gbadev.org forum archive

Download

This is a library that eases the initialization and usage of the External RAM that is available on some Slot-2 devices.
Currently supported are:

Supercard (32MB)
M3 (32MB)
Opera (8MB)
EZ3/4/3-in-1 (8-16MB)
G6 (32MB)

RAM API 1.2r
ram_api_1.2r.zip (5KB) -
- Relicensed under MIT and GPLv2.
- Updated loadnds.bin (= Chishm's load.bin).

RAM API 1.2
ram_api_1.2.zip (3KB) - contains ram.h, ram.c and readme.txt
- Fixed EZ detection & RAM+FAT 100%. Thanks to DSLinux developers.
- Removed Turbo, because it caused EZ to fail.
- By the way, my EZ device apparently works with the EZsd_alt DLDI. It's not broken. =)

RAM API 1.1
ram_api_1.1.zip (3KB) - contains ram.h, ram.c and readme.txt
- Fixed EZ detection.
- Warning: EZ unlocking/locking is still buggy!
- Added functions to retrieve the detected devicetype.

RAM API 1.0
ram_1.0.zip (3KB) - contains ram.h, ram.c and readme.txt
ram_test.zip (82KB) - contains a project that tests the ram and libfat. Might need DLDI patch.

License

Quote:

Copyright 2007 Rick "Lick" Wong

Credits to: Chishm, Lazy1, Cory1492, Viruseb, Amadeus, Pepsiman

Feel free to use and redistribute my library freely, as long as you
a) credit me for this library and
b) publish all your modifications to this library (if any are made) and
c) do not create any damaging software with this library.

Heck! There are a lot of names up there! That's because most of the unlocking sequences were copied from or possible thanks to many developers. I only collected them into an easy-to-use library.

API Reference

bool ram_init (RAM_TYPE type) - type of the device. You can use UNKNOWN_RAM to auto-detect. This function tests the device for RAM and returns true when it's available.

Code:

UNKNOWN_RAM, SC_RAM, M3_RAM, OPERA_RAM, G6_RAM, EZ_RAM

RAM_TYPE ram_type () - returns the current devicetype.

const char* ram_type_string () - returns the current devicetype in a string.

u32 ram_size () - returns the total amount of RAM, in bytes. This is pre-calculated in ram_init().

u16* ram_unlock () - prepares the RAM for access and returns a 16-bit pointer to the RAM. Note: 8-bit writes fail.

void ram_lock () - always lock the RAM after you accessed it to avoid conflict with libfat.

Example

Code:

#include "ram.h"

if(ram_init (UNKNOWN_RAM))
{
iprintf ("RAM: %u bytes", ram_size ());

// unlock ram, and get a pointer to it
vu16 *ram = ram_unlock ();

// 16-bit writes
ram[0] = 0xDEAD;
ram[1] = 0xBEEF;

// always lock
ram_lock ();
}

Check the example project for more!

Known issues

Possible conflicts with libfat - Although the ram_test runs fine on my SCminiSD, it might fail due to a conflict between RAM access and libfat. Remember to always pair unlocks with locks.Please report failures as soon as possible!

EZ4 fails at second transition from ram to fat: fat->ram->fat->ram->fat=break. update This could be a timing problem, as the EZ bankswitching may be slower. Need to test this later.

External RAM is SLOW! - Only use external RAM if you really need to. It is much slower than on-board memory, although there are ways to speed it up. Thanks sgstair for telling me about this.
_________________
http://licklick.wordpress.com

Last edited by Lick on Mon Sep 24, 2007 10:53 am; edited 12 times in total

Ooh, you got a 'ram base' function? On the ezflash 5 the base of memory (I'm 95% sure) isn't the same as the memory base of the supercard ram.

Either way I'll be stealing this for Quake...
_________________
Big thanks to everyone who donated for Quake2

ram_unlock() internally calls a function-pointer that is set to the current device's unlock-function, for example _sc_unlock().
So it's up to that function to return the correct location. _sc_unlock() returns 0x8000000 and _opera_unlock() returns 0x9000000. Just to give two examples.

I *could* think of situations where this could break, but these locations are pretty much the same for each card of the same brand.

Steal (and test) it as much as you want! =)
_________________
http://licklick.wordpress.com

Very nice!

A minor suggestion: Constants should be named RAM_EZ etc to be consistent with functions.

Nuts. I should really have read it properly first!
On my SC (with MY code) the testing/finding of memory is pretty slow. Walking 32 megs takes many seconds, and gets annoying when you're endlessly testing and rebooting a piece of code. Reckon you could have some flag or something in the ram init function prototype which would allow you to test (say) every eighth word to make it run quicker?
_________________
Big thanks to everyone who donated for Quake2

Sunray: true! But I really don't want to change it right now (hassle hassle). I'll take it with me for a future update.

simonjhall: the size is measured within a blink, 'cause I test-write only every 1024 bytes. You gotta take a look at the source now, hehe.
_________________
http://licklick.wordpress.com

Awesome-o.
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Awesome-o.

Thanks. (1000th post ;)
_________________
http://licklick.wordpress.com

Actually then, so what IS the score with unlock codes overwriting real data? Eg the ez unlock and lock functions write data into 0x9000000 range, where the extended memory actually lives...
_________________
Big thanks to everyone who donated for Quake2

when i use this on my supercard sd am i allowed to use this function to use the opera browser on my supercard?

By "use the Opera browser on your SuperCard" do you mean with the authentic Nintendo DS Browser card in SLOT-1 and the SuperCard instead of the official Expansion Pak in SLOT-2? That's nothing that Nitro Hax can't fix once someone makes the appropriate code.
_________________
Driven from Tilwick by ice storms, couldn't fit in in Flower Bud...

Nintendo DS: With two ARMs, who needs legs?

Eddy 912 wrote:

when i use this on my supercard sd am i allowed to use this function to use the opera browser on my supercard?

NO BACKUPS/WAREZ!

(Always wanted to say that)

simonjhall wrote:

Actually then, so what IS the score with unlock codes overwriting real data? Eg the ez unlock and lock functions write data into 0x9000000 range, where the extended memory actually lives...

If you really want to be safe, I recommend using libfat to detect the device, then passing it along in ram_init() to skip autodetection.

I am not really sure about the writability of that area. But AFAIK, libfat doesn't care about that either, as it calls all kinds of drivers in search for the right one. (At least, if DLDI wasn't found first.)
Good question, anyway.
_________________
http://licklick.wordpress.com

Hmm, but if you use a different fat device to your RAM device (like I do) then that won't work... Maybe you can store (in you RAM library) the contents of the unlock addresses before you write to them, and then when you do the unlock code you write the data back in...

This is gonna need some testing!
_________________
Big thanks to everyone who donated for Quake2

Wait a second, let's re-examine the detection procedure:
1) Unlock
2) Write value
3) Test written value

The interesting thing is that if the value is not written, the device is not detected. Can we conclude from this that the unlock sequence also didn't write?
_________________
http://licklick.wordpress.com

I think dldi have to be modified somehow to work fine with your RAM lib.
For instance when reading a file the buffer can be in gba rom space and the result will be rather impreditible (on V.019 G6 it won't work I'm sure of it). This kind of thing can append in dslinux when the kernel wants to load an exec into gba rom space. More likely du to its fairly big size the extented ram space will be used to hold textures, levels,... that come directly from files (simonjhall can maybe tell us more about it).
Secondly Unlocking and Locking the memory each time you want to use the ram is not very convenient and a big source of bugs. I propose that the normal state is unlocked ram and it's the dldi work to take care of locking the ram and leaving with a unlocked ram.
With thoses modifications the extended ram will look much more like the main ram exepted for its speed and the 8bit write problem. More importantly it will remove some tarpits that may burden devs who want to use the extended ram.

