Everdrive SDK / SD card IO

[SamIAm]

It'd also be nice to be able to dump CD data (all of it) directly to the SD card as well.

You know where that could come in handy? Dumping LD-ROM data tracks.

[megatron-uk]

Here's the latest state of my implementation.

It uses MooZ's Everdrive sd.asm library to initialise and read sectors from the card - my first few functions implement FAT MBR and partition scanning. By default it will return the first FAT partition it detects on the card (but will show any others it finds). I'm part way through reading the filesystem start addresses from the volume sector of the detected FAT partition.

I've also attached the basis of my 32bit (4byte char array) math library needed to do 32bit sector calculations - before anyone says anything, yes, I know the multiplication functions are dreadful (calls add_int32 over and over), and they need to be redone as bitshifting ops.

Anyway, now that that's out of the way. I'd love some feedback from others - does the included test programme detect your Everdrive and SD card OK? Does it pick up your FAT partitions?

Although no write functionality is included and I've not had any filesystem issues so far, I take no responsibility for this code destroying your SD card, setting your dog on fire or releasing bubonic plague in your household.

[megatron-uk]

... and here are the assembly Everdrive functions and the HuC interface.

All credit to MooZ for these two files.

I've attached an image of what I get on my Express with a SD card with one primary FAT partition. It *should* detect and handle up to 4 primary partitions. Extended and non-dos partitioning schemes (GPT, bsd disklabel, etc) are not supported (as the Everdrive doesn't support them anyway).

A quick runthrough the display:

disk_init - does the asm call to the Everdrive registers succeed - if so, what SD card type is detected?
getMBRPart - could we read sector 0 of the SD card?
1be, 1ce, 1de, 1ee - results for reading the first four primary partition records - their filesystem type (FAT32 is 0x0B and 0x0C) and a summary of whether the partition was detected as FAT or Non-FAT
getFATVol - could we read the volume sector from reading the LBA start address of the detected partition?

Hopefully, with a working combination of ED and SD card, you should see something similar.

[BlueBMW]

It'd also be nice to be able to dump CD data (all of it) directly to the SD card as well.

You know where that could come in handy? Dumping LD-ROM data tracks.

A very good idea!  While most people dont really care for laseractive stuff, if its not emulated, eventually it will be lost.  Then five of us will cry

[megatron-uk]

Latest version of my Everdrive FAT test utility - MBR and partition detection code are now very robust, currently working on extracting start sector, data cluster start sector, FAT table offset etc, from the volume sector of the detected partition.

Also updated the test code using these functions to scroll back and forth through the process -> scan mbr, detect partition, load partition volume sector etc, as well as print out a lot of current debug values on the bottom half of the screen.

Feel free to give the current version a try.

(image is code running in mednafen and the error messages shown when no Everdrive is detected).

[megatron-uk]

In the latest version I've refactored some code - removed several local variables no longer needed and have finished the routines to extract FAT filesystem geometry and cluster information from the FAT volume sector.

The next step is to use the information retrieved about the root directory cluster in order to read directory enries and then follow the cluster chains to read file entries and contents.

The latest binary attached should detect any of the 4 primary partitions of an SD or SDHC card, use the first FAT partition detected and extract and display the volume information.

I'm hoping to implement a basic C 'stdio' set of file functions (fopen, fclose, fread, fwrite, fputc, fgets, fseek) on top of these functions to make use of the Everdrive SD interface in a more standard way. Low-level write functionality is currently being worked on by MooZ, so that may come later.

[megatron-uk]

Starting up the tool - screen 1 shows detection of SD card type using the low level sd assembly library.

The second image shows the detection of the four primary partitions and their status as FAT or non-FAT. In this example my 8gb SDHC card has a single primary FAT32 partition.

[megatron-uk]

The third image shows the retrieved address of the volume sector for the currently selected partition (p1 in this example) and the volume sector being read.

The fourth and final image shows FAT filesystem information (no. of sectors per cluster, no. of reserved sectors, size of FAT, start address of data clusters etc). At this point we have the address of the root directory entry and can start reading directory entries and file names.

[megatron-uk]

Oh yeah. Anyone spot the obvious mistake in the last image?

Yes, that's right; the cluster number for the root directory hasn't been switched from little to big-endian yet (it should be cluster 2, not 200 million). Endian issues have gotten me a quite a few times so far!

[Necromancer]

Obviously. 

I seriously have no idea what's going here (anything past "push run button" is too confusing for me), but I love it.

[Lochlan]

That's awesome that you're doing this, I am very excited!  Thank you so much!

A request:
I greatly (hugely) appreciate you posting source for this--but would you consider throwing it up on github?  Source control is great, and there's also the theoretical possibility of contributors via pull requests.  It seems like a good idea--right?  If you have something against using github there's also bitbucket.

Aside: one of the biggest problems with homebrew console dev IMO is that very few people throw their code into a publicly-accessible remote repository.  Easily-accessible source is just good for other hobbyist devs, and it's also a useful way to preserve these efforts.  Public github repos are likely to outlive forum posts!

[megatron-uk]

I'll certainly look in to doing that. I have a local subversion repository, but it makes sense to have the code publicly available.

[megatron-uk]

I've commited the current code to Github - it lives at:

https://github.com/megatron-uk/everdrive-fat

It's not ready for general use yet however - neither directory or file access are implemented yet, so you can't do anything constructive at the moment.

I'll add documentation on how to use it within the next few days, but the test application I've shown the screenshots of is also included in the repository.

[megatron-uk]

I've moved on to the actual fopen/fclose, fread/fseek functions now - things you can actually use in your code to interact with the FAT32 filesystem.
 
So far I have directory traversal working for my fopen() implementation - for now my design decision is to focus on the classic 8+3 filename support as LFN support require a lot more work (and work memory - twice the storage for the same length of filename). I can't see that being a major problem in the short term - all LFN entries have a corresponding 8+3 representation anyway.

Anyway, given a normal file path (eg "/files/saves/soldier.sav")* I'm able to traverse the root and then sub-directories to find the file and record a free 'file pointer' against it (really just an index into an area of memory i'm calling the file work area that holds the directory entry for a file, its starting cluster, current cluster and current seek position within the file - struct support would really simplify things here).

The maximum number of open files is configurable at compile-time - and the size of the file work ram is a product the number of files you want to be able to support at any one time (minimum of 2 - one for internal directory operations and 1 for user files) multiplied by the number of bytes neded to store the metadata for a file (currently 44 bytes). So a minimum of 88 bytes.

When I've got the last kinks of fopen() worked out I'll commit the changes back up to github.

* Incidentally, the code supports both Unix-style ('/') and DOS-style ('\') directory name seperators. eg:

Code: [Select]

fopen("/files/data/cheats.txt")
and

Code: [Select]

fopen("\\files\\data\\cheats.txt")
are equivalent (backslashes must be escaped in HuC otherwise the compiler chokes). Paths are always relative to the current active partition, as selected with getMBR(part_number) or getMBR(0) to select the first active FAT parition.

[Bonknuts]

Write operations are going to be next on the list?