Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!ernie.Berkeley.EDU!carlson From: carlson@ernie.Berkeley.EDU (Richard L. Carlson) Newsgroups: comp.sys.amiga.tech Subject: Re: printer probs Star NX1000 Keywords: printer,star Message-ID: <25159@ucbvax.BERKELEY.EDU> Date: 22 Jul 88 01:10:11 GMT References: <3049@geac.UUCP> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: carlson@ernie.Berkeley.EDU.UUCP (Richard L. Carlson) Distribution: na Organization: University of California, Berkeley Lines: 82 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