Serial Transfer

A project log for OMNI 4 - a Kaypro 2x Logic Analyzer

A while back I acquired a rare logic-analyzer, whose lone system-diskette needed backing-up. Now this page is all things OMNI 4

Eric HertzEric Hertz 09/18/2017 at 00:2619 Comments

Oddities abounded... apparently the KayPro 2x doesn't have a standard serial port pinout.

Key factors include: Only using CTS, and Tx and Rx swapped. I found  this pinout in the technical reference manual.

Here's a cable I hacked from a typical null-modem for communicating with a newer PC...

DB25 (M)       DB9 (F)
2  RxD         3 TxD
3  TxD         2 RxD
7  GND         5 GND
20 CTS         4 DTR
               1 DCD,6 DSR (unnecessary?)

 Note that the end-result is very different than a null-modem... weird world.

(CTS <- DTR, NOT CTS <- RTS, was necessary, otherwise the transfer never starts)

Truns out pip doesn't convert *to* ihex, only *from*... well that doesn't help. OTOH, looks like the serial port does infact send 8 bits.

On the PC-side I used 'dd bs=1 if=/dev/ttyUSB0 of=<filename>' (after setting the baud-rate to 300bps (!!!))

On the KayPro side I used 'pip tty:=<file>[o]'

tty: is the serial printer port, and [o] indicates to send the file as binary, so it won't stop early when a byte matching 'end-of-file' is found.

After the transfer completes, the KayPro returns to 'A>'... at which point I type <CTRL>-C on the PC.

The process is *slow*... and pip doesn't say much while it's running... or not (e.g. when the handhaking is not correct, it just stalls... forever?) 

So I opened another terminal window on the PC and ran 'ls -l <filename>' repeatedly to make sure that filesize was increasing. 

Many files from the disk are now available in the files section, after literally hours of file-transfers ;)


There were some strangenesses during the transfers. I transferred K2X* twice, and verified they matched. LA.COM I transferred numerous times and verified they matched, but the remaining I did not verify. Oddly, unlike the others, their file-sizes didn't match the output of 'D.COM' (which is essentially 'dir' or 'ls'). One I tried twice, both times receiving 4K, when D.COM claimed it was 6K... so I dunno.


Eric Hertz wrote 09/19/2017 at 17:58 point

@ziggurat29 interesting re: 8008!

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 17:56 point

@Morning.Star pretty certain it's parallel printer, not SCSI... but that'd be a trip. Scsi is cool, doubt I'd miss it right in front of me ;)

  Are you sure? yes | no

ziggurat29 wrote 09/19/2017 at 18:46 point

definitely garden variety parallel.  And unidirectional at that. There is a latch on port 0x18 for the data, and a bit 3 on port 0x14 for the strobe line for the printer, and that's it, I think, but I'd have to look at the schematic or the code to verify there is not, say, 'paper status', 'online', etc. somewhere on an input port, but I don't think so right now.

There is a serial port dedicated for a serial printer, and a serial port for general IO (which I believe is the one you were using for transfer); both are hard-wired as DTE, I believe.  There are two other serial ports for special purposes -- one for the built-in modem, and one for the keyboard.

  Are you sure? yes | no


[this comment has been deleted]

Eric Hertz wrote 09/19/2017 at 02:56 point

You've some interesting projects. I want ro hear this alien thing!

And cool about the combo lock... analog? ttl?

Haha brokasheck... almost forgot about that... yeah, it can be an isolated place to be. Not quite as isolated as Antarctica, and generally warmer. Can be hard to get away from... Best of luck!

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 03:41 point

sounds interesting. I think I recall museum madness. Certainly recall franchise radioshacks.

  Are you sure? yes | no

Starhawk wrote 09/19/2017 at 02:09 point

Also, printers are PARALLEL. At least traditionally. *That* protocol is IEEE1284, if you want to look it up. So it's not a "serial printer" port. It might be a "serial terminal" port -- RS-232, once current loops went out of fashion, used to be used to connect what we now call dumb terminals ("video terminals" in the day -- really a teletypewriter with a screen instead of a daisy-wheel printer -- look up the DEC VT100 and the Wyse 50) to business mainframes and minicomputers...

