lansd@eecg.toronto.edu (Robert Lansdale) (04/05/89)
I have a small problem trying to get Control-Break to be recognized while in graphics mode, using Turbo-C's Hercules BGI driver (version 2.0). I initially revector the control-break handler to my own handler using the ctrlbrk(handler) command, which works fine while in text mode, but is ignored once I switch over to graphics. I assume the BGI driver is vectoring the interrupt to itself. Any suggestions? -- CSNET: lansd%eecg.toronto.edu, ARPA: lansd%eecg.toronto.edu@relay.cs.net Electrical Engineering Computer Group, University of Toronto.
hollombe@ttidca.TTI.COM (The Polymath) (04/07/89)
In article <89Apr4.202845edt.2759@godzilla.eecg.toronto.edu> lansd@eecg.toronto.edu (Robert Lansdale) writes: } I have a small problem trying to get Control-Break to be }recognized while in graphics mode, using Turbo-C's Hercules BGI driver }(version 2.0). I initially revector the control-break handler to my own }handler using the ctrlbrk(handler) command, which works fine while in text }mode, but is ignored once I switch over to graphics. I assume the }BGI driver is vectoring the interrupt to itself. Any suggestions? Does your graphics software spend much time in a tight loop? I had a similar problem with a mandelbrot program written in TC 2.0. It would ignore control-C interrupts until I put in some debug screen output. Then they worked just fine. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (04/08/89)
The problem is that checking for ^C is performed only on system calls (i.e. the I/O routines). When you are in graphics mode, these instructions are not being accessed. The solution is to include a call to kbhit() within a tight loop in graphics mode. This performs an unobtrusive system call during which ^C is serviced. (I assume one call to kbhit does not interfere with a later call?) Now, how to get rid of the ^C echo? -- Eric A. Raymond (raymond@ptolemy.arc.nasa.gov) "A hungry mob is an angry mob"
ching@pepsi.amd.com (Mike Ching) (04/08/89)
In article <4212@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: >In article <89Apr4.202845edt.2759@godzilla.eecg.toronto.edu> lansd@eecg.toronto.edu (Robert Lansdale) writes: >} I have a small problem trying to get Control-Break to be >}recognized while in graphics mode, using Turbo-C's Hercules BGI driver >}(version 2.0). I initially revector the control-break handler to my own >}handler using the ctrlbrk(handler) command, which works fine while in text >}mode, but is ignored once I switch over to graphics. I assume the >}BGI driver is vectoring the interrupt to itself. Any suggestions? > >Does your graphics software spend much time in a tight loop? I had a >similar problem with a mandelbrot program written in TC 2.0. It would >ignore control-C interrupts until I put in some debug screen output. Then >they worked just fine. > I believe the control-c interrupts are checked during console I/O so there needs to be getchar() and putchar() being executed somewhere for the interrupt to be recognized. Any program not doing I/O would also seem to ignore control-c. The debug screen output adds the I/O necessary for the program to respond to control-c. The original poster may be able to do something like add a keyboard test or print cursor positioning commands occasionally to allow program to respond to keyboard input. Mike Ching
keithm@wicat.UUCP (Keith McQueen) (04/11/89)
>In article <89Apr4.202845edt.2759@godzilla.eecg.toronto.edu> lansd@eecg.toronto.edu (Robert Lansdale) writes: } I have a small problem trying to get Control-Break to be }recognized while in graphics mode, using Turbo-C's Hercules BGI driver }(version 2.0). I initially revector the control-break handler to my own }handler using the ctrlbrk(handler) command, which works fine while in text }mode, but is ignored once I switch over to graphics. I assume the }BGI driver is vectoring the interrupt to itself. Any suggestions? The problem is that control-break is only checked by DOS during I/O and possibly at other key points during DOS interrupts. When you are in graphics mode, you have bypassed the DOS I/O and started outputing directly to video RAM. All is not lost, however. The keyboard interrupt that recognizes the actual keypress maintains a flag in low RAM that can be inspected by a user program at key intervals. The flag is kept at address 0:471 and is the high-order bit of the byte. This bit is set to a 1 when control-break is detected. Your program can check it at regular intervals and handle the situation accordingly. Be sure to clear the bit after you have handled things. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Keith McQueen, N7HMF Organization: Wicat Systems, Inc. | | 1116 Graff Circle Work (801)224-6605x422 | | Orem, Utah 84058 Packet: N7HMF @ NV7V | | Home (801)224-9460 Voice: 147.340 MHz or 449.675 MHz | | =====> My opinions are all mine... <===== | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -