SIO protocol for printers

[JoSch]

Does anyone know how the SIO protocol for printers is implemented?

I know of command 0x53 (Get Status) and command 0x57 (Write), but I have not much more informations.

I'm developing a printer emulation for RespeQt and I noticed, that the buffer is always 40 bytes long and right filled with 0x20 (space).

Is this a correct observation? If so, is there a way to know how long the string is that the program really was sending?

[Rybags]

Supposedly there's also "Sideways" 29 chr per line and "Wide" modes.

 

Looking at a disassembly of the XL OS, it appears that the SIO record size is adjusted to match the printing mode.

But how the printer knows what size record to expect?

 

Here's a code extract though it's not a match for the ROM I have in Altirra.

<pre>
FF14:		stx	DBUFLO
		sty	DBUFHI
		lda	#$40	; printer 1 ID
		sta	DDEVIC
		lda	ICDNOZ
		sta	DUNIT
		lda	#$80
		ldx	DCOMND
		cpx	#'S'	; COMMAND == STATUS ?
		bne	@1
		lda	#$40	; yes!
@1:		sta	DSTATS
		lda	PBUFSZ
		sta	DBYTLO
		lda	#0
		sta	DBYTHI
		lda	PTIMOT
		sta	DTIMLO
		rts
</pre>

Here's the XL OS listing I used in a zip file, AFAIK it's an unofficial reverse-engineering effort with each block of code in HTML for viewing in a browser:

XL OS.zip

 

[phaeron]

The 820 printer SIO interface is documented in the OS Manual. It's very minimal: a status command that only sends back the timeout value, and a write command that takes a space-padded buffer along with the mode. One error in the manual, though: the OS sends the mode (N/S) in AUX1 and not AUX2.

 

And no, you can't tell how long the original line was. The OS handler automatically line breaks and pads the incoming text to fixed-length buffers.

[JoSch]

Supposedly there's also "Sideways" 29 chr per line and "Wide" modes.

The text printer code in RespeQt handles it like this on AUX2, but that seems to be incorrect.

 

The 820 printer SIO interface is documented in the OS Manual. It's very minimal: a status command that only sends back the timeout value, and a write command that takes a space-padded buffer along with the mode. One error in the manual, though: the OS sends the mode (N/S) in AUX1 and not AUX2.

 

And no, you can't tell how long the original line was. The OS handler automatically line breaks and pads the incoming text to fixed-length buffers.

Do you mean this OS manual http://atariage.com/forums/topic/127483-atari-os-and-hardware-manuals-get-them-here/?p=1538702?

So, this implies that the OS fills the buffer and sends it, if full or pads the buffer if a EOL occurs.

That would be the behaviour, I'm seeing when LPRINTing a long string. Then I can try to reprogram my code and the text printer emulation, to assume that EOL means end of buffer.

 

Thanks, guys, as always very helpful informations around here

 

EDIT: I read the linked OS manual. It mentions a checksum byte. Does anyone know whether the checksum calculation is documented, and if so, where?

RespeQt already handles the checksum byte, but I thought I saw a byte coming after the spaces.

Edited March 30, 2017 by JoSch

[Rybags]

So I assume there's no CR/LF conversion or insertion? Does the printer automatically do so itself after every received record? Wouldn't that mess with stuff like overprinting to acheive bold?

[JoSch]

That probably is printer dependent. I work as a proof of concept on an Atari 1027 emulation.

To my knowledge, this printer is not capable of CR without LF.

Edited March 30, 2017 by JoSch

[sup8pdct]

status and write are the only commands that printers/interfaces use. Interfaces like 850 convert EOL to LF.That is why std centronics printers connected to 850 and like must have CR after LF dip switch/option set. Each data packet is 40 bytes long. A problem occurs when printing graphic data through 850 and the like interfaces, any EOL (155) is converted to LF (13) regardless. Lines longer then 40 bytes will have just plain text in 1st block and as many blocks as required, then an EOL is sent. what is padded after that,i am not sure.

 

James