It is currently Tue Dec 11, 2018 3:30 pm

All times are UTC - 7 hours

Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Aug 24, 2016 2:05 pm 

Joined: Sat Aug 28, 2010 9:01 am
Posts: 221
TravistyOJ wrote:
everdrive seems to present RAM as FF's, which I imagine is what a brand new game would have on it's SRAM.

No, SRAM is essentially random on power-up. Each bit cell consists of 2 nand gates connected in feedback. When powered, the feedback keeps the cell stable. But on power-up, a cell has no defined state and could stabilize to either state. Different cells in the array can be more likely to stabilize to either 0 or 1 depending on the design of the chip, which gives interesting patterns in uninitialized SRAM, but it will typically not be all 1 or all 0.

PostPosted: Tue Aug 30, 2016 12:53 pm 

Joined: Sat Aug 06, 2016 10:22 pm
Posts: 16
Hey guys, I am Capaneus on the romhacking forum, the guy who started working on this a couple of years ago, and unfortunately got sidetracked by other projects/life. Coincidentally, I thought about this a couple of days ago and found this thread. First, I thought I'd do a little more experimentation, and after fixing the checksums, I've found my original changes do work on real hardware on an EverdriveGB with game type 09 (ROM+RAM+BATTERY) so long as I seed the .srm file with zeros. Obviously, that's just part of the solution as a real SRAM game would be able to initialize the ram (everdrive seems to present RAM as FF's, which I imagine is what a brand new game would have on it's SRAM. I'm completely new to asm, so I imagine you are already farther along on that front, but I wanted to pass along my discovery.

Hey Capaneus, good to see you here! I wouldn't have even attempted this stuff if you hadn't already wrote all those notes in that thread, so thanks! I'm surprised you got a working way to get SRAM working as a type 09 on the Everdrive. Nothing I've done so far has worked. Just FFFFFF's and and lines of a strange symbol. Would you be willing to share an ips patch of your working rom? Your method of seeding the SRM with zeroes is working for me on bgb, but not the Everdrive.

I still plan on writing new ASM code that works with nitro2k01's code he wrote for me. I've just been busy these last couple of weeks (even neglecting to check the thread for updates). When I get some time I will be doing some ASM reading and learning and hope to take a crack at writing the code.
Thanks again nitro2k01 for all the help and patience.

PostPosted: Wed Sep 07, 2016 10:12 pm 

Joined: Sat Aug 06, 2016 10:22 pm
Posts: 16
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
; 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?
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[i]-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 (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:
ld  (hl), 6CC
inc  c
jr  6F3b
ld a, (bc)
inc d
jr, z, 6F8B
and  b
ld  e, 3C
ld  a, b
ld  c, 6F
ld  sp, hl
ld  a, h
rest 38
ld  a,h
ld  de, 217D
ld  a, l
dec  b
ld  l, a
ld  c, b
ld  a, (hl)
ld  b, h


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:
        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 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.

PostPosted: Sun Sep 18, 2016 3:08 pm 

Joined: Wed Aug 24, 2016 7:30 am
Posts: 2
Hey there, sorry it took so long for me to check in, I was on a long unplugged vacation, but I'm back. For any interested, you can find the whopping 34 byte patch here:

I'm gunna continue fiddling with the ASM already provided in this thread to get it to support SRAM init. Thanks!

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group