Then again, another term for "teletype" or "teletypewriter" was "teleprinter" -- so it might be referring to that. Again, it would in reality more likely be hooked to a video terminal...

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 02:47 point

yep yep... this box has both a centronics parallel printer port and a "serial printer" port... both a bit uncommon in my experience. Maybe teletype is what they had in mind... it is called "tty:" in the os. Doubt there would've been much use for a dumb terminal attached to this thing which is meant to be luggable and already has a screen/keyboard which it uses upon boot... but who knows... daddy uses the main machine while kiddo types on a vt100? Possible, and kinda cool to imagine... but os support seems lacking. And really, I bet vt100s weren't much cheaper nor their cpus much less powerful..

  Are you sure? yes | no

Starhawk wrote 09/19/2017 at 02:57 point

Teleprinter, then.

But, you're not thinking about it right -- the VT100 doesn't *have* a CPU. /That/ would be the VT180 -- which is in fact a VT100 with a set of add-on cards that turn it into a complete microcomputer. Video terminals were exactly that and nothing more -- they could not /per se/ compute themselves, they just sent data back and forth to something that could. Hence the modern term, "dumb terminal". Seriously, the electronics in a video terminal were just barely enough to put letters on a screen when receiving (usually 7bit ASCII over RS-232) data, and to scan and decode the keyboard and report (same protocol, usually) back to whatever was actually driving the blasted thing.

Think in terms of teletypewriters such as the Teletype (brand) 33 ASR, which was the standard of its day. It's literally a keyboard, a daisy-wheel printer, and driver circuitry, along with a current-loop "modem" -- and that is it. (Well, okay, there *was* the option of bodging on a Hayes AT modem in the waning days... but let's not talk about that.) If you replace the printer and corresponding logic board with a CRT and /its/ requisite power and control circuitry, you get what a VT100 is supposed to be. Nothing in any of that can reasonably be called a CPU -- CPUs, even fogey old CPUs like the Z80 (which went into the VT180 on one of those cards, IIRC) are an order of magnitude (at least) more complex than anything required of or present in a teletypewriter or video terminal.

  Are you sure? yes | no

Morning.Star wrote 09/19/2017 at 05:20 point

Hey Eric :-)

Are you sure that Centronics plug is a printer port? They also got used a lot for disk drive interfaces... Starhawk is probably right about it being 1284 protocol, I encountered loads of PC cards dedicated to 'Scuzzy' hard drives back in the day. They all had that rounded 50-way connector. ;-)

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 03:13 point

guess I hadn't thought about it really... I kinda figured it a bit like a video game system in the era of NESs... has a full blown cpu, much like the one in a home computer of the era... (e.g. apple 2), but much limited in terms of support circuitry and general purpose hardware and I/O (no floppy, no printer, no expansion slots... no os... no bios!) Yet, realistically still having a full-fledged era-computer-cpu with a dedicated purpose... (depending on the 'boot rom'/cartrige inserted...)

Decoding a keyboard matrix and storing 80x24 bytes is no small task... and random-access as i recall (requiring protocol handling, etc) there must've been some sort of processor (or many?) in those 'dumb' things... certainly dumber than a mainframe, but I bet capable of way more than allowed... I'll have to look it up.

  Are you sure? yes | no

Starhawk wrote 09/19/2017 at 03:24 point

Again, you're overthinking it. Serial terminals didn't store jack $#!*. If all you need is hexadecimal... Intel 8279 and enough 7400 chips stacked 'round to provide some illusion of a control system and a crude transceiver setup (TBH you could probably get away with a 74C922 and some circuit shenanigans instead of the 8279), that's all you need. A full ASCII keyboard and a CRT...? Either an MC6845, character ROM, a couple cheap DRAMs, and a triple-fistful of 7400-series chips direct-driving the CRT through some sort of analog monstrosity, or an MC6847 in text-only mode (gaining an internal character ROM) paired with an MC1372 and a CRT kit/setup that can take composite video in (they sold those as modules, that's how the Osborne One works), for the screen, and another pile of 7400-series chip crap to do strobe-and-sense for the keyboard and to send data back and forth.

