Re: firmware for the PseudoDisk

[bieling@terra.es]

Alex Freed ha escrito:

> <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.

Have you considered using some spi RAM instead ?

8 kBytes : <http://www.nanoamp.com/datasheets/N64S08xxHDA.pdf>