Disk Checkout For 2040, 4040, And 8050 Disks
Jim Butterfield Toronto, Canada
Last month, in Part I, a method of communicating with the disk drive in machine language was outlined. Here, the techniques are brought together into one program (a mixture of machine language and, BASIC). The BASIC part is:
100 OPEN 6, 8, 15 110 PRINT #6, "10" 120 OPEN 2, 8, 3, "#" 125 SYS 1200 190 CLOSE 2 : CLOSE 6
The article concludes with a program which will perform quality checks on disks and can also recover scratched disks. The Disk Checkout program will work on all disk units. For the new single-drive disk units, type S when you are asked for the Drive #.
Here's a listing of the complete machine language program:
; select command channel 04B0 A2 06 LDX #6 04B2 20 C9 FF JSR SWITCHOUTPUT ; send U1 message 04B5 A2 00 LDX #0 04B7 BD 0A 05 ULOOP LDA UMESSAGE, X 04BA F0 06 BEQ QUIT 1 04BC 20 D2 FF JSR OUTPUT 04BF E8 INX 04C0 D0 F5 BNE ULOOP 04C2 20 CC FF QUIT1 JSR RESTOREIO ; send B-P message 04C5 A2 06 LDX #6 04C7 20 C9 FF JSR SWITCHOUTPUT 04CA A2 00 LDX #0 04CC BD 19 05 BLOOP LDA BMESSAGE, X 04CF F0 06 BEQ QUIT2 04D1 20 D2 FF JSR OUTPUT 04D4 E8 INX 04D5 D0 F5 BNE BLOOP 04D7 20 CC FF QUIT2 JSR RESTOREIO ; GET VALUES 04DA A2 02 LDX #2 04DC 20 C6 FF JSR SWITCHINPUT 04DF A2 00 LDX #0 04E1 20 E4 FF READ JSR GET ; convert to hexadecimal 04E4 48 PHA 04E5 4A LSR A 04E6 4A LSR A 04E7 4A LSR A 04E8 4A LSR A 04E9 20 FD 04 JSR HXPRNT 04EC 68 PLA 04ED 20 FD 04 JSR HXPRNT 04EC 68 PLA 04ED 20 FD 04 JSR HXPRNT 04F0 A9 20 LDA #$20 04F2 20 FF D2 JSR OUTPUT 04F5 E8 INX 04F6 E0 08 CPX #8 04F8 90 E7 BCC READ 04FA 4C CC FF JMP RESTOREIO ; hex conversion subroutine 04FD 29 0F HXPPRNT AND #$0F 04FF 09 30 ORA #$30 0501 C9 3A CMP #$3A 0503 90 02 BCC NUM 0505 69 06 ADC #$06 0507 4C D2 FF NUM JMP OUTPUT ; canned messages : U1 and B-P 050A 55 31 3a 33 20 30 20 31 38 20 30 30 0d 00 0519 42 2d 50 3a 33 20 31 0d 00
Putting It Together
Type in the BASIC program first. Now, call the Machine Language Monitor with SYS4 and display the desired part of memory with .M 04B0 0520–you'll see whatever values are currently in memory. Ignore them; move the cursor back and type over so that you get:
04B0 A2 06 20 C9 FF A2 00 BD 04B8 0A 05 F0 06 20 D2 FF E8 04C0 D0 F5 29 CC FF A2 06 20 04C8 C9 FF A2 00 BD 19 05 F0 04D0 06 20 D2 FF E8 D0 F5 20 04D8 CC FF R2 02 20 CS FF R2 04E0 00 20 E4 FF 48 4A 4A 4A 04E8 4A 20 FD 04 68 20 FD 04 04F0 A9 20 20 D2 FF E8 E8 08 04F8 90 E7 4C CC FF 23 0F 09 0500 30 C9 3A 90 02 69 06 4C 0508 D2 FF 55 31 3A 33 28 30 0510 20 31 38 20 30 30 0D 00 0518 00 42 2D 59 3A 33 20 31 0520 0D 00 00 00 00 00 00 00
Remember to press RETURN on each line to enter the values. One last change: display .M 0028 0028 and change what you see to:
.:0028 01 03 22 05 22 05 22 05
You may now return to BASIC (with .X) and SAVE the program if you wish. If you have carefully proofread the code, type RUN and watch the program do the same thing as in BASIC. The values are output in hexadecimal rather than decimal.
You may have noticed that we have done a lot of work to produce a machine language program that is bigger than the BASIC one we wrote in the first place. For our example, speed isn't much of a factor.
In doing so, however, we've established that you can indeed work a disk from machine language. And sometimes that can be very useful indeed.
Before I take a diskette "on the road," there are two things that I often want assurance about. First, are all the files good? Secondly, are the empty blocks in good condition?
This program tests the disk for these two properties, and adds a third: it will reclaim one scratched file if desired – and if the file is still intact on disk.
The program is constructed to work on 2040, 4040 and 8050 disks. On 2040's, however, it can only usefully perform the first of the three activities.
There's more to checking a file than seeing if it is there. Some of the questions that need to be asked are:
–Are all the blocks of the file OK?
–Are all blocks allocated?
–Is there conflict with any other file?
–Is the block count correct?
This program checks all of the above. In doing so, it has turned up a minor bug in the disk system: files joined with CONCAT and APPEND are likely to have the wrong block count. This doesn't hurt anything, but gives you misinformation on your directory listing.
The files are shown on the screen as they are checked. If there is an error, the program will stop with an error notice. See the note below on errors.
If you plan to write on a disk, and aren't sure everything is in good order, option two, checking blocks, is convenient.
The program reads all blocks and ensures that they are in sound working order. 2040 type disks (DOS1) can't be checked in this way; when a 2040 diskette is new-ed, all blocks are not written. This program checks by reading, not by writing; it can't do a valid job if some blocks have never been written.
The blocks and sectors are shown on the screen as they are checked. If there is an error, the program will stop with an error notice. See the note below on errors.
The program searches the directory for the names of scratched files and asks you whether you want to recover any file. When you say yes, you will be asked to identify the file type – this information was lost when the file was scratched. Then, a number of checks are very carefully made:
–Are all blocks good?
–Are all blocks free?
–Is the block count correct?
If the file passes all the above tests, the unscratching takes place, and the disk is asked to perform a VERIFY/VALIDATE/COLLECT which re-allocates the blocks.
Only one file can be reclaimed during a run. Multiple runs can unscratch many files, one at a time. The reason for this is related to the safety interlocks. When you reclaim a file, its blocks will be re-allocated. If you attempt to reclaim a second file and somehow its blocks conflict with the first file, this will be spotted: an allocated block will be found and the unscratch will not take place. If the program had been constructed so as to reclaim a whole series of files in one shot, this level of protection would have been lost.
The program is written entirely in BASIC, so a user can modify it to his particular needs. Except for a very small part of un-scratch, the program does not write to the disk; it only reads. Be aware, however, that closing a direct channel will force a BAM write to take place; this makes it desirable for a program to run through to completion rather than be stopped halfway through. See the error note below.
The Block Availability Map (BAM) is printed, and this may be an interesting thing to view for users who are not aware of the disk's organization. The centre track (track 18 or 39) is reserved for the directory, and file space is allocated close to this centre track where possible; this minimizes drive head movement. When a file is written on a track, it is not written to consecutive sectors, but "hops around" in order to optimize speed.
The program decides what sort of disk it has based on information supplied by the diskette itself. Thus, a 2040 diskette placed into a 4040 drive will be recognized as being 2040 format.
The directory is read from disk the "hard" way – as a bit map. This allows us to see things that a "normal" directory won't tell us, allowing us to find file starting locations and to see scratched files if we wish.
This program won't attempt to read a disk which is bad format. If you can't initialize a disk, this won't help you.
If the program stops on an error, we have a delicate condition – an opened direct file. Unless you really know what you're doing, I would recommend removing the diskettes and turning the power off the disk unit.
If you find a problem on a disk, get it out of your inventory as quickly as possible. Copy the files you can salvage over to a fresh diskette. Diskette problems don't solve themselves: once a disk is in trouble, the errors can propogate and eventually harm your good files. It won't happen often; but none of us need to have it happen even once.
Copyright © 1981 Jim Butterfield