![enable disk controller in bios foxin enable disk controller in bios foxin](https://www.softwarepro.org/blog/wp-content/uploads/2019/02/images-1.png)
Now, the Drive/head register is laid out such that the low four bits contain the head number, and the next bit is the device select register. The resulting remainder is written into the Drive/head register, and the dividend is written to the Cylinder Low and High registers. The dividend is divided again by the number of heads.
#ENABLE DISK CONTROLLER IN BIOS FOXIN PLUS#
The remainder plus one is written to the Sector Address register. The way IDE.DSK translates from internal LBA to CHS is quite straightforward: Divide the LBA by sectors per track. If geometry translation is in use, IDE.DSK may end up with a translated CHS which is not suitable for programming into the IDE controller. NetWare appears to query the disk geometry from the partition table if it can, or from the FDPT.
#ENABLE DISK CONTROLLER IN BIOS FOXIN DRIVER#
But the IDE.DSK driver needs to translate those into a CHS (Cylinder/Head/Sector) address that the IDE controller can use.
![enable disk controller in bios foxin enable disk controller in bios foxin](https://i.ytimg.com/vi/Scl72txrPH0/maxresdefault.jpg)
Internally, NetWare uses logical block numbers like any sane OS.
![enable disk controller in bios foxin enable disk controller in bios foxin](https://cdn.mos.cms.futurecdn.net/PbwaxzjY665km9GBGVFRzg.jpg)
The problem has to do with the dreaded geometry translation. Then it would read the alternate status register, get rather confused, and start endlessly re-calibrating and resetting the drive. After working correctly for a short moment, NetWare would select non-existent device 1 (slave) on an IDE channel with only device 0 (master) present. The symptoms of the problem initially didn’t seem to make much sense. Crucially, there were also no translating BIOSes yet. The driver notably does not use LBA, because it was not yet standardized at the time disks with LBA were perhaps just coming on the market, and they were generally not big enough to require LBA. The IDE.DSK driver in NetWare 3.12 dates from April 1993, meaning it’s older than the original ATA specification. The driver loaded fine, discovered a 1GB disk fine, but when accessing it, it was extremely slow and produced a lot of errors.Īfter some debugging and disassembling IDE.DSK, the cause became obvious, but the chain of events that led to it was anything but. Recently I had an occasion to find out why NetWare 3.12 using the shipped IDE driver (IDE.DSK) behaves, very, very strangely when let loose on disks bigger than about 500MB (a very foolish thing to even try).