Mixing and Matching Commodore Disk Systems

Jim Butterfield

The computer and the disk are separate devices. They communicate only over the IEEE-488 bus. Any Commodore disk can be worked by any PET/CBM system (except the original ROM systems which have an IEEE bus problem).

The newer computers and newer disks seem to work well together. But you can mix and match older systems with the new to suit your own special requirements.

First, a little terminology. "New disk" doesn't just mean the 77-track 8050 unit. The 2040 units can be fitted with equivalent logic which provide auto-initialization, file append, and relative files. New 2040's will be shipped that way, and old ones can be retrofitted with new ROM sets. Disk units that have the new features will be referred to as "DOS 2.0" systems; the original 2040 units without the extra features will be "DOS 1.0" systems.

Similarly, the 80-column computers give you new Basic commands such as SCRATCH or APPEND; but you can also get these features on newer 40-column machines, and some older machines can be retrofitted. Systems with the new Basic commands will be called "Basic 4.0"; the earlier upgrade ROMs will be referred to as "Basic 2.0". The very first PET units with original ROMs won't be mentioned here; they don't work disk at all.

Why keep the old?

There are a number of reasons that a user might prefer to stay with an older disk or computer ROM.

On his computer, he might have machine language programs that might be difficult to upgrade. He might need all of his spare ROM sockets. Or he might just like the old system and see no reason to pay extra money to go to the new. If he has an early model PET, the new Basic 4.0 might not fit — it requires an extra ROM socket that just isn't there.

On his disk, he might not want to give up a little capacity on the new system: DOS 2.0 gives only 664 blocks as compared to 670 on DOS 1.0, and the directory capacity is trimmed to 144 entries as compared to 152. He might have direct access files which depend on the old allocation patterns of the DOS 1.0 system, and views conversion as too much trouble.

My personal view is that disk upgrade is desirable, but computer upgrade is optional and a matter of preference.

New Computer, Old Disk

It's quite easy to work a DOS 1.0 disk unit with a new Basic 4.0 computer.

You must remember to initialize each new diskette as it's inserted into the unit. The usual way is:

OPEN 15,8,15,"10" — or any similar sequence.

All of your new Basic commands will work well, except APPEND and RECORD. These will be sent along to the disk, but the disk unit won't understand and will return a SYNTAX ERROR message.

Of course, you can't open a file using the L option: relative files are unknown to a DOS 1.0 unit.

But everything else will work nicely, and you'll have the convenience of commands like CATALOG or SCRATCH to make things easy.

One caution: If you should happen upon a disk that has been initialized on a DOS 2.0 drive, don't try to write on it with your DOS 1.0 system. It might work, but it might also wreck the diskette information. Copy the files over to a disk of your own and you'll be free to make all the change you like.

Old Computer, New Disk

All of the old disk features are preserved. You won't need to initialize, which is a great convenience.

You'll probably want to use that old standby, the DOS Support Program (the "wedge") to help in cataloging and error checking. No problem; everything is as it was before.

When you want to exploit the new features of your DOS 2.0 disk unit, you'll have a little more work. Appending is quite easy. As an example, suppose you have a sequential file called RABBIT and you want to tack some records onto the end. You just open with:

OPEN l,8,3,"0:RABBIT,A"

..and you're ready to write the extra records. As usual, don't forget to close the file when you're finished.

Handling the new Relative files requires careful coding. You should, of course, read up on this type of file in the manual first. In some ways a relative file can be handled in the same way as a sequential file. The big differences are in two areas: opening the file; and at a later time, positioning so as to read or write a specific record.

To open a relative file the first time, you use a conventional OPEN statement. An example will illustrate the method. Suppose we want to write a relative file called RANDFIL, with each record to be no longer than 25 characters. We would write:

OPEN 1,8,3,"0:RANDFIL,L," + CHR$(25)

Following this, as usual, we would write records to this file — as many as we think we need — and then CLOSE 1. The records may be blank, but we should write then anyway since we are building the framework into which data will later be placed.

At a later time, we will wish to read or write a specific record in the file. We open the file with a conventional statement:

OPEN 2, 8, 4, "RANDFIL" : OPEN 15, 8,15

and now we want to position the file to read or write a given record. Let's say we want to write to record-number 30. We code:

PRINT#15,"P" + CHR$(96 + 4) + CGR$(30) + CHR$(0) + CHR$(1)

What's happening here? Well, the P stands for Position; it's the same as the RECORD command in Basic 4.0.

The CHR$(96 + 4) identifies the file as secondary address number 4. The disk unit needs this to identify the file that's needed; going back to the OPEN statement, it will see that file RANDFIL is the one that's wanted.

CHR$(30) + CHR$(0) says that we want to go to record number 30. The second value is the high-order byte (multiples of 256). If we wanted record number 800, this group would be CHR$(32) + CHR$(3).

Finally, the CHR$(1) means that we want to read starting at the first character in the record.

After the positioning is complete, you can then INPUT# or PRINT# in the same way you would for a sequential file.

Summary

You can mix and match disk and computer if you wish. Sometimes it's a little more work to get the most out of the available features, but it's all there.

I sometimes wonder if Basic 4.0 isn't a little too cosmetic. Users may forget (or never find out) that COLLECT is translated to V (for Verify), or that HEADER becomes N (for New). And perhaps they won't need to know such things — their computer will take care of it all for them.

But dedicated users who plunge into the under-world of Machine Language programming will need to know these details. If they know the secret codes, they too can mix and match — but that's another story.