Jim Leonard wrote:
> How did people debug interrupt handlers,
> BIOS functions, etc. "back in the day"?
When I have the source of an interrupt procedure, I let it write 65
to B800:0000 and increment that at critical spots.
When the program freezes, the character in the upper left part of the
screen shows how far it came.
Stepping through Dos or Bios function is a pain, but with Turbo
Debugger you can set a breakpoint at the memory address that an
interrupt points to. Use SwapVectors and GetIntVec or look at 0:84
(0:$54) to find the address. Go to that address in the debugger, I
think the key-combination is Alt-F10 G, then set the breakpoint. Next
time the interrupt is called, it should be triggered.
But I don't know if this works with Int 21 because the debugger itself
also needs to call that, so it could break its own operation...
Also in your case that problem probably only occurs when your
interrupt is triggered while the Dos function is still running. That
won't happen when you are stepping through it, or if it does, all will
crash.
> I tried to optimize it today by having the disk
> ****tion read more than one audio/video chunk at a time. This
> dramatically improves disk performance, but now the program locks up
> after a random period of time seemingly INSIDE the INT 21,3f call to
> read data from a file handle.
I guess that something that you do in the interrupt disturbs DOS. For
example if that interrupts also calls a Dos function or you forgot to
save a register or your stack overflows.
hope this helps,
Klaus
|
