Every few years, I get the idea in my head that it would be cute/
interesting to write a DOS TSR that would display CS:IP in the top
corner of the screen, so you could watch the numbers fly by, see if
your locked up machine is actually locked up or just stuck in a dumb
loop somewhere, etc. And, every few years, I lazily type MOV AX,IP
into debug and am reminded that you can't directly read IP. And then
I realize that wouldn't be useful anyway.
Thinking about this further, I guess there are two ways to implement
an "execution monitor" in a small TSR:
- Hook the system timer, increase timer update rate to rate*4 (so it
fires at 72.8Hz instead of 18.2Hz), so that I the updates exceed the
screen's refresh rate, and then peek at the stack every time the ISR
is executing to glean the CS,IP,flags and put them to the screen
or
- Turn on the Trap flag and update the display on every instruction.
Of course this will slow down program execution by a factor of 500 or
more, making it impractical on anything slower than a 486 probably.
Are there any other ways of implementing the above I may be missing?
More importantly, has someone written a little toy like this already
to save me the trouble?
|
|
0
|
|
|
|
Reply
|
MobyGamer301 (139)
|
1/20/2012 8:27:26 PM |
|
Jim Leonard wrote:
> Every few years, I get the idea in my head that it would be cute/
> interesting to write a DOS TSR that would display CS:IP in the top
> corner of the screen, so you could watch the numbers fly by, see if
> your locked up machine is actually locked up or just stuck in a dumb
> loop somewhere, etc. And, every few years, I lazily type MOV AX,IP
> into debug and am reminded that you can't directly read IP. And then
> I realize that wouldn't be useful anyway.
>
> Thinking about this further, I guess there are two ways to implement
> an "execution monitor" in a small TSR:
>
> - Hook the system timer, increase timer update rate to rate*4 (so it
> fires at 72.8Hz instead of 18.2Hz), so that I the updates exceed the
> screen's refresh rate, and then peek at the stack every time the ISR
> is executing to glean the CS,IP,flags and put them to the screen
I'm really not sure what could be the gain of such an attempt.
If any application code like to know why and when its terminated by the
OS seems to be an obvious need to tell why when and where..
this information is usually gathered and stored in crash.log or else.
sorry I can't/wont remember what this question were about [error_code?] ?
__
wolfgang (the elder, and a short hint: noone can buy experience)
|
|
0
|
|
|
|
Reply
|
nowhere583 (184)
|
1/20/2012 9:07:46 PM
|
|
"Jim Leonard" <mobygamer@gmail.com> wrote in message
news:4d14f460-810a-448c-93ad-a8577a584488@t13g2000yqg.googlegroups.com...
> Every few years, I get the idea in my head that it would be cute/
> interesting to write a DOS TSR that would display CS:IP in the top
> corner of the screen, so you could watch the numbers fly by, see if
> your locked up machine is actually locked up or just stuck in a dumb
> loop somewhere, etc. And, every few years, I lazily type MOV AX,IP
> into debug and am reminded that you can't directly read IP. And then
> I realize that wouldn't be useful anyway.
>
> Thinking about this further, I guess there are two ways to implement
> an "execution monitor" in a small TSR:
>
> - Hook the system timer, increase timer update rate to rate*4 (so it
> fires at 72.8Hz instead of 18.2Hz), so that I the updates exceed the
> screen's refresh rate, and then peek at the stack every time the ISR
> is executing to glean the CS,IP,flags and put them to the screen
>
Skips stuff ... Well, it should on modern hardware. ;-)
> or
>
> - Turn on the Trap flag and update the display on every instruction.
> Of course this will slow down program execution by a factor of 500 or
> more, making it impractical on anything slower than a 486 probably.
>
It works though. IIRC, interrupts turn off TF. So, you'd have to reenable
to trace them.
> Are there any other ways of implementing the above I may be missing?
x86 emulation on x86?
Custom ISA card with electronic display?
Given the old hardware you code for, I'd go with the second one, if you're
up to that ... It should be similar to one of those POST code cards. I.e.,
I'd guess that it'd be a few latches (perhaps 74LSxxx series) to latch the
address and a maybe a display driver chip and some display digits.
> More importantly, has someone written a little toy like
> this already to save me the trouble?
....
Rod Pemberton
|
|
0
|
|
|
|
Reply
|
do_not_have7664 (117)
|
1/21/2012 8:42:42 PM
|
|
On Jan 21, 2:42=A0pm, "Rod Pemberton"
<do_not_h...@nospicedham.noavailemail.cmm> wrote:
> Given the old hardware you code for, I'd go with the second one, if you'r=
e
> up to that ... =A0It should be similar to one of those POST code cards. =
=A0I.e.,
> I'd guess that it'd be a few latches (perhaps 74LSxxx series) to latch th=
e
> address and a maybe a display driver chip and some display digits.
Never considered it -- great idea!
|
|
0
|
|
|
|
Reply
|
mobygamer (60)
|
1/23/2012 7:28:14 PM
|
|
|
3 Replies
39 Views
(page loaded in 0.063 seconds)
|