Got some good news everyone. I've finally gotten a working version of Tetris that save high scores working on real hardware!
So when I read that Capaneus got a Type 09 version to save on his Everdrive GB it made me wonder what I was doing wrong. So I decided to try again. Seems it has been working this whole time, but I had the srm file (filled with zeroes) in the wrong SAVES directory on my card so it wasn't seeing the zeroed out save file. After I sorted that out it worked perfectly! I can save high scores for both Type-A and Type-B. I tested it on the Super Gameboy because it will boot the game even if the checksum header is wrong, which is not the case on the actual handheld. It even works WITHOUT the SRAM enable code inserted. I tried to change the rom type to 03h (MBC1) and insert the enable SRAM code
Code: Select all
; Enable SRAM.
ld a,$0A
ld [$0000],a
to see if that would work, but it didn't. I replaced the useless jump that nitro2k01 pointed out at address $0058 and put in this code. Not sure if you can call backwards into the rom? Or if this even worked?
Code: Select all
at $0058:
CALL $0010; free space
at $0010:
ld a, 0a
ld (0000), a
jp $005b; jump back to original code
It probably showed FFFFFF's in the score spots because of the reasons nitro2k01 explained before that there is no code to zero out the SRAM at the first initial bootup of the game.
So it was back to a type 09h rom. I needed to figure how to correctly recalculate a new checksum. The formula is this:
"x=0:FOR i=0134h TO 014Ch:x=x-MEM
-1:NEXT"
I cannot understand this for the life of me. I even tried to convert the hex bytes to binary and then add them up that way (which requires inverting the binary) since I read how to do it that way on the gbdev thread concerning calculating checksum headers. This did not work either. So then I read that a program from the year 2000 called RGBFIX can repair Gameboy checksum headers as one if it's features. However, I couldn't get this program to work. I was minutes away from downloading a Virtualbox to try and run it that way when I read on another GB thread about bgb having a checksum fixer.
It's as simple as opening the debugger in bgb, going to File -> Fix checksums. Then saving the GB file. This repairs both the rom checksum and header checksum. Honestly, I spent hours trying to recalculate this checksum and it only took seconds in bgb and was right in front of me this whole time. So frustrating, haha. Good news is that the game will now boot on the original handheld and any other device that runs Gameboy games (Pocket, Color, GBA).
So the only bad news is that it still requires a zeroed out SRM save file to work at first. I would upload this to romhacking.net (with credit to everyone here), but I still want to read up on ASM and see if I can get this working as a proper MBC1 game so that it doesn't need a zeroed out save file and works from the get go. Not to mention I would feel bad that nitro2k01 graciously wrote all of that code just for it to go to waste.
For people who are watching the thread and want to download it, if I can't get it working as a MBC1 game in a month or two I will upload what I have now as a patch for everyone (including a zeroed out save file).
I took a look at nitro2k01's code again and if I can manage to correctly insert it into the rom I may not have to write new code for the game to save high scores to SRAM since it's already doing that directly (reads/writes them to $A000 and $A654 instead of $D000 and $D654). This is what I'll be looking into next.
Also, I tried to do some research on the music side of things to see about putting the Type-A song from v1.0 into the v.1.1 of the game. I've been looking over many documents and I can't tell if there's a specific register that the Gameboy calls for music. I've read up before on MSU-1 for the SNES and how the SNES reads the music track from $2140-$2143. If it doesn't directly load the track number to be played into $2140 you can step back a bit into the code and find what register it uploads the track to. This is very easy with the snes9x Geiger debugger, but honestly the bgb debugger is a mystery to me.
So I have no idea where to find the music data for the Type-A song in v1.0, but I had an idea. The GBS music format takes the game rom and condenses it down to only the essential game music. So I downloaded GBS files of v1.0 and v1.1 and compared them in a hex editor and found a large chunk near the beginning which is different and probably the data for the Type-A song. If I look up those hex bytes in the actual rom and then go to them in the debugger I see operations like:
Code: Select all
ROM1:6F32
ld (hl), 6CC
inc c
jr 6F3b
ld a, (bc)
inc d
jr, z, 6F8B
and b
ld e, 3C
ld a, b
nop
ld c, 6F
ld sp, hl
ld a, h
rest 38
ld a,h
ld de, 217D
ld a, l
nop
dec b
ld l, a
ld c, b
ld a, (hl)
ld b, h
etc.
I can't really read code so well so for all I know this doesn't have to do with loading the data for Type-A or the data itself. However, in a GBS document about ripping sound from the rom I found this which looks familiar to the code I wrote above:
Code: Select all
ld hl,songs ; point to selection table
add a,l ; add accumulator to L
ld l,a
jr nc,$+1 ; increment H on overflow; if all table entries
inc h ; have same address MSB, you can eliminate this
ld a,(hl) ; read song number from table into accumulator
jp init ; jump to the init routine
songs: .db 3,1,5,4,2 ; selection sequence table
It doesn't seem there's a set place where music data is stored either. The rom maps for Pokemon Red and Battletoads are uploaded to datacrystal.romhacking.net and their music data are in totally different places.
I will open a separate thread about the music because the people who are experts on the Gameboy's sound hardware and GBS ripping and whatnot are probably not reading this thread because SRAM saving is something that might not interest them and this thread is about SRAM saving anyways.