viruseb wrote:

I think dldi have to be modified somehow to work fine with your RAM lib.
For instance when reading a file the buffer can be in gba rom space and the result will be rather impreditible (on V.019 G6 it won't work I'm sure of it). This kind of thing can append in dslinux when the kernel wants to load an exec into gba rom space. More likely du to its fairly big size the extented ram space will be used to hold textures, levels,... that come directly from files (simonjhall can maybe tell us more about it).
Secondly Unlocking and Locking the memory each time you want to use the ram is not very convenient and a big source of bugs. I propose that the normal state is unlocked ram and it's the dldi work to take care of locking the ram and leaving with a unlocked ram.
With thoses modifications the extended ram will look much more like the main ram exepted for its speed and the 8bit write problem. More importantly it will remove some tarpits that may burden devs who want to use the extended ram.

Interesting angle, but there is one issue I have with it. It assumes that one will be using a RAM-enabled device with DLDI, which is not an assumption you should be making. Also, it means you have to integrate DLDI and RAMlib stuff, which is tricky.

For example...

I use my SC:mSD with RAM-DLDI, cool. Works nice. DLDI handles locking, unlocking in during fwrites, etc, etc.

But...

I use my R4 with RAM-DLDI. Two scenarios. I have my SC in SLOT-2, or I don't. So, what happens. RAM-DLDI trys to lock/unlock and I may not have a RAM device in slot 2. Could cause problems.

The idea does have merit, but seems to be heading back into the OS-solution territory, as otherwise it involves strongly linking the RAM lib and libfat DLDI code, which is possibly problematic...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

OOPMan wrote:

Interesting angle, but there is one issue I have with it. It assumes that one will be using a RAM-enabled device with DLDI, which is not an assumption you should be making. Also, it means you have to integrate DLDI and RAMlib stuff, which is tricky.

For example...

I use my SC:mSD with RAM-DLDI, cool. Works nice. DLDI handles locking, unlocking in during fwrites, etc, etc.

But...

I use my R4 with RAM-DLDI. Two scenarios. I have my SC in SLOT-2, or I don't. So, what happens. RAM-DLDI trys to lock/unlock and I may not have a RAM device in slot 2. Could cause problems.

The idea does have merit, but seems to be heading back into the OS-solution territory, as otherwise it involves strongly linking the RAM lib and libfat DLDI code, which is possibly problematic...

In fact I wanted that dldi functions for devices that have a memory expansion assume that the memory is unlocked when called and leave with the memory unlocked. And also that ram_init leaves with _unlock() rather than _lock(). I'm not saying that ALL dldi have to call _lock() and _unlock(), only those with an memory expansion and those won't, of course, include ram.h but just theirs respective _xx_lock and _xx_unlock functions. It's about making dldi compatible with the RAM lib, you still have to call ram_init at the beginning of your program.

For your example you have a homebrew patched with R4 dldi and using RAM lib. The homebrew calls ram_init which return saying you have an memory expansion (thanks to your sc in slot-2) and unlock the ram. When using fsomething() libfat calls R4 dldi functions which doesn't try to lock/unlock the memory because R4 is a slot1 device and doesn't care about memory expensions.

This lead to an another issue. You still have your R4 dldi patched homebrews and an SC in slot 2. If the default behavior is locked ram each time you want to read a file with a buffer in gba rom space you have to do something like this

Code:

_unlock();
fwhatever(bufferingbaspace,...):
_lock();

Cumbersome isn't it ?

I fact I just want that devs doesn't waste their time thinking : "do I unlock the ram already ? or maybe not ? Is my buffer in gba space ?".
Assuming an unlocked ram and modifying the 5 dldi for devices that have memory expansion can solve those issues, neatly.

EDIT : all this thinking remind me that writing and reading using lifbat is cached and the cache is in ds ram space so no issue but I'd like to have chishm opinion.
EDIT2 : After digging into libfat code caching will not solve the issue for reading. Because cache handling code still have to move data from cache to gba rom space and if dldi leaves with a locked ram that's could be a problem.

Last edited by viruseb on Fri Apr 20, 2007 9:40 am; edited 3 times in total

You *could* move the unlock-lock into the fwhatever(bufferingbaspace,...)-function. It's not like the performance hit would be severe. (Most of the time will be spent accessing the slow RAM, not unlocking it)
_________________
http://licklick.wordpress.com

If it was included in the file-handling stuff itself, in a sequence such as this:
fopen
fseek
fread
fclose
you're gonna be locking and unlocking it over and over again. Yeah, I guess the hit isn't too high - but you still shouldn't be doing it!

I normally wrap all my file functions with the unlock and lock stuff anyway. Plus as you might want file access stuff to be thread-safe, you'd add all that hoo-ha in there too. Also, if you wanted the ARM7 to be able to use the memory (by default) you'd have to make a call at the end of the file access sequence anyway, so you may as well put the unlock there too...
_________________
Big thanks to everyone who donated for Quake2

Agreed, but what is better modifying libfat (and waiting devkitARM R21 for its releasing) and adding a unlock/lock sequence each time you want to do something in gba rom space for every homebrews that want to use extended ram (it's not about the performance thing but more thinking about it each time) OR modifying 4 dldi (well 3 cause I will do the G6 one of course) ?

Am-I partial ? nooo :)

Anyway, how does the test project (first post, second link) run on the other devices? It does a few transitions so it might be smart to test that first, before talking about libfat. Cause if it fails, there's no point integrating with libfat.

So far: SCSD works, EZ4 fails.
_________________
http://licklick.wordpress.com

Lick wrote:

Anyway, how does the test project (first post, second link) run on the other devices? It does a few transitions so it might be smart to test that first, before talking about libfat. Cause if it fails, there's no point integrating with libfat.

So far: SCSD works, EZ4 fails.

You're right, back to testing.... working on G6 !

viruseb wrote:

You're right, back to testing.... working on G6 !

Huh? Did you run the test on the G6?
_________________
http://licklick.wordpress.com

Lick wrote:

viruseb wrote:

You're right, back to testing.... working on G6 !

Huh? Did you run the test on the G6?

I didn't see that my sentence may have an another meaning :)
I've tested your test apps on my G6 and it is working. Congrats !

[quote="viruseb"]

OOPMan wrote:

I fact I just want that devs doesn't waste their time thinking : "do I unlock the ram already ? or maybe not ? Is my buffer in gba space ?".
Assuming an unlocked ram and modifying the 5 dldi for devices that have memory expansion can solve those issues, neatly.

You missed a HUUUUUUUUUUGE point I made dude...

Let me say it again...

It's not just 5 DLDI's that would need modding...

You'd need to produce 2 DLDIs for EVERY SLOT-1 device, a RAM-DLDI and a normal DLDI.

And you'd need to patch your stuff depending on what you want to use.

This is NOT just a minor problem. It's an a bloody great big schlep.

Because accidentaly running a SLOT-1 RAM-DLDIed file w/o the the RAM device in the slot could be a problem, as I'm sure you can see....

Gah, sorry, if I came across a bit harsh, but I just don't see integrating DLDI + RAM to be a good idea, as it makes all kinds of assumptions that are dangerous in the DKA environment.

The alternative, the current system is fine IMHO, as long as you program carefully (Something you should already be doing if you've done any multi-threaded coding and hence known that it's dangerous to make assumptions about system resources...)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

OOPMan wrote:

You missed a HUUUUUUUUUUGE point I made dude...

Let me say it again...

It's not just 5 DLDI's that would need modding...

You'd need to produce 2 DLDIs for EVERY SLOT-1 device, a RAM-DLDI and a normal DLDI.

