By: Robert Puff 12/15/97
After having dealt with it seems thousands of Atari 8-bit computers that have come into my shop for repair, one gets to recognize some common ills, with the appropriate solutions. Recently, I have seen a number of computers that, by them selves, work fine; yet once they are connected to a Black Box, or large memory upgrade installed, suddenly they become flaky. Random crashes, bad bytes on the screen, and characters that have randomly changing pixels in them are some of the symptoms of this flakiness. I think I've finally uncovered a solution that seems to work on just about every case. This solution is presented here, in hopes that this can help fix some 'field' problems, and give rock-stable performance. Note that none of the modifications below will interfere with other peripherals, or cause any incompatibility. Even if you are not using a PBI device, they can help. This text file assumes the user is skilled with a soldering iron, and know how to identify and number the pins on an integrated circuit chip. If you are unfamiliar, let someone else do these mods for you! Computer Software Services will perform the mods listed below for $25 plus shipping, if you so desire. Call (716) 429-5639 for information. Although the 8-bits run at a very slow speed compared to today's machines, the bus timing is very critical. It seems that this flakiness is directly attributed to very small timing problems. While I can't say that I know 100% of what is going on, I'll try to explain what and where the problem is.
The 02 (phase two) clock signal that comes out of the computer through the cartridge
(and PBI) port(s) is buffered from the signal coming directly from the CPU. This
buffering adds a small but measurable delay. By the time the signal gets out of the
computer and on to your PBI devices, there is more inductance and parasitic capacitance
to further delay this signal. When the delay gets too much out of hand, WRITES to the
PBI device get corrupted, because the data bus is no longer valid on the trailing edge
of 02. I used to swap out the 6502, which would generally fix the problem. However, I
found a solution that would work with ALL processors: add in the phase 0 clock input
(that goes into the 6502's clock circuit) into the 02 buffer gate. the phase 0 signal
is the same as the phase 2, only backwards in time slightly. It so happens that the 02
buffer gate is an AND gate, and has an unused input. Tying this unused input to the
phase 0 signal ends up bringing the high-to-low transition back in time, giving us a
little more grace for the extra delays that will happen in the outside world.
>> ON 600XL/800XL COMPUTERS: Solder a wire from pin 4 of the 74LS08 to pin 13 of this
same chip. ON 65XE/130XE COMPUTERS: Solder a wire from pin 4 of the 74LS08 to pin 2 of
this same chip.
This modification deals with a timing problem with the OS ROM. It seems that especially
with multiple EPROM OSes, the output buffers of the ROM chip stay on even into the start
of the next cycle. This causes RAM corruption, easily seen by bad bytes randomly
appearing on the screen. This fix isn't as simple as the first one. We need to connect
our newly-fixed buffered 02 signal (from Mod #1) into the (inverted) output enable line
of the OS ROM. While one might think you could simply gate the chip select line with 02,
better results seem to be had when you drive the ROM's chip select with the normal signal
(coming from the PAL), and send the inverted buffered 02 signal to the output enable,
which responds faster than the chip select pin.
>> ON 600XL/800XL COMPUTERS: Solder a wire from pin 6 of the 74LS08 to pin 5 of the
74LS14 chip. (We're going to use the one unused gate in the '14 inverter chip.)
The easiest way to finish this is to either desolder or cut pin 22 of the OS ROM,
and bend the little stub up, so it is not making contact with anything. Solder a wire
from pin 6 of the 74LS14 to this pin 22 of the ROM. If you have an UltraSpeed + OS or
some other sort of OS package and you can't lift this pin, you'll need to:
1. Cut the trace on the bottom side of the PCB tying pins 20 and 22 together.
2. Cut the trace that runs from pin 15 of the PAL (CO61618) to pin 22 of the OS ROM.
3. Run a wire from pin 15 of the PAL to pin 20 of the OS ROM.
4. Now run the wire from pin 6 of the 74LS14 to pin 22 of the OS ROM.
5. Run a jumper from pin 6 of the 74LS08 to pin 5 of the 74LS14.
>> ON 65XE/130XE COMPUTERS: You will need to add a 74LS14 chip.
Follow these steps:
1. Bend up all the pins of your new 74LS14 except 3, 7, and 14.
2. Stack this chip over the 74LS08 IC (oriented the same way), and solder pins 3, 7,
and 14 of the two chips.
3. As in the XL instructions, there are now two options: lift pin 22 of the OS ROM, or
cut traces. If you can just lift the pin on the ROM, then solder a wire from this
lifted pin to pin 4 of your 74LS14. You're done!
4. Ok, so you want to do it the hard way! Actually, it's not that bad. Look at the bottom
of the PCB. You'll see a trace that comes from the PAL, and goes to both pins 20 and 22.
Carefully cut the small trace that goes to pin 22, leaving intact the one going to
5. Now solder a wire from pin 4 of your 74LS14 to pin 22 of the ROM.
This is actually a Black Box modification. Again, due to varying phase two clock
signals, a timing circuit on the Black Box MAY need to be modified. The D1FF latch uses
a R/C delay to insure the latching occurs while the bus is valid. A late 02 signal can
skew this delay, causing the latch to grab random values at times. The fix is simple.
First, locate the resistor and capacitor combo that is just below the BB's SCSI port.
Look at the color bands of the resistor. It should be brown-black-brown. Now look on
the bottom side of the BB, and see if there is another resistor soldered in the same
place. If so, then no modification is needed. If you see no resistor on the bottom IN
THAT LOCATION, then solder a 220 ohm (red-red-brown) resistor across the two resistor
That's it! Hopefully you will now have a stable Atari!