MFM Emulator Updates

[BBMDonut]

Hey, all! I just wanted to give an update on some work I've been doing with the MFM Emulator's core software over the last few months.

For a quick back-story, I started with the MFM Emulator ecosystem a little over a year ago, after seeing a video posted by David over at Usagi Electric ("MFM is RLL"). I started working with the transition export file that was created during the video, but hit a brick wall after a bit. Working with Mr. Gesswein through e-mail, I was able to find out that the transitions dumped were mostly corrupt (most likely due to misaligned drive heads). Throughout the process, however, I managed to get mfm_util to recognize the RLL format used by the controller (WD1004-27X), and translate a few sectors successfully.

As of now, I'm working to port the external stepper controller code from a specialized 3.02b build into the latest version of the mainline code, combined with my RLL modifications. This build should allow mfm_read to use either standard reading, drive-specific "recovery" mode reading (already present), or specialized microstepping using the 4- or 5-wire external steppers specified in Mr. Gesswein's "Data recovery" page (tentatively activated using the new "-X"/"--ext_stepper" flags - for eXternal stepper control - but this is open to change if requested). I've done a bit of refactoring in order to break out much of the code common to both controller types, but it's still a bit... rough. I'll post updates and screenshots as more progress is made.

For now, here's an older screen from awhile back - when I first managed to get conversion working on a test file from Bitsavers. While the ECC and CRC checks appeared to pass, I unfortunately didn't have a source "user-level" disk image to compare  the converted transitions against. I'm working with a few individuals to build some samples I can use for building and testing out various controller configurations as well.



- Donut

[Eric J Korpela]

That is incredibly awesome.  Thank you for working on this!

--
You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/eeb5e2de-e291-4a88-a972-f24482268610n%40googlegroups.com.

[BBMDonut]

Hey, all! Just wanted to give an update on progress over the last few weeks...

I've managed to merge most of the stepper-specific code into the modified RLL codebase I have locally, and I think I have the right bits in place for the most part. One thing I didn't realize going into this, is that the external stepper controller appears to only be compatible with a Rev. B device or newer - which doesn't bode well for the Rev. A device I have on-hand. I've been studying the pinout mapping spreadsheets (https://www.pdp8online.com/mfm/board/mfm_revd_pcb/info/BBB_Pins.html), and I think I have a good mapping for a few of the differences - I just need to get the .dts and .bbio files set up appropriately, and make a few "final" changes to the setup_mfm_read script (as far as I can tell). In full disclosure, I've never worked with the BBB/BBG boards before, so much of the low-level configuration is new to me. Hopefully this last little bit will take care of things, and I'll know something soon.

Also, it appears that my screenshot didn't seem to go through in my last post for some reason (at least on my screen). For anyone who was interested, it's also on the GitHub issue tracker for the RLL work: https://github.com/dgesswein/mfm/issues/8#issuecomment-2874423083

[David Gesswein]

Thanks for putting in all the work. Let me know if you need help with
config files.

> >> <https://groups.google.com/d/msgid/mfm-discuss/eeb5e2de-e291-4a88-a972-f24482268610n%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/fed5e39a-5aab-4ebb-871b-29ed3eb09a41n%40googlegroups.com.

[BBMDonut]

No worries! While it started as a way to help out Usagi, it just makes sense to submit the changes for everyone to benefit. 

With that said, I'm running into an interesting issue - I managed to get a pinout set up for the Rev. A board, and drive is stepping, however it's not stepping as expected. For example, I can start at cyl 0 and attempt a read, but after it tries to step, it ends up near cyl 3. If I exit and specify "--step -3", I could end up on cyl 2, cyl 5, or back on cyl 3. If I do a "--step 5" instead (just for testing), I could end up anywhere from cyl 1 to cyl 12. If I immediately do another "--step 5", I could end up back on cyl 3, or cyl 10, or cyl 15. Over time, regardless of whatever step intervals I supply, the heads keep moving further and further into the disk. I ended up having to carefully shut down and put the stepper back onto the drive's main PCB in order to get the heads back to cyl 0 (they were out around 372 by that point).

My pinout to J7 is currently this (modified for Rev A):

// J7-3 EN
// J7-7 STBY
// J7-5 ERR
// J7-9 MODE3
// J7-6 MODE0 (was J7-8)
// J7-4 MODE2 (was J7-12)
// J7-14 MODE1 (was J7-15)

I looked at the Mode3 and Mode2 lines on a scope (separate), and did see pulse activity going on - I have a logic probe I can hook up as well in order to verify the actual pulse timings over multichannel, but it might be a day or two before I can get back to it. All of that being said, it's picking up data here and there - though I think I need to tweak the decoding a little bit to make it pick things up in a more stable manner. I don't have the "wait for a certain number of timing bits" logic in place as of yet, so it just goes back and forth between "find the next magic ID" (similar to the 0x4489 of MFM) and hope that it lines up with what it wants (address data vs. user data). I have been able to decode quite a few sectors of ASCII data, so I'm hopeful for things to come...

- Donut

[David Gesswein]

Stepper motors do odd things if phases aren't hooked up correctly.

If you can't figure it out I have my original board which is equivalent to
A. I can see whats going on if you send me the code. May be a couple days
before I could test.

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/6028faba-c298-43b5-bf06-af33cb9c5bc3n%40googlegroups.com.

[BBMDonut]

Well all, there is good news to report. With the gracious help of Mr. Gesswein, I have completely dumped the data on Usagi Electric's ST-238R, pulled from an EDS PC. This is from the combination of the latest official branch as of June 12th, RLL upgrades, and official manual stepper control modifications from version 3.02. Now that the proof-of-concept works, code cleanup can begin. Once things are tidy, I'll move on to adding ext2emu support for the new configuration, then hook it up to the WD1004-27X and (hopefully) get RLL emulation working. Thanks to everyone for their support, and here's to finally getting this code out of the "it works on my box" stage...

- Donut

[David Gesswein]

Good to hear you got a clean read. Will whatever Usagi is up to with the drive
be a video at some point?

Did I send you what I started with for mfm_emu rll support? Didn't seem to work
but it has PLL setup etc in it. Will be agains old code version.

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/baad8f56-5389-482f-8d1e-5e9f0f60777an%40googlegroups.com.

[BBMDonut]

I'm not sure yet if Usagi will do a follow-up video on it, since the recovered data didn't contain what we were hoping for. Regardless, I want to do something either way. Most likely, it'll be in the form of another talk at VCF Southwest (in 2026). Though the more I think about it, I'm tempted to try doing something before then - I just don't want to end up basically giving the same speech twice. I might do a more in-depth dive into the work for this effort as a solo video, then summarize and do higher-level version for VCF. We'll see... XD

I'm afraid I don't have the previous mfm_emu RLL code anywhere - though it might make for a good starting point when I get there. If you want to either package it and send via the Google Drive, or add it as a branch to your GitHub, I'll grab it and go from there.

In response to the Github comment, I'll go ahead and push the read/util decoding first (after I clean things up). I can circle back and add emu support after the basics are in. I'll start preparing for this setup, then.

- Donut