sic@ritcsh.UUCP (Eric A. Neulight) (09/01/88)
I am posting this in response to some feedback/problems that have
been brought to my attention concerning my submission of "256keys",
a PC 256 key type-ahead buffer program, to comp.binaries.ibm.pc.
In the accompanying documentation I stated that it worked with
most generic PCs. This of course was a brave, bold, and extremely
stupid promise. Invariably some people have not been able make it
work on their PC variant. Here are some possible reasons/hints/suggestions.
IBM's PC BIOS keyboard interrupt routine assumes that the keyboard
type-ahead buffer resides somewhere within segment 40h (BIOS' data segment).
That is, within reach of segment 40h. Remember were talking about an (ack!)
Intel processor, you know, ambiguous addressing, 4096 ways to describe
the same location, tons of processor overhead spent just setting up segment
addressibility (all kinds of wisdom there, huh). Within reach of
segment 40h means that the absolute address for the 256keys 512 byte buffer
can be as high as 64k-512+400h = 10200h.
1020:0000 = 1000:0200 = 0821:7FF0 = 005A:FC60 = 0040:FE00 .....
It appears that in many '386 machines, and I guess some other types,
even though BIOS may be compatible and hardcode the buffer within segment 40h,
DOS loads higher in memory, therefore loading 256keys even higher, past
the 10200h cut-off. How do you get around it (aside from burning a patched
BIOS ROM [don't think it hasn't crossed my mind])? I do not have access to
a '386 machine so I can not try this idea, but I distributed the short and
simple source code for 256keys. Try rewriting it as a dumb device driver,
just maybe DOS will load it lower in memory. If you are already loading
other device drivers in CONFIG.SYS you may have to do this anyway if the
device drivers are large (since they are loaded first). If that does not
work you can either write your own keyboard interrupt driver or you are SOL.
I have thought of a few other kludgy ways to get a large type-ahead
buffer, but they are too repulsive to repeat here.
If 256keys runs and states that it can not locate within seg 40h, and you are sure that it is the first memory resident program being loaded, and
you are not a great hacker, well, it didn't cost nuthin'. (sorry)
==============================================================================
CLAIMER: Well -- I wrote it! Eric Alan Neulight
"Nothing is Impossible -- Just Impractical." Electrical Engineering
"INSANITY is just a state of mine." Computer Science House
Rochester Institute of Technology
BITNET: EAN4762@RITVAX UUCP: ...!rutgers!rochester!ritcv!ritcsh!sic
==============================================================================Ralf.Brown@B.GP.CS.CMU.EDU (09/02/88)
In article <4050@ritcsh.UUCP>, sic@ritcsh.UUCP (Eric A. Neulight) writes: } IBM's PC BIOS keyboard interrupt routine assumes that the keyboard }type-ahead buffer resides somewhere within segment 40h (BIOS' data segment). } } It appears that in many '386 machines, and I guess some other types, }even though BIOS may be compatible and hardcode the buffer within segment 40h, }DOS loads higher in memory, therefore loading 256keys even higher, past }the 10200h cut-off. How do you get around it (aside from burning a patched }BIOS ROM [don't think it hasn't crossed my mind])? I do not have access to It wouldn't be the 386 machines' fault, but rather a recent version of DOS. DOS has really grown since 3.1, so I'm not surprised that it now uses too much memory. You may still be able to expand the buffer to 128 keys, though. In both DOS 2.10 and 3.10, the area from 60h:0 to 70h:0 is unused! DOS 1.x loads beginning at 60h:0, but DOS 2.10 and 3.10 load starting at 70h:0. As far as I can tell, all 60h:0 is ever used for in these versions is by the boot sector, which loads the first directory sector at 50h:0 (thru 70h:0), and then only looks at the first two entries. No guarantees, but if you twiddled the BIOS keyboard buffer pointers to move the buffer to 60h:0, you should be able to get a 128-key buffer. Disclaimer: I haven't tried it, and have no need to, as DESQview gives a 128-key buffer for EACH program anyway. -- 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 |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
rk@cs.strath.ac.uk (Richard Kingslake) (09/07/88)
I now have zoo, looz, booz, sez (& fiz - but I have never used it,
fortunately). What an excellent collection. They do nearly all I want.
My 20Mb disc now holds about 30Mb of information!
May I ask R.D if there are any more programs to come in the zoo toolkit?
The only one that I can see is missing is the "Self-extract and Execute"
program. Should it perhaps be called sex? :-) What it would do is to run
rather like a sez-generated archive, but it would only extract a single
file and then place it directly in memory and execute it - rather like
zoo xx archivename programname
does.
If this had an overhead of, say, 3000 bytes, and if a compression ratio of
30% is achieved (as is about normal for .exe files on my machine) then
substantial disc space could be saved for any executable file over 10K
bytes without any "effort". The file could simply be obeyed exactly as
usual. Of course, the load time would be increased, but for relatively
rarely used software this may not be a problem.
--
Richard Kingslake
JANET: rk@uk.ac.strath.cs
ARPA: rk@cs.strath.ac.uk
UUCP: !seismo!mcvax!ukc!strath-cs!rk or rk@strath-cs.uucp