Search

[cory1492]

Hey, I got asked a couple questions by email earlier, and to answer the questions (lengthfully  :oops: ) I wound up taking Zap's SD fat driver and cleaning out the M3 and non SCSD specific defines, as well as integrating the SC SD functions in place of the CF ones. I also resloved some issues with pointer errors during compile.

If anyone is interested, here it is:
http://nds.cmamod.com/files/buildtest_SCSD.zip

If you find any problems, do let me know, I have not extensively tested this library (and dont really have the time and knowledge to be 100% sure its working perfectly) since I just got it compiling without spewing on me.

Just a note, apparently there are problems with the origional CF drivers overwrite mode, and I never did get it to delete a partly written file properly without hanging.

I am honestly hoping to build some form of benchmark tool from this now, so we can see truthfully how our SC/SD cards compare.

edit:/ I just confirmed, the file delete code is not working quite right for files just created and closed by the lib (turn on DS, make file, close file, turn off DS - turn on DS, delete file, hangs - turn off/on delete file - success) wonder whats going on in there then...  :doubt:

next day edit:/
Okay, Ive isolated the issues, its down to 2 things now. When after writing a file with this and closing it fclose does not write the FAT, but file flush seems to... and for some reason FAT1 was written but FAT2 is not- also under windows, with this corrected, it still detects "minor inconsistencies in the volume" and after fixing it with chkdsk the file is sized to 1k larger and contains data that it did not before. How frustrating...could have something to do with timings I guess, perhaps I have not set waitCR to the proper value- must sleep on it. Again.

[Spooky]

Eventho i dont understand half of what you are saying =) its guys like you that makes the homebrew scene so cool!

Thanks for all the effort!!

[skydra]

what does this do?

[cory1492]

Spooky, thanks - I was hoping someone who knew could use the info.

skydra: it allows you to create homebrew that directly accesses the SD card. Actually, with the latest edition of chishms driver, which I added SCSD to, it allows you to read/write the SD and CF of GBA MP, M3 CF, and SC SD/CF

The problem I noted above: the FAT writing isnt an issue, when files are written in even multiples of 512 bytes, the fwrite allocates an extra cluster that it does not use and causes windows to complain, and the FAT file delete function to crash. Chishm helped me see this   and I am extremely grateful for it.

anyway, the origional driver from gba dev thread:
gba_nds_fat_2005-11-24.zip

modified to include SC SD and with extremely messy example code:
buildtest_newSD.zip
updated version of the FAT files from jan 4 2006
FAT_SCSDinc-2006-04-01.zip

for the time being, if you use this in DS code (and gba I think) make sure that files written with it have some data that is not multiples of 512bytes or there could be problems

I just successfully patched the RAIN 0.5 with stuff from the above files
RAIN_0.5_with_SCSD.zip
This should now work on SC CF/SD, GBA MP, and M3  

[deathrabbit]

This is neat.

Does writing to SC CF work even thought the cf driver is not in the folder, only the sd one is?

Also, is the 512 byte thing a problem with the source? or FAT in general?

Doesn't your source have the 512 byte problem also since 'info' is size 10240?

[Linus]

Hiya

Where can I find out more info on this, did you fix those bugs? Could it be used to help make an SD version of scummvm?

[cory1492]

I currently dont know the compiler options to build scumm with the sd file (although I did finally get it to build everything else properly). Still have some work to do, but the latest one does not have the bugs - if you need it let me know and I will post it, but it is still relying on the asm code (which in my opinion is far from optimized - hence requiring lower sampling rates/earlier stream buffering in things like MP3's in moonshell).

[Linus]

urm this is probably a stupid question but i dont understand what you mean by options to compile with sd. i had a look chishm's driver (with your source) and it appears to set an active interface as either mp/m3/sd/sc and all that kinda stuff. this interface is LPIO_INTERFACE that defines a bunch of disk access functions in disc_io.h

So after that shouldnt all io calls be standardised? if this is the case the  progam doesnt need to know what device its working on and you could just replace chishms driver in the scummvm code with your version and hey presto! lol im sure if it was that easy someone would have done it. Ive only just started lookin at the fat code so my understanding is wrong. sorry but im new to this but hopefully if i keep learning i might be able to help rather than just ask stupid questions!

Edit: i had a load of incorrect waffle here that ill delete because it could mislead people.

[cory1492]

Although I have not found it, there should be a way to compile the sd.s file in the makefile so the compiler does not pop out a "sd.o not found", which is where I'm stuck at and likely why the SD was not compiled into the origional version.

My attempt at converting the ASM to C for better portability and less dependancy on the compiler options has been frustrating to say the least. I am unable to get consistent results and there really is next to no information on doing such a thing (at least not specifically).

Im hoping chishm looks at it and says "ok, ez" and does it, but Im still working... Im at (probably) about 60% of what I need to know to do it all, and about 20% of the code converted and tested now.

[Linus]

yeah i know what you mean ive been looking round and to be honest your posts seem to be the ones with the most information in them heh. believe me i know frustrating these things are to test/debug. it is way above my head but if i find any info ill send it your way.

im still trying to get all the fat driver information in my head, but i think i need to refresh my fat knowledge first lol.

i still havent found where the original sd code came from, did the SC people release the source for working SD access with the ASM your talking about? Any whos this zap dude he seems to be workin on similar stuff to you, does he post anywhere?

well im gonna keep diggin for info

ps did someone over in gbadev mention pseudo code in a wiki or something?

[cory1492]

The wiki on GBAdev mentioned is here:
http://www.bottledlight.com/ds/index.php/Hardware/FlashCartridges
but the pseudocode is muffed a bit, Im still trying to understand how its accessing the data (registers are generally 32bit, and it seems that writes to supercard need to be 32bit for it to work out right...)

FAT is pretty simple, and chisms driver handles it very well, just the hardware abstraction for SuperCard SD that is relying on the assembly right now that is causing problems, the asm is pretty simple, but there are some really technical, hard to find info for converting it to C so it will work that I am not able to figure out just yet. (volatiles and where they are needed, and things of that sort)

Zap has posted here, but Im not sure if it is the same Zap that posted the source patches for supercard SD and moonshell, although the site for that was here:
http://www7.plala.or.jp/zap/download.html
and is in Japanese

edit:/ updated version of the FAT files, with jan 04 2006 source from chishm's site
http://nds.cmamod.com/files/FAT_SCSDinc-2006-04-01.zip

[Linus]

The new version looks like your making some progress converting it to C. for some reason i cant compile it with the asm (.s) file. Ive never tried to do this before so i dont really know how

But great work, i wish i could help out more though

Edit: sorry i was being a nibble jibble it was just a slight modification to the makefile.

ive got it compiled and got a certain program to run using the your code, im doing some tests on it now

[cory1492]

there is something in the generic nds makefile templates from ndslib examples that allows it to compile the .s code directly

I have about 60% of the code converted now, most of the reading stuff is now debugabble in C at least, but so far its not working (just crashes when it tries to init the FAT, pretty much on its first read)

[Linus]

hmmm if i compile scumm then put your fat code in compile again its fine. then if i edit the scumm files dsmain.cpp it says it cant find disc_IsInserted() but its clearly defined in disc_io.h which is clearly included by dsmain.cpp.

well anyway i dont why thats happening, but your read code doesnt crash for me all the time. scummvm crashes when i try enter a game and that is probably due to errors while trying to read but it can read the directories fine, add a game, write the ini file and load it so good going!

[WarGames]

this is really neat, I cant wait until you get this figured out so I can implement this stuff in my code