ChibiAkumas ASM Programming Forum

http://www.chibiakumas.com/z80/platform.php#LessonP8

We're going to do Hello World, and show a graphic on the Sega systems in this lesson...

Because the SMS/GG are not bitmap displays, we'll have to define our font as tiles , and set areas of the tilemap to those letters to show them on the screen... then we'll define our bitmap as some more tiles, and show it onscreen too!

Your graphics code does not work on real hardware ( which is a sega master system 2).
I was trying to make a game using your code to draw backgrounds and software
sprites for the sega master system 2 but your code does not work when used in
a simple way on real hardware sega master system 2.

I made a simple 32KB cartridge program only using your code-which there is not much of-to draw a 256 square block of tiles (16 tiles high and 16 tiles wide)

see
16by16blockoftiles.png below in the version 3.64 Fusion emulator it works as expect and showing the square block of tles drawn on screen using your FillAreaWithTiles subroutine code and some of your other subroutines code see

see emulatoroutput.png below
But on
a real sega master system 2 it shows as shown in the photo and the photo was taken of the TV screen

realhardwaresegaoutput.jpeg below
The black line is the aerial of the master system 2 so just ignore that
and the white spot is a flash from the camera so just ingnore that.


Clearly the output is incorrect from your code and has a bug somewhere-
the most obvious different is that is shows a square of 16 by 16 tiles
in the emulator and on real hardware it is NOT a square of 16 by 16 tiles.
Another obvious difference is the output on real hardware looks
less repetitive in the pattern in the 16 by 16 block.


For some reason I could not upload the .RAW 16 by 16 tiles image generated
by akusprite but it would be easy to make a substitute image anyway

The code used from your lessons to make the ROM image used to test both on the real hardware
sega master system 2 and the Fusion sega emulator is given below .


;;;Simple graphics tile drawing code that
;;;;does not work on real hardware (sega master system 2)

vdpControl equ &BF
vdpData equ &BE


org &0000
jr ProgramStart ;&0000 - RST 0
ds 6,&C9 ;&0002 - RST 0
ds 8,&C9 ;&0008 - RST 1
ds 8,&C9 ;&0010 - RST 2
ds 8,&C9 ;&0018 - RST 3
ds 8,&C9 ;&0020 - RST 4
ds 8,&C9 ;&0028 - RST 5
ds 8,&C9 ;&0030 - RST 6
ds 8,&C9 ;&0038 - RST 7
ds 38,&C9 ;&0066 - NMI
ds 26,&C9 ;&0080

; effective Start address &0080
ProgramStart:
di ;Disable interrupts
im 1 ;Interrupt mode 1
ld sp, &dff0 ;Default stack
;init the screen

ld hl,VdpInitData ;Source of data
ld b,VdpInitDataEnd-VdpInitData ;Byte count
ld c,vdpControl ;Destination port
otir ;Out (c),(hl).. inc HL... dec B, djnz




ld hl, &c000 ; set VRAM write address to CRAM (palette) address 0
; note &C0-- is a set palette command... it's not a literal memory address
call prepareVram

ld hl,PaletteData ;Source of data

ld b,32 ;Byte count (16 on SMS)

ld c,vdpData ;Destination port
otir ;Out (c),(hl).. inc HL... dec B, djnz




ld de,0; this defines the tiles using .RAW file it is a 4 by 4 set of tile
ld hl,Bitmap; the tiles data here is shared with the sprites
ld bc,BitmapEnd-Bitmap
call DefineTiles




ld bc,&0000
ld hl,&1010;THIS IS THE tst image 16 by 16 tiles( or 10 by 10 in hex)
ld de,&0000
call FillAreaWithTiles

pausescreenloop:
ld a,0; does nothing useful except pause screen
inc a
jp pausescreenloop






prepareVram: ;Set vdpData to write to memory address HL in vram
ld a,l
out (vdpControl),a
ld a,h
or &40 ;we set bit 6 to define that we want to Write data...
out (vdpControl),a ;As the VDP ram only goes from &0000-&3FFF
ret ;this does not cause a problem


; VDP Register settings (needed to turn on screen)

