SpritesMind.Net

I think I'm having a bit of misunderstanding with initializing the SRAM in the header, and I'm hoping one of you more experienced programmers can help me out

Using the BEX ASM library and this wiki article: https://en.wikibooks.org/wiki/Genesis_Programming , I've attempted to set the header up with the following:
If I understand the wiki article, then the SRAM should be enabled and addressing both even and odd bytes, and SRAM size is 8 KB. I'm able to successfully write to SRAM from my BASIC compiler, and this is where my questioning/misunderstanding is coming in. When I look at the .SRM file that Fusion creates, the file is only a few bytes large. If I run the same SRAM code from BEX (using the BEX SRAM syntax), the .SRM file that is created is 8 kb.

My question is: Does the size of the SRAM file that Fusion creates (or I suppose every emulator creates) just depend on how much you utilize the SRAM (like, if I only write 6 bytes, the file will be 6 bytes), or does the file get padded based on the size in the header? Or, does the size in the header not really matter like some of the other options?

I can tell just looking at it, the SRAM header is wrong. But fear not, as for most emulators this does not matter. This is also why the Fusion .srm file is usually only so large as you have written to it, rather than the intended size. There is no way to force this, other than to fill it completely. Then again it is also not necessary to do so. However, Bizhawk wont enable SRAM unless the header is correct. Your problem specifically, is the extra dc.l $0000 after the line describing SRAM type. If the data is aligned in ROM, it should be good to go. Test with Bizhawk to confirm.

elusive wrote: My question is: Does the size of the SRAM file that Fusion creates (or I suppose every emulator creates) just depend on how much you utilize the SRAM (like, if I only write 6 bytes, the file will be 6 bytes), or does the file get padded based on the size in the header? Or, does the size in the header not really matter like some of the other options?

Fusion will limit the size of SRAM file to what is actually written (maybe padded up to a power of 2 but I doubt it). It will also always write SRAM as 16-bit, ignoring the odd/even byte flag in the header field, so the size will actually be twice the desired size, with unused bytes.

Most (if not all) emulators do not care about the SRAM size (also remember there is no SRAM size field in the header, just a Backup RAM type byte, start address and end address so this needs to be calculated), they usually only look after the "RA" characters and SRAM start address to know if SRAM should be emulated and where.

Keep in mind that the ROM header is just a standard set by Sega and only served for production, the console does not care about it and actually many games do not respect the standard but still work and save fine, so emulators should - in theory - behave the same.

Natsumi wrote:Bizhawk wont enable SRAM unless the header is correct.

As said above, many released games with SRAM (mostly EA games I think, for example Buck Rogers and Might & Magic games) do no respect the header standard so this is not a good idea to do so.

Okay, so the hardware and emulators don't care about the header as far as SRAM is concerned? Am I understanding that right?

So if I want to use SRAM on the hardware, is all I need to do is read and write to the desired locations (say at &h200000) and if the pcb is wired for it, use even, odd, or both and I shouldn't have any issues?

Also, isn't backup ram the same as SRAM? If not, what are the differences? (Sorry for all the questions!)

Natsumi wrote:I can tell just looking at it, the SRAM header is wrong. But fear not, as for most emulators this does not matter. This is also why the Fusion .srm file is usually only so large as you have written to it, rather than the intended size. There is no way to force this, other than to fill it completely. Then again it is also not necessary to do so. However, Bizhawk wont enable SRAM unless the header is correct. Your problem specifically, is the extra dc.l $0000 after the line describing SRAM type. If the data is aligned in ROM, it should be good to go. Test with Bizhawk to confirm.

I completely missed your comment on my issue! I will look into this when I get home thanks a lot!

elusive wrote:Okay, so the hardware and emulators don't care about the header as far as SRAM is concerned? Am I understanding that right?

