<<Brainstorming mode on:> <Is IDE geared in any way to the MS-DOS filesystem? No. It's a device level interconnect similar to SCSI or other busses. In practice it's a 16bit data bus, several control lines and a few address bits. It was a result of putting the early PCbus MFM(or rll) card in the MFM hard disk to make it a single unit. The WD1003 MFM ISA16 (PC) bus card is a very similar interface when viewed from the ISA16(PC AT and later 386/486 sytems) bus. What IDE did was allowed the PC to offload one board (Disk controller) onto the disk drive (IDE= Integral drive electronics) and created a simple disk interface connector/cable that was cheaper than SCSI but offered many similar features of SCSI interfaced disks sans the greater cost. The drive and it's IDE interface is a series of registers for parameters and data transfer and it cares less what operating system is in effect. About the only difficulty is interfacing the 16bit wide(for data, 8bit for commands) bus to whatever the local CPU/BUS is in use. that logic is nearly the reverse of the 99/4a 16bit->8bit for the PEB. One could do a kluge and not use the high order bits as they are data only. However that means the default 512byte sector size would only hold 256bytes of data (with large drives dirt cheap this is not so bad!). I personally don't like that but it'd work. The interface is basically a series of registers that set up the transfer with data like command, head, sector, cylinder and number of sectors (transfer length). The interface does not have to keep up with the physical media as even the smallest ones have a 32k (up to 512k) cache ram on board so that if can feed data fast (or slow) as the host desires it. Most of the 60-100meg and later drives (quantum is known for it) have a LRU cache so that the drive can try to anticipate the next likely sector to transfer to avoid rotational latentcy. While the drives are hyped and speced for fast transfer rateds to their host system there is no requirement to use that speed as there is no lower limit. Because of the cache a polled interface is easy to do and there are no requirements for critical fast loops to avoid loosing data. I happen to use IDE with FreeBSD(on PC hardware) and also a Z80 CP/m system. Both are about as unDOS as they can get. DSR level issues are things like are there logical limits to how big a TI99/4a file system can be. Also how does one write a DSR that uses any one of several hundred differnt IDE drives of differnt sizes and configurations? IE: 20mb as 4 heads 615 cylinders of 17 sectors or 306 cylinders and 8 heads? PCs (CP/M and others) have the idea of a bios that translates differnt physical devices to look like one logical interface. Sadly most DSRs were not written that way. Having a differnt DSR for a WD 240mb and a shugart 340mb would be a real problem. Also the older drives are dumber and cannot tell the system what they are (configuration), the later (mostly over 200mb) drives added that functionality. So there would also have to be configuration tools and some amount of NVram(EEPROM) on the board to allow for whatever drive was available from the older 40mb up to the current 19gb drives. I'd point out that the drives in the 80-400mb range seem to be more inconsistant than the larger ones. Also drives over 512mb have additional fuctionality so that they can be addressed as block instead of cylinder, head, sector. So the driver (DSR) has to be a bit smart so that it know what class of IDE drive and what capabilities are available. That's a real tall order! So that is why I say the physical interface is trivial compared to the DSR. It can be done as many of the same problem occur with SCSI but the DSR will have a lot of differences at the lower levels of code. Judging from the SCSI dificulties reported here that wasn't easy either. Allison