gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Hardware > Accessing the RAM on a NDS Slot 2 cartridge

#177800 - nitro2k01 - Wed Mar 13, 2013 12:35 am

I have a NDS slot 2 cartridge that came with an M3 Real NDS flash cartridge package. Inside, it has an Altera MAX 2 CPLD, a RAM chip for holding a ROM image, a battery backed SRAM chip and an S3511A RTC chip.
Now I'm looking for any hints on how one would write to the "ROM" RAM. Is it open for access, or do you need to write an unlock sequence to access it? I've seen documents describing this before, but not sure where.

Images for those may be interested:

[Images not permitted - Click here to view it]

[Images not permitted - Click here to view it]

[Images not permitted - Click here to view it]
_________________
My blog

#177801 - Dwedit - Wed Mar 13, 2013 1:04 am

Try this code:
ram.c: http://pastebin.com/aEzTmxe0
ram.h: http://pastebin.com/ebSuRirE
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#177802 - elhobbs - Wed Mar 13, 2013 11:34 am

The ram in these gba carts is typically 16bit access only like VRAM. So, you need to be careful and avoid things like memcpy and memset which may try to use 8 bit writes - which would write bad data. Any 8bit reads at all will cause unexpected results. And keep in mind that gcc will emit its own memcpy calls for things like struct copies. Also it is really slow.

#177803 - nitro2k01 - Wed Mar 13, 2013 5:26 pm

Dwedit wrote:
Try this code:
ram.c: http://pastebin.com/aEzTmxe0
ram.h: http://pastebin.com/ebSuRirE
Thanks for the code, however I had no luck with getting it working. After some struggling I managed to compile the code with DevKit Advance, but the test comes back negative. Both the automatic test (ram_init(DETECT_RAM)) and some things I tried like always using _ram_test_nolock in case somehow the provided unlock function worked but not the lock function, so hat part of the test worked. But no luck.

I noticed that the battery has run dry. I don't see how this could affect the function if he ROM emulation, however. I'm also noticing that D2 (the battery side of the diode bridge for the SRAM power supply) has been replaced with a resistor. I wonder if this means the battery is actually meant to be rechargeable, since this allows current to flow into the battery when external power is present, or if this is a mistake/extreme cost cut.
_________________
My blog

#177804 - elhobbs - Wed Mar 13, 2013 6:37 pm

unlock puts the device in RAM mode - lock puts it back in cart mode. So,the no lock version only differs in that it leaves the device in RAM mode. Did you try changing it from auto detect to specify the M3 device on init? I remember some devices having a problem with the auto detect logic.

#177805 - nitro2k01 - Wed Mar 13, 2013 6:47 pm

elhobbs wrote:
unlock puts the device in RAM mode - lock puts it back in cart mode. So,the no lock version only differs in that it leaves the device in RAM mode.
No, the normal version also confirms that the lock command took effect and only returns true if that passes. Say that the unlock function works for my cartridge, but the lock function does not for some reason. Then the normal version of the test will fail because the cartridge still acts as RAM after the lock function failed to lock the cartridge.
But, that did not make a difference in my case. It was just something I tried when trying to think of reasons why the test might fail.
elhobbs wrote:
Did you try changing it from auto detect to specify the M3 device on init? I remember some devices having a problem with the auto detect logic.
Yes.
_________________
My blog