#121248 - Danno22 - Sat Mar 10, 2007 8:03 pm
as r4ds runs off slot1 i understand that it cant run .gba files.
But is there a solution (i.e. an emulator) to run .gba roms through r4ds?
Danno
#121258 - tepples - Sat Mar 10, 2007 8:55 pm
Which GBA homebrew games do you want to run? If they're my works (see list), I could look into porting them to DS. If they're someone else's, ask the author to port them. If they're free software, and you know how to code, try your hand at porting them yourself.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#121599 - Oliv5400 - Tue Mar 13, 2007 10:43 am
Hi !,
I have 2 big noobs question about that :
1-Why when the DS boot in GBA Mode (Slot2) we CAN launch ds stuff with a loader (ds.gba) and when the DS boot in NDS Mode (Slot1) we CAN'T launch GBA stuff ? ( no gba.ds.. )
2-Why the linker must have RAM to run GBA stuff ? the DS stuff don't need it, maybe all the GBA card have RAM onboard ? in this case why don't use it with our old GBA game for extra memory ?
Thanks !
#121601 - Diddl - Tue Mar 13, 2007 11:14 am
it depends on the structure of a program.
gba programs can be executed directly from rom, cause cartridge memory is directly addressable.
NDS cartridge is not directly addressable. you only can read the program into internal ram and execute (like a PC does). big programs have to be loaded partially and executed partially. so program for NDS have to be designed for this way of execution.
Ez Flash V goes it own way with a combination of slot 1 and slot2 cartridge. all gba games and nds games lies on a TF card in slot 1. if you want to execute a gba game, it loads into slot 2 cartridge and executes it.
#121603 - Oliv5400 - Tue Mar 13, 2007 12:44 pm
Ok, i understand.
So make a virtual memory management ( with forwarding acces ) between slot2 to internal RAM + Slot1 ( like NDS works ) can solve this.
Using a main NDS exec to cache reading the GBA ARM7 opcode and redirect it on the fly with the new I/O acces could do the trick.
Someone test it ? or this solution is too slow ?
I find this very interesting.
#121607 - Diddl - Tue Mar 13, 2007 2:23 pm
for virtual memory management you need other CPU. ARM doesn't support exceptions and such thing nessecary for VMM.
the only simple way is to have enough RAM to load all cartridge data in it. any slot2 ram extension will do it (browser ext. , supercard, m3, ez trimode ...).
the best way is a configurable memory extension like any slot 2 solution can do (ez flash4). only ram could be overwritten.
###
another problem would be save game management. only to execute a gba application isn't enough. but why do anything for gba stuff? there are enough slot 2 solutions which works perfect!!
#121610 - simonjhall - Tue Mar 13, 2007 2:50 pm
| Oliv5400 wrote: |
| Someone test it ? or this solution is too slow ? |
Yeah, I had a go with this. I set up an exception handler to catch accesses to the non-existent gba ROM space and then read the actual data from disk and patched in the result back into the running program. It ran completely transparently, but was pretty slow. I think I managed about ~100k a second...
I think Mighty Max had a better solution for this using the memory mirror system and cached data. Can't remember the details...
Either solution would allow you to emulate the gba rom space.
For proper memory-mapping support an MMU is required - neither DS CPU has one.
_________________
Big thanks to everyone who donated for Quake2
#121630 - tepples - Tue Mar 13, 2007 4:17 pm
| Diddl wrote: |
| but why do anything for gba stuff? there are enough slot 2 solutions which works perfect!! |
What happens when almost all homebrew effort has moved to the DS and demand for GBA flash equipment has dropped so low that mass production of SLOT-2 cards is no longer viable? I got into GBA homebrew in December [Error], six months after the GBA came out in North America, and this had already happened to GBC flash equipment.
CORRECTION: dec 2001.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
Last edited by tepples on Tue Mar 13, 2007 5:45 pm; edited 1 time in total
#121634 - kusma - Tue Mar 13, 2007 5:13 pm
| tepples wrote: |
| I got into GBA homebrew in December [Error], six months after the GBA came out in North America, and this had already happened to GBC flash equipment. |
Uh?
#121638 - Lazy1 - Tue Mar 13, 2007 5:42 pm
| tepples wrote: |
| Diddl wrote: | | but why do anything for gba stuff? there are enough slot 2 solutions which works perfect!! |
What happens when almost all homebrew effort has moved to the DS and demand for GBA flash equipment has dropped so low that mass production of SLOT-2 cards is no longer viable? I got into GBA homebrew in December [Error], six months after the GBA came out in North America, and this had already happened to GBC flash equipment. |
I think that as more applications start to use external ram on gba carts they will always be readily available.
However, as far as I know only 3 applications so far make use of it (DSLinux, Moonshell and Mini vMac DS).
As for GBA applications running from slot-1, wasn't someone working on getting those to run in DS mode?
#121639 - tepples - Tue Mar 13, 2007 5:44 pm
Sorry. I meant December 2001.
GBA release - June 2001
I discover GBA homebrew - December 2001
I discover no GBC carts are available - December 2001
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#121650 - Oliv5400 - Tue Mar 13, 2007 6:38 pm
| Quote: |
| why do anything for gba stuff? there are enough slot 2 solutions which works perfect!! |
Why not ? we are on GBADev afterall ;o).. this can be very usefull and don't forget : GBA never die !
| Quote: |
| It ran completely transparently, but was pretty slow |
Did you try it in full asm ?
| Quote: |
| I think Mighty Max had a better solution for this using the memory mirror system and cached data. Can't remember the details... |
Yes dynamic "rom to ram" caching with predictive area memory acces like a CPU pipeline.
#121698 - simonjhall - Wed Mar 14, 2007 1:17 am
Yeah, I'm sure you could predict where data's gonna be read from then pull that data from the disk. However, if it's an emulator you don't need any of these fancy exception-based schemes! Fixing up memory is like, part of the emulator... :-)
Anyway, coding it in assembler wouldn't have made too much difference, although I would have done so if required. The problem was the overhead of the actual exception-handling process, which wasn't in my control as I'm 95% sure that that task is split between the CPU and BIOS code. From doing an invalid read/write to actually entering my code hundreds (thousands?) of cycles had elapsed!
Even if I had done some kind of caching thing you'd still have to handle this overhead on every invalid memory access.
Max got around this by using the mirroring mechanism so that (if I remember correctly) on first access to an invalid page it would pull in the whole page and then the original program would use the mirror (which has no overhead). I don't think this would work too well if the program wasn't aware of it though...
I got bored of this virtual memory hoo-ha and now a bunch of kind people bought and donated me slot-2 hardware which has extra RAM :-)
_________________
Big thanks to everyone who donated for Quake2