That was kind of my point. People have got used to Bluetooth being flaky, WiFi having dead spots, WiFi performance not being that great, etc. They've forgotten how good wired connections are.
In my house I have a nice WiFi set up and performance from the Apple TV was awful. I discovered that someone had put in some Cat 5 in the walls and managed to test it, splice a few cables and get Ethernet working. End of trouble.
Same here. I specifically wired everything in my new house, including Chromecasts. There's enough going wrong with random software that adding a wireless link into the mix doesn't help.
Laplink was so great and always worked. The only thing was the lack of possibility to play games over parralell link, only serial was possible. That is not laplinks' fault but rather the technology. Naturally parallell 25 pin cables had a much higher throughoutput rate than serial 9pin links had.
What games did Laplink enabled serial multiplayer for? Back then game devs had to roll their own.
And likely they chose to avoid parallel because early ports were not intended for communication but rather a primitive extension of the CPU bus to an external device, originally printers. It allowed you to send bytes to a device and then read back a few GPIO like signals the device would set to indicate things like acknowledged, error, paper jam and so on. It was only later on they added functionality and smarts in the form of ECP/EPP with two way data transfers, buffers, IRQ and DMA. On top of all that, a parallel bus over cable is severely limited to something like 4-5 meters or 15 feet. Serial from the get-go was designed for device-device coms and with the right cable, RS232 can extend up to 100m. Of course you can change the electrical interface of serial to a differential, current or fiber interface and extend serial to reach many km.
It did read as if laplink was part of serial gaming and wondered if there was some alternate functionality or API/TSR it offered which I was ignorant of.
I loved the kit: easy to use software with a hydra cable that linked to everything available at the time (which was basically serial and parallel printer ports). Did many migrations with this thing. I remember one friend asked me to bring over "your computer jumper cables" to help migrate.
The version I had came with a thin blue serial cable with DE9 and DB25 serial connectors on both ends. The thick yellow parallel cable had to be purchased separately.
The first x86 system I had was a hand me down 286. The parallel port on the motherboard was only unidirectional, so I modified it to be bidirectional by soldering a bodge wire between the output enable signal on one of the 74LS374 (I think) and the other control register. Ah, old systems were so hackable in the 1980s prior to the mass migration to large scale SoCs.
The parallel port was wonderfully hackable. Having your PC control an LED light, or even a motor (with some effort), didn't take a whole lot of electronics knowledge. Or 8 LEDs, one per pin. And controlling it was as easy as sending text to a printer. We lost this in the age of USB...
When I was a kid my dad helped me hook up a pin to a motor. And not just any motor, but one inside a cassette tape player. I could then make little games in BASIC that had real voice! Of course it had to be linear, it basically played chunks of voice recording and stopped at the right times.
This sounds almost exactly like my first taste of computing with my dad; 8 low voltage fillament bulbs (and some buffering) wired to the parallel port, along with some simple code to count in binary. Sure, I was a kid and more excited just to have flashing lights, but in my more studious moments I did learn so much about binary, how things are represented in computers, programming, interfaces etc etc.
It seems like all of our modern abstraction layers have lead to a dirth of tinkerers on the edge between metal and software. There isn't any easy gpio on your standard Chromebook or desktop for instance. Yeah you can get a usb to gpio or make one. But being able to sit down at any computer and do something low level was nice.
that is a cool hack, but its just using i2c to talk to an atmega and have it do the gpio. You could just as well use the atmega from usb. Or an esp over wifi.
I once made a homebrew GraphLink parallel port cable so that I could upload games and programs to my TI graphing calculator. Made it a lot easier to write programs than to tap them out on the calculator itself.
A friend and I wrote a chat program that used the calculator-to-calculator GraphLink cable to send messages back and forth so we could chat in class. This was a neat hack, but considering the cable that came with the 85 was like 2 feet long, it was kinda useless in practice unless we were sitting at the same table. So I made a longer cable at home out of stuff from RadioShack.
Everything was cool until we got caught using the homebrew cable in class. Fortunately, once we showed the principal what we'd done, we were told that it was very clever, but not to have the cable in class anymore. :)
You know, I think I might still have my TI-85 and homebrew cables in a box somewhere. I wonder if any of my old programs are still there.
I recall dragging my massive second-hand Zenith 286 "laptop" into school and serving out zshell assembly programs to people with my homebrew GraphLink. I even sold a couple of them. Many a math class spent playing tetris on my TI-85...
There are many cheap system-on-a-chip microcontrollers that have enough computing power for many basic uses for which RPi is overkill, and some GPIO and built in wifi and/or bluetooth wireless, and they support dev frameworks like arduino or micropython.
Well, if your ok with the non-realtime characteristics of the RPi's GPIO via linux userspace, one might as well just buy one of the dozens+ of USB->GPIO adapters all over ebay/amazon/aliexpress/etc with windows/linux/etc drivers.
Or if you need something more advanced than basic LED blinking/etc, just pick up a wemos D1, or any of the dozens of other similar microcontrollers that can be had for a dollar or two that have GPIO and a USB serial interface and do your bitbanging on the ESP8266/etc in an environment that isn't susceptible to a heavyweight OS failing to schedule your task for long periods of time. One can hang that device off a PC and talk to it with simple serial programming/commands or just plug it into the target device as a wifi adapter and do all the control over Wifi+JSON/etc. Which it turns out are basically what most of the USB->GPIO adapters are anyway.
So, in the end, using a RPi for this is really sub optimal on every front, cost, performance/accuracy, complexity, power utilization, etc.
When I got my first Internet connection at home (kinda late as I was "big times" into BBSes before that), I was already using Linux. But we were too cheap to have a network at home so... I'd use "PLIP" (parallel port IP) to share our Internet connection between me and my brother: a parallel cable between my beige PC (a 486? Pentium? Don't remember) and a crappy old laptop. And so the two of use were simultaneously using Netscape or something.
It made me sad when computers starting shipping without a parallel port: I mean... Even laptop had these back in the days!
Yeah, I remember banging together a very simple ADC to take readings from various sensors straight into the parallel port - and being amazed at how easy it was to build something that could talk directly to PC hardware.
Indeed, my first PC to experimental hardware interfacing was through the parallel port with QBasic. It helps that the parallel port is a DB25-F and you can just poke wires into it :P
When I was young, I used it for a morse code decoder, and then later to decode magstripe data from a reader circuit I made with spare parts. QBasic made it trivial to interface with! I remember being able to achieve toggles at near a MHz with QBasic, since it was just a memory write.
Having that many IO, ready to go, was really great. I bought a separate ISA expansion card so I wouldn't burn out my motherboard's port. Now, you can get a little USB powered micro python board for the same price!
One of the most delightful and hilarious things I've ever seen anyone do with a computer involved a C64 and its parallel port. This guy I sorta knew in college had built a box with a bunch of relays and 120V AC power outlets. The parallel port would control the relays. Into this box, he plugged a bunch of lamps, then he'd turn out the other lights and play music on the computer, and the lamp would basically create a light show in time with the music.
He also had written some kind of memory-resident program (a TSR in DOS terms) that he could trigger while another program was running, and it would render pages of memory to the screen in real time. So he could start any program that had music, browse around through its memory space until he found a byte that seemed to be updating in time to the music, and then select that as the byte whose value got periodically copied to the parallel port.
So you could load up your favorite video game and then have a light show in sync with its music. Or any other activity of interest.
The communications speed vs disk size ratio was better back then I feel. A computer with no disk drive and only a floppy with a 10mb/s card wasn’t unheard of.
Wow, this takes me back to my freshman year of college in 1993 and trying to connect computers in different dorm rooms with lengthy serial cables. We eventually got it to work, but I remember it took a couple days of tinkering.
In the summer after that year, the school networked all of the on campus housing via ethernet, so connecting things the following year was much easier.
It could do both I think. I only used it with the parallel cable. And I still used it with Windows 95 in DOS mode. Back then most pcs still didn’t have NICs.
Oh this takes me back! I spent an afternoon soldering my own null modem cable so I could transfer large files without the hassle of spreading them across multiple diskettes (and play games, of course!)
Good old laplink. I've still got a "hydra" cable in my desk drawer.
Back in the 90s I used the parallel port to interface a PC to a TRS-80 to allow me to store games on the PC. As another commenter has mentioned, the parallel cable isn't fully bidirectional so I used the printer ready, paper out and other signals as imput lines and wrote a nybble (half a byte) based protocol between the two. Fun times.
My best use of LapLink was as a teen helping migrate a library off an old system. I think it was using NetWare 2.x with some DOS emulation for a library card catalog. Couldn't get it to talk IPX to the existing NetWare stuff (5.x) we were migrating to. But the DOS emulation was complete enough for us to install LapLink and bring over the files for the program!
I still have the yellow parallel cable and blue serial cables at my parents' house.
Also pretty sure I used the blue cable to do Command & Conquer over null modem to the next room at home before I figured out how to install IPX/SPX and get the machines to talk over the 10Base2 that was between them.
"I still have the yellow parallel cable and blue serial cables at my parents' house"
I still have both cables and they reside in my miscellaneous computer cables box (as opposed to the box of regularly used cables). I still consider LapLink (the software I also have) as a viable maintenance tool for when I have to occasionally maintain old DOS or Win 3.1 machines (surprisingly there are still some about including several that I own).
Recently, I came close to chucking them out but stopped short of doing that after I had to find some old files still stored on floppies and for doing that the quickest method was to use the DOS machine. (Logic dictated that if I still used a machine then it made sense to keep its maintenance tools.)
At my first desktop support job, we used to back up users' laptops over the parallel port to a blank drive on another computer.
One time, I got the command line parameters wrong, and accidentally ran the copy in the opposite direction, overwriting a senior manager's disk drive with a blank disk image. It was the first "big mistake" of my IT career.
Remember AT power supplies? i wired a power switch backwards once, turned it on, it exploded and started a literal fire in the office at a client. That was nice.
I think these were way more fun to play with if your line voltage was 220, than if your line voltage was 110; I only remember it as a thing to check if stuff isn't working, not a source of magic smoke or sparks.
I did a working interview at a pc shop in the late 90's, and the other guy doing the same interview swapped those on a customer's computer and smoked the new motherboard and the PSU. I knew there was an issue when they hired me... and him. Worst job ever.
I used it to fix a Windows 98 laptop that wasn't booting all the way to Windows. The would boot to a DOS prompt only, there was no CD-ROM driver, and I only had a Windows 98 install CD. So, there was no to re-install Windows to fix it.
So I wrote the assembly copier for the parallel port. I think it was about 200-500 bytes. Then I used dos DEBUG.EXE to write the hexadecimal code for the program into memory and then write the .COM program to disk. Surprisingly, I didn't make any mistakes (or any that mattered...) and it worked the first time. I had also done a checksum in the copy program in case I screwed it up. But it took about an hour to write the program into DOS debug.exe.
Thanks - I don't know if I ever tried that. I'm curious if that works, sadly I don't have any hardware to check anymore.
It seems unlikely to me though that that would work on DOS without special software because it's such a pauper's OS. To implement the read-side, the DOS kernel or COPY program would have to have a way to pretend to be a printer and then clock the data in according to some protocol. And given DOS is so resource constrained, seems unlikely Microsoft would add code in those fundamental pieces for such a use case, unless it were as simple as switching a few instructions.
There is also the INTERLNK and INTERSVR programs that are built-in to either MS-DOS 6 or 6.22 that could help with that use case.
Yeah, I've probably posted about it before - maybe even here.
Copying from a COM port could work because the MODE command could set the various settings - but input from LPT1 or PRN wouldn’t work by default in DOS.
Linux support IP over the same cable, it's known as PLIP, parallel-port Internet. It was the only way to access the outside world on my Toshiba T1800 laptop. However it wasn't fast (23 kB/s IIRC) and it completely bogged down the host (no hardware acceleration there).
There were experimental work on "8-bit PLIP", but the hardware wasn't very standard and in my testing it wasn't actually faster in practice. There was also some kind of DMA standard for the parallel port, but I don't think anyone succeeded in exploiting it for PLIP.
The who PLIP experience gave me a new appreciation for IBM's hardware accelerated "channels" concept - something we never got with x86 given its origin.
" serial communication is almost always faster than parallel communication."
Its a bit more complex than that. The PC serial port's top speed from the PC->printer/etc was significantly faster than serial at the time. Its only in the reverse direction that there were problems (note comment above about using the control lines for device->PC). And that is by design, the ISA/PCI/RAM/etc buses were parallel, and despite many of them becoming "serial" are still technically parallel (ex: PCIe) because its far easier to gang a bunch of serial data lines together and deal with said synchronization (which is frequently fixed by the hw design/trace length/etc) than attempt ever higher serial frequencies.
And that is fundamentally the problem with trying to use serial as a high speed peripheral interconnect (see HDMI vs displayport for an nice example of hitting walls). Eventually one runs out of bandwidth and the solution ends up being ganging a pile of them together into a... parallel bus. Its why thunderbolt will perpetually be a loser when it comes to GPU attach/etc. A serdes at N Ghz+PAM can just be put on a motherboard x16, and each line is synchronized at a higher level instead of each bit. Ex: PCIe 6. Same with RAM buses, the latency and bandwidth advantages have basically kept them parallel buses (using per line serdes kinds of tech), despite various serial memory standards.
Another example is ethernet where QSFP's are just x4 serial lines.. aka in parallel. SAS x4, etc.
So, these days like RISC/CISC its hard to be 100% correct calling some of these technologies pure serial or parallel.
I don't really agree with your classification of serial v parallel.
With a parallel port line, if you trim any line, the entire port is dead. What we now do is multiple serial lines sending data in parallel, but still in a serial fashion (IE, encoding data rate and clock information per line). If you cut a serial line, data still flows. (even with something like PCI-Express).
The key distinction is a parallel bus has effectively a single clock for the arrival of data whereas serial lines are allowed to have data flow at different rates per line.
Serial lines require more hardware at either end to work effectively but ultimately don't have the timing and cable length issues that plague parallel bus transmissions.
Though, I admit this is probably the same as quibbling over using threads vs forking for concurrency.
I figured someone would say this (each bit clocked in parallel), but there are a lot of other things one can use in an attempt to quantify whether something is "serial or parallel" and I don't think at the highest level any of them count more than whether or not your physically sending multiple bits in parallel down multiple wires.
Oh, and BTW, you can cut data lines on any number of "parallel" buses like DDR and they can frequently continue to work because there are extra ECC/parity lines which can recover the original data, or they are packetized and can recover/detect errors. Particularly on die/board level clocked interconnect buses which don't have as much complexity as the longer distance, outside the chassis interconnects.
OTOH, a single serial line is done if it gets cut. You can only fix that by... ganging them in parallel.
(edit: I keep tweaking this, but clock recovery isn't a hallmark of serial lines either, as there are plenty of things traditionally considered serial that have separate clock lines and have the same problems that happen on what one might consider a traditional parallel bus when run at high enough frequency)
Windows 9x did as well. It was a cheap way for my brother to be able to go online without extra hardware like network cards: I'd dial up the ISP from my computer, and he'd open up a parallel-to-parallel connection. I had Proxomitron running (ah, the good old days of HTTP proxy as an ad blocker) and on his browser he'd set that up as the proxy server and be able to go online.
> However it wasn't fast (23 kB/s IIRC) and it completely bogged down the host (no hardware acceleration there).
In the most basic fallback mode, the "uplink" from device to host is actually working 4 bits at a time over the "control" lines. All polled with no interrupts. The driver spends most of its time in a busy loop.
The parallel port eventually did eventually get quite fancy in the 90s, with buffered, interrupt-driven bidirectional communication possible in ECP mode (~2 MB/s). But USB was already on the rise by then and it was basically obsolete by the time drivers and motherboards widely supported it.
IIRC, you could only utilize ECP mode with a laplink brand cable (which would give you the faster transfer rate). Otherwise, you had to use EPP. I used the latter with a regular parallel cable with an adaptor I soldered with a certain pin to pin configuration.
It depended on the quality of the IO-chipset on your board, or cards. I remember experimenting with that between 91 to 94, and got it up to 4Mbit/s via parallel with ECP/EPP-DMA something.
Darn, you beat me to it! I just posted a similar comment. I also had some old Toshiba laptop and I'd use PLIP between that laptop and my PC. I don't remember it being particularly slow though: but it was many moons ago so...
There was a lot you could do with the parallel port. I was a coauthor on a paper about using parallel ports to interconnect computers to provide barrier synchronization for large parallel computing projects. It was a surprisingly fast way of getting a bunch of single bit synchronizations across a bunch of machines. This was back in the early 90s.
That interconnect was 3 or 4 orders of magnitude faster than Ethernet at the time for things like barrier synchronization and the hardware was fairly simple. [1]
Good links there. At a slightly higher level, I've sometimes wondered whether RTOSs and OS schedulers could make use of special-function hardware registers for keeping track of priority logic, etc.
Very cool. It all started because we had a bunch of gateway PCs that had parallel ports and we wanted something to synchronized across them. It was fun trying out different parallel cards made with different 374 latches. We even made a few custom ISA cards to play around with other ideas. Hard to believe it has been 30 years since I was at Purdue!
Early in my career, I spent an extraordinary amount of time as a co-op in a factory running around backing up logs and various other items using LapLink. If we ignore the manual labor part of it, it was a fairly decent system for weekly cold backups (our warm back-up solution was network based).
LapLink was a great idea and solved a very real problem: You could not copy large files (anything larger than 1.44MB) around without this, tape, or modem (and when it worked you felt it was finally time to build that Ethernet network).
I remember using pkzip's spanning feature to transport MP3 files home from school with a few floppies. I certainly would have preferred using something more like laplink in that case.
There was a very weird period of time there where floppy drives stopped advancing in capacity but the average file size had continued to outgrown them for years. I remember the iomega zip disks, despite their faults, actually showing up in a lot computer labs before flash drives finally buried them.
I tried to make a high-speed bus between a pair of computers using the parallel port once. But I couldn't get any appreciable bandwidth out of it. Turns out the hardware I was using (CTOS/BTOS workstation) had a capacitor on a critical line. To reduce noise the hardware guy said. But it severely limited the maximum transfer rate. On the widest connector available at the time! Printers don't need to go that fast, he said.
Anyway it still seems like a lost opportunity, years later.
Laplink had a really neat feature for when you didn't have your laplink install disk with you (or had the wrong size laplink install disk).
You could connect the two computers with a RS232 null modem cable, then type something like the following on the target computer:
mode COM1:2400,n,8,1,p
ctty COM1
This redirected the input/output for the terminal to the serial port.
Laplink on the source computer would then 'type' a series of console commands to create a simple transfer program on the target computer. It would use this simple transfer program to transfer the full laplink.
IIRC it used the msdos DEBUG.COM to build the transfer program on the target computer (but this is an old memory, so could easily be a reconstruction).
Composing this message is bringing back lots of weird memories about how we used to compute before the internet.
It’s pretty common to need this kind of bootstrap in the embedded world, and a similar technique is known there as the “three-instruction Forth”[1]. There is no actual Forth on the target, just a serial monitor with peek, poke, and jump, small enough that you can hand-assemble it in a pinch, but given a good dynamic interactive environment on the host you can build yourself a pretty comfy exploratory setup on top of that in a matter of days (hours, I imagine, for an embedded programmer who actually knows what they’re doing).
A few years ago I revived my xt clone. It was pretty much in the original state from the 80s, but since I got a nice isa 10mbit nic, I thought i should get this sucker online.
But how to get the drivers on there? Copy via netw- oh wait. 5.25" floppy? Doesn't seem my laptop has a matching drive for that. I had a core2duo running as my home server which actually had a serial port, so win? Not so much, I had no success getting Linux to talk to the xt clone in any way. No idea if the port was bad, or the controller, or linux, or minicom/screen. So I dug out a Pentium 200 from the basement which had nt40 on it and visual basic 6. So I googled how to set up the serial port with it, wrote a simple sending tool, then googled some more to figure out how to write the receiving counterpart in gwbasic. At first the received file got corrupted since I didn't immediately grasp the whole flow control crap and just ignored it. But that lead to dropped data when the receive buffer filled up while the xt clone flushed the data to its massive 20mb drive. So I lowered the baud rate further and further until the clone could finally keep up. After transferring the driver plus htget sucessfully, I could finally download and upload everything else directly. All in all, that was a fun little exercise for a rainy Saturday, plus a few more weekends trying stuff out on the xt clone, like 8088mph which just hit the webs, and might have been what inspired me to go on this journey in the first place.
Glad you succeeded in getting your clone working. Here's some speculation/information that might have been helpful.
1) The old XT clones used 8250 UARTs which had no internal FIFO buffer and triggered an interrupt each time received data became available (RDA). (That is, assuming your software used interrupt-driven queues vs. polling.) Either way, the maximum usable baud rate was determined by the inter-character timing vs. the system latency + ISR/polling timing. Assuming the 8250 is socket-ed, replacing it with a 16550 series UART would greatly improve your ability to operate at higher baud rates.
2) You mentioned flow control, but there are many variants of that in both hardware and software (such as ENQ/ACK, XON/XOFF, RTS/CTS). A common problem when dealing with serial ports is that hardware handshaking is enabled by default so the OS will not send/receive data without asserting CD/RTS/CTS/DTR/DSR to the proper levels. So you can either use a cable that correctly connects the hardware handshake signals at each end (assuming the OS on each end properly uses them), or disable hardware handshaking (via software).
For the Apple II, there's Apple Disk Transfer ProDOS[1] to transfer disk images from a Java program on a modern computer to a disk on the Apple; there's a similar bootstrapping process which is fun to watch. There's a video tutorial which shows the sequence: https://youtu.be/1xworYThmMI?t=157
I did something like that a few years back when I wanted to transfer a bunch of old floppies from my Apple ][ to a PC emulator. Eventually I worked my way to a IIGS with appletalk connected to a 68K mac with both appletalk and ethernet which FTP'ed things to my PC.
These days a far easier way to do this is to pick up one of the apple floppy->SD emulators. Replace one of the actual floppy drives with the emulator hardware and use Copy II+/etc to copy the floppy images to SD, which can then be plugged into your PC with them all stored as nice little disk images.
120 comments
[ 2.4 ms ] story [ 317 ms ] threadIn my house I have a nice WiFi set up and performance from the Apple TV was awful. I discovered that someone had put in some Cat 5 in the walls and managed to test it, splice a few cables and get Ethernet working. End of trouble.
https://www.doomworld.com/files/file/836-parallel-link-drive...
And likely they chose to avoid parallel because early ports were not intended for communication but rather a primitive extension of the CPU bus to an external device, originally printers. It allowed you to send bytes to a device and then read back a few GPIO like signals the device would set to indicate things like acknowledged, error, paper jam and so on. It was only later on they added functionality and smarts in the form of ECP/EPP with two way data transfers, buffers, IRQ and DMA. On top of all that, a parallel bus over cable is severely limited to something like 4-5 meters or 15 feet. Serial from the get-go was designed for device-device coms and with the right cable, RS232 can extend up to 100m. Of course you can change the electrical interface of serial to a differential, current or fiber interface and extend serial to reach many km.
I didn't realize ECP supported DMA.. when compared to a (16550 UART) serial port, that sounds like an ever bigger win than the 8 (vs 1) data wires!
https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handb...
(Back in the days of thin ethernet)
When I was a kid my dad helped me hook up a pin to a motor. And not just any motor, but one inside a cassette tape player. I could then make little games in BASIC that had real voice! Of course it had to be linear, it basically played chunks of voice recording and stopped at the right times.
The Covox speech thing was a nice hack as well
https://en.wikipedia.org/wiki/Covox_Speech_Thing
Amazing software for that time.
https://www.raphnet.net/electronique/snes_adaptor/images/sne...
A friend and I wrote a chat program that used the calculator-to-calculator GraphLink cable to send messages back and forth so we could chat in class. This was a neat hack, but considering the cable that came with the 85 was like 2 feet long, it was kinda useless in practice unless we were sitting at the same table. So I made a longer cable at home out of stuff from RadioShack.
Everything was cool until we got caught using the homebrew cable in class. Fortunately, once we showed the principal what we'd done, we were told that it was very clever, but not to have the cable in class anymore. :)
You know, I think I might still have my TI-85 and homebrew cables in a box somewhere. I wonder if any of my old programs are still there.
And got it back with rpi with true gpio pins
Another comment mentioned a bunch of other models, but I had some fun with the Espressif ESP32 platform where the bulk chips are like $4 each (depending on quantity) but there are some nice beginner-friendly devkits using the same chips for $15 like https://docs.m5stack.com/en/core/atom_matrix or https://shop.m5stack.com/collections/m5-controllers/products... that are sufficient for a bunch of tasks.
Or if you need something more advanced than basic LED blinking/etc, just pick up a wemos D1, or any of the dozens of other similar microcontrollers that can be had for a dollar or two that have GPIO and a USB serial interface and do your bitbanging on the ESP8266/etc in an environment that isn't susceptible to a heavyweight OS failing to schedule your task for long periods of time. One can hang that device off a PC and talk to it with simple serial programming/commands or just plug it into the target device as a wifi adapter and do all the control over Wifi+JSON/etc. Which it turns out are basically what most of the USB->GPIO adapters are anyway.
So, in the end, using a RPi for this is really sub optimal on every front, cost, performance/accuracy, complexity, power utilization, etc.
https://hackaday.com/2014/09/29/the-lpt-dac/
It made me sad when computers starting shipping without a parallel port: I mean... Even laptop had these back in the days!
http://zoobab.com/simple-jtag
Having that many IO, ready to go, was really great. I bought a separate ISA expansion card so I wouldn't burn out my motherboard's port. Now, you can get a little USB powered micro python board for the same price!
He also had written some kind of memory-resident program (a TSR in DOS terms) that he could trigger while another program was running, and it would render pages of memory to the screen in real time. So he could start any program that had music, browse around through its memory space until he found a byte that seemed to be updating in time to the music, and then select that as the byte whose value got periodically copied to the parallel port.
So you could load up your favorite video game and then have a light show in sync with its music. Or any other activity of interest.
Written from a mobile phone with 5G. Tell me about exponential growth.
And they're still in business: https://web.laplink.com/
In the summer after that year, the school networked all of the on campus housing via ethernet, so connecting things the following year was much easier.
https://tldp.org/LDP/Mobile-Guide/html/mobile-guide-p1c3s4-i...
Worked great in the days when networking equipment was still expensive
Back in the 90s I used the parallel port to interface a PC to a TRS-80 to allow me to store games on the PC. As another commenter has mentioned, the parallel cable isn't fully bidirectional so I used the printer ready, paper out and other signals as imput lines and wrote a nybble (half a byte) based protocol between the two. Fun times.
I still have the yellow parallel cable and blue serial cables at my parents' house.
Also pretty sure I used the blue cable to do Command & Conquer over null modem to the next room at home before I figured out how to install IPX/SPX and get the machines to talk over the 10Base2 that was between them.
I still have both cables and they reside in my miscellaneous computer cables box (as opposed to the box of regularly used cables). I still consider LapLink (the software I also have) as a viable maintenance tool for when I have to occasionally maintain old DOS or Win 3.1 machines (surprisingly there are still some about including several that I own).
Recently, I came close to chucking them out but stopped short of doing that after I had to find some old files still stored on floppies and for doing that the quickest method was to use the DOS machine. (Logic dictated that if I still used a machine then it made sense to keep its maintenance tools.)
One time, I got the command line parameters wrong, and accidentally ran the copy in the opposite direction, overwriting a senior manager's disk drive with a blank disk image. It was the first "big mistake" of my IT career.
https://github.com/dmeybohm/ppcopy
I used it to fix a Windows 98 laptop that wasn't booting all the way to Windows. The would boot to a DOS prompt only, there was no CD-ROM driver, and I only had a Windows 98 install CD. So, there was no to re-install Windows to fix it.
So I wrote the assembly copier for the parallel port. I think it was about 200-500 bytes. Then I used dos DEBUG.EXE to write the hexadecimal code for the program into memory and then write the .COM program to disk. Surprisingly, I didn't make any mistakes (or any that mattered...) and it worked the first time. I had also done a checksum in the copy program in case I screwed it up. But it took about an hour to write the program into DOS debug.exe.
Anyway, was there a chance you posted that story to Reddit or somewhere else previously? I'm sure I've read it before.
It seems unlikely to me though that that would work on DOS without special software because it's such a pauper's OS. To implement the read-side, the DOS kernel or COPY program would have to have a way to pretend to be a printer and then clock the data in according to some protocol. And given DOS is so resource constrained, seems unlikely Microsoft would add code in those fundamental pieces for such a use case, unless it were as simple as switching a few instructions.
There is also the INTERLNK and INTERSVR programs that are built-in to either MS-DOS 6 or 6.22 that could help with that use case.
Yeah, I've probably posted about it before - maybe even here.
There were experimental work on "8-bit PLIP", but the hardware wasn't very standard and in my testing it wasn't actually faster in practice. There was also some kind of DMA standard for the parallel port, but I don't think anyone succeeded in exploiting it for PLIP.
The who PLIP experience gave me a new appreciation for IBM's hardware accelerated "channels" concept - something we never got with x86 given its origin.
Didn't it have a serial port?
Turns out, synchronizing arriving signals is hard.
Its a bit more complex than that. The PC serial port's top speed from the PC->printer/etc was significantly faster than serial at the time. Its only in the reverse direction that there were problems (note comment above about using the control lines for device->PC). And that is by design, the ISA/PCI/RAM/etc buses were parallel, and despite many of them becoming "serial" are still technically parallel (ex: PCIe) because its far easier to gang a bunch of serial data lines together and deal with said synchronization (which is frequently fixed by the hw design/trace length/etc) than attempt ever higher serial frequencies.
And that is fundamentally the problem with trying to use serial as a high speed peripheral interconnect (see HDMI vs displayport for an nice example of hitting walls). Eventually one runs out of bandwidth and the solution ends up being ganging a pile of them together into a... parallel bus. Its why thunderbolt will perpetually be a loser when it comes to GPU attach/etc. A serdes at N Ghz+PAM can just be put on a motherboard x16, and each line is synchronized at a higher level instead of each bit. Ex: PCIe 6. Same with RAM buses, the latency and bandwidth advantages have basically kept them parallel buses (using per line serdes kinds of tech), despite various serial memory standards.
Another example is ethernet where QSFP's are just x4 serial lines.. aka in parallel. SAS x4, etc.
So, these days like RISC/CISC its hard to be 100% correct calling some of these technologies pure serial or parallel.
With a parallel port line, if you trim any line, the entire port is dead. What we now do is multiple serial lines sending data in parallel, but still in a serial fashion (IE, encoding data rate and clock information per line). If you cut a serial line, data still flows. (even with something like PCI-Express).
The key distinction is a parallel bus has effectively a single clock for the arrival of data whereas serial lines are allowed to have data flow at different rates per line.
Serial lines require more hardware at either end to work effectively but ultimately don't have the timing and cable length issues that plague parallel bus transmissions.
Though, I admit this is probably the same as quibbling over using threads vs forking for concurrency.
Oh, and BTW, you can cut data lines on any number of "parallel" buses like DDR and they can frequently continue to work because there are extra ECC/parity lines which can recover the original data, or they are packetized and can recover/detect errors. Particularly on die/board level clocked interconnect buses which don't have as much complexity as the longer distance, outside the chassis interconnects.
OTOH, a single serial line is done if it gets cut. You can only fix that by... ganging them in parallel.
(edit: I keep tweaking this, but clock recovery isn't a hallmark of serial lines either, as there are plenty of things traditionally considered serial that have separate clock lines and have the same problems that happen on what one might consider a traditional parallel bus when run at high enough frequency)
In the most basic fallback mode, the "uplink" from device to host is actually working 4 bits at a time over the "control" lines. All polled with no interrupts. The driver spends most of its time in a busy loop.
The parallel port eventually did eventually get quite fancy in the 90s, with buffered, interrupt-driven bidirectional communication possible in ECP mode (~2 MB/s). But USB was already on the rise by then and it was basically obsolete by the time drivers and motherboards widely supported it.
I also used something looking exactly like this http://www.cablesonline.com/rsdbbreakbox.html with gender changers.
Imagine the red/green blinkenlights!
But that was mostly just for fun, I already had Ethernet.
If you prefer a Windows GUI to this, Total Commander has full support for Laplink (still) built in:
https://www.ghisler.com/efaqport.htm
link - https://ieeexplore.ieee.org/document/4115699
http://aggregate.org/AFN/ has more, including hardware designs.
[1] http://aggregate.org/TechPub/spdp96a.pdf
Those were the days.
There was a very weird period of time there where floppy drives stopped advancing in capacity but the average file size had continued to outgrown them for years. I remember the iomega zip disks, despite their faults, actually showing up in a lot computer labs before flash drives finally buried them.
Anyway it still seems like a lost opportunity, years later.
You could connect the two computers with a RS232 null modem cable, then type something like the following on the target computer:
mode COM1:2400,n,8,1,p
ctty COM1
This redirected the input/output for the terminal to the serial port.
Laplink on the source computer would then 'type' a series of console commands to create a simple transfer program on the target computer. It would use this simple transfer program to transfer the full laplink.
IIRC it used the msdos DEBUG.COM to build the transfer program on the target computer (but this is an old memory, so could easily be a reconstruction).
Composing this message is bringing back lots of weird memories about how we used to compute before the internet.
[1] https://pygmy.utoh.org/3ins4th.html
But how to get the drivers on there? Copy via netw- oh wait. 5.25" floppy? Doesn't seem my laptop has a matching drive for that. I had a core2duo running as my home server which actually had a serial port, so win? Not so much, I had no success getting Linux to talk to the xt clone in any way. No idea if the port was bad, or the controller, or linux, or minicom/screen. So I dug out a Pentium 200 from the basement which had nt40 on it and visual basic 6. So I googled how to set up the serial port with it, wrote a simple sending tool, then googled some more to figure out how to write the receiving counterpart in gwbasic. At first the received file got corrupted since I didn't immediately grasp the whole flow control crap and just ignored it. But that lead to dropped data when the receive buffer filled up while the xt clone flushed the data to its massive 20mb drive. So I lowered the baud rate further and further until the clone could finally keep up. After transferring the driver plus htget sucessfully, I could finally download and upload everything else directly. All in all, that was a fun little exercise for a rainy Saturday, plus a few more weekends trying stuff out on the xt clone, like 8088mph which just hit the webs, and might have been what inspired me to go on this journey in the first place.
1) The old XT clones used 8250 UARTs which had no internal FIFO buffer and triggered an interrupt each time received data became available (RDA). (That is, assuming your software used interrupt-driven queues vs. polling.) Either way, the maximum usable baud rate was determined by the inter-character timing vs. the system latency + ISR/polling timing. Assuming the 8250 is socket-ed, replacing it with a 16550 series UART would greatly improve your ability to operate at higher baud rates.
2) You mentioned flow control, but there are many variants of that in both hardware and software (such as ENQ/ACK, XON/XOFF, RTS/CTS). A common problem when dealing with serial ports is that hardware handshaking is enabled by default so the OS will not send/receive data without asserting CD/RTS/CTS/DTR/DSR to the proper levels. So you can either use a cable that correctly connects the hardware handshake signals at each end (assuming the OS on each end properly uses them), or disable hardware handshaking (via software).
[1] https://www.adtpro.com/
These days a far easier way to do this is to pick up one of the apple floppy->SD emulators. Replace one of the actual floppy drives with the emulator hardware and use Copy II+/etc to copy the floppy images to SD, which can then be plugged into your PC with them all stored as nice little disk images.