Random far jump????????

[kendfrey]

I was using the Bochs debugger to step through this:

Code: Select all

LBAToCHS:
div [SectorsPerTrack]
mov cl, dl
inc cl
div [NumberOfHeads]
mov ch, al
mov dh, dl
mov dl, [DriveNumber]
ret

Something weird happened the second (the first time it worked fine) time the procedure was called. Before executing div [NumberOfHeads], CS:IP was 0000:7d74. After executing it, CS:IP was f000:ff53, pointing to an iret instruction. This is not a one-time fluke. I spent hours trying to track this down. Why does this happen? It makes no sense to me.
I didn't capture register information (Bochs debugger freezes if untouched for too long), but [NumberOfHeads] is 2 (it is a word) and ax SHOULD be 33 (decimal) but MIGHT be 31 or maybe some other number. I will see if I can grab some register info.

[kendfrey]

Actually, it is the third time it is called, but that shouldn't matter too much. I have some register information now and I was wrong about one thing. ax should not be 0, but 1. I forgot about the previous div operation. According to the debugger, ax is 1, and the registers don't change when the div is executed (it just jumps to f000:ff53). It seems like the div is failing in some way. Why would it do this?

[egos]

I think you have division overflow. It's popular mistake in such routine. At least for first division you should use "double division" operation (to know why look at my post here). You can use divide routine from my boot loaders.

Code: Select all

;
; input:
;   ax:cx (lo:hi) - divident
;   bp - divisor
; output:
;   ax:cx - quotient
;   dx - remainder
;
divide:
  xor dx,dx
  xchg ax,cx
  div bp
  xchg ax,cx
  div bp
  ret

[kendfrey]

I don't really understand. What exactly is "division overflow"? And how would double division help?
I did see somewhere that zeroing dx beforehand would fix it. Is that true?

[theseankelly]

Could it be [sectorspertrack] or [number of heads] is accidentally a < 1 value? For example, 60,000/.5 = out of range for a 16 bit register.

[kendfrey]

Nope, those are fine. I don't know what the problem was, but zeroing dx did fix it.