Hacker News Reader

Comment by samcheng | Hacker News Reader

Back in the day, the parallel port was awesome for hobbyist hardware hacking. You could 'bit bang' and basically use the pins as general-purpose I/O pins.

Rather than the bespoke setup described in the article, I guess the most-common equivalent these days is a USB connection to a Raspberry Pi or Arduino or similar?

View on HN

>Back in the day, the parallel port was awesome for hobbyist hardware hacking.

Also the MIDI-game port which was basically an ADC for the PC, meaning you could build your own gaming racing steering wheel using a volume knob screwed in the middle of a CD cake case and pedals using volume wipers, all connected to the MIDI port with no extra drivers needed. Good times.

Curious, MIDI is a decidedly digital protocol...

ISA cards, like the soundblaster had the MIDI and joystick on the same connector. The joystick had up to 4 analog inputs, maybe that's what's meant here.

The PC game port is a nearest thing to intentional GPIO that PC has. Parallel port is almost always better for digital GPIOs, but it was not designed that way and the fact that it can be used like that (and extended several times into what in the end was SCSI-like protocol) is kind of an coincidence.

> The PC game port is a nearest thing to intentional GPIO that PC has.

Er, what? Not every IBM PC (clone) had a (sound) card with joystick ports, but almost every PC clone had (ISA, later PCI) extension slots. There were/are plenty of digital i/o adapter cards for those available, from plain, cheap 8255 based ones to those with slave CPUs (potentially more powerful than the host's CPU).

But then, perhaps I don't understand what you mean by 'intentional' GPIO.

Maybe it would be better to say it was a common enough interface to hook up devices that were essentially a bunch of potis and not much more?

The game port was amazing. You got 4 ADCs (for the X axis and Y axis of a joystick, 2 joysticks supported) and you got 4 GPIO bins for the "buttons" (2 buttons per joystick, again 2 joysticks supported with 1 port).

If you didn't care about burning CPU, you could bit bang these "button" inputs and interface simple home-brew electronics. The clock line attaches to one "button" pin, the data line attaches to another "button" pin. When button 1 is "pressed" sample the state of button 2! Now you are reading a data stream.

I used this trick to interface magstripe readers directly to computers back in the early 2000s, and even wrote an article for the first issue of O'Reilly's Make Magazine about it. While professional readers/writers were hard to get, cost $100+, interfaced to the parallel or serial port, and used proprietary software, this let me do it for around ~$20 in parts and use my own software. I had quite a lot of fun learning what was stored on the various tracks of the cards I had, like my student id.

https://stripesnoop.sourceforge.net

Fun times of directly accessing hardware.

The world keeps flip flopping between serial and parallel.

Back in the day parallel ports were awesome because they were effectively 8 serial ports in parallel (sounds awesome right? 8 times the bandwidth)

But then some dude came along and USB did 100X the bandwidth in a serial bus. Then other dudes were like "okay great now let's put multiple USB data pairs in parallel" and boom USB 3.2 was born. Parallel again. USB-C is effectively a UPB.

Parallel ATA was the shit back in the day for hard drives but then Serial ATA replaced it. Now we're at NVMe which is parallel again with 4 PCIe lanes.

CompactFlash (parallel) -> SD (serial) -> UHS-II (parallel), same story

BNC cable ethernet (serial) -> 100-Base-TX (parallel) -> fiber (serial) -> fiber bundles (parallel), same story

Classic parallel (ATA, PCI, parallel ports) is going away and not really coming back. The newer interfaces like 4xPCIe and USB are multiple serial interfaces bonded together.

The difference is all the bits in a true parallel interface operate synchronously. All the bits get set; the clock pulses to signal data is ready; all the bits update again. The problem with this approach is you have to wait for all the bits to settle before you can read. It's no problem at low frequencies, but when you get into hundreds of MHz or more, it becomes a real challenge to get everything time-aligned.

4xPCIe channels operate on 4 independent clocks. They have the same nominal rate, but they don't have to be precisely aligned. Each channel is transmitting a single frame at a time - it's not splitting them into 4-bit packets and sending 1 bit down each channel.

I'm hard-pressed to think of a new technology in the last decade that implements splitting a byte into bits and sending each down a separate line.

I have a faint memory back in the day of using the parallel port to do super speedy file transfers (compared to serial at least). I wonder what insanely low bandwidth I was using by todays standards…

> I have a faint memory back in the day of using the parallel port to do super speedy file transfers (compared to serial at least).

In the mid to late 90s, I was sharing my main 486's dial-up connection with an old clunky laptop using PLIP:

https://docs.kernel.org/networking/plip.html

So my brother and I could both use Netscape at the same time, on two different computers. Felt like the future!

P.S: actually the laptop was just running an X (back then not even Xorg yet) and displaying a Netscape window running on the main, beefier, PC. All over PLIP : )

LapLink!

https://www.cambus.net/file-transfers-via-the-parallel-port-...

https://en.wikipedia.org/wiki/Laplink

Ah! You got me down the right rabbit hole. I think I was actually using INTERSVR and INTERLNK but yes, must have been a LapLink cable.

https://en.wikipedia.org/wiki/List_of_DOS_commands#INTERSVR_...

That was magic for me the first time I transferred a file between computers. I didn't have to re-type my code! What a time to be alive.