Contrary to popular opinion, you do not need an actual CPU in /any/ of that. It's all send, recieve, display, and decode. A CPU in that sort of thing would not only drive the cost way up so that nobody would buy it, but would be so bored as to likely get up off the PCB and wander away in search of something actually meaningful to bother with...

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 04:12 point

as I said.. cursors and escape sequences... those would be doable with discrete logic, sure... but it adds.up. regardless, think of the era... it wasn't the cpu that made it expensive... otherwise a kaypro wouldn't've been twice the price of a vt100... and, as you pointed out, microcontrollers of the era weren't really that different than cpus... mostly a matter of smaller instruction sets, internal ram, and a few embedded peripherals... and the romless ones even less different... exposing their bus for any memory-mapped I/o just like a cpu...

So we're left with... what would be an era-relevant way to build a slightly less dumb dumb terminal... and the answer is use a cpu, be it a uc or full fledged... at which point using the kaypro with two heads doing two separate things is a little ridiculous (especially when considering the lack of multitasking). In which case we're right back to where we started, that the "serial printer" port was intended for exactly that... and the second serial port... whatever random thing a user might wish, but nothing particular on mind. So then we're down to hackery... does it make any sense to throw a terminal on there when really the terminal itself is as smart as the system, only crippled? Or maybe a *really* dumb terminal... could be turned into something with the right software... or maybe not a terminal at all... maybe a groovy custom peripheral with a brain of its own that interacts with this comparatively dumb machine... (a switcheroo) maybe use the kaypro *as* a video terminal...

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 03:49 point

well lookie there... vt100 = i8080, wyse 50 = i8031... booyah!

But yes that isn't to say there weren't dumber terminals that could be attached to a kaypro as a second 'head'... dumber ones... not having cursors, etc, would be quite limiting for usage... maybe for error/debug output... then a printer might be handier... scrollback...

  Are you sure? yes | no

Starhawk wrote 09/19/2017 at 03:53 point

Intel 8031 is actually an 8051 MCU with no internal ROM... /technically/ not a CPU, although in that era there wasn't much difference. 8080, though, you got me there. BTW, the first CPU or CPU-like chip that had the "i" prefix was the 386 -- because the USPTO won the lawsuit Intel brought against them for saying that Intel couldn't trademark a number by itself (geez).

I've got to say I'm rather surprised, though, that chips of that sophistication were present in that equipment.

  Are you sure? yes | no

ziggurat29 wrote 09/19/2017 at 04:51 point

The 8008, predecessor to the 8080, was created specifically for a dumb terminal (well, sort of; the contract for the terminal vendor didn't work out, then Intel rebranded the processor as the 8008 for the general market. And so a long line of microcomputer history started....)

  Are you sure? yes | no

Starhawk wrote 09/18/2017 at 23:15 point

That's actually clever, switching RX/TX -- that way you don't NEED a null modem cable, the exact specific purpose of which is to switch those two lines. Bear in mind that, when RS-232 was originally created, it was intended strictly for two devices, a computer (not necessarily an /x86/ box, mind you...) and a modem -- and that particular combination was the only one considered in the spec.

Nobody thought that you'd want to connect two /computers/ that way -- or anything else other than a computer and a modem. All of that came much later, as did the "modern" nine-pin COMport -- the original connector was a twenty-five-pin male "parallel port" connector -- the different gender serving to prevent you from plugging your daisy-wheel or dot-matrix printer into the COMport accidentally and frying its logic board (presumably in a positively /spectacular/, if somewhat small-scale, fireworks show) in the process. The 25 pins really were needed in that day, and there are still a few legacy gadgets lying around from that era, in various parts of the world, that still need all 25 pins in order to work properly!

But there are also almost as many cut-down implementations of RS-232 as there were home microcomputers (as they were called) in the 70s and 80s. Take a look at the Commodore 64's RS-232 port some time... it's implemented using what's called a "bit-bang" method. Bit-banging is where you use a pin on a parallel I/O port (or a GPIO on a microcontroller) and you toggle it on and off and on and off to essentially simulate a serial port where there isn't one. On top of that, the C64's RS-232 is at TTL levels (so it's really just regular TTL serial) -- you need a MAX232 chip and the requisite capacitors, to bump it up to proper RS-232 levels (+/-12v, instead of +5v/0v) and it only has four lines -- TX, RX, CTS, RTS -- oh, and there's no dedicated connector, it's embedded into the User Port. Gee, have fun with that...

