#125614 - Lazy1 - Sun Apr 15, 2007 2:54 am
I am currently writing a library for using the ram found on some slot-2 cards.
My idea was to make one library to support all current and future cards, thats where a script file like this comes in.
| Code: |
(libextmem)
device=Supercard CF
size=0x02000000
base=0x08000000
fn set_ram
write16( 0x09FFFFFE, 0xA55A )
write16( 0x09FFFFFE, 0xA55A )
write16( 0x09FFFFFE, 0x0005 )
write16( 0x09FFFFFE, 0x0005 )
efn
fn set_disk
write16( 0x09FFFFFE, 0xA55A )
write16( 0x09FFFFFE, 0xA55A )
write16( 0x09FFFFFE, 0x0003 )
write16( 0x09FFFFFE, 0x0003 )
efn
fn set_disable
brk
efn
|
That script would be placed in the root of your media device as "memdrv.txt' and would be read and compiled once you initialize libextmem.
The script's program sections are compiled into read/write 8/16/32 instructions for a tiny virtual machine which will execute them whenever you want to set the cart to ram mode, disk mode or disabled.
The basic API will probably be just an init function and some functions to get the cart name, size and base address.
New carts can be supported by writing a driver script and dropping it into memdrv.txt in the root of your media device.
Any thoughts/ideas/suggestions?
#125615 - stampede_dude - Sun Apr 15, 2007 2:56 am
That would be awesome if someone ever gets a web browser working for the DS that is homebrew.
_________________
867-5309
#125617 - chishm - Sun Apr 15, 2007 3:52 am
You could just use compiled ARM code, with offset pointers in the header of the file. If you assume that the code is completely self contained, with each function (like set_ram, set_disk, etc.) having its own block of code, you can simply load it into memory, then use a bit of ASM magic to BLX to it.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#125621 - Lazy1 - Sun Apr 15, 2007 4:42 am
I wanted to keep things simple (except the script compiler which is huge and continues to grow in size) so that making and debugging ram drivers would be easier.
Besides, I doubt any applications would swap modes fast enough to notice any performance hit vs native code especially since the vm is extremely simple.
#125623 - HyperHacker - Sun Apr 15, 2007 5:20 am
A script parser is going to inflate the executable though, which could be an issue for games that already take up a fair bit of the available 4MB.
It's nice to see this being done though. Will it support other things, such as rumble and motion sensors?
_________________
I'm a PSP hacker now, but I still <3 DS.
#125624 - chishm - Sun Apr 15, 2007 5:22 am
Fair enough. I was just thinking that native ARM code is easier to execute, doesn't require a VM, and supports mathematical operations and looping.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#125642 - simonjhall - Sun Apr 15, 2007 11:41 am
Nice idea, but the script-parsing stuff would def increase the size (although it can't be that much...). How about just dropping a precompiled flat binary into the same directory as the program and that file just gets slotted straight into memory on startup?
You'd have to reserve a little bit of space though in your binary (I guess it'd be a little bit like the DLDI system).
Btw: some of these unlock codes write to locations that may be in the extended memory space. What happens to the data in those addresses when you write the code? Does it detect that it's unlock code and revert the changes, or does the data in those addresses get trashed?
_________________
Big thanks to everyone who donated for Quake2
#125647 - Lazy1 - Sun Apr 15, 2007 2:37 pm
It actually would be easier to keep the compiler in a separate standalone application and to compile the script into a single binary file.
About writing unlock codes:
I have no idea and wondered this myself, maybe someone who is more experienced in that area could give some info?
I haven't noticed a problem with Mini vMac though, but maybe that's why the M3 code never worked.
#125657 - Lick - Sun Apr 15, 2007 5:34 pm
| simonjhall wrote: |
| Btw: some of these unlock codes write to locations that may be in the extended memory space. What happens to the data in those addresses when you write the code? Does it detect that it's unlock code and revert the changes, or does the data in those addresses get trashed? |
Wasn't it so that the extended memory can only be written to 8 bits a time? When you write 16 bit to that address it might recognize as a state change, and with 8 bit it stores the data?
Just a wild guess.
_________________
http://licklick.wordpress.com
#125731 - FAST6191 - Mon Apr 16, 2007 12:12 pm
Personally I try to keep the root as clear as possible or for quick launching.
Anyhow I am sure I say this to the chagrin of a few end users but the idea of a dynamically linked ram interface (sorry chism) is an idea I had kicking around in my head for a while now.
Implementation may be fun though, maybe it could be piggybacked onto DLDI and placed in the "unused" DLDI section.
#125738 - simonjhall - Mon Apr 16, 2007 1:37 pm
Has anyone got proper unlock codes for the M3? It seems that people have problems getting them to work... I'd really like them so I can drop them into Quake! Plus someone to test them for me :-)
Oh and Lick, it's a 16-bit bus. If you write 32- and 16-bit quantities the data gets stored correctly (that's a str instruction). If you do 8-bit writes to the bus (with a strb or its derivatives) then the data that gets written is completely whack. Some people have said that what you get written is (number << 8) | number, but on my SC all I get is crap. Stores seem to be the only thing that's affected - loads work fine, regardless of the size.
If you're interested, I get about 15 megs/second writing with 32- and 16-bits to main memory and ~7 megs/second 16-bit writes, ~3 meg/second 32-bit writes to the GBA bus. It doesn't seem to make a difference which card is plugged in.
_________________
Big thanks to everyone who donated for Quake2
#125740 - MelGibson - Mon Apr 16, 2007 2:59 pm
I think the people over at dslinux.org (esp. Amadeus who implemented the RAM Access in DSLinux) should have the proper unlock codes for M3 (and other cards as well)
If you need an M3 tester, I'd be glad to help.
#125742 - Genoil - Mon Apr 16, 2007 3:20 pm
here
are the m3 unlock codes from the dslinux SVN trunk.
i think the best way to automagically support extended RAM is to modify the compiler like Amadeus did to the dslinux building toolchain.
#125746 - OOPMan - Mon Apr 16, 2007 4:27 pm
Isn't this a teensy little bit overkill, considering that there are basically 4 RAM devices, 5 if you include the rather difficult to use EZFlash one...
It just seems like setting up a library they way this is set up is a little OTT for the current scenario and potential future scenario...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#125748 - Lazy1 - Mon Apr 16, 2007 5:04 pm
I don't think it's overkill, it would making and debugging drivers easier as new devices come out without applications needing applications to be rebuilt.
Having an extra file in the root directory won't make a difference anyways since most apps can't save in their working directory.
Another reason for this library would be that even though there are only 5 ram devices the developer may only own 1.
Trying to support a device in your application without having it is a real pain in the ass, I don't know how many builds of Mini vMac I sent over IRC to get M3 support working. ( Which I never figured out )
With this library, I could send a small script file or compiled driver or the user could write one themselves.
This frees up time for the developer since he's guaranteed that through the API all devices look and act the same.
I would be planning to add an application to test and debug drivers to make it easier for people who actually have the devices to write them.
#125783 - simonjhall - Tue Apr 17, 2007 12:18 am
@Genoil
We've talked about adjusting the compiler before, and I think people preferred to do the work themselves, rather than let the compiler 'just fix it'. What'd be nice would be a tool which went through object files and gave you line info as to where strb (and its derivatives) live, so you could fix the code yourself. That way you'd be aware of what's fixed and what the performance implications would be...
_________________
Big thanks to everyone who donated for Quake2
#125814 - OOPMan - Tue Apr 17, 2007 7:54 am
| Lazy1 wrote: |
I don't think it's overkill, it would making and debugging drivers easier as new devices come out without applications needing applications to be rebuilt.
Having an extra file in the root directory won't make a difference anyways since most apps can't save in their working directory.
Another reason for this library would be that even though there are only 5 ram devices the developer may only own 1.
Trying to support a device in your application without having it is a real pain in the ass, I don't know how many builds of Mini vMac I sent over IRC to get M3 support working. ( Which I never figured out )
With this library, I could send a small script file or compiled driver or the user could write one themselves.
This frees up time for the developer since he's guaranteed that through the API all devices look and act the same.
I would be planning to add an application to test and debug drivers to make it easier for people who actually have the devices to write them. |
It's not the dynamic side that sounds OTT. It's the scripting engine + VM thing. You've said yourself that it continues to grow at an alarming rate.
You may well have the same problem I encountered with the threading library I ported. It works well, but at 60k, it's a rather large chunk of code.
The dynamic interface idea is cool, but if it comes at a cost of bloat, is it really worth it?
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#125815 - viruseb - Tue Apr 17, 2007 7:55 am
BTW Amadeus modifies the compiler because it more 'easy' to fix the compiler to forbide 8byte write than fixing all possible linux apps.
What can be useful is a malloc function capable of allocating data in the GBA 'ROM' space. It can even hold the unlock functions for that matters (and calling them on the first call).
#125839 - Lazy1 - Tue Apr 17, 2007 1:53 pm
Well, it has been decided that the VM compiler will be a standalone application to keep the size down.
The VM itself is tiny, not even 10 instructions so that won't be a problem.
#125841 - Lick - Tue Apr 17, 2007 2:26 pm
Is it possible to check how much RAM is available, in software?
_________________
http://licklick.wordpress.com
#125842 - Lazy1 - Tue Apr 17, 2007 2:41 pm
If you mean with the library, getting the size of the device will be part of the API.
It's up to the driver developer to put the "size=" line in the script, without one it will not be compiled.
#125843 - Lick - Tue Apr 17, 2007 2:59 pm
Well I actually meant in software. But I guess it would require some dirty and raw measurement routines.
_________________
http://licklick.wordpress.com
#125854 - simonjhall - Tue Apr 17, 2007 4:19 pm
In Q2 to find the amount of RAM, after unlocking the memory (or at least attempting, anyway) I take a pointer to the head of extended memory and write a (16-bit) magic number and then read it back, just to check it's there. Once that fails, we're out of memory. Repeat, counting the amount of words written.
Don't forget to slap some 'volatile's in there!
_________________
Big thanks to everyone who donated for Quake2
#125957 - chishm - Wed Apr 18, 2007 2:48 pm
| simonjhall wrote: |
| If you're interested, I get about 15 megs/second writing with 32- and 16-bits to main memory and ~7 megs/second 16-bit writes, ~3 meg/second 32-bit writes to the GBA bus. It doesn't seem to make a difference which card is plugged in. |
Are you sure about the GBA bus figures? I would have thought that 32-bit accesses would be faster when transfering the same amount of data due to sequential accesses.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com