[Coco] Bechmarks

[Robert Gault]

Tony Cappellini wrote:
> Message: 9
> Date: Thu, 20 May 2010 13:19:25 -0500
> From: "Boisy G. Pitre"<boisy at tee-boy.com>
> Subject: Re: [Coco] Bechmarks
> To: CoCoList for Color Computer Enthusiasts<coco at maltedmedia.com>
> Message-ID:<40B035F2-8AAC-4872-9A3F-CF69AB3D1337 at tee-boy.com>
> Content-Type: text/plain;       charset=us-ascii
>
>>> Yes, there is some cost associated with sending commands to the device and awaiting the 512 bytes, then sending a similar command>>again and waiting for the next 512 bytes.  It does account for some percentage of time t
>
> What is the fundamental reason for transferring only 1 sector at a time anyway?
> Logically it doesn't make sense, so there must be some limitation
> imposed at some level.
>

The transfer won't really be one sector at a time at machine level unless you 
have some hardware device that can transfer 256 bytes in "parallel" mode. The 
Coco transfers are either byte or bit sized.

At a higher level, it makes sense to transfer blocks of bytes in the quantity 
corresponding to the receiving device specs. Our Coco disks are formatted in 256 
byte sectors, as required by the controllers. That makes it easier for file 
managers and disk I/O software to work with sectors when performing any I/O.

Now that we are moving into modern equipment formatted in 512 byte sectors or 
larger, some type of translation is required to handle these larger sector sizes 
and stay backwards compatible.
Given the OS-9 structure, you could write new file managers and drivers to work 
with 512 byte sectors only. Then you would need a second set to handle all the 
existing 256 byte sectors and floppy controllers.

It seems, far as I can tell, the minimum amount of work is to leave file 
managers alone and handle translation of sector sizes at the driver level.