Homebrew How about running GBA games in DS mode, instead of emulating?

[McHaggis]

The release of Devolution for Wii got me thinking about this. Currently, playing GBA dumps on the DS requires a DSTwo card for emulation. But we already know that the DS can play GBA games natively using its secondary, ARM7 processor. So, my theory is that DS homebrew could run a GBA game natively on the second processor.

I asked tueidj about how Devolution works and if it's difficult to do. He responded with;

It's not difficult if you're a PowerPC expert, have substantial knowledge of how an operating system kernel works and the system you're emulating (gamecube) has a lot less memory available than the host system (wii). I don't know anyone who would be up to it since I've never worked on anything DS related.

I'm none of those things (nor an ARM expert, which would be a requirement with the DS/GBA), unfortunately, but I do know that the GBA had only 256KB RAM vs the DS's 4MB (less than 7%). If it could be done, various benefits could be possible, such as:

• Link via WiFi (perhaps even link to Devolution for GC games that support it, if tueidj was interested in collaborating) and the Internet.
• Using the DS's sleep mode
• Return GBA support to DSi/3DS with any homebrew supporting card.
• Cheats, RTS, etc.

Are there any experts around here that think this would be possible, or know anyone who might be able to do it?

 

[BlueStar]

As far as I'm aware if you're in DS mode you don't have any access to the GBA hardware. Do the 3DS and DSi even have the GBA innards in them?

 

[McHaggis]

As far as I'm aware if you're in DS mode you don't have any access to the GBA hardware. Do the 3DS and DSi even have the GBA innards in them?

The DS has two processors, an ARM9 and an ARM7, available to all DS software (so is the GBA slot). The GBA only has an ARM7, which is slower than the DS's ARM7. Other than that there is no GBA hardware, you're probably confusing the fact that GBA mode doesn't have access to DS-specific hardware like WiFi.

 

[BlueStar]

What would you be running the games off? Wasn't one of the other main problems the fact that the DS slot speed was too slow to transfer game data compared to the GBA one?

 

[McHaggis]

What would you be running the games off? Wasn't one of the other main problems the fact that the DS slot speed was too slow to transfer game data compared to the GBA one?

The idea would be that the ROMs are stored on your microSD alongside DS roms. Transfer speed could be a potential issue, though I'm unable to find any information verifying your claim.

 

[WiiUBricker]

Actually, that's not a bad idea. Running GBA games in DS mode with full hardware access. You have to write something similar to Devolution but as tueidj said, you have to be a PPC expert and the DS isn't a PPC machine. No idea if Devolution would have been possible on a pure ARM machine.

 

[RodrigoDavy]

Actually, that's not a bad idea. Running GBA games in DS mode with full hardware access. You have to write something similar to Devolution but as tueidj said, you have to be a PPC expert and the DS isn't a PPC machine. No idea if Devolution would have been possible on a pure ARM machine.

He just gave the PPC architecture as an example as it is the Wii/Gamecube architecture, which he is working on. In the case of the DS/gba it is even easier because they share the same processor and the DS has an extra one to help, the DS has pratically a more powerful gba inside it. In the case of the dsi, it is just sleeping and waiting to be awaked by the prince charming which is our ARM expert xD

EDIT
Hopefully, depending on how the 3DS backward compatibility works, even 3ds owners could benefit from that, just being optimistic

 

[Arya511]

this can be like the old CHICKhen for psp. (only works for ds and ds lite)

you need to put a (any) original cartridge. and load any rom from a homebrew emulator.

that would be good

---

 

[McHaggis]

Actually, that's not a bad idea. Running GBA games in DS mode with full hardware access. You have to write something similar to Devolution but as tueidj said, you have to be a PPC expert and the DS isn't a PPC machine. No idea if Devolution would have been possible on a pure ARM machine.

