Re: Wanted: a faster protocol for IEEE devices

From: Justin <>
Date: Wed, 18 Sep 2013 09:04:00 -0400
Message-Id: <>
I understand using it for speed up, but in context of archiving old floppies, I thought that the need for reading the whole track at once was driven by not being able to seek to a specific location, so for the copy protection systems that used unusual formatting, it was not possible to perfectly read themů so if you read the entire track at once, you would be able to capture everything regardless of funky alignment?

On Sep 18, 2013, at 8:59 AM, wrote:

> On 2013-09-18, at 14:31, Justin wrote:
>> Isn't the 8k mod for the 1541 part of dealing with the fact that its budget mechanism cannot seek to the same location repeatedly, so you have to read an entire track at once directly into RAM if you are trying to image it/copy it and it uses funky formatting for copy protection?  I thought the earlier more expensive mechanisms could do this?  If the mechanism reads more slowly than the IEEE bus can run, then shouldn't it be possible to write the read output from the mechanism to the bus as fast as the disk can be read?  Sorry, I don't have and have never messed with the mechanisms in question, but I always understood this to be a hassle that really only existed when dealing with the 1541.
> The 8KiB RAM in various 1541 extensions is generally used as a track buffer. It doesn't have much to do with the mechanism and "seeking to the same location repeatedly". It allows buffering whole track in one disk revolution, which in turn allows instant access to /every/ sector of the track, after ~0.2s buffering time only, without the need to wait until the desired sector arrives to the r/w head. In the theoretical best case this allows to speed reading up by factor of about 22 (if memory serves). Of course in real life the speed-up is smaller but still well worth the pain.
> -- 
> SD!
>       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list

Received on 2013-09-18 14:00:03

Archive generated by hypermail 2.2.0.