File transfers via the parallel port on DOS using LapLink
cambus.net
cambus.net
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.
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).
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.
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
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.
It made me sad when computers starting shipping without a parallel port: I mean... Even laptop had these back in the days!
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.
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.
http://aggregate.org/AFN/ has more, including hardware designs.
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.
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.
copy LPT1 output.bin
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.
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://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!
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.
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.
Year was 1997 I think.
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.)
And they're still in business: https://web.laplink.com/
If you prefer a Windows GUI to this, Total Commander has full support for Laplink (still) built in:
https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handb...
(Back in the days of thin ethernet)
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.
Written from a mobile phone with 5G. Tell me about exponential growth.
Anyway it still seems like a lost opportunity, years later.
Keep in mind that other data transfer options were generally disks of some sort that held less than 1.5MB of data and were very slow to write/read. It wasn't too important at the beginning as most systems with hard drives were generally only a few MB anyways.
But storage moves fast and software bloats quick and it wasn't too long before we were shuffling a couple dozen disks worth of stuff onto new system builds or worse, between systems as people migrated. Optical wasn't really an option for lots of reasons, most notably very expensive and at the time generally SCSI and tended to be exotic WORM drives. Almost nobody in the consume market had SCSI in the IBM-PC compatibles, and the disks were $30-40 each if you managed to write one successfully.
LapLink filled the gap for a couple of years instead. Connect the cable, boot to a couple of prepared floppies and start transferring. Really quite reliable even if it was slow.
Eventually it became so slow, and we realized "hey we work in a shop where we can take the hardware apart anyways" and just started mounting the harddrives with the data to transfer from into the system with the new volume and using xcopy or eventually a clone tool.
I think even that finally fell out of favor once rewritable IDE CDs became common, plus zip/jazz etc. drives, and eventually windows started shipping with a network stack, but I was long out of that business by then.
https://tldp.org/LDP/Mobile-Guide/html/mobile-guide-p1c3s4-i...
Worked great in the days when networking equipment was still expensive
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.
For my final year project in university I made a signal generator that was controlled via the parallel port. Would create the desired waveform in a GUI DOS program, then download via the parallel port. Would also start/stop the signal generator via computer.
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.
Those were the days.