And you'd need to patch your stuff depending on what you want to use.

No you don't. I think I didn't made myself sufficently clear. Let me explain again.

You mod the dldi for device with memory expansion (namely G6
, EZ4, Supercard, M3) so that theirs functions lock the ram when called and unlock it when leaving. And you change the behavior of ram_init so that it leave the ram unlocked.

case1 : you have an G6 dldi patched homebrew and an G6 inside your DS. The homebrew calls init_ram() and knows it can use 32Mo. As the dldi is modded there is no issue to call fat functions and worrying about the state of the ram.

case2a : your have a R4 dldi patched homebrew (remark that the dldi file is not modded for ram whatsoever it's the same that I can dl now in Chishm homepage) that also uses a lot of memory and likes to use memory expansion. In your slot 2 you add a G6 or whatever with memory expansion. The homebrew calls init_ram() which discovers that there is indeed a memory expansion and leave it unlocked. When calling fat functions the R4 dldi doesn't have to worry about ram locking/unlocking it simply retrieve/store data into ram space cause it's already unlocked thanks to init_ram().

case2b: same homebrew than 2a but this time there is no memory expansion present in slot2. The homebrew calls init_ram() which discovers that there is no memory expansion. After it is a matter of how homebrew should react (stoping with a error message, working with reduced capability with a warning message...)

As you can see there is no need to mod ALL dldi file nor making 2 versions of a dldi. (if I'm mistaken I really need more coffee).
Anyway I wrote this to be understood not to hammer again and again that my solutions is better or whatsoever. But without peoples willing to mod and test dldi it is a dead end.

BTW into what extend do you think slot-1 dldi shold be modded ? Because I don't see any reasons they should be.

Oh dear...

Sorry...

I think I had my brain switched off...

I totally forgot that a slot-1 device doesn't need to worry about the memory being locked or unlocked, since it writes/reads to/from slot-1...

Doh :-)

My bad...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Lick wrote:

Anyway, how does the test project (first post, second link) run on the other devices? It does a few transitions so it might be smart to test that first, before talking about libfat. Cause if it fails, there's no point integrating with libfat.

So far: SCSD works, EZ4 fails.

Supercard Lite/SCLT:

Code:

fat_init done
ram_init done : 33554432
test: 20 40 60 80 100
lock ram

fat done

unlock ram
test: 20 40 60 80 100
lock ram

fat done

Seems to work :) .

Yes, Supercard seems to switch fine between RAM and Media (fat). Thanks for testing on the Lite NorQue!
_________________
http://licklick.wordpress.com

OOPMan wrote:

Oh dear...
Sorry...
I think I had my brain switched off...
I totally forgot that a slot-1 device doesn't need to worry about the memory being locked or unlocked, since it writes/reads to/from slot-1...
Doh :-)
My bad...

No problem. This can happen even to the best of us ;)

This is weird. On an EZ4 the Supercard RAM is detected. (I added ram_type().) It seems like the EZ4 passes all detections, because it's completely writable? In that case, I'll set it as the first detection attempt.

Update I fixed the EZ4 code entirely. It now unlocks and locks the RAM like it should. It doesn't even conflict with libfat anymore! However, I have decided not to add 32MB support. Only the Deluxe card has 32MB of PSRAM but it requires some nasty switching to access it fully, because the memory range is only 16MB in size (0x8400000-0x9400000).

Update It randomly works. I think I broke my card.
_________________
http://licklick.wordpress.com

Last edited by Lick on Sun Apr 22, 2007 4:42 am; edited 1 time in total

Great work Lick!

i'm rooting for you XD

I released RAM API 1.1. However, the EZ driver does not fully work (for me at least).
_________________
http://licklick.wordpress.com

Hi Lick - I've been having a bit of a problem with the RAM unlocking API.
I'm using a Supercard miniSD and in the RAM init function I put UNKNOWN_RAM as the memory type. It works cool etc (check the vid in the other thread!) but if I then power on the DS again within ~30 seconds it'll detect the card as 'EZ'...
Have you seen this before?
The only convenient way to get round this is to hard-code it as SC_RAM...

Other than that, well done on the lib - dead useful :-D
_________________
Big thanks to everyone who donated for Quake2

I ran into the same thing. My SC Lite was identified as an EZ when the wifiloader I use left it unlocked.

Seems the lib simply tries all its drivers in sequence, and picks the first that "seems" to enable RAM writes. Since ram_init() also attempts to lock the card, I modified the detection to check that this actually worked, and now it finds my SC every time.

I do have one request, is it too hard to preserve the RAM? Most of my code is transferred to slot2 with wifiloader, which squirrels itself away at the end, so I can restart it to fetch/save/run a new binary. Writing blindly at the RAM breaks that. (I had fixed my older code to detect an SC, at least, without any destruction.)

Cydrak: would you mind posting the modification? Thanks! Oh you mean like LOCKING it. I see, smart move. I will add this to the next release under your name. =)

The RAM will be preserved ~30 seconds on some cards, others don't even do this.

This test program here seems to work fine on my M3 miniSD.
_________________
----
Now 10% more Old Man from Zelda 1 than ever before!

Yeah, basically you have to check for an actual change in state; just the fact the RAM is taking writes doesn't tell you anything about the card. :)

Here's my copy: http://draci.chaosnet.org/code/lickram/ (not well tested, beware)

The only change is in ram_init, where after _*_lock(), it then tries to change what it wrote, and only uses the current driver if that fails. Actually, now that I think of it, this will break (at least how I wrote it) on cards that -unmap- the RAM. On my SC I believe half is still readable, so more tinkering is required...

I meant to ask was if ram_init() itself could preserve the contents while it's doing its detection thing. I'm not powering off or anything, it's just a soft reset. Or do you mean that the RAM actually decays when you lock it? Ouch!

Anyway, I'm keeping it unlocked mostly, except to do FAT stuff (which still hangs on me sometimes, even though I lock it, gotta figure that one out..).

Good luck! The RAM will be mightily useful, so it's nice to have a tested library rather than scrabbling for code snippets and hoping they don't just work on your card...

I haven't found a way to identify the RAM without writing to it, so content-preserving is pretty much an impossibility.

The RAM only "decays" when you power it off. Some cards have built-in batteries that keep the RAM going for another umphty seconds before it "really powers off". And it's generally better to lock it when you're done with it.

I am not really convinced that the detectionprocedure will be perfect. The best way to do this is to let the user patch it (like DLDI). It's being worked on, but not by me. Hopefully that solution will give a more consistent RAM environment than this RAM API. (Bummer, but the truth is that homebrew devices are too inconsistent.)

I will use your "check if changed state" method in the next release! That's the best detection we can do, I guess.

Maybe the best way is to patch the program with a driver, like DLDI.

Lick wrote:

I haven't found a way to identify the RAM without writing to it, so content-preserving is pretty much an impossibility.

Leave some data at the beginning/end of it when loading another .nds?
_________________
I'm a PSP hacker now, but I still <3 DS.

nice release, great idea! so would it be possible to, for us peeps with GBAMP, to take it out while booting and add in the Opera cart? this can be used for more graphically entensive games!

*goes off to make awesome 3D game*
_________________
Development Blog: http://teendev.org
Homebrew Podcast: http://homebrewcast.net
Web Design: http://xtendesign.net

HyperHacker: I think he meant like not writing to the RAM to detect if it's writable. To which I replied that it was probably impossible (because manufacturers don't provide the registers that could help identifying the RAM).

tondopie: I haven't tried, but it could be possible to call ram_init() AFTER the user inserted some RAM device, like Opera. However, you have to keep in mind that accessing FAT afterwards will be extremely brain-damaging. I would recommend Slot-1=FAT, Slot-2=RAM.
_________________
http://licklick.wordpress.com

