Since my famous IC kits have sold out earlier this year, more and more Apple-1 builders are struggling with getting their APPLE-1 up and running. This post is meant to show a method to at least get a clue where the cuprit is which causes the Apple-1 not to work.
Key to understanding the method is to recognize it as a repeated "binary split" of the whole system to make the area in which the fault may be smaller and smaller, until, eventually, the splitting action ends at one IC, or a small group of ICs, which then gets replaced to see if this solves the problem. "Area" means, of course, PCB real estate or the landmap of the system, called the "schematic".
One of the nice things with the Apple-1 is that it splits into the "Terminal Section" and the "CPU Section", which both can work independently from each other. So this is the natural first binary split - where is the fault ? In the "Terminal Section" and the "CPU Section" ? We assume that the "Power Supply" section has been already checked and all the regulated voltage rails are up and running and the voltages are in spec.
Now, look at the picture on the monitor. After power up, you should get the usual "garbage screen" consisting of columns of the @_@_@_@ ... pattern. If you don't get that, look closer and try to see a faint dot pattern in an otherwise stable picture.
If you see that, you have got all the clocks running and get synchronization signals to the monitor, but you got no characters. The culprits can be anything in the video pipeline beginning with the two 74157, the 2519, the 2513, or the 74166. There are methods how to hunt that down by pulling ICs and injecting static 0/1 signals at places, to see where these signals disappear. Hunting down faults in the "Terminal Section" is relatively easy as you can see things on the monitor screen, and you can see the reaction to your manipulations, and tests, such as the reaction to the injected signals. But debugging the "Terminal Section" is not the topic of this thread.
DEBUGGING THE CPU SECTION
What is more difficult to debug is the CPU section, if it pretends to be deaf, dumb, and / or dead.
A typical symptom is that after power up, the @_@_@_@_ ... pattern can be cleared with CLR SCREEN, which makes the blinking cursor appear. If that can be done, the "Terminal Section" most likely is OK, as the CLR SCREEN operation exercises almost everything in it, including the cursor state machine. I will not further indulge into this topic, and not talk about those who sabotage everything by having a ill-designed keyboard interface that does not release the CLR SCREEN line (adding a diode in the CLR SCREEN line can help, cathode goes to the Apple-1).
A symptom of a deaf, dumb, and / or dead CPU section is that after giving a RESET, nothing happens, and the cursor just continues to blink. It does not drop one line and no Wozmon prompt appears. Bad !
Items / Instruments needed
What you need to investigate this any further is a) an oscilloscope (even a single channel 20 MHz one will do) and a set of my diagnostic PROMs. (I know, I know, without my kits these are hard to come by, but maybe somebody will lend you a set of them, or you can make a small EPROM adapter with the diagnostics page in it, I think Applefritter member 'macintosh_nik' did that, and made the plans or PCBs available. Otherwise you can proceed with the normal Wozmon PROMs, but the things you can see on the oscilloscope will be different from what is seen in the following. But it still may be useful, as long as the DRAM works, which is not needed if you have my diagnostic page.)
First oscilloscope measurements
To avoid a wild goose chase, use the oscilloscope to see if the 6502 has a ~ 1 MHz clock (pin #37) and produces about the same signal on its pin #39. After RESET, there also should be activity (positive pulses) on its SYNC output (pin #7) which indicates instruction fetches. No instruction fetches means the 6502 is bad, or was poisoned by one of the infamous "KIL" instructions. Cycling RESET should at least bring back some activity on SYNC, until the next KIL. Otherwise, with clock running, it would be a bad 6502. Replace and try again.
The next "binary split" step (skip if you only have the Wozmon PROMs)
There are a lot of opportunities for bad ICs causing a data bus conflict which crashes the firmware-in-PROM run. So it is smart to take this ability for sabotage away from the DRAM section. This is done by pulling the two 8T97 drivers at location A9 and A10 from their sockets. Then add four wire jumpers between pins #13-#14 and #11-#12 on each socket. Make these jumpers from a thin wire about the same diameter of an IC pin. Typical snipped off leads of the small signal diodes (1N914, 1N4148, ...) used in the build usually have the right diameter. Oh, you threw these snipped off leads in the trash ? Too bad ! Never do that ! Now you have to sacrifice some good part to make these jumpers.
Here is a photo showing where the jumpers go:
Then attach the ground clip of the oscilloscope set to 2us/div timebase to one of the ground pins in the vicinity of the PIA or the CPU (you may poke another of these snipped off leads into pins #8 of the now empty 8T97 sockets), power the Apple-1 up, and probe the pin #23 of the PIA. After RESET, and some fiddling with the trigger level, you should be able to observe negative going pulses spaced about 8 us apart. This is for the diagnostics PROMs. Wozmon may be a bit different, but unless it has crashed, due to bad RAM, it will also produce these pulses. They just mean that it looks for a keypress. For the diagnostics PROMs, which don't use the keyboard other than for CLR SCREEN and RESET, it means that they look for the Terminal Section being ready to accept a new character. Seeing these pulses in some pattern, and not just a flat line, means that the firmware in PROM is running. If you see a flat line, and no pulses, then the 74154 decoder is suspect, or any gate which drives one of its inputs. Note that depending on the trigger circuit of your oscilloscope, the pulses may not be as cleanly separated as seen in the photo:
It may be that you can see a messy trace with many such pulses superimposed. But that does not matter much, as long as these negative going pulses are there. In my case, I got a flat line, and after replacing the 74154, the pulses appeared. So the 74154 was bad. And after replacing it, the Apple-1 worked again !
Next steps - further verifications
Next step is to power down, pull the jumpers, and replace the 8T97. Power up, CLR SCREEN, RESET again. The firmware now should still run (and you still should see those pulses on PIA pin #23). Otherwise, something is wrong with the 8T97 or the gates controlling them, because they do something that makes the firmware crash.
This has limited the number of culprits down, just trace the signals controlling the 8T97 and see if something there is odd. Maybe the enable signals on pin #1 are low when the PROMs are enabled ? Or the enable signal on pin #15 controlled by the DMA line is always high ? (Forgot to close the nonDMA solder option ?)
If you have the diagnostics, and the DRAM is bad, they will spit out error messages. If the "Terminal Section" does not respond properly, then you still can see this error message activity going on by probing PIA pin #17, with the oscilloscope timebase set to 2ms/div, or slower. Each character that is output produces a tiny dot below the main trace, which almost always is high, except for these dots. Here is a photo:
The dot is circled in red. Typical distance for the dots is 16.67 ms, because the Apple-1 "Terminal section" can only output a character when the cursor impulse comes along. Which happens once per TV field (60 Hz field rate). If you can't see these dots and the signal is flatlined, then something in the cursor state machine is wrong, or the firmware has crashed (again ?). The cursor state machine is the cluster of TTL ICs in the lower right hand corner of the "terminal section" schematic.
Now, what if all of the above does not yield any culprit ?
We did not yet investigate the 74S257 multiplexers at locations B5, B6, B7 and B8. These are responsible to bring the sixteen address lines from the 6502 to the other parts of the system. Probe with the oscilloscope to see if they are enabled (pin #15 low) and what happens on the "refresh" signal (pin #1 of B7 and B8). If the refresh signal ever is low for more than ~ 1us, then something is wrong with the refresh logic. If you have the diagnostics PROM, you may try to pull the 7400 at location D10, slightly bend away its pin #11 (~30 degrees is enough), and insert it back into the socket, so that pin #11 now is disconnected (it just sticks out in the air). This disables DRAM refresh. Now, with the diagnostics PROMs, after RESET, you would get exactly one line of characters, then exactly one DRAM error message (caused by the missing refresh while the character line was written), and then no further error messages, all this under assumption of everything in the CPU section working as it should.
This is because once the diagnostics have encountered the first DRAM error, and have shown the message, they will not write out any further characters to exercise the "terminal section" but only run the DRAM test in an endless loop. This process is fast enough to refresh the DRAM by software. So unless there is a fault in the DRAM subsystem, no further error messages will appear and the firmware will continue running.
Conclusion
A few simple checks using an oscilloscope can reduce the number of suspect IC(s) in an Apple-1 to a few, which then can be swapped against (hopefully) good ones. Key is the isolation of subsystems (such as the DRAM) which can interfere with the proper execution of diagnostics in PROM. This approach works best with diagnostics firmware in PROM which does not need any functional RAM in the machine. The Wozmon as such uses subroutines and therefore can only work properly if the DRAM subsystem is functional to the point where page zero and the stack page work well enough to keep Wozmon from crashing. This underlines the importance of having diagnostics which do not need RAM.
- Uncle Bernie