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).


Omni 4 disk image, FINALLY! Use ImageDisk from: And PLEASE contact me if you use this... OMNI4 users seem sparse, to say the least! eric waz hung at gmail dot com

- 353.86 kB - 03/29/2017 at 07:42


View file

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

  • State of the Home Address

    esot.eric03/30/2017 at 06:06 4 comments

    "Sorry [about requesting your engineering skills]" -- Dax

    "No problem, it'll be nice to be working on something I can *solve* for a change." --Chief O'Brian (DS-9). LOL... right?


    In the process of preparing for the return of my guest-couch... (which, most-likely, will wind up collecting the things currently occupying my bed, which has been relegating my sleepage, workage, and cat-lovingage to the other couch... both of which are really just "love-seats" not nearly long enough for sleepage (or even two non-loving people to sit in a non-loving way), despite being used for the purpose of sleepage for weeks, despite there being a friggin' bed right next to me)... And in preparation for the return of the possibility of having guests!... I cleared off the "plank" that is the work-bench I've been using for the KayPro. It also managed to store some paperwork and other things I need to not displace, presently. So, in that cleaning-process, those things wound up on my sleepage/workage/cat-lovingage couch... *temporarily*... And the KayPro's guts were *temporarily* strewn across the plank. Which would've been fine, if this stupid thing was reassembled at the end of today, as I'd originally planned. But now, at reasonable-sleepage-hour, I must sit upright (or stand) in every location in my home that could be occupiable by a human body. Actually, I might be able to lay-down in the hall, feet in the bathroom, if I move a thing or two...



  • Probably shoulda left well-nough alone...

    esot.eric03/30/2017 at 04:23 17 comments

    UPDATE: Ponderances of what happened and where to go from here at the bottom


    Some things were necessary... the Power-Supply PCB was held down by only two of the four screws, and the two worst-placed ones. Nearly every screw in the machine is either loose or missing.

    Wherein we get down to the logic-analyzer PCB... which has a few corroded solder-joints. Alright, I'll fix 'em.

    Now there's some sort of white film all over the board... could that be coming from my rubbing alcohol? A mix of that and the flux? A mix of those two and whatever weird clear coat was covering all the chips? Did I forget to rinse out the old toothbrush thoroughly enough? Alls I know is the more I try to clean it, the more it appears. Finally down to literally pouring alcohol over it, and... it's worse.

    WTF. I've done my share of PCBs in my years... Alright? I mean, I hand-soldered custom PCBs for a living for years. And I've worked on countless repairs just like this... I've never seen anything like it.

    It's almost like there's salt mixed in there. How the hell. 91% IPA. I've never dipped anything in it that wasn't clean (q-tips), and always poured a little into another container when I needed to reuse tools/brushes/etc that could dirty the solution, and disposed of the remainder; certainly never poured it back in... I use this same bottle for wound-care fergodsakes!

    Again, this was supposed to be a one-day job. Tighten screws, resolder a couple, joints fergodsakes.

    This system is possessed.


    Update: Here's my understanding of what happened:

    Since I originally used the alcohol to clean up my flux only where I repaired some joints, I initially thought it was some reaction with my flux (which would've been weird, since I've done it that way on boards in the past), the flux they used originally, and maybe whatever corrosion was there. So I kept adding to the alcohol-spot-cleaning, and in a few places I think it cleared up. But, the white film seemed to expand outward in a ring/spiral... so I figured I was just pushing around the white-film outward in a spiral, and really needed to flush it off the board completely. Thus pouring the alcohol on the board, rather than brushing it around, and finding out that whatever's responsible appears not to have to do with the corrosion, nor the flux, but a chemical reaction with whatever clear-coat they put on everything(?)

    The film itself can (for the most-part) be wiped-up, e.g. with a dry Q-tip. But that doesn't help between pins, etc. where it's particularly nasty-looking like it's going to short everything out. Adding alcohol makes it appear clear, again, but once it dries, it's all white.

    I found this forum:

    wherein someone suggests that the alchohol is leaching the plasticizers out of the laquer(?!)... That page is a mess of random-stuff, not at all dedicated to the topic, so I suppose I should look into how to clean leached-plasticizers, and whether I need to worry about the leaching-process having introduced conductivity...?

    I'm definitely hesitant to use water to rinse it off, since it's corrosive and may have other things in it (salts) which are conductive. So, then, I suppose distilled-water? (Can I make that with the supplies/tools in my kitchen?).



    esot.eric03/29/2017 at 06:34 5 comments


    So check-this...

    After the last experimentation trying to access the image-file via cpmtools, I was somewhat convinced the image-file is right. Though, I wasn't able to figure out the *exact* specifications of the high-level disk-format (these things the ROM and OS *on the disk* would know, but have to be specified by the user if using a different system), I was able to extract some files via 'cpmcp' and they seemed mostly-alright. Again, the specific settings I don't know (skew, block-size, etc) are things actual system would know... so if I have the image written to disk properly I don't need that information to use the disk in the system it's designed for, only if I want to use that disk-image on *another* system.

    So, since I was able to [mostly] browse files (and a few other things including hexdumps of the image-file), I figured the disk-image *must* be right. Right?

    So why didn't it work? Last attempt was using gap-sizes that worked with a different disk-image, downloaded off the 'net, so it shoulda worked, right?

    So, now I'm writing a whole bunch of floppies with the image I made... using different gap-sizes... Then I'll plop the drive back in the system and try 'em out until one works...

    But then I notice something weird...

    WTF... it's writing sectors 10-19 on Head 0 (and 0-9 on Head 1)!

    ImageDisk has a utility 'bin2imd' which takes a raw binary file containing all the sectors of a disk and allows you to convert that to the IMD format... What I did with the raw sectors, of course, was to 'cat [eachSector] >> image.bin' (in order) then used 'bin2imd' to create a floppy-disk image.

    You can imagine, bin2imd needs some options, to indicate the sector-header information, etc.

    So... turns out the sector-map options are *reversed*. If you say "sm0=0-9 sm1=10-19" you'd think the sectors on head 0 would be numbered 0-9 and those on head 1 would be 10-19, right? Wrong.


    And now it works. And I can finally reclaim my couch and maybe even my coffee table!


    The sectors aren't interleaved... it's noticeably slower than with the original disk. We'll see if I have the patience to change that... but that's just a matter of options with ImageDisk (and swapping the drive between machines, which I've tired of, or finally figuring out how to use a 1.2MB drive).

  • promising...

    esot.eric03/29/2017 at 00:09 2 comments

    Maybe I did *something* right... so it's just a matter of MOAR EFFORT, right?



    This covers basically every file.

    ...(except LA.COM? Hmmmm... as in the Logic Analyzer application? Hmmmm....)

    Ah, no... would seem I've messed *something* up...

    used cpmcp to copy all the files to a directory on my main computer... and... this is a text-file:

    which seems to contain, at the beginning, an assembly listing, followed by an empty sector, followed by possibly machine-code from an executable, followed by a help file.



    "I wonder if..."

    If I understand correctly there are several different interleaving-methods...

    The obvious one is on-disk, wherein the sectors are out of order (so the disk-controller can read e.g. sector1, then process it, then by the time it's done processing it, the disk will've spun around a few sectors... so instead of putting them sequentially, they skip a few so sector2 will be close to the head when the processing of sector1 is complete).

    But, also, there allegedly exists *software* interleaving... which I suppose could exist at the ROM-level, the OS-level, or any number of other places. Hmmm... In which case, I guess, if the software was accessing what it would consider sequential sectors, it might remap the requests to *different* sectors... so it might want sectors 1 and 2, but then remap those to sectors 1 and 6, so it's actually requesting, from the drive, sectors labelled on-disk as 1 and 6, regardless of the physical order of the sectors on the disk.

    Thing is, since that's software-level, it should have no effect on whether my image, burnt to the floppy, is in or out of order as far as the numbering of the sectors on the disk. So it may help to know the software-interleave for using tools on my linux machine, but that has nothing to do with why the disk I wrote didn't work in the actual machine.


    And... what's up with this file called emo.lap with the first character in its name being 0x03? I've verified that the sector containing that file-entry was read without CRC-error *numerous* times.

  • well schnitzel

    esot.eric03/27/2017 at 23:53 7 comments


    one of those things where I coulda sworn it'd be done in a few hours... and...

    All the sectors have allegedly been extracted, without CRC error.

    Each is in its own file on my computer, named to match their sector-IDs.

    (800 files!)

    So, now I've merged them all into a single file using 'cat sector >> binaryImage'

    --Yes, I verified 'cat' works correctly with binary files--

    Then I used image-disk's "bin2imd" utility to rewrite that binary image into an ImageDisk format (containing sector ID information, etc.)

    Then I set the format-gap to 23 (which is how many 0x4e's, on average, that I read between each sector)

    And the write-gap to 12 (because...?)

    Then I wrote the disk using ImageDisk with nary a complaint.

    Then just to be safe I read-back the disk, with nary a complaint (so no data-overlap despite the tiny gaps, otherwise there'd be CRC errors, right? Maybe I should check that file).

    And... plopped the disk (and drive) into the Omni4

    And... nada.

    Just sits there spinning the disk... Which is apparently what it does until it finds the boot-disk.


    alright, minor break, then I'll verify that file was read-back with no errors (might even be able to diff 'em?)

  • Time to shift gears?

    esot.eric03/22/2017 at 19:33 0 comments

    UPDATE: No, really this time! See the bottom... And more pondering on how to write the new disk...


    I think I got 'em all, now...

    There were a few questionables... some tracks that had multiple identical sectors... would make sense e.g. if those sectors were unwritten (after format). But, then... there're a few that're filled with 0xff, a few filled with 0x00, and a few filled with 0xea (or something similar).

    These are a bit difficult to be *certain* are properly-IDed. But I think I verified it pretty well.


    Negative sector-IDs indicate data was found *long after* the alleged sector-ID... so most-likely is data associated with a *different* sector-ID which wasn't readable with that search-method.

    Sectors with allegedly 1024 bytes are most-likely wrongly-read Sector IDs (which is verifiable with the mismatched ID-CRC). So, then, the corresponding data-CRCs are prefixed with the location where a CRC-match was *actually* found. Thus, 0x27d39 indicates a data-CRC of 0x7d39, and an "N" value of 2. (N is a sector-ID mark indicating sector-size... (128<<N).. so 2 indicates 512 bytes.

    Alright... The last column indicates individual sector-extractions which were done previously (now weeks, if not months, ago)... These only exist if the floppy-disk-controller reported no-error (in either ID-CRC nor Data-CRC). If their CRCs match that reported by *this* extraction-attempt, then they're marked "OK". If they were found, previously, but not with this attempt, then their CRCs are in that column.

    ... So... in this example... we've read a CRC-matched Sector ID indicating sector-zero, with a verified data-CRC of 0xda6e... That one's a bit questionable, as other sectors also have that data-CRC. BUT that data-CRC matches that of a sector which is filled with nothing but 0x00. So, it could be an empty-sector.

    The only remaining questionable-bit is the fact that the ID-CRC is prefixed with 1.

    That happens when a sector-ID is matched with that on-disk... BUT... the address-mark, which is usually 0xa1 0xa1 0xa1, was read as 0xe1 0xe1 0xe1. This *could* be a quarter-bit-shift issue... But, again, I haven't *fully* wrapped my head around that. But what that 1-prefix indicates is that the ID-CRC was calculated *assuming* 0xa1's, but the program read 0xe1's. Well, if the 0xe1's were in-error, then how are we to know the ID itself wasn't in-error, as well...?

    So, some amount of uncertainty, but I did my best within my understanding to verify that it's *unlikely* I'm mistaken... I had to do similar with numerous missing-sectors, and most were much easier to discern (e.g. they had *different* matching CRCs than every other verified sector, so therefore *must* belong to the only missing sector... right?)

    So... Now... I think it's time to actually *write* the new disk. I have no idea how to do that, yet.


    Some things I'm still ignoring... sector-interleave... I'll probably write all the sectors in order, for now. It looks to me like they're *not* written that way on the original disk. They write them out-of-order so that they can be read-back as quickly-as-possible, while taking into account the facts of processing-time for each sector, and the amount of time it takes for the disk to spin around to the next sector. Clever, for the sake of speed-improvement, but not required (right?).

    ...I think that's it.

    I might experiment with fudging some of the characteristics... E.G. there's a "gap-length" of only 16 bytes after the index-mark. And yet, there's 190 at the *end* of the track. And, if the thing I read before is true (that IBM-PC-compatible disk-controllers fail on sectors too close to the index-mark, which seems quite probable considering the *majority* of my missing sectors were sector-0...)... Then, why not throw, say, 90 of the 190 bytes from the end at the *beginning* instead? Of course, those...

    Read more »

  • Gotta Catchem All!

    esot.eric03/21/2017 at 23:43 0 comments


    I Caught 'em All....most.

    And my umpteenth shitty-implementation of quarter-bit-shift didn't have anything to do with it (though I thought it did, at first). Turns out the missing-clock-bit argument, which I implemented *long ago* and didn't find *any* new results with in my early-testing had a huge impact on these files (and since it didn't seem to change anything, I never bothered to make it default, but then got so-used to the concept, assumed it *was* default.) So, it *seemed* like quarter-bit-shift implementation was responsible, but it wasn't. Though, in a sense, the missing-clock is *kinda* like (what I've been poorly-calling) quarter-bit-shift.

    And I got *all* the missing-sectors from my list.


    I realized that this whole time I've been working with a missing-sector list that apparently was generated with a script that had the following:

    for((head=1; head<2; head++))

    Yeah... There *must*'ve been a reason for that... right?

    because heads are 0-based, not 1-based... so, it was *weeks* ago, now... I don't recall why I started with 1, but it was probably intentional.

    So, we'll see how many *more* sectors are missing... yahknow, like from head-0.

    I coulda sworn I was going to be *done* hours ago, today... I've been at it since 3AM, it's now 4:30PM.


    The New List: :(


    Whelp... guess I know what I'm doing, now... How many did I start with, today...? less than 8...

  • Quarter Bit Shift Revisited

    esot.eric03/21/2017 at 20:25 0 comments

    Wow... managed to recover all but two sectors without getting the coding right for "quarter-bit-shift."

    Of course, it seems at least one of the two remaining missing-sectors is definitely a quarter-bit-shift issue:

    The floppy-disk controller read three 0xa0's where it should've read three 0xa1's (in the address-mark, before the user-data).

    So, it seems I need to think about this more thoroughly after all.


    In the image it looks like there's only one possible bit-alignment that could *possibly* have happened.

    So, the question is, [how] could this have happened...? Note the highlighted '10'. Again, from the floppy-disk-controller all I know is that it read 0xa0a0, I don't *know* what the MFM-encoding was. And a data-bit = 0 can be represented as *either* '00' or '10' in the MFM-encoding. The *value* 0xa0 wasn't written to the floppy disk, 0xa1 was. So, that means it must've been encoded correctly *for 0xa1* when written to the disk. When reading-back, of course, there may be bit-shift due to misaligned sector-writes... I think I've over-explained this several times already.

    The last time I tried coding this up, I got myself into some trouble... essentially I rewrote *every* 0-data-bit from the floppy-disk-controller with '00'. (via a mask). Then I masked-out *every* corresponding MFM-bit within the search-pattern (0xa1). The result...? 0xa1's representation in the above image, would've been 00 00 00 00 10 00 10 00

    Well, shit, that pattern's *easy* to find... since 0's are all (now) represented as '00' in the string-to-be-searched. The result was, I guess, that it wasn't finding what it was looking for because it'd find it too early, then only match once, rather than the three times it's supposed to repeat. Right, so I need to be a bit more conservative with my pattern-masking...

    And I've been trying to figure out how to do that for well over a week, now.

    My head's just not in coding that up, for some reason.

    But I can *see* the pattern, and I'm pretty certain that's exactly what's happened, in this case... So, maybe I can at least code-up a quick-fix to handle this one case.


    And, again, I think why I managed to get away *without* handling quarter-bit-shift correctly for so many sectors probably has to do with each track's having been read multiple times as though it was a single sector. So bit-shift in the first pass would likely vary from bit-shift in the next. But not always. Apparently.

    (Oh, and note that 0xa1 isn't actually a proper MFM encoding. There's a "missing clock bit" The sixth data-bit (0) *should* be represented as '10', but is intentionally-neglected in address-marks, *only*. If that wasn't the case it wouldn't match the 0xa0a0 pattern!).


    esot.eric03/21/2017 at 17:46 0 comments

    I've whittled it down to 2 missing sectors!

    My program has a few different search options, now, and running it with one option vs another can find different results. Sometimes it'll find the sector-headers and not the data, other times the data but not the sector-headers.

    So, I've gone through by hand and pieced together which sector-headers belong with which data... and we're down to only two missing sectors (once hundreds!)

    One's a bit more difficult to parse than the other, because it has several sectors with the same CRC (are they blank?) Unfortunately, the missing sector isn't consecutive with those... so looks like I'll be doing some digging, still.

    Oh, AND, some of the sectors once read with CRC errors have been recovered correctly. One very clearly contains part of a help-file... the original extraction with the CRC-error was only legible for the first line of text and the remainder looked like garbage (or machine code). it said: "g diagrams found il dightal data p"

    And now it says:

    So rewarding!


    Hahahaha, it just Burped at me... In Hex!

  • "Quarter-bit shift"

    esot.eric03/20/2017 at 21:12 0 comments

    Update: Therein lies a problem... at the bottom


    I've this running idea that there's actually 4 potential "bit-shifts" for each data-bit. This is a bit funky because MFM-encoding uses *two* bits on the floppy-disk for every data-bit. So, then, half-bit shift makes sense... but quarter?

    Well, I'm using the phrase "bit-shift" a bit loosely, here... but the idea remains the same: that for every *data* bit, there's actually four possible outcomes due to the bit-wise misalignment of sectors.

    I wrote a thing on it, but it's a draft and I haven't the energy now to revise it... but here's an example:

    Note the highlighted bit-patterns *don't* match. But they do, if you consider what I'm (poorly) calling "quarter-bit shift".

    Briefly: the "?" pattern is the MFM-bit-pattern I *presume* to have been read from the floppy-disk (It's not possible to *see* the actual MFM bit-pattern; the floppy-disk-controller returns the *data bytes* it decoded from the MFM-pattern it saw passing under the head). It's the MFM-re-encoding of the data-bytes read by the floppy-controller.

    But there are some key factors... The floppy-controller reads two MFM bits for every data-bit *that it returns*. So, e.g. if the floppy-disk-controller returned the byte 0x01, then there are certain things we do *know* about the MFM-bit-pattern it saw... We know, with some amount of certainty, that the very last two of the 16 MFM-bits must've been '01'. So, those two bits get 1's in the mask. And data-bits that are Zero have two representations in MFM, either '00' or '10'. So, we know, with some amount of certainty, that for every data-bit that the floppy-disk-controller returned as '0', it must've seen either of those two MFM-bit-patterns. So, I throw '01' in the mask, to indicate that the first MFM-bit is questionable, could be either 0 or 1, but the second bit is "known" to be 0.

    Thus, in the highlighted example, the two patterns actually very-well could be the same, on-disk, despite the fact they differ in encoding.

    And, that's a bit more confusing by the fact that in reality, the matching-pattern, if decoded from MFM clearly ends with a bit-value of 1 (the pattern ends in '01') while the pattern I'm searching for (0x4e) ends with a bit-value of 0 (the pattern ends with 'x0').

    But, again, it's not that we're debating what the disk-controller reported. In fact, we're working *within* what the disk-controller reported... It clearly said the last databit it detected (MFM-encoded as the last two bits in that string) is '0' (originally-presumed to have been stored as '10' in MFM). When, in fact, it may very well have been that it detected an MFM-pattern corresponding to the data-bit value of '0', but that it read that '0'-bit from two consecutive encodings of two entirely different actual bits as stored-on-disk. WHEW.

    Thus... I've just added this "mask" feature... and we'll see where it goes. It should *only* apply to half-bit-shifts. Though, also, there's a "missing clock" in certain bit-strings (between sectors) that would present itself similarly, so I think I can reuse this mask feature for those, as well.

    Kinda surprising I had such good luck with the last go-round; managing to extract all but 8 of the (originally hundreds of) missing sectors.

    I think the key-factor is that I requested a *really long* sector-size that allowed the disk to spin around multiple times. Thus, when the bit-shift of a particular sector was off, in the first cycle, by say a half-bit, it might be off by a full-bit by the next rotation, and be easier to detect.

    So, here's hoping when I get this "quarter-bit-shift" thing functioning properly, hopefully soon, that it gets me the remaining sectors and...

    Read more »

View all 15 project logs

Enjoy this project?



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

Adam Vadala-Roth 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