# Most of a parallel port's brains is in whatever
#   is connected to it, so there's no distinct parport handler. 

# cPC doesn't need a printer, but it's about the simplest output going,
#   and it's often hardcopy.

parport0=$((0x378))
parport1=$((0x278))

# The above is about the sum of the device-neutral port interface.
# The logic here is a Centronics interface, more or less. The parport itself
#    is little more than latches.

parportIRQbit=`binary 10000`

printringsize=1024

L parportsetIRQ

L printring0
allot $printringsize

L printring1
allot $printringsize

L print0response
	push D
		= $parport0 to D
	pull D
				dismiss

L print1response
	push D
		= $parport1 to D
	pull D
				dismiss

L printstrobe				## ##  NEED THIS


L printpending				## ##  NEED THIS


L printsend				## ##  NEED THIS


# A Centronics printer ACKs on byte_recieved. That's most
# of the interface. There's a couple of WHY bits, but they are why_no_ACK,
# and we don't want to check for no_ACK. 
# The only simplification I can see, other than slow poll-and-go, is 
# to ignore the case where a byte was sent and no ACK comes back.
# I've seen in some old tech notes where that approach is common.
# This means the printing process will lock up on no ACK. Maybe it will
# unlock if the non-ACKing condition is fixed manually, dono.
# The thing is, we are only happening on init_send and on ACK, and 
#  some cleanup code.
# 
# Thus the basic scheme is use the parport IRQ on ACK, ring-buffer
# some data, send one byte by hand, and check the buffer and send
# the pending bytes on the ACKs. "check buffer, if pending send, count" 
# is the IRQ handler. The speed range of printers I dono, so we use the IRQ.
#
# IRQ handlers have to know what port they are for inately. In other words,
# they have to be coded IRQ-specifically, which is unfortunate (barring 
# self-modifying code and similar). Subroutines can be general.
#

# colorgOS/parts/parprint
# Copyright 2002 Rick Hohensee
