Re: D64 with IDE64 and a parallel connected 1541... record beaten!?
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  

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