hah@isum.intel.com (Hans Hansen) (07/07/87)
I noticed while downloading with Facc running that when I format disks the verify is too fast, i.e., out of RAM rather than from the disk. Perry, please include the ability to turn off and on Facc to any given disk drive. Hans
scotty@l5comp.UUCP (Scott Turner) (07/10/87)
[I'm back, hide your CATS and flame throwers ;)] In article <861@omepd> hah@isum.UUCP (Hans Hansen) writes: >I noticed while downloading with Facc running that when I format disks the >verify is too fast, i.e., out of RAM rather than from the disk. > >Perry, please include the ability to turn off and on Facc to any given >disk drive. Actually there is no need to turn verify off. Rather Perry should NOT cache those sectors that have been formatted. :) Time to tie together a few points that have been collecting in my mind... First, the format command is identical to the write command. In fact in the original MicroForge driver for my system they used the same code for the format handler and the write handler! HOWEVER, write and format DO have differences. But there are only two real things to worry about: 1. Formats occur on TRACK boundaries, not sector boundaries. 2. Formats write where no data may have been written before. Thus the underlying media may require initialization. In reality the name "FORMAT" is not really very descriptive. The format command is in reality a "Track-Write" command. It's very tempting to treat the format command under this new description. If you ever write a "DiskCopy" program then you'll probably want to use format command to write data to the destination disk. :) But however you treat format there is one key that sets it apart from the write command. The format command is used for activities that one would not typically want cacheing. 1. Use in a "FORMAT" program. After a disk is formatted the only reason for reading the disk would be for physical verification. As pointed out one doesn't want a cache in the way here. 2. Use in a "DISKCOPY" program. First, data is already being moved wholesale. A cache will not provide any benifit to a program that is already doing large wholesale contigous reads/writes. And if the program is being run in VERIFY mode, a mode where is reads back the data it just wrote and checks it, we again don't want the cache involved. 3. Use in "DISKREPAIR" programs. FORMAT can be used with read to repair damage to a disk. One reads the disk, and the writes the data back out again with format. Then reads it back to see if the disk is repaired. Again, we don't want a cache involved here. There is an interesting item that comes up here. The fast directory program that used the GET_BLOCK packet to gain access to disk data had this curious behavior in which it could give "suprious" errors if it read blocks that had never been written to. The answer to this puzzle lies in two things: 1. The stock format program writes out a pattern of long words when it formats a disk and then reads this pattern back to check it. This pattern remains behind on the disk once formatting is complete. 2. The GET_BLOCK routine verifies the CHECKSUM and TYPE of blocks it is requested to read.... The blocks left behind by the stock formatter fail BOTH checks. :) This could be cured by having the format program use a pattern that results in the disk being full of empty data blocks that have valid checksums. This DOES have history behind it, CPM disks had to be formatted and left with all the sectors being full of hex E5's. Most other formatters I've dealt with leave the sectors filled with 0's etc. My p-System disk formatter for the Amiga leaves the sectors full of 0's for example. As for format and disk cacheing... When a format request comes in, any blocks in the cache for the blocks being formatted should be discarded. They should NOT be "updated" since if they're dirty they'll be written to the disk, that wouldn't be a good idea. :) And the data should NOT be cache'd. Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan Disclaimer? I own L5 Computing. Isn't that enough?
perry@well.UUCP (Perry S. Kivolowitz) (07/15/87)
Mike, Suggesting that Facc look for the data written by a format is one of the most maxed out kludges I have ever heard. Why not simply look at the incoming command? (As Facc already does). You may say that a write and format are the same. Maybe even they are implemented by the same code. But very simply, there is one com- mand for write. And another for format. I don't think my more detailed response (to Hans original posting) ever got out of New Jersey (figures). With the help of Carolyn Scheppner the cause of seemingly faster verifications during formatting has been found. The verification is NOT taking place from memory. Nope. Don't worry. But they ARE taking place faster. The verification IS actually running faster. Facc introduces a slight pertebation in process priorities which allows the floppy driver to get more undisturbed cycles. Normally this has no influence on the other processes on the machine but formatting is the only time the driver is asked to deliver 11K of data at once. The pertebation man- ifests itself here (in a positive way). P.S. FaccII programmer's manual is available at no charge to CBM certified developers. Send a stamped self addressed envelope to us (8.5 x 11 at least). This is prerelease information so you can get a head start making your next application FaccII compatible. Perry S. Kivolowitz ASDG Incorporated (201) 563-0529
perry@well.UUCP (Perry S. Kivolowitz) (07/15/87)
In article <3560@well.UUCP>, perry@well.UUCP (Perry S. Kivolowitz) writes: > Mike, I should have said Scott. Sorry.