29 Sep
2009
29 Sep
'09
9:30 a.m.
I recently wrote a ping utility for my DOS TCP/IP stack, and I wasn't
satisfied with the 55ms resolution of the BIOS timer tick. I used the
'delay' function in the Turbo C runtime which gives me a processor loop
that delays with 1ms granularity. I figured that I could call that and
poll for the ping reply, and the number of calls would be the ping
latency in ms.
Testing of delay in a controlled environment shows that at least on my
PCjr, it is off by 15%. My V20 processor might be part of the problem,
although I'm not going to fix it.
So I decided to dabble with the 8253 a bit. What a nightmare ..
First, some observations on the 8253:
- Mode 3 on the 8253 is not suitable for reading because of the way it
counts down twice before triggering an interrupt. If you just latch and
read the count you can't tell if you are on the first pass or the second
pass before the interrupt. That's not good for timing.
- Mode 2 counts down and generates an interrupt in a sane way, but
generates a different pulse to the 8259 interrupt controller so I'd
rather not use it. The BIOS initializes with Mode 3, and that is what I
am sticking with.
I decided to make timer 0 tick at a faster rate (64x faster), and in my
interrupt handler I call the original interrupt handler at the
appropriate rate to avoid speeding up the system clock. This works
fine, even on the PCjr. Except for one case ...
On the PCjr, if I touch the keyboard the machine screeches. And not its
normal polite 'Go away I'm busy beep' either. The keyboard on this
machine is wired to NMI instead of IRQ1, so it has higher priority than
timer 0. The NMI interrupt is used to read the keyboard serial data
stream and it uses timer 1 of the 8253 to record when the first bit is
received. Timer 1 isn't used elsewhere, so that is fine. If there is
an error in the serial data it sounds the system beeper, so timer 2 can
get altered at any time making timer 2 unusable.
Any keypress causes the screeching. First, I can't figure out why the
NMI handler is having a problem deserializing the keyboard even if timer
0 is running fast. All interrupts are disabled, so this should be
business as usual. Yet any keypress causes it to go nuts. Any ideas?
(As a side effect the timings reported by ping start to look bad - the
NMI is definitely taking up precious time.)
Second, the machine becomes unstable. I don't care about getting bad
timings because of keypresses, but this is far worse ..
If I disable the NMI interrupt everything is perfect - but then you
can't hit Ctrl-Break to stop pinging. (Yes, I have Ctrl-Break captured,
and it works if I don't mess with timer 0 at all.) I don't want to have
to shut off the keyboard entirely if there is a possibility of figuring
out why the NMI is causing problems with a fast timer 0.
Ideas?
Thanks in advance,
Mike
29 Sep
29 Sep
2:59 p.m.
It was thus said that the Great Michael B. Brutman once stated:
On the PCjr, if I touch the keyboard the machine screeches. And not its
normal polite 'Go away I'm busy beep' either. The keyboard on this
machine is wired to NMI instead of IRQ1, so it has higher priority than
timer 0. The NMI interrupt is used to read the keyboard serial data
stream and it uses timer 1 of the 8253 to record when the first bit is
received. Timer 1 isn't used elsewhere, so that is fine. If there is
an error in the serial data it sounds the system beeper, so timer 2 can
get altered at any time making timer 2 unusable.
Any keypress causes the screeching. First, I can't figure out why the
NMI handler is having a problem deserializing the keyboard even if timer
0 is running fast. All interrupts are disabled, so this should be
business as usual. Yet any keypress causes it to go nuts. Any ideas?
(As a side effect the timings reported by ping start to look bad - the
NMI is definitely taking up precious time.)
Second, the machine becomes unstable. I don't care about getting bad
timings because of keypresses, but this is far worse ..
If I disable the NMI interrupt everything is perfect - but then you
can't hit Ctrl-Break to stop pinging. (Yes, I have Ctrl-Break captured,
and it works if I don't mess with timer 0 at all.) I don't want to have
to shut off the keyboard entirely if there is a possibility of figuring
out why the NMI is causing problems with a fast timer 0.
Ideas?
If you have the IBM PCjr tech ref handy, it does contain the BIOS listing,
but if you don't, the NMI routine itself reads the timer (see below for the
sequence) to time the bit stream coming from the keyboard (no hardware
assist here, so it's the CPU reading the bits directly). Further more, for
each code received from the keyboard, the NMI routine calls INT $48 (about
five and a half pages of code) to translate the code to an IBM PC keyboard
compatable code, stuffs that value (or values if a multi-byte sequence is
needed) into port $60, then directly calls INT $09.
And if there's an error during any of this, a sound routine called, which
manipulates port $61 to toggle the speaker directly (using software loops to
control pitch and duration).
The code sequence to read the timers goes
mov al,40h
out 43h,al ; translated from symbolic constant
nop
nop
in al,41h
mov ah,al
in al,41h
xchg al,ah
I hope this helps some.
-spc (The PCjr was my second computer ... )
4:02 p.m.
Hi Sean,
I've got the tech ref and have the pages handy. I've been staring at
the NMI keyboard handler, but I can't figure out what the machine might
be doing that would cause keyboard handling to fail.
If NMI is the highest priority, then nothing about decoding the keyboard
should fail except for the keyboard sending out bad bits. The call to
INT 0x48 will still be done under the NMI interrupt, so nothing else can
interrupt it and hose it.
So the big question is, given the NMI setup, how can keyboard decoding
ever fail due to something else the system might be trying to do? All
other INTS are suppressed.
The fact that I'm messing with a timer that it is not even using (0)
bothers me even more .. Same code with the standard clock tick rate
from timer 0 works just fine with the keyboard. Change
the clock rate,
and the keyboard goes nuts (can't decode anything) and the
system
becomes unstable. Lock the keyboard out with the faster rate, and
everything is golden.
Still have your Jr?
Mike
10:53 p.m.
It was thus said that the Great Michael B. Brutman once stated:
The fact that I'm messing with a timer that it is not even using (0)
bothers me even more .. Same code with the standard clock tick rate
from timer 0 works just fine with the keyboard. Change the clock rate,
and the keyboard goes nuts (can't decode anything) and the system
becomes unstable. Lock the keyboard out with the faster rate, and
everything is golden.
I wonder if it's a buggy timer chip?
Still have your Jr?
Yes. And it even has a V20 in it. Unfortunately, it's backed away in
storage at the moment and even if it was handy, there's no place to set it
up.
-spc (And it's been a loooooong time since it was last fired up ... )
30 Sep
30 Sep
5:53 p.m.
Ok, solved my own problem. If you bang your head hard enough ...
The first version of Ping worked just fine no matter how hard I abused
the keyboard.
My new timer code is fine. The BIOS of the machine is fine. So what's
the problem? This is the first time since I started this project that I
turned on floating point emulation in the Turbo C++ 3.0 library. Even
though I specified emulation, it is probably trying to be smart and use
an 8087 if it finds one. Which also implies that it is setting the NMI
vector. (I'll verify this later.)
So doing anything on the keyboard on the Jr while the code was running
was enough to trigger an NMI, and the Turbo C++ runtime was probably
trying to figure out what to do with a bogus NMI. Not a happy thing.
The same exact code without the one stinking little floating point calc
works just fine, and I can lay on the keyboard the whole time.
Grrrr ...
On an unrelated note, CLI and STI are not enough to prevent an NMI on
this machine. (Or on any PC for that matter - but on this machine NMIs
are easy to trigger.) I'm wondering if I should make it a habit to
disable NMI if I really am serious about disabling interrupts. In this
particular case, touching the timer while only using CLI and STI is
unsafe because a keypress will touch that exact timer hardware too.
Anytime that an NMI caused by the keyboard might screw up the state of
hardware that you are touching it seems like NMI needs to be disabled.
Unfortunately, there is a lot of BIOS code to handle the keyboard that I
need to read to find out what it might be touching.
Mike
6:05 p.m.
On a related note, does anybody have a good method for doing a floating
point multiply in software? Before I steal an existing floating point
emulation lib, I'd like to see if I can cheat and just write enough code
to do the one multiply that I need.
I need to figure out how to do this:
float elapsed = ticks * 0.85;
using purely integer operations.
Thanks,
Mike
6:15 p.m.
On Wed, Sep 30, 2009 at 21:05, Michael B. Brutman
<mbbrutman-cctalk at brutman.com> wrote:
I need to figure out how to do this:
?float elapsed = ticks * 0.85;
using purely integer operations.
There's a gazillion ways to do it; first question would be, what
precision do you need? What is the range of ticks?
If the range of ticks is small (8 bits or so) see if a lookup table
can be fit into RAM; otherwise, figure out the precision you need and
the size of storage for an intermediate value, then calculate
(ticks*x)>>n, where x/(2^n) approximates 0.85.
Joe.
--
Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem
6:17 p.m.
On 30 Sep 2009 at 20:05, Michael B. Brutman wrote:
On a related note, does anybody have a good method for
doing a
floating point multiply in software? Before I steal an existing
floating point emulation lib, I'd like to see if I can cheat and just
write enough code to do the one multiply that I need.
I need to figure out how to do this:
float elapsed = ticks * 0.85;
What range of arguments and and to what precision? You can always
simplify division by a constant to multiplication by the binary-
scaled reciprocal (with some loss of precision). Multiplication, of
course, can be decomposed to a series of adds and shifts.
--Chuck
6:22 p.m.
On Sep 30, 2009, at 6:05 PM, Michael B. Brutman wrote:
On a related note, does anybody have a good method for doing a
floating point multiply in software? Before I steal an existing
floating point emulation lib, I'd like to see if I can cheat and
just write enough code to do the one multiply that I need.
I need to figure out how to do this:
float elapsed = ticks * 0.85;
using purely integer operations.
<rant>
Why do people always seem to want to have elapsed time as a floating
point number?
</rant>
How about:
elapsed = (85 * ticks) / 100.
If you need more scale, try a scaling factor:
scale = 1000
elapsed = (85 * scale * ticks) / 100
TTFN - Guy
6:43 p.m.
On Wed, 30 Sep 2009, Guy Sotomayor wrote:
<rant>
Why do people always seem to want to have elapsed time as a floating
point number?
</rant>
Because some of the CRAP that they learned in school makes them think that
truncation (or even rounding) to an int value "isn't the RIGHT answer".
In the XenoSoft Sales Tax Genie, I wrote a very small TSR that calculated
the sales tax of every California jurisdiction (based on ZIPCODE), rounded
appropriately to an "exact" cents amount. I NEVER used floating point.
I do not HAVE any "fraction of a cent" coins!
--
Grumpy Ol' Fred cisin at xenosoft.com
7:17 p.m.
Fred Cisin wrote:
On Wed, 30 Sep 2009, Guy Sotomayor wrote:
I think that both of you are making assumptions about my education,
upbringing, etc. that are not true and I'd like you to calm down.
I've used that trick in all of my other TCP/IP apps so far - they all
report elapsed time (sometimes with decimal points), and I managed to do
it without ever linking in the floating point library.
I was using this to explore other methods ..
I don't know what CRAP you learned, but I would try to be more gracious ...
Mike
<rant>
Why do people always seem to want to have elapsed time as a floating
point number?
</rant>
Because some of the CRAP that they learned in school makes them think that
truncation (or even rounding) to an int value "isn't the RIGHT answer".
In the XenoSoft Sales Tax Genie, I wrote a very small TSR that calculated
the sales tax of every California jurisdiction (based on ZIPCODE), rounded
appropriately to an "exact" cents amount. I NEVER used floating point.
I do not HAVE any "fraction of a cent" coins!
--
Grumpy Ol' Fred cisin at xenosoft.com
10:04 p.m.
New subject: "What;s the matter with kids today" (Was: PCjr NMI and 8253
>> <rant>
>> Why do people always seem to want to have elapsed time as a floating
>> point number?
>> </rant>
> Because some of the CRAP that they learned in school makes them think that
> truncation (or even rounding) to an int value "isn't the RIGHT
answer".
On Wed, 30 Sep 2009, Michael B. Brutman wrote:
I think that both of you are making assumptions about
my education,
upbringing, etc. that are not true and I'd like you to calm down.
Sorry.
I was, indeed, assuming that you had been through the school system in the
USA, and I blame that system for many problems, including the one of
people using floating point when it is inappropriate (almost always).
I assumed that your education was similar to ours. I have no ideas about
your "upbringing".
Even FORTRAN makes the very sad mistake of calling floating point numbers
"REAL" numbers.
And although I will always have fond feelings for Microsoft "street"
BASIC, its use of single precision float as the default variable type
reinforces Djikstra's "It is virtually impossible to teach good
programming practices to students who have had a prior exposure to BASIC.
They are mentally mutilated beyond hope of regeneration."
"God made integers, all else is the work of man." - Leopold Konecke?
Using floating point inappropriately might be the most common mistake made
by those who start with a high level language (as I did), and come from a
school mathematical background. If you would like to blame that mistake
on something else, you're entitled. I blame that on certain aspects of
mathematics education, including the emphasis on "pure" math and rote
memorization to the detriment of understanding of calculatory methods.
For example, how many people can compute a square root?
What percentage of the polulace think that PI == 22/7, not "about 22/7"?
I've used that trick
"trick"????
It's not a trick. It's one of the basic normal ways in computer math
to get a fractional portion of an integer.
Similarly, use and understanding of interpolation makes it trivial to
compute a square root. Is it a "trick"? No. But lack of that
"trick"
accounts for why less than a tenth of a percent of college graduates can
compute a square root. Yet anybody who takes a community college course
in computer math instead of one from the Mathematics department, has no
difficulty at all.
Even using shifts and adds for multiplying isn't so much a "trick" as it
is understanding the capabilities and limitations of the tools in use.
Y = X * 10
Y = X * (8 + 2)
Y = (X * 2) + (X * 8)
Y = (X >>1) + (X >>3)
T = X >>1
Y = T + T >>2
(leaving out discussion of accumulators)
I was using this to explore other methods ..
a very reasonable and commendable thing to do.
I don't know what CRAP you learned, but I would
try to be more gracious ...
Trust me, it was horrible.
Yes, I did get disciplined for insisting that "PI is about 3.1416 or 22/7"
in the textbook did NOT mean that PI was exactly 22/7.
I have much to unlearn to be able to work well with computer math. I am
grateful for the help, tips, "tricks", and reality-checks that
"seasoned"
computer people have provided. I was even using floating point to
determine which pixels to set to draw a line from (X1,Y1) to (X2,Y2)
--
Grumpy Ol' Fred cisin at xenosoft.com
10:39 p.m.
New subject: "What;s the matter with kids today" (Was: PCjr NMI and 8253
On 30 Sep 2009 at 22:04, Fred Cisin wrote:
What percentage of the polulace think that PI == 22/7,
not "about
22/7"?
Hey, that only goes to show that the populace gets smarter with time.
In 1897, the Indiana Legislature attempted to declare it as 3
(exactly). Gotta love them lawyers.
http://en.wikipedia.org/wiki/Indiana_Pi_Bill
But maybe not; politicians today seem to be as benighted as they ever
were...
Cheers,
Chuck
1 Oct
1 Oct
1:08 a.m.
On Sep 30, 2009, at 7:17 PM, Michael B. Brutman wrote:
Fred Cisin wrote:
Please re-read what *I* said. Your original post contained:
float elapsed = ticks * 0.85;
Which is what *I* had the <rant> about.
On Wed, 30 Sep 2009, Guy Sotomayor wrote:
I think that both of you are making assumptions about my education,
upbringing, etc. that are not true and I'd like you to calm down. <rant>
Why do people always seem to want to have elapsed time as a floating
point number?
</rant>
Because some of the CRAP that they learned in school makes them
think that
truncation (or even rounding) to an int value "isn't the RIGHT
answer".
In the XenoSoft Sales Tax Genie, I wrote a very small TSR that
calculated
the sales tax of every California jurisdiction (based on ZIPCODE),
rounded
appropriately to an "exact" cents amount. I NEVER used floating
point.
I do not HAVE any "fraction of a cent" coins!
--
Grumpy Ol' Fred cisin at xenosoft.com
I've used that trick in all of my other TCP/IP apps so far - they
all report elapsed time (sometimes with decimal points), and I
managed to do it without ever linking in the floating point library.
I was using this to explore other methods ..
I don't know what CRAP you learned, but I would try to be more
gracious ...
Part of my job is to maintain/manage time for a particular OS. In
that OS all time (internally) is kept as a 64-bit number of
nanoseconds (10**-9 seconds). However, the number of people that
insist that it be converted to a floating point number so that they
can have seconds and fractional seconds (and then want to do math on
it) is astounding. I tend to overreact on this topic because floating
point to represent time is idiotic IMHO especially since some of the
low level conversion constants I deal with are specified in
femtoseconds (10**-15 seconds). If I can do everything necessary to
maintain time in integer values at those precisions then I fail to
understand why anyone needs to deal with time as a floating point
value. In case anyone is wondering, 64-bits of nanoseconds can
represent a time span of over 500 years.
TTFN - Guy
30 Sep
30 Sep
6:36 p.m.
On Wed, 30 Sep 2009, Michael B. Brutman wrote:
On a related note, does anybody have a good method for
doing a floating
point multiply in software? Before I steal an existing floating point
emulation lib, I'd like to see if I can cheat and just write enough code
to do the one multiply that I need.
I need to figure out how to do this:
float elapsed = ticks * 0.85;
using purely integer operations.
Unless you are deliberately TRYING to waste cycles, then stay clear of
floating point!
What's wrong with:
(int) elapsed = ((int) ticks * (int) 85)/ (int) 100
with remainder.
(or (long) if you are dealing with larger numbers)
1 Oct
1 Oct
12:18 a.m.
It was thus said that the Great Michael B. Brutman once stated:
On a related note, does anybody have a good method for doing a floating
point multiply in software? Before I steal an existing floating point
emulation lib, I'd like to see if I can cheat and just write enough code
to do the one multiply that I need.
I need to figure out how to do this:
float elapsed = ticks * 0.85;
using purely integer operations.
mov ax,ticks
mov dx,55706
mul dx
The result is now in DX (55,706 is 85% of 65,536).
-spc
2 Oct
2 Oct
1:49 a.m.
On Wed, 30 Sep 2009, Michael B. Brutman wrote:
on floating point emulation in the Turbo C++ 3.0
library. Even though I
^^^
I beg your pardon?
On an unrelated note, CLI and STI are not enough to
prevent an NMI on this
Guess why it's called a non-maskable interrupt...
Christian
6:30 a.m.
Christian Corti wrote:
Thanks - I don't think I missed that though.
I think you missed the subtlety of the problem - on a normal PC an NMI
would be very rare. On a PCjr you can hit any key on the keyboard and
cause it. That makes the the CLI/STI exposure to NMI much greater on
this machine. (And on the PC Convertible from what I am reading.)
On Wed, 30 Sep 2009, Michael B. Brutman wrote:
Yes .. Turbo C++ 3.0 for DOS. I don't use a lot of the fancier C++
language features because they are not appropriate for this type of
programming. It looks like very well structured and encapsulated C when
I use it.
on floating point emulation in the Turbo C++ 3.0
library. Even though I
^^^
I beg your pardon? On an
unrelated note, CLI and STI are not enough to prevent an NMI on
this
Guess why it's called a non-maskable interrupt... Christian
30 Sep
30 Sep
9:31 a.m.
----- Original Message -----
From: "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
To: "CCTalk_list" <cctalk at classiccmp.org>
Sent: Tuesday, September 29, 2009 11:30 AM
Subject: PCjr NMI and 8253 Timer interactions
I recently wrote a ping utility for my DOS TCP/IP stack, and I wasn't
satisfied with the 55ms resolution of the BIOS timer tick. I used the
'delay' function in the Turbo C runtime which gives me a processor loop
that delays with 1ms granularity. I figured that I could call that and
poll for the ping reply, and the number of calls would be the ping latency
in ms.
Testing of delay in a controlled environment shows that at least on my
PCjr, it is off by 15%. My V20 processor might be part of the problem,
although I'm not going to fix it.
So I decided to dabble with the 8253 a bit. What a nightmare ..
First, some observations on the 8253:
- Mode 3 on the 8253 is not suitable for reading because of the way it
counts down twice before triggering an interrupt. If you just latch and
read the count you can't tell if you are on the first pass or the second
pass before the interrupt. That's not good for timing.
- Mode 2 counts down and generates an interrupt in a sane way, but
generates a different pulse to the 8259 interrupt controller so I'd rather
not use it. The BIOS initializes with Mode 3, and that is what I am
sticking with.
I decided to make timer 0 tick at a faster rate (64x faster), and in my
interrupt handler I call the original interrupt handler at the appropriate
rate to avoid speeding up the system clock. This works fine, even on the
PCjr. Except for one case ...
On the PCjr, if I touch the keyboard the machine screeches. And not its
normal polite 'Go away I'm busy beep' either. The keyboard on this
machine is wired to NMI instead of IRQ1, so it has higher priority than
timer 0. The NMI interrupt is used to read the keyboard serial data
stream and it uses timer 1 of the 8253 to record when the first bit is
received. Timer 1 isn't used elsewhere, so that is fine. If there is an
error in the serial data it sounds the system beeper, so timer 2 can get
altered at any time making timer 2 unusable.
Any keypress causes the screeching. First, I can't figure out why the NMI
handler is having a problem deserializing the keyboard even if timer 0 is
running fast. All interrupts are disabled, so this should be business as
usual. Yet any keypress causes it to go nuts. Any ideas? (As a side
effect the timings reported by ping start to look bad - the NMI is
definitely taking up precious time.)
Second, the machine becomes unstable. I don't care about getting bad
timings because of keypresses, but this is far worse ..
If I disable the NMI interrupt everything is perfect - but then you can't
hit Ctrl-Break to stop pinging. (Yes, I have Ctrl-Break captured, and it
works if I don't mess with timer 0 at all.) I don't want to have to shut
off the keyboard entirely if there is a possibility of figuring out why
the NMI is causing problems with a fast timer 0.
Ideas?
Thanks in advance,
Mike
Many years ago I tried a similar trick. I think I wanted a 10 millisecond
interrupt rate instead of 55ms for an embedded DOS application, and I got it
to work - sort of. However, I soon discovered that many other things
including the Borland delay() function depend on the 55ms interval, so I
rather quickly abandoned that line of thinking. I rather suspect your PCjr
keyboard driver is making similar assumptions regarding the tick rate.
I still use the 8253 for timing with better resolution by simply latching
and reading it periodically. Of course one must check and compensate for
the case where the timer rolls over from 0x0000 to 0xFFFF between two
successive reads. It is necessary to hold interrupts around the latch and
read command sequence to avoid incorrect register read values. I seem to
recall the 8253 counts down at a 0.8 microsecond rate so this only works if
one can arrange to check the timer at least once every 52ms.
I should add that my experience doing this is all under DOS on a PC, not a
PCjr. It does seem to work fine in a DOS window under both W98 and XP as
well, though I try to always use a full screen DOS window since I understand
that fewer things are "virtualized" in that case. I have no details as to
what those things are, but everything just seems to work better that way.
Later,
Charlie Carothers
--
My email address is csquared3 at tx dot rr dot com
1 Oct
1 Oct
9:32 a.m.
On 30 Sep 2009 at 11:31, CSquared wrote:
Many years ago I tried a similar trick. I think I
wanted a 10
millisecond interrupt rate instead of 55ms for an embedded DOS
application, and I got it to work - sort of. However, I soon
discovered that many other things including the Borland delay()
function depend on the 55ms interval, so I rather quickly abandoned
that line of thinking. I rather suspect your PCjr keyboard driver is
making similar assumptions regarding the tick rate.
Several programs made this work on the PC, as long as the interval
could be a sub-multiple of 55 msec. So, for instance, if you could
live with 11 msec. or 5.5 msec., this is how you would do it.
Hook the interrupt 9 vector and create your own ISR for 4 of 5 timer
interrupts, then direct the the 5th to the normal vector. All that's
required in your ISR is any register saving required for your own
needs, and a routine to issue an EOI to the 8259. Works like a
charm--everything runs just as it should.
However, on Mike's Peanut, there is no 8259. Everything goes through
the NMI handler--a very bad decision on IBM's part, seeing as how the
8259 was one of the least expensive Intel 8x support chips. A
rudimentary prioritized interrupt system could have been implemented
with a priority encoder and some other glue.
Cheers,
Chuck
3:03 p.m.
----- Original Message -----
From: "Chuck Guzis" <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Thursday, October 01, 2009 11:32 AM
Subject: Re: PCjr NMI and 8253 Timer interactions
On 30 Sep 2009 at 11:31, CSquared wrote:
Neat! I never thought of that, but I can see that it would work just fine.
I'm pretty sure I made the mistake of changing the 8253 counting rate
without compensating for it as you describe. I probably could have lived
with an 11ms interrupt rate too. I was porting a good-sized semi-ancient
program from PLM-51 on an 8032 to C and PLM-86 to run on an embedded PC
motherboard, and did not want to have to change a whole bunch of timing
constants with the attendant risk of overlooking something. I wound up just
changing all the constants instead. I'll have to keep your idea in mind for
future reference. Believe it or not, I still do a bit of development under
DOS at times.
Many years ago I tried a similar trick. I think
I wanted a 10
millisecond interrupt rate instead of 55ms for an embedded DOS
application, and I got it to work - sort of. However, I soon
discovered that many other things including the Borland delay()
function depend on the 55ms interval, so I rather quickly abandoned
that line of thinking. I rather suspect your PCjr keyboard driver is
making similar assumptions regarding the tick rate.
Several programs made this work on the PC, as long as the interval
could be a sub-multiple of 55 msec. So, for instance, if you could
live with 11 msec. or 5.5 msec., this is how you would do it.
Hook the interrupt 9 vector and create your own ISR for 4 of 5 timer
interrupts, then direct the the 5th to the normal vector. All that's
required in your ISR is any register saving required for your own
needs, and a routine to issue an EOI to the 8259. Works like a
charm--everything runs just as it should.
However, on Mike's Peanut, there is no 8259. Everything goes through
the NMI handler--a very bad decision on IBM's part, seeing as how the
8259 was one of the least expensive Intel 8x support chips. A
rudimentary prioritized interrupt system could have been implemented
with a priority encoder and some other glue.
I did not know that; I've never done anything at all with a PCjr.
Cheers,
Chuck
5329
days inactive
5332
days old
20 comments
8 participants
participants (8)
-
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
cisin＠xenosoft.com -
csquared3＠tx.rr.com -
ggs＠shiresoft.com -
joachim.thiemann＠gmail.com -
mbbrutman-cctalk＠brutman.com -
spc＠conman.org