yeah I fiqured have a confirmation after launching the program to int RAM access, like "Press A to continue" or something.
_________________
Development Blog: http://teendev.org
Homebrew Podcast: http://homebrewcast.net
Web Design: http://xtendesign.net

Are there any updates on this one?

Quote:

External RAM is SLOW! - Only use external RAM if you really need to. It is much slower than on-board memory, although there are ways to speed it up. Thanks sgstair for telling me about this.

How slow is external ram? What are the ways to speed it up?
Does anybody have a decent workaround for 8 bit writes?

All I know is that my Supercard's RAM is too slow for many commercial GBA games to play correctly, and that the M3 has faster RAM therefore better GBA ROM compatibility. Not that I've experienced these first hand though ;)
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

Well it's slower than the Main Memory, but if you need extra RAM then just use it. Worry about it when you're software's functionality is written and complete.

By the way, 1.1 which is linked in the first post, has a function that enables Turbo mode. This potentially doesn't work on all devices, but the devices I've worked with all became faster.
Also, with future DevKitARMs hopefully we can add the GBA area to the ARM9 cache. I've done tests on it was logically just as fast as the cached Main RAM. This isn't something that should be used lightly though, until there's a stable way of enabling it.

For now, just don't worry about speed.
_________________
http://licklick.wordpress.com

Yo, I care about speed!
I remember talking to you a while ago about this - is the turbo mode what you get when you adjust the memory wait states?
Also, do you have the code to enable/disable (and flush) the caching of the GBA slot in the lib, or would I have to set that up myself?

And re: the old 8-bit write problem, I seem to remember someone talking about using the data cache writeback to fix this problem. You turn on the '9's write cache, do strbs etc and when the cache gets written back it is done so with 16-bit quantites... (ie, without error).
I've not personally tested this though - when I use slot-2 memory I do everything with 16-bit writes, or add in read-modify-writes wherever there was a strb...
_________________
Big thanks to everyone who donated for Quake2

I just modified desmume to log 8-bit writes to the console then immediately exit.
Then arm-eabi-addr2line is used to locate the problem code which can be modified into a 16-bit write.

Dood77 wrote:

All I know is that my Supercard's RAM is too slow for many commercial GBA games to play correctly, and that the M3 has faster RAM therefore better GBA ROM compatibility. Not that I've experienced these first hand though ;)

Surely the ez4 and g6 have better suited ram then too.

The problem isn't so much the speed of the RAM, it's the speed of the bus. It's just not fast.
_________________
Big thanks to everyone who donated for Quake2

Then enable caching on the GBA BUS, WinterMute on IRC provided the code to me which I used in Mini vMac.
The speed difference vs main ram is only about 3-5 FPS after that.

Is it possible to ever see the ability to use Libfat to read from disk to cartridge ram?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

You can read data from libfat into GBA RAM, it goes something like this:

Switch to I/O mode
Loop
---Are there bytes left to copy?
------Read x bytes into main RAM buffer
------Switch to RAM mode
------Copy x bytes into GBA RAM buffer

---Switch to I/O mode
End Loop

This is from memory, may not be 100% accurate.

Unfortunately that ^^^ does not work on EZ devices. It does work on Supercards, M3s G6s and stuff. What ALWAYS works is Slot-1 FAT to Slot-2 RAM, but that's logical.
_________________
http://licklick.wordpress.com

Simon: yes, it eliminates the 8 bit restriction because you're basically writing to the cache and then letting the PU write to the bus. And like Lazy1 said, caching speeds up the regular access by a lot. Though currently it requires you to modify the toolchain or do some hackery, which the higher elite elves rather have you not.
_________________
http://licklick.wordpress.com

Quote:

Then enable caching on the GBA BUS, WinterMute on IRC provided the code to me which I used in Mini vMac.
The speed difference vs main ram is only about 3-5 FPS after that.

Emm, not knowing how much FPS is tops, and how often you use memory etc, its hard to guess what that means.

I've been pondering about the whole 8bit write issue. I was thinking that (asm) code that writes to external ram in 8bit quantities could call PLD for that address and thus perform a linefetch. if the cache is set up to WB (see below), then the 8bit write goes into cache, and when the cache is flushed it does so with word writes. (too bad there is not much information of pld out there, but i believe that if one runs code from dtcm, then linefetch happens during execution). On a side note, one could probably put most code in itcm and set up a unified cache. I think then one would essentially have the DCache + ICache as the actual cache, which'd be 12KB instead of 4KB DCache (correct me if i'm wrong).

from the arm9 tech rerence:

Quote:

WB
Searches the DCahce fore reads and writes. Reads that miss in the DCache cause a line fill. Reads that hit in the DCache do not perform an external access. Writes that miss in the DCache are buffered. Writes that hit in the DCache update the cache line, mark it as dirty, and do not send the data to the write buffer. DCache write-backs are buffered. Writes (write-miss and write-back) cannot be externally aborted. DCache linefills cause the write buffer to drain before the linefill starts.

...
One could possibly setup a cache in some fast ram oneself, maybe with some protection region and memory mirrors trick. Does anybody have some experience with this? (too bad there are only 8 protection regions that have to be at least 4kb of size)

Lick wrote:

Simon: yes, it eliminates the 8 bit restriction because you're basically writing to the cache and then letting the PU write to the bus. And like Lazy1 said, caching speeds up the regular access by a lot. Though currently it requires you to modify the toolchain or do some hackery, which the higher elite elves rather have you not.

as noted above, if the address you perform an 8bit write to is not in DCache, then it's written to the bus. so that'd still be bad. one would have to make sure that that address sits in the cache (i.e. with pld).

How about this caching idea:
- set up the dtcm to cover the lower 32MB (with mirrors) and protect it with the PU.
- use 4 4KB regions as a direct mapped cache. That is, if a region is supossed to be in cache, load it into the dtcm. The mirroring will ensure that direct mapping works. then put a protection region over it to make it readable.
- now use the external memory, but pretend its at 0x0, where the external memory is cached.
- if a data abort occurs, it means there was a cache miss. do a write back of the region currently in the dtcm that uses the adressed spot, and then load the latter region from external ram.

This would also work with shared ram, here 8 regions are possible. Since there are only 5 protection regions available (3 already in use), the 3 last recenly used cache regions can not be accessed without a data abort, despite being in ram.

Lick, a bunch of questions:
a) so is there a way to enable/disable/flush data caching for the gba slot in the library - or should I roll my own bit of code?
b) the version of the library I have (from a few months ago) doesn't seem to work on my EZ-flash 3-in-1 - will it work now?
c) how do you reckon I could test to see if the higher wait states are cool on a given flash card? It takes quite some time to walk the 32 megs of RAM on my Supercard so writing/reading a magic number until it breaks could take some time!
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

c) how do you reckon I could test to see if the higher wait states are cool on a given flash card? It takes quite some time to walk the 32 megs of RAM on my Supercard so writing/reading a magic number until it breaks could take some time!

The last time we had a discussion about overclocking RAM, it was about an undocumented register in the GBA that could reduce the EWRAM wait state from 2/2 cycles to 1/1 cycle. In that topic (which I don't feel ready to dig up because forum.gbadev.org blocks Google and phpBB 2.x built-in search is inadequate), someone stated that the stability of faster wait states will vary based on the temperature inside the chip, so you might want to make a program that runs for up to an hour at a time.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

simonjhall wrote:

Lick, a bunch of questions:
a) so is there a way to enable/disable/flush data caching for the gba slot in the library - or should I roll my own bit of code?
b) the version of the library I have (from a few months ago) doesn't seem to work on my EZ-flash 3-in-1 - will it work now?
c) how do you reckon I could test to see if the higher wait states are cool on a given flash card? It takes quite some time to walk the 32 megs of RAM on my Supercard so writing/reading a magic number until it breaks could take some time!

