In the 90's I was on a research ship writing software that towed an instrument (SeaSoar) behind the ship that could be "flown" up and down through the water column. One of the challenges was to make it not go so deep when we came up on the continental shelf.
Given the idle nature of a month or two at sea, I started looking at the bathymetric electrostatic chart printer we had, and realized it had some kind of 4 bit output that was basically the raster of each depth print scan.
So what I recall is wiring up the 4 pins to the 4 inputs (Busy, Paper-Out, Select, Error) on the DB25 on some PC, and scanning those to read the current bathymetric trace. Then turn that into a visual depth display overlaid on the 640x480 VGA display of the SeaSoar's position.
Eventually then, I was able to figure out where the bottom was and have it automatically do a "turn up" when it got within a certain range of the bottom. Bit of a knuckle biter the first time I had to trust it to not smash a quarter million $ instrument into the sea floor.
These were fun hacks. You're at sea, no internet, no place for parts, just hacking together stuff and dealing in the moment.
For quite a while, the parallel port was the only external high(-ish) speed port on PCs, not only used for printing, but also scanning, networking (with a yellow LapLink cable, or, if you wanted to get really fancy, a Xircom Pocket Ethernet adapter that almost did 10Mbits/s) and even storage (various weird MO contraptions, but also a regular hard disk with almost 1MB/s read performance...).
The history in the linked article is quite comprehensive, and touched on the slightly-incompatible (EPP, ECP) standardization efforts for bidirectional use. When USB finally came along, that made things a lot more convenient.
Out of desperation, I once soldered a bunch of resistors onto a parallel port connector to create a crude DAC converter so I could get my PC to output "high quality" audio. The results were pretty good! I could play MOD files as if I had an actual sound card.
Early USB was terrible on both hardware and software support. It took a long time for most people to stop using parallel. Honestly, the only thing I ever used USB for before the USB2.0 era was computer mice.
I usually ended using the PS/2 adapters because the USB mice wouldn't work when you first plugged them in, but they did if you used the PS/2 adapter, and then I'd just leave them that way.
My first MP3 player (the Rio PMP 300) and digital camera (Canon Powershot 600) both used parallel ports for data transfer. Plenty of other weird things used
the port, Autocad’s licensing dongles come to mind. It was really used for some versatile functions!
As a young kid I remember developing this conclusion that Macs must be better because ours had a SCSI port and the devices were just better and faster than the parallel port devices of our PC.
I ran my entire physics thesis project on the parallel port, using homemade ADC, DAC, and stepping motor drivers. Turbo Pascal provided built-in functions for the "port" i/o operations of the 8088 CPU. All's you needed was the address.
A buddy of mine got an Apple Mac. It was lovely, except... no GPIO. But it had a serial port. Creating simple devices that could talk to the Mac serial port was my first introduction to microcontrollers. Of course, programming those microcontrollers required a device programmer, which I built and connected to... you guessed it... the parallel printer port of my PC.
> It was easy and cheap, before microcontrollers were as friendly to use as they are now.
I got started with AVR microcontrollers with a DIY parallel port ISP adapter: just cut a printer cable in half, solder in 4 resistors and you were good to go :-)
Then spend a ridiculous amount of time re-learning assembly to port the parallel port LED blinking program from DOS to the AVR.
Only needing the few scavenged parts and buying just the MCU was a lot cheaper than buying the "recommended" adapter cable or some eval board, making the whole thing affordable for my 13 year old self.
Things certainly got better. Now it is very possible to get Arduino devboards under $3 from China.
If you must, as it's possible at the same prices to instead get much more powerful microcontrollers with RISC-V or ARM processors, like the ESP32 or STM32 lines.
Early PCs were actually really similar to modern Arduino boards. UART for Serial Port, GPIO is basically parallel ports, ADC vs Gamepad port, etc. etc.
20MHz Arduino Uno compares favorably to 16MHz 80386, its really just RAM that's feeble (2kB SRAM on Arduino Uno, which is much less than computers in the 80s), but its not too hard to expand RAM out a bit (or buy a comparable uC today that has 1MB or so of RAM)
-----------
Even then, today's I2C ports (Arduino / Rasp. Pi) are way easier than old ISA stuff, but you run into very similar issues. I2C address collisions can cause a lot of pain, and ISA boards had DIP switches to move those peripherals to other ports.
I2C is much more streamlined compared to ISA. Especially because we don't care about speed anymore (if you "need speed", USB and other protocols exist. All the protocols for modern uCs are for convenience: SPI, UART, I2C, etc. etc.)
The Harvard architecture on Arduino and not being able to load code at run time is a real buzz kill. It would be so much better if you could execute out of RAM so young hobbyists could make their own Apple II grade hobby computer.
Microcontrollers were always weird. Z80, 8051, AVR... they never were designed to really use OSes like Linux or Windows (or Apple II).
That being said: Rasp. Pi, Beaglebone Black, Le Potato, and many other SBCs are proper computers with proper OS support.
---------
Back in the 80s, the Microcontroller vs Microcomputer concept wasn't really solidified yet. Yes, the 8051 and Z80 existed, but they were still external memory bus and kinda microprocessor-ish.
If memory serves, game ports on PCs didn't use any ADC as those would cost a lot in the 80s and 90s. They rather used the gamepad controller (a potentiometer) as part of a RC oscillator where the C was on the mainboard, then they would sample the period which would be proportional to the controller resistance and get the relative position.
Arduino Uno is mostly 1-clock per instruction. A 16MHz ATMega328p scores 16MHz MIPS.
80386 was mostly 4-clocks per instruction. A 20MHz 80386 only scored 5MHz MIPS. Most 1980s/90s computers were multiple-clock-ticks per instruction (8051 was 12-cycles per instruction, so a 12MHz 8051 is only 1 MIPS).
I don't think Intel got to single-cycle instructions until 80486?? Hard to remember all the differences...
Furthermore, the ATMega328p has many 16-bit instructions, like add, which operate over two registers in one clock tick.
That's exactly the distinction. "Parallel Port" meant two things in the PC world:
* An ad hoc standard descended from Centronics printers for transferring data on a 7 bit parallel TTL bus.
* The IBM PC Parallel Port Interface, an extremely simple (like four chips!) 8086 ioport based controller for the various lines in the port that was used for decades as a general GPIO interface for whatever gadgets you wanted to hack together.
To the enduring shame of everyone involved in the disaster, the USB standardization process for "parallel port" treated only the first definition. It only does data transfer at the line level, there's no individual control over the wires as there is for the PC interface.
It's basically useless, unless your problem really is to connect a printer to your USB host. That said, there are proper USB GPIO controllers out there. But DOS software written to the old standard (and there was a lot of it!) is unrunnable junk now.
Indeed, that's how basically everyone I knew growing up who managed to interface stuff to PCs did it. Except the one guy with a hand-me-down BeBox. That GeekPort was something to envy.
I never got why the GeekPort didn't catch on more beyond BeBox, even as an add in card, given how ubiquitous the parallel port was for interfacing with simple external electronics.
Yeah, there were tons of "basically a GeekPort for PCs" in the industrial control/test and measurement world, but not much aimed at home hackers or even really low-end experimentation. I don't know if that's a result of just the parallel port being used so often and it not being cost-effective, or what.
In the pre-PC home computer world, there were products like that, and even in the early x86 ISA PC world, there were analog/digital I/O cards that didn't break the bank.
Me too, I also had a board with 8 relays and a centronics printer connector. Super easy to switch stuff on and off safely back in the day when a PC was a serious investment.
I believe there are some rare adapters that will work with custom drivers, but almost all of them I've seen are programmed specifically to provide a printer device.
> Would that still work with USB → Parallel convertors?
I use FTDI 232h based devices to drive 433Mhz transmitters, using gpio/bitbang functionality. There are multiple pins that can be used for that so theoretical parallel port like functionality can be achieved.
IEEE 1284 is the relevant standard for "modern" (ECP/EPP) parallel ports, but most adapters only provide that interface on the printer side, not a general-purpose host-side interface to control an IEEE 1284 port.
ECP and EPP are not really useful for GPIO-style use and even the simpler modes are not really desirable if the adapter is implementing the handshaking in hardware. You really just want to be able to manually control all the bits. The original parallel port (and later integrated ones when set to an appropriate mode in the BIOS) allowed this because it was a very simple device and relied on software to handle things like toggling the data strobe line when a byte was written to the data lines.
I started using PCs at the start of the century, and it had a parallel port (still in order). When I entered university about 15 yrs later, using it as a makeshift GPIO was my first use case, ... was too broke to afford a Raspberry Pi.
Now that I'm not broke anymore, still pi is out of stock everywhere
Early parallel ports were often used for hacked "GPIO" applications, they gave you more useful lines than a serial port and were often less picky about the voltages.
The "Speech Thing" [1] is the most commercial example I can think of, until "laplink" hit.
There's another reason why USB-to-parallel adaptors can't replace a PC with a printer port: the latency for round-trip applications is significantly higher over USB. It takes a few microseconds to read/write a byte from a PC printer port. Over USB, the control message latency leads to this taking tens of milliseconds. USB beats it on throughput, but only when transferring lots of data.
Before they disappeared, printer ports on motherboards began getting worse for latency and compatibility. This was likely due to cost reduction since low latency two-way communication was not needed for printing.
There was an interface for old Commodore floppy drives that is just remapped pins on the printer port[1]. When PC's circa 2005 stopped working with it, I designed a USB microcontroller board to implement the protocol[2]. It had to do some fancy state machines to get around the round-trip problem, caching a set of commands until the host was ready for the transfer. Then it would send them all back-to-back and start streaming back the bulk data. Fun stuff.
> Over USB, the control message latency leads to this taking tens of milliseconds.
This sounds an order of magnitude wrong. I have just setup a loopback with a CH340 USB to serial adapter and ran the following code:
#!/usr/bin/python3
import serial
import time
ser = serial.Serial(port="/dev/ttyUSB0", baudrate=1_000_000, timeout=1)
iters = 100
x = time.time()
for i in range(iters):
towrite = b"%i\n"%i
ser.write(towrite)
line = ser.readline()
assert(line == towrite)
delta_ms = (time.time() - x)*1000
print("Finished %i iterations in %ims = %.1fms/iteration"%(iters, delta_ms, delta_ms/iters))
and it says Finished 100 iterations in 272ms = 2.7ms/iteration
Amazingly I was just thinking about the parallel port this morning. My first PC (a Toshiba T1850 notebook) only had a serial port and a parallel port. Wanting faster network performance inspired me to play with PLIP (parallel-port IP). PLIP only works in nibble-mode so I played with the bidirectional support and got it working. However, I didn't measure much improved performance and lost interest. Indeed, later EPP and ECP came around, but at the time I couldn't find any documentation. This article fill of lot of the gap and has some amazing backstories I never knew, very cool.
My first two networked Linux computers where my desktop (probably a 486) and a laptop, though the parallel port using PLIP. My desktop was much faster than the laptop so I'd just launch a X11 server on the laptop and then run everything on the desktop. By doing that my brother and I could both use the Internet (Netscape) at the same time, sharing our... 28 800 modem connection : )
It not too far from how I work today - I have all sorts of devices around the house that I use to ssh and tmux attach to my EPIC server; I’m logically running the same session for months, but the terminal changes several times a day.
I don’t think any of the devices in use have a (parallel) printer port though.
I remember my father teaching me about some basic digital electronic using the parallel port. How to multiplex and use it as GPIO & primitive expansion bus.
Eventually, my father had some board using parallel port for stuff. Including a Dobson telescope control board (based on Mel Barters designs). I had half-write a program to control it from Visual Basic (there was some VB controls that allow to direct control of the parallel port). Sadly, the Dobson mount and the control board was lost when we move to a new house.
20ish years ago I was on a team that was working on the PC version of a popular sports game. For the multiplayer mode (2 players only), the way the game worked both instances had to maintain the exact same internal state. For debugging, one of the things we used to do was connect two machines together via the parallel port and let them play each other for hours. It was slow, but still far faster than ethernet because the latency was so much lower.
> Even better, the original IBM PC was capable of a "direction-switching" handshake that allowed the peripheral to use the full 8 bit data bus to return data. This feature was apparently unused and disappeared from subsequent PCs, which is ironic considering later events.
I guess this is talking about the XT and AT, but the article kind of makes it sound like this simple bidirectional mode was gone from all PCs after the 5150 when it in fact came back with the PS/2 and remained present on clones long after that. You generally needed to set the right parallel port mode in the BIOS, but I was using this simple bidirectional mode for communicating with a Sega Genesis over its controller port in the mid-2000s.
Sorry, that is a bit unclear. You're right, sort of the oddest thing about IBM's basic bidirectional mode (which is pretty much equivalent to byte mode in 1284) is that support for it went away only briefly. I sort of wonder about the internal events at IBM here, one would think they were probably starting to develop applications for bidirectional mode at the same time they stopped including it, since they brought it back pretty quickly. Something I didn't make clear enough in general is that, as with several other interfaces, the modern "parallel port" is pretty much a clone of the PS/2 specifically.
> You're right, sort of the oddest thing about IBM's basic bidirectional mode (which is pretty much equivalent to byte mode in 1284) is that support for it went away only briefly. I sort of wonder about the internal events at IBM here, one would think they were probably starting to develop applications for bidirectional mode at the same time they stopped including it, since they brought it back pretty quickly.
You got me curious about this and so I looked into it a bit further. I managed to find IBM's technical documentation[0] for the original printer original printer port card and it looks like it only sort of supports bidirectional use of the data pins. It supports reading the state of the data pins, but it seems this was intended to be used for diagnostic purposes. There's no way to disable the output drivers for these pins like there are on later bidirectional ports. The manual does mention that if something happens to drive the pins the result of reading the port will be that value ORed with whatever was written previously (though I've seen claims elsewhere that it's actually more of an AND), but it also cautions that driving these pins externallly is "in violation of usage ground rules". Apparently some folks did use it this way though and perhaps that's what inspired making it properly supported in the PS/2.
It's unclear where this idea that the original PC had this feature, but it went away came from. I looked at the manual for the AT's serial/parallel combo card[1] and the parallel port portion is almost identical. I guess it's possible the hack to use unidirectional didn't work in some 3rd party cards or clones.
I remember the best multiplayer DOOM experience was got using a little hacky IPX/SPX over parallel driver. When my friend would bring his rig over to my place to play we always spent way longer getting stuff to talk to each other than actually playing. Good times.
IPX over parallel is true dedication! We at least had network cards so the only difficult part was remembering to put termination in the right places on our 10Base2 ethernet.
Have bricked a windows NT server pluging a printer while the machine was ON => kernel panic and NTFS filesystem was corrupted. Beware the parallel port is not hot-pluggable :)
I plug/unplug many times a printer, and a ZIP disk unit, to the parallel port without issues on Windows 95/98/ME. And more recently, a 90's Roland plotter on a 2010's computer that have yet a parallel port, running Debian.
Probably like the ps/2 port, it's not actually hotplugable, but most of the time you can get away with it.
The article mentioned there was an effective dma mode where the parallel port was wired directly into the isa bus. I imagine that if a port was in that state it could cause some real havoc if something suddenly got plugged in.
AT motherboards had a physical, discrete fuse on the keyboard connector that would sometimes blow if you hot-swapped the keyboard. Then soldering iron ahoy.
Oh man, using laplink with the parallel port and serial port was way faster than floppies. Used this method for years to rescue files off computers. You could even bootstrap laplink using dos copy con if there were no working floppies if I recall correctly.
Correct. I'm not sure if Mach3 is actually sending pulse data at all. It occurs to me that they could send timestamps plus pulse rates in a more compressed exchange. I believe there are other systems that do work this way.
Back in the mid 90s I was teaching myself QBasic and basic electronics. Realizing I could combine the two via the parallel port on our PC was a magical epiphany that I'll never again experience. Being able to "pull" programs into the physical world blew my 14 year old mind.
Our modern PC's have a surprising lack of human scale IO. It's all usb, pcie, sata. Nice enough interfaces but very hard to work with from first principles. If you are lucky you will still find an exposed gpio or serial header.
Most boards have the serial port in a header. It is the same pinout that I/O cards in old PCs in the 1980s used for extra ports. Careful that they are at RS232 levels, not TTL. It is a shame that it isn't directly exposed in the backplate.
The control lines can be abused as GPIOs, but I would not recommend doing so.
Many USB to TTL UART chips do also expose GPIO functionality, if you want somewhat direct access to GPIOs.
Given the idle nature of a month or two at sea, I started looking at the bathymetric electrostatic chart printer we had, and realized it had some kind of 4 bit output that was basically the raster of each depth print scan.
So what I recall is wiring up the 4 pins to the 4 inputs (Busy, Paper-Out, Select, Error) on the DB25 on some PC, and scanning those to read the current bathymetric trace. Then turn that into a visual depth display overlaid on the 640x480 VGA display of the SeaSoar's position.
Eventually then, I was able to figure out where the bottom was and have it automatically do a "turn up" when it got within a certain range of the bottom. Bit of a knuckle biter the first time I had to trust it to not smash a quarter million $ instrument into the sea floor.
These were fun hacks. You're at sea, no internet, no place for parts, just hacking together stuff and dealing in the moment.