creps@silver.bacs.indiana.edu (11/10/87)
This may have been discussed before, but I just noticed it. On DOS 3.21, if I type ^P at the system prompt the cursor moves back to the beginning of the line, and then the keyboard locks up, although I can still reboot with <ctrl><alt><del>. Neither ^C nor ^<break> will do anything. Anyone know of a patch for this? By the way, this is on a clone, although nothing else has ever failed to work properly on it. Before you take the time to mail me, you might check replies to this. I'll post a reply if and when I get it figured out, or someone mails me a solution. - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu
creps@silver.bacs.indiana.edu (11/11/87)
I've been told that ^P acts like control-printscreen. Since I don't have a printer connected, that's why it locks up.
jojo@speedy.WISC.EDU (Jon Wesener) (11/11/87)
In article <15000046@silver> creps@silver.bacs.indiana.edu writes: > > I've been told that ^P acts like control-printscreen. Since I don't >have a printer connected, that's why it locks up. Well, then try hitting the break key on an enhanced keyboard about 6 or 7 times and see if that doesn't hang the machine to hell. You get an internal stack error, and have to turn it off to restart it. This happens on both of the enhanced keyboard machines I have seen. bad bios? --j jon wesener jojo@speedy.wisc.edu "remember kids, just say NO! to MSDOS"
jgray@toad.pilchuck.Data-IO.COM (Jerry Late Nite Gray) (11/11/87)
In article <15000045@silver>, creps@silver.bacs.indiana.edu writes: > > > This may have been discussed before, but I just noticed it. On > DOS 3.21, if I type ^P at the system prompt the cursor moves back > to the beginning of the line, and then the keyboard locks up, although > I can still reboot with <ctrl><alt><del>. Neither ^C nor ^<break> will > do anything. Anyone know of a patch for this? By the way, this is on a I would have replied by Email but I have a question for the general public. I saw the same thing (sort of) but it usually occured when using ^P within Emacs. There was generally no problem until exiting the program and the system would lock up. I found out later when I bought an NEC P6 printer (very happy with it, best investment I've made) that this problem occurred due to the PC trying to write to a non-existant printer and $##*$&^$#*$& DOS not dealing with it in a civilized manner. Whenever this happens now, I just enable the printer and it unlocks the system by generating the familiar : Trying to write to device driver Abort, Retry or Ignore: Of course I have to type "Retry" since anything else will cause whatever task I am running to abort (Stupid $#%&^&#%#&^#&%^ OS). My general question is how can I temporarily suspend the ^P function when entering Emacs. I have source code and if I only know how I would compile in the change. I am too inflexible to re-bind the previous line key to anything other than ^P. --------------- Jerrold L. Gray UUCP:{ihnp4|caip|tektronix|ucbvax}!uw-beaver!tikal!pilchuck!jgray USNAIL: 10525 Willows Road N.E. /C-46 Redmond, Wa. 98052 (206) 881 - 6444 x470 Telex: 15-2167
kneller@cgl.ucsf.edu (Don Kneller) (11/12/87)
In article <753@pilchuck.Data-IO.COM> jgray@toad.pilchuck.Data-IO.COM (Jerry Late Nite Gray) writes: >In article <15000045@silver>, creps@silver.bacs.indiana.edu writes: >> >> >> This may have been discussed before, but I just noticed it. On >> DOS 3.21, if I type ^P at the system prompt the cursor moves back >> to the beginning of the line, and then the keyboard locks up, although > >I saw the same thing (sort of) but it usually occured when using ^P within >Emacs. There was generally no problem until exiting the program and the >system would lock up. I found out later [...] that this problem occurred >due to the PC trying to write to a non-existant printer and $##*$&^$#*$& >DOS not dealing with it in a civilized manner. Whenever this happens >now, I just enable the printer and it unlocks the system by generating the >familiar : > Trying to write to device driver > Abort, Retry or Ignore: > >Of course I have to type "Retry" since anything else will cause whatever >task I am running to abort (Stupid $#%&^&#%#&^#&%^ OS). > >My general question is how can I temporarily suspend the ^P function when >entering Emacs. The ^P toggles the "echo output to printer" command, just like ^PrtSc. With DOS 3.1 (I can't speak for any higher), when the prompt to "Abort, Retry or Ignore" happens, type ^P (toggling echo off again), then `I' each time you get reprompted. After only a few prompts, the printer buffer will be flushed and you will be back in business. It is possible to disable ^P (and ^S) with the DOS IOCTL interrupt. This is used to put the terminal into "raw" mode. A side affect of doing this is that output to the screen is sped up quite a bit (perhaps twice to thrice as fast). This side affect happens because DOS no longer checks the input buffer for special characters whenever it *outputs* to the screen. Here is a code fragment in C for putting the terminal into raw mode and for returning it to the default. This is for Microsoft C but it is very short and should be easy to modify. #include <stdio.h> #include <dos.h> #define DEVICE 0x80 #define RAW 0x20 #define IOCTL 0x44 #define STDIN fileno(stdin) #define STDOUT fileno(stdout) #define GETBITS 0 #define SETBITS 1 static unsigned int old_stdin, old_stdout, ioctl(); void setraw() { old_stdin = ioctl(STDIN, GETBITS, 0); old_stdout = ioctl(STDOUT, GETBITS, 0); if (old_stdin & DEVICE) ioctl(STDIN, SETBITS, old_stdin | RAW); if (old_stdout & DEVICE) ioctl(STDOUT, SETBITS, old_stdout | RAW); } void unsetraw() { if (old_stdin) (void) ioctl(STDIN, SETBITS, old_stdin); if (old_stdout) (void) ioctl(STDOUT, SETBITS, old_stdout); } static unsigned int ioctl(handle, mode, setvalue) int handle, mode; unsigned int setvalue; { union REGS regs; regs.h.ah = IOCTL; regs.h.al = (unsigned char) mode; regs.x.bx = handle; regs.h.dl = (unsigned char) setvalue; regs.h.dh = 0; /* Zero out dh */ intdos(®s, ®s); return (regs.x.dx); } ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
guardian@laidbak.UUCP (Harry Skelton) (11/12/87)
If you have ansi.sys loaded via device=ansi.sys, you can remap your
keyboard to have the ^P to be made into a Null or space or a simple P.
It is a simple matter to do. Otherwise I would get a print spooler to
handle things for you. i.e. a print spooler will buffer the stuff and
you won't have to worry if you have a printer or not.
I'll post one to comp.binaries.ibm.pc soon.
.---------. OO OOOO OO
Harry Skelton : .-. : OO OO
guardian@laidbak.UUCP : `-'o : OO OOOO OO
{sun, spl1, ihnp4}!laidbak!guardian : O : OO O O OO
`---------' OO OOOO OO
The Far Seek ... Tales from the bad sector. OO
"As 'panic traps' appear across the console, Edward, once OOOOOOOOOO
again, finds Harry scratching his back against the
disk drives."sampson@killer.UUCP (Steve Sampson) (11/13/87)
The ^P on my clone turns the printer on like CP/M. Hitting ^P again turns it off. Course the printer probably needs to be turned on.
darrylo@hpsrlc.HP.COM (Darryl Okahata) (11/13/87)
In comp.sys.ibm.pc, kneller@cgl.ucsf.edu (Don Kneller) writes: [ ... ] > Here is a code fragment in C for putting the terminal into raw mode > and for returning it to the default. This is for Microsoft C but > it is very short and should be easy to modify. > [ ... ] > Don Kneller > UUCP: ...ucbvax!ucsfcgl!kneller > INTERNET: kneller@cgl.ucsf.edu > BITNET: kneller@ucsfcgl.BITNET > ---------- Be careful about placing DOS into RAW mode. In some versions of DOS (I don't know about the latest versions), using certain DOS functions while you are in RAW mode will cause DOS to HANG. I can't remember which DOS calls will do this (I think they are DOS handle read/write fcns) but, if anyone is interested, I'll dig up the info. Example (make sure the system is backed up before this is tried): Use a program to place the console in RAW mode. Then run LINK. Your machine will hang and require a reboot. -- Darryl Okahata {hplabs!hpccc!, hpfcla!} hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.