Before Arduino and the analog Square reader, the parasitic-powered serial port wireless X-10 Firecracker seemed magic level to me.

https://www.x10.com/products/cm17a

The serial null modem cable with 4 ends commands you!

There is the cable used for things like LapLink and PLIP, that was inherently bitbanged. Then in theory with ECP you could connect two PCs with straight-thru cable and get something like 500Mbps with DMA support from that, on paper it was faster than both FireWire and USB HS. Whether it ever really worked is another question.

FTDI also makes a lot of USB chips with software controllable GPIO pins:

https://www.adafruit.com/product/2264

https://ftdichip.com/products/ft2232h-mini-module/

Bit banging on a modern OS subjects you to a lot of jitter though. It's not like using a parallel port in DOS where you just have to worry about interrupts. The preemptive scheduler can really mess up your timing.

That said, the FT232H, FT2232H, and FT4232H have an FTDI Multi-Protocol Synchronous Serial Engine (MPSSE) cores that you can program to protocols like SPI and I2C where the high speed part doesn't require any smart logic to handle. It's a bit of a special skill though (you send MPSSE specific command bytes over the USB interface into the chip's command buffer and tell it to execute them).

If you need more high speed smarts, it's also convenient to use a Raspberry Pi Pico with MicroPython or CircuitPython with Programmable I/O (Pio) with an interactive session:

https://www.raspberrypi.com/news/what-is-pio/

https://docs.micropython.org/en/latest/rp2/quickref.html#pro...

But yeah, beyond that, you're better off using an Arduino or something and doing it all on the microcontroller.

On the plus side, all of these things are relatively cheap and easy to obtain.

Also, while libftdi isn't hard to work with:

http://developer.intra2net.com/git/?p=libftdi;a=blob;f=examp...

It's dead simple to also use these FTDI devices with Python:

https://eblot.github.io/pyftdi/api/index.html

I wanted this for GPIO on my PC to interface with some hardware, but all the prebuilt USB TF232 adapters had the GPIO pins closed off, and AFAICT the TF232 requires flashing using some proprietary windows binary to get into a mode where the GPIO pins can be used as GPIO (since it has multiple modes of operation).

I can't believe I'm not missing something... Is there an off the shelf USB GPIO device somewhere? Plug it in and start using the linux GPIO driver?

The solution my friends gave me was "buy an arduino", flash the arduino, and use the arduino's gpio... which yeah, I could do, but is that really what it takes for a $2000 desktop to flip a bit these days?

That (or an ESP) is a really effective, easy, and cheap solution, which makes it hard for a more limited and more expensive solution to take hold. Most everyone who wants a digital output is capable of following the Arduino route to the end.

There's little market for the product you crave. Most people who know what GPIO is know how to buy a $5 microcontroller with a USB port and upload some firmware to convert serial commands to the pin states/transitions they need.

Here a few options for you:

https://www.adafruit.com/product/2264 - USB to GPIO (and other stuff)

"Bus Pirate"

Or get a RasPi - it's not your desktop PC, but they're running Linux with direct GPIO access available in userspace.

The FT232H you linked in the default UART configuration has no GPIO pins according to the datasheet pin description table. You need to change to MPSSE mode or similar using the flashing tool.

The Adafruit FT232H works out of the box with pyftdi and libftdi. You don't have to use any special tools or flash it in any way. The USB commands are handled by the underlying libraries.

See page 9 of the datasheet here:

https://ftdichip.com/wp-content/uploads/2020/07/DS_FT232H.pd...

The async and sync bitbang columns denote the GPIO pins as D0-D7 and show them assigned to the 8 ADBUS pins that are provided on the breakout board.

Assuming the udev rules are set up in Linux, you can simply install pyftdi, open the device, and start using the ADBUS pins as GPIO pins:

https://eblot.github.io/pyftdi/gpio.html#setting-gpio-pin-st...

If you're using libftdi, you want to call ftdi_set_bitmode with the BITMODE_BITBANG enum value for the mode:

https://www.intra2net.com/en/developer/libftdi/documentation...

Then the ftdi_read_data and ftdi_write_data functions can be used to read or write to the ADBUS pins:

https://www.intra2net.com/en/developer/libftdi/documentation...

You can then build a nice, simple high level GPIO interface over that if you want.

Parallel port adapters maybe?

> Back in the day, the parallel port was awesome for hobbyist hardware hacking.

R-2R Soundcard!

Soundblasters were crazily expensive (and a Gravis UltraSound even more), but you could solder a R-2R resistor ladder [1] connected to the parallel port, and have pretty decent soundcard (well, at least when compared to the onboard speaker) for $10 or less [2].

Not many games worked with it, but it was quite popular amongst the demoscene at the time.

[1] https://hackaday.com/2014/09/29/the-lpt-dac/

[2] https://en.wikipedia.org/wiki/Covox_Speech_Thing

Yes, this is the concept of the Firmata project.

and if you only needed a few milliamps at 5V, you could tie together a few lines (ideally with isolating diodes, but in practice, total bridging worked fine) and get enough power to run your circuit. I had tiny i2c eeprom programmers built into DB25 hoods that just worked being plugged into a parallel port.

Reply on news.ycombinator.com