🚀 go-pugleaf

In article <3049@geac.UUCP> arnold@geac.UUCP (Arnold Rosenbloom) writes:
>I have an Amiga500 and I just got a Star NX 1000 for it ...
>... The next problem is if the Amiga starts a print sequence when the
>printer is off line then the Amiga hangs(even when I put the printer
>back on line)...

Aha!  The dreaded parallel printer hanging problem!  The last time I brought
this up, I got only one response from someone having the same problem.
Apparently, this is something most people either put up with or work around;
so I am just waiting until 1.3 is released to see if its parallel.device
has the same problem and, if so, how it might be fixed.

Quick and dirty solution:

If the printer otherwise seems to be handshaking with the Amiga OK, you can
probably solve the problem by changing a single wire in the cable: take pin
10 coming from the Amiga, DISCONNECT it from pin 10 coming from the printer,
and RECONNECT it to pin 11 coming from the printer (leave pin 11 connected
to pin 11 of the Amiga, as well).  (Also note that this change is NOT
symmetric -- you've connected pins 10 and 11 of the Amiga side of your
cable, not of the printer's side of the cable.)

This fix is almost tolerable on the 1000, since you need to have a special
printer cable anyway.  But on the 500 and 2000, where Commodore has gone
to great lengths to ensure IBM compatability, I think messing with the
printer cable is an unacceptable general solution, and that the problem
should be fixed in software.

Why this is a problem:

Since this is the .tech group, I might as well  #define TECHNICAL_MODE ON --
The problem is unquestionably in the parallel.device, not the printer.device.
Disassembling the parallel.device with Lattice's OMD and examining the
Amiga's schematics revealed the following interesting information:

The Amiga's parallel interface allows one printer signal to generate an
interrupt via an 8520; this signal is ACK* (pin 10).  Under program control,
an interrupt can be generated on every falling edge of ACK* (i.e., whenever
the printer acknowledges a byte of data).  The BUSY signal from the printer
(pin 11) can be examined in software, but cannot generate an interrupt.

Thus, in general, every time the printer has finished printing (or buffering)
one character, it pulls ACK* low, which generates an interrupt in the Amiga;
the parallel.device then knows it can send the next character to the printer,
then sleeps until the next interrupt is received.

This arrangement works great, except in one very important case -- how do
you send the FIRST character to the printer?  As it is now, the code checks
the status of BUSY when you first attempt to write a string to the printer,
and, if the printer is "not BUSY", the code can immediately send the first
byte out to the printer -- no problem.

BUT, if the printer is "BUSY", the code simply waits until it receives an
ACK* interrupt before sending out the first character -- oops; how is that
interrupt going to be generated?  In all of the printers I know of, taking
them from "not ready" to "ready" simply toggles the "BUSY" line, but does
not generate any pulse on "ACK*".  In other words, you're stuck forever.

The parallel cable kludge I describe above does nothing more than generating
a signal that will cause an Amiga interrupt when you make the printer ready.
And, of course, this fix will only work if the "BUSY" signal coming from
your printer generates a pulse after EACH character is received (i.e., the
printer briefly goes "BUSY" while it processes each character), because
you're now using it as an "ACK*" signal.  I believe (but am not sure) that
this is the case with most common printers.

This long-winded explanation does indicate a couple of important points --
the problem originates from the hardware design of the computer (and which
signals can generate interrupts) so there is probably no trivial software
fix.  Instead, I think the parallel.device must use the timer.device to
periodically poll the printer if it was not ready initially.  (Incidentally,
the AW RKM says that the parallel.device now opens the timer.device on
initialization -- this is not true, but may indicate that this is the way
the code was originally supposed to work).
#define TECHNICAL_MODE OFF

I hope this has been of some interest to others who have experienced this
problem.

-- Richard
   {tektronix,dual,sun,ihnp4,decvax}!ucbvax!ernie!carlson
   carlson!ernie.berkeley.edu