Ok, I'm getting closer to cleaning up the Imagewriter driver, and one thing has really perplexed me when trying to get it to work with the ct486. It appears that what they call DTR is actually RTS and vice versa.

I ran a neat little program called "SERIAL" by Bret Johnson http://bretjohnson.us/ and it seemed that it was dropping DSR periodically instead of CTS.

It shows the DSR and CTS status on the screen in the upper right.

[Linked Image from i.imgur.com]

The gap between DTR and RTS is where DSR would be since DSR is now off. It's a little hard to read because I've put mame in pause.

[Linked Image from i.imgur.com]


Reading the imagewriter manual it says:

Quote
(page 103)

Signal Descriptions

Request to Send: Output signal from the printer; logic 0
(Spacing) when the printer is turned on.

Fault: Output signal from the printer.

Data Terminal Ready: Output signal from the printer, logic 0
(Spacing) when the printer is on and able to receive data; logic 1
(marking) when unable to receive data.




Data Transfer Ready Protocol
Whenever the capacity of the input buffer becomes less than 30
characters, the printer sends a busy signal by setting the DTR line
false. The computer must stop transmission within the next 27
characters; if it does not, the printer will ignore the excess data.
The DTR line is also set false when the printer is deselected, and
when it receives a DC3 character. The DTR line is true whenever
there is room for at least 100 characters in the input buffer, when
the printer is turned on, selected, and has received a DC1
character.


watchpointing io port 61 (write command), you can see it drop DTR

Code
data written to 61  =  27   pc=13D9

(drops DTR bit 1)

data written to 61  =  25

data written to 61  =  25   pc=1397

Reading wikipedia's article on https://en.wikipedia.org/wiki/Data_Terminal_Ready
Quote
Use for flow control

On some printers with serial interfaces, the DTR line is used for hardware flow control, similar to the use of RTS and CTS for modems. This practice is not consistent; other printers define RTS for this same purpose.

When DTR is used for flow control, it manages the flow of data from the printer to the computer. However, because during printing, the bulk of the data is from the computer to the printer, the importance of flow control in the opposite direction is minimal.


So this makes sense because when I hook up DTR to CTS, it is able to print a full page. Hooking up DTR to DSR causes the print to fail midway.

I think the Imagewriter falls into the "using DTR for flow control instead of CTS" category.



I've been using a configuration ioport to flip things around and invert them instead of recompiling.

Code

	PORT_START("DTR")
	PORT_CONFNAME(0x3, 0x01, "Connect DTR ->")
	PORT_CONFSETTING(0x0, "No connect")
	PORT_CONFSETTING(0x1, "DSR")  // default to DSR
	PORT_CONFSETTING(0x2, "CTS")
	PORT_CONFSETTING(0x3, "DSR + CTS")

	PORT_START("RTS")
	PORT_CONFNAME(0x3, 0x02, "Connect RTS ->")
	PORT_CONFSETTING(0x0, "No connect")
	PORT_CONFSETTING(0x1, "DSR")
	PORT_CONFSETTING(0x2, "CTS")  // default to CTS
	PORT_CONFSETTING(0x3, "DSR + CTS")

	PORT_START("INVERT1")  // for testing / inverting various things without having to recompile
	PORT_CONFNAME(0x1, 0x01, "Invert1 DTR")
	PORT_CONFSETTING(0x0, "Normal")
	PORT_CONFSETTING(0x1, "Invert")

	PORT_START("INVERT2")
	PORT_CONFNAME(0x1, 0x01, "Invert2 RTS")
	PORT_CONFSETTING(0x0, "Normal")
	PORT_CONFSETTING(0x1, "Invert")


//-------------------------------------------------
//    i8251 DTR and CTS Handlers
//-------------------------------------------------

void apple_imagewriter_printer_device::dtr_handler(uint8_t data)
{
//	output_dsr(data);
	if (ioport("DTR")->read() & 0x1) output_dsr(data ^ ioport("INVERT1")->read());
	if (ioport("DTR")->read() & 0x2) output_cts(data ^ ioport("INVERT1")->read());
}

void apple_imagewriter_printer_device::rts_handler(uint8_t data)
{
//	output_cts(data);
	if (ioport("RTS")->read() & 0x1) output_dsr(data ^ ioport("INVERT2")->read());
	if (ioport("RTS")->read() & 0x2) output_cts(data ^ ioport("INVERT2")->read());
}

so for apple2 and the ssc, it seems to work with DTR->DSR and RTS->CTS and normal
so for apple2gs with the printer port, it seems to work with DTR->DSR and RTS->CTS and normal

for the mac512k , it seems to work with DTR->DSR and RTS->CTS and inverted

for the ct486, it seems to work with DTR->CTS and RTS->DSR and normal

for the amiga a500, DTR->CTS and RTS->DSR and normal allows me to print at 9600 bps

Last edited by Golden Child; 09/16/21 02:34 AM.