In light of my numerous troubles with MFM drives, I feel like I need to be able to analyze what MFM formatting software is doing "under the hood" to avoid future woes. This includes what commands the software was sending to the BIOS or controller before formatting, how hard drive parameters were auto-detected, etc. A simple error code was not enough- and still isn't enough- for me to figure out exactly why my MFM/RLL controllers are so finicky depending on the computer. It would also help immensely to not have to go through DEBUG routines and restart the machine everytime! :D.
I didn't see any open source versions (understandable, since it has a very specific use-case)- so I made my own! Well, right now I have the skeleton of a full program, and a proof-of-concept formatter that works on a single IBM drive type (Type 8 ). I have enclosed the source for those interested, and will add to it as I have time. I originally intended to do a BIOS-compatible version and a Xebec-compatible-detailed version (talk to the controller directly), but I think I may just combine the functionality into one program. I would appreciate any feedback anyone has to make the LLFormatting process less painful too
.
Again, this is proof-of-concept, and it only works on Type 8 or comparable (733 cyls, 5 heads, 17 sectors/track) drives. My comments are out of date (the attached source creates the EXE with which I successfully tested a real MFM drive), and there are instructions which do nothing meaningful other than add heat to the room. The progress indicator doesn't even count up in decimal, but in hex (I'll get to it)! But it does work, and the source code be modified to work on any MFM drive type with moderate effort. At this point, this program does not do a surface scan after formatting (if anyone can suggest good MFM test patterns beside FFFF and 0000, I'm all ears), and interleave is ignored (seems to be standard to ignore for AT controllers). I have NOT tested it on an 8-bit controller yet.
One thing I find interesting is that in my initial test, I had CH and CL swapped from their correct positions when calling int 13h, subfunction 5...
Normally, CL holds the top 2 bits of the cylinder number and CH holds the bottom 8 bits. When this is reversed (which was necessary to print the hex value of the cylinder to the screen), this means that cylinders 00 to whatever got reformatted a significant number of times (I figured this out when I noticed significant seek delays between moving from cylinder 00 to 64 :D). When I rebooted the machine during these tests, I got a fake "Track 0 bad" error from my BIOS- it just said "Primary Master Hard Disk Fail", but I can tell that it's related since the problem went away when I made sure CL and CH held the correct data.
SpeedStor also claimed Track 0 and others were bad when I performed media analysis.
My question is: Why would a track format failure occur after repeated LLFormatting? I figured the disk would just write the same data structures repeatedly to cylinders 0 to whatever, so I'm not exactly sure I understand why repeated formatting would result in garbage tracks or unreadable data.
I didn't see any open source versions (understandable, since it has a very specific use-case)- so I made my own! Well, right now I have the skeleton of a full program, and a proof-of-concept formatter that works on a single IBM drive type (Type 8 ). I have enclosed the source for those interested, and will add to it as I have time. I originally intended to do a BIOS-compatible version and a Xebec-compatible-detailed version (talk to the controller directly), but I think I may just combine the functionality into one program. I would appreciate any feedback anyone has to make the LLFormatting process less painful too
.Again, this is proof-of-concept, and it only works on Type 8 or comparable (733 cyls, 5 heads, 17 sectors/track) drives. My comments are out of date (the attached source creates the EXE with which I successfully tested a real MFM drive), and there are instructions which do nothing meaningful other than add heat to the room. The progress indicator doesn't even count up in decimal, but in hex (I'll get to it)! But it does work, and the source code be modified to work on any MFM drive type with moderate effort. At this point, this program does not do a surface scan after formatting (if anyone can suggest good MFM test patterns beside FFFF and 0000, I'm all ears), and interleave is ignored (seems to be standard to ignore for AT controllers). I have NOT tested it on an 8-bit controller yet.
One thing I find interesting is that in my initial test, I had CH and CL swapped from their correct positions when calling int 13h, subfunction 5...
Code:
;Perform format- registers ready
;clc
mov ah, 05h
clc
int 13hNormally, CL holds the top 2 bits of the cylinder number and CH holds the bottom 8 bits. When this is reversed (which was necessary to print the hex value of the cylinder to the screen), this means that cylinders 00 to whatever got reformatted a significant number of times (I figured this out when I noticed significant seek delays between moving from cylinder 00 to 64 :D). When I rebooted the machine during these tests, I got a fake "Track 0 bad" error from my BIOS- it just said "Primary Master Hard Disk Fail", but I can tell that it's related since the problem went away when I made sure CL and CH held the correct data.
Code:
;SI- copy of AX
;DI- copy of DX
;BP- copy of CX
...
;Print current track
dosstr chs_str
mov dx, si
mov ax, di
;Perform format- registers ready
;clc
mov bp, cx
mov ax, cx
xchg ah, al
mov cl, 6
shl al, cl
mov cx, ax
mov dx, si ;Restore DX
mov ax, di ;Restore old AX
mov ah, 05h
clc
int 13h
mov cx, bp ;Restore CXSpeedStor also claimed Track 0 and others were bad when I performed media analysis.
My question is: Why would a track format failure occur after repeated LLFormatting? I figured the disk would just write the same data structures repeatedly to cylinders 0 to whatever, so I'm not exactly sure I understand why repeated formatting would result in garbage tracks or unreadable data.