Classic Computer Magazine Archive COMPUTE! ISSUE 46 / MARCH 1984 / PAGE 172


Larry Isaacs

This month we'll cover two topics. First, we'll add a RESET switch so you can easily recover from a program "crash," and then we'll discuss file access for the 1541 disk drive.

When you're using some of the special hardware features of the 64, and especially when you're experimenting with machine language, a simple mistake can cause the 64 to crash. The display just sits there, if there is a display; nothing happens when keys are pressed; and even pressing RUN/STOP—RESTORE doesn't help.

In such cases, it takes a reset to bring the 64 back. Naturally, turning the machine off and back on is one way to recover from a crash. Unfortunately, this means that the contents of RAM will be lost, including the program you were working on.

There is another way to reset the computer, without turning it off. You can connect a switch to the User Port to trigger the reset sequence.

A Clean Start Out Of The Gate

As you would expect, the 6510 microprocessor contains some complex circuitry. If the microprocessor is to operate properly, all the various parts of this circuitry must work together in an exactly defined set of steps. A RESET signal gets everything synchronized. When this signal is grounded, the 6510 is forced through a sequence, like horses going into the starting gate to get ready for a race. When the RESET signal is released from ground, all the processor's components start off together.

At this point, the 6510 is ready to start executing machine language instructions. But where will these instructions first come from? The reset process also deals with this question. The first thing the 6510 will do after the RESET signal is released is fetch two bytes from the top two mem-ory locations in the 64. These bytes are the starting address for executing machine instructions. Two such bytes, used to form an address, are called a vector; the two bytes mentioned above are called the RESET vector.

RESET Without Losing The Program

You have access to the RESET signal through two pins in the User Port (the rightmost connector as you face the back of your 64). Triggering a RESET through the User Port will cause a RESET without turning the power off (and memory contents will not be lost). There is a good chance that the program you were working on will still be intact. You can save a fair amount of time while experimenting and debugging by not having to reload the pro-gram every time.

To construct a RESET switch, you will need the following items:

1 Momentary contact switch (SPST)
1 24-pin card edge connector
  (contacts on .156 inch centers)

You will also need a small amount of wire (preferably stiff wire) as well as a soldering iron and a little solder. If you aren't good at soldering, perhaps you can find a friend who can do the construction for you.

The construction involves connecting one terminal of the switch to pin 1 on the card edge connector, and the other terminal on the switch to pin 3 on the connector:

When construction is finished, plug the connector onto the 64 User Port (with the computer's power off), making sure that the terminals with connected wires are on top. With your switch in place, if your program crashes you just press the switch, and your 64 is RESET.

If you are working strictly with machine language, you may be able to continue working with your program immediately after using the RESET switch. If you are working with BASIC or are using the DOS Wedge, you must do a little more work to get things back to normal. To restart the DOS Wedge, execute the following command:

POKE 186,8:SYS 52224

The first POKE is necessary to put the 1541's device number where the Wedge expects to find it. Normally it would be put there automatically when the Wedge is loaded from disk. The SYS command links the Wedge into BASIC again.

Recovering A BASIC Program

When you are working with BASIC programs, using the RESET switch will effectively perform a NEW on your program. To recover the BASIC program, a small machine language routine will be necessary. The following program will POKE the required routine into memory.

10 AD = 49152:FOR I = 0 TO 21
30 DATA 169,8,141,2,8,32,51,165,24
40 DATA 165,34,105,2,133,45,165,35
50 DATA 105,0,133,46,96

As written, the routine should be located at 49152 ($C000). The routine will run correctly no matter where it is placed, provided it is some place out of the way. You could put the routine in the cassette buffer by simply setting AD to 828 in line 10. You should execute this program before beginning your experiments with the program under development. Should you be forced to use the RESET switch, you can recover the BASIC program by executing the command:

SYS 49152:CLR

As you might guess, this will also recover a program which has been inadvertently NEWed. The CLR command is necessary to clean up some pointers that BASIC uses to locate where variables and arrays are to be stored.

Finding The Variables Again

Unfortunately, there isn't an automatic way to recover the old values of the variables or arrays. Recovering arrays is too complicated to be practical. However, some of the variables can be recovered, provided you have an idea of how many there were. To recover a given number of variables, substitute that number for n in the following command:

?PEEK(45) + PEEK(46)*256 + 7*n

Substitute the value printed into the N in this additional command:


At this point you should be able to print the values of the first N variables created by the BASIC program, assuming there were that many.

When you're working with machine language programs, the RESET switch can be especially handy. In addition to not having to reload your programs all the time, the variable storage used by the machine language program should still be intact. This can be very helpful in determining where in the program the crash occurred.

A Corrupted Program Must Be Reloaded

As mentioned before, the great majority of memory will be left unchanged after the reset. How-ever, there is a possibility that the program was accidentally corrupted by the crash. Therefore, if you must be sure that there is a good copy in memory, you should reload the program. This obviously implies that you saved a copy before you tried it out.

But for simple experimentation, you can assume that the program in memory is still good and simply execute it again. If it crashes right away, or in a different manner, it may be time to reload the program.

If you've managed to live without a reset switch this long, you may wonder whether you should bother building one. When you are debugging a program which crashes the machine, anything which can help minimize the frustration is desirable.

File Access And The 1541

Now to look some more at the 1541 disk drive. Fortunately, we have a nice thick reference manual for the 64 to provide lots of detailed information. Unfortunately, the Commodore 64 Programmer's Reference Guide doesn't cover the 1541 disk drive. Instead, we are left with the 1541 User's Manual, which isn't totally accurate or clean. To help fill this gap, I will pass on any interesting bits of information I can discover concerning operation of the disk drive.

How many disk files can be open at one time? The only hard facts I could find in the 2542 User's Manual were under DOS Error Message 70: NO CHANNEL. Here it states that six "direct" access (which I assume to mean random access) or five sequential files may be open at one time. From previous experience, I knew these numbers were not correct.

Since my experiments gave inconsistent results, I am unable to give you a simple answer to the question. Instead, I'll just tell you what I observed, and not try to explain it.

Maximum Of Three Sequential Files

First of all, I was able to open only four random access channels before getting the NO CHANNEL error message. This implies that only three sequential channels may be opened at one time. This I found to be true, provided only one of the three files was opened for writing. Opening three sequential files for writing resulted in an error. It's interesting that opening three sequential files did not result in a NO CHANNEL error, rather there was a DRIVE NOT READY error (74).

Opening two sequential files for writing and one for reading was accepted by the disk drive, provided that the one for reading was opened last. If the file for reading was opened first or second, a DRIVE NOT READY message was returned by the disk drive. Because of this inconsistent operation, I would open no more than two sequential files for writing.

As for relative files, it appears that only one relative file may be opened on the 1541 at one time. Opening a relative file in conjunction with a random access file or sequence file resulted in the same inconsistency as opening two sequential write files. If the relative file was opened first, another file, random or sequential, could be opened afterward without complaints from the disk drive. However, when a random or sequential file was opened first, opening a relative afterward caused the NO CHANNEL error.

Mixing File Types

From these observations, I would say it's safe to use up to four random access files at one time, three squential files (with only one opened for writing), or one relative file. It should also be possible to mix some random access files with sequential channels, if desired. My experiments did not involve reading or writing data to any great extent. To be thorough, this should be done as well. I may be able to report on further experiments in my next column.

I will also try to verify if the 1541 drives currently being sold show the same symptoms as my drive. It is possible that the software inside has been upgraded since I obtained my drive, though I haven't heard any reports of this.