ruud.baltissen_at_abp.nl
Date: 2007-12-06 08:10:25
Hallo ATT,
Again an answer from home didn't reach the list :( Have to see the
reason this evening.
> That "reasonable" scheme - already implicitely used in your source,
> if I'm not mistaken altogether, is:
You are correct but take in mind, this is real data ie. non-GCR data.
> Well, at least I thought it still would be done like this (but
faster).
> Storing all the sector header GCR info to the harddisk seemed like
Storing GCR data or non-GCR data in this order has two disadvantages:
- With an interleave of 10 it takes at least 10 revolutions of the
floppy disk to read all sectors.
- You loose the information of the way the original sectors where
stored. Keep in mind: not every disk has the same sector layout as on
original 1541 disk.
So if you want to read GCR data anyway, just read it all, including
header info. Just look for a significant marker like sector 0. Read and
store the header. You know it is followed by a SYNC and then data. After
the data is another SYNC gap which is followed by the next header. What
number this sector has, is not important. The only thing that is
important is that track 1 has 21 sectors. So after reading 21 sectors
you know you are finished.
I know, the above cannot deal with abnormal formatted tracks but I leave
this matter to the experts :)
> and the sync size *can* vary.
That's correct. But IMHO there should be ways to calculate the length of
the gap between sectors. The length between an header and the data is
always constant AFIAK (5 $FF's IIRC). And in the worst case you always
can assume a fixed number of SYNC's between sectors, that's what those
fast formatting routines do as well.
Storing the correct calculated/fixed number of SYNC's to the disk during
reading the floppy has an enormous advantage: you can write the track in
one revolution.
> Bit sad, that. Can't we grab some 1541 line somewhere? :-)
2^8 = 256, 2^9 = 512. But we are dealing with data lines, not address
lines. In this particular case if you want to store twice as much data,
you need twice as much data lines.
> As long as all sectors are neatly in place, (track 1
They aren't and, as explained above, that isn't needed at all.
> But, I'm also concerned with using the PC for getting out a "neat"
> d64 image out of all the GCR mess.....
Star Commander does the same in warp mode: it reads the GCR data, stores
it on the PC where it is analysed and turned into a D64. If SC can do
the trick, why cannot do another program the same?
--
___
/ __|__
/ / |_/ 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.
Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer: 41074000
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 its 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.
Stichting Pensioenfonds ABP, having its registered office at Heerlen, is registered in the Traderegister of the Chamber of Commerce Zuid Limburg (Maastricht), the Netherlands, registration number: 41074000
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.