I know it's been a long time, but I am returning attention to this project, so I thought I'd make a pseudo-blog about it here, just to note what I am working on.
The project had been on hiatus due to other hobbies and a dread of implementing FAT write routines (reading is easy, if there are issues, nothing is ruined. writing is a commitment). And, writing files in FAT16/32 with Long file names is a serious exercise.
Currently, just opening a file for writing is a 234 line function, and I still need to add the code to add a new sector/cluster to the dir if all entries are full on the current sectors. But, it's a pretty small function, so I should have that done tonight.
Doing so will require creating a function to find a free FAT cluster and updating FAT, so I can reuse that when I write sectors.
On a whim, I last night hooked an IDE drive and a CF card up the interface, and they both worked at the same time.
On the bad side, I realized I need a RTC for the interface, and I am out of pins... I need at least 1 SEL line, so I need to go digging for it.
When I started the project, no one had FAT16/32 routines that offered LFN support and many only allowed one open file, or were write only. So, I started rolling my own. Then, I got busy, and had trouble grokking the LFN rules, so the project progressed very slowly.
Last week, I spent a lot of time getting the LFN entries created correctly on the CF card. Of course, I still had the actual FAT-entry work and such to do.
Then, I happened online and found FatFS, available since 2006, which has all the pieces I don't have, and lacks only LFN support.
sd2iec also uses it.
So, I went to work, now that I understand how LFNs work, adding the code to FatFs to do LFNs.
TO save development time, since FAT routines have nothing to do with uControllers, I moved my development over to the PC for the moment. I images a CF card as a raw data file, and retargeted my FAT16/32 routines to mess with the img file. That sped up development a lot.
I am finishing up the more esoteric functions in FatFs right now. I am also looking if I can borrow from the sd2iec project codebase, as I would rather add my multi-partition/CMD path handling code to that effort than re-invent everything they have (I covet the D64 code, for example, as that is in my plans).
Of course, the multi-partition code is not of major interest to sd2iec, as that is RAM limited, but I have more RAM in my design, and it's not much bigger. But, one codebase with two developers is better than 2 codebases with 1 developer each.
sd2iec? Would that be this? (http://snowcat.de/mmc2iec/)
There is no sd2iec-specific schematic because it is using the same hardware as Lars Pontoppidan's MMC2IEC. There will be a version for an improved board in the future (the original MMC2IEC hardware has problems when many devices are connected to the bus and fixing that will require incompatible changes in the software - the brainstorming about this is still ongoing at forum64.de), but as long as I can fit more features in an ATmega32 I'll release MMC2IEC-compatible binaries.
I sent multi-drive patches to Unseen last week, and they are merged (after he fixed a bunch of bugs). It took a few days to clean up the patches to make them more elegant, and reorganize some arrays and such. But, multi-drive support is merged into mainline now. Multiple partition code and a C version of JiffyDOS routines are merged into the mainline tree, as are some Fat cleanup and optimizations.
Code is looking very nice and very robust. Unseen is definitely doing the bulk of the work, as part of the firmware updates for sd2iec, but I do get the benefit, as he keeps the uIEC config up to date.
Since multiple partition and multiple drive code is in place, much of the work now is in adding support for more CMD commands, adding more error handling, and cleaning up code.