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.

DS development > Feasibility of new hardware

#72310 - VortexDS - Fri Feb 17, 2006 4:03 pm

Hi all,
I have recently acquired a DS and am currently thinking about ways of running DS Code. I feel that the hacks involving passmes and such while useful for preliminary experiments is not very practical (and I need the GBA slot for other projects). So I started thinking about other options and the one that I have come up with is this:
The only reason that the flash cartridge/memory storage adapter is used is for the menu/loader code. surely this can be implemented in hardware. I was thinking about using a system with a CPLD to act as a passme type device as well as a cache controller. Data would come off SD card and be cached in SRAM in blocks of 512 bytes, the standard read write block for the SD cards. On boot the user would select an image some how, at the moment I am thinking of LCD display though thats a bit of a waste, maybe dip switches. a microprocessor would handle reading the FAT of the card and compiling a table of file start locations, which would then be given to the CPLD and the CPLD would handle the translation from NDS address request to SD card location, data retreival, from cache or loading a page from the SD card. The fact that the game data is stored in a ROM form makes the job of cache implementation easy, no cache poisoning or other nasties.
In my head it is a nice, fast solution but I wonder what others think.
Also I am trying to wrap my head around how the passme actually works, especially what actually occurs on boot up and how and when transfer is switched from the NDS to the GBA rom. Specifically related to the passme2 as my new DS shows a magenta screen when doing the firmware test.
If someone could give me a simple idea of the steps of the code that I can compare with the VHDL on the sites to get a feel for the code I would be greatful.
If others have started down a similar path and been stopped I would also like to hear there experiances.
thanks
Vortex

#72365 - chishm - Sat Feb 18, 2006 12:21 am

There is already a device that can read SD cards and goes in the DS slot - the Neoflash MK2/MK3. However, these also require a GBA cart to contain the menu code to select a ROM to load. This is because they act like a PassMe 1. They modify the header of the inserted DS card so that the ARM7 jumps to GBA cart address space where the menu is.

There is a way around using a GBA cart by installing a new firmware on the DS. This can either be a menu for ROMs, or load the menu code stored in the MK2 and jump to it.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#72380 - Darkflame - Sat Feb 18, 2006 2:18 am

Quote:
(and I need the GBA slot for other projects).


Your not going to be using the GBA games and homebrew at very the same time are you? :?

Running code from the GBA slot (ver,say, GBAMP ) dosnt mess up its ability to use the slot later...
Hot-swaping should be possible even.

#72399 - natrium42 - Sat Feb 18, 2006 8:10 am

Passthrough for DS is just like a switch: it can either connect data lines to DS card or to the values stored in PLD. When DS reads certain byte indexes in the header, passthrough switches to internal values.

This is how ARM7 and ARM9 entry points are replaced by new ones. ARM7 entry point is modified to go to GBA slot. ARM9 entry point is modified to go to an infinite loop that is also placed in the header by the PLD. Additionaly, header CRC is calculated by the PLD and corrected.

This is how PassMe1 works. PassMe2 redirects ARM9 to a BX LR instruction in the game binary itself and begins looping in an infinite loop. ARM7 is redirected to an out-of-range SWI call in the game binary. Luckily those SWIs are bugged in the BIOS and, in turn, jump to GBA SRAM. That's where some really crazy code sits which takes recreates PassMe1 state (so that homebrews don't have to be recompiled). Eventually, a jump to GBA flash is made.

You can see how this explot makes PassMe2 game dependent.

Credits: PassMe1 exploit was discovered by DarkFader. PassMe2 exploit was discovered by Loopy (Olimar on this forum).
_________________
www.natrium42.com

#72413 - HyperHacker - Sat Feb 18, 2006 12:11 pm

Hot swapping is possible, but has a tendency to freeze the system, especially if the cart is being accessed at the time.

#72458 - AnalogMan - Sat Feb 18, 2006 6:55 pm

Wasn't there a homebrew for the Rumble Pack released with Metroid Pinball? How was that executed? I'm assuming once you ran the homebrew it told you the right time to swap the carts, but I have never personally used it, so this is all conjecture.

#72466 - Darkflame - Sat Feb 18, 2006 8:04 pm

HyperHacker wrote:
Hot swapping is possible, but has a tendency to freeze the system, especially if the cart is being accessed at the time.


Certainly, but I meant if things where designed for it they wouldnt be accessing it at the swap time.

#72511 - HyperHacker - Sun Feb 19, 2006 10:33 am

No, but I've found it occasionally freezes even if the cart isn't being accessed. Can't say why for sure. It should just read garbage and continue running... maybe a hardware issue.

#72526 - tepples - Sun Feb 19, 2006 3:58 pm

HyperHacker wrote:
No, but I've found it occasionally freezes even if the cart isn't being accessed. Can't say why for sure.

Depends on the interrupt mask. If you have the interrupt controller set to throw an interrupt when the Game Pak is ejected, but you don't have an interrupt handler installed that acknowledges the interrupt, you might get problems.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.