consp06@bingsung.cc.binghamton.edu (Robert Konigsberg) (03/10/90)
All - ( Please forgive duplicate posting on ALT.MSDOS.PROGRAMMER:
1) I am working on a game in Turbo Pascal 5.5. I would like to set and
read the keyboard rates so that I can speed the keyboard. I want to
eliminate the wait before a key's 'repeat-mode' steps in. As well, I
want to restore the original values of whatever settings are needed.
Anyone out there on this one?
2) I have seend the messages going back and forth about starting a
secondary process, but I am still stuck as to how to actually start a
secondary process. I would like to keep it as generic as possible,
because I want to be able to spawn to 4DOS, let alone COMMAND.COM in
whatever subdirectory the file exists. All I know is that in TURBO PASCAL 5.5,
uses DOS;
.
.
.
exec(getenv('COMSPEC'),'WHAT GOES HERE?');
.
.
.
Is this right? I doubt it because it isn't working.. what should I do?
Also, is it important to know if I have enough memory to spawn this
secondary command process? How would I do that? What other side
effects am I not thinking about?
-Rob Konigsbergsorc@carina.unm.edu (Paul Caskey) (03/11/90)
On 9 Mar 90 18:31:00 GMT,
consp06@bingsung.cc.binghamton.edu (Robert Konigsberg) said:
Robert> 1) I am working on a game in Turbo Pascal 5.5. I would like
Robert> to set and read the keyboard rates so that I can speed the
Robert> keyboard. I want to eliminate the wait before a key's
Robert> 'repeat-mode' steps in. As well, I want to restore the
Robert> original values of whatever settings are needed. Anyone out
Robert> there on this one?
Boy does this sound familiar. I spent quite a few hours trying to do
exacly that. Are you trying to modify the sample Breakout program by
any chance? In any case, after digging into this problem all the way
down to inline assembly code, I came up empty-handed. The problem
lies in the fact that DOS will tell you if a key was just pressed or
just released. But nothing in between, until the key starts
repeating. On the AT, there is a way to change the time it takes for
a key to start repeating...but I don't think you can cut it to zero.
And I don't have an AT, so that wasn't a solution for me.
I figured if I dug deep enough, there would have to be some way to ask
the computer to go look at the space bar and tell me if it was up or
down at any given instant. But I really don't think you can. If you
do come up with a solution for this, I'd be really curious to see it.
Robert> ... but I am still stuck as to how to actually start a
Robert> secondary process. ...
Robert> All I know is that in TURBO PASCAL 5.5,
Robert> exec(getenv('COMSPEC'),'WHAT GOES HERE?');
Put any does command ('dir *.pas') for 'WHAT GOES HERE'. '' will just
give you the shell.
Robert> Is this right? I doubt it because it isn't working.. what
Robert> should I do? Also, is it important to know if I have enough
Robert> memory to spawn this secondary command process? How would I
Robert> do that? What other side effects am I not thinking about?
First of all, in TP5+ you have to call SwapVectors immediately before
and after every call to Exec. But the main problem is that you need
to change memory allocation with the $M directive to allow enough
memory for DOS to run. The examples in the manual use {$M 8192,0,0}
which leaves the max. amount of memory for things like Exec, but
leaves you with no heap for your program to use. I don't know enough
about memory allocation to say what would be a good compromise.
The solution I found to this is a program by TurboPower software
called ExecSwap. This program dumps the current state of the program
to a disk file, then calls Exec and you have almost all of your
computer's memory available in your DOS shell. Then when you exit
back, ExexSwap reads the "snapshot" of your program back off of disk
and into memory, and program execution continues as if nothing
happened. This program is "free to use as long as due credit is
given" and I got it off a local BBS. It comes with .pas and .asm
source code and a demo program. It's probably available on an ftp
site like wuarchive.wustle.edu or cheops.cis.ohio-state.edu, or I can
upload it somewhere as long it's free. :-)
Happy .PAS-ing...
--
/*********/
Paul Caskey
pcaskey@ariel.unm.edu
Only lawyers represent anyone's ideas but their own.
/*********/nraoaoc@nmtsun.nmt.edu (Daniel Briggs) (03/11/90)
In article <SORC.90Mar10131459@carina.unm.edu> sorc@carina.unm.edu (Paul Caskey) writes: > >I figured if I dug deep enough, there would have to be some way to ask >the computer to go look at the space bar and tell me if it was up or >down at any given instant. But I really don't think you can. If you >do come up with a solution for this, I'd be really curious to see it. The usual way to do this is to catch the hardware keyboard interrupt yourself. (This is interrupt nine, not sixteen.) The keyboard generates both a make and a break code for every keystroke. (I am not certain about repeats in this context.) You maintain a flag like "space_is_down" in your program. Set this true when you get a 'make code', and reset it to false when you get a 'break code'. Note that the normal BIOS simply ignores all break codes, and doesn't even pass them to DOS. (Except for the shift keys.) Programming the keyboard in this manner is a little gruesome. When I tried some of this, (a long time ago), I simply copied the code from the IBM XT Technical Reference manual BIOS listing. (I highly recommend this as required reading if you want to get down and dirty when programming PCs). Read the interrupt nine handler carefully, and it should tell you all you need. Beware, though, I have seen instances where some clone keyboards occasionally drop the break codes. This is bad news for a game such as I describe. ----- This is a shared guest account, please send replies to dbriggs@nrao.edu (Internet) Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801 (U.S. Snail)
sorc@carina.unm.edu (Paul Caskey) (03/12/90)
On 10 Mar 90 23:26:57 GMT, nraoaoc@nmtsun.nmt.edu (Daniel Briggs) said: Daniel> In article <SORC.90Mar10131459@carina.unm.edu> Daniel> sorc@carina.unm.edu (Paul Caskey) writes: > >I figured if I dug deep enough, there would have to be some way to ask >the computer to go look at the space bar and tell me if it was up or >down at any given instant. But I really don't think you can. If you >do come up with a solution for this, I'd be really curious to see it. Daniel> The usual way to do this is to catch the hardware keyboard Daniel> interrupt yourself. (This is interrupt nine, not sixteen.) Daniel> The keyboard generates both a make and a break code for every Daniel> keystroke. (I am not certain about repeats in this context.) Daniel> You maintain a flag like "space_is_down" in your program. Set Daniel> this true when you get a 'make code', and reset it to false Daniel> when you get a 'break code'. Note that the normal BIOS simply Yeah! Duh...how embarassing. I can't believe I didn't see that. For some reason it didn't occur to me that it's good enough to know whether a key has just been pressed or just been released, because like you said, if it was pressed and not released yet, it's still down. :-) Sigh....I hate it when I look so hard for something that I miss the obvious solution. Ah well. -- /*********/ Paul Caskey pcaskey@ariel.unm.edu Only lawyers represent anyone's ideas but their own. /*********/