...and, yes, TTL serial really is the RS-232 protocol, using different voltage levels to be more compatible with various kinds of logic chips and microcontrollers and CPUs. MAX232 chips haven't been around forever, you know ;)

...oh, and if you want to REALLY torture yourself... look up current loops. That's how serial was done in the teletype era. It's awesome, particularly over seriously long distances -- and super easy to implement, even with discrete-transistor tech -- but it will screw with your head something fierce when you go to try and understand how it works. It's /weird/.

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 02:02 point

awesome! Thanks for the study-material!

Good point about swapped tx/rx and modem cables... wonder if it's only the case on the printer port... there is a user serial port, I just dunno its name. 

And the explanation that rs232 was designed for one purpose (connecting "terminal equipment" to "communication equipment", I presume) would help to explain why the pin names seem arbitrary regarding which direction they go wrt a computer... assuming the (or one) computer is always the "terminal" (as in end-point or destination?) would probably make those signal names/directions more intuitive for me. Thanks!

The CTS <-DTR hack was a bit of a guess, on my part...CTS <- RTS didn't work. My guess was that the PC wouldn't necessarily be *requesting* data since it sits around waiting for whatever comes in... OTOH, it would most likely signal that it is ready for data (to come whenever it might) at least whenever the ttyUSB device file was opened for read. Now I think it makes even more sense when considering the PC a terminal, vs a modem... surely a modem with data in its buffer would request that the terminal is ready to receive data (e.g. where a terminal might be a printer whose baud rate is faster than the print head). So figuring a fast PC with a hardware serial buffer which is backed by a huge OS buffer, probably would seldom if ever need to indicate that the buffer is full... seems reasonable, but still not within the spirit of the spec...

The odd bit being that RTS *wasn't* being toggled... maybe that's the difference between actually performing a blocking read() command vs. A non-blocking "is data available? Then read ()"... hmmm....

Or... maybe different equipment handles "hardware handshaking" differently (actually, I discovered the lack of RTS output from the PC when running hyperterminal in windows... hmmm) 

and then... actually, if the names on the modem side and terminal side arethe same... and a straight-through cable used... then it makes even more sense that the names would change depending on the computer manufacturer's intent... *nixes often using serial ports to connect to (dumb) terminals... making the *nix machine "communication equipment" whereas windows' often using the port for modems and/or mice, etc .. making the windows machine "terminal equipment"... no wonder the pinouts vary! Oy! Realistically, it seems to me, the computer-side  probably wouldn't have *all* the signals *unless* it was designed with intent to be used as both comm and term equipment... oy! Which, then might explain why one of my *nix machines had two device names for each a erial port... tty and cu. Hmm.

I guess a good example of a pin that would have a different direction depending on which equipment it's attached would be "ring indicator"... clearly that'd only come *from* a modem, and only go *to* the computer/printer "terminal". Hmmmmmm...

So then... a straight through cable, as originally intended, would indicate that the names of the pins should be relative to the *modem*, and that there is no *one true* serial port pinout, because it would depend on which end it's attached and what that equipment may be. Sheesh!

Got me thinking!

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 02:07 point

I've already tortured myself with current loops... midi... lvds... I'll leave that to the other readers ;)

  Are you sure? yes | no

Eric Hertz wrote 09/19/2017 at 02:18 point

interesting about the comedore 64  using bit banging... and ttl levels... at that point, it's more like saying it doesn't have a serial port at all, but one could be emulated with the parallel port (and level shifters)... except that, from the sounds of it, there's a default/standard emulation pinout... and bios/os support for said emulation... Interesting.

  Are you sure? yes | no