pilgrimk@lafcol.UUCP (Guru Jee) (01/31/89)
I'm using INT 1CH to install a clock on my screen. Problem is that
it works when it wants to.
The problematic part of the code (at least I think that this might be
it) is:
....
GetIntVec($1C, Int1C);
SetIntVec($1C, @ClockProcedure); {call ClockProcedure ~ 18 time/sec}
....
then there is an exit procedure (yes, I did force a far call using $F+)
which contains, among other things
....
SetIntVec($1C, Int1C);
....
which is supposed to reset the INT 1C to its original address.
When the program works, it works FINE. I can simultaneously display
a clock and have the user type in stuff.
When it doesn't, it may do any of the following:
i. Never return to the C> prompt but the computer can be rebooted
using the Ctrl-Alt-Del sequence
ii. Never return the C> prompt and lock the keyboard up so
to reset, the ON/OFF switch must be used.
While running the program from within the integrated environment,
both of the afore-mentioned errors show up as stack overflow errors.
(at which point the computer crashes.) I have tried setting the
stack size to its limit (65520) but no way jose - same problem.
One last word. Without the INT 1C part, everthing works as I expect
it to - ALL THE TIME. Introduce the INT 1C and I have a temperamental
program.
Do I have to use STI and CLI instructions?
If so, should these be installed in the interrupt procedure?
Should I be using INT 1C in the first place?
One more thing. The code to display the time onscreen is contained in
a unit. The procedure which is global looks like
DisplayDate(X,Y: byte); {X,Y are screen coords}
Any helpful hints would be appreciated. If this made no sense to
you, or if you'd like to see the source code, I be happy to mail
it to you.rbw@williams.edu (02/01/89)
> I'm using INT 1CH to install a clock on my screen. Problem is that > it works when it wants to. The first questions I would ask are: 1) Is your handler using any of the TP I/O calls (read, write, etc)? These are not re-entrant, and you may be screwing things up if you call them from an interrupt. 2) Is your handler taking too long? I had that problem once. My handler was updating a number of things on certain occasions, and it would get caught in the next tick, and my global structures would go to chaos or worse. 3) Are you calling a DOS function? I can send you some pointers on using DOS functions from within interrupts, if you want. -Richard Ward rbw@cs.williams.edu Williams College, Williamstown, MA
abcscnuk@csuna.UUCP (Naoto Kimura) (02/02/89)
In article <369@lafcol.UUCP> pilgrimk@lafcol.UUCP (Guru Jee) writes:
]I'm using INT 1CH to install a clock on my screen. Problem is that
]it works when it wants to.
]
]The problematic part of the code (at least I think that this might be
]it) is:
]
] ....
] GetIntVec($1C, Int1C);
] SetIntVec($1C, @ClockProcedure); {call ClockProcedure ~ 18 time/sec}
] ....
* I know this is already obvious, but make sure that you used the
"interrupt" directive on ClockProcedure. This will assure that
ClockProcedure will use IRET instead of RET.
* Also make sure that you are not using "write" or "writeln" procedures to
write to the screen, as they may end up using the DOS routines, which are
not re-entrant. I might suggest using the BIOS routines instead.
//-n-\\ Naoto Kimura
_____---=======---_____ (csun!csuna!abcscnuk)
====____\ /.. ..\ /____====
// ---\__O__/--- \\ Enterprise... Surrender or we'll
\_\ /_/ send back your *&^$% tribbles !!pilgrimk@lafcol.UUCP (Guru Jee) (02/03/89)
To those of you who replied, thanks again. Haven't really solved the problem as yet, but I now have lots more to think about in terms of how I'm going to implement this Clock procedure of mine -Kenwyn