Floppy "Fun" -- Backing up a unique Kay-Pro disk

Apparently I've acquired a one-of-a-kind logic-analyzer, whose lone system-diskette is in need of backing-up.

Similar projects worth following
This KayPro-based "Omni4" logic-analyzer is pretty impressive, for its time... And still certainly usable/useful. 20MS/s on 16+ channels...
30 years old, and it booted up right away, despite having its diskette clamped in its heads for probably decades.
I can't find much on the ol' interwebs about this machine, so it's plausible this is amongst only a few remaining system-disks on the planet!
But copying this aging diskette has turned into quite a feat.

Based on the limited info I can find on the web...
(see a great article, here).

It would seem I've come across a system which may be one of only a few remaining in existence... or at least one of only a few that anyone's bothered to mention on the ol' interwebs.

And I've only got the one floppy disk containing the software for its unique hardware...

And thus beginneth my endeavor into learning a bunch about floppy-disks, drives, and more.

What I thought was going to be a one-night project with a floppy-disk imaging-utility like ImageDisk has turned into a month+ of work, extracting as many sectors as possible via many different methods, including several scripts and a pretty large program I've written myself. Has turned into my learning about MFM-encoding, CRC-checking, Gap-lengths, and countless other factors of floppy-disks, some eccentricities and limitations of various floppy-disk-controller-chips, and more.


So, what's the world-changing-ness of this project...? Well, as it stands, this little piece of history isn't too-well-documented... and if its lone floppy-disk fails before I can make a copy, the entire system could be lost to "bit-rot," plausibly leading its kind to extinction!

Don't want to see that happen!

And, otherwise, even if it's not so unique, at least it'll still be functional, keeping a chunk of metal from the e-waste bin and, with the right owner, giving this system a few more years of usefulness. 20MS/s is still plenty for many needs!

(Heck, most of it is based on well-documented and easily-sourced chips... it could very-well outlast the majority of systems in use today, 30 years after its birth).


Floppy drive manual... this drive is *not* from the Omni4, but this manual has extensive data regarding the boolean-logic implemented in drives' circuitry regarding I/O. E.g. /STEP is ignored if /WG is active.

Adobe Portable Document Format - 481.84 kB - 11/15/2017 at 11:37



Old photos of the Logic Analyzer PCB prior to the "white-powder" incident, which destroyed readability of many chips. It's plausible some of the now unreadable chip-markings may be readable in some of these images (plausibly with some image-processing: contrast-adjustment, etc.).

Zip Archive - 32.04 MB - 10/08/2017 at 05:07



Combined disassembly of boot ROM and all operating system components. This is ongoing work, current as of the timestamp in the filename. (Note from esot.eric: WTF!!!! This is some INCREDIBLE work, here, by ziggurat29!)

lst - 639.21 kB - 09/27/2017 at 03:20



some other files from the logic-analyzer disk that may be part of the LA program, including la.la0 (?), la1.lah and la2.lah (which appear to be help files), z80.z80 (which appears to be an example for disassembling with the logic analyzer), (pattern-generator), (PROM programmer). These files were not verified with the originals and transferred at 300BPS, so I don't plan to verify them any time soon. IMPORTANT NOTE!!! These files were serially-transferred via PIP.COM, which appears to have converted "Tab" to spaces, regardless of whether the files were transferred as binaries. These are PROBABLY WRONG. Instead, try using cpmtools with the 'kpiv' format (despite its being a KayPro 2x, not an IV/4) on the raw binary disk-image.

Zip Archive - 72.71 kB - 09/17/2017 at 23:51

Download, copied from the original floppy via serial port at a whopping 300BPS. Several other files exist which may be necessary for running this program (e.g. la1.lah)... These are large and not (yet?) downloaded. IMPORTANT NOTE!!! These files were serially-transferred via PIP.COM, which appears to have converted "Tab" to spaces, regardless of whether the files were transferred as binaries. These are PROBABLY WRONG. Instead, try using cpmtools with the 'kpiv' format (despite its being a KayPro 2x, not an IV/4) on the raw binary disk-image.

bs=1 - 33.54 kB - 09/17/2017 at 19:02


