following the footsteps of many and thinking about interfacing an SD card to my breadboard build.

I like the idea of delaying the CB1 clock for SPI mode 0. (would a d-flip flop be an alternate to the delay network?)

i've found lots of ideas about filesystems like implementing fat32 or simpler modern systems but everything feels a little complicated. I was leaning towards some raw storage approach but not sure I want to build it completely from scratch.

then ran across this post about a new prodos release in 2016 which is wild. I couldn't find much discussion of it here. is it closed source but free to use?

i kind of like the "one in a million" idea of my SBC with 32Kb of ram reading from a 32Mb prodos volume which is stored as a single file on a 32Gb SD card

anyone explored anything along these lines?

ProDOS is fairly wedded to the Apple II and its hardware.

That's not to say you can't separate out the filesystem bits from the low-level driver bits if you tried hard enough.. How much time have you got?

A down-side of doing down that route is the ability (or inability) to read/write the SD card on another computer. Might be possible, might not ... So you'd have to resort to other means to get data to/from the card... There may be utilities from the Apple people though.

When I started my Ruby 6502 project I decided that a ProDOS-like filing system would be a good idea. Files/Volumes up to 16MB, extendable directories, hierarchical filing system and so on, so I wrote it and got it working. I enhanced it slightly to allow for much longer filenames and file attributes that the Acorn MOS likes to have (Load and Start addresses and a Timestamp.

I had the advantage in that (a) I've written several other filesystem in the past and (b) I was writing it ib C to run on the ATmega "host" MCU to my 65C02 system which has native SPI and runs the SD card at 8Mhz.

It worked well, but then the issue I mentioned above came to light - I could copy volumes (as they were MSDOS partitions), but getting files to/from it was only possible via the SBC itself through the serial line. I'd intended to write a FUSE driver for Linux but never got round to it.

I eventually decided to go down the FAT route and used a freely available FAT32 filing system module written in C for microcontrollers and haven't looked back.

There is a FAT filing-system written in 6502 and I've seen mention of it here, but my search-fu is weak today and I can't find it. Maybe if you have more time you'll find it.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

OK, interesting. Yup i've found various 6502 fat-32 implementations and was thinking maybe to use something like that for low-level read/write to a volume file (or partition) but then do all the actual file management inside that volume with a simpler 16-bit fs. maybe following the prodos file organization spec ends up not being much different from writing fat-16? i don't know enough about any of the details yet.

Hi,
If you look on Daryl (8BIT)'s site, he has a FAT16 implementation. I think it was for his SBC2.5. I'm preparing an "inspired" version of same for my WBC.
FWIW

_________________
Glenn-in-France

Seems odd... Why put a ProDOS filesystem inside a FAT-32 one?

Maybe use the MSDOS partition table format, then a ProDOS filesystem inside each partition (sort of what I did).

The low-level stuff is the simple read/write a block from/to the SD card via SPI - that's simply a matter of sending it the block number (32-bits) then reading or writing the 512 byte 'sector'.

(Well, "simply" is relative but it's not hard once you're at that level)


-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

right. i guess what you really want is a contiguous range of 64K x 512 byte blocks on the SD card which the 6502 can manage as its own filesystem. that's presumably easier to do by reserving a separate partition (or keeping the whole SD card raw) than assuming you can somehow create a static file within a fat32 FS that occupies a fixed/knowable set of blocks.

reading the prodos FS spec it seems pretty straightforward compared to fat32 - i might try a host-side python implementation to get the feel for it and let me manage volumes on the host side

I'll second Gordon's approach. I connected an Arduino+SD card hat to my Apple II to make a poor-man's file transfer device. The Arduino run's a FAT library to handle all the file system management details. The communication between the Apple and Arduino are fairly high level operations like open filename, read directory, change directory, etc. Consider it a smart storage device. Is it as pure as interfacing directly to the SD card? Maybe not, but you are interfacing to an SD card, which isn't period correct anyway. And you save a great deal of code on the 6502 for other things. You can always migrate the functionality to the 6502 later, if you chose.

there are also commercial options available, like the CH376S which (AFAIK) is just an 8085 based microcontroller with a USB and SPI controller slapped on, it has built-in support for FAT32 for both SD cards and USB drives and even gives you direct access to the USB host controller, so with the right driver you could in theory connect and use any USB device through it.

Another approach is to have a latch that is holding the SPI_SCLK clock low, until the VIA_SCLK drops, and then the SPI_SCLK line is released to follow VIA_SCLK. At the end of transceiving a byte, you reset the one shot, which gives the final SPI_SCLK drop that the Mode0 requires. That needs a /MODE0_SET GPIO and an /R /S latch.

That can be done with a single quad NAND, with two of the NAND used for the /S /R latch, the VIA_SCLK as one of the latch inputs and the /MODE0_SET used as the other. Using a NAND as a filter based on whether the /S /R latch is set or reset ends up inverting the clock, so three NAND gates gives a Mode2 SPI clock line, and then the fourth NAND can be used as an inverter to give the Mode0 SPI.

Note that while it is parsimonious hardware, it does mean an extra GPIO manipulation per cycle, but if it allows a VIA and a shift register to implement the SPI bus with a variable clock rate of up to Phi2/2, that overhead may well be worth it. Also, having a VIA being the MOSI driver and a shift register being the MISO receiver means you don't have to worry about whether setting up the SCLK line to avoid the VIA SSR input bug.

oh interesting, thanks! new to the hardware side of things, will spend some time playing around with this

Step forward on the software side. I was able to extract a portable (no apple h/w deps) relocatable kernel for the prodos FS and get it running. More here https://github.com/patricksurry/p8fs

ProDOS has a well documented machine language interface (MLI) and abstracts all its IO via a simple block device driver API. This makes it easy to plug in arbitrary storage devices like RAM disks or SD cards. Drivers simply read (and optionally write) sequentially numbered 512 byte blocks from their storage.

My slimmed down version contains just the filesystem and MLI implementation - it uses a little under 8K ROM, 2K RAM and 10 ZP bytes.

I got a little demo going in pymon65 which plugs in a (tiny!) RAM disk driver hosting a standard prodos disk image and then interacts with it via the MLI.

Next I'll hook up one of the 6502 SD card block read/write routines - this should give me r/w access to up to 14 x 32Mb prodos volumes on an SD card with a full-featured FS. Almost half a gig of storage seems like more than I'm likely to need... (I remember back in the day plugging in a 20Mb hard drive to my Apple //e and wondering how I could ever come closing to filling it

Great work.
Nice to have a native choice from FAT now too.

As for the 20MB drive - Yea, I had a Symbfile back then - never thought I'd fill it then..

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Got this working on my ben-eater breadboard! Cool to see it going on real hardware.

I did take me a while to remember that his address decoding has an 8Kb "hole" in it, and unsurprisingly mapping the
prodos work space there led to unpredictable results...

Anyway, I repackaged the prodos 8 filesystem kernel as a relocatable ca65 object file (see https://github.com/patricksurry/p8fs).
Then I connected the SD card pairing VIA with an incoming SR for SPI-mode0, and wrote the block read/write driver routine
that prodos wants, linking with the p8fs kernel (my hacky breadboard code is at https://github.com/patricksurry/breadboard-rom).

I created a 32Mb prodos volume with a test file on it (see https://github.com/patricksurry/pyprodos or
use your favorite apple emulator tool) and wrote it to the raw SD card device.
Prodos uses a 2 byte block offset, and the SD card uses a 4 byte index, so I use the prodos unit number (0-14)
as byte three in the SD index giving us 14 x 32Mb separate addressable volumes on the SD card.

Then I used the regular prodos MLI routines (see https://prodos8.com/docs/techref/calls-to-the-mli/)
to open and read /DEMOVOL/README which in my example is the opening paragraphs of hitchhiker's guide
(which you can kind of read on the tiny LCD).

This gives almost half a gig of storage (still only 1/64th of my 32Gb SD card lol) and should be easy to boot directly from the
SD card.

Well done!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

That is some amazing breadboard work. I should have mentioned this earlier since you wanted ProDOS support - here is a super minimal ProDOS interface file: https://github.com/peterferrie/prorwts
Very useful in memory constrained devices.

Peter uses it to port single load DOS games to ProDOS compatible devices and used in the Lawless Legends game (which also happens to use PLASMA): http://www.lawlesslegends.com/