• Please review our updated Terms and Rules here

Emulated parallel printer

I took a look at Crystalfontz. Their graphical OLEDs and LCDs max out at 320x240 resolution, so that's no good for printer emulation. But they are easy to interface to; I've used old Nokia displays in the past and they were nice.

Higher resolutions are only available through TFTs, which either use an RGB or MIPI interface. Both types are not cheap and require you to use a controller with hardware support for them, which usually limits you to the higher-end, more expensive variants. Or you use a display with HDMI support and go full SBC, as many projects seem to do now. (After dealing with MIPI camera sensors, I don't want to touch MIPI displays at all.)

Actually, eInk displays would be the perfect technology in this application, but I have never found larger ones. Apart from very few, older high-end devices, there aren't even full page sized eBook readers out there. I don't understand why, these would be great for looking at larger schematics.
 
Back in the 1980's amongst other things I made commercial laser printers that emulated line, dot matrix, daisy wheel printers and other laser printers.
Initially memory was very expensive and limited thus lines were compiled and sent to the laser printing engine on the fly.
When memory became cheaper more of it was installed and used as a complete page buffer.
For A4 paper size it was about 1Mbyte @ 300 DPI, for A3 it was 2Mbytes.
 
Why go to the trouble of using LSTTL? An MCU with 5V tolerant GPIO can do this easily with few components; something akin to #4. There are better chips for this, too.
 
Ruud said:
An Arduino Uno R3 should do IMHO and it is much cheaper than a R-PI.
Click to expand...
Interfacing to the parallel port, connecting an SD card and rendering into an image file are easy.

But you can't drive a high-resolution display with an Atmega328 to show the printed output (many ESC/P2 printers support 360 dpi). That's the problem.
 
If you want hi-res paper output, get a decent laser printer and use the MCU to convert from parallel to USB (or TCP/IP or whatever your printer uses). Or convert the output to a PDF for later viewing.
 
Ruud said:
An Arduino Uno R3 should do IMHO and it is much cheaper than a R-PI.
Click to expand...

A Pi Zero W is $15, can be GPIO’ed to a parallel port trivially, and it has both an HDMI port and wireless networking, so if you want a dingus that can catch parallel port output and render it for video display *and* forward it on to be printed on a modern printer this seems kind of like a no brainer.
 
Trivially? Pins aren't 5V tolerant according to my search of the RP2040 datasheet, which indicates that GPIO input is limited to Vdd+0.5V

There are plenty of cheap MCUs with published 5V tolerant inputs--and 5V tolerant outputs that can run in OD mode.

Guess I'm not one of those who thinks my hammer is an RPi.
 
Chuck(G) said:
Trivially? Pins aren't 5V tolerant according to my search of the RP2040 datasheet, which indicates that GPIO input is limited to Vdd+0.5V

There are plenty of cheap MCUs with published 5V tolerant inputs--and 5V tolerant outputs that can run in OD mode.

Guess I'm not one of those who thinks my hammer is an RPi.
Click to expand...

The 2040 is the Pico, not the Zero. But sure, the Zero isn’t officially 5v tolerant either. (Not that it stops a lot of people.) It might cost you the better part of two bucks to add level shifters. But here’s the point so far as I’m concerned: for this task my inclination would be to be as lazy as humanly possible. The request here was for a dingus that would accept the input, render it *graphically* on a display high res enough to be useful, and do format conversion. (Making the printouts available as files and/or send them to a more modern printer.)

The Pi Zero W runs Linux, it has a network connection, USB host, and HDMI built into it, and there is a lot of off the shelf software you could tie together using *scripting languages* to implement the whole feature set. *Only* thing you need is a driver to implement parallel input from the PIO pins, and even that you can grab off of any number of GitHub repos.

If your interest lies in cooking up a more efficient implementation to run on a cheaper MCU directly interfaced to some bare LCD panel then, sure, you can do it for a few bucks cheaper, probably, but… let’s get real here, we’re arguing about hardware costs being a trip to McDonalds vs. Denny’s, and ignoring the time investment.
 
Just thinking about it from a product engineering standpoint. Would you float a mass produced commercial product using the Zero? Second sources? Substitutes? Code control?
But that's my hang-up. Sure, the zero'd be fine for a ones-twosy lashup.
 
voidstar78 said:
Maybe fun to run ancient versions of WordPerfect or PageMaker and be able to still print
Click to expand...

Plasma said:
I have not seen a hardware version of what you are describing, although there is DosPrint.
Click to expand...

If we're just talking about printing from DOS, my cheap (not requiring any hardware I don't already own) solution would be to run something like PC Magazine's PRN2FILE.COM with the output written to a file on a network share (hopefully that works!) and then do something with the output file using a more modern machine. Perhaps one could even use some kind of parallel port networking so that a parallel cable is still involved :biggrin:
 
I did exactly that (capturing the INT 17h calls) and posting them to files. The reason was that I didn't have one of the printers the application took (Schema SDT) and processed the file later for the printer I did have (I think it was an old Tally, but memory is foggy there). Making big D-sized prints by patching together letter-sized printouts.

If you dig around in the ancient SIMTEL20 archives, you'll find a TSR that I wrote that captures INT 17h destined for an attached HP plotter. All I had at the time was a HPIB plotter. The TSR used the printer port to drive the HPIB bus. Called something like "LP2HPIB" or some such. I used it with SuperCalc. Ancient history.
 
Last edited:
doshea said:
If we're just talking about printing from DOS, my cheap (not requiring any hardware I don't already own) solution would be to run something like PC Magazine's PRN2FILE.COM with the output written to a file on a network share (hopefully that works!) and then do something with the output file using a more modern machine. Perhaps one could even use some kind of parallel port networking so that a parallel cable is still involved :biggrin:
Click to expand...

I have a network card with the mTCP suite installed in my Tandy 1000, and I’ve done exactly this, IE, either run a TSR that captures output to a parallel port or, if the program supports it, printing directly to a file, and then just using NetCat to blast the captured data at my network printer’s TCP port. (An HP Jetdirect.) And it works. Obviously to go straight to the printer you’ll need both a pretty decent printer that still has legacy emulations like Postscript/HP LaserJet/whatever and dos programs that have drivers for such, but it’s not that high of a bar. If you really want to support stuff like Epson emulation it’s not that much in the way of rocket science to set up a Linux print server with auto filtering capabilities.

Chuck(G) said:
Just thinking about it from a product engineering standpoint. Would you float a mass produced commercial product using the Zero?
Click to expand...

I sure wouldn’t, but I was assuming we were talking about a hobby project.
 
The eink idea is pretty neat.


Maybe the idea of a "serial monitor" can make a come back? Weren't original CRTs like that (late 1960s)? If you don't need particularly high refresh rate, maybe a serially attached screen would make an easier interface for integrating with Arduino or RPi type devices? EDIT: especially for resolutions past typical 40x4 character type LCDs.

Printers were inherently slow since it took time to actually actuate the print head and give time to apply ink-to-paper. So we don't need any 60fps type display here, but a decent resolution is needed to avoid some scaling.

But yes, an active "real-time" depiction of the printed output is a luxury (but nice for old setups that used to print log status to a printer). For starters, just dumping to an image or PDF on a SD-card file is fine. I'll see of this RetroPrinter device can do that. Being independent of system OS would be nice.
 
Last edited:
Hmmm. Makes me kind of glad that I hung on to my old Tandy DMP-130 all these years. Still works, but my ribbon collection is a little peaked. Does a real good job in DOS.
 
You must log in or register to reply here.
Back
Top