[Coco] CoCo Serial to Ethernet Interface/Converter

[Don Barber]

I have a usb printer driver as part of the usb drivers I'm making for 
Nitros9. One can see this driver here: 
https://github.com/barberd/nitros9-usb/blob/main/level1/modules/usbprinter.asm. 
It works great.

However, while this solves the communication problem, it turns out you 
can't just dump ascii to the printer like you could 40 years ago and get 
it to print. High end printers can accept postscript or pcl and low end 
printers expect some kind of specialized raster, usually kinda looking 
like a TIFF file with some additional headers. So one has to write a 
driver for their printer to use it. One can use open source linux 
drivers as a guide, but some printers (like my Brother printer) are 
proprietary and only distribute binary drivers. So its hard to use on a 
CoCo.

This would be the same problem for a network attached printer. You can 
probably talk to one fine with a CoCoIO card or similar and just tcp 
connect to port 9100 or 515. But you'd still need to pass it something 
the printer understands.

Idea: A linux box (could be a small one like a beaglebone or rasberry pi 
but doesn't have to be) can read from the coco's serial, then send 
whatever it gets through a modern driver to the printer. The program 
would be really simple, just collect bytes until it gets a EOT (maybe a 
few other things like FF too, depends on what the coco program sends) 
then pipe the batch into lpr.

Thanks,

Don

On 5/19/25 20:51, gene heskett via Coco wrote:
> On 5/19/25 20:16, Richard E. Crislip via Coco wrote:
>> Hello,
>>
>> As the Subject says, has anyone developed a CoCo serial to ethernet
>> converter to run a ethernet connected printer from the CoCo? TIA
>
> IF note BIG IF we have a ser to usb, you are about halfway there as 
> there are many USB hubs available which include a more or less std 
> Ethernet cat5 port replacing one of the USB outputs on these.
>
> The problem is mainly the FCC regulations for wireless stuff, makers 
> are precluded from exposing any wireless devices that can be 
> potentially be made to do illegal frequencies or power outputs, making 
> them essentially black boxes, so if the maker does not supply a 
> driver, they are also enjoined from sharing the how to drive it info 
> with us so we could write our own.
>
> That, and the coco's sharing a grossly incomplete i/o decoding scheme 
> with memory access throws some very large wrenches into the works. 
> I've screamed about that for 30 years or more, but no one has ever 
> designed a new mobo that fixes that.  That is 100% our fault.
>
>
>>
> Cheers, Gene Heskett, CET.