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.
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.
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
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.
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.
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.
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!
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.
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
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.
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.
> 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.
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.
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...
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.
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]
Parallel port was great. It's super annoying that USB-to-Parallel adapters cut corners and only transmit the bare minimum signals to print to an inkjet printer. There was a rich ecosystem of parallel port devices out there, including MIDI and SCSI adapters, even ethernet ports. But none of them work through USB adapters.
> It's super annoying that USB-to-Parallel adapters cut corners and only transmit the bare minimum signals to print to an inkjet printer.
That's because they weren't USB-to-Parallel adapters, they were USB printer adapters. A parallel port was effectively a GPIO port to which most people happened to attach a printer.
There is no standard USB device class for arbitrary GPIO devices. The USB printer class is defined to make sense for native USB printers, so USB printer adapters present the same to the host and then convert this to a parallel format. This is a lot more efficient than having a device that actually implements arbitrary GPIO and then bitbanging those lines to speak to the printer.
You might similarly note that a USB gameport adapter won't work with some higher end devices that "hacked" the port to offer force feedback and/or more than the expected amount of buttons, because the USB HID game controller class is designed to efficiently handle native devices rather than to support all possible weird ways one could use a port in the days of raw hardware access.
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.
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.
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.
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.
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.
I migrated data off a dying PC once onto a new one in a pinch by using two paperclips to cross the TX/RX pins of both computers' serial ports while they were back to back. Then I used PC Anywhere (another fine bit of software) to do the file transfer. Took about 24 hours but moved everything fine.
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 really like the UX/UI of the transfer tool. The dialog meant for literate people that explains in clear terms what the problem is and what can be done about it is a breath of fresh air coming from our world where "the user is stupid" toy-like UIs dominate.
Oh wow, this brought back memories. I remember using LapLink to transfer files from our family desktop to a used Toshiba 286 laptop that my parents found for me over a parallel cable so I could mirror the setup.
I ended up using this tool multiple times over the years, and even well into the Win2k / Win98 days, it was still a more reliable method for transferring files between computers on WinTel systems vs other methods. Sometime in the Win2k days I transitioned to using a crossover Ethernet cable and setting up an FTP server on the origin system.
[+] [-] wmitty|4 years ago|reply
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.
[+] [-] iforgotpassword|4 years ago|reply
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.
[+] [-] toast0|4 years ago|reply
[1] https://www.adtpro.com/
[+] [-] kingcharles|4 years ago|reply
[+] [-] wdrw|4 years ago|reply
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.
[+] [-] adrianmonk|4 years ago|reply
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.
[+] [-] bluedino|4 years ago|reply
The Covox speech thing was a nice hack as well
https://en.wikipedia.org/wiki/Covox_Speech_Thing
[+] [-] alibarber|4 years ago|reply
[+] [-] TacticalCoder|4 years ago|reply
It made me sad when computers starting shipping without a parallel port: I mean... Even laptop had these back in the days!
[+] [-] anonymousiam|4 years ago|reply
http://zoobab.com/simple-jtag
[+] [-] peckrob|4 years ago|reply
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.
[+] [-] zokier|4 years ago|reply
And got it back with rpi with true gpio pins
[+] [-] systems_glitch|4 years ago|reply
[+] [-] kingcharles|4 years ago|reply
https://hackaday.com/2014/09/29/the-lpt-dac/
[+] [-] madaxe_again|4 years ago|reply
[+] [-] rjsw|4 years ago|reply
[+] [-] FullyFunctional|4 years ago|reply
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.
[+] [-] retrac|4 years ago|reply
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.
[+] [-] netsharc|4 years ago|reply
[+] [-] TacticalCoder|4 years ago|reply
[+] [-] gattilorenz|4 years ago|reply
Didn't it have a serial port?
[+] [-] bcrl|4 years ago|reply
[+] [-] sponaugle|4 years ago|reply
link - https://ieeexplore.ieee.org/document/4115699
[+] [-] mcshaner1|4 years ago|reply
http://aggregate.org/AFN/ has more, including hardware designs.
[1] http://aggregate.org/TechPub/spdp96a.pdf
[+] [-] phendrenad2|4 years ago|reply
[+] [-] wolrah|4 years ago|reply
That's because they weren't USB-to-Parallel adapters, they were USB printer adapters. A parallel port was effectively a GPIO port to which most people happened to attach a printer.
There is no standard USB device class for arbitrary GPIO devices. The USB printer class is defined to make sense for native USB printers, so USB printer adapters present the same to the host and then convert this to a parallel format. This is a lot more efficient than having a device that actually implements arbitrary GPIO and then bitbanging those lines to speak to the printer.
You might similarly note that a USB gameport adapter won't work with some higher end devices that "hacked" the port to offer force feedback and/or more than the expected amount of buttons, because the USB HID game controller class is designed to efficiently handle native devices rather than to support all possible weird ways one could use a port in the days of raw hardware access.
[+] [-] dmeybohm|4 years ago|reply
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.
[+] [-] ronsor|4 years ago|reply
Anyway, was there a chance you posted that story to Reddit or somewhere else previously? I'm sure I've read it before.
[+] [-] mwexler|4 years ago|reply
[+] [-] ThinkingGuy|4 years ago|reply
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.
[+] [-] chasd00|4 years ago|reply
[+] [-] unixhero|4 years ago|reply
[+] [-] tokamak-teapot|4 years ago|reply
https://www.doomworld.com/files/file/836-parallel-link-drive...
[+] [-] MisterTea|4 years ago|reply
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.
[+] [-] jgrahamc|4 years ago|reply
[+] [-] jacquesm|4 years ago|reply
[+] [-] anotherevan|4 years ago|reply
[+] [-] Starwatcher2001|4 years ago|reply
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.
[+] [-] api|4 years ago|reply
Year was 1997 I think.
[+] [-] hed|4 years ago|reply
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.
[+] [-] fortran77|4 years ago|reply
And they're still in business: https://web.laplink.com/
[+] [-] andix|4 years ago|reply
[+] [-] scurraorbis|4 years ago|reply
[+] [-] awiesenhofer|4 years ago|reply
If you prefer a Windows GUI to this, Total Commander has full support for Laplink (still) built in:
https://www.ghisler.com/efaqport.htm
[+] [-] bombcar|4 years ago|reply
[+] [-] jacquesm|4 years ago|reply
https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handb...
[+] [-] tristor|4 years ago|reply
I ended up using this tool multiple times over the years, and even well into the Win2k / Win98 days, it was still a more reliable method for transferring files between computers on WinTel systems vs other methods. Sometime in the Win2k days I transitioned to using a crossover Ethernet cable and setting up an FTP server on the origin system.