Re: CoCo Serial to Ethernet Interface/Converter
Don Barber via Coco <coco-uNHYcr1XS/wmlAP/[email protected]>
| Newsgroups | gmane.comp.hardware.tandy.coco |
|---|---|
| Message-ID | <[email protected]> |
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. -- Coco mailing list [email protected] https://pairlist5.pair.net/mailman/listinfo/coco