#128278 - goruka - Thu May 10, 2007 7:42 am
Hi! I own a Slot-1 Flash card, so I naturally can't run GBA Software with it.
But I was thinking and.. Do you people think it may be too hard to write a GBA emulator for it? I had in mind that by using a virtual addres space, i could map the rom into pages.. and a use some sort of LRU mechanism for paging out when a new page is needed.. and then, using CPU exceptions or pagefaults to emulate access to the GBA registers. I'm pretty sure that this method should work pretty well (I dont think that GBA roms access the whole rom all the time during the game).
For those over here more skilled with ARM7/9 than I am, do you think this may be possible and feasible?
Thanks!
#128280 - OOPMan - Thu May 10, 2007 8:07 am
Er.......
Since Slot-1 isn't memory mapped, wouldn't mapping the ROM pages to a virtual address space be painfully slow.
Now, I know that a form of virtual address spacing has been done on the DS by Mighty Max with his Virtual16 proto-type system, so I won't say it isn't possible, but you might want consult him about the feasability of using virtual address space. Given that the DS only has an MPU and not a full MMU, you might have problems...
However, I'm thinking of another issue...
It's well known that GBA binaries do not always perform well even when running from the RAM contained in certain SLOT-2 cards. The question then is how you intend to obtain full speed using a more complex mapping mechanism running of a slower underlying data storage system (Ie. RAM access vs. Flash access)
To be honest, I think it's a stretch...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#128283 - goruka - Thu May 10, 2007 8:26 am
| OOPMan wrote: |
Er.......
Since Slot-1 isn't memory mapped, wouldn't mapping the ROM pages to a virtual address space be painfully slow.
[..]
Given that the DS only has an MPU and not a full MMU, you might have problems...
[..]
The question then is how you intend to obtain full speed using a more complex mapping mechanism running of a slower underlying data storage system (Ie. RAM access vs. Flash access)
To be honest, I think it's a stretch...
|
First, It doesnt need to be memory mapped, you just load pages when needed...
Second, Are you sure that ARM9 doesn't have full MMU? otherwise I dont think Linux would run on it..
Third, you dont seem to be understanding what I mean, which is that, by using virtual addres space, to cache the page accesses to regular DS ram, which is about 4mb ... of course, at some points it will slow down a little (reading the page from flash), but shouldnt be much, and happens only once ,then the page will be cached in the main ram and accessed from there without any kind of delays..
#128286 - PhoenixSoft - Thu May 10, 2007 8:51 am
| goruka wrote: |
| Second, Are you sure that ARM9 doesn't have full MMU? otherwise I dont think Linux would run on it.. |
http://en.wikipedia.org/wiki/DSLinux:
| Quote: |
| DSLinux runs a modified μClinux kernel. It is currently based on μClinux 2.6.14 (Linux-2.6.14-hsc0). |
http://en.wikipedia.org/wiki/μClinux
| Quote: |
| μClinux was a fork of the Linux kernel for microcontrollers without a memory management unit (MMU). |
EDIT: Haha, beat you Pepsiman :p
Last edited by PhoenixSoft on Thu May 10, 2007 8:52 am; edited 1 time in total
#128287 - pepsiman - Thu May 10, 2007 8:52 am
| goruka wrote: |
Second, Are you sure that ARM9 doesn't have full MMU? otherwise I dont think Linux would run on it.. |
DSLinux is based on uClinux. uClinux is for CPUs with no MMU.
#128295 - OOPMan - Thu May 10, 2007 9:35 am
| goruka wrote: |
First, It doesnt need to be memory mapped, you just load pages when needed... |
Somehow I think that might result in painful performance...
| goruka wrote: |
Second, Are you sure that ARM9 doesn't have full MMU? otherwise I dont think Linux would run on it.. |
As others have illustrated, 100% sure. The DS has an MPU, not an MMU. However, it can be used to do certain forms of memory trickery. Mighty Max was able to create 16mb of virtual address space using it, although it was actually just a mirror of the 4mb of physical memory, I think. You might want to do a search for "Building an OS" and read that. There are more details there, along with the source for Max's efforts...
| goruka wrote: |
| Third, you dont seem to be understanding what I mean, which is that, by using virtual addres space, to cache the page accesses to regular DS ram, which is about 4mb ... of course, at some points it will slow down a little (reading the page from flash), but shouldnt be much, and happens only once ,then the page will be cached in the main ram and accessed from there without any kind of delays.. |
Erm...it sounds like you'd be writing a thunking layer of huge proportions. For one, when the DS is running in GBA mode, all the DS-mode HW is not accessable. That means no read/writes from SLOT-1, no ARM9 and so forth.
Which means, for your idea to work, you'd have to write a software layer to sit between the DS and the GBA binary. Said layer would probably end up being a specialised OS of sorts, mapping GBA ROM space to physical data on the SLOT-1 card while virtualizing all the calls to GBA hardware.
A non-virtualized form of the emu would be horribly slow, so your only real hope for full speed would be to go with a virtualization technique. However, whether the DS's hardware is up to this is hard to say. Once again, Mighty Max might know more, try PM'ing him...
So...
Possible? Maybe...
Easy? Unlikely...
However, I myself would be very interested to see if it is indeed possible to perform virtualization on the DS in the fashion describe above, so keep investigating the options...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#128298 - simonjhall - Thu May 10, 2007 10:30 am
I wrote some fancy code a while back which would do as you say - 'page in' sections of data and then use processor exceptions to handle access to this data via a virtual address space. It would do this by pulling in data on demand into a cache (with an lru scheme) and software emulate all the various types of store and load instruction.
But yeah, OOPMan's right - it was horribly slow :-)
The biggest problem was due to the lack of MMU this procedure happened every time a load/store accessed the virtual address space rather than once on the first time. Also due to all the fancy bios/mode switching code this meant that hundreds of cycles would be wasted before my exception handler got called.
So yeah, ~170k/s to 'memory' is too slow for a gba game!
MM had a much more interesting way of doing virtual memory access, but I can't remember too well how this worked.
_________________
Big thanks to everyone who donated for Quake2
#128311 - tepples - Thu May 10, 2007 2:40 pm
| goruka wrote: |
| Hi! I own a Slot-1 Flash card, so I naturally can't run GBA Software with it. |
What you need to get is a GBA flash card that can be written to through SLOT-2. Then you load up your GBA launcher, and it copies the file from your microSD card in SLOT-1 to the NOR flash or RAM in SLOT-2. The old Flash2Advance cards (and I think just about every classic GBA flash card that doesn't have a USB port on it) can do this with appropriate DS-side software, and there's a SLOT-2 expansion card called "EZ-FLASH 3-in-1" designed specifically for this method.
As others have stated, doing this in pure software will be too slow to be usable for the foreseeable future.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128344 - dantheman - Thu May 10, 2007 9:54 pm
As far as I was aware, the only DS-side flashing software was for Flash Advance Pro cards and the new EZ-V expansion pack. I know for instance that you cannot write to a Flash2Advance Ultra cart using DS-side software.
But yeah, if you want GBA compatibility, you'll need to get some homebrew device that fits in slot-2, whether it be a traditional NOR-based flash cart or a CF/SD adapter like the Supercard or M3.
#128349 - Dood77 - Thu May 10, 2007 10:43 pm
| goruka wrote: |
| i could map the rom into pages.. |
This seems like it would involve a ton of custom-tailoring for each individual ROM...
#128360 - Gunnex - Fri May 11, 2007 12:05 am
I'm going to post my famous FAQ:
Why? Well let's refer to an FAQ.
| Quote: |
Q: The DS has GBA hardware! Why can't we?
A: Yeah, but the GBA BIOS are not seen in DS mode, but Slot-2 is still used. Basically, it's a DS taped to a GBA where a screen and a Slot is shared and nothing else.
Q: Will some one make a GBA emulator?
A: The point? A console needs to be at least 4 to 8 times more powerful to emulate another system. DS is only about twice the power of the GBA. No one has the time to make one, and if there was, it would be horribly slow.
Q: Old flash cards can! Why not new ones?
A: Because they have RAM. DS cards use a lower-speed ROM chip, thus it can be easily substituted with Flash Memory like SD cards. GBA game paks use a higher-speed ROM chip, thus flash memory isn't enough. So RAM is used to replace the ROM chip. Thus, only (most) Slot-2 cards can run GBA.
Q: The DS can boot Slot-2 in DS mode! Why not vise versa?
A: Because the DS BIOS can see the GBA Slot, but as an EXPANSION. Thus the 'Rumble Pack' and 'Opera RAM' go in through the GBA slot, but can't be run by the GBA BIOS. The GBA BIOS cannot see the DS Slot as the DS slot is 1) Not connected to GBA BIOS hardwarewise and 2) Not naturally part of GBA hardware, thus the BIOS are not programmed to see it.
Q: Then can we just flash the BIOS chip with something similar to FlashMe?
A: No. The firmware for the DS is on a flash chip. All it does is tell the processors what to do. BIOS are hard-written ROM chips that cannot be 'flashed.' You would have to recreate and install a chip yourself.
Q: Will anyone do this?
A: No. No one has the time as most of the major DS developers have Slot-2 cards.
Q: What can I do to play GBA?
A: cory and some other developers are creating DLDI ready programs for the EZFlash V 3n1 pack. Use that. It's cheap and doesn't need flash memory.
This should clear up some things. |
I have posted this in many places.
#128364 - Darkflame - Fri May 11, 2007 12:56 am
| Quote: |
| DS is only about twice the power of the GBA. |
Purhapes thats slightly unfair.
GBA = 16.8mhz
one cpu on the DS = 66mhz
66/16 = 4.125
One cpu is 4 times, and the ram is vastely more.
(the other cpu is 2 times as powerfull when in ds more)
So I think saying the DS is only twice as powerfull isnt quite doing justice to the system.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#128368 - Lazy1 - Fri May 11, 2007 1:15 am
Isn't the GBA close enough to slightly modify multiboot binaries and run them in DS mode?
#128376 - tepples - Fri May 11, 2007 1:47 am
| dantheman wrote: |
| As far as I was aware, the only DS-side flashing software was for Flash Advance Pro cards and the new EZ-V expansion pack. I know for instance that you cannot write to a Flash2Advance Ultra cart using DS-side software. |
F2A classic (not Ultra) is the same as FA Pro. In theory, it should be possible to reverse-engineer the protocol that each flash cart uses. But if you're buying something today, and you have a DS Lite or are willing to buy a DS Lite, get an EZ 3-in-1. But what should owners of an original DS use? Or are DS early adopters assumed to have been in the GBA homebrew scene before the DS came out?
No, Lazy1, the GBA is not close enough. On GBA, audio and video run on the same CPU, but they run on separate CPUs on the DS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128387 - dantheman - Fri May 11, 2007 3:21 am
There is reportedly a Phat-sized version of the EZ-V expansion pack, but as of yet I am not aware of any retailer that carries it. RealHotStuff has reported that they will receive them soon, but it's still indefinite at this point.
#128409 - OOPMan - Fri May 11, 2007 8:14 am
| Darkflame wrote: |
| Quote: | | DS is only about twice the power of the GBA. |
Purhapes thats slightly unfair.
GBA = 16.8mhz
one cpu on the DS = 66mhz
66/16 = 4.125
One cpu is 4 times, and the ram is vastely more.
(the other cpu is 2 times as powerfull when in ds more)
So I think saying the DS is only twice as powerfull isnt quite doing justice to the system. |
Indeed, the DS's dual-CPU design is actually a very clever design. Although it does make the system harder to code for, it increases the "power" is the DS far beyond a simple GBAx2 equation :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#128424 - pepsiman - Fri May 11, 2007 12:12 pm
| simonjhall wrote: |
| Also due to all the fancy bios/mode switching code this meant that hundreds of cycles would be wasted before my exception handler got called. |
If I understand what you're talking about here, then you can just remap the vectors to 0x0 and your exception handler will be called immediately.
(DSLinux does this).
#128507 - goruka - Sat May 12, 2007 3:04 am
| Gunnex wrote: |
I'm going to post my famous FAQ:
Why? Well let's refer to an FAQ.
|
Sorry, Gunnex, your faq is just not useful. Basically the fuzz was about the arm9 in the NDS having MMU, if it had, then emulating the GBA would be trivial, because wathever bios, registers, memory areas, etc the GBA has could be mapped to any place in the virtual address space. I thought it did, because Linux runs on the DS, but then i was soon pointed out that it is uClinux, a version of linux that doesn't need MMU. So, i guess my plan is frustrated :(
#128514 - knight0fdragon - Sat May 12, 2007 5:05 am
would it be possible to port the GBA emu on GP32 to NDS?
http://exophase.devzero.co.uk/gpsp09-2xb_src.tar.bz2
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#128515 - chuckstudios - Sat May 12, 2007 5:16 am
#128518 - tepples - Sat May 12, 2007 5:22 am
GP2X's CPU is clocked at three times the speed of the DS's ARM9, and GP2X has much more RAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128519 - knight0fdragon - Sat May 12, 2007 5:30 am
ohhh, perhaps there can be some tweaks made to speed improvements, who knows, I am not big on emulating, just thought Id throw in here what I saw.
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#128521 - Tikker - Sat May 12, 2007 6:13 am
why would you want to code an emulator when the DS will run GBA natively via slot 2?
it doesn't make a lot of sense
it's like building a floppy emulator to run on a CD-rom
#128526 - Miika - Sat May 12, 2007 9:23 am
| tepples wrote: |
| GP2X's CPU is clocked at three times the speed of the DS's ARM9, and GP2X has much more RAM. |
Yeah, it's very good! 64MB RAM, and when I overclock to 240MHz I can play Donkey Kong Country and WarioWare on it fullspeed! OK it skips some frames now and then but fullspeed and very playable :)
| Tikker wrote: |
why would you want to code an emulator when the DS will run GBA natively via slot 2?
it doesn't make a lot of sense
it's like building a floppy emulator to run on a CD-rom |
For people that doesn't own a slot-2 card that are too cheap to buy one and want to buy GBA games that suck 90%.
_________________
My DSQuake video: http://www.youtube.com/watch?v=03wz7nmaXa8
My QuakeDS video: http://www.youtube.com/watch?v=nNIKneo11o4
#128528 - Devil_Spawn - Sat May 12, 2007 10:28 am
i'm sure its possible to create psuedo emulators that only emulate what is needed, and surely the hardware can process/render all that is needed, surely that and a frame limiter would be all that is needed -.-
what about a modified flashme :P
#128542 - knight0fdragon - Sat May 12, 2007 3:48 pm
| Tikker wrote: |
why would you want to code an emulator when the DS will run GBA natively via slot 2?
it doesn't make a lot of sense
it's like building a floppy emulator to run on a CD-rom |
wifi multiplayer support perhaps?
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#128543 - tepples - Sat May 12, 2007 3:52 pm
GBA wired multiplayer protocols expect a latency so low that you'd have to use the "TGB Dual" method of emulating both GBAs on each host system. A laptop PC is fast enough for this; a DS isn't.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128549 - knight0fdragon - Sat May 12, 2007 4:17 pm
there is always those wireless multiplayer games like pokemon
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#128559 - Lynx - Sat May 12, 2007 6:30 pm
Can someone port the fricken thing already and put an end to this? Hack it together, get it to run at all, and release it.
_________________
NDS Homebrew Roms & Reviews
#128583 - Dood77 - Sun May 13, 2007 2:51 am
| Devil_Spawn wrote: |
| i'm sure its possible to create psuedo emulators that only emulate what is needed, and surely the hardware can process/render all that is needed, surely that and a frame limiter would be all that is needed -.- |
I believe this is called High-Level Emulation (remember UltraHLE?)
| Lynx wrote: |
| Can someone port the fricken thing already and put an end to this? Hack it together, get it to run at all, and release it. |
That would probably create more whiners than before it was sloppily ported, because they would whine about speed and compatibility etc.
#128589 - Frz - Sun May 13, 2007 4:34 am
| Quote: |
| I believe this is called High-Level Emulation (remember UltraHLE?) |
No it's called Virtualisation (that's also what VMWare is doing basically)
High Level Emulation basically means emulating the complete system and what it does (naive example: display a sprite as the result of a command) as opposed to each specific chip in the system
The problem with this seems to be that the DS does not have a MMU which makes it anywhere between hard and impossible (or infeasible for speed reasons) to implent a virtualisation system
While I'm really not familar enough with the ds, the gba and this method of emulating a system wouldn't theoretically speaking dynamic recompilation be possible (atleast for games that aren't too big and don't require huge amounts of ram)? I believe there has been a gb emulator on a z80 based handheld which did some virtualisation by dynamic recompilation but then again I'm not sure on this
#128590 - Ant6n - Sun May 13, 2007 5:23 am
| tepples wrote: |
| GBA wired multiplayer protocols expect a latency so low that you'd have to use the "TGB Dual" method of emulating both GBAs on each host system. A laptop PC is fast enough for this; a DS isn't. |
one could argue that this latency could be emulated by stalling gba emulation while the ds's are waiting for answers through the cable in order to emulate instant communication; since the DS is four times faster on arm9 alone one could probably spare a couple of hundred cycles here and there
#128604 - tepples - Sun May 13, 2007 1:11 pm
| Ant6n wrote: |
| one could argue that this latency could be emulated by stalling gba emulation while the ds's are waiting for answers through the cable |
But how would the emulator be able to notify the other emulators that their emulated machines will be waiting? The serial port throws an interrupt when a packet (2 bytes from each machine) has been transferred.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128666 - Dood77 - Sun May 13, 2007 11:45 pm
| tepples wrote: |
| But how would the emulator be able to notify the other emulators that their emulated machines will be waiting? The serial port throws an interrupt when a packet (2 bytes from each machine) has been transferred. |
You would just have a small icon displayed when that interrupt is thrown... on the screen other than the video output of course.
EDIT: Whoops I think I read this wrong... So I guess there would have to be something else sent along with the normal data? Does the GBA send back data confirming each packet was recieved?
#128679 - tepples - Mon May 14, 2007 1:01 am
| Dood77 wrote: |
| So I guess there would have to be something else sent along with the normal data? Does the GBA send back data confirming each packet was recieved? |
Each machine has an output register and four 16-bit input registers. The master sends a transmission start signal and a clock signal, and each of the four GBAs sends the 16-bit contents of its output register in turn by placing it on an electrical bus that all four GBAs see. To give you an idea of the latencies you need to support: - 000 ?s: GBA 1 sends start transmission signal and begins to send clock signal. GBA 1 places its 16 bits onto the bus.
- 156 ?s: GBA 2 places its 16 bits onto the bus.
- 312 ?s: GBA 3 places its 16 bits onto the bus.
- 469 ?s: GBA 4 places its 16 bits onto the bus.
- 625 ?s: All four GBAs get a serial interrupt.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128689 - Gunnex - Mon May 14, 2007 2:25 am
| goruka wrote: |
| Gunnex wrote: | I'm going to post my famous FAQ:
Why? Well let's refer to an FAQ.
|
Sorry, Gunnex, your faq is just not useful. Basically the fuzz was about the arm9 in the NDS having MMU, if it had, then emulating the GBA would be trivial, because wathever bios, registers, memory areas, etc the GBA has could be mapped to any place in the virtual address space. I thought it did, because Linux runs on the DS, but then i was soon pointed out that it is uClinux, a version of linux that doesn't need MMU. So, i guess my plan is frustrated :( |
I posted that to show the limits of a GBA Emu on DS. Yet, it is still not that useful as people keep asking. Though I had a concept. This would only work for multiboot and maybe homebrew, but how about the following process:
-Executing an NDS file on a Slot-1 card.
-Selecting the file.
-Loading the file into the RAM (size issue here)
-Applying a border if wanted.
-Booting GBA mode with the file at hand.
You can at least run things like Lockjaw: The Overdose.
#128690 - Ant6n - Mon May 14, 2007 2:39 am
| tepples wrote: |
| Dood77 wrote: | | So I guess there would have to be something else sent along with the normal data? Does the GBA send back data confirming each packet was recieved? |
Each machine has an output register and four 16-bit input registers. The master sends a transmission start signal and a clock signal, and each of the four GBAs sends the 16-bit contents of its output register in turn by placing it on an electrical bus that all four GBAs see. To give you an idea of the latencies you need to support: - 000 ?s: GBA 1 sends start transmission signal and begins to send clock signal. GBA 1 places its 16 bits onto the bus.
- 156 ?s: GBA 2 places its 16 bits onto the bus.
- 312 ?s: GBA 3 places its 16 bits onto the bus.
- 469 ?s: GBA 4 places its 16 bits onto the bus.
- 625 ?s: All four GBAs get a serial interrupt.
|
I dont really see the problem. #1 sends his halfword and starts waiting, then #2 sends halfword and starts waiting ... and when everybody has received #4's message they fire the interrupt. During waiting the DS would just idle around, emulate nothing and the emulated clock would be stopped, too... wouldn't that work?
#128742 - tepples - Mon May 14, 2007 6:55 pm
| Gunnex wrote: |
I posted that to show the limits of a GBA Emu on DS. Yet, it is still not that useful as people keep asking. Though I had a concept. This would only work for multiboot and maybe homebrew, but how about the following process:
-Executing an NDS file on a Slot-1 card.
-Selecting the file.
-Loading the file into the RAM (size issue here)
-Applying a border if wanted.
-Booting GBA mode with the file at hand. |
No. You cannot run multiboots this way because the GBA BIOS zeroes all EWRAM before displaying the logo.
| Ant6n wrote: |
| I dont really see the problem. #1 sends his halfword and starts waiting, then #2 sends halfword and starts waiting ... and when everybody has received #4's message they fire the interrupt. During waiting the DS would just idle around, emulate nothing and the emulated clock would be stopped, too... wouldn't that work? |
But how would the other systems know that they should be waiting?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128862 - Ant6n - Wed May 16, 2007 1:25 am
maybe a system could just wait per default after sending a message for a time that is approximately equal to the network delay, so that an instant answer from another DS will be perceived like an actual instant answer by the emulated gba. that only works of course if the there is not too much message sending going on, so that the accumulated delays would be noticeable
#128918 - tepples - Wed May 16, 2007 7:21 pm
Good idea. Implement it. ;-)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.