🚀 go-pugleaf

In article <DEVEN.90Apr13071330@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes:

[ lot of program description deleted ]

> Unfortunately, in practice, the blitter is a bottleneck in the I/O,
> since the trackdisk.device uses the blitter for encoding, decoding and
> shifting the tracks.  Hence, the async copy tends to run lockstep
> waiting for the blitter, which is beyond my control.  Perhaps ECS or
> 1.4 trackdisk might be better.  Anyway, it would have been nice if an
> asynchronous copy could have done at the speed of a format, (i.e.
> about 50 seconds) but actual timings have always been between 83 and
> 84 seconds, which is still pretty good.

> Deven

 Can trackdisk.device read tracks without MFM-decoding? If it can't, don't
 use it, but instead take all disk-control for yourself (dunno how, never
 programmed anything with multitasking) and use direct IO-calls in hardware
 registers, so you don't have to decode data. There is no use to decode
 the data if you are just copying it. 
 IMHO Why are you making this program since for example PCopy does all you
 want, only with two drives, but there are lot of one-drive copiers around.
 And they are as fast as the theoretical copying speed (NumberOfTracks(160)/
 SpinsInSecond(5)*2(Both read and write(3 for verify))) which something like 
 64 sec. and with verify 96 sec. Thats because there is only one dma-slot for 
 disk-drives. You can have multiple drives spinning but only one disk can be 
 accessed at a time.
 
  MIT




--
-----------------------------------------------------------------------
: Mikko Tsokkinen         : I'm not a number ... I'm a free man       :
: Internet mt87692@tut.fi : UUCP tut!mt87692 : Bitnet mt87692@fintut  :
-----------------------------------------------------------------------