a. You'd have to dig up the linker script in your current toolchain, see which PU region covers the GBA bus. You'd want that region to be at least 32MB and enable the datacache-bit for that region (and also the writebuffer and daccess I think). It's quite a stupid hack. I had it working but I lost the code.
b. Nope, and I hate EZ devices now.
c. I don't know. If I knew then I'd have automated it in the RAM API. I suggest not worrying about it.
_________________
http://licklick.wordpress.com

Lick wrote:

b. Nope, and I hate EZ devices now.

Mind if I ask why?

I wasted many hours trying to get the FAT -> RAM -> FAT transition to work but somehow it always failed after a few transitions. At some point I managed to screw up my device so badly that it doesn't initialize FAT anymore, at all. Yes, I was able to break it.
_________________
http://licklick.wordpress.com

0_0 bummer

don't drop support for ez4 at least :P

anyone have any sample code for using this?

I see the test code, but not really sure if I am understanding what I need to do to add this to my code.

for example I have a large array that i would like to put into the extra RAM, right now the code has this.

unsigned char* brickTable[9000];

and then it uses malloc for each brickTable entry, which uses about 3.8mb of space.

and reads from FAT into each entry.

Do I just use brickTable as my variable that I unlock? and everytime that I use brickTable do I use the lock and unlock ?

Thanks,
Troy

so has anyone used this code yet?

Do I have to setup my own memory allocator to use with the extra memory?

Thanks,
Troy(GPF)

I've been using it for a while. I use it like this: (off the top of my head - I'm at work)

Code:

#include "ram.h"
if (ram_init(SC_RAM) == false)
error("couldn\'t init memory);

void *base_addr = ram_unlock();
unsigned int memory_size = ram_size();

printf ("memory starts at %08x, length %d bytes\n", base_addr, memory_size);

<do stuff with base_addr pointer - this is the lowest word address of the memory of the card in slot-2>

<I now wanna do something with files, so>
ram_lock();

fopen();
fread();
fclose();

<now we want to use slot-2 ram again>

ram_unlock();

<do more stuff with slot-2 ram>

The reason I force the card to be a supercard (SC_RAM) rather than use the auto detection is if I power cycle my DS too fast, my supercard is always detected as an ez-flash (which has a different base address).

Also remember that when you wanna do stuff with the file system on the slot-2 card you must call ram_lock() to switch back to file-access mode. However if you're using a fat device in slot-1 and the memory in slot-2 you won't need to do this ram lock/unlock step.

And yes, you need to do your own memory allocation. For Quake2, I use a slightly-modified version of this: http://gee.cs.oswego.edu/dl/html/malloc.html
I seem to remember that this is the OpenBSD memory allocator...but I can't remember ;-)
_________________
Big thanks to everyone who donated for Quake2

ram_size() can be called directly after ram_init(), because the size detection is done in there. Basically it's like this:

Code:

if (!ram_init(...)) return;

int bytes = ram_size();

// use RAM:
u16 *ptr = ram_unlock();
ptr[0] = 0xFFFF;
ram_lock(); // lock after using

_________________
http://licklick.wordpress.com

Okay I retract my previous sayings about EZ devices. It seems that my EZ4Lite Deluxe is NOT broken. Libfat initializes successfully with the EZSD_alt DLDI written by Moonlight (or cory?).

I decided to take a look at the DSLinux side of the RAM research and it seems they have a working detection system for EZ and they found out that the EZ unlock and lock functions are supposed to be void. EZ doesn't require those, apparently.

So I added their procedures to RAM API, now 1.2. I guess it's safe to say that RAM API works along side Libfat nicely now, even on Slot-2 devices.

Also removed Turbo-mode, because it seems to cause failures on the EZ devices.
_________________
http://licklick.wordpress.com

Any idea why my SC is miss-detected as an EZ-flash if I power cycle my DS too fast? Has that been fixed now?
_________________
Big thanks to everyone who donated for Quake2

Well, my previous EZ detection procedure was pretty lame. I can't say for sure, it would help if you tested the new release. =)
_________________
http://licklick.wordpress.com

Hi Lick, just bit of feedback re: ye ol' ram lib in QDS.

Supercard miniSD - detected fine (haven't tried new lib enough to see if it's occasionally detected as EZ), plays fine, 32 megs detected using my algorithm
M3 lite - detected fine, plays fine (speed seems the same as the SC), 32 megs (I think)
EZ 3-in-1 - detected fine, game crashes when using 16 megs of memory however is fine with 8 (I'll have a look), 16 megs detected
Opera - not detected, however works fine when manually told which card, plays fine, 8 meg detected

...and this is all without any fancy turbo/caching code. This is a pretty good start ;-)

BTW I've personally own the SC and EZ but the M3 and Opera were tested via someone elses DS.

EDIT: just an EZ update, the game plays fine with 12MB, crashes with 13+. However if I shift the memory base up by as little as 256k (but still give 12MB to the game, it'll crash). Maybe I have a dodgy card...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

EDIT: just an EZ update, the game plays fine with 12MB, crashes with 13+. However if I shift the memory base up by as little as 256k (but still give 12MB to the game, it'll crash). Maybe I have a dodgy card...

Maybe someone should do a port of memtest86! >.<
memtestARM?
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

Seems the whole 12 meg thing was my fault ;-)
The full 16 megs works fine now on the EZ 3-in-1 RAM expansion. But still, Opera detection doesn't function correctly.
_________________
Big thanks to everyone who donated for Quake2

Whew. I was a little worried. I just ordered a R4 and EZ 3-in-1 a few days ago. XD

And you know, MemtestARM doesn't sound like a bad idea...
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3

But how would such a "memtestARM" program relocate itself to test the part of memory that its code occupies? Or would it suffice to just test as much memory as it can malloc(), as well as the part of RAM that the RAM Unlocking API gives? I'd almost do it myself, but the RAM Unlocking API's license appears incompatible with the GNU General Public License used by Memtest86+.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Is there ever going to be a gba version?

Lick where I find the file .nds? Doesn't the old link act http://lickr.org/files/exram.nds, can someone help me?

Lino: it's for developers. It won't be of any use to end-users.

Ant6n: nope, but the code is pretty straight-forward. The unlocksequences should work outside libnds.
_________________
http://licklick.wordpress.com

I am implementing the expansion ram on the emulator, please you can post the new link?

EDIT: ok, thanks I have resolved use dslinux.

Lino wrote:

I am implementing the expansion ram on the emulator, please you can post the new link?

EDIT: ok, thanks I have resolved use dslinux.

Awesome to hear Lino , looking forward to the new version of Ideas :)

Troy(GPF)
http://gpf.dcemu.co.uk

Can the arm7 access this? (seems like it could)
Can the dma controller access the extra ram?
Could you point a sound channel at the extra ram?

Would something like this work?
1) arm9 loads large sound data from fat, stores it in slot2 ram
2) arm9 releases slot2 ram, sends message to arm7
3) arm7 grabs slot2 ram and starts playing audio

If I remember correctly, the sound hardware cannot access slot-2.

40004x4h - ARM7 - SOUNDxSAD - Sound Channel X Data Source
Register (W) Bit0-26 Source Address
Bit27-31 Not used

It isn't big enough to hold 0x8000000. :(
_________________
http://licklick.wordpress.com

Would it be hard to just make a pair of 4 ksample ring buffers in main RAM and continuously copy audio into those?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

> It isn't big enough to hold 0x8000000. :(

Ah, ok.

> Would it be hard to just make a pair of 4 ksample ring buffers in main RAM and continuously copy audio into those?

