Koen Martens <gmc@metro.cx> wrote:

Nils M Holm <nmh@sraddha.invalid> wrote:

There's QTERM and other programs for serial connections. You usually
don't use a terminal emulator, though, because you use a real terminal
(or emulator) to communicate with CP/M. SO if you want VT100, just
connect a VT100 terminal to your CP/M machine. :)

The only 'terminal' I have is a DECwriter :)

Now that's a cool terminal! :)

I'm on the lookout for an actual VT100 though. ~20 years ago you'd
stumble upon one on every street corner and they were giving the away
by the pallet load, but it seems they're a bit more rare nowadays.

Yeah, I remember getting a used one for little money some 25 years
ago from a guy who repaired TV's. Gave it away when I stopped
collecting old hardware.
--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

Keep in mind Kermit was less popular than the XMODEM,YMODEM,etc.

Indeed. My CP/M single board computer came with a program
with X/Y modem built in.

Friends were Kermit advocates but that was like early Linux.
Open source but all roll-your-own.

--

ZMODEM was the preferred one due to efficiency, until bimodem came
along, which let you upload, download & chat at the same time!

ZMODEM was great because it allowed for batch transfers.
Procomm automatically recognized the start of transfer,
popping up the file receive function.

--

On 6/11/26 2:43 PM, Jeff Jonas wrote:

Keep in mind Kermit was less popular than the XMODEM,YMODEM,etc.

Indeed. My CP/M single board computer came with a program
with X/Y modem built in.

Friends were Kermit advocates but that was like early Linux.
Open source but all roll-your-own.

Kermit was well used long before most of us got into computers.

It was designed to work on pretty much every system out there and allow
file transfers between them. This made is the de facto file transfer
protocol between dissimilar systems (ex: Univac mainframes and CP/M).

XMODEM was made to work on systems that were very resource constrained,
but didn't have the "dissimilar systems" requirement. So XMODEM worked
much better when going CP/M to CP/M or even between CP/M and MS-DOS.

YMODEM, of course, was just XMODEM with a larger block size to reduce
the overhead.

ZMODEM was the file transfer protocol rethought/redesigned based on the technical advancements (i.e. faster and error correcting modems, faster computers, etc.).

Fun Fact: Kermit already had many of the features that ZMODEM had long
before ZMODEM existed. Ex: batch file transfers, I don't remember what
ZMODEM called it, but Kermit called it "Sliding windows" where blocks
were sent before the prior blocks were acknowledged.

ZMODEM was the file transfer protocol rethought/redesigned based on the technical advancements (i.e. faster and error correcting modems, faster computers, etc.).

, asymmetric modems, problematic latency on packet switching networks, ...

Fun Fact: Kermit already had many of the features that ZMODEM had long before ZMODEM existed. Ex: batch file transfers, I don't remember what ZMODEM called it, but Kermit called it "Sliding windows" where blocks
were sent before the prior blocks were acknowledged.

ZMODEM went further. No acks at all, 'til the end, at least in some
cases. One good reason for doing that, if the link was reliable, was
that some modems would turn the line around every time you sent an ack,
and then again for the next data packet, and then...

*cough*HST*cough*

De

You might want to look at Z20X LCD CP/M open source software and
hardware. z20x.cc

Tom
KE6JAG

KE6JAG <ke6jag@email.com> wrote:

You might want to look at Z20X LCD CP/M open source software and
hardware. z20x.cc

An interesting project, but I prefer the DIP-based ones. Yes, I know,
the DIP-based Z80 is discontinued unfortunately, but it's a lot easier
to solder than the SMT eZ80 components. And the Z80 uses external ROM,
whereas the eZ80 boots off of internal flash, which is also less
interesting to me. The eZ80 also has a bunch of built-in peripherals,
which makes it more and more a microcontroller and less and less a microprocessor, even though it still exposes all the
data/address/control bus signals externally.

Having said that, the z20x is definitely more future proof than the
RC2014 for example, which uses the DIP packaged Z80.

I might see about building a z20x though, I've been meaning to get my
feet wet with the eZ80. Thanks for sharing!

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

Having said that, the z20x is definitely more future proof than the
RC2014 for example, which uses the DIP packaged Z80.

Presumably someone will make (has made?) an adapter for a 44LQFP
Z80 to DIP form factor.

De