On 2021-02-11 12:41 p.m., Al Kossow via cctalk wrote: Doesn't stop me trying, Al. Lots of things were achieved by people who didn't know they couldn't do it! My controller has settings for different sector sizes.? I owe it to my friend to try! Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.johnson at ieee.org

On 2/11/21 10:03 AM, Josh Dersch via cctalk wrote: Another issue with ESDI is the drive has the data separator on it and the data rates off of the drive were anywhere from 10 to 2x megabits/sec. The higher density drives just upped the data rates and packed the sectors tighter.

On 2/11/21 9:36 AM, Chuck Guzis via cctalk wrote: What do you do if the controller and drive don't match? ESDI and RLL versions of Dave's MFM reader are on my list of things to do.

On 2/11/21 9:40 AM, Nigel Johnson via cctalk wrote: I was speaking about the interface to the controller. Of course, if you don't have the right controller, all bets are off. --Chuck

On 02/11/2021 11:36 AM, Chuck Guzis via cctalk wrote: No. ESDI is similar to MFM, there is a differential read data pair on the 20-pin connector, but the data rate is much higher, 10, 15 or 20 MBit/sec, and used a different encoding scheme that gave more data bits/flux transition. I think the 34-pin connector also allowed an additional head select bit, so you could have up to 16 heads. ATA has a single 40-pin connector with a 16-bit parallel data bus for all command and data transfers. Jon

On 2/11/21 10:22 AM, Jon Elson wrote: Brevis esse laboro, obscurus fio. Let me be more concise. On an x86 PC, *most* ESDI controllers present an interface exactly like ATA, right down to the IDENTIFY command. If you're talking about the naked drive, it isn't ATA, nor is it similar to MFM. ESDI drives are "smart" in the sense that they do have a command set (not ATA, however) and perform tasks such as data separation and seeking (one issues a SEEK command to the drive, not a STEP IN/OUT). ST506, in contrast, is a glorified floppy drive with differential data interface--it has no smarts. In addition, ESDI also pertains to certain early optical drives, which ST506 does not. I believe that there was also a possibility for a tape interface. --Chuck

On Thu, 11 Feb 2021, Chuck Guzis via cctalk wrote: I'm more than a LITTLE confused by parts of this discussion. To what extent are ESDI controllers interchangeable with already written drives? Remember that XT/5160 ST506/412 controllers were often NOT interchangeable, although AT/5170 ones usually were. Mattis says that he has the controller that that drive was written with. Some folks are talking about how the controller talks to the drive. If using OS or BIOS (mine had a ROM), unless changing THAT, such as trying to use a flux-transition device, controller to drive communication seems largely irrelevant. At least in the case of ISA, for the sake of compatibility, and transition, the controller and drive COMBINATION looks the same to the computer/OS as an ST506/412. Similarly, on PCs, IDE typically, for the sake of compatibility, and transition, the controller and drive COMBINATION looks the same to the computer/OS as an ST506/412. Similarly, on PCs, ATA typically, for the sake of compatibility, and transition, the controller and drive COMBINATION looks the same to the computer/OS as an ST506/412. All followed the ST506/412, and strived for transparent compatibility, but did not necessarily derive from each other.

On 2/11/21 12:51 PM, Al Kossow via cctalk wrote: Another possibility is looking at the driver in the AIS sources. That's been on my list to do, next to disassembling the controller code. I don't know if it's possible to pull data out of the sector buffer without DMA That would simplify hacking something together to try to use the board in a PC

On 2/11/21 12:31 PM, Mattis Lind via cctalk wrote: I have a bunch of RT drives that I need to archive, and I have the same problem. It should be possible to disable write gate and use a generic PC ESDI controller to position the heads, then extract the data with a logic analyzer or something else capable of running at that data rate. If you look at the spec, there is a byte strobe along with the clock and data.

On Thu, 11 Feb 2021, Paul Berger via cctalk wrote: The most likely ISA ESDI would be the WD1007 controller. There were a few variant submodels of that, such as with/without floppy support, w/wo BIOS ROM. http://www.minuszerodegrees.net/manuals/Western%20Digital/WD1007A-WAH%20and… Mine had the ROM. On one machine, I had a 200M 3.5" drive. My first drive of that size of both capacity and physical size. I think that I know where it is.

On 2021-02-11 6:35 p.m., Fred Cisin via cctalk wrote: No that is not it the one I used was a full length controller, but unlike the RT controller that was pictured it did not have an IBM square aluminum can chip on it, but it was probably at least 30 years ago so I don't recall any more.? By the time I left the Toronto Lab where I had almost all my exposure to RTs I was already using SCSI disks in my PC. Paul.

I am pretty sure that my controller is the IBM Enhanced ESDI board and having support for it in Linux is probably unlikely. But perhaps it is the WD1007, I am not sure until I checked and it is 100 km away right now. Anyway I did some reading of the ESDI spec. There are things that I really like to have clarified. ESDI has a hard sector and soft sector mode, much like floppy disks. But in contrast to floppy disks which are hard set to a certain number of sectors per track the hard sectoring in ESDI (and SMD) is just a counter derived from the bit clock / byte clock, right? As far as I can understand you can set any number you like for this divider both in ESDI and SMD. So you can select a big variety of sector sizes using hard sectoring. This would then be in contrast to a hard sector floppy disk where only one format can be handled. The latter would then lead to a soft sector format for floppies where one could select the number of sectors arbitrarily. But what sense makes a soft sector ESDI drive. Isn't it just add overhead by having address marks? Wouldn't it just be simpler with hard sectoring? Less overhead? Then another issue in ESDI is that it seems to be quite elaborate protocol between the drive and the controller. Not just for sending commands which are done serially 16 bits plus parity but also the reading process. I am a bit confused about the READ GATE. It has to be deasserted in the PLO SYNC interval. Why is that? I am clearly missing something. A ST506 can be read raw and then decoded in software if you like. But it seems that just enabling READ GATE and reading the track of the drive (perhaps with SECTOR PULSE for hard sector configured drives) wouldn't work. You have to fiddle with the READ GATE at the correct bit point in time. It seems that this fiddling with the READ GATE controls how the VCO in the data separator behaves. In any case this exact timing of the READ GATE makes things a bit more complex on how to read a disk without the proper controller. One needs some logic with counters to handle this. Why didn't they put that logic in the drive? The PLO SYNC stuff is drive specific anyhow as I understand it. http://bitsavers.informatik.uni-stuttgart.de/pdf/maxtor/1011004B_XT-4000E_P… http://www.bitsavers.org/pdf/micropolis/ESDI_spec_X3.170-90.pdf /Mattis

On 2/12/21 8:12 AM, Al Kossow via cctalk wrote: oops, page 445 and it describes how to program the dma

On 02/12/2021 09:04 AM, Mattis Lind via cctalk wrote: ESDI has a clock separator built into the drive, with logic to decode the data format and convert to a standard protocol. Many of the higher-end drives used some form of RLL encoding internally. I'm just guessing here, but I suspect that the sector headers were written during a drive format, and then never written again, as some recently discussed DEC drives did. So, there'd be a synch discontinuity between every sector header and the data block. I'm guessing a drop and then re-assertion of read gate would prepare the PLO to resynch quickly at the beginning of the data packet. The controller would know when to do this, as it would read every sector header looking for the desired sector, and as soon as the header data ended, it could wiggle read gate. Jon