Nearly a decade(?!) later...

I have a use for this machine, as-designed!

#M-740 Reverse-Engineering And Hacking Adventures has me wondering about how that machine's two MELPS-740 (6502-derivative) microcontrollers communicate (and why!)...

So I thought I'd dig out the ol' Omni4, which was made in the same year.

It took a tiny bit of effort to get the Omni4 booted, mostly consisting of acknowledging that my A-drive is flakey. Swapping it out with B did the trick, and I started reading the online help to figure out a triggering scheme.

I ran some really simple tests, just toggling a pin between its internal pull-up and ground... Seemed to work great!

Then I read [most of] the manual, which is thorough, and was so-generously scanned by a fellow I met through here years ago. (mine didn't have a manual).

Interestingly, the manual mentions at least twice that the disk should *not* be inserted during power-up, and *should* be inserted when the drive light is on. The claim is that CP/M is notorious for creating bad sectors if the disk is in during power-up/down.

As @ziggurat29 pointed out, this is probably more about the drive-electronics and electrical glitches than about CP/M, but either way, the Omni4 manual makes a big point of it twice.

I certainly had never worried about it before...

All those years ago when I backed-up its disk, I'm pretty certain I treated the machine more like I'd always treated a PC, when intending to boot from floppy, and put it in *before* power-up.

Aside from tgat, as surely I mentioned in the early log-entries here, when I dug the OMNI4 outta storage that first time, after numerous moves, I discovered its disk had been clamped in the read/write heads for easily the decade I'd had it, and possibly most of the decade it went unused before it was given to me... And... It booted as soon as I powered it up. And... Of course I went through several power-cycles at that time with the disk in...

Maybe that's part of the reason I had such difficulty extracting the sectors... Maybe a power-glitch toggled an MFM-encoded bit, somewhere...

So weird how that went... I tried *numerous* methods to try to recover the data... Oh the months... only eventually to essentially give-up and just run a script to repeatedly read each sector as many times as it took to get a valid checksum. I *really* did *not* expect that to work, but it did. Sheesh.

So, I suppose, maybe, in the realm of MFM-encoding, it's plausible such a power/write-glitch could've occurred *anywhere(s)* on the disk surface... including, plausibly, somewhere *mid*-"bit".

What would that mean, then? Well, *plausibly* since there's a clocking-reference at the beginning of each sector, and no guarantee of a clock alongside every "bit" thereafter, and thus a PLL is necessary to keep that clock ticking during the remaining "bits"... it's *plausible* that every time a sector is read it might actually *sample* the mfm-encoding (flux-transitions) at very slightly different timings... And maybe after a hundred tries it just happened to sample *past* or *before* the "glitch*...

I think I can see how it's feasible, anyhow. Especially with glitches that might occur in one bit-level vs the other... because, as I recall (was it bit='0'?) the *data* encoding is officially something like <flux-change, no-flux-change> but *also* is sometimes encoded as something like <no-flux-change, no-flux-change>, wherein the lesser-common encoding is especially used during the PLL-clock synchronization pulses *before* the data...

Hmmm...

So, I guess the point is that a single flux-transition might get mangled (or inserted?) in a sector, and it *might* be possible to read the data correctly, on random-ish occasion.

That *could* explain why the "brute-force" "just keep trying" approach eventually worked. Maybe... Heh!

Whoa, sidetrack.

Anyhow,

Yesterday I was stoked to see something, so hooked up the probes (for my first time?) to some circuitry... and... "bad sector."

Oddly, *after* I started being cautious about *not* having the disk in during power-cycles.

And, dare I note that there was no bad-sector (at least at that point in the program's loading) there the night before, nor the near decade since I wrote that disk? Heh.

(Thank Goodness I *did* go to all that effort backing up the original all those years ago! Now I guess we'll see how good my documentation is for writing a new disk).

.....

In other news:

I'd given-up on using the 5.25in drives that came with the machine in favor of 3.5in. This was such a weird discovery... because, surely, it would've become a common hack! It's almost that they *designed* 3.5in drives *to* be drop-in-compatible with 5.25in drives...

If I plug a 1.44MB drive in place of the old 390(?)KB drive, then use the old 720KB 3.5in disks (or put tape over the 1.44MB hole), it works fine-n-dandy.

As I recall the only jumper-change necessary was due to the weird PC-style Drive-Select scheme (with twist in the cable).

The key points were that A) my 5.25in disk stash was running low, B) I didn't have a spare low-density 5.25in drive to put in the PC (1.2MB drives weren't writing disks reliably-readable on the low-density drives) and C) I needed to use a laptop to image disks... Compatibility with available tools.

I'm *really* surprised how rare it is to find folk who replaced those 5.25in drives with 3.5in!

....

OK, so today's challenge...  

The 486 laptop I'd been using to image disks is in sad shape. (rabbithole 3A).

I've got precisely *two* tower cases, one containing #Improbable AVR -> 8088 substitution for PC/XT, the other containing a hyperthreaded P4... 

And... The OMNI4 used some trickery to fit an extra sector on each track that newer PCs' floppy controllers are known to seldom be capable of working with.

I've got a box full of old motherboards, I think, still, if they made it through the last move... But that box *was* "dead" boards, where I had previously found a functional early pentium for this task, but apparently that machine did not make it with the last move... Abd, again, am I gonna go caseless?

...

Anyhow, thankfully it seems I still have a few 3.5in drives that might help.