RE: Order of sectors on a track

RE: Order of sectors on a track

From: ruud.baltissen_at_apg.nl
Date: Mon, 25 May 2009 08:11:49 +0200
Message-ID: <3FAF2D74FB701448B997B2CB7A0076C20F4C0B06@winsv116.office01.internalcorp.net>
Hallo allemaal, 


What should have been a lovely Sunday turned into a day full of hard
labour: for the first time in twenty years something infected my laptop
:( To be short, yesterday was a waisted day.



Hallo Patryk,


> you just get the next available sector and check whether you
> need this one 

The problem is that the header is GCRed as well. And decoding the header
after having read it takes too much time I already found out: the first
SYNC I was able to catch was of the next header ie. I missed the data
one. 

As waiting for the _known_ 4th sector worked out fine for track 25..36,
I decided to use this for the lower tracks as well. But the moment I
wanted to program my EEPROM, that virus, worm or whatever spoiled the
fun. This mechanism also has another advantage: If the sector order
isn't as expected, I still can be sure the right one is read. 


> and you don't have to wait for sec 0, etc..

One trick I still have in my sleeve is reading and decoding a header and
using the next header as starting point. This will save me 35 * 1/6 / 2
= 3 seconds in avarage.


> but the biggest gain is in GCR decoding 

I need 24.3 sec. to read the sectors. Which means I need 10 secs. for
changing tracks and finding sector 0. Make that 7 if the above trick
works. I now use 4 sectors for handling 1 sector = reading, decoding and
saving it to HD. Decoding and saving it to the HD in 1 sector seems
impossible to me. Doing everything in 3 sectors means 35 * 1/6 * 3 =
17.5. Plus the 7 seconds mentioned above gives 24.5. So I wonder how you
manage go as fast as 21.x sec. 
Hmm, I think I know: you mentioned speedloaders. They normally only read
the data from disk, they don't store it on another device as well as I
do. 
 


Hallo Spiro,


> This is what I described when I told about how the warp routines
> in OpenCBM and Star Commander work. But it seems I was ignored. ;)

No, you weren't ignored, but I cannot use the Warp routines because I
cannot use the GCRed data.
Regarding the 1571 routines, at this moment I cannot use them as I don't
know enough of how to use them; the sources I have lack a bit of comment
on this subject.


--
     ___
    / __|__
   / /  |_/     Groetjes, Ruud
   \ \__|_\
    \___|       URL: Ruud.C64.org

 
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de 
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te 
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit 
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. 
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige 
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij 
overgebrachte virussen.

APG Algemene Pensioen Groep NV is gevestigd te Heerlen en is ingeschreven in het handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged. 
It may be read, copied and used only by the intended recipient. 
If you have received it in error, please contact the sender immediately by 
return e-mail; please delete in this case the e-mail and do not disclose it's 
contents to any person. We don't accept liability for any errors, omissions, 
delays of receipt or viruses in the contents of this message which arise as a 
result of e-mail transmission.

APG Algemene Pensioen Groep NV is registered in the trade register of the Chamber of Commerce Limburg, The Netherlands, registration number: 14099617



       Message was sent through the cbm-hackers mailing list
Received on 2009-05-25 09:19:29

Archive generated by hypermail 2.2.0.