#139072 - tepples - Sat Sep 01, 2007 2:26 pm
| In a post about a DS card loader, chishm wrote: |
| That's mine. It's possibly the app I made to use Supercards or M3s (SLOT-2) as RAM Paks for official Opera DS cards. |
What would it take to make the SuperCard, M3 Pro, M3 Perfect, EZ 3-in-1, or Opera RAM card into a block device for libfat, like some sort of RAM disk in a virtual "SLOT-3"? This alternative to Lick's RAM unlocking library might be based on FCSR, except read-write, and there'd have to be some sort of lock against simultaneously accessing the RAM and the media card in SLOT-2. I don't have a whole collection of cards to test on; otherwise, I might have done it myself.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139074 - truedream - Sat Sep 01, 2007 3:37 pm
| tepples wrote: |
| In a post about a DS card loader, chishm wrote: | | That's mine. It's possibly the app I made to use Supercards or M3s (SLOT-2) as RAM Paks for official Opera DS cards. |
What would it take to make the SuperCard, M3 Pro, M3 Perfect, EZ 3-in-1, or Opera RAM card into a block device for libfat, like some sort of RAM disk in a virtual "SLOT-3"? This alternative to Lick's RAM unlocking library might be based on FCSR, except read-write, and there'd have to be some sort of lock against simultaneously accessing the RAM and the media card in SLOT-2. I don't have a whole collection of cards to test on; otherwise, I might have done it myself. |
ah using opera ram as ram disc was my idea also only yesterday, can load it from slot-1 and then use as disk with FAT, but that would need 2 disk interfaces being selectable, think that not possible with DLDI approuch, I could see it easy done with older moonshell that supports multply filesystems
#139079 - calcprogrammer1 - Sat Sep 01, 2007 5:38 pm
Considering Libfat already can use 2 different devices at the same time, provided only one of them needs a DLDI (DSFile uses a Slot-1 DLDI and a Slot-2 native like GBAMP at the same time), and all you need to do is call "fat1:/" or "fat2:/" depending on slot, it may be possible if all the RAM carts are written natively into libfat (thus not requiring a DLDI), then you could call "fat3:/" or maybe "ramdisk:/" to get to it.
I'm not sure of the internals of libfat though, just thinking it may work. Wouldn't benefit me any as I don't have any ram carts :( but it may be good for those who need it, and it'd make RAM usage easier for temporarily storing files.
You might have to format the RAM into a FAT filesystem upon each boot though, which may take time.
_________________
DS Firmware 1, Datel Games n' Music card / Chism's FW hacked GBA MP v2 CF
There's no place like 127.0.0.1.
#139081 - tepples - Sat Sep 01, 2007 6:17 pm
| calcprogrammer1 wrote: |
| You might have to format the RAM into a FAT filesystem upon each boot though, which may take time. |
There are two steps to "formatting": 1. testing each sector and 2. creating the file system data structures (FAT and root directory). Step 1 can be skipped if you are confident that all sectors on the medium are good, and Windows is capable of doing only step 2 in a "quick format". In fact, step 2 can be completed in milliseconds on a RAM disk.
The reason I suggested that this be implemented inside libfat rather than as a separate library is that FCSR already does the reading side of what is needed here. All the driver would have to do is extend the FCSR image to the end of RAM, and then the program could create files in the extended space.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139086 - laos - Sat Sep 01, 2007 7:13 pm
I'm not very knowledgable with this, but isnt the Supercard and M3 Slot 2 solutions (Except rumble and pro) provide 32 MBs of ram, if correctly use
and my last question, why cant you ever use the SD's flash memory as RAM, whats the difference
_________________
laos,
In charge of Storyline: Tales of Dagur 2
#139087 - calcprogrammer1 - Sat Sep 01, 2007 7:38 pm
Flash memory is slower than RAM, and if you write to flash memory too much, it wears out. The listed cycles is around 100,000, but think that RAM is being written to, in many cases, every cycle, and that cycles occur many of hundreds or thousands of times a second. That would wear out the flash memory of an SD card quite fast.
The flash memory could be used as a cache to store files that aren't going to be constantly rewritten though, like DSOrganize uses the flash memory to help support images in the browser.
_________________
DS Firmware 1, Datel Games n' Music card / Chism's FW hacked GBA MP v2 CF
There's no place like 127.0.0.1.
#139095 - Cydrak - Sat Sep 01, 2007 10:31 pm
Yup, they do have 32MB... the main difficulty is finding and setting up a separate allocator--malloc() is unaware and doesn't cope with two heaps. And even if it could, you can only write u16/u32, so byte access will break.
My understanding of CF and SD is they're more like DS cards than RAM.
RAM is fairly simple-minded. You supply an address, then send or receive (usually in the DS case) 16 bits of data. There are separate pins for address, data and control signals, so it's a parallel interface.
DS' RAM I believe is 4MB--so that's 21/22 address + 16 data bits. For the GBA side (32MB--16M halfwords), you'd need 24+16, ignoring control and power... Maybe you noticed SLOT-2 is kinda short on pins! So what do they do? Borrow address pins for the data. These are saved, and when reading consecutive addresses, just the data is sent.
Now if I look at my shiny 1GB microSD... I don't know about you, but mine has 8 pins. This is probably the most they could fit, considering wear on the slot, and that it's not soldered in! So even THAT trick isn't going to work. Instead, these cards use a serial, command/reply type interface (1 or 4 bits sent at a time I believe). Rather than bytes or words, whole sectors are read and written.
I think bare NOR flash can be used as ROM, but writing only changes the bits in one direction, e.g. 1 => 0. To actually write new data you have to erase whole sectors, which sets them to 1's again.
#139120 - chishm - Sun Sep 02, 2007 8:13 am
Since the RAM is volatile, you'd need to rebuild the file system every time the DS was power cycled. This would involve creating the appropriate structures on disc/RAM (MBR, BSB, FAT and root directory) before mounting it in libfat.
I honestly don't think a FAT based RAM disc is a good idea. You'll incur large function call overheads in comparison to the speed of the RAM, you'll waste space on the file system structure, and you'll need to initialise it with data every time you turn on the system.
If you want a RAM disk that is usable with stdio functions, I suggest writing a simple implementation that hooks into the devoptab directly.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#139132 - tepples - Sun Sep 02, 2007 4:05 pm
| chishm wrote: |
| If you want a RAM disk that is usable with stdio functions, I suggest writing a simple implementation that hooks into the devoptab directly. |
That was my plan initially until I thought of four issues, which may or may not be directly related: - How well would a RAM file system coexist with FCSR? Is there a defined way to find the end of an FCSR image in RAM?
- How well would a RAM file system coexist with accessing files on the SLOT-2 card? Based on comments in the topic about Lick's RAM Unlocking API, it appears that libfat or its drivers expect exclusive access to SLOT-2 when SLOT-2 is mounted.
- How often does devoptab change? Is there any documentation for devoptab other than the devkitARM source code, the libfat source code, and one page in French?
- How would I get it to work on multiple cards without linking in Lick's library, whose license appears to require that even private modifications be published? Such a requirement is not compatible with the GNU GPL or even free at all by the FSF standards.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139177 - chishm - Mon Sep 03, 2007 3:22 am
1: FCSR is designed for ROM, and not to coexist with writable memory in ROM address space. At the time it was written, any cart that had RAM either had a memory card interface or was a pure RAM Pak. There is no defined way to find the end of an FCSR image.
2: DLDI allows you to write a driver that locks RAM and unlocks the memory card interface before reading/writing to a disc and then doing the reverse either. The normal DLDI drivers don't do this, as it causes an unnecessary slow down in any application that doesn't use both RAM and disc.
3: All changes to devoptab have been simple additions to the functions it supports. It only changes when there is a real need, such as when someone requests statvfs support.
4: This sounds like you're trying to hack libfat+DLDI into something it isn't for the convenience of having support for multiple cards. Either ask Lick to relicense his library or find the source information for his card and write a new library with a more compatible license. This may be a duplication of effort, but if the license requires it, then it's really no different to cloning a proprietry (closed source) library into an open source compatible version.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#139204 - tepples - Mon Sep 03, 2007 2:36 pm
Thank you. I'll bug Lick instead.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#139254 - Dan2552 - Tue Sep 04, 2007 12:15 am
Interesting, I do wonder what it'd be useful for - maybe cache for browsers and such. Maybe even holding an MP3 or something in memory for quick access.
#140014 - laos - Wed Sep 12, 2007 8:09 pm
i guess what they mean by cache is temporary usage, until your done using that item or power the DS off, a little inch for the mile. Overusage = bad day
It would be interested if someone devised a hack for more RAM, but likewise its pointless, this is a weak handheld console not a current of the age laptop
_________________
laos,
In charge of Storyline: Tales of Dagur 2
#140015 - tepples - Wed Sep 12, 2007 8:25 pm
Thread-jacking myself to refocus the design given recent developments:
So if a tmpfs were done, it would not depend on libfat. Instead, it would be a file system that acts as a layer on top of the recently relicensed RAM Unlocking API, mounted through devoptab. Each call would unlock RAM on entry and lock RAM on exit.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#140028 - kusma - Wed Sep 12, 2007 10:17 pm
I think this is a very good idea, and it sounds very usable for a small application that I'm considering to make. IMO it would be even cooler if the FS would persist between different applications without a hard-reset between, but I realize that implementing that would be very tricky if not impossible given the current state of NDS homebrew.
As a side-note, I think we are approaching where a lightweight "operating system" (think DOS-variants, or even better AmigaOS) would be really useful and allow better interaction between applications. How much work would be required to take MightyMax's ultramicrokernel and make something like an application-framework that allows relocatable applications to perform cooperative multithreading in a defined way?