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

Fudge

Remember that death is not the end, but only a tra
Banned
Joined
Aug 26, 2009
Messages
2,653
Trophies
0
Age
27
Location
New York
Website
Visit site
XP
687
Country
United States
Since GBA games are streamed directly from the cartridge and could take up a maximum of 32MB of RAM, wouldn't it be in theory be possible to use a cart with extra RAM like the DSTWO or similar to store the game and stream data to the DS's ram and use the ARM 7 processor? Please tell me if I'm talking out of my ass :D
 

RchUncleSkeleton

Skeletron 9000
Member
Joined
Feb 2, 2009
Messages
1,136
Trophies
1
Age
39
Location
California, USA
Website
www.youtube.com
XP
359
Country
United States
Try buying a slot 2 device these days. It's not exactly easy.
A simple search on Google and shoptemp would suggest otherwise.
http://www.realhotstuff.hk/EZ-Flash-3-in-1-Expansion-Pack_p_15.html
http://www.tradeinthebox.com/ez-flash-3-in-1-expansion-pack-rumblegbaram-expansion_p306.html
http://www.nds-card.com/ProShow.asp?ProID=153
http://www.eachgame.me/goods-615.html
http://shop.01media.com/info.asp?ProductID=38418
 
  • Like
Reactions: 1 person

AceWarhead

"Must Construct Additional Pylons"
Member
Joined
Apr 9, 2011
Messages
1,277
Trophies
0
XP
601
Country
United States

RchUncleSkeleton

Skeletron 9000
Member
Joined
Feb 2, 2009
Messages
1,136
Trophies
1
Age
39
Location
California, USA
Website
www.youtube.com
XP
359
Country
United States
They all require a SLOT-1 card to run off of.
uhhhhh, yeah obviously. Most slot 2 devices require a slot 1 device to run, that's why it's called a slot 2 device and not a GBA flash card. Now if you're speaking of the latter, you would be hard pressed to find one unless you're in the used market. However, according to this http://www.realhotstuff.hk/EZ-Flash-IV-Flashcard_p_76.html you can still find the ez flash IV readily available and that does not require a slot 1 card as it is a GBA flash card.
 
  • Like
Reactions: 2 people

SifJar

Not a pirate
Member
Joined
Apr 4, 2009
Messages
6,022
Trophies
0
Website
Visit site
XP
1,175
Country
I meant actual slot 2 devices, not expansion packs. Of course, those will do the job just fine, but I just mean that actual GBA flash cards are hard to find now. (I have tried to find Supercards etc. before, and failed)
 

Rydian

Resident Furvert™
Member
Joined
Feb 4, 2010
Messages
27,880
Trophies
0
Age
36
Location
Cave Entrance, Watching Cyan Write Letters
Website
rydian.net
XP
9,111
Country
United States
uhhhhh, yeah obviously. Most slot 2 devices require a slot 1 device to run, that's why it's called a slot 2 device and not a GBA flash card.
Slot2 was called slot2 before all else ._. ...A GBA flashcard IS a slot2, a slot2 cart does not have to be a GBA flashcard.
Why the hell would you call the only slot on a device the second slot? :P
 

RchUncleSkeleton

Skeletron 9000
Member
Joined
Feb 2, 2009
Messages
1,136
Trophies
1
Age
39
Location
California, USA
Website
www.youtube.com
XP
359
Country
United States
uhhhhh, yeah obviously. Most slot 2 devices require a slot 1 device to run, that's why it's called a slot 2 device and not a GBA flash card.
Slot2 was called slot2 before all else ._. ...A GBA flashcard IS a slot2, a slot2 cart does not have to be a GBA flashcard.
Why the hell would you call the only slot on a device the second slot? :P
Thank you Rydian! My thoughts exactly, when GBA flashcards were introduced it was for the GBA which only had ONE slot...a "Slot 2" device would be classified as a rumble pack or an expansion card for use in slot 2 on the NDS.
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,403
Country
United Kingdom
Thought exercise then, I would maintain a practical use of it would probably not arise

The true emulation is that of the transistors upwards which has been done and that would be painfully slow even on a modern PC I figure. However the DS has an ARM9 which is functionally identical to an ARM7 (albeit slightly faster and with a few extra instructions) which you can see about http://imrannazar.com/ARM-Opcode-Map and http://nocash.emubase.de/gbatek.htm#cpuoverview meaning you can go in for the lesser, but still very effective, type of emulation of just translating instructions and maybe modelling a few things that do not exist. This carries on a fair bit and in many ways I would call the DS a beefed up GBA with fewer restrictions: some of the quirks of DMA on the GBA do not really exist on the DS among other things.
The DS one is higher clocked but clock alone does not play the greatest role as you also have vblank and hblank to contend with may make things easier or may make them harder- many functions are tied to vblank interrupts so having a game run too fast might not be the biggest problem but unlike PCs and to a lesser extent the consoles they can effectively rely on a single relatively stable clock. Race conditions... purely by virtue of C probably being the language of choice (it was available and quite viable but I have yet to fully confirm it across many games) and the compilers not being terribly odd as far as doing crazy compiler things race conditions are probably not that big an issue but I do want to note it being a potential one.

