arnold@geac.UUCP (Arnold Rosenbloom) (07/20/88)
I have an Amiga500 and I just got a Star NX 1000 for it (I hope this will eventually turn out to be a good choice). Anyway I have been having trouble getting my Amiga to speak to it. First of all, when I start a print sequence (single sheet feed) I get a bunch of line feeds (both directions) and then I end up with print starting at the center of the page. 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). I am sure I will find more problems later on, but I was hoping that someone could give me a hand and let me in on the secret (how do I configure the damn thing). Also is the printer/Amiga hanging usual. Thanks in advance for any comments/help Arnold Rosenbloom
carlson@ernie.Berkeley.EDU (Richard L. Carlson) (07/22/88)
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
bobb@tekfdi.TEK.COM (Robert Bales) (07/25/88)
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 (I hope this >will eventually turn out to be a good choice). So I'm not alone in the world. :-) I just got a Star NX 1000 for my Amiga 2000, and guess what. . . Problems. Not completely the same, but still problems. >Anyway I have been having trouble getting my Amiga to speak to it. First of >all, when I start a print sequence (single sheet feed) I get a bunch of line >feeds (both directions) and then I end up with print starting at the center >of the page. I haven't noticed this. I'm using tractor feed, but that shouldn't make any difference. With my previous printer, I noticed not-starting-at-the-left- margin at times when using 'type' to prt: but not when typing to par:. No extra line feeds, though. There is a DIP switch to give a automatic LF after receiving A CR, but mine works with the switch in the factory-set position. >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). Yes. I've poked around a little, but haven't worried about this because I have a more severe problem, but it appears that the on-line interface line is not changing state when the printer goes off-line. So maybe (?) the Amiga sends a character when the printer is off-line, the printer doesn't respond, and the Amiga waits. Which brings me to the biggie. After printing for a while (2 lines to 1+ pages) everything stops and hangs. Momentarily grounding either the DRDY* line (which indicates to the printer that there is data and cause it to acknowledge) or the ACK* line starts things up again. The first time or two this happened, I got "printer trouble" requester, but usually I don't. So far, I have exchanged the printer (the first seemed to get worse with time on, suggesting a thermal problem), tried the printer with another computer (it worked fine), changed the cable, and interchanged my 8520's. All with no effect. Next, I think I'll look at pulse timing. Bob Bales Tektronix, Inc. I help Tektronix make their instruments. They don't help me make my opinions.
daveb@cbmvax.UUCP (Dave Berezowski) (08/01/88)
In article <2274@tekfdi.TEK.COM> bobb@tekfdi.UUCP (Robert Bales) writes: >I haven't noticed this. I'm using tractor feed, but that shouldn't make any >difference. With my previous printer, I noticed not-starting-at-the-left- >margin at times when using 'type' to prt: but not when typing to par:. No >extra line feeds, though. There is a DIP switch to give a automatic LF after >receiving A CR, but mine works with the switch in the factory-set position. > When you output to par: you are talking directly to the printer. When you output to prt: you are going thru the Amiga printer interface. The Amiga printer interface looks at your printer preference settings and sets up the printer accordingly. Thus if you have your printer preference margins set to something other than 1 and 80 (for 10 cpi) you will find that any text sent to the printer will not look at same (with respect to margins) when sent to prt: vs sending it to par:. Try setting ... 10 cpi, lmarg = 1, rmarg = 80, 66 lpp, 6 lpi, narrow tractor. Regards, David Berezowski