Message-ID: <206@terak.UUCP>
Date: Wed, 28-Nov-84 11:51:31 EST
Article-I.D.: terak.206
Posted: Wed Nov 28 11:51:31 1984
Date-Received: Sat, 1-Dec-84 19:06:32 EST
References: <6045@brl-tgr.ARPA> <6060@brl-tgr.ARPA>
Distribution: net
Organization: Terak Corporation, Scottsdale, AZ, USA
Lines: 74
Xref: godot net.micro.trs-80:182 net.micro:3141
> > 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
Members
Search
Help
Register
Login
Home
