DiscFerret disc analysers for sale!

On Tue, 6 Sep 2011, Al Kossow wrote: Well, I did say "READ" :-) which would either require some sophisticated analysis, or passing the expected info TO the code. I would add additional parameter(s) to the INT1Eh structure. For conventional MFM "IBM/WD" sectors, that already includes the sector size (0,1,2,3). Add another parameter(s) for MFM V other formats. If done well (yeah, right!), the reulting code could be a drop-in replacement to hook the 13h vector to, for OS and utility software (XenoCopy, etc.) that would otherwise call INT13h. For those not familiar with it: INT13h calls for pointing INT1Eh at a data structure with certain physical parameters. Then uses most of the general purpose registers to pass drive, head, track^H^H^H^H^H cylinder, sector, address of the DMA buffer, etc. On return, the accumulator has an error code. This INT13h surrogate would be another layer on top of the DiscFerret code. It would seek to the appropriate track, call the DiscFerret code to read the track, separate the date, decode, decipher the MFM sector headers, and copy the decoded sector contents into the specified buffer location. It also certainly shouldnt't be "hard" (in some meanings of "hard") to analyze the raw flux transitions, and recognize whether what is there is compatible with a WD/IBM style MFM, and look at the sector headers to report what sectors are there. Similar code could be done for FM, Amiga (MFM without the sector headers), GCRs, MMFM, and maybe some others. If what is there is compatible with MULTIPLE formats???? then it's up to you to speculate. If what is there is NOT compatible any known formats, then it's up to you to abandon all hope before entering. -- Grumpy Ol' Fred cisin at xenosoft.com