Re: firmware for the PseudoDisk

["Alex Freed" <alexf@mirrow.com>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
ef2dnQx2jrFXH8jYnZ2dnUVZ_tidnZ2d@comcast.com">news:ef2dnQx2jrFXH8jYnZ2dnUVZ_tidnZ2d@comcast.com...
>
> So you are suggesting a read-only FAT16 file system implemented
> as a boot-code selector to "boot" the chosen file (Apple volume)
> for actual use?

I'm not sure I understand the "read-only" part here. Once again the
simple implementation that I see is this:

1. There is always space on the disk (and memory card) before the
first partition. Only the first block is used for MBR out of the whole
track 0. So this space can be used to hold the 6502 "selection" code.

2. This code uses the ProDOS driver (6502 code at Cx00) to read the
FAT16 volume's directory and ask the user which image to use.
The image can be NIB or HDV.

3. A pointer to the image file (physical address of the first cluster)  is
passed to the AVR.

4. From now on AVR translates the sectors. For example a request of
the boot sector of a ProDOS volume will read the first block of the HDV
image.

5 ProDOS image can be written too, but it can't grow. In other words
all 32MB should be allocated when the image is written to the SD card.

>
> The booted OS would then use read/write drivers for to then carry
> out the two-level mapping as the OS runs from the pseudo-volume--
> in ROM, I expect.  The mapping to physical sectors is done
> transparently by code running on the card that understands FAT16, yes?

The booted OS only knows about the blocks of the volume. AVR translates
them to the physical blocks on the SD card.

-Alex.