Date:	Mon, 27 Mar 1995 06:48:48 -0800 (PST)
From:	".ASM SoftWare Systems" <rdc AT freenet DOT vancouver DOT bc DOT ca>
Subject:	Re: How to debug after playing with timer-int ?
To:	THE MASKED PROGRAMMER <badcoe AT bsa DOT bris DOT ac DOT uk>
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu, badcoe AT bsa DOT bris DOT ac DOT uk

THE MASKED PROGRAMMER <badcoe AT bsa DOT bristol DOT ac DOT uk> wrote:
: Hi,Badders here again.
:         I'm still having some difficulty in my attempt to use a redirected
: int 0x8 and a reprogrammed PIT to do screen-refreshes. Let me just ask a few
: questions out of context to see if I'm missing anything obvious:
and detailed horrid debug interupt troubles ...

I was playing with an on screen clock that updated itself decently and
kept correct time while my program ran (WHEW!) ...

Caused me some pain ...

I did this long ago but from memory ...


You must find where protected mode is entered (in the debugger's source) ...

Patch the source for debug32 to permit TurboC to single step through it
without crashing (add -I_forgot- into the go32.c module, both sides of
the coming in and the going out to set those PIT flags just before entering
PMode - this was a few versions ago also!)

Now you ought to be able to 'step over' and execute your program (written
and compiled under gcc - now being debugged by a TurboC compiled version
of debug32) until it hits protected mode (for whatever reason) - now there
can be 'nothing?' going on 'behind-your-back'.

You can be more selective about what kinds of protected mode fault
you trap by hacking in stop points and recompiling the debugger ...


IF you place your breakpoint (eventually) right before it crashes
you might be able to stop it (and perhaps change something) and fix it
and continue it on it way - Apply the new patch into the debugged program
(not the debugger - be careful 'where' you 'really' are).

  IF your REALLY good at it ...
When it crashes write down the go32 or debug32 error message (look at
QEMM messages also if they show up) and find what produces it in either
go32 or debug32 and trace BACKWARDS -- Real tough since 'calls' can come
from out of the ether - if you can find what initiates the bug, it's gone.

- Raw text -