Hi All!

Has anyone taken on the Hercules task of porting a FAT32 filesystem for the 6502? There's a bunch of code out there in C but erm, it's a lot.. I've done a simple FAT16 reader once that I *could* port over to 6502 but that kinda limits the amount of storage (then again, files aren't generally that big)

Open to suggestions / alternatives as well! The goal is to be able to read 'standard' SD cards.

Yvo

I must admit...I'm wondering why you would need that much storage for a 6502 based system.

Not that I'm against it, just curious.

One idea I suppose would be media content to stream. Like playing music or in-game video. But even then, it would have to be a LOT for FAT32.

What are you aiming to build?

_________________
Cat; the other white meat.

It's not so much about the amount of storage but more so about compatibility. Most cards these days are int he GB range and you have to go really out of your way to find smaller ones. IIRC Windows doesn't even give you the option to use FAT16 on large cards, hence my FAT32 dilemma

I do have a FAT16 read-only system I once wrote in C which I could port if all else fails but I'd rather support more spacious cards as they're readily available...

Yvo

Have you considered something like the CH376? It's a chip that interfaces to USB, and it supports FAT32, you just talk to it via parallel, SPI, or async serial. You can get a CF Flash Reader to plug in to the USB port.

There's little breakout modules, for about $3 all over the internet, with the chip and USB connector, but I've tried in vain in the past to just try and locate the bare chip (were I motivated enough I suppose I could buy one of these modules and simply de-solder it).

It's annoying having to hook up a far more powerful computer in terms of raw CPU power, and storage, and what not, just to talk to a peripheral, but such is life today -- c'est la vie.

All that said, it's an elegant solution to the problem. With this kind of thing you can connect almost any kind of modern mass storage.

whartung beat me to it.. I was about to suggest the ch376. I have one of those breakout modules but I haven't yet interfaced it to anything yet.

Oooh, I hadn't heard about that one! It looks like it's obsolete though but yeah, that'd be a nice solution I'm using an FTDI 230x (always confuse that one with the flower delivery service) to talk to my PC which comes in at about $2 or so.. Alternatively, I could go with SPI flash to avoid the whole thing and use a block-based approach but that would mean you'd have to hook it up to a PC every time you want to update it, which isn't ideal either..

I did a little bit of sleuthing and, since I don't really need a full featured fat32 solution, it should be do-able to write it in asm..

Now, if you want to be really hardcore, you are welcome to reuse / adapt the SD and FAT16 code I created for my homebrew.

If only I had heard about this 376 chip - looks very good. But alas I didn't, so I wrote from the ground up SD card routines which bit-bang SPI through a 6522, and deals with FAT16 format cards.

I coded the routines poorly in the sense that they work with the 1GB cards I have to hand - you may need to mess with MBR locations and such things for other cards (and my code commenting isn't great ). However it works - file create, read, write, delete, directory listing. Significant limitations include - files have to be 8.3 format, no timestamp, and doesn't deal with sub-directories. But I was and am under space constraints, and it's enough for what I wanted.

I haven't looked in to it properly (yet), but I *think* even large cards can be partitioned and then formatted with FAT16, so these routines may well work with > 2GB cards (as long at the partition is within FAT16 size limits).

Despite not having the benefit of the 376 device, all of the above, plus a BASIC-like tokenising interpreter with support for TMS9918 graphics and AY-3-8910 sound in just under 16KB of ROM. The link below is the main repository, from which you can get to the source code.

Cheers, Dolo
https://hackaday.io/project/5789-6502-homebrew-computer

I believe the Mega65 project uses FAT32, and has 6502-ish code for working with it. I say '6502-ish' because their processor has some custom extensions on top of the C65's CPU. But it would provide a base to work from.

https://github.com/mega65 mega-65/src has the source code.

That's pretty nice.

Having just had a recent epiphany, assuming it works (it should work, dunno why it wouldn't, but...), the 376 is compelling to me short term in that you can hook up more than one device.

The low level drive the entire time has been, for me, a self contained system. And one aspect of that is that you can, for lack of a better term, "copy floppies". Now, clearly, that can be done with a single drive. But the idea of being able to plug in two devices "easily" is an interesting capability for a 1" square piece of kit. In my world those would just be generic USB sticks, and, hopefully, through a simple USB hub.

In theory the 376 brings not just USB block storage, but all of USB to the plate. So, that can be interesting as well. You're also not limited to FAT32, you just get that for free. You can do low level block I/O with it as well (I think). Not sure if it can, out of the chip, format device or not.

Anyway, quite a bit of potential for $3.

Thank you, means a lot from a long standing member of the forum. I agree the 376 is great bit of kit, and if I used it I could have saved ROM space for more features in the interpreter, but the geek in me did enjoy getting the SPI SD Card interface working and then deep diving in to FAT to support a PC compatible filesystem.

I read the manual, I couldn't see a command to format disks, but looks like block level access is possible - as you say, loads of possibilities.

Hi,

we are working our own FAT32 implementation as part of the operating system "SteckOS" for our 6502-based homebrew computer "Steckschwein" http://www.steckschwein.de

It's not complete yet, we currently do not follow cluster chains, so files > 1 cluster are a problem.
We chose not to support long file names either.
But creating, reading, writing files and directories works. The "API" is loosely modeled after POSIX (open,close,read,write).

The code is publicly available: https://bitbucket.org/steckschwein/stec ... os/kernel/

Our implementation only needs a means to read and write (512 byte)blocks and a few memory locations.

Cheers,
Thomas

Really nice.

I was planning to use Opencores SD card interface, but it was stealing so much of the FPGA. With a 6502 implementation, the SD card interface will use very little in FPGA resources.

Can you comment on the 1 cluster limitation? It limits the files to 64KiB? Maybe I need some way to get around that..

BTW, here is a Microsoft technical paper on the FAT filesystem for those who don't have all the details.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, if you format your file system with a cluster size of 64k. Our implementation is still lacking the actual FAT lookups to get the first block of the next cluster. This should not be a problem if your files are not fragmented, in which case you would just keep reading the next blocks until the end. Which is what our implementation does, IIRC.

Also worth noting Paul Stoffregen's page about FAT32 as he concentrates on the bare minimum you need to get started:
https://www.pjrc.com/tech/8051/ide/fat32.html

Helped me a great deal.