VdpInitData:
db %00000110 ; reg. 0, display and interrupt mode.
db 128+0
db %11100001 ; reg. 1, display and interrupt mode.
db 128+1
db &ff ; reg. 2, name table address. &ff = name table at &3800
db 128+2
db &ff ; reg. 3, Name Table Base Address (no function) &0000
db 128+3
db &ff ; reg. 4, Color Table Base Address (no function) &0000
db 128+4
db &ff ; reg. 5, sprite attribute table. -DCBA98- = bits of address $3f00
db 128+5
db %00000100 ;&ff ; reg. 6, sprite tile address. -----D-- = bit 13 of address $2000
db 128+6
db &00 ; reg. 7, border color. ----CCCC = Color
db 128+7
db &01 ; reg. 8, horizontal scroll value = 0.
db 128+8
db &00 ; reg. 9, vertical scroll value = 0.
db 128+9
db &ff ; reg. 10, raster line interrupt. Turn off line int. requests.
db 128+10
VdpInitDataEnd:


VdpInitDatas:
db &01 ; reg. 8, horizontal scroll value = 0.
db 128+8
db &11 ; reg. 9, vertical scroll value = 0.
db 128+9
VdpInitDataEnds:


; Basic palette in native format

PaletteData:

db &00
db &01
db &04
db &05;dark yellow
db &10;;;dark blue
db &33
db &30
db &15
db &15;; dark gray
db &03
db &0C;;light green
db &0F
db &10
db &33
db &3C
db &3F
db &00
db &01
db &04
db &05;dark yellow
db &10;;;dark blue
db &33
db &30
db &15
db &15;; dark gray
db &03
db &0C;;light green
db &0F
db &10
db &33
db &3C
db &3F





; this is common to all systems


; Footer


GetVDPScreenPos: ;Move to a memory address in VDP by BC cursor pos
push bc ;B=Xpos, C=Ypos
ifdef BuildSGG
ld a,c
add 3 ;Need add 3 on Ypos for GG to reposition screen
ld h,a
else
ld h,c
endif
xor a
rr h ;Multiply Y*64
rra
rr h
rra
rlc b ;Multiply X*2 (Two byte per tile)
or b
ifdef BuildSGG
add 6*2 ;Need add 6 on Xpos for GG to reposition screen
endif
ld l,a
ld a,h
add &38 ;Address of TileMap &3800
ld h,a ;(32x28 - 2 bytes per cell = &700 bytes)
call prepareVram
pop bc
ret


FillAreaWithTiles:
;BC = X,Y)
;HL = W,H)
;DE = Start Tile
ld a,h
add b
ld h,a

ld a,l
add c
ld l,a
FillAreaWithTiles_Yagain:
push bc
push de
push hl
call GetVDPScreenPos ;Move to the correcr VDP location
pop hl
pop de
FillAreaWithTiles_Xagain: ;Tilemap takes two bytes, ---pcvhn nnnnnnnn
ld a,e ;p=Priority (1=Sprites behind) C=color palette (0=back 1=sprite), V=Vert Flip, H=Horiz Flip, N=Tilenum (0-511)
out (vdpData),a ; ---pcvhn
ld a,d
out (vdpData),a ;nnnnnnnn

inc de
inc b
ld a,b
cp h
jr nz,FillAreaWithTiles_Xagain
pop bc

inc c
ld a,c
cp l
jr nz,FillAreaWithTiles_Yagain

ret

DefineTiles: ;DE=VDP address, HL=Source,BC=Bytecount
ex de,hl
call prepareVram
ex de,hl
DefineTiles2:
ld a,(hl)
out (vdpData),a
inc hl
dec bc
ld a,b
or c
jp nz,DefineTiles2
ret

org &3FF0

Bitmap:
incbin "C:\testonrealsms\smstest256chars.RAW"

BitmapEnd:

org &7FF0
db "TMR SEGA" ;Fixed data (needed by some SGG)
db 0,0 ;Reserved
db &69,&69 ;16 bit Checksum (sum of bytes $0000-$7FEF... Little endian) checksum corrected in ROM image these are default values from lesson
;Only needed for 'Export SMS', not checked by emulator without bios
db 0,0,0 ;BCD Product Code & Version

ifdef BuildSGG ;Region & Rom size (see below) - only checked by SMS export bios
db &6C ;GG Export - 32k
else
db &4C ;SMS Export - 32k
endif




;&3- SMS Japan
;&4- SMS Export
;&5- GG Japan
;&6- GG Export
;&7- GG International
;&-C 32KB
;&-F 128KB
;&-0 256KB
;&-1 512KB

Yeah, I'm afraid I don't really care if my examples work on real hardware or not - I'm a hobbyist, and I only ever state they work on emulators.

Testing and debugging for real hardware would take an impossible amount of time (I don't even own real hardware for many of the systems I develop for... I don't even LIKE half of them)

