Disk Checkout For 2040 4040 And 8050 Disks

Part II:

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.

Disk Test

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.

Checking Files

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.

Checking Blocks

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.

Un-SCRATCHing

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

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.

Error Procedures

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.