is there any trick when accessing the SAVERAM using the Flashboy Plus? I tried storing some values and everything works fine in RealityBoy. However, when I use the Flashboy I get strange results from data not being stored to randomly changing data.
Isn’t the SRAM hooked to the same bus as the rom but only half of the data lines hooked up?
Is it the data lines that are used every second one and not just the upper or lower half?
So is the SRAM using D1, D3, D5, D7, D9, D11, D13, D15 instead of just D0-D7 or D8-D15?
Guess I could open a cart and have a look…
It would actually be great if someone else would look into this. I just hacked something together that worked for me. However, it would be great if someone could end the ongoing speculations and post some code that shows how it should be done.
HorvatM wrote:
I understand that the lowest bit is always zero, but if you look at GP’s SRAM, you will see that, for example, the player names are stored as consecutive ASCII characters, and it uses all 8K of the SRAM. So how does it access the odd bytes? Does the SRAM support 16-bit I/O or what?
I assume you mean a file generated by an emulator, since a dump of the actual chip would be pointless. However, you should specify which emulator.
I just looked at a GP RAM file made by (I think) Reality Boy. It’s 8K in length. That explains the lack of “garbage” bytes: they’re not written to the file (otherwise, it would be 16K in size).
I also looked at Mednafen’s (0.9.17.1) save folder. None of the VB save files I have are larger than a few hundred bytes, which means some kind of compression is being used (possibly just a means of skipping the unused areas, given that most games don’t use the entire 8K).
e5frog wrote:
Seems a bit odd to me.
Isn’t the SRAM hooked to the same bus as the rom but only half of the data lines hooked up?
Is it the data lines that are used every second one and not just the upper or lower half?
I’m 99% sure that the lower (“even”) byte of the VB’s bus is hooked up to the SRAM. It doesn’t matter which of the SRAM’s data lines are hooked up to said bus lines, though, as long as the same ones are used for both reading and writing. The same goes for the ROM, as well as the address lines on either chip. The lines are almost always used in numerical order, however. This simplifies preparation of the file to be written to the ROM.
Compared to the ROM: A0-A12 are hooked to eachother and D0-D7. So it doesn’t seem that (hardware wise) it would be different from reading from the ROM but with only the lower eight bits.
Other differencies to ROM is the /WE on cart pin3, /CS1 cart pin 6, CS2 cart pin 7 (seemed to be held high).
So if I got this right…
If reading at address “SRAM” which is the first address for the SRAM’s first byte you should instead of getting 16 valid bits just get eight valid bits and the rest is crap. If listing the data as bytes that’s every second byte. As D0-D7 is hooked up to the sram it should be even bytes in such a data list that are valid ones, that’s byte 0, 2, 4 etc…
To solve this ancient riddle ;-), M.K. kindly provided his SRAM access code. I haven’t tested this yet, but apparently, the trick is to mask the return value.
u16* const SAVERAM = (u16*)0x06000000;
// write (0 < x < 8191)
SAVERAM[x] = value; //8bit value
// read
value = SAVERAM[x] & 0xFF;
jorgeche contacted me yesterday and asked some questions about how to access SRAM. So I did put together a sample how to access all 8k of SRAM. Obviously, this is based on M.K.s solution.
The vb ROM also includes a little test-program that checks if everything is written correctly.