I do not make money from my youtube channel - it costs me more in time than I get in donations.
I've stated in the past I will not attempt to test on real hardware unless it becomes 'economically viable' (pays me minimum wage for the hours it takes)

I realize this may seem disappointing, but look at it this way, This video was made 4 years ago, and you're the first person to report a problem.... Kind of like no-one really cares if my example works or not isn't it? (The video in question has 1.8k views - total YT income to me $0.22)

I guess I'd try and put a few NOP commands after the OUTs, maybe the VDP is getting the commands too quickly to process (seen that problem on the MSX)
If you figure out a fix for the problem, feel free to let me know.

I guess the answer is in some sega programming assembly book.

I've come across these kind of problems on the CPC and MSX, and it's basically trial and error until it works.

You have to read over the technical docs, come up with a hypothesis of what's going wrong, write a new version of the example that 'fixes' that possible problem, and repeat until the problem's solved. It's a time sink, and it's stressful as F--k, if for no other reason than until you fix it, you're 'project' is dead

sometimes it takes an hour, sometimes a day, sometimes a week - That's why I can't do it for a small youtube channel - I just can't handle the stress it causes, To be honest I've pretty much vowed never to do another commercial game release so I don't have to do the exhaustive real hardware bug testing again - It's literally 10x more stressful than my day job.

I found a 'bug' in the OpenMSX V9990 emulation - There's a 1 byte cache in the vdp vram writes - one of the devs swore there definitely wasn't such a cache, but it was the only explaination for the graphical glitches I was seeing, and I proved there was by modifying my game until it works.... To my knowledge, there's no documentation of that cache.
What I'm saying is you just have to work until you fix the problem.

I'm sure the SMS issue isn't as hard to find, but I'm also sure it will take just as long to solve on real hardware, just because of the time it takes to transfer rom images to a cartridge emulator and so on.

The heydays (or the 1980s) of all 8bit systems has passed and 8bit retro system programming
is always going to have a smaller audience or less money than compared to programming
a modern system such as a cartridge game for Nintendo Switch or a game for PS5 or
a game for Xbox one console where more money is made for a successful game.
I will try out your suggestion to save you time as my hardware is already set up and I have no issues with hardware testing which I find fun. Moving the cartridge image from PC to the real master system 2 hardware is actually done automatically for me so no issue.

testing on real hardware is no issue for me. The hard part for me is the software part i.e. If it doesnt work I will need to think of the hypothesis for new code.

An emulator is based on how some person personally thinks how the hardware works. If the programmer did not fully understand the hardware then it is possibly emulated wrongly in some aspect of it. That is why I want to test my program on real hardware to make sure it 100% works because it a real thing instead of possibly what some person may wrongly think about how the hardware works.

Sure, the real question is is it worth it?

As you said, the market of 'real hardware' people is only going to shrink closer to closer zero over time. and no matter how hard you work or good a game you make, you'll never earn anything from a physical release - so is it even worth bothering to make it work on real hardware if you'll never get anything for it, and no one will care but you?

I put everything I had into ChibiAkumas Ep2, including all the real hardware testing time - everyone's forgotten it exists now, in fact judging from my web analytics, they forgot in a week.

I'm not criticizing your effort... just asking myself out loud.

I hear your voice and you interesting words.

I did not say it would shrink closer to zero.

On the contrary I actually think money can be made from writing or selling great retro games. E.g. the company "Limited Run Games" makes tons of money from from publishing new great physical retro games. Lots of business today are still selling games or new hardware for old consoles.

My goal is not making money from writing commercial games but if it was I would start by making a game for a modern systems instead such as Nintendo switch,PS5 or xbox one since everyone knows about these modern consoles and the chances of making money is greater because the audience bigger since they have millions of current owners. More sales are likely a short time after a new console is launched. For modern games on computer or console the number of customers for the non-physical or physical game market is in the tens of millions of potential customers compared to the number of customers for the physical retro game market so the audience is bigger. For me it not only about money because I am simply interested in learning new retro technology things. I am only mentioning money because you mentioned about money in your first reply.

If you use a game engine like Unreal 5 or Unity you would make the game on a PC then test
it on real hardware an PS5 ,Xbox one, Nintendo Switch for example and this is what current professional software development game companies do or I do. So in modern times the real hardware step is still needed. A challenge with programming the ARM based Nintendo switch is it is under powered compared to a Xbox One/PS5 for programming the same game.