dgesswein
Reading and emulating RLL Disks not supported
I have today managed to hack up some python code, which reads a transition file and picks out address marks and sectors, including CRC checks, for a disk written with a WD1006 RLL controller.
Do you want to include it in this repository ?
I can create a contrib directory for it.
Good to know that the transitions file resolution was sufficient for RLL.
On Tue, Mar 25, 2025 at 03:57:14PM -0700, Poul-Henning Kamp wrote:
bsdphk left a comment (dgesswein/mfm#8)
I have today managed to hack up some python code, which reads a transition file and picks out address marks and sectors, including CRC checks, for a disk written with a WD1006 RLL controller.
Do you want to include it in this repository ?
-- Reply to this email directly or view it on GitHub: https://github.com/dgesswein/mfm/issues/8#issuecomment-2752724533 You are receiving this because you authored the thread.
Message ID: @.***>
Preliminary, very dirty WIP code appears functional for RLL-based WD1006V-SR2-encoded data. I need to do quite a bit of code cleanup and sanity checking, get it onto the hardware and test everything, and add more controllers/conversion tables. But progress has been made!
It's been awhile, but I've been continuing on as time allows. While my previous post showed translation on a previously-captured transition backup, I've started to receive data in real-time from an older Rev. A MFM Emulator. The code still needs much work, and it's a bit inconsistent (though the source drive I'm working with isn't in the best shape either). But it's getting there... I've been able to identify what looks like FAT cluster allocation data, along with some MS-DOS messages. I'm working with an ST-238R with potential head alignment issues, so I'm also trying to tie into its pin 16 "/RECOVERY" signal along the way.
Thank you for your work on this. Looking forward to when it's incorporated in the future. I think David actually bought a WD 1006 from me last year in the hopes of trying to get something working with reading RLL drives. If I knew how to program, I'd wholeheartedly help.
@bbmdonut Thank you for this work, it will be super useful to many of us! Are you pushing your work-in-progress code somewhere, or do you plan to release this when it's sufficiently stable?
I have a fork of the project on my own GitHub account, however I am still in a "cleanup" phase to move the code from proof-of-concept into something resembling actual production code. As such, I haven't yet pushed any updates. I don't want to get too much out to the public just yet, as the code only really works as far as mfm_util and mfm_read for now. I want to get support for ext2emu and actual RLL emulation in place before making an official pull request to merge everything in, though if @dgesswein would rather I just submit individual functional features incrementally, I can do that as well. Grabbing partial work-in-progress versions from my repository would definitely come with a "use at your own risk" citation... I've been posting more frequent status updates on the mfm-discuss forum at Google Groups as well.
That's fine; I wouldn't mind if reading/processing and emulation came separately in two different PRs though, as I'm mainly interested in this for data recovery purposes, at least for my use!
Separate pull for mfmemu from the reading/decoding etc code seems reasonable since there isn't much shared between them. Whatever way you want to do it is fine with me.