rbharding@orchid.waterloo.edu (Ron Harding) (04/08/89)
I was wondering about how Atari printer interfaces, or the P: driver handle
conversion of ATASCII to ASCII. It seems to me that if the ATASCII codes such
as EOL (155, $9b) are universally converted to the ASCII codes, such as CR/LF
(13,10 $0d$0a), then important things like dot-matrix graphics will be munged
up. But if they aren't converted, then normal text won't print properly.
How is this resolved? My theory is the following:
- The P: handler will perform conversion of ATASCII to ASCII if the output
command is PUT_RECORD. This command is line-oriented (a record is always
terminated by an ATASCII EOL (155) ).
- If the output command is a PUT_BYTES, the P: handler performs no conversion
whatsoever, so graphics dumps will work correctly.
Am I reasonably close to the truth here? I need to know, since I am faced
with the task of writing a P: driver for the parallel port I built for my old-
style 800. Currently, I use a cludgy SpartaDOS program I whipped up:
PPRINT fname.ext
Thanks in advance.
Ron Hardinggdtltr@vax1.acs.udel.EDU (Gary D Duzan) (04/08/89)
In article <682@orchid.waterloo.edu> rbharding@orchid.waterloo.edu (Ron Harding) writes: > > I was wondering about how Atari printer interfaces, or the P: driver handle >conversion of ATASCII to ASCII. It seems to me that if the ATASCII codes such >as EOL (155, $9b) are universally converted to the ASCII codes, such as CR/LF >(13,10 $0d$0a), then important things like dot-matrix graphics will be munged >up. But if they aren't converted, then normal text won't print properly. > > How is this resolved? My theory is the following: > In general, this is handled by the interface. ALL EOL's (155) are translated into CR (13, or CR/LF (13/10), depending on the interface.) This does, in fact, disallow code 155 in any bit-mapped output to the printer. Generally, programs which send bit-mapped data to the printer are required to check for a 155 and either report an error or send it varied slightly (more likely the former.) >- The P: handler will perform conversion of ATASCII to ASCII if the output >command is PUT_RECORD. This command is line-oriented (a record is always >terminated by an ATASCII EOL (155) ). > >- If the output command is a PUT_BYTES, the P: handler performs no conversion >whatsoever, so graphics dumps will work correctly. > > Am I reasonably close to the truth here? I need to know, since I am faced >with the task of writing a P: driver for the parallel port I built for my old- >style 800. Currently, I use a cludgy SpartaDOS program I whipped up: > PPRINT fname.ext > For a general solution, rewriting (or patching) the built-in P: handler to change all 155's to 13's (or 13/10's) would be best. "Mapping the Atari", Codebuster, your favorite assembler, and a good bit of stamina would be all you would really need (assuming a working knowledge of the Atari OS & the 6502.) I would advise against your above suggestions due to possible problems with compatability. Your best bet would be to write a general PUT_BYTE routine that does the conversion and have PUT_RECORD and PUT_BLOCK call PUT_BYTE directly for each character. > Thanks in advance. > > Ron Harding You are certainly welcome. Gary Duzan Time Lord Third Regeneration Atari Enthusiast Extreme
arthur@pnet02.cts.com (Arthur L. Rubin) (04/08/89)
rbharding@orchid.waterloo.edu (Ron Harding) writes: > > I was wondering about how Atari printer interfaces, or the P: driver handle >conversion of ATASCII to ASCII. It seems to me that if the ATASCII codes such >as EOL (155, $9b) are universally converted to the ASCII codes, such as CR/LF >(13,10 $0d$0a), then important things like dot-matrix graphics will be munged >up. But if they aren't converted, then normal text won't print properly. > I'm fairly sure the 850 interface just converts all $9b's to $0d$0a. You just can't have $9b's in your graphics (try 7-line graphics). Arthur L. Rubin (home) (818)286-1121 (818)286-0981 PO Box 2437 (work) (818)281-6011 (213)670-1100 San Gabriel, CA 91778 MCI Mail: ARUBIN 216-5888 Compuserve: 70707,453 INET: arthur@pnet02.cts.com