Probably. I was hoping I could shove all the sound data off onto the arm7, and then have the arm9 forget about it. If I stream audio, the arm9 will need to pull data from the cart in sync with what the arm7 wants to play.

Anyway, thanks for the answers.

Lick's custom license is as follows:

Lick wrote:

Feel free to use and redistribute my library freely, as long as you
a) credit me for this library and
b) publish all your modifications to this library (if any are made) and
c) do not create any damaging software with this library.

I asked about the rationale behind this custom license in a previous topic. Lick's response was "Licenses are annoying, I'll just leave it as it is." To me, bugs in a license are at least as annoying as bugs in a program.

Lick: Is there a specific reason that you want us to publish all modifications to the library, even those modifications that we use only privately and do not distribute to the public in binary form?

How do you, the author of the license, define "damaging software"?

If this license is not clarified, a lot of developers will not be able to use libraries distributed under this license and will not be able to use features implemented only by libraries distributed under this license.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Hmm...I feel like butting in here... (I've been looking forward to this discussion!)

Why are you bothered about what license he chooses for his piece of software? He wrote it, he gets to choose which license to use. If he wants people to publish all modifications then so be it. Pushing someone to use an overly-complicated license (eg GPL and its derivatives) just because it's a favourite in the open source world isn't the way forward!
However, I do agree that the "no damages" clause is hazy, but I'm sure that even if this was solid people would still complain if their DS' were broken by the software.

Finally, if you were to rewrite your own version of the library with a different license then that would just be making noise and writing code for the sake of it. Time which would be better spent actually making a cool piece of homebrew...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

Why are you bothered about what license he chooses for his piece of software? He wrote it, he gets to choose which license to use. If he wants people to publish all modifications then so be it.

Because that limits the set of software that is allowed to link against his library. To use an example of a program you maintain, Quake cannot use it because Quake is under the GPL, and the license of this library introduces restrictions that the GPL does not allow.

Quote:

Pushing someone to use an overly-complicated license (eg GPL and its derivatives) just because it's a favourite in the open source world isn't the way forward!

Complicated? Not necessarily. My complaint about term b) would have been satisfied by rewriting it as follows: "b) if you distribute modified versions of this library in executable form, publish the source code of the modified library, and".

Quote:

Finally, if you were to rewrite your own version of the library with a different license then that would just be making noise and writing code for the sake of it.

Like the GNU project itself, which is a rewrite of UNIX?

Quote:

Time which would be better spent actually making a cool piece of homebrew...

Because making a cool piece of homebrew is impossible if one is trying to port a program whose license is incompatible with a given library.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Because making a cool piece of homebrew is impossible if one is trying to port a program whose license is incompatible with a given library.

Well there's technically nothing physically stopping you from using it however you please :-)
Plus since it seems the majority of projects that are started here are never finished, the license used would rarely affect any project!

<rant>
Tbh I see licenses right up there with software patents - nobody likes them, they never help you and generate vast amounts of duplication of effort / prevention of duplication. There are so many 'open source' projects out there which have had issues with incompatible licenses (eg minor details in the wording) and this always affects the end user.
</rant>

Using you example of my port of Quake - what can I do? I could distribute the game and its source*, but would I have to make the the RAM library module a separate installable module which would inform the user of broken licenses when they invoke it? That's only gonna make more work for me and add extra confusion (I get stupid enough emails as it is...I don't want more support mails!)

*my work contract says that everything I make (be it at work, work-related or not) is owned by them - I'm already walking a fine enough line as it is! Licenses are the least of my worries :-p
_________________
Big thanks to everyone who donated for Quake2

If you are a developer and want to use software written by others, you might want to be legal and obey the licenses of the software written by others. It is a lot better if this included software has a "standard" license, because then its compatibility with other licenses has been debated to death by people more knowledgeable in the legal field than you. The problem with arbitrary self written licenses is that other developers have to do this evaluation of the compatibility of licenses themselves. In addition, I believe most well thought licenses include a liability clause just in case someone wants to sue them over something related to the software.

But, of course, you may choose whatever license you want for your software, its your code, but people might be afraid to use it in their software because they are not really sure what you actually meant by the license and if it is compatible.

If you want to go open source, try first looking at GPL, LGPL or BSD to see if anyone of those licenses fits your needs, before coming up with a badly thought of license yourself.

Relicensed.
_________________
http://licklick.wordpress.com

Well done tepples, you got what you wanted. Now write something to use it.
EDIT: I'm sorry, that was rude - I take it back.
_________________
Big thanks to everyone who donated for Quake2

Last edited by simonjhall on Thu Sep 06, 2007 11:04 pm; edited 1 time in total

Lick wrote:

Relicensed.

Thanks a bunch. Now I can get to work on memtestARM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

does dual license imply you can use either license or must use both?

MIT == good

GPL == the suck
_________________
www.drunkencoders.com

dovoto wrote:

does dual license imply you can use either license or must use both?

either

Has anyone got the latest version to autodetect an EZ-Flash V 3-in-1 card? Or does it work only with earlier EZ-Flash cards?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

dovoto wrote:

does dual license imply you can use either license or must use both?

http://en.wikipedia.org/wiki/Dual_license

Quote:

MIT == good

GPL == the suck

That completely depends on the type of source code and what the intentions of the source code and its author are.
_________________
[project website] [personal website]

Download ram_api_1.3.zip (4KB)

It seems 1.2r was an old version. It contained old code for the EZ detection. This was already fixed in 1.2, but to avoid confusion and naming hell, here's 1.3 with the good EZ detection and new license.

By the way I didn't mention it but the dual-license idea came from here: http://code.jquery.com/jquery-latest.pack.js

Quote:

/*
* jQuery 1.2.1 - New Wave Javascript
*
* Copyright (c) 2007 John Resig (jquery.com)
* Dual licensed under the MIT (MIT-LICENSE.txt)
* and GPL (GPL-LICENSE.txt) licenses.
*
* $Date: 2007-09-16 23:42:06 -0400 (Sun, 16 Sep 2007) $
* $Rev: 3353 $
*/

_________________
http://licklick.wordpress.com

One question we've had is: what happens if an interrupts occurs during the unlock/lock code? Will it still work, or does the flash card expect these commands to come on successive clock cycles?

Also we've noticed that if a dldi driver uses dma (I think it's the m3sd_alt one I'm thinking of) you can occasionally get wonkiness after fread if the card is turned back to RAM mode too soon after a read. So those folks who are using slot-2 RAM - watch out!

Finally: one weird thing I can't explain is if using my Supercard RAM (and FAT files coming from that file too) I can do fopen with the filename string living in the RAM I just disabled. However if the same fopen is run with the M3 it baulks at the filename pointer to a now-dead bit of memory! Yeah it's a mistake on my part, but I still can't explain why it works on one card but not the other! And yes, I'm flushing the data caches like a madman :-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

One question we've had is: what happens if an interrupts occurs during the unlock/lock code? Will it still work, or does the flash card expect these commands to come on successive clock cycles?

I've got no idea.

Quote:

Also we've noticed that if a dldi driver uses dma (I think it's the m3sd_alt one I'm thinking of) you can occasionally get wonkiness after fread if the card is turned back to RAM mode too soon after a read. So those folks who are using slot-2 RAM - watch out!

Good tip!

Quote:

Finally: one weird thing I can't explain is if using my Supercard RAM (and FAT files coming from that file too) I can do fopen with the filename string living in the RAM I just disabled. However if the same fopen is run with the M3 it baulks at the filename pointer to a now-dead bit of memory! Yeah it's a mistake on my part, but I still can't explain why it works on one card but not the other! And yes, I'm flushing the data caches like a madman :-)

