• Please review our updated Terms and Rules here

Disabling the PrtSc key

R

Retro Canada

Experienced Member
Joined
Aug 23, 2012
Messages
280
Location
Vancouver, BC
Hi,

Everytime I press the right shift on a model F keyboard (PC5150-2) I have 75% of chance in pressing both keys, (thanks to the sort Shift) and the DOS 3.3 locks up for 10 or even more seconds.

Is there a way to disable that ? I don't have a printer nor I am buying one :)

Can we change the BIOS ? I am using the Super PC-XT Bios...
 
Yes, you can change the BIOS--or you can install an alternate TSR handler for INT 5 that simply returns from the interrupt. PrtSc simply "calls" INT 5 when pressed. Alternate print-screen routines routinely "hook" this interrupt also.
 
Here's a piece of code I quickly slapped together for you; View attachment DISPRTSC.ZIP

Looks like this in DEBUG;
Code: 
150C:0100 B0CF          MOV     AL,CF
150C:0102 BF00F0        MOV     DI,F000
150C:0105 8EDF          MOV     DS,DI
150C:0107 8EC7          MOV     ES,DI
150C:0109 31FF          XOR     DI,DI
150C:010B B9FFFF        MOV     CX,FFFF
150C:010E F2            REPNZ
150C:010F AE            SCASB
150C:0110 8D55FF        LEA     DX,[DI-01]
150C:0113 B80525        MOV     AX,2505
150C:0116 CD21          INT     21
150C:0118 C3            RET
 
Cute! Could shave three bytes by changing MOV DI,F000 to XOR DI,DI (and removing the second XOR DI,DI) because, hey, there's got to be an IRET in the first 64K of the system where DOS is loaded ;-)
 
Trixter said:
Cute! Could shave three bytes by changing MOV DI,F000 to XOR DI,DI (and removing the second XOR DI,DI) because, hey, there's got to be an IRET in the first 64K of the system where DOS is loaded ;-)
Click to expand...

Yeah, and with a bit of luck it will still be there when the user hits PrtSc. :D
 
Much safer to rely on the immutability of BIOS ROM... Besides, Krille's code isn't a TSR--it's execute-and-go-away. You'll be using at least 512 bytes to store it, so no need to gild the lily.
 
Krille said:
Yeah, and with a bit of luck it will still be there when the user hits PrtSc. :D
Click to expand...

Actually, I thought about that before I wrote my response -- I think it is highly unlikely that an IRET will go away, since it's not like anything overwrites DOS or relocates it. The only fear is that you'll hit a CF that isn't actually an IRET.

This is tongue-in-cheek of course; the ROM is 100% safe.
 
Well the solution for IBM-PC/XT and Super PC XT BIOS is very simple:

Just set the byte at [0050:0000] to 1. The BIOS uses this position to prevent reentrant INT. Set it back to 0 to activate it again.

Tested and worked on my Super PC XT BIOS.
 
If anyone is interested I made a very simple toggle executable. Just add to your autoexec.bat and call it again if by any chance you are going to print the screen...

Code: 
.MODEL SMALL
.STACK 100h
.DATA
	ENA_MSG	DB "PrtSc Key is activated$"
	DIS_MSG DB "PrtSc Key is disabled$"
.CODE
BEGIN:	
	XOR	AX,AX
	MOV	DS,AX
	MOV	SI,0500h
	CMP	[SI],AL
	JZ	DISABLE
	MOV	[SI],AL
	LEA	DX,ENA_MSG
	JMP	DONE
DISABLE:
	MOV	BYTE PTR [SI],01h
	LEA	DX,DIS_MSG
DONE:
	MOV	AX,@DATA
	MOV	DS,AX
	MOV	AH,09h
	INT	21h
	MOV	AH,04Ch
	XOR	AL,AL
	INT	21h

	END	BEGIN

View attachment PRTSC.ZIP
 
Had some time to kill at lunch and got this down to 70 bytes:

Code: 
; Must make as a .com file, as we make assumptions about our environment.

BEGIN:
        PUSH    DS                      ;DOS print string needs valid DS
        MOV     DS,BX                   ;BX = 0 at .COM start
        INC     BX
        XOR     [0500h],BL              ;Toggle the value at 0:50h; sets zero flag
        POP     DS                      ;Restore DS for DOS printstring func.
        JNZ     DISABLE                 ;If 1, it's "in progress" (disabled)
        MOV     DX,OFFSET ENA_MSG
        JMP     DONE
DISABLE:
        MOV     DX,OFFSET DIS_MSG
DONE:
        MOV     AH,09h
        INT     21h

        RET

ENA_MSG DB "PrtSc Key is activated$"
DIS_MSG DB "PrtSc Key is disabled$"
 
Trixter said:
Actually, I thought about that before I wrote my response -- I think it is highly unlikely that an IRET will go away, since it's not like anything overwrites DOS or relocates it. The only fear is that you'll hit a CF that isn't actually an IRET.
Click to expand...

Yeah, I was thinking of the interrupt vector table and stuff in the BIOS Data Area like the timer ticks since midnight counter.

Trixter said:
Had some time to kill at lunch and got this down to 70 bytes:
Click to expand...

I too got the urge to improve that code. I originally wrote this in DEBUG but rewrote it for NASM for readability;
Code: 
	org	100h

	pop	ds			; DS = Zero
	push	ds
	mov	dh, 1
	xor	[0500h], dh
	push	cs
	pop	ds
	jnz	Disable
	mov	dl, s$Enabled-$$ & 0FFh
	db	3Dh			; SKIP2B f = cmp ax, imm
Disable:
	mov	dl, s$Disabled-$$ & 0FFh
	mov	ah, 9
	int	21h
	ret

s$Enabled	db 'PrtSc Key is enabled$'
s$Disabled	db 'PrtSc Key is disabled$'
65 bytes so 5 bytes less but 2 of those is because I changed a string. BTW, regarding BX=0 at start, is that always true for all DOS versions? Is it documented somewhere? Does it apply for EXE programs as well as COM?
 
I fail to understand the reason for all of the tinkering--please forgive me.

If the program is smaller than a cluster and is an "execute and go away" (i.e. not a TSR), what does size matter?

Or is this a manifestation of some other deeper psychological gender-related phenomenon? :)
 
Krille said:
65 bytes so 5 bytes less but 2 of those is because I changed a string. BTW, regarding BX=0 at start, is that always true for all DOS versions? Is it documented somewhere? Does it apply for EXE programs as well as COM?
Click to expand...

www.sizecoding.org was created to answer this question. And it should be true for most DOS version that matter (ie. 2.x and later). More info here: http://www.sizecoding.org/wiki/Getting_Started#.COM_file_defaults

Chuck(G) said:
I fail to understand the reason for all of the tinkering--please forgive me.
Click to expand...

www.sizecoding.org :) It's a challenge just for the challenge's sake, like locksport or democoding.
 
Last edited:
Well, the HOLD key is scancode 46h, so installing a custom keyboard handler to intercept 46h and discard it would do the trick. That's not what the above program does, however.
 
You must log in or register to reply here.
Back
Top