The cart itself- others mentioned the GBA cart is mapped to memory (08000000-09FFFFFF with mirrors of variable priority at 0A000000 and 0C000000) where the DS one is not mapped at all although the 08 mirror is still available in DS mode. For my money this is the hardest problem to solve and this is big and why supercards on the GBA were less than stellar even after speedpatches which nothing else this side of the switch from the GBC needed.

The BIOS functions- several have different mappings and if you prefer some of the GBA ones are now available as extra features on the DS hardware. The audio stuff might be troublesome though.

I have probably said as such in the past but I reckon a combination of application specific emulation (been seen at various points in the past) and either a static reinterpreter (automated or hand guided I have not decided upon) or maybe a dynamic one might be able to be used to allow a few games coded without relying too deeply on the specifics of the hardware. Personally I would not put the effort in and instead spend the time designing a proper GBA flash cart- the GBA and DS count as embedded hardware in my book and with some of the fairly easy to use programmable chips and/or NOR or RAM interfaces I doubt those capable of doing any damage here would have a hard time putting a halfway functional GBA cart together at least*. Likewise if people are already making clone GBA type devices I would look there for some would be hardware (clone NES devices have long existed and many of the others are looking like they might have something at some point in the not too distant future if they have not already got something halfway there).

*NES mappers, SNES special chips and GBC bankswitching make life a slight bit more difficult but the GBA was pretty much easy street. Sure trying to get a full soft reset, cheat engine, fancy UI and more working would be harder.

This is turning into a repeat of conversations I have had on IRC on the matter so much like there I will say if someone does well on one of these then they will get a drink out of me should we meet but I hold out no hope of it going terribly far/place hope of being able to do it all on the cheap as it were. Purely as a "is it worth the time as far as creating a functional piece of code?" then no as it is available with not a lot of effort on hardware and emulation on other readily available handhelds and there are still emulators, ports, hacks and remakes of things that could do with some work (the DS emulation of the PCE/TG16 is next to non-existent and there were several notable games there). It was probably already clear but if doing it for intellectual curiosity or something similar then carry on as I am sure it would be fascinating and cause you to learn a lot.
 
  • Like
Reactions: 1 person

Beldr

Well-Known Member
Newcomer
Joined
Aug 1, 2012
Messages
69
Trophies
0
Age
28
Location
The HELL
Website
www.darkcookies.com
XP
47
Country

C-Kronos

Well-Known Member
Member
Joined
Mar 11, 2010
Messages
260
Trophies
0
XP
142
Country
United States
Thought exercise then, I would maintain a practical use of it would probably not arise

The true emulation is that of the transistors upwards which has been done and that would be painfully slow even on a modern PC I figure. However the DS has an ARM9 which is functionally identical to an ARM7 (albeit slightly faster and with a few extra instructions) which you can see about http://imrannazar.com/ARM-Opcode-Map and http://nocash.emubas...htm#cpuoverview meaning you can go in for the lesser, but still very effective, type of emulation of just translating instructions and maybe modelling a few things that do not exist. This carries on a fair bit and in many ways I would call the DS a beefed up GBA with fewer restrictions: some of the quirks of DMA on the GBA do not really exist on the DS among other things.
The DS one is higher clocked but clock alone does not play the greatest role as you also have vblank and hblank to contend with may make things easier or may make them harder- many functions are tied to vblank interrupts so having a game run too fast might not be the biggest problem but unlike PCs and to a lesser extent the consoles they can effectively rely on a single relatively stable clock. Race conditions... purely by virtue of C probably being the language of choice (it was available and quite viable but I have yet to fully confirm it across many games) and the compilers not being terribly odd as far as doing crazy compiler things race conditions are probably not that big an issue but I do want to note it being a potential one.

The cart itself- others mentioned the GBA cart is mapped to memory (08000000-09FFFFFF with mirrors of variable priority at 0A000000 and 0C000000) where the DS one is not mapped at all although the 08 mirror is still available in DS mode. For my money this is the hardest problem to solve and this is big and why supercards on the GBA were less than stellar even after speedpatches which nothing else this side of the switch from the GBC needed.

The BIOS functions- several have different mappings and if you prefer some of the GBA ones are now available as extra features on the DS hardware. The audio stuff might be troublesome though.

