15

In his autobiography, Steve Wozniak recounts[1] his difficulty getting interrupts working on the 6502 microprocessor:

The next step was to debug the 256-byte monitor program on the PROMs. I spent a couple of hours trying to get the interrupt version of it working, but I kept failing. I couldn’t write a new program into the PROMs. To do that, I’d have to go to that other building again, just to burn the program into the chip. I studied the chip’s data sheets to see what I did wrong, but to this day I never found it. As any engineer out there reading this knows, interrupts are like that. They’re great when they work, but hard to get to work.

Finally I gave up and just popped in the other two PROMs, the ones with the “polling” version of the monitor program. I typed a few keys on the keyboard and I was shocked! The letters were displayed on the screen!

Can anyone shed some light on the root cause of the problem? Were the 6502's data sheets wrong?


[1] Wozniak, Steve. iWoz. W. W. Norton, 2006.

7
  • 8
    If I understand the story correctly, he tried to get the interrupt version of the monitor to work and failed, using a fallback version in the end. Without a listing of the erroneous program it would be pure speculation to say what was the problem. I found a listing of wozmon at this site sbprojects.net/projects/apple1/wozmon.php which has no interrupt service routines.
    – Peter B.
    Nov 7, 2019 at 0:29
  • Thanks for reminding me of iWoz - i bought a copy a few years ago, never got around to reading it, and forgot all about it until now!
    – LAK
    Nov 7, 2019 at 1:01
  • 2
    Above statement reads as if the issue wasn't the interrupt, but his attempt to write/change a PROM with the interrupt version. The source code comments do show hints of interrupt usage. Likewise do the Apple 1 schematics. As @PeterB. says, it's all speculation as not even the issue is described in consistent form.
    – Raffzahn
    Nov 7, 2019 at 6:44
  • 1
    @Wilson If you can prove that the interrupt-based monitor program no longer exists, I think it would be better as an answer than as a close reason. Nov 7, 2019 at 16:29
  • 1
    I wonder how easy or hard it would have been to construct a crude peg-board reader with a row of ten microswitches and wire a 6502 so that when a toggle was set a certain way, every read in the upper half of the address range range would wait for the next pair of transitions on two of the switches and then put on the bus the value from the other eight? That would allow one to design a 6502 system where the only "ROM" was a peg-board. Start with a half-dozen or so E9 so code will start executing somewhere around E9E9, then EA xx A9 byte0 85 00 A9 byte1 85 01 etc. to write some code...
    – supercat
    Mar 2, 2020 at 16:38

1 Answer 1

10

My two cents: I have written a lot of code with interrupts, and failed many times. Interrupts are very difficult to debug because they are asynchronous, you cannot easily enforce the same conditions again and again and you are fighting against race conditions and a lot of "background" operations.

The main problem, in my opinion, was that Woz had to program a PROM with a new version. It is very expensive (a lot of time, failed PROMs are destroyed forever, etc.) so he had only a few shots. With such conditions, it is better to give it up than keeping the "try-fail" approach.

1
  • I think this does answer the question, because of the second paragraph.
    – wizzwizz4
    Dec 8, 2019 at 10:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .