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.
MODIFICATION #1
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.
MODIFICATION #2
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
pin 20.
5. Now solder a wire from pin 4 of your 74LS14 to pin 22 of the ROM.
MODIFICATION #3
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
pads.
That's it! Hopefully you will now have a stable Atari!