[HN Gopher] XMODEM in 2022
___________________________________________________________________
XMODEM in 2022
Author : bcantrill
Score : 92 points
Date : 2022-05-31 15:49 UTC (7 hours ago)
(HTM) web link (www.mattkeeter.com)
(TXT) w3m dump (www.mattkeeter.com)
| jstapels wrote:
| Fun blog, but I was left hanging as the author never found the
| issue with the OS level driver (and instead <spoiler>used a
| workaround library</spoiler>).
|
| It's easy to just blame the FTDI driver, but FTDI is used all
| over the place in the arduino community on MacOS, so I would have
| have assumed it was working.
| saulrh wrote:
| I'd trust the FTDI windows drivers, because almost all
| industrial use of embedded is on windows, factories and
| electrical engineering and the like. I'd _mostly_ trust the
| Linux drivers, because the open-source community uses them. I
| wouldn 't trust the Mac drivers at all.
| abotsis wrote:
| I did this inside idos on an iPad before Apple approved (then
| later revoked) the ability to drop binaries in the emulator. iDos
| (dosbox) shipped with a compiler and ability to map a serial port
| to a tcp socket. So I implemented an XMODEM receiver so I could
| load my retro warez inside the walled garden :)
|
| I spent more time writing the XMODEM receiver than I spent using
| software I sent over it. It's never the destination, always the
| journey.
| theturtle32 wrote:
| Having been a heavy Linux user continuously since about 1999,
| including a few years as a Linux (and OpenBSD) sysadmin for an
| ISP back in the day, the biggest unanswered question in my mind
| at the moment is: why on earth are we using XModem over a serial
| link to send the initrd to boot a Linux server in 2022?
| stdcall83 wrote:
| I implemeted xmodem over uart as a recovery boot for several SOCs
| in my career. It's a simple protocol you can actually fit into a
| small boot ROM and test using RTL. We use it only to load the
| rest of the bootloader which is few hundreds of kb. Then we
| switch to networking using rj45 for the rest of the
| bootstrapping. When using xmodem 1k with higher bps you can get
| to a decent speed.
| cpeterso wrote:
| Back in the BBS days, I used to "collect" BBS file transfer
| protocols. I shared the source code for some of them on GitHub:
|
| * JMODEM: https://github.com/cpeterso/jmodem
|
| * SEAlink (System Enhancement Associates):
| https://github.com/cpeterso/sealink
|
| * WXMODEM (Windows XMODEM): https://github.com/cpeterso/wxmodem
|
| * ZMax: https://github.com/cpeterso/zmax
|
| I also remember "Leech Modem", a file transfer protocol that was
| compatible with XMODEM and YMODEM but designed to bypass a BBS's
| download quotas. The protocol would NAK the last packet and then
| abort the file transfer. The user had successfully downloaded the
| file, but the BBS would mistakenly not count the aborted file
| transfer against the user's download quota.
|
| https://en.wikipedia.org/wiki/LeechModem
| reaperducer wrote:
| Don't forget Punter:
| https://en.wikipedia.org/wiki/Punter_(protocol)
|
| I still think in terms of "SYN/ACK SYN/ACK" pairs when
| analyzing technology.
| _JamesA_ wrote:
| GOO
|
| As a teenager I wrote a few implementations of X/Ymodem and
| Punter for the C64 in machine code back in the day. I was too
| poor at that age to afford an assembler.
|
| I also wrote a native X/Ymodem utility for the IBM AS/400. I
| had to write the CRC calculations in MI (AS/400 machine
| interface language) in order to get enough performance to
| make it work well.
| ape4 wrote:
| I remember zmodem was slightly better
| https://en.wikipedia.org/wiki/ZMODEM
| EvanAnderson wrote:
| Xmodem is the right thing for an embedded target for bringup,
| but zmodem was tons better for BBS'ing. It performed much
| better than xmodem. Auto-start in zmodem is wonderful. Multi-
| file transfers are easy and it even sends the filenames. (My
| old libraries of BBS downloads, pre-zmodem, are a mess of
| crappy filenames.)
| KerrAvon wrote:
| There has got to be something better than Xmodem for use over
| a reliable connection. It's not going to be particularly
| fast.
| EvanAnderson wrote:
| I guess it depends how "embedded" the target is, I guess.
| I'd rather write an xmodem implementation in assembler than
| I would zmodem. I'm envisioning that you're using xmodem to
| transfer "brain-stem" type firmware where you're talking to
| a very constrained system. (I know I've sent firmware to
| Ethernet switch bootloaders via xmodem over serial.
| Presumably I was very, very close to the metal in that
| case.)
| amluto wrote:
| cat works great over a reliable connection as long as you
| can get it to start and end in the right places. When the
| connection is reliable, the only thing that needs doing is
| delimiting the transfer and possibly sending metadata.
| KerrAvon wrote:
| ZModem was much better once it was available. You'd generally
| only use Xmodem after that point if you had no other choice,
| because it failed frequently over unreliable connections, and
| all phone line connections were essentially unreliable due to
| line noise (and sometimes other in-band interruptions). IIRC,
| ZModem was both faster and resumable, so that if your
| connection terminated in the middle of your two megabyte
| transfer you didn't have to redownload the first megabyte.
| [deleted]
| bluedino wrote:
| I remember all kinds of other protocols coming and going.
| Ymodem-g! Blazing fast. I never had issues with it but
| friends with worse modems/phone lines were always restarting
| their transfers.
| ericbarrett wrote:
| If I recall, Ymodem-G (as opposed to Ymodem) was basically
| an unchecksummed raw file dump with a little metadata
| header, so it was only usable on a connection without line
| noise. You could actually get undetected file corruption.
| Mountain_Skies wrote:
| Some SysOps would collect and support as many protocols as
| they could as sort of a form of bragging rights. Even with
| dozens, almost everyone used zmodem, or once in a while,
| BiModem if they wanted to chat during a transfer.
| a-dub wrote:
| you can't just go all the way from xmodem to zmodem without
| stopping at ymodem, ymodem 1k and ymodem 1k with batch support
| first.
|
| also, kermit.
|
| who remembers rip graphics?
| fullstop wrote:
| Don't forget HS/Link! [1] It was kind of cool being able to
| chat while the transfer was happening.
|
| 1. https://en.wikipedia.org/wiki/HS/Link
| altairprime wrote:
| HS/Link was invaluable for QWK swapping, especially
| combined with a {COMMO} auto dialer. I still miss QWK,
| which was essentially a two-way hybrid of RSS and RFC822.
| tssva wrote:
| I see Telix, Qmodem and Procomm mentioned frequently when
| people reminisce about their modem days but rarely
| {COMMO} which is a shame. It was a fantastic piece of
| software which deserves more recognition.
| thedougd wrote:
| I believe I do! Where it'd paint the progress gif or line by
| line with other formats as it downloaded? You could terminate
| early if it wasn't what you wanted.
| a-dub wrote:
| and full blown point and click guis!
|
| of course it was made irrelevant by the fledgling world
| wide web.
| mmastrac wrote:
| RIP script bombs on BBSes were evil. You could black out
| someone's screen until they exited and dialed back up.
| a-dub wrote:
| come to think of it, i don't think there were any private
| multiline boards in my local toll-free calling area.
|
| it was only packet switched commercial services and shell
| based internet at the libraries/university.
| mmastrac wrote:
| The only multi-line one I remember vividly was running
| MajorBBS. The inter-user chat was especially vulnerable
| to sending RIP commands as it didn't filter them out.
| bwanshoom wrote:
| RIPscrip from Telegrafix, remember it well. Hit the industry
| like a tornado at the tail-end before the web overwhelmed
| everything
| rascul wrote:
| > who remembers rip graphics?
|
| Seeing LORD the first time with RIP graphics made me rethink
| everything I thought I knew about BBS games.
| influx wrote:
| Good memories, beverage on me in the tavern.
| bregma wrote:
| Not rip graphics, but targa and spectrum 512. Almost
| lifelike.
| blibble wrote:
| zmodem is still very useful as you can use it with ssh
|
| use zssh instead of ssh, then sz on the remote end to send
| files (and rz to receive)
| throw0101a wrote:
| > zssh
|
| TIL:
|
| * https://packages.ubuntu.com/search?keywords=zssh
| kazinator wrote:
| I wrote a zmodem-like protocol many years ago called
| "sixpack" that worked through anything; I used it through two
| nested telnet connections going through two terminal servers
| (serial lines). Sixpack's wire format packs data into six
| bits, similarly to base64.
|
| This was in 1996. In a fit of amazing fortuitousness, a
| fellow in Japan, almost exactly at the same time, developed a
| program called Modemu. It is still out there and has not been
| maintained since. What Modemu does is creaete a pseudo-tty
| device in your system that you can use in a program like
| Minicom. This pseudo-TTY device accepts AT commands to "dial"
| remote hosts and connect to them.
|
| So at the time I was able to install my Sixpack commands
| (sps, spr) into Minicom, and then telnet out using Modemu:
| ATD<host-namne>, then transfer files to the remote hosts.
|
| I would install the receive program by uuencoding it, and
| then just doing piece by piece copy and paste into the remote
| session to recover the binary.
| tssva wrote:
| I used it just last week. Thanks to a bad choice regarding
| kernel modules on Canonical's part I had an update to Ubuntu
| 22.04 on a Raspberry Pi leave the RPi inaccessible via
| Ethernet. Luckily I have the serial console on the RPi
| connected to another co-located device for exactly this
| potential situation. I was able to ssh to the other device,
| launch a serial terminal from there to the RPi and transfer
| the deb file needed to fix the problem directly to the RPi
| from my laptop via modem.
| outworlder wrote:
| Is that for some kind of use-case where you can't use SCP?
| fullstop wrote:
| Absolutely. On some boards where ethernet is not an option
| you can still run a serial getty and transfer files to /
| from the device.
| EvanAnderson wrote:
| Absolutely. I used a ton of "sz" when I had a dial-up shell
| account (and didn't yet know about SLiRP). More recently
| I've used sz/rz when I've been connected to a router w/ a
| serial connection and needed to pull down a file from a
| remote host. The router had an SSH client so I just
| connected to a Linux box, downloaded my file, then sz'd it
| to myself over the SSH connection via serial.
| blibble wrote:
| works through as many levels of ssh as you want, and much
| more convenient that having to open another terminal,
| figure out the cwd and run the command
|
| years ago a load of GUI clients used to have a right click
| menu to send/receive files that used zmodem (sadly putty
| wasn't one of them)
| hinkley wrote:
| zmodem dealt with line noise a lot better, but it seems it was
| also faster: XMODEM used 128-bytes payloads
| with a three-byte header and one-byte checksum for a total of
| 132 bytes per packet. In the era of 300 bps modems, a packet
| took about four seconds to send, and typical latencies were on
| the order of 1/10 of a second, so the performance overhead was
| not significant. As speeds increase the problem becomes more
| problematic; at 2400 bps a packet takes about 1/2 to send, so
| about 1/5 of the available bandwidth is wasted waiting for
| ACKs. At 9600 bps a packet requires only 0.13 seconds to send,
| so about 1/2 of the bandwidth is wasted. ZMODEM
| addressed these problems by removing the need for ACKs at all,
| allowing the sender to send data continually as long as the
| receiver detected no errors. Only NAKs had to be sent, if and
| only if there was a problem. Since ZMODEM was often used on
| links with built-in error correction, like X.25, the receiver
| would often not send a single message back to the sender. As a
| result, the system would send the entire file in a continual
| stream, and ZMODEM referred to itself as a "streaming
| protocol".
| icedchai wrote:
| I was a big BBS user (and sysop) from roughly 1988 to 1997 or
| so. zmodem was much, much faster.
| hinkley wrote:
| I was just a user so my memory of why I switched to zmodem
| was a bit suspect. Now that you mention it, there were
| definitely largish binaries that I could only download with
| zmodem.
|
| At some point I found a BBS with big files I wanted that
| only supported ymodem, and after several days of trying and
| hitting the hour timeout, I gave up.
| gruturo wrote:
| Indeed, at higher speeds it would waste an awful lot of time
| waiting for ACKs, and that's why XMODEM ACK Spoofing was a
| feature of higher end (error-correcting, obviously) modems.
|
| They would recognize the protocol, immediately forge ACKs,
| deal with error correction and retries, and swallow the other
| side's ACKs when they eventually came.
|
| Truth to be told, by the time this feature was available,
| many had moved to YMODEM, ZMODEM, BiModem (Bidirectional
| transfers whoohoo!) and HS/Link (Bidirectional as well, and
| even chat with the SysOp while transferring data!).
|
| But those spoofing modems were very valuable for environments
| where the protocol was hardwired and you couldn't update.
| flyinghamster wrote:
| The other thing that ZMODEM brought to the table, provided
| your terminal emulator supported it, was automatic downloads.
| You didn't have to tell the BBS to send FOO.GIF and then turn
| around and tell your computer to receive FOO.GIF, you just
| downloaded it with ZMODEM and the download started
| immediately.
| hinkley wrote:
| I had forgotten about that. Super fun when someone sliced a
| large file into parts and you typed in the wrong thing.
| mercutio2 wrote:
| This. So much this.
| PaulHoule wrote:
| XMODEM is a terrible protocol.
|
| I was needing a reliable protocol to move binary data out of an
| Arduino into my PC and researching XMODEM I found so many things
| wrong with it, particularly no sane way to specify the file
| length and a checksum scheme that is totally inadequate. The
| buffer size also is a bit big for a machine with tiny RAM.
|
| I wound up rolling my own version of
|
| https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
|
| with much smaller packets and a carefully chosen CRC which is
| adequate for the task. Retrospectively I was shocked that we
| accepted XMODEM back in the day.
| hinkley wrote:
| There was a point as a teenager where getting hardware flow
| control working on my modem ranked among my achievements in
| life (high cost, high reward).
|
| When I found out the Arduino had no wires for FC, I practically
| had a histamine reaction. That killed the Arduino for me, which
| was too bad because I had ideas about creating something
| information radiators for developers and ended up with a box of
| parts I never touched again. And Raspberry Pi had the same
| issue, and although having Ethernet made that less of a
| problem, it didn't fix the problem I was trying to solve (how
| do I run a device in an organization that doesn't allow BYOD on
| their networks?)
| theamk wrote:
| The first generation arduinos did not have flow control to
| built-in serial converter, true. But it does not mean
| "Arduino does not support FC" - if you connect a your own
| serial port to a "pro" series device, you can implement flow
| control without any problems.
|
| And all the next generation arduino clones with built-in USB
| stack are just wonderful for serial data! I went over 3Mpbs
| on atmega32u4 device, and it came with USB flow control, so
| speed goes up as USB bandwidth is freed up, and connection
| pauses if data is not consumed, fully automatically.
| PaulHoule wrote:
| The trouble isn't that the Arduino doesn't support hardware
| flow control but that the USB-to-serial adapter built into
| the Arduino doesn't support hardware flow control.
|
| I have another USB-to-serial controller I got to program my
| handheld ham radio that does support that, you can wire that
| to your Arduino and it just works...
|
| But really it is a bad bit of cost cutting because the AVR8
| is capable of very fast and reliable communications and you
| shouldn't need to have to add another dongle to get access to
| it.
| mikewarot wrote:
| >XMODEM is a terrible protocol.
|
| I think a more charitable description would be Minimum Viable
| Product. It was far less complex than KERMIT, and got the job
| done.
|
| As soon as better options became available, we all jumped.
|
| Still, sometimes you've got a spiffy new Toshiba laptop with 3
| 1/2" disk drives, MS-DOS, and nothing else. This in a house
| full of 8" and 5 1/4" floppies. What to do? Use debug and Copy
| con to pull over just enough of Xmodem from another machine, to
| then pull over Qmodem, then Laplink, and it's off to the races
| we go.
|
| I was amazed to watch it happen.
| yarone wrote:
| As a kid in 1994 ish, through trial and error I learned that
| ZMODEM was the far more reliable way to download stuff (from a
| user POV).
| baruch wrote:
| There was also BiModem or something like that for the higher
| speeds too. With restart recovery and larger block sizes.
| ChrisLomont wrote:
| >XMODEM is a terrible protocol....
|
| >I was needing a reliable protocol to move binary data out of
| an Arduino into my PC
|
| Each solution is designed to deal with the types of noise
| present in the signals. XMODEM may be bad for you, excellent
| for the phone lines it was used for. Your method may be
| terrible for phone line noise. XMODEM was designed to be fast
| and low cost to implement for the majority case. Your solution
| looks like it would be neither of those things.
|
| I've made zillions of binary embedded to outside protocols. If
| you really want robustness, implement a nicer forward error
| correction protocol.
|
| In any case having a solid understanding of the noise types you
| see is important to getting best performance. Examples are
| burst noise (likely bad or loose wiring), average noise (bad
| shielding), dropped bits (too low power), etc. Each can be
| combatted by making sure the hardware and connections are
| decent up to some cost point, then fight the rest with error
| detection and correction.
|
| As to getting stuff from an arduino to a PC, I've gotten max
| speed with zero error checking to work on most every occasion,
| no error correction or detection, testing over many gigabytes
| to a terabyte, with straight serial protocols. Why is your case
| so noisy? Is there some physical problem or constraint on the
| path? I found such transfers to be so robust I no longer even
| worry about packets or retries for such hardware.
| PaulHoule wrote:
| It's the junk USB-to-serial converter that ships with the
| Arduino that doesn't support flow control.
| ChrisLomont wrote:
| Ah - you didn't need robustness, you needed flow control?
| PaulHoule wrote:
| Without the flow control the data gets scrambled if you
| go above about 9600 bps.
|
| The system I am working on is meant to extract graphical
| data from a persistence of vision display that's hard to
| test under real conditions because it is supposed to be
| strapped onto a moving vehicle.
|
| If the probability is 1% that a test isn't giving the
| right results because a bit got flipped on the serial
| line that is too much. So I want to _know_ the data is
| clean and not guess about it.
| theamk wrote:
| I think something was wrong with your system somewhere -
| bad usb cable? Overloaded system?
|
| I routinely transfer data on original arduinos at 38400,
| 57600 or faster. The error rate is pretty low, way
| smaller than 1%.
| reaperducer wrote:
| It's all about which cable you get. Or, more
| specifically, the chip inside the cable.
|
| The majority of cheap cables use a super low-cost chip
| that ruins data at higher baud rates.
|
| If you get a quality cable with a known good chip in it,
| then you can transmit at crazy speeds.
|
| My TRS-80 is supposed to max out at 300 baud. But I can
| go to 600 baud with a crap cable, or 57,600 with a good
| cable.
| theamk wrote:
| If we are talking about original arduino uno, as in
| https://www.pololu.com/product/2191, then cable should
| not matter - the converter is on the chip, the cable is
| dumb.
|
| The knock-off often use ch340 chip (which is super
| annoying as it has no serial number of any sort), but
| even that chio can be pretty fast if placed on the well
| designed PCB - I regularly upload 1MB firmware files to
| esp8266 at 230400 using that chip.
| miohtama wrote:
| > excellent for the phone lines it was used for
|
| Unfortunately it was not. Thus, YMODEM and ZMODEM replaced
| it. ZMODEM is more complex, more reliable. YMODEM is same as
| XMODEM, but bigger buffer if I recall correctly.
|
| XMODEM is "simple" implementation, but maybe not "fast" or
| even "low cost" implementation due to time needed to debug
| its issues :(
| IncRnd wrote:
| People well knew of the shortcomings, so they used XMODEM-1K
| (called YMODEM and had a larger block size) or ZMODEM (a
| sliding window and retransmission recovery). ZMODEM was
| definitely the one to use!
|
| Once you've used the latter letters you never fallback. You'd
| never leave z to use y or leave y to use x.
| hinkley wrote:
| There was always that One Guy who supported XMODEM and YMODEM
| but either didn't support ZMODEM or had a buggy
| implementation and couldn't be arsed to fix it.
| kevin_thibedeau wrote:
| Technically XMODEM-1K lacks the YMODEM block 0 header with
| file name, size, and other metadata. I had an employer that
| fastidiously stuck to this and it caused no end of annoyance
| that you had to deal with files quantized to 128 or 1024 byte
| multiples because YMODEM was just too complicated to
| implement 25 years ago. YMODEM is fine if you want something
| simple. Don't ever do XMODEM.
| dharma1 wrote:
| Yep zmodem was the one! Always a pleasant thing to discover
| the BBS you called supported it - way faster and supported
| continuing interrupted downloads when your mum picked up the
| phone in the middle of warez leeching
| deepspace wrote:
| Yes, I am not sure why someone would roll their own protocol
| when ZMODEM was available and solved most of XMODEM's
| problems. I was forced to use XMODEM back in the day (because
| ZMODEM did not exist yet), but as soon as the ZMODEM spec was
| published in 1988, _everyone_ moved to it and XMODEM became
| obsolete almost instantly.
| [deleted]
| hinkley wrote:
| If you're talking about this blog in particular, then my
| read between the lines was that 1) XMODEM is much easier to
| implement from scratch, and 2) the Linux Community
| recommends an XMODEM implementation for certain tasks,
| despite the fact that the implementation comes from a
| package that also supports ZMODEM. Lacking context for why
| that may be, that seems like a pretty dumb position. I am
| curious if anyone can dig up a defense of that rationale.
| huslage wrote:
| I mean there was always
| https://en.wikipedia.org/wiki/Kermit_(protocol)
| kstrauser wrote:
| Could Kermit have worked there? Its claim was that it scaled up
| and down as far as you need, and makes in all the reliability
| stuff.
| PaulHoule wrote:
| Kermit is way more complex than XMODEM and many of its best
| features were just not relevant for my case. For instance
| Kermit could communicate with computers that used strange
| charsets like the EBCDIC used by IBM mainframes and also
| communicate over networks that weren't transparent to binary
| data.
| wvenable wrote:
| For file transfer for my 8bit computer, I also couldn't bring
| myself to implement XMODEM. I ended up making a protocol
| similar to XMODEM because I used the standard ASCII characters
| for framing and escaping but my protocol doesn't have XMODEM's
| weirdness.
| AaronFriel wrote:
| Let me know if you need the source for QMODEM, I know a guy :)
| thedougd wrote:
| Your father? If related and around, please tell them thank you
| for many years of exploration and learning.
| AaronFriel wrote:
| I'll let him know!
| Thoreandan wrote:
| At least a dozen friends I know swore by QModem :^) I was
| always a Telix user but found QModem a solid term program when
| I used it! Cheers!
| kazinator wrote:
| Telix was nice; I did some scripting in the Salt language.
|
| In my first job out of high school, I worked as an IT person
| in law firm that used Procomm Plus (for connecting to some
| databases over dial-up, like the land title registry). I used
| its scripting language to automate logins. I remember Procomm
| Plus being decent.
| bwanshoom wrote:
| What is your dad up to these days? Did he go to Microsoft like
| the rest of Mustang?
| AaronFriel wrote:
| We moved back to Iowa - I was pretty young - and he's doing
| pretty well.
|
| Now his only Mustangs are his cars.
| rwl4 wrote:
| I'll bite! There's a reimplementation called Qodem, but it
| would be great to see the actual QModem source since AFAIK it
| has never been released.
| glonq wrote:
| For heinous reasons that I won't get into, my team recently
| finished implementing YModem-over-BLE for our embedded project.
| pantalaimon wrote:
| Why not CoAP?
| qalmakka wrote:
| Why would anyone think someone would implement YMODEM over
| BLE if they could use anything else? It's one of the
| crappiest things ever.
| thatfunkymunki wrote:
| same team as https://news.ycombinator.com/item?id=31572391 ? or
| is this more common than i imagine
| nickdothutton wrote:
| I'd probably reach for ZMODEM 1st, if only because that's where I
| ended up in the early 90s running a BBS. I recently had to use
| Kermit to get some data through a very, very narrow (we are
| talking a few '000 bytes per second) 7-bit only link. The "kids"
| were in awe.
| mrlonglong wrote:
| I see your XMODEM and I raise you KERMIT.
| floatinglotus wrote:
| Maybe BBSs will make a comeback?
| MontagFTB wrote:
| Please share the address for HNMUD when it launches, thanks.
| nope96 wrote:
| They might be! I see new ones listed from time to time here:
| https://old.reddit.com/r/bbs/
|
| Weird factoid for the day: Country music star Shooter Jennings
| runs one!
| https://old.reddit.com/user/ShooterJennings/submitted/
| zwieback wrote:
| Mentioned in the article: Saleae logic analyzer. I love that
| thing, especially the newer mixed-signal version.
| daneel_w wrote:
| I often used YMODEM-G, which offered nice transfer speed
| improvements. It absolutely needed a clear line since it employed
| no error correction. I rarely ever had issues with the protocol
| when dialing local BBSes, but it was a gamble on long-distance
| calls.
| WalterGR wrote:
| > It absolutely needed a clear line since it employed no error
| correction.
|
| YMODEM-G was fast because it didn't do any error detection of
| its own, so it didn't have the overhead of checksums and such.
| The usage scenario was that the connection would already have
| error detection and recovery by virtue of the modem and the
| connection... protocol? I forget what we called them.
| gruturo wrote:
| >error detection and recovery by virtue of the modem and the
| connection... protocol? I forget what we called them.
|
| Yeah protocols. First ones to see widespread use (at least
| subjectively) were MNP4 and MNP5 for, respectively, Error
| correction (with a 25% speed increase as a bonus, since it
| was synchronous and would not therefore waste code space with
| start and stop bits) and Data Compression (a terrible one
| which would actually incur an overhead if data was already
| compressed).
|
| They got later replaced by v.42 and v.42bis, with the same
| respective purposes (but v.42bis was smarter than MNP5 and
| could switch to transparent mode when sending incompressible
| data).
|
| CARRIER 14400
|
| COMPRESSION: V.42 bis
|
| PROTOCOL: LAPM
|
| CONNECT 57600/ARQ
| qalmakka wrote:
| Yeah, XMODEM... I had to implement YMODEM for a client of the
| company I work with a few months ago... Over BLE. It is every bit
| as bad as it sounds like.
| thatfunkymunki wrote:
| https://news.ycombinator.com/item?id=31571831 same team? story
| time?
| qalmakka wrote:
| It is more common that you imagine. In my case, the story is
| that some people have literally been porting the same C code
| base on multiple computers first, and embedded devices later,
| since the late '80s. Given their lead engineer is literally
| 80 years old now, the client once again slap YMODEM on their
| latest device, which uses BLE to literally emulate a good old
| serial port and pass data on it using YMODEM. It sucks, hard.
| They were quite puzzled about why it ran so badly, and I
| didn't have the heart to tell them it was because the whole
| thing was incredibly idiotic.
| [deleted]
| throw0101a wrote:
| Once HS/Link came out, I never looked back to x/y/zmodem if the
| BBS had it on their end:
|
| * https://en.wikipedia.org/wiki/HS/Link
|
| Bidirectional transfers were so handy and a time saver if you
| were transferring mail files (QWK, SOUP, BlueWave) and your
| replies. If anyone has some of those old files available, readers
| are still available:
|
| * https://wmcbrine.com/MultiMail/
| gfodor wrote:
| HS/Link was also the only protocol I remember that also
| included a chat between sender and receiver during the
| download. For the first time you could actually continue your
| conversation while sending files to one another, instead of
| having to go dark like you were flying around the moon or
| something.
| michaelcampbell wrote:
| I once entered a chat on CompuServe with Ward Christensen, the
| author of Xmodem. Was ~1984/1985. Had a nice chat (at $6/hour)
| with him, and he was pretty surprised I (nay, anyone) recognized
| his name and what he had done.
|
| Nice guy as I recall.
| ceautery wrote:
| That's awesome!
|
| Ironically, Xmodem wouldn't have worked well over CIS's
| network, since to talk to the X25 nodes you had to have
| software flow control enabled in your modem connection. Small
| transfers might work, but when you hit the Xmodem block number
| that coincides with ^Q, that block would repeatedly NAK until
| the transfer failed.
| ok123456 wrote:
| You could download things from Compuserv's file forums with
| Xmodem.
|
| They probably had some kind of escaping to overcome that???
| icedchai wrote:
| You could. I remember doing it (on my Apple IIc, right
| around 1988-89!)
| mmastrac wrote:
| Most of the time it's easier to unload the driver just to write
| bytes to the USB endpoints. These devices are basically the
| easiest possible thing you can talk to over USB.
| the_only_law wrote:
| Believe I used it last year to transfer files between a Agilent
| J2300E running Win95 or Win98 and a modern PC. Slow, but
| convenient given it was already implemented in the terminal
| emulators used on both end.
| jeffbee wrote:
| Surprised at the statement that very few new computers have
| serial ports. I guess true for macs, but most PC motherboards
| still come with a superIO-type thing that offers 1 or 2 16650A
| UARTs. [ 0.362434] 00:01: ttyS0 at I/O 0x3f8
| (irq = 4, base_baud = 115200) is a 16550A
| deckard1 wrote:
| they are talking about a D-Sub 9 connector, which I haven't
| seen on new PCs since the early 2000s. If your motherboard has
| pins they are probably undocumented. And that's likely the best
| case scenario.
| StillBored wrote:
| Nah, on actual x86 PC atx/etc motherboards the ports are
| frequently fully RS-232 compliant, and on all my desktop
| boards for the past few years are even still documented.
|
| Example: I have native, documented DB9/25 on my latest
| machine, an asus prime x570-pro
| https://www.asus.com/us/Motherboards-
| Components/Motherboards... which if you download the manual
| and search for "COM" you will see that it uses the semi
| standardized 10 pin motherboard header into which a card edge
| DB9/DB25 can be plugged into.
|
| They are overwhelmingly used by hw/firmware/bringup
| engineers, so, while your right they are frequently
| undocumented or unpopulated, like JTAG ports its more unusual
| not to find them. And, yah on a lot of machines they are just
| whatever logic level the chip supports for IO 1.8V/etc so its
| common to just wire the headers to FTDI/etc usb converters
| rather than level shifters.
| tyingq wrote:
| They may, but that would be TTL-level and would need a level
| shifter and a 9-pin connector to do actual RS-232, plus trying
| to find the pins, maybe enabling the UARTS in the BIOS, etc.
| Making using a USB-to-serial adapter less work.
| zauguin wrote:
| Looking at my last two (non notebook) motherboards (neither of
| them being particularly new) one of them has a pin header where
| a serial port could be attached, the other only has some
| contacts on the board without even pins. Neither of them had a
| proper port.
|
| So even if they could offer these ports and Linux reports them,
| they might not be usable without special work.
| jeffbee wrote:
| Ugh, not even populating the header is a terrible way to save
| one penny. This one I'm using came with the rear panel
| bracket and everything.
| jabl wrote:
| Server platforms tend to have the serial wired to the BMC and
| going out over the IPMI serial-over-lan on ethernet.
|
| But from the host OS it looks like a regular 16550A.
| lol_catz wrote:
| I prefer MobyTurbo for my file transfers
___________________________________________________________________
(page generated 2022-05-31 23:00 UTC)