Antitrack_at_networld.at
Date: 2007-12-05 17:16:30
Hi Ruud et al,
Quoting ruud.baltissen@abp.nl:
> I will upload an improved version of the page this evening.
>
> Sorry for any inconvenience.
No problem. :)
> @ATT
>
> > I have read your post saying that you were using "256 bytes of 512
> bytes of each harddisk sector". Didn't you say this?
>
> But what is the problem?
The problem is, i was thinking ahead about too many details that I haven't
spoken out, since everyone here on the list knows them already, and thus I was
assuming too much, so to say, but anyway... :-)
Let me explain: What I was thinking is, that maybe we only ought to store the
GCR sector data to any suitable harddisk sector in a "reasonable" scheme.
That "reasonable" scheme - already implicitely used in your source, if I'm not
mistaken altogether, is:
read track 1 sector 0 from 1541, (sector data only, 324 gcr bytes not-converted)
write to harddisk sector 12345
read track 1 sector 1 from 1541, (sector data only, -""-)
write to harddisk sector 12346
read track 1 sector 2 from 1541, (sector data only, -""-)
write to harddisk sector 12347 ....
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
a) a waste for me and
b) would make it more difficult to convert the "wanted" sector GCR data to D64
format, ultimately, since grabbing the GCR data out of the "binary mess" of a
mixture of binary stored mess of (SYNC/GCR HeaderData/SYNC/GCR Sector data/GAP)
is simply less convenient. You have to shift all 324 bits GCR Sector data as
many times as the actual Sync size is, and the sync size *can* vary.
So, yes, if the 1541 drive can handle the GCR mess much easier than any PC
would do it, (by using SYNC) I was assuming that the 1541 indeed should handle
all the "problems" with findinf the SYNC etc. - instead of dumping all 1541
data including SYNC marks to the harddisk.
That was my assumption. Sorry for that. :-)
> Maybe this will clear things: an harddisk
> sector contains 512 bytes. Using an 8 bits interface means that one can
> only access 256 of these 512 bytes. Writing $00, $01 .... $FF to a
> sector with my interface and reading the same sector using a PC will
> give $FF, $00, $FF, $01, $FF, $02 ..... $FF, $FE, $FF, $FF.
Ah yes, this makes it much more clear for me. You cannot store more than 256
bytes because you don't have a 9th line providing that extra bit of information
for storage? Hmmm. Bit sad, that. Can't we grab some 1541 line somewhere? :-)
> > How are you going to map this to several harddisk sectors, then?
>
> There is a register to tell the harddisk how may sectors you want to
> access in one go. So writing 8192 bytes = 32 sectors in a row is no
> problem. But you MUST complete the process. If there are only 8000 bytes
> on a 1541 track, you must add the missing 192 bytes. When not writing
> all 512 bytes to the disk for a sector, you run the risk that the sector
> is not written from the buffer to the actual disk.
Oh, now I understand why you would want to simply dump $8000 bytes from the
1541 to the harddisk. As long as all sectors are neatly in place, (track 1
sector 0 followed by track1 sector 1, t1s2, t1s3 etc.) this is clearly very
effective in storing all 1541 sector data in one reading-revolution to the
harddisk.
But, I'm also concerned with using the PC for getting out a "neat" d64 image
out of all the GCR mess.....
Yours
Antitrack
--------------------------------------
Ein Service von http://www.networld.at
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.