Actually, I'd like to see it just read/write flux changes + index marks onto a SD card for later analysis. Building all the smarts into the controller means that some formats will get missed. One can later write translation code for what ever format one has. Make this information open source, much of it is already in bits and pieces. Make sure it can read and buffer an entire track of data in RAM ( Gotek can't ). We no longer need proprietary hardware. There are a number of off the shelf controller boards capable of handing this. It would only need cables to match the drive. Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Fred Cisin via cctalk <cctalk at classiccmp.org> Sent: Tuesday, February 19, 2019 2:02 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info? On Tue, 19 Feb 2019, Ali via cctalk wrote: What I would like to see, coming at it from a high level software viewpoint, would be: Complete and accurate emulation of 765. Including ROM or being loadable into RAM (TSR) and repoint the Int13h vector. That would permit it to fully replace the stock 765. Include a switchable "quirks" mode for full compatability with 765 "features", such as "flash blindness" after index pulse, switchable inability to handle 128 byte sectors, etc. 8" and FM and 128 byte sector support (obviously) 125kbps (5.25" FM), 250Kbps, 500Kbps, 1000Kbps (2.8M) Ability to read MFM data with FM headers (RX50) Added commands accessible through the [replacement] Int13h: Track read, modeled after the WD track read (that could also provide access to Amiga, with additional code for sectors and filesystem) RAW track read (flux transition), with and without data/clock synchronization. Hard sector, GCR, copy protection cloning, etc. could be handled by other code that calls that function in the [replacement] Int13h. Optionally: drivers for "modern" OS, inverted data reversal, EBCDIC/ASCII conversion Installable File System (IFS) to permit mounting alien disks, including: Apple2 ProDos/SOS Apple CP/M Apple P-System Mac 400K/800K Commodore Sirius/Victor 9000 CP/M (partial list available at http://www.xenosoft.com/fmts.html) P-System Amiga Northstar N-DOS TRS-DOS and derivatives (list available on request) Coco-DOS Microsoft Stand-Alone BASIC (NEC, Oki, etc.) Unix/Linux file systems If it also does HDDs, . . . -- Grumpy Ol' Fred cisin at xenosoft.com

On 2/19/19 2:31 PM, dwight via cctalk wrote: You want to do the analysis at the time of capture, in case you need to re-read the media, or wiggle the head to try to push off a bit of gunk, or micro step it for off-track errors. ie. you need to know if what you capture is meaningful.

On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote: That should read flux transition plus appropriate control signals for the drive. Seeking tracks, turn on the drives R/W circuitry, etc. Flux transition ITSELF is just making sense out of the pulses on the track.

On Tue, 19 Feb 2019, Paul Koning wrote: As Al pointed out, at least an initial stage of analysis should be done real-time, or close to that, to determine whether the read seemed to have been successful. 'Course, that doesn't preclude later stages from also requesting a new attempt, if the data doesn't look good on further analysis. And, of course, using multiple machines, or just multiple processes, one system could begin processing, while another is reading more tracks. The reliability encountered would determine how much testing should be done before moving on, either to the next track? or the next disk? If errors are RARE, then there would be no cause to hesitate and hand off processing while moving on to the next JOB. If errors are FREQUENT (Al, Chuck, and I dealt with some that required dozens of attempts to get a successful read of a track), then that would caall for MORE processing before stepping to the next track or disk. FDC does a CRC "real time", and compares that with the value stored in the sector header.

On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote: It's not that simple. There's the matter of "DEC MFM" which encodes a few bit patterns differently to avoid collision with FM headers. --Chuck

On Tue, Feb 19, 2019 at 3:38 PM Chuck Guzis via cctalk < cctalk at classiccmp.org> wrote: The RX50's are MFM encoded. There's no FM anything on it, unless it's that way on all MFM diskettes. Other DEC diskettes may have done this, but RX50's are just higher track density, but old pre IBM-AT data encoding rate diskettes. At least on the Rainbow the floppy chip is kept in MFM mode all the time, unless you've written something to hack it to read alien disks. Warner

On Wed, 20 Feb 2019, Chuck Guzis via cctalk wrote: That was my mistake. I wrote RX50, but I meant RX02. And, as Chuck pointed out, the MFM data within the sectors is not quite the same as the MFM encoding used by others. Sorry about that.