AWINFHAH@HMARL5.BITNET (06/01/89)
0. Introduction
---------------
Hi Netlanders,
About two weeks ago I posted an article about the NEC P2200 printer
connected to the ST. The contents was something like:
If you have a NEC P2200 connected to your ST *without* modifica-
tion, DISCONNECT it now. The 1 kOhm pull-up resistors on the Cen-
tronics interface of the NEC will eventually kill the sound chip
of your ST. I have hacked a small buffer box into the printer
cable to fix the problem.
In this article I will give some more details about both the problem
*and* the solution, since I have had some responses.
1. The Problem
--------------
| |
ST <-|-> Cable <-|-> Printer
| |
+5V
------+ |
| |
S | +-+
o | | |
u | | | 1 kOhm pull-up resistor
n | | |
d | +-+
| |
C |--------/ /--------+---- Data[1-8], Strobe, etc.
h |
i |--------/ /------------- Ground
p |
|
------+
The above picture shows the problem. Suppose the output of the sound chip
is at low level (ca. 0.5 V). This causes a current of 4.5 mA going
through the resistor. The sound chip has to sink this current, but is
rated at only 1.6 mA. It is clearly overloaded. Therefore your ST may
(and surely will) get damaged in the course of time.
NOTE #1: This may also be true for some older printers.
NOTE #2: The ST wants to see pull-up resistors of at least 2.8 kOhm. Any
printer having smaller pull-up resistors needs treatment (check
the manual or consult your supplier).
2. The solution
---------------
My first thoughts were to replace the pull-up resistors inside the P2200.
This is not possible as they seem to be integrated in some interface
chip (I cannot find the resistors, but the manual says they are there).
If you could replace them, you void warranty anyway.
My final solution was to hack a buffer box into the printer cable. This
box contains two 74LS365A chips (hex non-inverting bus drivers). You
can also use 74LS367A (they are organized differently, but pin compatible
for our hack). I decided to buffer all inputs to the printer (Data 1-8,
Strobe, Auto Feed XT, Input Prime, Slct In), even though the ST does not
support all these signals. You need two chips anyway.
Each buffered signal now has the following circuitry inserted.
+5V
|
+-+
| |
| | 4.7 kOhm pull-up resistor
| |
+-+ +--------+
| | |
From ST -------------+-----| Buffer |------ To printer
| |
+--------+
The 4.7 kOhm resistor does not overload the ST. However, you cannot omit
it. It is necessary for reliable operation. The buffer output is rated at
24 mA.
The 5V power for the circuit comes from the P2200. It is on pin 18 of the
Centronics interface. (I resoldered one of the signal-ground wires of the
printer cable to use it.) Most printers have this feature, some restrict
its use to 30 mA (enough for us). The hack thus works for most printers.
The Centronics pin numbers to be buffered are 1 (Strobe), 2-9 (Data),
14 (Auto Feed XT), 31 (Input Prime), 36 (Slct In). The ST only supports
the Strobe and Data lines.
The input->output pin pairs of the buffer chips are 2->3, 4->5, 6->7,
10->9, 12->11, 14->13. Two 'gates' (pins 1 and 15) enable the outputs.
They must be tied to ground (signal ground, NOT frame ground). Signal
ground is available on Centronics lines 19-30. The buffer chips want 5V
on pin 16 and signal ground on pin 8.
Finally, I advise you to install a 100 nF capacitor between pin 8 and pin
16 of each buffer chip. It enhances reliable operation just a little bit
more (it reduces noise on the power lines).
WARNING: take care to connect the correct wires. Wrong connections may
send your equipment to Nirwana at once.
3. Remarks
----------
I really like the P2200. It is one of the cheapest 24-needle printers
around here, and it prints nice and fast.
NEC is not to blame, Atari Corp. just does not comply with the Centronics
specifications.
The buffer box has been working flawlessly for 8 months now. So does my
ST for two years.
Sorry for the length of the article, but I wanted to be as clear as
possible.
4. Disclaimer
-------------
My opinions are my own, the consequences are entirely yours.
5. My address
-------------
Roger Hunen
University of Limburg
Dept. of Computer Science
Maastricht
The Netherlands
awinfhah@hmarl5.bitnet
hunen@rlinf.uucp (preferred)