bochs bugs

[Ozguxxx]

Hey, I think I have found two bochs bugs. They are related to its floppy "machine".

• fdd chip of bochs does not send an interrupt (which is irq6) after sending it a reset command however in intel manuals it is told that you should wait for an interrupt just after doing a reset, before sending a sense command status command. So while initalizing fdd you do not have to wait for an interrupt while you are using bochs, but on real hardware you have to wait for that interrupt.
• fdd chip of bochs does not send correct sr0 in result phase of read and (I hope) write operations. It sends updated head information (that is, it increases lba address and then sends its head value) however on real hardware that is not the case. On real hardware fdd chip sends head value of currently read or (I hope) written sector's lba.
• ???

Are there anybody who have seen these kind of errors? If not are there anybody whom I can ask about these errors?

BTW: I am saying "I hope" becasue I did not test these if they exist while writing or not. But while erading floppy they are existent.

[nullify]

Hey, I think I have found two bochs bugs. They are related to its floppy "machine".

Did you test for these "bugs" on real hardware also? Its very possible they are bugs in your code, not Bochs.

fdd chip of bochs does not send an interrupt (which is irq6) after sending it a reset command however in intel manuals it is told that you should wait for an interrupt just after doing a reset, before sending a sense command status command. So while initalizing fdd you do not have to wait for an interrupt while you are using bochs, but on real hardware you have to wait for that interrupt.

If when you executed a controller reset you also disabled the IRQ bit, e.g., outb(DOR, 0), you must set it again to receive the IRQ (e.g., outb(DOR, 0x0c) will re-enable the controller, DMA, and the IRQ again). I had no problems in Bochs with this.

fdd chip of bochs does not send correct sr0 in result phase of read and (I hope) write operations. It sends updated head information (that is, it increases lba address and then sends its head value) however on real hardware that is not the case. On real hardware fdd chip sends head value of currently read or (I hope) written sector's lba.

Again, Bochs worked as expected for me when I tested my floppy sector read/write operations.

Are you using the latest version of Bochs?

[Ozguxxx]

Hey, I have tested these on real hardware. I am telling about the differences between same code's operation in bochs and on real hardware(one pentium 800 and one pentium 166).
Well, I dont have code with me right now, I dunno if I am disabling irq but Ill check it as soon as I get back home. But a quick look at internet sources tells me that you are right, anyway Ill check em. Also thanx for your response...

[Ozguxxx]

Hey, OK, I think I might be wrong about floppy initialization procedure bug of BOCHS. Although I have not fully tested it, nullify seems to be correct about it. ;D

About second bug that BOCHS does not correctly update st0 after a floppy read, I am including different outputs of bochs and a pentium II 166Mhz machine below: (Code just does read of sector 17 from an 18 sectors per track floppy and then writes result phase bytes and halts.)

BOCHS output:

st0 = 4
st1 = 0
st2 = 0
result_cylinder = 0
result_head = 1
result_sector = 1
sector_size = 2
Before increment: 17


Machine output:

st0 = 0
st1 = 0
st2 = 0
result_cylinder = 0
result_head = 1
result_sector = 1
sector_size = 2
Before increment: 17


These are values that are read after result phase of a floppy read. I think, BOCHS sends a false st0 value because I am doing a 17. (logical sector, or lba address = 17) sector read which is on chs=0,0,18. After reading is done, assuming it was successful, lba address is updated, and new values are sent by result phase in result phase. Although these values are matching, st0 value is different because bochs sends updated_head<<2 (which is 4), while actual machine sends read_head<<2 (which is 0). Clearly one of these has to be wrong, I mean code also might be wrong but read is successful in the sense that it does reading correctly. In the fdd chip docs it just says that in result phase bit 2(third from last bit) of st0 is current head address. Can anybody check if it is in that way in their machine? Thanx.