This message is in a couple of parts: The first describes what I needed to do to fix my "Missing operating system" problem. The second part is a condensed version of how and why. But it's pretty long. Part 1: I used the fdisk program from linux to find out what was on the dodgy HD. It said (not surprisingly) that the physical and logical partitions didn't match. The drive had one partition, in slot 1, that spanned the whole disk (85MB). This partition was also flagged bootable. Since partitions should end on cylinder boundaries, I was able to deduce the CHS values used, when the drive was partitioned, from the "what it should be" messages for the end of the partition. Fdisk told me that it expected the end to be at cylinder 901, head 3, sector 45. So I used expert mode to experiment with different C, H and S values for the drive until I didn't get any errors. The CHS value that worked nicely was 901:4:46 (no surprises there). (You can get this information my reading the MBR and decoding the partition table by hand. If you don't know the layout of the MBR, then the entry for INT 19, in file interrup.d of Ralf Brown's Interrupt List will be useful. One way of reading the MBR is given in part 2). Shutdown and enter the new CHS values into the CMOS and up came win3.1. Whoopee! The 'no message at all' problem could be caused by a mismatch between the system files on the disk (I didn't get any messages when I booted from diskettes with a dodgy mix of boot sector, system files and command.com from a variety of different dos versions). And just a note: it doesn't matter where the files are on the disk (as long as they are reachable by the BIOS routines). What is important is that IO.SYS (and probably MSDOS.SYS, too) are in the root directory. For IBMBIO.COM and IBMDOS.COM the above also holds, but, for DOS5, they must also be the 1st and 2nd entries in the root directory (and in that order). FYI: "Missing operating system" is generated by the MBR code (DOS5, and probably DOS's earlier). DOS7 has a different message. The message occurs when: a:) it fails to read the sector where it thinks the partition boot sector is - e.g. you've told the CMOS it has 17 sectors per track, but when the drive was partitioned it had been told it had 63, and the partition boot sector was written to sector 40. So it tries to read sector 40, and fails. b:) A target sector is read ok, but it doesn't have 0x55AA as the last two bytes (all DOS boot sectors, including the MBR, have them).

0

Part 2: This sort of describes the events of the four days I spent getting around the "Missing operating system" problem. Software tools used were: from the DOS diskette: SCANDISK.EXE, FDISK.EXE, SYS.COM and DEBUG.exe. from linux: fdisk from the net: a free disassembler (so I could edit labels and comments on the screen rather than writing it all on bits of paper); a hex editor; Ralf Brown's Interrupt List (invaluable); Microsoft KB article number Q114841. You can get the interrupt list from - http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html I was given a tower case with a 386 m/b, a Conner HD (CP30084E, 85MB), and a Trident video card. Someone else had donated a desktop case with a 486SX m/b, but no HD, and I thought I'd make a little server with some of the other bits and pieces I've got lying around. So I took out the 486 m/b, filled the cache from yet another m/b I had, put it in the tower case, attached the other necessary bits and turned the machine on. That was when I got the first "Missing operating system" message. I was, however, able to boot with the win98 floppy I keep for installations and emergencies. FDISK and SCANDISK both seemd to work ok on the HD, and FDISK showed one partition (C:), and it was marked as bootable. Some of the items of interest from the first look at the HD: + the windows part was old - pre win95. + the 'system' files were IBMBIO.COM and IBMDOS.COM, and the dos version was 5 (I found that by using the DOS DEBUG command to look at COMMAND.COM: A:\>debug command.com -r debug command.com, will load command.com starting at offset 0x100. The CX register contains the number of bytes loaded (or BX:CX if there are more than 0xFFFF bytes). You can also use the -n command to enter a new name. When writing data to a file, enter the number of bytes into CX (using -r cx), and then issue the write command -wYYYY, where YYYY is the address of the start of the buffer. For example ... -l1000 0 0 1 data buffer Return: CF set on error if AH = 11h (corrected ECC error), AL = burst length CF clear if successful AH = status (see #00234) AL = number of sectors transferred (only valid if CF set for some BIOSes) Note that CL starts at 1, not zero. We want to read the first sector of the HD, that is at CHS=0:0:1. First pick an address - 100 is usually pretty good. -a100 16A0:0112 mov ax, 201 16A0:0115 int 13 16A0:0116 int 3 <-- break. So the program stops. 16A0:0117 Then we fix the registers -rdx :80 <-- 80h is the first physical HD, 81h is the second -rbx :3000 <-- no special reason, just habit -rcx :1 then we make the program do its thing -g=100 and we can look at the data at 3000 -d3000 31ff If the last two bytes aren't 55AAh, then you didn't read a DOS boot sector.

0

Hey silly question ? Is your HD jumpered as master??????????

0