I believe it depends on the DLDI. Or the hardware.
_________________
http://licklick.wordpress.com

I wondered about interrupts during locking and i/o too... for example, I noticed my mp3 streaming is fine with unexpected sleep events--but is that because the card's happy, is it by chance, or is it the sync code recovering? I could've sworn it glitched up before. Hrrrr... just another thing to test...

Since I try to avoid disruptive IRQs, I never looked into it. :/ Is there a preferable wiki with a place for obscurities and test cases like this?

http://www.dslinux.org/blogs/pepsiman/?p=70
http://www.bottledlight.com/ds/index.php/Hardware/FlashCartridges

Anyway, Supercard I/O lies in the 0x09000000 region, eg. the upper 16MB of slot-2. I'm thinking when you "lock" it, it just maps the I/O on top, leaving the bottom 16MB readable. Whereas, if the M3 (with its different setup) balks there, it must have unmapped all the RAM...

i've got a problem with my m3sd: ram seems fuked! when i run ram unlock api test apply, it freeze; when i run links with graphic by dslinux, after some times it crashes. so i ran memtestarm and rim's said that my ram pack is broken(about @ 0x08090000 or something similar). is there any way to fix ram?

Strangely enough, I got a boatload of errors when compiling the new ram.c:

Code:

arm-eabi-gcc -std=gnu99 -Wall -O2 -march=armv5te -mtune=arm946e-s -fomit-frame-pointer -ffast-math -mthumb-interwork -I/c/devkitPro/libnds/include -MMD -DARM9 -c src/ram.c -o obj/ds/ram.o
src/ram.c:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
src/ram.c: In function '_sc_lock':
src/ram.c:32: error: 'vu16' undeclared (first use in this function)
src/ram.c:32: error: (Each undeclared identifier is reported only once
src/ram.c:32: error: for each function it appears in.)
src/ram.c:32: error: expected expression before ')' token
src/ram.c:33: error: expected expression before ')' token
src/ram.c:34: error: expected expression before ')' token
src/ram.c:35: error: expected expression before ')' token
src/ram.c: At top level:
src/ram.c:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token

Adding the following near the top fixed them all:

Code:

#include "ram.h"

My EZFlash V 3-in-1 works, even at turbo (2,1) wait state, but sometimes it takes a few tries to autodetect it if I hot swap it. A memtestARM update is coming soon.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Since lickr.org wasnot reachable I'm not sure if the ram_api 1.3 also left ? Is it still available from different sites ?
_________________
with kind regards, euer Dieter, still or again 8th kyu GO ranking
Only ... "Beginners play atari"
( http://senseis.xmp.net/?path=GoProverbs&page=BeginnersPlayAtari )

Bump.

Can somebody please mirror this lib?

It's in tepples' code. I think I'm only using v1.2 in mine but if you want to have a look, look on http://quake.drunkencoders.com in either the Q1 r3 source code or the Q2 r1 source.
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

It's in tepples' code. I think I'm only using v1.2 in mine but if you want to have a look, look on http://quake.drunkencoders.com in either the Q1 r3 source code or the Q2 r1 source.

Thanks for the tip. I found the files in tepples' memtestARM.

So has anybody worked out a way to use this stuff as general-purpose heap memory without 8-bit write problems? I'm trying to port The Ur-Quan Masters (http://sc2.sf.net) to the DS and it sure would be nice to have a 20MB heap with my 3-in-1. :) AFAICT dslinux manages to do it somehow, but I haven't taken a look at their code yet.

From Wikipedia:

Quote:

Adding support for external RAM was not trivial, as the GBA slot bus only supports 16-bit writes. If only 8 bits are sent over the bus, the result ending up in memory is garbage. A DSLinux developer called Amadeus found a workaround for this involved replacing "strb" (store byte) ARM assembly instructions with "swpb" (swap byte) instructions. The swpb instruction results in a cache hit, causing a whole 16-bit wide cache line to be written back to memory over the bus, instead of a single byte, thus eliminating all 8-bit writes over the bus. Amadeus modified the GCC code generator for ARM so that all applications compiled for DSLinux now use swpb instead of strb instructions. Assembly code in the Linux kernel had to be adapted manually.

Oh man! Thanks a lot for the info. I *never* would have figured that out myself. What an epic hack.

Is there a patched version of gcc availiable for use with devkitPro? It doesn't seem to support -mswp-byte-writes out of the box. :(

The DSLinux toolchain is based on but different from devkitpro. The modified toolchain is available in source with the normal DSLinux svn in the toolchain dir:

http://stsp.spline.de/dslinux/dslinux-snapshot.tar.gz
or

Code:

svn checkout svn://dslinux.spline.de/dslinux/trunk dslinux

@type error, yeah it's a right pain in DKA and I really wish the Linux compiler modifications were added to our compiler too! Until then I have to use a bunch of scripts that disassemble and grep the elf, then addr2line all the 8-bit writes, then go into the code and manually fix them! Plus the compiler often inserts memcpys, memsets and the like you so you really gotta be on your game ;-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

@type error, yeah it's a right pain in DKA and I really wish the Linux compiler modifications were added to our compiler too! Until then I have to use a bunch of scripts that disassemble and grep the elf, then addr2line all the 8-bit writes, then go into the code and manually fix them! Plus the compiler often inserts memcpys, memsets and the like you so you really gotta be on your game ;-)

Could you post in more detail about hunting down those 8-bit writes?
My solution was to hack desmume to log them to the console and fix them up later, your idea is probably a thousand times better though.

Yeah I remember you had that desmume method, but I didn't have the l337 skillz needed to do that so had to come up with my own method! I originally ran Q1 from main memory then external memory and diff'd the RAM over and over until my eyes bled, then realised that I needed an easier approach.

Will post scripts when I come back from the chip shop.
_________________
Big thanks to everyone who donated for Quake2

Testet a M3Real Ram pak with the memTool.

Detects as G6, but failed the writing tests

Hm?! I guess the unlocking scheme is different for the M3Real. Anyone any infos?!

People have had success using that RAM card with my stuff. I think they use the EZ-flash option and then it works from there... However I do have one guy who tells me that the rumble goes off during the libfat fatInit() function! Uh-huh...
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

@type error, yeah it's a right pain in DKA and I really wish the Linux compiler modifications were added to our compiler too!

That's not going to happen, ever.

devkitARM is not a DS only toolchain. Those modifications are far too intrusive.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Ah I didn't say that it should be added, just that it would be nice if there was some automatic tool for sorting out! I did start writing one, but got bored ;-)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

People have had success using that RAM card with my stuff. I think they use the EZ-flash option and then it works from there... However I do have one guy who tells me that the rumble goes off during the libfat fatInit() function! Uh-huh...

using the EZ-flash option with M3Real ram pack does not work

wintermute wrote:

simonjhall wrote:

@type error, yeah it's a right pain in DKA and I really wish the Linux compiler modifications were added to our compiler too!

That's not going to happen, ever.

devkitARM is not a DS only toolchain. Those modifications are far too intrusive.

They don't do anything unless you explicitly use -mswp-byte-writes.

pepsiman wrote:

They don't do anything unless you explicitly use -mswp-byte-writes.

Missing the big picture.

What's the point of modifying the toolchain if the support libraries aren't built with -mswp-byte-writes? If the support libraries are built with that option then the other targets supported by devkitARM suffer a performance hit for absolutely no good reason.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

If the support libraries are built with that option then the other targets supported by devkitARM suffer a performance hit for absolutely no good reason.

DSLinux uses multilib to avoid this.

pepsiman wrote:

wintermute wrote:

If the support libraries are built with that option then the other targets supported by devkitARM suffer a performance hit for absolutely no good reason.

DSLinux uses multilib to avoid this.

Which would require building two copies of dswifi, libnds & libfat at least. This will also double the multilib load - arm + thumb * (le + be + swp-byte-write). Please remember that devkitARM is not a DS toolchain, it also supports GBA, GP32, and is in use for several varieties of ARM experimentor board.

There's another way around the byte write problem which may be better suited to devkitARM. More on that when I've had a chance to test - it's not something I want to discuss in public without verifying that it's possible.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

pepsiman wrote:

wintermute wrote:

If the support libraries are built with that option then the other targets supported by devkitARM suffer a performance hit for absolutely no good reason.

DSLinux uses multilib to avoid this.

Which would require building two copies of dswifi, libnds & libfat at least. This will also double the multilib load - arm + thumb * (le + be + swp-byte-write).

Yes, but so what?
If you're worried about bandwidth then make the extra libs an optional download.

Just wondering where you guys got the _xx_unlock ()
/ _xx_lock() codes for these various ram expansion cards?!

Is it all the work from the DSLinux developers?!

Still like to know how to unlock/lock the M3Real Rumble+Ram pack

Can someone reupload version 1.3? The links are broken...
Thanks!

http://www.pineight.com/ds/#memtestARM contains the entire library.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

http://www.pineight.com/ds/#memtestARM contains the entire library.

Thanks :)

