Interrupts are ... tricky

by Leonard Tramiel

Some early PET users reported that their machines would "hang". After doing ... something the machine would become unresponsive. Nothing short of a power cycle would get the machine back into operation. The hardware folk on the project said it was obviously a software problem and, not surprisingly, the software folk said it was a hardware problem. As mentioned in another entry here, there were some ... idiosyncrasies in the MOS memory being used. In particular the 6550 pseudo static RAM. This was an interesting(?) device, it had a combination of the characteristics of a static and a dynamic RAM but none of the advantages of either. Dynamic, as opposed to static, RAM has fewer pins so it greatly reduced the number of traces on the board but it needs external logic to generate the address signal and it needs a regular pattern of signals to produce a refresh signal. Static RAM uses simpler addressing so more pins but doesn't need to be refreshed. The 6550 had the simple addressing of static RAM but it still needed a "refresh" signal. The timings were ... strange.

I had left Commodore to pursue an advanced degree but I had a PET and some spare time so I thought I'd try to narrow this down. One of the best features of Commodore's 8-bit computers was the on screen editor. It allowed many unusual and interesting uses of the machine and one of those was that it made it possible for a BASIC program to modify itself. I thought that using this feature made the machine do the most work so I wrote that kind of program. It took a while but eventually I wrote a, thankfully short, program that would put the machine into this state. After a bit more tweaking it would enter that state reliably, in just a few seconds.

I called John Feagans and told him that I had made this problem repeatable. I figured that if he ran it on another PET and it behaved like mine did, it was likely a software problem, Otherwise hardware was likely the issue. In either case having a reliable way to cause the problem would make it far easier to diagnose and eliminate. I read him the program. That was the fastest way to get the program to him at the time, at least with the equipment, or lack thereof, I had available. When he typed in the program we typed in RUN and hit return at the same time. I said "Three, two, one, die". John responded with one of the few times I can remember him swearing.  His machine died at the same time mine did. That made it likely that it was a software problem.

In a very short time he found the error and fixed it. Here's John's description:
I went over and over the code and had the MDT attached but the timing was not the same as your program hammering.  If I had a logic analyzer monitoring all the transactions up to the crash it would have been quicker, but acting on the hunch after your program crashed I went directly to the source.
The code that parsed a line of BASIC into tokens directly manipulated the processor stack in a way that was not interruptible. If the hardware timer that updated the internal clock occurred at just the wrong time the stack would be corrupted and the machine would crash. John replaced it with code that had exactly the same effect but didn't cause a problem and did it in less space than the original. Later John found a note in an Ohio Scientific manual that interrupts should be disabled when running Microsoft BASIC. Sure would have been nice if Microsoft had told us that.

Popular posts from this blog

Calculators, codes, and hidden messages

Image
by Leonard Tramiel Looking at a list of the chips used in Commodore calculators we see some letter and number combinations that are quite meaningful, if you know the stories. Some of the most sophisticated processors that Commodore made were based on a custom chip set that used a common processor and different ROMs (or two) that contained the code for that particular model. I wrote the firmware for a few of those. Like this one: Photo credit: Dave  McMurtrie One of my favorite memories is the way those ROMs were programmed, as described here . This processor was a fully custom chip and it required a LOT of engineering work, time, and money. When my father, Jack Tramiel, was persuaded to approve the project he told the person in charge "God help you" if this doesn't work. The chips all have product names the contain GHU for God Help Us. The first set of calculator chips that Commodore engineers developed included as much of the circuitry as thought possible into a single
Read more

If Looks Could Kill

by Leonard Tramiel At one of the many computer trade shows over the years I had a really funny interaction with Bill Gates. I was doing demos on the PET and answering the questions of those that walked by. I noticed a large group of people approaching, but at first I didn’t recognize anyone. As they got closer I saw that it was Bill Gates leading the others around. There was a translator repeating what Bill said into Japanese. When they reached me Bill walked up to a PET and typed WAIT 6502,10. This caused the machine to hang and he froze. I said, quietly enough in the loud hall that only he could hear, “Bill, there’s nothing at 6502 so that’s just going to freeze”. He turned and gave me a look that was a perfect example of a look that could kill. I knew what he was doing so I turned to the group and said something along the lines of, “Microsoft BASIC is a valuable part of this machine”. Bill relaxed and the group left the suite. The WAIT command in Microsoft BASIC was an unusual addit
Read more

Programming by Tweezer

Image
by Leonard Tramiel In another post I mentioned that one summer I wrote the firmware for a couple of Commodore’s calculators. Commodore had a wide variety of proprietary calculator chips that they used for an even wider range of calculators. The earliest example I can think of is what I think was Commodore’s first calculator that had only one chip. Prior to this there were two chips. One that did the computations and one that provided the drive current for the LED display. I won’t go into the details but a clever engineer figured out how to get the computation chip to also drive the LEDs. it required a pretty basic change to the way the display subsystem worked but wouldn’t make the calculation chip more complex. This was code named RBP (Rock Bottom Price). The designer was sure that the chips would be opened to figure out how this was done so he added the letters FKU to a corner of the die. I used to have a few of these actual chips but I can’t find them. The chips used in the calcula
Read more