For real hardware, yes, unless you are using a flashcart where SRAM access is only enabled by the embedded OS after looking at the loaded ROM header (i don't think any flashcart does that but you never know). For emulators, it depends on which emulator you are using. It's always better to respect the standard on that regard, to ensure software compatibility with everything.

So if I want to use SRAM on the hardware, is all I need to do is read and write to the desired locations (say at &h200000) and if the pcb is wired for it, use even, odd, or both and I shouldn't have any issues?

Yes, it depends on the address decoding, connected data bus and write strobe signal used by the cartridge to select / access SRAM chip (most of them use VA21 and /CE0 to select up to 32kB of SRAM in $200000-$3fffff range, VD0-VD7 and /LWR so only odd address / low byte writes goes to SRAM but different pcb layouts also exist). Some emulators / flashcarts only support this most commonly used SRAM layout so again, it might be better to stick with it when you can.

elusive wrote:Also, isn't backup ram the same as SRAM? If not, what are the differences? (Sorry for all the questions!)

Backup RAM is more generic, there are different type of external memory used for backup and the header type field has bits to distinguish between them. See the documentation below if you are interested :

Eke, thank you for that wealth of knowledge. My plan is to support standard usage of SRAM so any compiled rom could use any general sports game as a donor pcb (and my SRAM pcbs that I had designed and made up, which supports ODD, EVEN, and BOTH; tested using BEX and all).

I still have some confusion and questions, but I'll ask those after I get home from work to go over the information everyone has provided and can do some testing (and hope I can clear some confusion before posting those questions)

Thanks again!

Natsumi, a big thank you for pointing out the dc.l $0000 after the SRAM portion. That wasn't affecting the SRAM, but instead the region settings. Regardless, thank you for quickly pointing out that mistake I also tested the ROM in BizHawk (neat emulator, btw, thanks for showing that to me!) and it worked before I made the changes to the header code.

Eke, that scan is exactly what I believe I needed.

Just to make sure I'm understanding all of this, and using that scan, for a typical 8KB SRAM, using battery backup, should be: A few questions about the random syntax:
The ?: In the scan, it mentions volatile and non-volatile RAM. Is battery backed SRAM considered non-volatile because it's backed up by a battery, or volatile because if the battery isn't present (or dead), the data is lost on power off? Maybe both depending if a battery is actually used or not? All of the examples I've seen use 111 and not 101, so I'm going to assume that it doesn't really matter and External/SRAM is always handled by code, or SRAM utilizing a battery is non-volatile.

[Type]: Depending on the SRAM configuration, it will either be ODD (11), EVEN (10), or WORD (00), typically. The exceptions would be games that use Serial EEPROMS (such as Evander Holyfield and Wily Wars; I also found Eke's document on Serial EEPROM's). A quick question about Serial EEPROMs: is the code to read and write to Serial EEPROM's the same as standard SRAM, and the hardware configuration deals with the different type, or is there more to it than that?

* and ABCD: The * would either be the odd or even byte, depending on the write mode, right? I suppose it really doesn't matter since if you're writing to the ODD byte, you can't use the even "0" address and have to start at 1 anyway, and if you're writing to the EVEN byte, then using an odd to start off with would just reduce the amount of SRAM available to you.

Now a question about setting the SRAM size - what is the proper way to calculate it? The example in the scan shows for 8k, the end address is $203FFF, a difference of 3FFF, which is 16383 in decimal, or 2 KB. Or is it really 16k, but since the example is using ODD, it's halved and referenced as 8k instead, which would really be 1 KB?

If I understand all of that right (or most of it), if I wanted to use a 256kb SRAM chip, the ending address would be $23FFFF, right?

Thanks for these noobish questions, I really appreciate it

EDIT:

One final question: For the region settings, do the letters have to be in a specific position, or order? For example, worldwide is JUE, but if I wanted just Europe, would it be 'E', or ' E', and if I wanted Japan and Europe, would it be "J E' or 'JE'?

elusive wrote: A few questions about the random syntax:
The ?: In the scan, it mentions volatile and non-volatile RAM. Is battery backed SRAM considered non-volatile because it's backed up by a battery, or volatile because if the battery isn't present (or dead), the data is lost on power off? Maybe both depending if a battery is actually used or not? All of the examples I've seen use 111 and not 101, so I'm going to assume that it doesn't really matter and External/SRAM is always handled by code, or SRAM utilizing a battery is non-volatile.

Battery backed RAM is non-volatile. I don't think there are any released games with volatile external RAM and I'm sure emulators / flashcarts software completely ignore this bit anyway.

[Type]: Depending on the SRAM configuration, it will either be ODD (11), EVEN (10), or WORD (00), typically. The exceptions would be games that use Serial EEPROMS (such as Evander Holyfield and Wily Wars; I also found Eke's document on Serial EEPROM's). A quick question about Serial EEPROMs: is the code to read and write to Serial EEPROM's the same as standard SRAM, and the hardware configuration deals with the different type, or is there more to it than that?

It requires specific routines as data must be read/written serially (bit by bit) and eeprom protocol (generally i2c but not always) must be fully handled by the game. Cartridge hardware only manages the connection between eeprom pins and cpu address/data lines.

* and ABCD: The * would either be the odd or even byte, depending on the write mode, right? I suppose it really doesn't matter since if you're writing to the ODD byte, you can't use the even "0" address and have to start at 1 anyway, and if you're writing to the EVEN byte, then using an odd to start off with would just reduce the amount of SRAM available to you.

Correct but again, it will only reduce anything that is available if emulator/flashcart software actually check all accesses precisely against these addresses, which is quite unlikely.

Now a question about setting the SRAM size - what is the proper way to calculate it? The example in the scan shows for 8k, the end address is $203FFF, a difference of 3FFF, which is 16383 in decimal, or 2 KB. Or is it really 16k, but since the example is using ODD, it's halved and referenced as 8k instead, which would really be 1 KB?

The size is in bytes so $200000-$203FFF covers 16KB of CPU memory range but only 8KB of SRAM if it is a 8-bit chip like most SRAM games used. Remember the 68000 uses a 16-bit bus (VD0-VD15) so when mapped to a 8-bit bus, only "odd address" / low (VD0-VD7) or "even address" / high (VD8-VD15) byte can be used, which halves the accessible SRAM size.

If I understand all of that right (or most of it), if I wanted to use a 256kb SRAM chip, the ending address would be $23FFFF, right?

If you mean 256KB and 16-bit SRAM, then yes, otherwise no, 32KBx8 SRAM would be mapped up to $20FFFF. Also note that due to the way SRAM address lines are usually wired and decoded, access above that "end" address will rollup to the start of memory array.

One final question: For the region settings, do the letters have to be in a specific position, or order? For example, worldwide is JUE, but if I wanted just Europe, would it be 'E', or ' E', and if I wanted Japan and Europe, would it be "J E' or 'JE'?

I don't think there is any rule for that. It is only used by emulators to guess the default region system to emulate and, generally, as long "U" is present, it will automatically run in NTSC mode by default. If for some reason you absolutely need your game to run in PAL mode, putting only "E" will generally force emulators to do so. There is no need for region (U/J) distinction unless your game has some region lockout implemented and flashcarts will likely ignore that field since they can't change the console region (they might be able to patch the ROM header themselves if they have some sort of region bypass feature for games that have region lockout routines).

Thanks Eke!

elusive wrote:My question is: Does the size of the SRAM file that Fusion creates (or I suppose every emulator creates) just depend on how much you utilize the SRAM (like, if I only write 6 bytes, the file will be 6 bytes), or does the file get padded based on the size in the header? Or, does the size in the header not really matter like some of the other options?

From experience: Fusion only writes the parts the game touches. From more experience: it always emulates 64KB worth of 16-bit SRAM, even though no official game ever used that (and heck, when it comes to homebrew I think only gasega's mode 7 stuff relies on that)

But yeah. Most emulators just assume 64KB of 16-bit SRAM, period (except that Fusion can detect EEPROM support without going through a hardcoded list, if you set the header properly). Genecyst is the only emulator I'm aware to actually need correct data in the header (this was probably before it was noticed that several games didn't have correct information in the header anyway).

Flashcarts normally support only one kind of save memory (if any at all) so check the flashcart's documentation. As for your own cartridges, well that's up to you =P

Sik wrote:

elusive wrote:My question is: Does the size of the SRAM file that Fusion creates (or I suppose every emulator creates) just depend on how much you utilize the SRAM (like, if I only write 6 bytes, the file will be 6 bytes), or does the file get padded based on the size in the header? Or, does the size in the header not really matter like some of the other options?

From experience: Fusion only writes the parts the game touches. From more experience: it always emulates 64KB worth of 16-bit SRAM, even though no official game ever used that (and heck, when it comes to homebrew I think only gasega's mode 7 stuff relies on that)

But yeah. Most emulators just assume 64KB of 16-bit SRAM, period (except that Fusion can detect EEPROM support without going through a hardcoded list, if you set the header properly). Genecyst is the only emulator I'm aware to actually need correct data in the header (this was probably before it was noticed that several games didn't have correct information in the header anyway).

Flashcarts normally support only one kind of save memory (if any at all) so check the flashcart's documentation. As for your own cartridges, well that's up to you =P

Sik, I believe you're 100% correct on that Fusion only allocates what it touches.With my testing, whenever I wrote to the first byte (EVEN, ODD,or WORD), it only allocated 1 kb for the .SRM file, and when I wrote to a higher location, it wrote the .SRM file up to that byte. I'm not sure what BEX is doing to allocate all 64kb, but it seems to be working with all the help given in this thread

I tested it with Bizhawk as suggested by Natsumi, and everything worked well. I also used GenRomSuite to verify that the header data was being written properly (it wasn't, even after Natsumi's notice, but with Eke's scan, Charles MacDondald's VDP document, SonicRetro, and a few other documented sources, I was able to figure the rest out )

All the flash carts I've used (really just the Everdrive MD and Mega Everdrive MD for Genesis), they support typical battery backed SRAM. My own PCB's will match the standard SRAM specs (&h200000 starting address), so I'll be doing some testing on the real hardware hopefully by the end of next week

I suppose that BEX notices SRAM wasn't used yet and it's clearing SRAM (hence touching all 64KB).

On Mega Everdrive (with 16-bit sram) most(or all) byte instructions doesn't work on odd addresses.