←back to thread

407 points sbt567 | 3 comments | | HN request time: 0.492s | source
Show context
rkagerer ◴[] No.44384301[source]
This is awesome!

But it also makes me a little bit sad. The original parallel port and even ISA interface seemed so simple by comparison, with less layers of abstraction. Just run a wire, and write to a port.

I remember when I was a kid, I found a breakout board in an electronics store's random clearance parts bin, with an ISA header on an edge. On a whim I took it home and wire-wrapped a 7-segment LED onto it. Power and ground were easy. Each segment was hooked to a data line, through a simple buffer IC. I cheated and used only a minimal number of address lines to feed the enable port (guessing through a simple AND gate or something). I was amazed when I wrote to that address and it worked the first time!

I look at a protocol like USB, with hundreds of pages, and instead of that curious excitement and enablement I felt back then, I feel a bit overwhelmed.

replies(5): >>44384342 #>>44385045 #>>44386730 #>>44388110 #>>44390357 #
colechristensen ◴[] No.44384342[source]
I sometimes think about this, starting from scratch with a computer hardware and software stack that disallowed all of the layers of abstraction that have built up over the decades.

Yeah many of the abstractions help with performance but maybe there's value giving up much of that performance in exchange for simplicity.

replies(2): >>44384731 #>>44388041 #
1. dspillett ◴[] No.44388041[source]
For toy tinkering, to replicate something like the old ability to just write a byte to an IO memory location and have it appear on the pins of a parallel port, you could design a simple USB peripheral that did similar. Give it a set of DIP switches to pick a number (4 for 0-f, more would probably be overkill but feel free) and have the driver present something like /proc/simpleio/device<num>/in and /proc/simpleio/device<num>/out/pin<num> for reading & writing¹. If you use the same set of pins for in and out, /proc/simpleio/device<num>/config to state which direction each is expected to work, and perhaps set voltage options (probably per device, per pin sounds overkill for this). Release the full design and let people make their own, sell pre-made boards and cases and/or let others do that (or just the boards and have people 3D-print their own cases). Devices could have as many pins as the maker likes.

That would only cover the real basics: reading/writing the hi/low status of pins. Other things people might want is analogue voltage control/read (for many sensors) or pulse control (for controlling servos and such). Things like that could be mapped into the /proc/simpleio/device<num>/{in|out}/pin<num> files. Perhaps for setting/reading multiple pins at a time perhaps have something like /proc/simpleio/device<num>/{in|out}/allpins. You could expand the feature in many ways, though TBH beyond the simple hi/low thing people are probably better off getting an rPi or microcontroller and using all the available devices and plans there are out there already for their IO pins and using something newer.

--------

[1] Not sure what you'd do for Windows, I'd be inclined to release a Linux driver and let the Windows community worry about one for their platform.

replies(2): >>44388550 #>>44388852 #
2. colechristensen ◴[] No.44388550[source]
USB parallel ports, data acquisition peripherals, or modern boards that run linux and have GPIO pins are already a thing and don't need to be created.

What I'm talking about is a whole computer system + systems programming language + OS which is as simple to understand and program as computers were in the 80s. With modern speedups, without modern layers of abstraction.

3. rkagerer ◴[] No.44388852[source]
Thanks for the info!

I actually bought a real parallel port card years ago that plugs into a PCI port on my motherboard. Incidentally it also provides 4 serial ports.

Only tried it on Windows, but it works great. If I recall there was some kind of library I have to use in modern Windows versions due to a permissions or kernel isolation thing.