My teenage impression of the Kermit and Zmodem protocols, written in the mid 90s:
here’s my impression of how kermit works
client: here is byte number 1
server: i have received byte number 1. the checksum was 3.
client: i agree that the checksum was 3.
server: ok, we’re done with byte number 1.
client: I agree, we’re done with byte number 1.
client: here’s byte number 2.
server: you know, it’s not easy being green
now zmodem zmodem goes something like this:
client: I’m gonna send you about 200k now, and you’re gonna bend over and take it
server: thank you sir! ( … )
server: ok, got 200k, checksum was 523
client: DID I ASK YOUR FUCKING OPINION?
server: NO SIR! SORRY SIR!
After using Xmodem it was like my modem was upgraded from 14.4 to 28.8. And if someone picked up the house phone during a 3 hour download, I could continue where I left off, assuming the BBS wasn't busy by the time I called back.
That's Kermit in its very basic version, which is slow but has the advantage of working just about everywhere under extreme constraints. If you have an urge to send data from your C-64 or Tandy CoCo to a Burroughs B5500, there is or was probably a version of Kermit for each that would let you do it. Later Kermits had large packets, sliding windows, and ways to specify what characters needed special encoding.
Yeah this was a while ago. ;) My experience was that zmodem was incredibly fast under real-world conditions. It really was like getting a speed boost on your 300 or 1200 baud (or 2400 baud, if you were lucky!) pipe. Anyone remember xmodem or ymodem as well?
EDIT: I didn't realize he'd written ymodem as well! What a brilliant guy.
One of my first contract development jobs came in '96 when a research group in Norway was going to do a demo of their autonomous underwater mapping submersible for some US navy brass. Problem was the tiny tracking boat that was following the submersible on the surface to receive the data (via an accoustic link..) would not hold everyone who was going to be in attendance, so they needed a way to stream the data from the tracking boat to a US navy ship to display it on some Sun workstation there.
For some reason they'd decided the best option was GSM data. 9600bps should be fine - the mapping data feed was about 2400bps. Problem of course was both of these ships would be out in a fjord, far from any cells, and in motion.
So I ended up writing a little proxy that they'd connect to and feed data that'd do automatic redialling and then layered a variant of the zmodem protocol on top of that to handle re-sending of data, and tuned it for specifics of the app to minimize delays in catching up to the live feed.
I'd used zmodem a lot in my BBS days before, but that was the last time.
I think Chuck would be quite pleased with your story!
It's always sad to lose someone so talented - or anyone for that matter. One of the few consolations is that it gives us a chance to tell great stories about them.
BTW for anyone like me who often just reads the comments here, take a few minutes to read Chuck's obituary. It's a wonderful celebration of his life and work.
"Having his own company allowed Chuck to be Chuck. He got up when he felt like it (usually in the afternoon), he worked when he felt like it, and wrote the software he wanted to write. He was a guru in the fullest sense of the word."
I first started my online journey with a 300bps Hayes modem and an original 4.77mhz IBM PC, connecting with a service called The Source in 1981. I soon moved on to Compuserve and then, of course, BBSs.
The first protocol I remember using was not Zmodem, but Xmodem, which as I recall, had a really nasty habit of losing its place in the middle of a 2 hour download, forcing you to start completely over.
Remember, Compuserve costed $5/hr(!), so these disconnect/restarts were not only really annoying but quite expensive.
Zmodem solved this problem very nicely...it was smart enough to restart downloads at the point of disconnect, and because of this, Chuck was a hero of my youth.
RIP. Zmodem was so amazing. It was a huge step forward. I got started in 1980 with an old Hayes 300 baud modem on the Source, and graduated to Compuserve and BBSes in 1986 when I got a 2400bps modem. When I got a 9600bps modem in ~1988, that's when things really took off for me online.
Early BBS culture was really something else--we'd do meetups at the local Godfather's Pizza on Saturday afternoon and knew each other by our handles. We'd trade notes on new BBSes that had cool downloads or interesting message boards, and give each other advice on which companies had the best long distance plans. I remember doing math to calculate how many 3.5" disks worth of data I could download from a given BBS in another area code--IIRC it was something like $5 per disk with a 9600bps modem. I didn't even try downloading full games until I had a fast enough modem because downloading a floppy at 2400bps meant you'd blow out your daily time allocation before the download finished. What an era.
Ahh the good old days. I remember downloading a 4 floppy game overnight, because some BBSes would give you unlimited time after 10pm or something like that.
In the pre-internet-for-everybody days (and even quite a while afterwards) zmodem and other file transfer protocols were pretty much the only way short of mailing floppy discs to get a file from one place to another, and there wasn't a terminal package or a BBS system that did not support it. Even today plenty of terminal programs will happily respond to the download initiation sequence.
Yes, but for very obvious reasons not in this thread. The most abbreviated version of that story would be: I indirectly owe Chuck Forsberg all of my wealth.
I used to "collect" file transfer utilities back in my BBS days. When I found source code on some old floppies, I decided to publish them on GitHub for future generations:
Other utilities for which I have MS-DOS exes but not source code include: BMODEM, BiMODEM, CMODEM, Leech, Lynx, Puma, TMODEM, YMODEM, and others. Leech was compatible with X/Y/ZMODEM but it would fake a transfer abort after the last byte was downloaded so the BBS would not count the file download against your quota. >:)
Back in 2005 we had a really bad issue with ZModem to a barcode terminal over an USB2Serial adaptor and Chuck helped us as a consultant.
I've just dug out the old emails we've exchanged back in the day and I remember how great it felt when after only two days, he solved the problem we've been working on for weeks.
I was so happy to finally see our problem go away.
Not only Zmodem was cool, it was also open source back then, and very easy to integrate into your program.
In fact, little known fact, it's still very useful today; if you ssh into a box that has it installed, and you have it installed locally, you can quickly send yourself back a file with it, across the current connection...
Just to 'sz <file>' on the remote side, and do <return><tilde>|rz<return>
to tell you ssh client to start 'rz' locally and zoom, zmodem the file over.
> n fact, little known fact, it's still very useful today; if you ssh into a box that has it installed, and you have it installed locally, you can quickly send yourself back a file with it, across the current connection...
This has been my use case for having lrzsz everywhere since dog knows how long. Nicely, iTerm2 has pattern-based triggering which lets you fire off zmodem. I keep meaning to sit down and hack on tmux so that transfers will pass through cleanly.
Oh you've just given me a huge dose of nostalgia - I used to do that over telnet back in... 92 or 93 I forget which. I had completely forgotten that sz/rz existed.
Try that thru a double connection? ie, ssh-ing to a machine from an already open ssh session?
I'm amazed I get -1 for that post; scp is clunky as hell when you already have a shell in 'that' directory; and it'll only work if you have /direct/ access to the machine you are logged in, and that's rarely the case if you first connect to a front end machine.
I'm an embedded dev as well, and I use zmodem everyday. I have boards that have no network, just a serial port, and I can upload an executable, download the log from just the debug console.
It's interesting how tcp/ip is pretty much taken for granted. Of course you could run SLIP over that serial port ;)
Just the other day I was bitching about how it is easier to drive a printer than a relay from a present day computer, the answer I got back was 'can't you use an arduino?'...
Hehe you'd be /amazed/ how much smaller the kernel gets it you don't put in IPv4/6 -- and let me tell you, when you upload via uart, every little helps :-)
My fav method is to build a kernel with just busybox using my minifs [0], making sure I have kexec support in that kernel.
Once booted, I can upload a new kernel via zmodem, and kexec straight into the new kernel. Rince, repeat!
You can also use zmodem to upload new binaries to a system, even if it's an initramfs, without having to do a full rebuild/reboot. Quite handy.
> I'm amazed I get -1 for that post; scp is clunky as hell when you already have a shell in 'that' directory; and it'll only work if you have /direct/ access to the machine you are logged in, and that's rarely the case if you first connect to a front end machine.
I did not downvote you, but setting up a port forward (-L) or SOCKS proxy (-D) on the first machine is very easy and extremely flexible. I do it all the time.
You can also do some tricks in ssh_config to route through the first machine (this is non-obvious, I'll grant). I do "ssh <secondmachine.whatever.tld>.<hopmachine>", and then I transparently connect from my workstation to the secondmachine, through the hopmachine. This is also more secure as the hop machine is just a dumb transport for data.
> I'm an embedded dev as well, and I use zmodem everyday. I have boards that have no network, just a serial port, and I can upload an executable, download the log from just the debug console.
Absolutely, zmodem is still very useful for serial links, and they are very common in embedded devices.
I really doubt there's any reason to use zmodem over SSH other than convenience if you happen to know it better than the alternatives.
> I really doubt there's any reason to use zmodem over SSH other than convenience if you happen to know it better than the alternatives.
You might not have encountered it.
Here's the use case: the ssh session terminates at a bastion host running a restricted sshd that drops port forwards and punts the connection to an internal landing host which is not permitted to ssh out.
Using an in-band file transfer protocol is incredibly useful.
Then there's other tricks you could do like port forwarding, filesystem mounting over SSH (sshfs) etc. But if zmodem works for you then it's as good a solution as any of the above. I only give SSH examples as demonstration at just how scarily powerful a tool it can be.
That assumes ssh is present to begin with. Really in the embedded world (which was the context if I got it right) you can just about throw all those assumptions out of the window. You're roughly back in 1989 or so when it comes to the features available to you in the environment, unless you're going for the more powerful platforms (with associated physical footprint, power consumption and boot times).
I attended several BBSCon which was a BBS conference sponsored by BoardWatch magazine. It later morphed into ISPCon.
Chuck Forsberg was a featured speaker from the beginning at BBSCon. Here's audio of him talking with Ward Christensen, inventor of XModem as well as CBBS which was the world's first BBS.
If you're not old enough to remember late nights dialing into BBSs you really missed a very interesting time in computing. Most BBSs were pretty tight communities. ZModem was an integral part of the technology that made this happen.
My brother and I discovered BBSes in at the peak of our adolescence. Someone had given a copy of Procomm that we could use with our 2400 baud modem and a list of BBS numbers and it didn't take us too long to learn that some of those BBSes hosted porn. We had some friends with modems and it wasn't long before we started a porn collective where we'd coordinate downloads and share images via floppy disk and bicycles.
Because most of the BBSes would only give you 30-60 minutes a day, time was of the essence. You'd quickly log in, scan the list of files with the most promising sounding name, start your download and wait an agonizing 5-6 minutes counting the seconds until it was complete.
There were a few dilemmas you had after downloading. You could disconnect so you could view the picture right away, but you risked not being able to get back in because some other guy called as soon as you hung up.
ZModem was a godsend. Not only was it faster, it supported resume after abort when your line got disconnected. Soon after, the terminals and picture viewers were getting so good you could shell out and view images while you were downloading.
Zmodem inspired me to rewrite the CP/M BIOS routines for reading the floppy drive on the computers we sold at my first job. The floppy format had a sector interleave of 4, which meant 4 rotations to read an entire track. 300RPM is slow enough without cutting it to 75 effective RPM.
The interleave was a throwback to the programmed-I/O days of older systems; the CPU couldn't setup to read the next sector right away, so they solved that problem with an interleave. But the new systems had a DMA controller, so I made the BIOS interrupt-driven and read the sectors out of order but into the correct RAM buffering address. Instant hot rod floppies. Everyone on the team bitched that I "wasted" two days "over optimizing a non-core feature". You know what though, they all smiled most every time they had to sneaker net something to a different department.
Zmodem was awesome. I remember the transition from Xmodem or Ymodem to Zmodem. Zmodem was fully duplex and was so much faster than the other protocols, until BBSes died due to the Internet. I'm hopeful he lived a very great life.
What a great write up of someone that was very influential in the BBS world for pretty much all users. My ZModem memory is downloading the 5 zip files for Duke Nukem 3D.
We had three BBSes (Tat's Box, Blind Man's Bluff, Microcosm) in the mid 1990s where I lived in East Texas and would have regularly monthly meetings at a local pizza place. It was a special time that I wish more people could have experienced.
The conversations about politics, religion, and computing in general are similar to what I see on the web today, but back then it felt like everyone was more aware of the fact that there was another person on the other side.
Without zmodem... I wouldn't have downloaded the huge number of floppies required to install SLS Linux back in the early 90s. The download took forever. I can't imagine how long/hard it would have been without it! Instrumental in my getting into Linux!
I never knew him or was aware of him, but apparently I loved him.
From the wikipedia page on zmodem: This design limits the feasibility of ZMODEM to only reliably transfer files that are under 4GB in size.
Haha, I remember waiting 30 minutes for 200k and that seemed like forever. How anyone would have gotten to 4gb back in those days and would even have a way to store that much data makes me chuckle.
Brings back memories. I used the official Omen Technology software externally on my BBS because it was better than the software's built-in implementation.
Omen also had a terminal client that was equally as cumbersome to use, but quite powerful. I used it for a few months until the richness of Terminate pulled me back.
Back in the 90's I ran a 24 line BBS that used Zmodem and a Telix script I wrote to mirror itself to 20 systems worldwide. Zmodem was the only way I could reliably transfer files to those systems via dialup. Chuck was always my hero for writing such a solid protocol.
At some point in Finland we got smodem. This was huge improvement. You could upload, download and chat at the same time.
https://en.m.wikipedia.org/wiki/SMODEM
Well, God bless him! I'm thankful for his work on Zmodem. It was such an advancement over X/Ymodem. His work had a positive impact on helping me learn more about computing, and become more fascinated with it, which I am to this day.
Very sad news. Ran a BBS in the early 90's and it was a wonder to move to Zmodem. I still use it every day. lrzsz and built in zmodem in ZOC. Superfast simple file movements.
I tinker with embedded hardware in my spare time, basically anything I can get serial out on. It seems like I could learn a lot from zmodem - but where do I start?
here’s my impression of how kermit works
client: here is byte number 1 server: i have received byte number 1. the checksum was 3. client: i agree that the checksum was 3. server: ok, we’re done with byte number 1. client: I agree, we’re done with byte number 1. client: here’s byte number 2. server: you know, it’s not easy being green
now zmodem zmodem goes something like this:
client: I’m gonna send you about 200k now, and you’re gonna bend over and take it server: thank you sir! ( … ) server: ok, got 200k, checksum was 523 client: DID I ASK YOUR FUCKING OPINION? server: NO SIR! SORRY SIR!