[HN Gopher] File transfers via the parallel port on DOS using La...
___________________________________________________________________
File transfers via the parallel port on DOS using LapLink
Author : fcambus
Score : 118 points
Date : 2022-04-13 12:12 UTC (10 hours ago)
(HTM) web link (www.cambus.net)
(TXT) w3m dump (www.cambus.net)
| sponaugle wrote:
| 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.
|
| link - https://ieeexplore.ieee.org/document/4115699
| mcshaner1 wrote:
| 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]
|
| http://aggregate.org/AFN/ has more, including hardware designs.
|
| [1] http://aggregate.org/TechPub/spdp96a.pdf
| a9h74j wrote:
| 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.
| raintrees wrote:
| I still have my custom-made 20' cable for laplink over parallel
| ports...
|
| Those were the days.
| Starwatcher2001 wrote:
| 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.
| deelowe wrote:
| 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).
| jacquesm wrote:
| You can even do IP:
|
| https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handb...
| youngtaff wrote:
| One of my first ethernet adapters plugged into the parallel
| port
|
| (Back in the days of thin ethernet)
| jacquesm wrote:
| Oh the joy of insulation displacement taps...
| raffraffraff wrote:
| Jesus, HN has been a nostalgia machine recently. That's another
| thing I didn't realise I had forgotten.
| jon_adler wrote:
| Has MFM vs RLL encoding of hard disks been brought up recently?
| Hopefully I was able to remind you of another thing you thought
| you had forgotten.
| awiesenhofer wrote:
| Oh what a blast from the past - copying files with blazingly fast
| 1MB/s!
|
| 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 wrote:
| 1MB/s is pretty fast all things considered - a gig every 17
| minutes.
| api wrote:
| 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.
|
| Year was 1997 I think.
| 1970-01-01 wrote:
| 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).
| ridgered4 wrote:
| 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.
| tommieb wrote:
| LHZ / ARJ archive anyone? :)
| [deleted]
| bluedino wrote:
| Had some fun one time making a boot floppy to install Linux from
| a parallel port CD-ROM or Zip drive
|
| https://tldp.org/LDP/Mobile-Guide/html/mobile-guide-p1c3s4-i...
|
| Worked great in the days when networking equipment was still
| expensive
| bane wrote:
| oh man, this brings back some memories. In the early-mid 90s I
| worked at a mom-n-pop computer repair store and LapLink at some
| point became sort of a standard tool for all sorts of system
| setup and configuration stuff.
|
| 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.
| hed wrote:
| 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.
| hilbert42 wrote:
| _" 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.)
| jaimex2 wrote:
| Remote install on Laplink was the bomb.
| JoeAltmaier wrote:
| 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.
| andix wrote:
| I always used INTERLNK, which was included with MS-DOS 6.22. I
| think you could even just copy the exe to older DOS versions and
| it would just work.
| micheljansen wrote:
| 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!)
| littlecranky67 wrote:
| I also remember INTERLNK but IIRC it was using a null-modem
| cable on the serial port, not parallel port.
| andix wrote:
| 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.
| wmitty wrote:
| 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.
| iforgotpassword wrote:
| 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.
| anonymousiam wrote:
| 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).
| kingcharles wrote:
| That's actually really impressive.
| mananaysiempre wrote:
| 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).
|
| [1] https://pygmy.utoh.org/3ins4th.html
| toast0 wrote:
| 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
|
| [1] https://www.adtpro.com/
| StillBored wrote:
| 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.
| tristor wrote:
| 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.
| malkia wrote:
| I used this few times, when I was a kid in one of our local PC
| computer clubs. It was magic to me. There were some alternatives,
| and friend of mine was using something "kermit"-based
| (protocol?). That was years before internet really came to my
| city for real.
| jon_adler wrote:
| Kermit, xmodem, ymodem and zmodem were all file transfer
| protocols, often used to transfer files on bulletin board
| systems (BBS).
| fortran77 wrote:
| LaPlink (as we called it) was such a useful utility back before
| wireless and even before ethernet.
|
| And they're still in business: https://web.laplink.com/
| pjmlp wrote:
| Now that is a travel to my teenage years
| wdrw wrote:
| 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.
| rjsw wrote:
| I have used a parallel port to drive a JTAG port on a different
| device to program a boot ROM.
| bluedino wrote:
| Parallel ports were very popular for connecting joysticks to
| MAME cabinets
|
| The Covox speech thing was a nice hack as well
|
| https://en.wikipedia.org/wiki/Covox_Speech_Thing
| kotaKat wrote:
| And homebrew SNES controller adapters! Good ol' "SNES
| controller on lpt1" in zsnes got me many hours of emulation
| fun back in the day.
|
| https://www.raphnet.net/electronique/snes_adaptor/images/sne.
| ..
| bluedino wrote:
| I remember learning about this by some company that made
| DOS shareware clones of PacMan and Galaga but can't
| remember the name. Ring a bell?
| bluedino wrote:
| I found it - ChampSoftware and the ChampCable
| mobilio wrote:
| and ModPlay: https://awe.com/mark/dev/modplay.html
|
| Amazing software for that time.
| adrianmonk wrote:
| 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.
| alibarber wrote:
| 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.
| galangalalgol wrote:
| 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.
| kingcharles wrote:
| The best thing was using it as a DAC. A bunch of resistors and
| off you go! That was one of the greatest things I ever made as
| a kid.
|
| https://hackaday.com/2014/09/29/the-lpt-dac/
| anonymousiam wrote:
| I've used my parallel port as a JTAG (IEEE-1149.1) interface to
| reflash/debug embedded targets. It's slow, but it works.
|
| http://zoobab.com/simple-jtag
| userbinator wrote:
| PIC and AVR microcontrollers can be programmed using a
| parallel port; passive adapters with nothing more than
| resistors used to be common.
| TacticalCoder wrote:
| 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!
| systems_glitch wrote:
| 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
| peckrob wrote:
| 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.
| retzkek wrote:
| 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...
| zokier wrote:
| > We lost this in the age of USB..
|
| And got it back with rpi with true gpio pins
| StillBored wrote:
| 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.
| orangepurple wrote:
| RPI is $70-110 in the United States nowadays. There has got
| to be a cheaper alternative that is widely available like
| some sort of NodeMCU?
| PeterisP wrote:
| 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.
|
| Another comment mentioned some, 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://sho
| p.m5stack.com/collections/m5-controllers/products... that
| are sufficient for a bunch of tasks.
| madaxe_again wrote:
| 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.
| fatnoah wrote:
| 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.
| danrl wrote:
| Nostalgic! I used LapLink a lot back in the days. When Ethernet
| became affordable I was baffled by the speed of data transfer.
| Lightning fast!
|
| Written from a mobile phone with 5G. Tell me about exponential
| growth.
| mmastrac wrote:
| I started out with 10mbps links and those were gloriously fast.
| I even had a 3com card in a 386 that was running linux.
| ThinkingGuy wrote:
| 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.
| chasd00 wrote:
| 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.
| geocrasher wrote:
| 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.
| bombcar wrote:
| They used to have a physical 220/110 voltage switch on them,
| and you could cause fun by playing with it.
| toast0 wrote:
| 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.
| akudlacek wrote:
| Not as convenient for transfering from a modern Windows 10 to MS-
| DOS. I ran into this problem and used Kermit and teraterm.
| Teraterm has ability to transfer over a couple different
| protocols.
| phendrenad2 wrote:
| 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.
| wolrah wrote:
| > 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.
| jgrahamc wrote:
| We've got so used to WiFi, GSM and Bluetooth that people forget
| how robust wired connections are.
| jacquesm wrote:
| Bluetooth is anything but robust.
| jgrahamc wrote:
| 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.
| jacquesm wrote:
| I use cable where I can and wireless only when I absolutely
| have to.
| mmastrac wrote:
| 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.
| bombcar wrote:
| And amusingly enough the more wired you use the better
| the remaining wireless connections are (as they don't
| have to compete).
| systems_glitch wrote:
| This works with Microsoft's INTERLNK/INTERSVR as well. As others
| have mentioned, this was our first form of networking at home!
| Even had a special DB25 punchout wall plate to make the non-
| basement end more presentable.
| unixhero wrote:
| 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.
| MisterTea wrote:
| 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.
| unixhero wrote:
| Thanks for the deep dive! No games, and I didn't say that
| either. Although the post itself was a bit unstructured I can
| see how you thought that.
| MisterTea wrote:
| 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.
| andrewf wrote:
| As a youngster the two household computers were connected
| with parallel _and_ serial lines (for Laplink and games!)
|
| 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!
| tokamak-teapot wrote:
| I used to play multiplayer DOOM over parallel port in 1994.
|
| https://www.doomworld.com/files/file/836-parallel-link-drive...
| mwexler wrote:
| 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.
| anilakar wrote:
| 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.
| dmeybohm wrote:
| I wrote a utility to copy small files from Linux -> DOS over a
| LapLink cable.
|
| 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 wrote:
| Even in DOS, I think copy LPT1 output.bin
|
| would have worked at the time.
|
| Anyway, was there a chance you posted that story to Reddit or
| somewhere else previously? I'm sure I've read it before.
| dmeybohm wrote:
| 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.
| bombcar wrote:
| 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.
| bcrl wrote:
| 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.
| FullyFunctional wrote:
| 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.
| netsharc wrote:
| 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.
| TacticalCoder wrote:
| 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...
| gattilorenz wrote:
| > It was the only way to access the outside world on my Toshiba
| T1800 laptop
|
| Didn't it have a serial port?
| cogman10 wrote:
| What was wild to me is learning that serial communication is
| almost always faster than parallel communication.
|
| Turns out, synchronizing arriving signals is hard.
| StillBored wrote:
| " 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.
| cogman10 wrote:
| 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.
| StillBored wrote:
| 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)
| FullyFunctional wrote:
| Sorry, it's ~30 years ago and my memory was faulty as I
| checked and it did have one. However, I didn't use it so it
| must have been slower than PLIP.
| retrac wrote:
| > 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.
| u801e wrote:
| 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.
___________________________________________________________________
(page generated 2022-04-13 23:01 UTC)