[Coco] Printing on a Coco with modern printers.

[Aaron Wolfe]

On Fri, Jan 10, 2014 at 9:47 AM, Al Hartman <alhartman6 at optonline.net> wrote:
> I believe a Coco is powerful enough, it just doesn't have enough memory to
> composite a page.
>
> A CoCo 3 in Turbo mode with a 2 meg upgrade could probably print simple text
> based pages, and upscale CoCo resolution graphics pages. The limiting factor
> would be the serial port speed, rather than the processor speed.
>
> Especially, if it was equipped with a hard drive and used a page file.
>
> I used to sell LaserMaster Printers that did this on 386 based computers,
> and this is how an Atari-ST printed to a Laser printer through the DMA port
> with a limit of 2mb of RAM.
>

Ok.. I think I am understanding your proposal.. stop me if I get it wrong :)

You're saying that the CoCo probably could drive a modern printer in a
limited fashion, given enough ram etc.  *but* your idea was not that
we actually try to do that.  Your idea was that we could take the
output that CoCo programs already produce and connect the bitbanger
they already use to a PC takes this "legacy" output and drives a
modern printer.  Is that accurate?  I hope I'm getting it, because we
could easily do this with just a couple changes to DriveWire.

DW already knows how to render one type of output (fx80), and the
framework supports adding more printer emulations if they were
written.
It also already connects to the bitbanger.  So the only remaining
issue is that DW ties up the bitbanger for itself (this is actually
the reason I ever began work on DW4, although it was because I wanted
to use the bitbanger for telecom stuff, not printing).

We can easily add a function in DriveWire that allows the CoCo or the
user to say "hey Drivewire, I want to use the bitbanger to print
something".  DW can then kick the serial poty down to the proper bps
speed and feed bytes to the emulated printer it already has.  When the
print job is done, the user or coco would need to tell DW to become
"normal" again.

There is a conflict if the program needs to read from the disk before
it's done sending the print job.  We could detect this situation
easily enough in the disk io routines, but I'm not sure if there is
any simple way to make things work properly.  I will think about that.