He just gave the PPC architecture as an example as it is the Wii/Gamecube architecture, which he is working on. In the case of the DS/gba it is even easier because they share the same processor and the DS has an extra one to help, the DS has pratically a more powerful gba inside it. In the case of the dsi, it is just sleeping and waiting to be awaked by the prince charming which is our ARM expert xD

EDIT
Hopefully, depending on how the 3DS backward compatibility works, even 3ds owners could benefit from that, just being optimistic

My guess is that's how the GBA VC games work anyway, since they don't seem to run in 3DS mode (they don't support sleep mode, home screen, or a 3D screen at original resolution).

 

[SifJar]

I thought of this a while ago, i think it has great potential. Transfer speeds could potentially be an issue.

 

[DiscostewSM]

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well. This is different from the DS because the DS must load the executable code from ROM into RAM, and execute that code from there. It cannot execute code directly from the card, as the card is not like a cartridge. A cartridge is literally an extension to the system's memory, can be accessed as if it were memory, and has speed within reasonable limits that memory would have. DS cards have none of these. The code itself on the GBA can be anywhere and fragmented into however many parts within the limit of the 32MB ROM area. The code itself can even take up the entire 32MB if it were designed that way.

 

[SifJar]

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well. This is different from the DS because the DS must load the executable code from ROM into RAM, and execute that code from there. It cannot execute code directly from the card, as the card is not like a cartridge. A cartridge is literally an extension to the system's memory, can be accessed as if it were memory, and has speed within reasonable limits that memory would have. DS cards have none of these. The code itself on the GBA can be anywhere and fragmented into however many parts within the limit of the 32MB ROM area. The code itself can even take up the entire 32MB if it were designed that way.

ROMs could be defragmented prior to putting them on the flash card which would eliminate that part of the issue, and with the extra CPU speed available, I would imagine it would be possible to stream the parts of the ROM likely to be needed soon into RAM so they're quickly accessible when necessary (e.g. load the current function and any that it calls into RAM or something). Of course, that would be quite a lot of work, but in theory, I reckon it is possible. (Then again, I don't know a whole heap about the topic).

 

[RchUncleSkeleton]

I know this doesn't apply to the DSi or 3DS but why would you want to do this when you can just use a slot 2 device on the DS Lite or Phat? It's also possible to run GBA on PC, Wii, PSP and much more through standard emulation.

 

[Rydian]

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well. This is different from the DS because the DS must load the executable code from ROM into RAM, and execute that code from there. It cannot execute code directly from the card, as the card is not like a cartridge. A cartridge is literally an extension to the system's memory, can be accessed as if it were memory, and has speed within reasonable limits that memory would have. DS cards have none of these. The code itself on the GBA can be anywhere and fragmented into however many parts within the limit of the 32MB ROM area. The code itself can even take up the entire 32MB if it were designed that way.

Well this explains why 32MB is the hard ROM limit, at least.

EDIT: Fixed wording.

 

[SifJar]

I know this doesn't apply to the DSi or 3DS but why would you want to do this when you can just use a slot 2 device on the DS Lite or Phat? It's also possible to run GBA on PC, Wii, PSP and much more through standard emulation.

Try buying a slot 2 device these days. It's not exactly easy.

 

[Darkrai]

I know this doesn't apply to the DSi or 3DS but why would you want to do this when you can just use a slot 2 device on the DS Lite or Phat? It's also possible to run GBA on PC, Wii, PSP and much more through standard emulation.

Doing this would bring more knowledge about the DS hardware. I think even if you have other ways to emulate GBA, it would be interesting to the community and can help in any way with the 3DS in future...

 

[ferofax]

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well.-snip-

So in essence, a GBA cart is like a RAM stick, except preloaded with games?

That's actually pretty cool.

 

[DiscostewSM]

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well. This is different from the DS because the DS must load the executable code from ROM into RAM, and execute that code from there. It cannot execute code directly from the card, as the card is not like a cartridge. A cartridge is literally an extension to the system's memory, can be accessed as if it were memory, and has speed within reasonable limits that memory would have. DS cards have none of these. The code itself on the GBA can be anywhere and fragmented into however many parts within the limit of the 32MB ROM area. The code itself can even take up the entire 32MB if it were designed that way.

