My understanding is that RLL and MFM controllers talk to drives with the same electrical signals, but the RLL controller is going to put out a data signal for the heads that is a higher frequency and the data in the signal is reordered to be "run length limited" to make it viable at that density on the media. What you are seeing matches my expectation when a drive can't handle the higher frequency. The MFM drive can't quite reliably lay down and read back the higher frequency data signal from the magnetic media, so you get lots of bad sectors when you won't if you have an MFM controller. Or it could just be bad sectors, hard to say without getting an MFM controller.

Didn't see a jumper to change modes on your controller. I remember seeing a WD drive controller that would let you jumper between RLL and MFM modes once upon a time, but I couldn't find the part number with the time I have available right now.

Sadly, the above is quite correct.

I hesitate to suggest it, but you 'might' be able to reduce the drive's capacity with fewer sectors per track, and get it to work. (Keep the same number og heads and tracks, so the drive actuates correctlty, but lay down fewer sectors.)

(Eg, if you have a st-225 with 615,4,17 for chs, you MIGHT try 615,4,12 with rll encoding. There's some math you could do to derive suitable auraral density of the medium with the new encoding by examining the raw bit patterns laid down, if you feel like doing that, so you can zero in on the 'best fit' new geometry. Low-level formatting is assumed, naturally. You would need to consider the total number of inversions used to encode mfm over a given sector, (convenient wiki article) -vs- that for rll encoding, then determine the RATIO difference, then reduce number of sectors by that RATIO. The resulting auraral density should be the same, so bit flipping shouldnt happen. Theoretically.)

(The wiki article for RLL gives a hint for this, at least for 2,7 RLL.

(2,7) RLL edit

(2,7) RLL is rate-1⁄2 code, mapping n bits of data onto 2n bits on the disk, like MFM, but because the minimal run length is 50% longer (3 bit times instead of 2), the bits can be written faster, achieving 50% higher effective data density. The encoding is done in 2-, 3- or 4-bit groups.

Western Digital WD5010A, WD5011A, WD50C12

So, the correct ratio reduction would be 2/3 the number of sectors.

(3, is 50% bigger than 2. The gain is 1. 2/3 of 3 is 2. This is the correct ratio, at least for 2,7 RLL, per wiki)

So, for that 17 secors per track st-225, you would work out to 11.333 sectors. My guess of 12 works, with a little extra fudge room. Who'da guessed!)

In theory, that would spread the data markings over a longer run.

If the issue is with data density being too high (bit inversions in the media from domains too close together), this might 'fix' it, by spreading the markings over a larger area. (The drive will spin at the same speed, and the tracks will be the same stepping, but the sectors will be spread out more)

It's a crapshoot if that would work reliably or not though.

If the issue is from a lack of signal intensity (head is not dwelling long enough/not outputting enough energy to properly set medium polarity) or quality though, it's gonna be like putting a type iv metal cassette in a standard tapedeck. Not gonna work good regardless.

danijelm wrote on 2024-04-03, 13:12:

Am I doing something wrong? and whether this combination of disk and controller can work together?

Not wrong as such, but you are trying to write the HDD with higher bitrate than it can handle and you get errors. Setting BIOS to 17 sectors doesn't switch the controller from RLL to MFM, it just uses less space per track than it could, but it's still RLL.

FYI MFM encoding uses 10MHz signalling rate and RLL raises that to 15MHz - which is a 50% "overclock" so to speak. If the magnetic surface can't reliably store that density, or if the head amplifiers have too high noise floor and can't reproduce the timing properly during reads you will get tons of errors. Nothing can be done about that, not all MFM HDDs are good enough to handle RLL. Although I had some pretty good results with two D5126.

You could try a different HDD controller if you have one, since the signal coming from HDD is the raw bitstream the quality of the PLL on the card matters a lot. So does clean power supply, cable length and routing. But in general it you have a problems they will not just go away with a simple change (unless something is actually broken and gets fixed - like very noisy PSU). I have a few MFM HDDs and for example the NECs took the RLL format pretty well but Seagate ST-125, which is a newer model and one would think improved tech, works well with MFM but gets tons of ustable sectors with RLL. Especially one head/surface but others are not exactly great either.

I didnt mean to suggest it would somehow magically switch rll to mfm.

Only that the drive might better be able to handle the data being read/written, by having more platter to write on.

Again, a crapshoot.

The out of spec signal rate would still be a huge issue. The mfm drive might just be too slow. 🙁

Deunan wrote on 2024-04-03, 17:00:

higher bitrate
FYI MFM encoding uses 10MHz signalling rate and RLL raises that to 15MHz - which is a 50% "overclock" so to speak.

this is true, but Afaik:
-FM allows transitions on every clock, clock = 2x data rate.
-MFM allows transitions on every clock, clock = data rate.
-RLL guarantees at most only 3? transitions every 7 input bits? lets you use much faster clock and still remain below speed of MFM transitions.

FM->MFM Instant doubling of density using same drive&magnetic medium. Double capacity and double speed for free.
MFM->RLL 50% higher recording density without changing drive&magnetic medium. 50% capacity and speed bump for free.

Lets encode "lol" 01101100 01101111 01101100

Data________: 0 1 1 0 1 1 0 0 0 1 1 0 1 1 1 1 0 1 1 0 1 1 0 0
FM encoded__:101111101111101010111110111111111011111011111010
MFM clock___:?00000000000001010000000000000000000000000000010
MFM encoded: ?00101000101001010010100010101010001010001010010
RLL 2/7 WD__: 00100000100010010010000010001000001000001000100100
Please correct me if I got something wrong.

1 is not a logic level. Magnetic recording doesnt store levels, can only store magnetic impulses (flipping magnetic pole).
So yes, RLL controller uses higher input frequency/bitrate, but actual FLUX transitions send to the head stay at same max frequency as in MFM.
In theory we could have gotten 2.16MB 3.5 inch HD floppies back in the eighties. Maybe even 3.2MB with addition of Zone bit recording, all with just a change in the Floppy controller chip leaving same floppies/drives.

RLL isn't about higher frequency.
RLL is about higher PRECISION.

The critical parameter is stability of spinning speed.
Stable RPM = precise timing.

There are some MFM+RLL controllers but the NCL 5275 is not one AFAIK. And you did not hurt the drive trying it on a RLL controller, just tried to format it not fully supported.... like a 1.2Mb drive doing a 360k format ;p
You need a MFM controller. If you lived in USA would send you a WD MFM controller for shipping, have more than I need.....
And it is more than speed and precision the diff of MFM and RLL but that discusion doesn't help him 😀

Horun wrote on 2024-04-04, 03:07:

And it is more than speed and precision the diff of MFM and RLL but that discusion doesn't help him 😀

I would love to know more. On paper RLL should be much easier on the drive than MFM, so why are some disks not cooperating?

Many thanks to everyone for the answers. In the end I gave up. I found 2 capacitors on the controller that were bad. I changed them but the same thing happens.
Still the disk has BS. when I format it, scandisk runs without problems, but as soon as something is written to the disk, a bunch of BS is created in that place.
if I understood this controller is only RLL and if I switch to 17 sectors, it's still encoding in RLL, only the disk has less capacity.
Unfortunately that's the only controller I have. I'm from Europe so thanks for the controller suggestion but I think the postage would be too expensive.
I'm saving the disk and the controller for better times. Maybe an MFM controller or an RLL disk is running into me.

I see that the controller has 2 EPROMs, one is bios and the other? Can it be switched to MFM by changing the EPROM?

Quite likely, but then you need to have a dump of the MFM version controller ROM.

what chip is on the controller? I cant even find a single photo of it

rasz_pl wrote on 2024-04-04, 00:39:

So yes, RLL controller uses higher input frequency/bitrate, but actual FLUX transitions send to the head stay at same max frequency as in MFM.

On average, yes. All these coding schemes can be considered a type of FM (frequency modulation) or PM (phase modulation). To - possibly - re-use existing drives the average frequency has to say below certain limit but look at your own example and calculate times, in ns, between ones (flux transitions). For all possible cases in a given encoding scheme. Then calculate the minimum clock required to both write and recover the flux properly, to not for example confuse 1001 and 10001. Then consider more subtle issues like noise, trigger levels, pre-compensation (and why it's required in the first place), etc.

Grzyb wrote on 2024-04-04, 01:10:

RLL isn't about higher frequency.
RLL is about higher PRECISION.

True, but...

Grzyb wrote on 2024-04-04, 01:10:

The critical parameter is stability of spinning speed.
Stable RPM = precise timing.

From personal observations it's not that critical. These are pretty big, usually multiple platters with a lot of mass so the spindle motor doesn't really have the power to introduce all that much jitter. Depends on the motor type and the RPM control scheme as well. That being said dying spindle bearing(s) can cause a lot of problems due to more chaotic noise they induce (along with the motor trying to correct for it).

So you are not wrong but I would say the main limiting factor is the quality of the head amplifier, how much jitter does it add to the flux timing due to its own noise. Then there's the media quality and lastly the spindle stability.

Deunan wrote on 2024-04-04, 08:42:

rasz_pl wrote on 2024-04-04, 00:39:

So yes, RLL controller uses higher input frequency/bitrate, but actual FLUX transitions send to the head stay at same max frequency as in MFM.

On average

Absolute maximum frequency never goes over MFM.

Deunan wrote on 2024-04-04, 08:42:

look at your own example and calculate times, in ns, between ones (flux transitions). For all possible cases in a given encoding scheme.

yes, we go from 2 in FM to 3 in MFM to 6 in RLL.

Deunan wrote on 2024-04-04, 08:42:

Then calculate the minimum clock required to both write and recover the flux properly, to not for example confuse 1001 and 10001.

more or less scaled as much as ascii allowed 😀

FM_Data_____:____0_____1_____1_____0_____1_____1_____0_____0_____0
FM_encoded__:_1_____1__1__1__1__1_____1__1__1__1__1_____1_____1___
MFM_Data____:__0__1__1__0__1__1__0__0__0
MFM_encoded_:_?___1__1_____1__1____1__1_
RLL_Data____:_0_1_1_0_1_1_0_0_0
RLL_2/7_WD__:___1_____1___1__1__

found RLL goldmine https://c65gs.blogspot.com/2022/01/more-work- … l-encoding.html Paul Gardner-Stephen implementing RLL floppy controller for ordinary 3.5 inch HD floppies.

rasz_pl wrote on 2024-04-04, 14:47:

Absolute maximum frequency never goes over MFM.

You keep using the word frequency as if this was pure, constant sine wave. In fact it's not really frequency we are concerned about here, but bandwidth of the entire transmission line, and it's noise. But I really do not want to explain the properties of angle modulation here, there's enough reading material out there already.

I'm not sure what it is you are trying to prove with that ASCII art. I asked you to compare the required resolution of the clock signal to discern between flux changes for FM (which carries clock bits), MFM (which skips clock bits but arranges data to always have a phase sync with the clock) and various wider RLL schemes (that put way tighter requirements on PLL clock recovery). Read about data separators and why these circuits were initially a separate chip, and why even after floppy controllers integareted them the hard drive ones still used a separate circuit. Read about gaps before sector headers and data blocks, and why they carry specific bit patterns.

Read, in general. And then you can nitpick about the words I use to try and explain this in simple terms. Again, we are done here.

While testing the drive, I turned off the bios on the controller. I set the CHS parameters in the bios of the motherboard. I don't know how to access the controller bios.
It should be on C800h, but when I go to that address in debug, nothing happens.What is the purpose of the bios on the controller if the motherboard can do everything from its own?
I downloaded the contents of the eprom and the bios eprom shows that it has a format utility for RLL disks. The second eprom is probably a rom, I didn't see anything interesting in it.
Here is a picture of the controller and the contents of the eprom

danijelm wrote on 2024-04-04, 17:14:

While testing the drive, I turned off the bios on the controller. I set the CHS parameters in the bios of the motherboard. I don't know how to access the controller bios.
It should be on C800h, but when I go to that address in debug, nothing happens.What is the purpose of the bios on the controller if the motherboard can do everything from its own?

Try dumping (in debug) the code at C800 - BIOS ROM extensions need to have a header so that BIOS can tell it's there. The actual excutable code starts at +3 bytes into the ROM.
Not all mobos can deal with 26 sectors per track, some only carry disk table with 17 sectors and won't let you enter custom values. In that case the ROM might detect that and modify it during boot to 26 (or another value that it supports - some controlers will store such settings on the HDD itself). And there might be other functions in it too, like the ability to translate CHS for HDDs with more than 1024 tracks (there are such MFM HDDs).

Scott Mueller's 1998 book has a large section on MFM and RLL, and also shows/describes the binary and waveform differences of data to flux and encoding (pages 576-580 of 8th Ed.). Much like the Paul Gardner-Stephen paper descriptions. A bit Too much knowledge to post here 😁
Most WD and compatible MFM and RLL controllers the entry point with debug is : g=c800:5 (if controller bios set at C800).

Horun wrote on 2024-04-04, 22:45:

Most WD and compatible MFM and RLL controllers the entry point with debug is : g=c800:5 (if controller bios set at C800).

And in case you don't know what that means:

1. Boot to DOS from floppy or the HD
2. Run DEBUG.EXE
3. At the dash prompt, enter: G=C800:5

And that will start the disk utilities stored on the ROM