keithe@tekgvs.TEK.COM (Keith Ericson) (06/25/88)
In article <45919AHS@PSUVM> AHS@PSUVM.BITNET writes: > >Tom replies: >>In article <8806190331.AA02653@slvblc.UUCP> AHS%psuvm.bitnet@rutgers.edu writes: > >>This program does work as advertised! > > Prove it. Publish the correct symbolic dissassembly. I am > not going to load in my machine routines that deeply alter > its guts without looking at the code first. > ["deeply alter its guts" referring to stack manipulation in the program - kde] You know, some people would complain if they were handed the earth on a silver platter. The person posting this veiled accusation is certainly not worth my time of posting a rebuttal, but Tom's work and reputation most certainly are. It distresses me greatly that <whover this person is> (why doesn't he or she include their name in their postings, by the way?) feels that their cautious skepticism must be blasted all over the Net instead of conducted in civil, private e-mail. QUESTIONS such as this should be asked and answered via private e-mail, with RESULTS posted to this wider forum. Anyway, simply because <whover this person is> is incapable of properly disassembling Tom's program is not grounds for accusations of skulduggery or devious programming. I know Tom as a co-worker and friend; the reason the code may be difficult to exegete is that it is well written by a craftsman who knows the ins and outs of the IBM-PC/AT/Clone/DOS architecture better than anyone else I know. Not satisfied with the size/speed performance of "conventional" programming languages, Tom is an acknowledged expert in FORTH programming, having written (among many other things) a compiler which inhales FORTH code and exhales tight, well-optimized machine code. It is this output that you have as his keyboard macros. FORTH uses stacks as a matter of course and this is exemplified in Tom's keyboard macros. To castigate the program and/or Tom (as was done in these postings) is simply a demonstration of one's onwn ineptitude and lack of proper human-relationship abilities. This will be my only posting on the subject: public rebuttals and retorts will be ignored; private e-mail will be answered (given a useable return path is provided/discernable). Thank you for your patience in reading this. keith
AHS@PSUVM.BITNET (06/27/88)
Keith write: >>From: keithe@tekgvs.TEK.COM (Keith Ericson) >>Subject: Decency on the Net (was Re: Keyboard "fix" TSRs) >>Date: 24 Jun 88 17:37:44 GMT >>Organization: Tektronix, Inc., Beaverton, OR. >> >>In article <45919AHS@PSUVM> AHS@PSUVM.BITNET writes: >>> >>>Tom replies: >>>>In article <8806190331.AA02653@slvblc.UUCP> AHS%psuvm.bitnet@rutgers.edu writes: >>> >>>>This program does work as advertised! >>> >>> Prove it. Publish the correct symbolic dissassembly. I am >>> not going to load in my machine routines that deeply alter >>> its guts without looking at the code first. >>> >> >>["deeply alter its guts" referring to stack manipulation in the >> program - kde] Manipulating the stack will not move keys around the keyboard. No. To move the keys around, you need to alter the guts of the machine such as re-vectorizing some interupts, such as Int 09 (or 15, or ???), and perhaps play with IN and OUT ports -- these are not trivial programs. If done improperly (and bugs are always a possibility), they will create instabilities or conflicts. (I am sure you have heard of TSR conflicts, especially among those who use Int 09). Now, these interrupts are so hush hush that, for example: Int 9 (the keyboard interrupt): Int 9 is not described in Ray Duncan's Advanced DOS. He only discourages such programing and says to those who must ignore his advice to go and study the assembly code for the keyboard handler in the IBM tech ref manual. Int 9 is not described in Ralf Brown's superb and super-extensive documentation of practically all interrupts. His only entry is: Last edited 1/30/88 ----------------------------------------------------------- INT 09 - MATH UNIT PROTECTION FAULT (80286 protected-mode internal) ----------------------------------------------------------- Not a word on the keyboard (I am *not* blaming Ralf -- I am *too* grateful to him for having done this compilation. I am just saying that Int 9 is undocumented and information on Int 9 is hard to come by -- which increases the chance of programming bugs). >>You know, some people would complain if they were handed the earth >>on a silver platter. >> >>The person posting this veiled accusation Which accusation ? >>is certainly not worth my >>time of posting a rebuttal, but Tom's work and reputation most >>certainly are. >> >>It distresses me greatly that <whover this person is> (why >>doesn't he or she include their name in their postings, by >>the way?) feels that their cautious skepticism must be >>blasted all over the Net instead of conducted in civil, >>private e-mail. QUESTIONS such as this should be asked and >>answered via private e-mail, with RESULTS posted to this >>wider forum. The challenge to dissassemble the KBD* programs was made publicly, not privately. >>Anyway, simply because <whover this person is> is incapable of >>properly disassembling Tom's program is not grounds for accusations of >>skulduggery or devious programming. No personal remarks were made. Only questions about the code and the programming intentions of the programmer concerning the program flow were asked. >>I know Tom as a co-worker and >>friend; the reason the code may be difficult to exegete is that it is >>well written by a craftsman who knows the ins and outs of the >>IBM-PC/AT/Clone/DOS architecture better than anyone else I know. The code to be dissassembled was written by a compiler. Typically, a human writes assembly differently; often clearer, sometimes elegantly. From my readings, the best compilers are not yet there. >>Not >>satisfied with the size/speed performance of "conventional" >>programming languages, Tom is an acknowledged expert in FORTH >>programming, having written (among many other things) a compiler which >>inhales FORTH code and exhales tight, well-optimized machine code. Tight and well optimized code are relative notions. I cannot believe that the standard of comparison you are using is hand-crafted assembly. More likely, you are comparing to the output of a set of comparable compilers. >>It >>is this output that you have as his keyboard macros. FORTH uses stacks >>as a matter of course and this is exemplified in Tom's keyboard >>macros. To castigate the program and/or Tom (as was done in these >>postings) Again, read the original. No personal remarks were made. Only questions about the code and programming intentions were asked. Remember, the posting of the programs contained a public challenge to dissassemble them. The wording was ambiguous and suggested that dissassembly was either trivial or a challenge. >>is simply a demonstration of one's onwn ineptitude and lack >>of proper human-relationship abilities. >> >>This will be my only posting on the subject: public rebuttals and >>retorts will be ignored; private e-mail will be answered (given a >>useable return path is provided/discernable). >> >>Thank you for your patience in reading this. >> >>keith A final note: I have both separately and by private mail thanked Tom Almy for showing us how to use Int 15 to remap the keyboard. --------------------------------------
Ralf.Brown@B.GP.CS.CMU.EDU (06/28/88)
In article <46157AHS@PSUVM>, AHS@PSUVM.BITNET writes: } Int 9 (the keyboard interrupt): } } Int 9 is not described in Ray Duncan's Advanced DOS. He only } discourages such programing and says to those who must ignore his } advice to go and study the assembly code for the keyboard handler in } the IBM tech ref manual. } } Int 9 is not described in Ralf Brown's superb and super-extensive } documentation of practically all interrupts. His only entry is: } } Last edited 1/30/88 } ----------------------------------------------------------- } INT 09 - MATH UNIT PROTECTION FAULT (80286 protected-mode internal) } ----------------------------------------------------------- Actually, it is mentioned, but slightly hidden: INT 08 thru 0F - VECTORED HARDWARE LINES In IBM, these 8 interrupts are generated in response to IRQ 0 through IRQ 7 (if enabled via port 21h). [Tandy 1000] [Adapters] IRQ0 - timer interrupt IRQ1 - keyboard interrupt ^^^^ this is INT 9 } } Not a word on the keyboard (I am *not* blaming Ralf -- I am *too* } grateful to him for having done this compilation. I am just saying } that Int 9 is undocumented and information on Int 9 is hard to come } by -- which increases the chance of programming bugs). The problem with INT 9 is that in order to do anything useful, you have to munge with the hardware. If your machine has even the slightest incompatibility in this area hardware-wise, you will have even more problems. And each of IBM's three different "standard" keyboards has a slightly different interface.... } A final note: I have both separately and by private mail } thanked Tom Almy for showing us how to use Int 15 to remap the } keyboard. Unfortunately, the INT 15 call for remapping the keyboard is only available in recent BIOSes. My 6/86 Award BIOS knows nothing about that hook. INT 15 - OS HOOK - KEYBOARD INTERCEPT (AT model 3x9,XT2,XT286,CONV,PS) AH = 4Fh AL = scan code CF set Return: AL = scan code CF set Note: Called by INT 9 handler to translate scan codes -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I | claimed something?| Insert your favorite quote here
few@quad1.UUCP (07/01/88)
In article <22c78b7a@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: >Unfortunately, the INT 15 call for remapping the keyboard is only available in >recent BIOSes. My 6/86 Award BIOS knows nothing about that hook. >INT 15 - OS HOOK - KEYBOARD INTERCEPT (AT model 3x9,XT2,XT286,CONV,PS) > AH = 4Fh > AL = scan code > CF set >Return: AL = scan code > CF set >Note: Called by INT 9 handler to translate scan codes INT 15H used to be the cassete tape interface. Since nobody really cared about this, many people have re-used this INT in the past (T*pView, various network handlers, ...). It appears that BigBlue has again changed the meaning. I use INT 9H and 16H in some keyboard handlers, but I think I'll stay away from INT 15H... -- Frank Whaley Senior Programmer Quadratron Systems Incorporated sdcrdcf! scgvaxd! bellcore! ttidca! ihnp4!psivax!quad1!few Water separates the people of the world; Wine unites them.
ralf@b.gp.cs.cmu.edu (Ralf Brown) (07/02/88)
In article <1584@quad1.quad.com> few@quad1.quad.com (Frank Whaley) writes: }In article <22c78b7a@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: }>INT 15 - OS HOOK - KEYBOARD INTERCEPT (AT model 3x9,XT2,XT286,CONV,PS) }> AH = 4Fh }INT 15H used to be the cassete tape interface. Since nobody really cared It still is, for AH = 0,1,2,3 (of course, very few machines have a cassette port anymore....) INT 15h has become a catch-all, much like INT 2Fh. At least the additions are downward compatible, not like the "Get Country- Dependent Info" DOS call (INT 21h/AH=38h), which almost completely changed the format of the returned data structure between DOS 2.x and 3.x. -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?