Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: An asynchronous track-by-track disk copier... Message-ID: Date: 14 Apr 90 08:31:00 GMT References: Distribution: comp Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 122 In-Reply-To: mt87692@tut.fi's message of 13 Apr 90 15:52:39 GMT In article 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.} :-) 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.