ROMs could be defragmented prior to putting them on the flash card which would eliminate that part of the issue, and with the extra CPU speed available, I would imagine it would be possible to stream the parts of the ROM likely to be needed soon into RAM so they're quickly accessible when necessary (e.g. load the current function and any that it calls into RAM or something). Of course, that would be quite a lot of work, but in theory, I reckon it is possible. (Then again, I don't know a whole heap about the topic).

Defragmenting would require knowing where all the code is. Unlike a filesystem, there is no telling what is code and what is data. They are both mixed together like letters in alphabet soup. An 'A' in this soup may be part of code, or data, or even both. The only way to know what is code and what is data in ROM involves beginning at the entrance address, and then running through the code as you get to them, jumping to different sections based on what the code says. Much of the code requires player input and specific states in game logic to even get into them, making it impossible for a program to get to every part to set up this defragmentation process.

CPU speed has no influence on the speed of which data gets read off the card. Plus, the DS cards work in burst mode, which contain a delay before transferring a section of data. Because code jumps around all the time, you would have these delays all over the place. Just like code is all over the place, so is data, which is also accessed like memory. Some are chunks of related data that can be copied at once, somewhat nullifying the delay attached to reading from ROM on DS cards. But, a lot of data comes as single values, and have no relevance to the surrounding data. Delays would be astronomical because of having to read these variables one at a time because that is what the code says.

Changing the code to make it do what it does already but in a different way is basically emulation.

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well.-snip-

So in essence, a GBA cart is like a RAM stick, except preloaded with games?

That's actually pretty cool.

That's basically the gist of it.

Edit: GIST, not JEST

 

[McHaggis]

Sorry to be the bringer of bad news, but even with the DS mode having access to the GBA hardware, the problem involves access to the ROM, and it isn't just speed. The GBA doesn't just read data from the cartridges. It executes code directly from the cartridges as well. This is different from the DS because the DS must load the executable code from ROM into RAM, and execute that code from there. It cannot execute code directly from the card, as the card is not like a cartridge. A cartridge is literally an extension to the system's memory, can be accessed as if it were memory, and has speed within reasonable limits that memory would have. DS cards have none of these. The code itself on the GBA can be anywhere and fragmented into however many parts within the limit of the 32MB ROM area. The code itself can even take up the entire 32MB if it were designed that way.

Yeah, this was something that occurred to me when @BlueStar mentioned the speed issue. I remembered that GBA carts (and GB, GBC, SNES, and NES carts) extend the memory with the contents of the cart. Like SifJar said, it might be possible to work around it by streaming the most important parts into memory, but I imagine that would be much more difficult and possibly break compatibility. I guess that makes it more likely that it's only doable on the 3DS (which has 128MB, more than enough to load an entire ROM into memory and patch it on the fly).

I know this doesn't apply to the DSi or 3DS but why would you want to do this when you can just use a slot 2 device on the DS Lite or Phat? It's also possible to run GBA on PC, Wii, PSP and much more through standard emulation.

Try buying a slot 2 device these days. It's not exactly easy.

Not only that, but it pretty much rules out almost all the other features I thought would be available like WiFi linking and automatic sleep mode. Also, I was thinking this would be more valuable for my 3DS than my DS. I have a slot-2 device knocking about somewhere, but it doesn't fit in my DS Lite properly to leave it in all the time .

 

[RodrigoDavy]

In the case of the DS phat and lite, I remember the slot-2 devices were only necessary because they had extra RAM necessary for the gba games. The actual gba game was stored in the sd card on slot-1, which was copied to RAM solving the speed problems. Nowadays RAM chips are pretty small and inexpensive and the Supercard team have an entire processor in the SCDS2 isn't it possible to find or make a slot-1 flashcard with 32MB of RAM?