Hate to necrobump an old dead thread, but I see a bunch of discussion regarding how to unlock RAM with a guarantee that the contents of RAM won't change, and know of the simplest solution:

Make a copy of RAM before you write there. If it's writable, write the old data back as long as such a sequence will not send commands.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

How do you know if the memory that you're reading is valid memory? What if you read it again and it changes?
One of the cool things that I discovered was that if you haven't unlocked the memory correctly yet you still try and access the memory, you'll get a data abort. If you have unlocked it then you won't get an abort!

Not really too sure why ;-)
_________________
Big thanks to everyone who donated for Quake2

gbadev.org forum archive

DS development > RAM Unlocking API 1.3 [fixed]

#126044 - Lick - Thu Apr 19, 2007 3:48 pm

#126046 - simonjhall - Thu Apr 19, 2007 4:16 pm

#126049 - Lick - Thu Apr 19, 2007 4:30 pm

#126051 - Sunray - Thu Apr 19, 2007 4:34 pm

#126053 - simonjhall - Thu Apr 19, 2007 4:39 pm

#126055 - Lick - Thu Apr 19, 2007 4:44 pm

#126056 - simonjhall - Thu Apr 19, 2007 4:46 pm

#126057 - Lick - Thu Apr 19, 2007 4:49 pm

#126058 - simonjhall - Thu Apr 19, 2007 4:59 pm

#126059 - Eddy 912 - Thu Apr 19, 2007 4:59 pm

#126065 - tepples - Thu Apr 19, 2007 5:54 pm

#126066 - sonny_jim - Thu Apr 19, 2007 5:57 pm

#126078 - Lick - Thu Apr 19, 2007 9:28 pm

#126084 - simonjhall - Thu Apr 19, 2007 10:58 pm

#126089 - Lick - Thu Apr 19, 2007 11:26 pm

#126130 - viruseb - Fri Apr 20, 2007 7:55 am

#126132 - OOPMan - Fri Apr 20, 2007 8:20 am

#126137 - viruseb - Fri Apr 20, 2007 9:19 am

#126138 - Lick - Fri Apr 20, 2007 9:22 am

#126141 - simonjhall - Fri Apr 20, 2007 9:38 am

#126143 - viruseb - Fri Apr 20, 2007 9:52 am

#126144 - Lick - Fri Apr 20, 2007 9:56 am

#126145 - viruseb - Fri Apr 20, 2007 10:09 am

#126146 - Lick - Fri Apr 20, 2007 10:15 am

#126151 - viruseb - Fri Apr 20, 2007 10:32 am

#126153 - OOPMan - Fri Apr 20, 2007 11:03 am

#126157 - viruseb - Fri Apr 20, 2007 12:16 pm

#126158 - OOPMan - Fri Apr 20, 2007 1:02 pm

#126160 - NorQue - Fri Apr 20, 2007 1:54 pm

#126163 - Lick - Fri Apr 20, 2007 2:03 pm

#126170 - viruseb - Fri Apr 20, 2007 4:06 pm

#126314 - Lick - Sun Apr 22, 2007 3:16 am

#126316 - OSW - Sun Apr 22, 2007 4:17 am

#127055 - Lick - Sun Apr 29, 2007 5:25 pm

#127964 - simonjhall - Mon May 07, 2007 12:18 am

#127985 - Cydrak - Mon May 07, 2007 6:28 am

#128008 - Lick - Mon May 07, 2007 3:28 pm

#128009 - 9th_Sage - Mon May 07, 2007 3:52 pm

#128030 - Cydrak - Mon May 07, 2007 10:03 pm

#128032 - Lick - Mon May 07, 2007 10:15 pm

#128064 - Sunray - Tue May 08, 2007 7:06 am

#128149 - HyperHacker - Wed May 09, 2007 12:45 am

#128231 - tondopie - Wed May 09, 2007 10:08 pm

#128237 - Lick - Wed May 09, 2007 10:21 pm

#128239 - tondopie - Wed May 09, 2007 10:28 pm

#133429 - Ant6n - Fri Jul 06, 2007 4:37 am

#133450 - Dood77 - Fri Jul 06, 2007 7:17 am

#133487 - Lick - Fri Jul 06, 2007 1:34 pm

#133496 - simonjhall - Fri Jul 06, 2007 3:06 pm

#133502 - Lazy1 - Fri Jul 06, 2007 3:57 pm

#133503 - OSW - Fri Jul 06, 2007 4:05 pm

#133505 - simonjhall - Fri Jul 06, 2007 4:16 pm

#133517 - Lazy1 - Fri Jul 06, 2007 6:42 pm

#133524 - Dwedit - Fri Jul 06, 2007 8:13 pm

#133526 - Lazy1 - Fri Jul 06, 2007 8:21 pm

#133551 - Lick - Sat Jul 07, 2007 1:22 am

#133554 - Lick - Sat Jul 07, 2007 1:26 am

#133558 - Ant6n - Sat Jul 07, 2007 1:57 am

#133563 - Ant6n - Sat Jul 07, 2007 2:42 am

#133606 - simonjhall - Sat Jul 07, 2007 4:57 pm

#133613 - tepples - Sat Jul 07, 2007 6:09 pm

#133737 - Lick - Sun Jul 08, 2007 7:23 am

#133757 - chuckstudios - Sun Jul 08, 2007 1:58 pm

#133773 - Lick - Sun Jul 08, 2007 4:10 pm

#133862 - OSW - Mon Jul 09, 2007 10:25 am

#133983 - GPFerror - Tue Jul 10, 2007 12:18 am

#134275 - GPFerror - Thu Jul 12, 2007 6:33 am

#134292 - simonjhall - Thu Jul 12, 2007 9:31 am

#134303 - Lick - Thu Jul 12, 2007 10:44 am

#134492 - Lick - Fri Jul 13, 2007 12:15 pm

#134495 - simonjhall - Fri Jul 13, 2007 12:29 pm

#134496 - Lick - Fri Jul 13, 2007 12:49 pm

#135254 - simonjhall - Sat Jul 21, 2007 2:35 pm

#135313 - Dood77 - Sun Jul 22, 2007 3:36 am

#135349 - simonjhall - Sun Jul 22, 2007 5:40 pm

#135363 - MechaBouncer - Sun Jul 22, 2007 7:48 pm

#135366 - tepples - Sun Jul 22, 2007 8:20 pm

#135476 - Ant6n - Mon Jul 23, 2007 8:48 pm