abc@brl-tgr.ARPA (Brint Cooper ) (11/25/84)
My TRS-80 Model I has suddenly stopped sending linefeed characters to my
Okidata 82A printer. That is, listing a program or outputting a file
results in all the printed output being on one line! This is
irrespective of whether I'm using a TRSDOS system, CP/M, or Level II
Basic.
The only other anomaly I've found is that when I LPRINT CHR$(N) for N
larger than 128 (i.e., a graphics character), the character appears to
be printed twice.
I have confirmed satisfactory printer operation from another computer.
I have cleaned and checked all the edge connectors and have pried out
and reinserted every socketed chip in the keyboard and the expansion
interface.
If there is a pattern-sensitive hardware fault, I'm baffled as to what
could cause it and not afect other ASCII characters. Yet, all those
that I'M able to confirm seem to be received correctly at the printer
except this one.
Has anyone out there experienced this problem? Please ask your friends
and acquaintances. I must work from home for several weeks because of
illness. Without a printer, I'm quite handicapped. HELP!
Please respond by any medium that's convenient to you.
Thanks!!
Brint
(301) 278-6883 AV: 283-6883 FTS: 939-6883
Dr Brinton Cooper
U.S. Army Ballistic Research Laboratory
Attn: AMXBR-SECAD (Cooper)
Aberdeen Proving Ground, Md 21005
ARPA: abc@brl.arpa
UUCP: ...{decvax,cbosgd}!brl-bmd!abcabc@brl-tgr.ARPA (Brint Cooper ) (11/26/84)
> My TRS-80 Model I has suddenly stopped sending linefeed characters to my > Okidata 82A printer. That is, listing a program or outputting a file > results in all the printed output being on one line! This is > irrespective of whether I'm using a TRSDOS system, CP/M, or Level II > Basic. > > The only other anomaly I've found is that when I LPRINT CHR$(N) for N > larger than 128 (i.e., a graphics character), the character appears to > be printed twice. > > I have confirmed satisfactory printer operation from another computer. > I have cleaned and checked all the edge connectors and have pried out > and reinserted every socketed chip in the keyboard and the expansion > interface. > > If there is a pattern-sensitive hardware fault, I'm baffled as to what > could cause it and not afect other ASCII characters. Yet, all those > that I'M able to confirm seem to be received correctly at the printer > except this one. > > Has anyone out there experienced this problem? Please ask your friends > and acquaintances. I must work from home for several weeks because of > illness. Without a printer, I'm quite handicapped. HELP! > > Please respond by any medium that's convenient to you. > > Thanks!! > Brint > Thanks to the two or three who have already responded. I failed to make one thing clear: the printer is working CORRECTLY. With the software that I use on the TRS-80, the printer should NOT generate its own linefeeds. Linefeed characters come from the computer. The problem is, specifically, that if I SEND a linefeed to the printer, the printer does not react to it. In Level II, this is done by LPRINT CHR$(10). The printer works correctly when connected to the Apple IIe running Applewriter. The Apple also provides its own LF characters, and the printer responds correctly to them. The puzzle appears to be: Why do linefeed characters NOT get sent to the printer as commanded? Thanks, again. Brint
doug@terak.UUCP (Doug Pardee) (11/28/84)
> > My TRS-80 Model I has suddenly stopped sending linefeed characters to my > > Okidata 82A printer. That is, listing a program or outputting a file > > results in all the printed output being on one line! This is > > irrespective of whether I'm using a TRSDOS system, CP/M, or Level II > > Basic. > > > > The only other anomaly I've found is that when I LPRINT CHR$(N) for N > > larger than 128 (i.e., a graphics character), the character appears to > > be printed twice. > > > > I have confirmed satisfactory printer operation from another computer. > > I have cleaned and checked all the edge connectors and have pried out > > and reinserted every socketed chip in the keyboard and the expansion > > interface. > > Thanks to the two or three who have already responded. I failed to make > one thing clear: the printer is working CORRECTLY. With the software > that I use on the TRS-80, the printer should NOT generate its own > linefeeds. Linefeed characters come from the computer. > > The problem is, specifically, that if I SEND a linefeed to the printer, > the printer does not react to it. In Level II, this is done by LPRINT > CHR$(10). > > The printer works correctly when connected to the Apple IIe running > Applewriter. The Apple also provides its own LF characters, and the > printer responds correctly to them. > > The puzzle appears to be: Why do linefeed characters NOT get sent to > the printer as commanded? > Thanks, again. > Somebody is hopelessly confused here... maybe it's me, but here goes anyway... I can't believe that the Mod-I has SUDDENLY quit putting out line feeds, since the Mod-I printer driver not only did NOT put out line feeds, but would remove any that the user program attempted to generate for itself. This "feature" resulted in a great number of half-baked work-arounds during the hey-day of the Mod-I. Those work-arounds all went to H**l when the Mod-III was introduced, which had a completely reworked printer driver with a totally different set of "features". One of those work-arounds was to use LPRINT CHR$(138); to put out a line-feed, since the Mod-I printer driver strips off the upper bit of the character before sending it to the printer but after making the check for the line-feed character. The Mod-III printer driver does not strip the upper bit off, so that work-around fails for the Mod-III. Unless, like Epson, Okidata decided to be nice and kludge the kludge by accepting a 138 as a line-feed! Wait a sec... I take back about the printer driver NEVER putting out line feeds... It will generate line feeds when a carriage return is sent immediately after another carriage return. This is because the Centronics printers which Radio Shack sold with the Mod-I would not line-feed when a carriage return was sent with an empty print buffer (nothing printed on the line). Anyway, the way to really see what's happening with the printer and interface hardware is to POKE 14312,CHR$(10) which will send a line-feed directly to the Centronics printer port (Lord, I hope you're using the Centronics port, and not a serial port, since the Mod-I doesn't have software support for serial printers). Location 14312 (37E8 hex) is the memory-mapped address for the Centronics port. If you need further details, let me know and I will dig out my old (and dusty) notes regarding line-feeds and the Mod-I and Mod-III. Personally, I would recommend avoiding this "hacker's Vietnam". Doug Pardee -- Terak Corp. -- !{ihnp4,decvax,hao}!noao!terak!doug