Gameboy Development Forum

Hi, I'm the author of Bleep. I can't provide the source (yet). I will release the source to Bleep when I finish it. But until then, I can tell you that it's written in a high-level assembly language that maps almost 1:1 to the GBZ80 instruction set, you can reverse engineer the source code using a disassembler to get a rough idea of the original, just know that there are a lot of things that I intend to change, so this is why it's not public yet.

In the meantime, I can explain how to persist things to save RAM.

It depends largely on your cartridge's MBC type. I use MBC5: http://gbdev.gg8.se/wiki/articles/MBC5

Here's a summary of save management for MBC5 (the other MBCs work similarly, but read their documentation to be sure):

- Select an 8K bank of save RAM to view by writing $0 - $F into $4000.
- The bank you selected will be visible in 8K memory area from $A000 - $BFFF.
- Enable save RAM access by writing $0A to $0000. When enabled, you can read/write to $A000 - $BFFF.
- Disable save RAM access by writing $00 to $0000.

The first time you use save RAM, it will be uninitialized. Some emulators will fill this with zeroes, but good emulators like BGB will fill this area with random noise (or in the case of single-ROM dev carts, might be the save data of another ROM). To ensure your save is initialized, and not just garbage memory, you need to write a signature of some kind into the RAM. This signature could be a simple 2-3 byte sequence, like a short piece of text or numbers. If this signature isn't there, you should initialize your save RAM (possibly by clearing it, maybe doing more) and then add the signature.

Some stuff will improve their save format and also add simple checksum or parity fields. This can be useful for detecting corrupted saves, by verifying that the checksum/parity of the bytes in the save match the value in the checksum fields. This helps integrity check saves are written correctly, and for games, might be useful to prevent undesirable states from being reached. Bleep doesn't do this (but might do some limited validation -> correction in spots), because for a song editor, a corrupted song is slightly better than completely losing a song, and can be fixed.

Last edited by Overkill (2014-08-04 18:58:32)

I only use assembly, so I unfortunately am not familiar with how GBDK handles that.  GBDK must handle bank-switching for ROM code bigger than 32K, but my guess for variables is it would only use the 8K of system RAM and not touch the cartridge RAM. You can definitely write to the SRAM in C, but you may need to do it a bit manually.

Methods in order of niceness:
1) Use GBDK's library functions or macros.
2) Create a pointer to the memory-mapped registers explained in the docs for your specific cartridge MBC. So, like, create a volatile uint8_t* / volatile unsigned char* pointing at the memory locations (SRAM area + the bank switch registers) you want to address and then write values into it.
3) Alternatively, some helper functions with inline assembly could write to the MBC RAM bank registers. Then once RAM is enabled and the correct bank is selected, you can have a volatile pointer that will be used to write a bunch of junk into SRAM.

That hopefully should be enough to by.

Last edited by Overkill (2014-08-12 19:03:14)