Hacking GBA Cart Adapter

[Archerg]

Hi there, I know this has been asked, but I just wanted to ask if this is even hypothetically feasible, whether or not if it's been made or programmed, which as of now it has not.

As I understand it, the GBA couldn't be used on a DS slot 1 because the DS had much slower transfer speeds since the GBA is basically a memory extension. The dsi could not run GBA games because despite it having GBA hardware, the ram was too small to store the rom in its entirety and still run system resources.

For the 3ds, I can't find any documentation on the cartridge read speeds other than 150ns, so fairly fast. With the advancement of open_agb_firm, we get loading games into ram directly from a location (sd card) without layers of VC injects. Wouldn't this mean it's possible to modify the source and destination including where it saves to?

Lastly, the pinouts should be similar. 3ds and GBA carts have ground, clock, vcc, and all 7 data pins. I'm a bit lost on the address pins, but if necessary someone could include a cpld chip to access the data/address combo pins. Or if we can just dump the entire rom and saves into the 3ds ram and read/write back to it, it would make reading from it constantly moot, wouldn't it?

I don't have much concrete knowledge of the process, if any. If it's been attempted is another topic or even worth it since it can just be loaded digitally. But with all this and for those who want to play three generations of physical media on one device, is it possible in theory?

 

[SylverReZ]

You will need to use some form of FPGA and a ton of reverse engineering to make this possible.

 

[Archerg]

You will need to use some form of FPGA and a ton of reverse engineering to make this possible.

Good point. I was doing some more thinking about it, and realized that someone would have to make a chip in between the GBA and the card slot to do a mirage of things. You could have it translate the rom into a readable file in the same way you can read .app files within godmode9s file management system, or how the joey jr lets you view files on windows as simple .GBA and .sav files. Or a mask .3ds file with special private headers to show up on the screen with a basic banner to either boot open_agb_firm or a modified agb_firm. And that's not even touching coding, translating, and transferring data back and forth between the GBA and the system. A bit more than drag and drop, eh? But if someone ever decided to take the time, it might just be possible.

 

[Jokey_Carrot]

You can dump GBA games using a DS and an R4 card if you want some clean legal ROMs.

 

[Archerg]

You can dump GBA games using a DS and an R4 card if you want some clean legal ROMs.

That's quite true, although I think you might be missing the intention of this thread.

I think I might be overthinking it. Rather than have the system read the pins directly from the cartridge, or a quasi-custom card slot rom interface, it could just be simple.

If only there was a software on a chip that could be made to make the rom and save appear as files in the 3ds, then open_agb_firm could just read and write the save back to it. If you wanted to take it a step further, you could just crate a forwarder to a version of OAF that just auto loads the file in there, and easy peasy.

 

[sirocyl]

The theory is sound, it would just need some light electronics, hardware/PCB manufacture, and software engineering.

Hardware needs:
- SPI USB 1.0/2.0 FS/HS host controller interface IC.
- Any USB GBA cartridge dumper.
- A new homebrew SLOT-1 board, with SPI chip select gated properly with CS_SPI pin, and connected to SPI USB host controller.

Alternatively, if you have an open-source GBA cartridge dumper which can talk natively over SPI, you can short-circuit the need for an SPI USB HCI chip.

Software needs:
- A USB HCI driver for the SPI chip, to be included into open_agb_firm
- A driver for the GBA cartridge dumper, also to include in OAF (replacing fatfs)
- A modification of open_agb_firm to read its ROM and save data from the connected USB device.

No FPGA needed, and the implementation is very simple.

Also, if there's any open-source NTRCARD/NTRBOOT/NTRCARDHAX tools/chips out there (e.g., firmware for a microcontroller to emulate the DS card protocol, or gateware for a CPLD/small FPGA), it could be possible to have this version of OAF as an NTRBOOT payload, and run on stock 3DS consoles, as the card signals and SPI are multiplexed with a simple CS gate.

You could possibly also modify an existing NTRBOOT flashcard for this purpose, but they are getting harder to find, and they're not open-source.

 

[Jayro]

Are you trying to add a GBA Cart slot to a DSI? Is that what I'm reading from the first post?

 

[master801]

The theory is sound, it would just need some light electronics, hardware/PCB manufacture, and software engineering.

Hardware needs:
- SPI USB 1.0/2.0 FS/HS host controller interface IC.
- Any USB GBA cartridge dumper.
- A new homebrew SLOT-1 board, with SPI chip select gated properly with CS_SPI pin, and connected to SPI USB host controller.

Alternatively, if you have an open-source GBA cartridge dumper which can talk natively over SPI, you can short-circuit the need for an SPI USB HCI chip.

Software needs:
- A USB HCI driver for the SPI chip, to be included into open_agb_firm
- A driver for the GBA cartridge dumper, also to include in OAF (replacing fatfs)
- A modification of open_agb_firm to read its ROM and save data from the connected USB device.

No FPGA needed, and the implementation is very simple.

Also, if there's any open-source NTRCARD/NTRBOOT/NTRCARDHAX tools/chips out there (e.g., firmware for a microcontroller to emulate the DS card protocol, or gateware for a CPLD/small FPGA), it could be possible to have this version of OAF as an NTRBOOT payload, and run on stock 3DS consoles, as the card signals and SPI are multiplexed with a simple CS gate.

You could possibly also modify an existing NTRBOOT flashcard for this purpose, but they are getting harder to find, and they're not open-source.

What? Why would you want to over complicate something like this with USB, of all things.

Serial to USB and then back to serial is not a good idea.

 

[sirocyl]

What? Why would you want to over complicate something like this with USB, of all things. Serial to USB and then back to serial is not a good idea.

GBA cartridges aren't serial, and GBA dumpers on the market today are USB. If there is a serial GBA cartridge dumper out there, by all means - use that. I even mention this in the post.