🚀 go-pugleaf

In article <DEVEN.90Apr13071330@netserv2.rpi.edu> I write:

[ lot of program description deleted ]

Deven> Unfortunately, in practice, the blitter is a bottleneck in the
Deven> I/O, since the trackdisk.device uses the blitter for encoding,
Deven> decoding and shifting the tracks.  Hence, the async copy tends
Deven> to run lockstep waiting for the blitter, [...]

On 13 Apr 90 15:52:39 GMT, mt87692@tut.fi (Mikko Tsokkinen) said:

Mikko> Can trackdisk.device read tracks without MFM-decoding?

Yes.  TD_RAWREAD and TD_RAWWRITE.

Mikko> If it can't, don't use it, but instead take all disk-control
Mikko> for yourself (dunno how, never programmed anything with
Mikko> multitasking) and use direct IO-calls in hardware registers, so
Mikko> you don't have to decode data.

Well, not exactly...  I don't want to deal with the hardware directly.
No need to, no value in it.  Trying raw reads and writes is a
possibility, but I don't know if it will work.

Mikko> There is no use to decode the data if you are just copying it.

Maybe, maybe not.  See below.

Mikko> IMHO Why are you making this program since for example PCopy
Mikko> does all you want, only with two drives, but there are lot of
Mikko> one-drive copiers around.

Partly, I wanted to see if an asynchronous copy would really fly (as
it seemed it ought to) or not.  It doesn't fly, but the speed isn't
awful.

Mikko> And they are as fast as the theoretical copying speed
Mikko> (NumberOfTracks(160)/ SpinsInSecond(5)*2(Both read and write(3
Mikko> for verify))) which something like 64 sec. and with verify 96
Mikko> sec.

You're not taking into account seek time...

Mikko> Thats because there is only one dma-slot for disk-drives.  You
Mikko> can have multiple drives spinning but only one disk can be
Mikko> accessed at a time.

For actual data transfer, sure.  But I expect of the time it takes to
transfer a track to memory, raw data transfer from the drive seems
unlikely to be more than 20% of the entire time -- the rest would be
the blitter decoding and aligning the track.  I could be wrong here,
but decoding the MFM is rather a bit more complex a task than blasting
the data off the drive into memory.

Yes, the bus is still going to be locked for the blitter, but I don't
believe it's data transfer time -- just decoding time.  (The shifting
operation can't be too hard; it probably takes an amount of time
similar to that of transfering the data from the drive.)

As for the idea of using raw reads and writes, it's a good thought,
but there are possible complications.  Most importantly, it would NOT
work correctly to simply read a raw track and write it back out.
Okay, it might, but it's unlikely.

Consider how the trackdisk.device deals with the drive.  To read a
track, it simply starts a DMA transfer from the drive from wherever it
may happen to be.  It reads slightly MORE than a full track, likely 12
sectors' worth.  (There being 11 sectors/track.)  [12 sectors + track
gap length, that is.]  {this is a guess.}  <this is too many
parenthetical notes.>  :-)

It then searches from the start of the read-in data for the start of a
new sector.  It uses the next 11 sectors in the buffer as the track
read, using the blitter to shift the entire track buffer to start with
the new sector, and then it does another shift for the sectors in the
track buffer which are after the track gap, so the gap is moved to the
end of the buffer.  Then it does a few tricky operations with the
blitter to decode the MFM into actual data.  Maybe I missed something
in that description, but that's the basic idea.

Now, if I read a raw track, I don't think the trackdisk device will do
the shifts with the blitter to align to a sector start and move the
track gap.  Perhaps it does; I'll make a point of checking next chance
I get.

Assuming it doesn't, I see a definite problem -- I read a raw track
and have data for a track which probably starts in the middle of the
sector.  If I just write this as is on the destination drive, how much
would you care to bet that the alignment and speed of the drive is so
perfect that it finishes in the middle of that same sector such that
when read back in that sector can be decoded correctly?

Now, if the trackdisk device DOES do the shifts on a raw read, then it
should work fine; you're right that I don't need the MFM decoded
myself; I'm only copying it, and the encoding comes out to the same
thing.  On the other hand, will a TD_RAWWRITE work correctly to an
unformatted disk?  I would assume it should work if I write a full
track.

If for some reason I must use TD_FORMAT, then I'm stuck with decoding
and encoding again.  [I don't have to do this, right?]  I guess a
relevant question is: Is there a difference between a full-track write
with CMD_WRITE or TD_FORMAT?

If the trackdisk doesn't do the shifts, I could grab the blitter and
do it myself; it's just more work.  But if I can do the copy without
decoding the MFM, it should speed things up considerably.

One important question -- is it possible that such a raw copy could
INCREASE the probability of an error on the copy?  And if I do a
verification read on it, if the MFM-encoded data matches, am I clear,
or MUST I decode the MFM to be sure it's not garbage?

This is getting long again.  *sigh*

Deven
-- 
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2151 12th St. Apt. 4, Troy, NY 12180   Phone:  (518) 274-0327
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.