I have probably said as such in the past but I reckon a combination of application specific emulation (been seen at various points in the past) and either a static reinterpreter (automated or hand guided I have not decided upon) or maybe a dynamic one might be able to be used to allow a few games coded without relying too deeply on the specifics of the hardware. Personally I would not put the effort in and instead spend the time designing a proper GBA flash cart- the GBA and DS count as embedded hardware in my book and with some of the fairly easy to use programmable chips and/or NOR or RAM interfaces I doubt those capable of doing any damage here would have a hard time putting a halfway functional GBA cart together at least*. Likewise if people are already making clone GBA type devices I would look there for some would be hardware (clone NES devices have long existed and many of the others are looking like they might have something at some point in the not too distant future if they have not already got something halfway there).

*NES mappers, SNES special chips and GBC bankswitching make life a slight bit more difficult but the GBA was pretty much easy street. Sure trying to get a full soft reset, cheat engine, fancy UI and more working would be harder.

This is turning into a repeat of conversations I have had on IRC on the matter so much like there I will say if someone does well on one of these then they will get a drink out of me should we meet but I hold out no hope of it going terribly far/place hope of being able to do it all on the cheap as it were. Purely as a "is it worth the time as far as creating a functional piece of code?" then no as it is available with not a lot of effort on hardware and emulation on other readily available handhelds and there are still emulators, ports, hacks and remakes of things that could do with some work (the DS emulation of the PCE/TG16 is next to non-existent and there were several notable games there). It was probably already clear but if doing it for intellectual curiosity or something similar then carry on as I am sure it would be fascinating and cause you to learn a lot.

Had a good laugh at his comment about javascript >.>

EDIT: In reference to the MOS 6502 video.
 

McHaggis

Fackin' Troller
OP
Member
Joined
Oct 24, 2008
Messages
1,749
Trophies
0
XP
1,466
Country
Thought exercise then, I would maintain a practical use of it would probably not arise

The true emulation is that of the transistors upwards which has been done and that would be painfully slow even on a modern PC I figure. However the DS has an ARM9 which is functionally identical to an ARM7 (albeit slightly faster and with a few extra instructions) which you can see about http://imrannazar.com/ARM-Opcode-Map and http://nocash.emubas...htm#cpuoverview meaning you can go in for the lesser, but still very effective, type of emulation of just translating instructions and maybe modelling a few things that do not exist. This carries on a fair bit and in many ways I would call the DS a beefed up GBA with fewer restrictions: some of the quirks of DMA on the GBA do not really exist on the DS among other things.
The DS one is higher clocked but clock alone does not play the greatest role as you also have vblank and hblank to contend with may make things easier or may make them harder- many functions are tied to vblank interrupts so having a game run too fast might not be the biggest problem but unlike PCs and to a lesser extent the consoles they can effectively rely on a single relatively stable clock. Race conditions... purely by virtue of C probably being the language of choice (it was available and quite viable but I have yet to fully confirm it across many games) and the compilers not being terribly odd as far as doing crazy compiler things race conditions are probably not that big an issue but I do want to note it being a potential one.

The cart itself- others mentioned the GBA cart is mapped to memory (08000000-09FFFFFF with mirrors of variable priority at 0A000000 and 0C000000) where the DS one is not mapped at all although the 08 mirror is still available in DS mode. For my money this is the hardest problem to solve and this is big and why supercards on the GBA were less than stellar even after speedpatches which nothing else this side of the switch from the GBC needed.

The BIOS functions- several have different mappings and if you prefer some of the GBA ones are now available as extra features on the DS hardware. The audio stuff might be troublesome though.

I have probably said as such in the past but I reckon a combination of application specific emulation (been seen at various points in the past) and either a static reinterpreter (automated or hand guided I have not decided upon) or maybe a dynamic one might be able to be used to allow a few games coded without relying too deeply on the specifics of the hardware. Personally I would not put the effort in and instead spend the time designing a proper GBA flash cart- the GBA and DS count as embedded hardware in my book and with some of the fairly easy to use programmable chips and/or NOR or RAM interfaces I doubt those capable of doing any damage here would have a hard time putting a halfway functional GBA cart together at least*. Likewise if people are already making clone GBA type devices I would look there for some would be hardware (clone NES devices have long existed and many of the others are looking like they might have something at some point in the not too distant future if they have not already got something halfway there).

*NES mappers, SNES special chips and GBC bankswitching make life a slight bit more difficult but the GBA was pretty much easy street. Sure trying to get a full soft reset, cheat engine, fancy UI and more working would be harder.

This is turning into a repeat of conversations I have had on IRC on the matter so much like there I will say if someone does well on one of these then they will get a drink out of me should we meet but I hold out no hope of it going terribly far/place hope of being able to do it all on the cheap as it were. Purely as a "is it worth the time as far as creating a functional piece of code?" then no as it is available with not a lot of effort on hardware and emulation on other readily available handhelds and there are still emulators, ports, hacks and remakes of things that could do with some work (the DS emulation of the PCE/TG16 is next to non-existent and there were several notable games there). It was probably already clear but if doing it for intellectual curiosity or something similar then carry on as I am sure it would be fascinating and cause you to learn a lot.
Ouch, my brain!
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    Bunjolio @ Bunjolio: