#110496 - OOPMan - Tue Nov 28, 2006 10:31 pm
Okay, seeing as how I've noticed a number of people mentioning the additional RAM provided
by these devices in a number of homebrew project related threads I figured I'd finally table
this topic and see what everyone thinks.
For the uninitiated, we know the following:
- Certain media adapters, including the SC, M3 and G6 contain on-board memory, usually 32mb
- This memory can be accessed via the GBA slot
- This memory can be made writable by writing a special unlocking code to a certain memory area
- Only 16-bit writes to this memory can be made. 8-bit writes cause corruption
- 16-bit and 8-bit reads work fine
This is all old news, though. Some DS homebrew already uses this additional memory. DSLinux is
the key example of this, although in some ways it's actually not a relevant example for the
general homebrew situation. Moonshell also reportedly uses the additional memory when displaying
very large image files (Can anyone confirm this?)
Other than these examples, though, not much has been done with this extra memory, despite it's
potential to be used as a cache area (Assuming that this memory is quicker to access than the
media plugged into the media adapter that is...) Not much information seems to be available on
how to use this memory and a couple of misconceptions seem to exist.
Some pretty good ideas are also floating about though. A while back, in a thread devoted to a different topic
entirely, tepples mentioned that it might be nice if someone were to code a library that enabled access to the extra
memory in the form of a FAT device via libfat.
We have some good ideas and the information is available, but nothing has really been done...
So what I'm thinking is that we do some discussing about the ways of implementing a generally usable
library that provides access to the extra RAM in some fashion or other and maybe someone will actually
be able to use the provided info and discussion to whip something up. At the very least it'll make
for some fun chat...
Anyway, some stuff with regards to DSLinux and the memory access structure. In another thread it was
mentioned that to use the RAM you'd need to re-write your entire program to avoid 8-bit writes. However,
this idea seems to be based on the fact that DSLinux had to have its toolchain restructured to avoid
8-bit writes at the OS level. With DSLinux this was necessary, otherwise it would have been required
to rewrite the entire OS and software running on it to avoid 8-bit writes, not a feasible approach.
So DSLinux had it's toolchain monkeyed about and now it uses the extra memory just fine.
Do we need to restructure devkitPro to use the memory, though? I don't think so. DSLinux combines the
DS's main ram and the extra ram so as to seem contigious. I can see why they'd need to avoid any 8-bit
writes, since you could never be sure when you're writing to the main memory or the extra memory, as the
memory appears contigious.
Bare-metal homebrew need not cater for this worst-case scenario, though. If
access to the extra ram was provided by a special interface (For example, as a special FAT device as
proposed by tepples) that controlled all reads and writes to the extra ram then the problem of avoiding
8-bit writes to the extra ram could be avoided without needing the re-jigger the whole program
to avoid accidentally performing an 8-bit write to the extra memory and corrupting its contents (Although
it would still be possible to intentionally perform and 8-bit write, unless the interface could somehow
lock access to the memory area)
Well, anyway, my thoughts on that. And now, for the disclaimer:
I may have written some complete crap up here. I can not claim to be a brilliant programmer so what is
written above is based on what I've gleaned and "understood" from various posts related to this topic on
both the DSLinux and GBADev forums, as well as pepsiman's blog (Where the details for unlocking the extra
ram can be found...). Also, I'm not a hotshot when it comes to hardware level stuff. What this means is that I would really really appreciate it if you correct me on
something that needs correcting. It's quite possible that my understanding of things is flawed and I
would prefer not to wander about with cracker-jacked ideas in my head :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#110503 - Lick - Tue Nov 28, 2006 10:45 pm
I'm against a malloc/free implementation, because of the 16-bit writes I think it's better to provide a safe write function.
I'm also against making it a FAT device. It's simply bullshit, it's NOT a FAT device. Make it stand-alone instead.
Anyway, I sure would love such a library.
_________________
http://licklick.wordpress.com
#110509 - agentq - Tue Nov 28, 2006 11:06 pm
Ported software like ScummVM would need the 8-bit writes problem resolved, as they will never be rewritten to avoid doing any 8-bit writes.
But I would be quite interested to see a library that provides access to this memory compatible accross cards, and still alows use of the FAT driver.
#110514 - Izhido - Tue Nov 28, 2006 11:50 pm
Hmm... y'know, we might learn a little from the PalmOS development model for this.
The memory heap for a Palm device is waaaay too short (~256kB or a little more, depending on device) for many applications. There is, however, a way to use the 64-128-256 MB of memory actually available within the devices. Palm recognizes three ways of handling memory:
1) Memory pointers: common, run-of-the-mill memory blocks, accessible through both new/delete operators AND MemPtrXXXXXX() functions, whose size is actually limited to whatever free space the current memory heap has;
2) Memory handles: special "pointers" to memory outside the heap, that can be "locked" into the current memory address space of the application, accessible only through MemHandleXXXXXX() functions and, once "locked", accessible as normal memory;
3) "Databases": collections of "records" that are, in essence, memory handles to either battery-maintained RAM, flash memory, or actual hard disks (in the case of the LifeDrive).
This link explains all of this better:
http://www.palmos.com/dev/support/docs/palmos/Memory.html
It might not be the best approach for handling the extra RAM for these cards, but since it is already in use for another devices, and many of us Palm developers already do memory management this way, I feel like it could be a decent alternative.
Discuss.
- Izhido
#110521 - simonjhall - Wed Nov 29, 2006 12:41 am
I've heard (via the Internet) that you can use either the memory or the flash card - but not both at the same time. Is this true?
And if someone could give me a sprog of code, showing me how to read/write to the card (yeah, I'm sure it somewhere in the forums but I've just been to the pub) then I'll see what I can do with Q2 once I get a card. It'd then be trivial to fix up programs to make them run with the full whack of memory. Neil, yeah I'm looking at you and ScummVM :-D
And regarding the topic of the post :-) yeah a library would be cool but I think it would be too heavyweight to do the things I'd like to do. I'd just like to use it as RAM; I'd not like to use it as a temporary RAM drive. I've got a compact flash card for that.
#110522 - agentq - Wed Nov 29, 2006 12:43 am
Do you intend to use one of your postprocess-the-binary techniques?
I worry though, about the thousands of people who mail me when their particular card reader doesn't work with the RAM expansion code. It's been enough hastle with ScummVM as it is.
#110523 - sasq - Wed Nov 29, 2006 12:45 am
Locking and unlocking means copying memory back and forth which is a waste of cycles IMO. A simple interface that lets you init (and check for precence), allocate and free memory should cover it.
int exmem_init() // returns size or 0 if not present
u16 *exmem_alloc();
void exmem_free(u16 *);
Does all the mentioned devices actually use RAM or do some use FLASH ?
#110524 - Dwedit - Wed Nov 29, 2006 12:46 am
| simonjhall wrote: |
| I've heard (via the Internet) that you can use either the memory or the flash card - but not both at the same time. Is this true? |
You can not simultaneously use the extra ram and flash card, but you can instantly switch which one you are using at any time.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#110530 - simonjhall - Wed Nov 29, 2006 1:03 am
@agentq: I've glad to head you're still in the mix, dawg - not heard from you for a while! Just got back from a launch lunch - did like two hours work this morn, then went for a nine hour lunch :-)
Teh pwn. Got me a plaque! Gonna hang it in the bathroom to piss off Jenny.
| agentq wrote: |
| Do you intend to use one of your postprocess-the-binary techniques? |
Yeah. I've shown that it can work on the complex source files whilst using a minimal amount of memory, so I can't see why I can't use something similar on the DS. The load/store instructions are much more complex in ARM than what I wrote for the prev version, but it shouldn't be too much trouble.
I had a big discussion about this with Markie and Chris Carty recently, esp regarding DMAing code in, as well as data. It's totally do-able. Chris suggested I move the Quake renderer to...one of the extra processors in order to get some kick ass fill rate. Oh and I think Dan wants to use that compression stuff you wrote.
I'd be interested to see well how it works with ScummVM - I'm not saying you should release it, but it'd be a laugh running those games (eg The Dig?) that you can't currently do... :-p
#110531 - agentq - Wed Nov 29, 2006 1:07 am
Yeah, I'm still around. Not been here much recently though. I've just been reading your posts on the Quake port. We should catch up. Pub on Friday, perhaps?
Maybe I'll try it with ScummVM. At least I've got a debugger to help me out ;-)
...and now we've wasted the time of everyone reading this.
#110533 - sasq - Wed Nov 29, 2006 1:12 am
| simonjhall wrote: |
| agentq wrote: | | Do you intend to use one of your postprocess-the-binary techniques? |
Yeah. I've shown that it can work on the complex source files whilst using a minimal amount of memory, so I can't see why I can't use something similar on the DS. The load/store instructions are much more complex in ARM than what I wrote for the prev version, but it shouldn't be too much trouble.
|
You are talking about going through the TEXT sections, replacing all STRB and LOADB opcodes with SWI or JUMP or something to code that performs the same operation using word-sized accesses instead?
#110534 - Lazy1 - Wed Nov 29, 2006 1:15 am
From what I see both ScummVM and Mini vMac need the same thing: A devkitpro version with the 8bit write patch applied.
Both projects are too large to locate and change every 8bit write.
As for making a library, it's a good idea if the only thing you'll do is add functions for unlocking the ram and switching to/from memory and I/O mode.
#110535 - simonjhall - Wed Nov 29, 2006 1:18 am
Yes, pubage sounds fun. Though I know that every time that that happens we all always end up in some kind of Japanese restaurant at about 11:50pm, and I'm always pissed! I've then gotta borrow money off G you and Duncan in order to eat... ;-)
Wanna lend me one of your cards which has RAM on it? You can say no, but you won't get a free copy of Quake!
Hope you're ok at work man. I also hope that you're not the person who has to update the SDK when a new version comes out! Spent all day faffing with Imogen and 'urev today :-(
And to the OP: I'm really sorry for hijacking your thread! I really am interested in using these extra cards to make better homebrew!
Oh and for those interested, changing (offline) every 8-bit write to a 32-bit read/modify/write is easy, as long as the code isn't dynamically generated.
| Quote: |
| As for making a library, it's a good idea if the only thing you'll do is add functions for unlocking the ram and switching to/from memory and I/O mode. |
My thoughts exactly.
#110560 - felix123 - Wed Nov 29, 2006 6:37 am
Would integrating it into devkitPro make it easier to use? Make it detect the presence of ram, use it if it is available.
#110566 - OOPMan - Wed Nov 29, 2006 8:01 am
| Dwedit wrote: |
| simonjhall wrote: | | I've heard (via the Internet) that you can use either the memory or the flash card - but not both at the same time. Is this true? |
You can not simultaneously use the extra ram and flash card, but you can instantly switch which one you are using at any time. |
Yes, DSLinux currently does this thanks to the funky drivers Amadeus wrote. He also somehow managed to work out how to access all 32mb with the M3, which normally only allows access to 16mb of the memory (Something to do with an I/O vs memory split or something if I recall. The details of that are here)
Simon, no worries about the thread hijackage :-) I also really think it would be good to actually make the extra memory usable by general homebrew. The DSLinux people did some great work in digging the stuff up, but not much has been done with it outside of DSLinux and I see that as lost potential. I'm sure there are numerous projects that would benefit from it...
With regards to modifying the toolchain, wintermute has apparently looked into this (According to stsp over at DSLinux) but he didn't reply to
the PM I sent him asking what the case was with this. It's a pity DSLinux uses a different toolchain to compile, otherwise we'd already have the support for this that we need...
At least in the short term a ram-drive type library might not be a bad idea...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
Last edited by OOPMan on Wed Nov 29, 2006 8:08 am; edited 1 time in total
#110567 - Payk - Wed Nov 29, 2006 8:06 am
it would interest me how much faster that 32MB are compared to a SD/CF.
My game uses KOSFS(ROMDISKFS by GPF) and as alternative FAT. The speed difference isnt much, well its not very noticeable. But of course it doesnt just read in that time (for example when loading md2 it converts float to fixed point). But i can tell you that ROMDISK is SLIGHTY faster.
best would be to do some messuring to compare. But generyl i wanted to say if your looking for a FAT-ACCESABLE device, use your SD ;P
A malloc/free command would sound to me. Maybe emalloc/efree or something. Alternative to that you could do a wrapper for malloc/free which first trys to get the extended ram or something. But could the pointers realy point to that extra ram?
One great thing would be to load a entiry mp3 into it using arm9, then overgive that device to arm7 and let that helix-mp3 codec play it while arm9 can do all that stuff it has to :D
#110572 - sasq - Wed Nov 29, 2006 11:54 am
Another possibility would be to set up the protection unit so the extended memory becomes write-only to programs, then the exception routine checks the offending opcode for STRB and if so emulates the memory access.
This would slow down all writes to extended memory however - but you could make memcpy, stcpy etc aware of this and implement fast copies to that memory.
#110584 - OOPMan - Wed Nov 29, 2006 4:41 pm
By the way, does anyone know if my original idea would work? The one involving custom access to the extra memory?
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#110587 - Izhido - Wed Nov 29, 2006 4:48 pm
OOPMAN! NO SOUP FOR YOU! OUT!
- Izhido
#110590 - OOPMan - Wed Nov 29, 2006 5:28 pm
Que Pas?
That was special...
Thanks anyway :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#110615 - HyperHacker - Wed Nov 29, 2006 11:04 pm
Sasq seems to be on the right track. Use the exception handler to emulate 8-bit writes. Since 16 and 32-bit can be used where speed is an issue, and reads of all sizes work just fine, this seems like the ideal way to work around the issue. Postprocessing might be an alternative for ports or cases where speed is important and 16/32-bit writes aren't feasible.
Also why exactly can't we use amadeus' cache/swap solution?
_________________
I'm a PSP hacker now, but I still <3 DS.
#110617 - simonjhall - Wed Nov 29, 2006 11:11 pm
The exception-handling method mentioned here was almost the same as what I used to do the memory-mapped files. One of the main reasons I discarded it in the end was due to the speed...
Why not just use that compiler patch to stop it from emitting 8-bit writes?
#110684 - OOPMan - Thu Nov 30, 2006 12:12 pm
The problem with Amadeus's stuff is that it's all been done to the DSLinux specific toolchain. I'm not sure how easy it would be to move it across to the devkitPro toolchain. Depending on how much the toolchains differ, it could be a lot of work or a small amount of work...
Also, the DSLinux toolchain specific changes to cause a general performance hit for all memory access...
As I said, I'm of the opinion that such a general change is not necessary for bare-metal homebrew unless you have a burning desire to treat the 4mb of main memory and the 32mb of additional memory as contingious (Ie Your homebrew will see 36mb of memory total...). By wrapping the extra memory up with some access code you could maintain the main memory's speed while also gaining access to the extra memory. But the downside is that the memory is not contigious, so you you would need to think about exploiting things like the principle of locality, etc to use the extra memory as cache for data not required for immediate use...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#110729 - Lazy1 - Fri Dec 01, 2006 12:34 am
I'll try later on and see if I can get mini vmac compiled with the dslinux toolchain and post an update if it works.
I'm expecting it to halve performance though so I hope people have fun with 8fps emulation under load :)
One day I'll rewrite that 68k core in assembly, all I have to do is learn it without getting bored and quitting.
#110785 - simonjhall - Fri Dec 01, 2006 3:12 pm
Does anyone know how fast the memory on one of those cards (like the Supercard and M3 etc) is? As it has to be accessed over the gba slot, is it limited to the speed of that? ie 16-bit access etc.
Also, can you DMA from the memory on those cards to main memory?
#110790 - OOPMan - Fri Dec 01, 2006 3:54 pm
I believe the memory access is fairly fast. Not as fast as main memory, but probably faster than accessing the SD card.
I already posted a link, but here it is again.
This topic on the DSLinux forums contains a lot of useful information about the extra memory provided by certain cards and the pros and cons of using it.
You might also want to PM Amadeus of DSL, as he's the best person to ask with regards to information on the extra memory.
With regards to Memory Speed and DMA, Amadeus has the following to say:
| Quote: |
Yes, the GBA ROM space is slower than main memory. We rely on the data cache for speedup, as we rely on the instruction cache for speedup of XIP execution.
Other limitations: GBA SLOT space is not reachable by DMA. Fortunately, the linux kernel knows these problems from the 386 architecture. |
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#110792 - pepsiman - Fri Dec 01, 2006 4:29 pm
| simonjhall wrote: |
| Also, can you DMA from the memory on those cards to main memory? |
Only one CPU can use the cart memory at a time.
As the ARM9 uses it in DSLinux, the ARM7 cannot.
The CPU that does have access can use DMA.
#110803 - sasq - Fri Dec 01, 2006 8:18 pm
Ok... reading about the SWP-trick I am considering a combination of my idea and that concept:
You set the entire 16-bit memory as read-only, but have one overlapping page read/write that can be moved around, 4KB in size.
Now when you write to 16-bit memory, the exception handler triggers, and there you perform serveral SWP (or a similar opcode) to read in the current cache line, as well as all following cache lines until an entire 4KB page has been read into the cache.
Now you can move the PU-page over the area that recides in the cache and return.
If this works you would only get an overhead for the first write inside the area, which would mean very little for sequential writes.
On the other hand it would be pretty expensive for non-sequential writes - but that can be avoided by keeping random access stuff in main ram.
#110842 - HyperHacker - Sat Dec 02, 2006 3:14 am
I think the best solution depends on the application. For example, a SNES emulator will probably want to load the ROM image (and perhaps emulator code) into the 32MB region and keep emulated system memory and emulator variables in main RAM, which means almost entirely sequential writes and few of them. Whereas something memory-heavy like a web browser would probably benefit from having one contiguous 36MB block at the cost of some speed, and a simple OS might keep kernel (and maybe some app's) memory in the internal 4MB while giving apps the other 32MB.
_________________
I'm a PSP hacker now, but I still <3 DS.
#110847 - Dwedit - Sat Dec 02, 2006 5:28 am
I would think that emulators would want to keep their CPU emulation code in fast ITCM, not slow cartridge ram. NesDS uses the ITCM for holding the 6502 emulation core.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#110849 - HyperHacker - Sat Dec 02, 2006 6:10 am
#110853 - dantheman - Sat Dec 02, 2006 6:52 am
Does that mean that he's found a way to use the Opera browser's RAM pack for general homebrew? Sounds good if it does.
#110864 - OOPMan - Sat Dec 02, 2006 9:15 am
No, not really. The Opera DS ram pack only has something like 6-10mb of RAM in it. Not very much really.
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#110907 - dantheman - Sat Dec 02, 2006 7:38 pm
It's still better than nothing though. Then again, now that I'm awake and can think about it, this would only be useful to users of Slot-1 devices, since you can't use a Slot-2 device and the RAM expansion pack at the same time.
This is just theoretical thinking here, but perhaps it might be useful for GBAMP users who want to use binaries larger than 4 MB. Load 4 MB of the program into RAM, pack-swap to the RAM pack and unload it to there, then pack-swap back to the GBAMP to get the rest of the program into the DS's RAM. It probably wouldn't work, but it's an interesting idea nonetheless.
#110989 - chishm - Sun Dec 03, 2006 12:40 pm
| dantheman wrote: |
| This is just theoretical thinking here, but perhaps it might be useful for GBAMP users who want to use binaries larger than 4 MB. Load 4 MB of the program into RAM, pack-swap to the RAM pack and unload it to there, then pack-swap back to the GBAMP to get the rest of the program into the DS's RAM. It probably wouldn't work, but it's an interesting idea nonetheless. |
The RAM pak would lose the data when you pull it out. RAM is volatile and needs electricity to maintain data. This is assuming you aren't equiped with super-human speed and a secondary power source to power the RAM pak while the rest of the data is loaded from the GBAMP. Alternatively you could hack a secondary power supply into the RAM pak, but then you might as well use an M3 or Supercard.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#111031 - dantheman - Sun Dec 03, 2006 7:47 pm
...and you know, the sad thing is that I knew that fully well. Perhaps I need to think these things through before posting about them.
#111035 - OOPMan - Sun Dec 03, 2006 7:53 pm
We all make impulse posts now and then :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#111098 - HyperHacker - Mon Dec 04, 2006 2:41 am
| OOPMan wrote: |
| No, not really. The Opera DS ram pack only has something like 6-10mb of RAM in it. Not very much really. |
Certainly useful to those on a small budget who already have Opera.
_________________
I'm a PSP hacker now, but I still <3 DS.
#111107 - chishm - Mon Dec 04, 2006 3:48 am
| dantheman wrote: |
| ...and you know, the sad thing is that I knew that fully well. Perhaps I need to think these things through before posting about them. |
It's okay, I assumed your post was tongue-in-cheek and I hope mine comes across as such too.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#111111 - Dwedit - Mon Dec 04, 2006 4:41 am
| chishm wrote: |
| dantheman wrote: | | This is just theoretical thinking here, but perhaps it might be useful for GBAMP users who want to use binaries larger than 4 MB. Load 4 MB of the program into RAM, pack-swap to the RAM pack and unload it to there, then pack-swap back to the GBAMP to get the rest of the program into the DS's RAM. It probably wouldn't work, but it's an interesting idea nonetheless. |
The RAM pak would lose the data when you pull it out. RAM is volatile and needs electricity to maintain data. This is assuming you aren't equiped with super-human speed and a secondary power source to power the RAM pak while the rest of the data is loaded from the GBAMP. Alternatively you could hack a secondary power supply into the RAM pak, but then you might as well use an M3 or Supercard. |
Compress the program, it may be smaller than 4 megs once compressed, then it can expand to any size.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#111115 - dantheman - Mon Dec 04, 2006 5:33 am
| chishm wrote: |
| dantheman wrote: | | ...and you know, the sad thing is that I knew that fully well. Perhaps I need to think these things through before posting about them. |
It's okay, I assumed your post was tongue-in-cheek and I hope mine comes across as such too. |
No, actually I was quite serious, heh. It's just that for some reason, at the time I forgot about the fact that RAM is volatile. You'd think a guy who spends 90% of his time at a computer would remember a simple fact like that, but I guess not.
Besides, my whole theory of "GBAMP must load everything into the 4 MB of RAM" was disproven anyway, as Lynx explains in this post.
In any case, my point is that although it doesn't have the sheer capacity of the Supercard or M3, support for the RAM pack could potentially be useful for some users if he or she has already bought the browser. Perhaps for instance it could allow users of SLOT-1 devices to run GBA homebrew (as long as it fits within the size limit of course). As there is already software that allows you to switch to GBA mode from the DS (adding a custom border at the same time) it could theoretically be possible.
*runs away before someone can debunk this theory as well*
#111121 - tepples - Mon Dec 04, 2006 6:45 am
| dantheman wrote: |
| In any case, my point is that although it doesn't have the sheer capacity of the Supercard or M3, support for the RAM pack could potentially be useful for some users if he or she has already bought the browser. |
As far as I know, Nintendo and Opera have not set a date for when Nintendo DS Browser will become available in North America. SuperCard and M3 are out now in the single largest monolingual market in the highly developed world; Nintendo DS Browser isn't.
| Quote: |
| Perhaps for instance it could allow users of SLOT-1 devices to run GBA homebrew (as long as it fits within the size limit of course). |
And assuming that the RAM card is mapped into an address space conducive to GBA homebrew.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#111122 - HyperHacker - Mon Dec 04, 2006 6:46 am
Unless Nintendo made some effort to prevent a GBA ROM from being loaded correctly into the device (IE making the first few bytes unwriteable so the Nintendo logo won't match up) or it's too slow, it'd certainly be possible. The program you speak of will go right ahead and boot no matter what's in the slot, though it has no way to actually load something into GBA "ROM".
Of course the majority of that app's code is for setting borders and configuring the system. Going into GBA mode is as simple as
mov r2, #0x40
swi 0x1F0000 @0x1F in THUMB
on ARM7, though this leaves you with the other screen on, whatever was in the border area still on the screen, etc.
[edit] And yes, it'd have to have some RAM mapped to the GBA header area or the BIOS will reject it. There's nothing that can be done about that; once you make that SWI call the GBA BIOS takes over completely, and it's read-only data built into the CPU so you can't just rewrite it.
_________________
I'm a PSP hacker now, but I still <3 DS.
#111124 - tepples - Mon Dec 04, 2006 7:04 am
Likely case is open bus at 0x08000000 through 0x08FFFFFE, RAM at 0x09000000 through 0x09FFFFFE. Try booting that.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#111266 - simonjhall - Tue Dec 05, 2006 10:38 am
What happens to the memory protection unit when you use memory on one of these fancy cards? Does it 'just know' that there's RAM there, or do you have to set it up so you don't get faults when accessing it?
I'm just thinking that if the MPU doesn't like the extended RAM then I'll have to just disable it and I won't be able to use the debugger :-(
_________________
Big thanks to everyone who donated for Quake2
#111376 - simonjhall - Wed Dec 06, 2006 12:27 am
I was thinking about this extra RAM thing (again) earlier and was annoyed that if I do Q2 for extra RAM cards I'm gonna have to get each of the cards in order to properly work on it. Then I thought of the 'library' idea mentioned here and how useful that it could actually be.
So, what I'd like to see from libextraram is:
some functions which,
- detect which card it is (and see if memory is available)
- initialise the device (and the MPU if reqd)
- return a pointer to the top of the new memory
- return the size in bytes of the total accessible memory
- do some basic stress tests to see if the RAM performs as expected
- an a lock/unlock function which needs to be called when you want to do disk access
- a memcpy function, and a DMA function (if applicable)
I'd not like to see functions which manage the memory. ie no malloc functions. Also as people are aware of the restrictions (ie the 8-bit thing) when using these cards there should be no fancy workarounds and the programmer should be allowed to do their own solution if required.
This'd ideally work for all the cards but would have the same interface, so you could load a memory-heavy program onto any of these cards and it'd just work... (or fail with a message)
How's that sound? I'd def use this lib if available.
_________________
Big thanks to everyone who donated for Quake2
#111377 - Izhido - Wed Dec 06, 2006 12:45 am
Excellent. Then, I ask again, what do you people think about designing such library along the lines of the PalmOS memory management model? It's just curiosity, whatever way it becomes implemented I will definitively use it.
- Izhido
#111405 - OOPMan - Wed Dec 06, 2006 8:29 am
Some cool ideas simon...
There is one thing to keep in mind that the DSLinux ram stuff has illustrated though.
If having the 4mb main + 32mb extra act as a contigious block of memory then the it is very likely that the DKP toolchain would need to be patched to handle 8-bit writes in the same fashion as the DSLinux toolchain was.
I believe cart detection can already be done. If I recall, Lick's libcartreset does does so...
The other points all sound good :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#111417 - simonjhall - Wed Dec 06, 2006 10:30 am
How could the toolchain be patched to make it appear as one contiguous block? I'm guessing here but I doubt the base address of the extra RAM is not at the start of the very end of the regular RAM.
If you wanted it to look like one big block wouldn't you need an MMU?
I was reading that big memory thread on the dslinux site last night and there's something to do with a 16/16 split on the M3. Does anyone know what this is about?
It'd be really awesome if there was an FAQ written somewhere about how to use all the cards and contained all the (known) little details. I might mail Amadeus to see if he's got anything like this.
_________________
Big thanks to everyone who donated for Quake2
#111418 - OOPMan - Wed Dec 06, 2006 10:42 am
Bleh, I didn't quite explain myself correctly :-)
Patching the toolchain probably won't make the RAM seem contigious. However, what it will do is allow you to write to RAM without needing to worry about whether the RAM in question is main RAM or extra RAM.
Hence, if you plan to write a piece of software that treats the main RAM and extra RAM as being contigious (For example, an OS like DSLinux does this. Apps compiled for DSLinux do not see the main RAM and extra RAM as being separate. It's all just RAM :-) then you will need the 8-bit write-patch applied to the toolchain.
If you're happy keeping the 2 pieces of memory separate and in their own boxes, then I would imagine you only need 8-bit writes for the extra RAM, not the main RAM.
The 16mb RAM/16mb IO split on the M3 was dealt with by Amadeus. It has something to do with the manner in which the M3 handles IO and RAM access. Normally, I believe, the M3 is only able to access 16mb of the RAM, not the whole 32mb.
I'm not sure how Amadeus got around it though. I think you'd need to ask him what he did that allowed the M3 to access the full 32mb of RAM. You could also get the DSLinux sources and take a look at the M3 RAM driver he wrote...
I would strongly recommend mailing Amadeus if you want to know more about the memory stuff, since he is the key developer of it on DSLinux. I believe he's moving house right now, though, so it may take him a bit longer too reply until he's settled in...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#111493 - Firon - Thu Dec 07, 2006 2:04 am
| OOPMan wrote: |
I'm not sure how Amadeus got around it though. I think you'd need to ask him what he did that allowed the M3 to access the full 32mb of RAM. |
Basically, he did it by making sure that no I/O is being done at same time that the extra memory is being accessed. It just switches back and forth.