Re: firmware for the PseudoDisk

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

<bieling@terra.es> wrote in message
1163245007.337812.260720@f16g2000cwb.googlegroups.com">news:1163245007.337812.260720@f16g2000cwb.googlegroups.com...
> Who is going to translate prodos blocks to sd blocks ?
> The 6502+prodos driver or the AVR+code inside it ?

AVR. One nice person reading this newsgroup is donating his
FAT implementation to the project.

>
> Alex, when you say "The hardware works great."

I have to qualify this statement. Glenn Jones reported problems with IIGS.
Probably only works at 1 MHz speed. I need to look into it.

> The firmware is very
> simple but seems to do the job. There is a huge room to improve on it:
> the code takes a small fraction of memory even though it is written in
> "C"." you're talking about the avr code, I think, yes ?

Yes, I was talking about the AVR code, but ALL of my code could
use improvement: I'm mostly a hardware guy :)


>
> If so, do you think that there's enough space left (in the AVR) to add
> code to parse a *fat16* filesystem and (pre) build (at boot time) and
> keep in AVR's ram a prodos-block to sd-physical-block *table* given an
> image file as the parameter, so that the translation is done
> "transparently" for the 6502/apple2 prodos driver ?

That's exactly what I'm planning to do. Using donated FAT code.
The only trouble is that the AVR ATMEGA88 only has 1K of RAM
total. So we can definitely keep a table of 13 physical sectors that
represent one track of a NIB image in AVR's memory. It is also
easy to keep a table of the mapping of the directory area sectors
of a ProDOS volume. But in general every time ProDOS asks for
a block, the AVR code should traverse the FAT to get the physical
address. In fact there is no space for the FAT either so it will
have to be re-read from the card. So the bad news is that FAT makes
seek operations much slower. The good news is AVR is running at 16 MHz
and SD memory is pretty fast.

-Alex.