silverdr_at_inet.com.pl
Date: 2005-11-22 20:05:56
On 2005-11-22, at 18:45, David Wood wrote:
>
> MV forgot also to mention that the IDE64 has to deal with deblocking
> 512-byte blocks into the 256 byte blocks the c64 expects.
>
Not really. C64 is actually filesystem agnostic. It doesn't expect
any fixed blocksize.
> I'm not sure if the FS assumes 512 byte blocks, but in the event
> that it
> does not, writing a 256 byte block involves three operations: Load
> the 512
> byte block, change one half of the buffer, write the block back.
In the 8bit world it's the Atari that suffers the problems you
mentioned. They have either to emulate the 256 bytes long blocks on
512 bytes long ones (MyIDE), effectively wasting half of the drive's
capacity or they have to do exactly what you describe (KMK/JŻ IDE)
causing the write performance to be about 1/4 of IDE64's.
> This is all done in PIO, resulting in 2k of aggregate IO bandwidth:
> Read
> 256-byte sector from gcr buffer, read 512-byte sector from ide,
> copy sector
> from buffer to ide buffer, write ide sector).
Luckily C64 doesn't have to "boot" DOS as Ataris do and IDE64
filesystem is built on top of 512 bytes long blocks. Of course
everything is done in PIO which means: read GCR into inbound buffers,
decode GCR2BIN and write BIN into outbound buffers, write, loop until
finished.
> IDE kinda sucks like
... like most PC inventions ;-)
> that on systems that rely on 256-byte sectors. I
> shudder to imagine all the work the CMD HD does to deal with the
> odball
> sector sizes
Again - C64 doesn't suffer this problem as DOS and its filesystem
implementation is left up for the peripheral device.
--
If you are using a new Macintosh running OS X then you probably have
[...] "daemons" on your computer, hardly something a good Christian
would want! - Dr. Richard Paley
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.