View all 11 files

  • 100 × blood
  • 1000 × sweat
  • 10 × tears
  • 400 × hours

  • DRAM Refresh....

    esot.eric11/07/2017 at 08:28 4 comments

    UPDATE: Whoa Whoa Whoa..... (at the bottom).

    So, the question, earlier, came up regarding how the DRAM gets refreshed, if the /REFRESH pin is N/C (which it appears to be, according to the schematic).

    and dammit if I didn't have a long write-up on the matter, and lost everything after this point. So, I guess I'll get to the point.

    There's really no *need* for the /RFSH signal. At least with typical DRAMs. Basically, a row in the DRAM is refreshed whenever a row is accessed. And for a typical Read/Write operation, the row is accessed first, then the column, then the Read/Write signal is sent. So, the row gets refreshed with every read/write access.

    So, why not treat *every* address placed on the address-bus, accompanied by /MREQ, as a Row AND Col access, as though for a read/write? And... now I'm pretty sure that's what happens.

    And I'm betting the custom chip doesn't contain any specialized logic regarding refresh.


    There's still the issues of BANK and /PROMCS, and how those are related to the DRAM... My guess, again, is that *every* address-access on the Z80's address-bus, accompanied by /MREQ, accesses a memory-location in the DRAM (even, for instance, when the ROM is being read).

    BANK is controlled by a bit on the "system port" register... That, as we understand, chooses whether to do memory-accesses from the ROM or the RAM. So, e.g. during boot, BANK directs it to the ROM, then after boot, its directed to the RAM where the OS is stored, etc. (There's some debate as to whether the "BIOS" in the ROM is accessible to applications once the bank has been switched to RAM... E.G. if there could be, say, routines in the BIOS for displaying characters on the screen, could that be called from a user-application, switching into the ROM for execution, then back into the RAM for the next portion of the user-application? I'm sure there are ways, but they may not be pretty... e.g. storing *pieces* of the same code in both ROM and RAM, at the same locations... I'm sure I can find out with further analysis of Ziggurat's ROM disassembly).

    So, obviously, when BANK is set to ROM, /PROMCS gets activated with /MREQ, but /XENRAM does not. But, then, when the ROM is executing (during boot), the RAM still needs to be refreshed... so its still feeding *every* address-access to the row/col system... Which is fine for /RD, since /XENRAM is disabled and therefore the data in the DRAM is not written to the data-bus...

    But what about Write...? /WR is not gated through the custom chip, it goes *straight* to the DRAM!

    Ah hah!

    Write... Never Happens to the Read ONLY Memory.


    Now this leads me to the question of how the ROM can access RAM, for storing variables, etc.

    In what I've seen of Ziggurat29's disassembly, it seems the stack-pointer is set-up in a high-address, e.g. 0xff00... and it seems most other variables are stored up there, as well...

    So, then, BANK only switches between ROM and RAM in the *lower* addresses, and always accesses RAM in the higher ones... simple enough.

    And, again, by treating the RAM as though it's being accessed even when the ROM is, but gating the RAM's /RD signal (/XENRAM), it still gets refreshed.

    This custom chip is starting to seem quite simple, really... a few gates.

    (As Ziggurat29 pointed out a while-back, the 2x motherboard uses this custom chip, but the earlier motherboards are similar in design but use discrete logic instead... I've been meaning to look at those, but haven't yet. All these ramblings are from the perspective of treating it like a black-box... I guess it's kinda like doing math homework where the answers are in the back of the book... should I go look?)


    Whoa Whoa Whoa!!!

    that /WR signal is *directly* connected to the DRAM chips! And they don't have Chip-Selects! That's fine for ROM... but...

    What the heck happens during an I/O write!?

    ... "/CAS is used as a chip select activating the column decoder and the input and output buffers."

    So, maybe I'm mistaken in...

    Read more »

  • 'round the web...

    esot.eric11/06/2017 at 12:24 2 comments

    1) An image-search for '"Omni 4" "Logic Analyzer"' results in many hits from this project-page... pretty cool. OTOH, it's quite strange, saying that many of the images are "4-5 days ago" that were actually several months ago. (is it 4-5 days ago that Google crawled on 'em?)

    2) A resulting-image doesn't show anything related to the OMNI4... so I clicked through to the page to see what Google thought made it relevant... Apparently MAME now comes with the OMNI4 ROM (?!)

    "October, 26th 2017" ... "Changelog" ...

    "What's new in this version:" ... "New clones marked as NOT_WORKING:" ... "- Omni 4 Logic Analyzer [rfka01]"


    A bit more research...

    Added as a 'diff' patch 10-15-2017.downloads/mame/mame-0191/

    Cool! Glad to see it won't get lost to bit-rot. Is this your doing @Ziggurat29?

    ...ah... the ROM's not included with MAME's source-code... so I guess it still has to be downloaded from somewhere.

  • Esot's Analysis of Ziggurat29's Boot Disassembly... -- video initialization

    esot.eric11/03/2017 at 07:33 0 comments

    Update 11-6-17-2: Notes on I/O addressing thrown at the bottom.

    Updated 11-6-17: Revision with some new understanding...


    Ziggurat29 has done some amazing work disassembling the OMNI4's Boot-ROM and OS(?!).

    (Note that we've determined the motherboard is a pretty-much stock KayPro 2x, but it has a custom Boot-ROM and Character-ROM, both of which are available in the "Files" section of this project).

    Herein, I'm gonna throw up some notes, as I read-through his work...

    (Note that I currently have Zero experience with Z80 assembly-language, and am pretty slow with assembly-language in general, and am unfamiliar with the unit's registers/peripherals... So, this is a great learning-opportunity. Interestingly, this is the same approach I took in learning about the IBM PC/XT architecture, by looking at the BIOS Assembly-listings and schematics in order to determine how to initialize and make use of its peripherals.)

    You might want to take a look at the KayPro Service Manual, which contains schematics of the KayPro 2x motherboard.


    First interesting note...

    The BootROM appears to launch right into external (to the Z80 chip) register-setup... Apparently not much configuration needs to be done within the Z80 CPU, itself.

    There is a "system port" register at 0x14 consisting of quite-literally a byte's worth of TTL Flip-Flops whose outputs are fed to various peripherals, most-notably the Floppy-Controller, but also the Character-Generator ROM (and more?). Setting up the "system port" register is the second operation, the first being setting up the stack-pointer, and both are accomplished in only a small handful of instructions. Wild.

    UPDATE: The system port (address 0x14), from the schematic:

    D0 - /DRV_A              (Floppy)
    D1 - /DRV_B /HD_CTRL_RST (Floppy)
    D2 - /SIDE_ONE           (Floppy)
    D3 - /PSTROB 
            (Parallel Printer Strobe)
    D4 - /MTR_ON             (Floppy)
            (via inverter)
    D5 - /DDEN               (Floppy)
            (Double-Density Enable)
    D6 - A12CH (Write), [PBUSY (Read)]
            (Selects the character-set)
            (See notes in previous log)
    D7 - BANK                (RAM vs ROM?)

    (Side-Note: Appears that the parallel-printer port is output-only, and reading the written values is not possible... wouldn't take much modification to make it bidir... strap a '244 atop that '373, and some glue...)

    Immediately thereafter, is the version-string "2.01", which gets loaded into RAM. This version-string appears on several screens... E.G. When the unit is turned on, as I recall, it says something like "Omni 4 version 2.01" and also, upon loading CP/M, something like "Omni 4 CP/M version 2.01". (TODO: verify... I thought we had CP/M 2.2..?)

    It's interesting to me that these two things are in the Boot-ROM, as I'd've thought CP/M was loaded from the disk (and therefore its version would be dependent on that which was on the disk... like, e.g. DOS 3.3 vs. DOS 6... Or Windows XP vs. Windows 10).

    (To-Ponder... The RAM is already being filled with data, including the version-string and the stack, at this point... More, surely, to come... But doesn't this system use DRAM? Doesn't it need refreshing? How about column vs. row-addressing? Is that *all* handled via dedicated circuitry?! (UPDATE: Looking at the schematic, it appears U29, a custom chip numbered 81-194, takes care of this. This chip appears to handle only interfacing with the DRAM and generating a few clock-signals, from 4.9KHz to 4MHz. As (Actually, it has a couple other outputs I'm working out). Ziggurat29 has pointed-out, this custom chip is a new thing as of the '84 versions of KayPro systems like the 2x, the prior versions used discrete logic, which I've yet to look into. Interesting that, at the time, designing and manufacturing a custom 40-pin chip is cheaper than just replacing the...

    Read more »

  • Duds

    esot.eric09/25/2017 at 11:26 10 comments

    the serially transferred files are duds.

    Apparently pip decided to translate tabs to spaces.... even in binaries, even in binary mode.

    On that note... cpmtools seems to work with the disk image when using the kpiv format.

    Only one hiccup (besides discovering the tab to space conversion)... a large text file ends with a bunch of 0x1a's... (ascii substitute?) Dunno why, but doubtful they belong there.

  • Chargen

    esot.eric09/22/2017 at 05:44 7 comments

    u9 appears to be the character ROM... there's a 2732 24 pin EPROM in the socket. Its contents is in the files section, and ziggurat29 decoded it into ascii art. It appears the Omni4 has a custom character set for drawing logic waveforms.

    Ziggurat noted that the schematic shows pin 2, a12 is driven from somewhere... (where?). Well the 2732 doesn't have an a12, but the 2764 does... and the 2732 is pin-compatible-enough that it could be dropped in a 2764 socket, if said socket is designed with that intent... which this one is. And that explains the larger socket than the chip...

    Ziggurat also noted some code in the bios that seems to support character-set switching (via a12, most likely)...

    So my guess is that this was designed with the intent to support two character sets... a normal one for normal stuff... and switching to the custom one for the logic analyzer.

    Seems logical.

    So some tests run tonight:

    A12 starts low, upon reset, but goes (and stays) high as soon as the boot title screen pops up... even before the disk is read, so before the os is loaded, and long before the logic analyzer software is loaded...

    This seems backwards to me... certainly itit'd be more logical to use the default character set for boot, then switch charsets when loading

    An easy change... for a designer... and another thing leading me to think this guy's a prototype (or they ran out of energy for such a simple change... with the assumption few people would be using a $4000 logic analyzer to play games?). While the change would be simple, it would require modifying both the bios and (and any other related software)... so I can see how a backburner idea like that might've been abandoned...

    So... since a12 isn't used on the 2732, and since the 2732 only contains the custom charset, the machine thinks its accessing the custom charset (immediately upon boot and always thereafter) in the higher address space of a 2764... but it's really wrapping around and accessing the lower address space, which is fit in a 2732. 

    So I guess... if this were something I cared to fix, like if i wanted to play games on this thing, I could load the custom charset in the higher addresses of a 2764 and the regular one in the lower space, as designed... then I'd need a utility to switch to the normal charset every time I wanted to play a game... which would mean not being able to just boot off any floppy.

    Or... I could swap it from the presumed-intended design... have the custom charset in the low space and the normal one in the high space... this'd mean having a utility run before the la software to switch to the low space. Could do that in some sorta script, right?.. completely goofy, but a solution that would allow normal disks to boot with the normal charset.

    Now... what if there are games, etc. That expect their own custom charset..? Or, maybe weirder, what if some programs reset to the default charset when starting... Who knows.

    It definitely looks, though, as if this charset swapping is a thing designed in kaypro 2x's... not limited to the omni 4... but am guessing the choice to set a12 high in the bios is specific to the omni4...

    Anyhow, a curiosity.


    Probing: A12CH appears to be connected to U58, PIN 16... heading back to the schematic... yep... there it is, sheet D just as it says... dunno how I missed it before.


    Replaced the second 5.25in drive with another 3.5... MUCH easier, now, to try out other software... (looking into something that'll transfer the disk contents faster and reliably for viewing on a newer computer).

    Not sure where I stand with this thing... I'm starting to get hackish ideas... that can't end well... and... could be done with a normal kaypro, anyhow...

    (Seriously: installing a soundblaster has crossed my mind a couple times... maybe I'd better get this thing out of my sight ASAP... I can do stuff like that with #Improbable AVR -> 8088 substitution for PC/XT instead of frankensteining one of the last of an endangered...

    Read more »

  • Serial Transfer

    esot.eric09/18/2017 at 00:26 19 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.

  • ROMulus and Remus; a tale of two EPROMs

    ziggurat2909/15/2017 at 16:02 8 comments

    A couple days ago Esot.eric dumped the two EPROMS on the board, U9 and U32.  I spent a little time with those images, and Esot.eric suggested I share my findings thus far (there is much more to go, but that will take several days work).

    U9 is the character generator ROM, and U34 is the 'boot' ROM.  Why the quotes?  Well, we're pretty sure it is more than just the boot ROM.  For starters, a boot ROM would not need to be 8K -- 2K would be more than sufficient to init the system and load the second stage loader off disk (and indeed earlier Kaypros did have a 2K boot ROM), so the current thinking is that it contains other subroutines that are of use at runtime.

    The Kaypro is a CP/M machine, and those familiar with CP/M will know that one of it's quirks is that it requires RAM at the bottom of memory.  Yet 0000h is the reset vector for 8080 and Z80 (for which CP/M was created), so you've got to have ROM there at least during boot up, and that generally implies some sort of bank switching to get it out once you've gotten past boot.  So far, so conventional.  Also interesting is that the ROM does not reference any RAM locations below 8000h (even though this one is only 2000h long), so it seems that Kaypro had plans to possibly expand this ROM-based subroutine approach in future models, and set up their codebase accordingly.

    I'll cover the disassembly findings in a subsequent post in more detail (i.e., when I have details to post!), but some interesting things have come out already with a cursory scan:

    1. there are some peculiar register addressings related to video
      The video is mostly controlled by the then-popular MC6845 (or clones).  This chip has 18 registers, and is interfaced through two physical addresses:  the first is the address register selecting which of the 18 internal registers is being operated upon, and the second is the data register that is mapped to the selected register.  So far so straightforward, but I noticed in the code many times accessing of a register 1Fh, which does not exist on the chip.  Blargh!  My mind is boggled.
    2. to add confusion to befuddlement, there is a physical port 1fh that is routinely accessed in the (ostensibly) video driver code.  But this one I think I have more of a handle on:
      The video memory on this unit is composed of two 6116 static RAMs, 2K each.  Hmm, this device has an 80x25 display, which is 2000 characters, so why do we need a total of 4K?  Hypothesis:  attributes.  8 bits for character data, and some more bits for things like high-intensity, inverse video, etc.  Some of Esot.eric's screen shots show that these capabilities are there, so we know we need the extra bits.  Also, the 6845 is essentially a fancy address generator -- you still have to implement circuitry to shift out pixels and blend in sync pulses and whatnot.  So, the video memory is typically being addressed and controlled by the 6845 on a continual basis, and not mapped into the CPU's direct address space.  But something's gotta let us write data into video memory!
      There is a gate array in this machine (actually two).  Since it is a custom chip, it is a black box from the standpoint of analysis, and could be doing anything.  So, my hypothesis in this case is that the port 1fh is decoded by the gate array, and is used to access the video memory to write characters into it.  And probably the attribute bits as well.  Much more work will be done in this area.
    3. As was common on many machine designs, the address decoding may take shortcuts by not decoding some bits and thus creating aliases in the address space.  This was typically done simply to save on parts count ($) but was Hell on 3rd party expandability.  This was done here as well, and A6 does not contribute to the decoding of port addresses, and so there are IO aliases of the first 64 ports into the 40h-7fh space.  Fortunately for the rest...
    Read more »

  • Easy pipping, aka to pip or not to pip

    esot.eric09/14/2017 at 02:25 2 comments

    UPDATE: NOPE. See next log...

    ziggurat and I have both been unable to fiigure out how to successfully mount the disk (image) on a linux machine using cpmtools. Seems strange... seems like surely enough folk out there use (d) kaypro 2x's that surely the settings should already be in there. But alas, two folk, no go.

    The idea, then, is to use pip, the peripheral interchange program, to send the files from the booted disk in the booted machine via serial port to a linux (or whatever) machine. Sounds simple enough...

    Unsure how exactly to format the command line, came across this:!topic/comp.os.cpm/f9vzK1OvaII

    Wherein numerous caveats I'd vagued upon are brought up... and several I hadn't considered.

     First... pip does have the ability to send binary files, but how would the receiver recognize the end of the file, when only 8 bits are transferred at a time, and a binary file can contain *any* 8bit value in any location, including the "end of file" byte...?

    So then pip must use a protocol for the transfer, like xmodem, right? Well I don't see that in the manual, it looks like it isn't that sophisticated. Then raw binary transfer... I guess I could have a timeout... or maybe the handshaking lines... dunno.

    Then that page made note of something I'd glossed over... pip *does* have the ability to convert an input file to intel hex format. BAM.

    Which is also a great idea because:  I haven't found anywhere info on how to configure the serial port... yahknow, baudrate, parity, handshaking... which didn't seem like too big a deal until I happened upon anithher comment at that page... default it 7bit! Well shit... that'd put a serious damper on a binary transfer.

    So yes... I think intel hex conversion will do quite nicely. Built into pip. And crc's to boot. BAM.

  • (TODO!) + ROMs, Good Disk, First Samples

    esot.eric09/13/2017 at 06:55 2 comments

    (TODO: Apparently I set the logic-analyzer board on a scanner way-back when... 350MB files my computer can't handle right now. But maybe they show some now-unreadable chip-markings. I do remember, now... my scanners weren't too happy with the three-dimensionality of the thing. But who knows... Next time I free up a couple gigs for temporary files, I'll try to remember to look at 'em, and maybe upload. And now I recall why I was so excited to spend $300 on a student's wage to buy a SCSI scanner I did a lot of researching for, way back when.)

    Two EPROMs exist on the KayPro motherboard (none seen on the Logic Analyzer board). U9 and U34, different sizes.

    U9 seems to be the character-generator ROM (likely once labelled "K2xCHAR", though the sticker has been floating in the case).

    U34 seems to be the boot-ROM/BIOS...

    Funny it mentions CP/M in the ROM... because that message doesn't come up until the disk loads.

    The ROM images are now in the "Files" section.


    "Burnt" new disks (several, infact). Turns out the first diskette was corrupt. The image burnt without errors numerous times thereafter.

    Now I can run D.COM:

    yeahp... I ran that once before and forgot... basically just a little more sophisticated than "dir"

    STARDNLD.COM still just freezes... anyone know what it might be?

    I think the majority of the rest of the files are actual logic-analyzer samples and/or configurations... but I have yet to look into them.


    On to sampling!

    Only one probe is labelled... and the other seems to have different heatshrink...

    I had to look inside... (I'm guessing someone else did before, as well).

    Huh... This thing supposedly does waveform generation, but I don't see that happening with 7400's at the probes. Maybe they require different probes.

    I set up the logic analyzer pods to read from a few pins on what I think to be the video-controller and discovered an interesting error message:

    "External clock does not generate waveform"

    This message occurs when the cables are near other circuitry... or when the cables overlap themselves. Lotsa testing happened... Apparently we've got some antennas.

    Re-ran the cables away from other circuitry, and now we have waveforms!


    Gotta cut my laptop-usage short... thing eats through the battery, gotta leave the engine on to use it longer than an hour-ish, else I'll need a jump-start tomorrow.

  • Mounted, etc. And a Kaypro question.

    esot.eric09/12/2017 at 09:32 4 comments

    opening and closing the case every time I want to work with the thing is getting tiresome... but space and the necessity to "batten down the hatches" requires its full assembly when not in use. so mounted a 3.5in drive in place of the original 5.25... took a while to find the right drive for the job... and had to resolder the drive-select jumpers. But it's just a standard 1.44mb drive and works... no other jumper changes required.

    Had a brilliant idea to mount the original drive inside so it can't get misplaced... went through all the racket necessary (reopening the case, removing the PCBs, mounting the thing, making sure it was secure for transport...

    Friggin thing fit perfectly. Then put the PCBs back in.... and dag nab if it wasn't 1/8th of an inch too high. So the original drive and the kaypro may both be suffering separation anxiety.  I kinda am as well.

    Ran some experiments while it was open... tried running the logic analyzer program with the board disconnected. Definitely failed all self tests. 

    So looks like the LA board is functioning, despite not having sampled any data yet. Also, it detects that I hadn't yet attached the probe-pods. Smart cookie.

    Also experimented with the other programs (?) has a sector error. And recall that there were a couple failures during the write-process... so may just be a flaky disk. (?) just freezes...

    But apparently turns the thing into an eprom programmer (with the right personality modules... which of course I don't have) turns it into a pattern generator... 16 channels? is the logic analyzer is the cp/m program for peripheral intercommunication (basically xcopy or dd, if I understand) makes for a nice UI.

    And here's a full listing of all the files... since two folks, now, have been unable to mount successfully with cpmtools...


    Other notables: "Omni4" is printed on screen in many locations... once before reading any disks, so this must have a custom ROM, rather than the standard Kaypro 2x ROM. Got the eeprommer running with the 486 lappy (man it's way easier to use floppies than my original plan to use xmodem) and waiting for my next patience with case opening, etc. 

    Thanks to my new pal ziggurat for bringing the custom ROM and more to my attention.

    Also cp/m appears to be customized.

    But we're pretty durn certain this is a kaypro 2x.

    Also... the 3v battery (over 30 years old) has 2.73v on it... so if anyone knows how to read things in the nvram and/or date/time on one of these things, we're curious what it's been holding onto all these years.

View all 35 project logs

Enjoy this project?



ziggurat29 wrote 09/06/2017 at 21:46 point

minor point since I was just re-reading your logs (to download some of the blurry board pics for comparison):  'denatured alcohol':  it's alcohol that has toxic stuff added, so you can't drink it.  (Otherwise it is ethanol, which you could drink, but then there'd be tax and whatnot on it).  The stuff they add is wide and varied.  We used it as kids for the alcohol lamp in our chemistry set.  You can probably use it just fine as a solvent, too.  But 'maybe', because as I said, the particular denaturant used is vendor-specific.  Usually it's methyl alcohol, though, so you'd be fine with that.

  Are you sure? yes | no

esot.eric wrote 09/07/2017 at 05:15 point

Stupid phone deleting responses.

Thanks! Methyl is the claim on the label. I'm no chemist, so your word is helpful.

Photos... I'll definitely be taking better photos and documenting the major chips... may be a bit since it's assembled finally...

Something specific?

  Are you sure? yes | no

ziggurat29 wrote 09/07/2017 at 14:38 point

Truly, I was trying to get a better handle on the unit's specifics in advance of attempting to disassemble the software on your disk image you so meticulously restored.

I am currently guessing this is a 'Kaypro IV'.  Kaypro's numbering was confusing; there was a '2' and a 'II' and a '4' and a 'IV', which were quite different.  E.g. the 'IV' ran a 2.5 MHz, and the '4' (release less than a year later) ran at 4 MHz.  The 'IV' and '4' had significantly different electronics designs (as I understand), but the 'IV' and the 'II' were electronically similar, apparently differing in the upgrade of the DSDD drive.
I did find a schematic to the 'II', but not the 'IV', so I'm hoping those similarities hold true.  I also found a manual for the CP/M for that unit, but not for the various 'Perfect Suite' apps that shipped with it.  And of course not the Omni4 manual (do you have that?).  (I can send you all these docs, of course, if you want them.)
Anyway, don't go out of your was to take it apart again, but it would be useful to verify some assumptions at some point, so let me know if you have plans to re-open and I can send you some more pointed questions (or I'll just formulate some anyway and send those to you for future).
Lastly, it seems there is coincidentally a guy in Oregon (I think) who also recently found one of these units, albeit the prior model (Omni2?), who alas does not have floppies or manuals.  What a weird coincidence!

  Are you sure? yes | no

esot.eric wrote 09/08/2017 at 00:44 point

Mr. Gung-Ho!

Alright, I'll throw more energy in trying to document this thing... I have to open it up for the latest floppy-endeavor, anyhow.

I *think* It's a Kaypro 2x (?) But I'll get on figuring that out as well.

No manuals, but the help file is full of info (except, now I recall there's a section that says "to be completed" or something... more in favor of its being a prototype?)

Ah, right... it's *difficult* to read these files without knowing the model-number/OS since they all use different methods of storing the files... I gave up at that point, managed to get a directory-listing via a linux-box I think, but not sure I ever came up with the right combination of 'mount' settings to access all the files...

Interesting about the Omni2, link?

  Are you sure? yes | no

ziggurat29 wrote 09/08/2017 at 02:07 point

Oh yes, I'm quite serious when it comes to disassembly.  It's a bizarre fetish of mine -- I don't know why, but I find it very relaxing.  Maybe it's the same thing that impels some folks to fiddle with watch mechanism.

Anyway, this is your project of course, so any looking you do is purely a bonus for me and don't derail your other plans my account.  I currently have some trouble with the disk image you placed in the 'files' section.  It's probably something I am not doing correctly in reading it -- I can read the directory, but I cannot reconstruct the files.  I sent a more detailed explanation via PM (figuring most folks would prefer my not polluting your discussion area with longer messages).

Upon revisiting the Omni2 inquiry stumbled across yesterday, I now see my memory failed me and that it was not so recent: 2013.  (But in the 34 years since the unit was current, what's 4 years?)


  Are you sure? yes | no

ziggurat29 wrote 08/31/2017 at 23:12 point

Could your PCB mess you were dissolving with alcohol be a conformal coating?  It was popular in the day.
Pity the board picture in your mar 30 post was blurry (I know, I have the same trouble with phone cams), but I'm assuming its a Z80 board.

  Are you sure? yes | no

esot.eric wrote 09/01/2017 at 05:03 point

thanks for reminding me of that post... lotsa comments there regarding what that coating may be and how to go about solving the mess... not sure where I got the idea it's lacquer. Funny thing it's only on the logic analyzer board but not the motherboard.  The logic analyzer board doesn't have a processor... just a couple DMA controllers, as I recall. The motherboard is z80.

  Are you sure? yes | no

ziggurat29 wrote 09/01/2017 at 14:07 point

It seemed unusual to me that unusual that it would be used at all, but I suspected that it was just a common practice with the assembly house they used. Now that you mention it is only on one board, I'm not so sure.

Conformal coatings were typically used to control things like dielectric and to avoid ambient humidity being absorbed into dust and changing resistances (in very high impedance circuits).  It was particularly used on analog boards.  Maybe they were being defensive on the IO board design.

Anyway, if it is conformal coating, you probably can scrub away with impunity and a toothbrush, but I certainly leave that decision to you -- you don't want to break your toy!

Also, I myself have a bit of a fetish for disassembly (and in particular Z80 since that is what I cut my teeth on).  If there are any boot roms, or programs on that disk that you would like disassembled and commented, let me know.

  Are you sure? yes | no

esot.eric wrote 09/02/2017 at 05:22 point

wow oh wow! Disassembly of something like this could be quite something! I have no idea what I'd use it for, off hand, but that could be quite handy. If I understand properly, it uses a typical k2x bootrom, if so the application is the special part. 

Was half-tempted to bring it outta storage for something to fix up... and allegedly it only takes 65W, so could run off my inverter. Now the temptation is stronger ;)

Got me thinking... if the powder from the coating isn't a problem for functionality, it's probably best left alone, should anyone ever be interested in tracing out the circuitry... rather than risk ruining any markings on chips... then if the coating itself is blocking a marking it could be spot-cleaned... ugly, but maybe better than risking further damage.

And you probably got it... the board house probably did it... the other boards seem to be standard kaypro stuff... and otherwise the omni4 stuff is just a sheet of aluminum and a custom painted case... of course the omni4 crew wouldn't make *everything*, now that you mention it.

Kden... it's settled, I'll take the blasted thing on the road!

  Are you sure? yes | no

ziggurat29 wrote 09/06/2017 at 15:09 point

OK, well I see you did post the floppy image.  I'm not sure what format that is in, but I'll study it.  I /should/ be able to reconstruct the files from it, sector-by-sector, if I can gain an understanding of the CP/M file system (which I'm sure is documented somewhere).

Anyway, if I can do that, then I'll try some disassembly.  I'll certainly have to ask you about electrical stuff along the way, since I don't have the physical box to study.  Hmm, I should probably search for a Kaypro schematic -- that might exist somewhere, and would save some trouble in figuring out the standard stuff.

  Are you sure? yes | no

Greg Kennedy wrote 03/29/2017 at 15:44 point

Well done!

So... when are you building the Floppy Disk Emulator, to store the image on flash and serve it entirely solid-state to the machine?

  Are you sure? yes | no

esot.eric wrote 03/29/2017 at 23:59 point

You know I thought about it... They do already exist, though... ;)

  Are you sure? yes | no

Dr. Cockroach wrote 03/29/2017 at 08:34 point

Oh boy, Blood, Sweat and Tears. You should win something from the contest for all that effort if it was up to me :-) There must be

many older systems out there that need that kind of love and attention to keep them going, Great Job :-D

  Are you sure? yes | no

esot.eric wrote 03/29/2017 at 08:58 point

hahahahaha... I dunno if I've got that in me... I like the concept, it kept me going... I even thought maybe my unknown-calling was as an archaeologist. But boy was I ready for that much-needed sense of completion! but... "I wonder if..."  ;)

  Are you sure? yes | no

Dr. Cockroach wrote 03/21/2017 at 19:45 point

Hey there eric, Man you have put in a lot of work on finding those sectors, I know that I could not have stuck with it as you have :-)

  Are you sure? yes | no

AVR wrote 03/03/2017 at 12:35 point

what a sick find dude!

  Are you sure? yes | no

esot.eric wrote 03/03/2017 at 20:18 point


It was given to me many years ago from an old boss who I think had it for many years prior without probably ever having used it. I just turned it on for the first time a few weeks ago, having figured the floppy-disk would've been long-ago corrupted to the point of unusability. Turns out the darned-thing booted right up into the program without a hitch! 

The only hitch was when I tried to make a backup of that floppy... which I've been doing for the past three weeks(!)

  Are you sure? yes | no

Dr. Cockroach wrote 03/03/2017 at 12:00 point

Man oh man, that brings a few flash backs to me. I had a KayPro II quite a few years ago and the disk system never stopped working. But yea, better get a backup made asap :-)

  Are you sure? yes | no

esot.eric wrote 03/03/2017 at 20:28 point

This is my first KayPro and/or CP/M endeavor... But the machine is surprisingly robust. And, surprisingly, given its age, still useful.

It's reassuring that you had a good experience with the disk-system. I've been a bit hesitant to believe floppy-disks/drives can be in any way reliable, and have been proven wrong on several occasions with this system. (Seriously, the heads were clamped on the disk while the thing had been lugged-around and stored for decades, and it booted right up!)

If it weren't for the fact this appears to be a one-of-a-kind floppy (can't find any images, or even mention of *users* on the interwebs), I'd be tempted to just use it until/if it wore out. But, yeah, probably shouldn't do that when it seems to be the only one in existence.

I think you're right, this appears to be a relabeled/modified KayPro II.

  Are you sure? yes | no

Dr. Cockroach wrote 03/03/2017 at 21:17 point

Hello again, Just my three cents but I would just keep it the way you got it. I know how it is with the cord for the keyboard, the Kaypro II was the same just not CP/M. If you ever tire of it I sure would not mind providing it a good home ;-)

  Are you sure? yes | no

esot.eric wrote 03/03/2017 at 22:31 point

Awesome! I'll definitely keep you in mind. And I've no doubt you'd give it a much-better home/purpose than I. I'll likely be getting back to #sdramThingZero - 133MS/s 32-bit Logic Analyzer sooner or later... once that thing's functional, I'd probably just be putting this guy back into storage. Though the thought of having a logic analyzer to work on my new logic analyzer is slightly appealing, if you can wait for a while :)

Glad you spoke-up about the keyboard. It's an annoyance, but I can imagine a modification like I'd attempt could de-value a vintage.


Hah, I just remembered I have *another* logic-analyzer (peripheral) which I tried to back-up its floppy-disk a while back with errors, as well. I'll look into that one next, maybe this guy'll be available sooner than later.

  Are you sure? yes | no

Dr. Cockroach wrote 03/03/2017 at 22:54 point

Hey, that's cool beans Eric :-) Take your time but I do like the older systems. Kinda why I am building IO Lol 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates