Another breakthrough in the HB scene! RAM expansion!

Over at GBADev they have posted that they are now able to use the memory from the Ram Expansion and what Supercard Lite has too, what does this mean, well im no devver but it should mean more memory which should help quite a bit with Emulators and games.

UPDATE

Sonny_Jim posted this to me: (thanks)

The DSLinux ram breakthrough has NOTHING to do with the Opera RAM extension.

It uses the 32M on the Supercards (CF/SD/Lite). These allows DSLinux to use 16M on the Supercard as main ram. This means we get around 17M free in DSLinux as compared to 2M before.

No other homebrew so far uses this technique.

A Very Interesting Breakthrough, any Devs want to explain Further ?

Great, Things are really starting to look up for homebrew.

Yes I hope they come out with a supercard lite version of snezzi with use of the ram :D!

wha? Does this mean emulators can get better? Maybe a saturn emulator? N64?

Does the RAM expansion come from that Opera web browser pack, or from Supercard Lite?

Yay! Better Stuff!! WooT (Fails To Understand But Happy Anyways) :D

Quote:

---

Originally Posted by Video_freak

Does the RAM expansion come from that Opera web browser pack, or from Supercard Lite?

---

i think its from both the Opera web browser pack and the Supercard Lite.:)

Thanks for the information kcajblue. I was wondering whent hey were going to incorporate it into homebrew. :)

First off it's NOT the Opera RAM expansion, it's the 32M on the Supercards, that is normally used to hold GBA/NDS roms. At the moment 16M is used for romfs (I think) and the other 16M can be used by Linux. These means we get around 17MB free for userspace programs.

(can someone change the main page post to reflect the fact it has nothing to do with the Opera RAM extension?)


AFAIK even though the nessacery information has been available to developers for a while, no homebrew is doing this atm apart from DSLinux. If you want to access this memory in homebrew it's not impossible but then again, it's not just a case of changing a few lines. Amadeus and the others have had to do a LOT of poking around to get this working.


One thing to always bear in mind with emulation:

The host system CPU has to be roughly 10 times the speed of the emulated system. Having more RAM available is not going to make the emulator run faster.

One reason why Windows runs faster with more RAM is because it doesn't have to hit swap as much. This really doesn't apply to homebrew.

Once again, more RAM doesn't equal faster, just more room to store data. Also, the Supercard RAM is substainally slower I'm lead to believe than the main RAM due to the funky tricks needed to make it work.

EDIT: I can't believe I registered just to moan

Quote:

---

Originally Posted by Sonny_Jim

EDIT: I can't believe I registered just to moan about the incorrect facts

---

I'm glad that you did as it means myself or others didn't have to. :D

Reading through everything it supports all versions of the SuperCard, from CF to Lite. It has been possible for sometime for homebrew coders to use this RAM but they would have to write the libraries themselves. Hopefully it will get added to DSLib for more ease.

Abs

Thanks for the confirmation Sonny_Jim. :)

Copied from a post by Amadeus on the DSLinux forums:
See here for original post: http://www.dslinux.org/index.php?showtopic=1748&st=0

FAQ
===

What is the 8bit-write-problem, and why do I care?
--
The GBA ROM space is the only big (32 MBytes) addressable extension for the DS. If you want more memory, you need to use the GBA ROM space. Unfortunately, the GBA ROM access is 16bit only. For 8bit read access, the unused byte is sorted out by the CPU. But for 8bit write access, you end up with the unused byte beeing garbage, and destroy your memory layout. This is the reason why the GBA ROM space is only used for read-only memory.

What about Opera for the DS lite?
--
Opera is sold with a RAM extension in the GBA slot. Nobody knows how they did it. As there is only one program using this extension, I think they have recoded the program to avoid 8bit writes.

What possibilities exists to overcome this problem?
--
First of all, you can recode your programs to don't use 16bit writes. Regarding the endless amount of available linux software, this will be an endless task, and nobody has tried to do this.

Second, you can modify the compiler (gcc) to do a 16bit read-modify-write instead of a 8bit write. This will lead to slow programs, because the compiler has to check for even or odd addresses before doing the read-modify-write. Nobody has made an attempt to do this.

Third, you can disallow all(!) write accesses to the GBA ROM space, and let the data abort handler in the kernel do the read-modify-write. This has been done (outside DSLinux), but the resulting programs are suffering a massive slowdown (100 times).

And then, there is the cache+swp solution...

How does the solution work?
--
Pepsiman an me have discussed the 8bit problem over IRC and email, and have discovered that a data cache writeback will write back 16 bytes at once. So if you enable the data cache in writeback mode for the GBA ROM space, each 8bit write which hits data in the data cache is no problem any more, because the 8bit write is transformed into a 16byte write (when the cacheline is written back).

But what about data cache misses? They don't go into the data cache and are written back 8bit wise!

Working with the ARM assembler manual, I discovered the SWP instruction. This instruction is doing a read and a write from/to the same address in a single, uninterruptable instruction! The read will load the data cache, and the write will produce a data cache hit. And no interrupt can go between the read and the write and invalidate the cache!

I wrote some assembler code in head.S and studied the behaviour of swp, and proved that it works.

What are the drawbacks of this solution?
--
If the compiler is modified, ALL 8bit writes are turned into swps. So there is a slight drawback in speed in the main memory, and you can not access 8bit hardware registers with GCC any more. For hardware access, you must use the writeb() macro instead.

swp is doing a data cache load first. So the first access to a sequence of bytes is slow, but the subsequent accesses are fast. If your program has many accesses to 8bit data scattered all over the memory map, execution speed will suffer. But for most programs, this is not the expected behaviour. Most times, there is no visible slowdown.

swp uses a third CPU register and is limited in the addressing modes. So the code generated by GCC is larger and slower. How much larger and slower depends on the usage pattern. Again, most times slowdown is not visible.

Modify the compiler? Are you crazy?
--
Puhhh.. this is a huge task, anyway. But there is the GCC devel mailing list, and there are some friendly people with deep knowledge in the GCC community. So I decided to give it a try. After all, if you don't try it, failure is guarantied...

It turned out that making this modification is a _very_ huge task because the semantics of strb and swpb are different, and that we are needing a 3rd register. There were months of trying, tests, and emails. Finally, we have a GCC which is able to compile whole DSLinux (kernel and userland) without "internal compiler error".

hmm, maybe they can finally add image support to the retawq browser?

retawq is text only. Links is in DSLinux and has a graphical mode, but it doesn't work yet afaik.

Thanks for the info, Sonny. You saved me a TON of explanation.

Eather way its looking better and better i will get the new soft ware.

The M3 also has 32 MB ram. Think that maybe IT can also be utilized?

Man, I hope so...Better emus with all 'at.

The M3 RAM cannot be used for this purpose.
http://forum.gbadev.org/viewtopic.php?t=10892
M3 uses most of the RAM for I/O operations.

Aw.

Well we have to have some way to make genesis etc. emu faster.