filetp@dnlunx.pttrnl.nl (Peter Filet) (11/29/90)
I am developing an Operating System, in the Protected Mode of the i286 processor. Up until now I've used the basic hardware timer interrupt (08H) to switch tasks. Unfortunately, this interrupt occurrs merely 18 times per second, which doesn't give me much flexibility in assigning time slices to a task. I've been told that the 8253-5 and 8254.2 controllers offer me more interrupts per second, thus more flexibility for task switching. Could anyone please provide me with some (detailed) info on programming these controllers ? Please send any kind of (helping) info to the E_Mail address below. Thanx in advance. E_Mail : PW_Filet@pttrnl.nl Name : Peter Filet
c164-bd@katerina.uucp (John D. Mitchell) (12/01/90)
In article <4348@dnlunx.pttrnl.nl> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: [deleted] >I've been told that the 8253-5 and 8254.2 controllers offer me more >interrupts per second, thus more flexibility for task switching. See the timers developed in "Zen of Assembly Language" by M. Abrash published by Scott, Foresman and Co. ---- John D. Mitchell johnm@cory.Berkeley.EDU
hughes@copper.ucs.indiana.edu (larry hughes) (12/03/90)
In article <4348@dnlunx.pttrnl.nl> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: >I am developing an Operating System, in the Protected Mode of the i286 >processor. >Up until now I've used the basic hardware timer interrupt (08H) to switch >tasks. Unfortunately, this interrupt occurrs merely 18 times per second, >which doesn't give me much flexibility in assigning time slices to a >task. > >I've been told that the 8253-5 and 8254.2 controllers offer me more >interrupts per second, thus more flexibility for task switching. > >Could anyone please provide me with some (detailed) info on programming >these controllers ? You should be very cautious of this; as I recall, the disk drive routines in the BIOS are heavily dependent on the clock interrupt (they use it for timing purposes). I tried to do this a long time ago ('84?) for a real time application, but gave up trying for this reason. //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) (12/05/90)
In article <4348@dnlunx.pttrnl.nl> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: >I am developing an Operating System, in the Protected Mode of the i286 >processor. > (wants a faster system clock) This is actually very easy to do. The idea is to hook the clock tick interrupt,keeping the original vector and substituting your own handler. Then, if you want, say, a 4X clock rate (72.8/sec), you call the original handler every fourth tick. The rest of the OS has no idea anything has changed. Indeed, from its point of view, nothing has. I'll be happy to send the .asm code that does this to anyone who wants it. Academic types can usually tell you why you can't do something. Commercial software developers can usually tell you how to do it anyway :) .
levericw@cheetah.ece.clarkson.edu (Walden Leverich) (12/13/90)
In article <76399@iuvax.cs.indiana.edu> bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) writes: Tim> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: Tim> >I am developing an Operating System, in the Protected Mode of the i286 Tim> >processor. Tim> > (wants a faster system clock) Tim> This is actually very easy to do. The idea is to hook the clock Tim> tick interrupt,keeping the original vector and substituting your own Tim> handler. Then, if you Tim> want, say, a 4X clock rate (72.8/sec), you call the original handler every Tim> fourth tick. The rest of the OS has no idea anything has Tim> changed..... Very interesting. But wrong. Considering that your interrupt timer will be called once every 1/18.2 seconds. Now if your pass that tick onto the OS every fouth time, then the OS gets 1/4 of the clock *NOT* 4X the clock. Tim> from its point of view, nothing has. Tim> I'll be happy to send the .asm code that does this to anyone who wants it. Tim> Academic types can usually tell you why you can't do something. Tim> Commercial software developers can usually tell you how to do it Tim> anyway :) Academic types in the CompEng field will explain why it is impossible. -Walden -- --------------------------------------------------------------------------- Walden H. Leverich III | Inet: levericw@clutx.clarkson.edu ECE Dept. | CServ: 73237,2212 <- checked weekly Clarkson University | SnailMail: Software Solutions | PO Box 763 | Potsdam, NY 13676-0763 #include <std_disclamer_concerning_what_I_say> --------------------------------------------------------------------------
everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) (12/13/90)
/ levericw@cheetah.ece.clarkson.edu (Walden Leverich) writes... > bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) writes: >Tim> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: >Tim> >I am developing an Operating System, in the Protected Mode of the i286 >Tim> >processor. >Tim> > (wants a faster system clock) >Tim> want, say, a 4X clock rate (72.8/sec), you call the original handler every >Tim> fourth tick. The rest of the OS has no idea anything has >Tim> changed..... >Very interesting. But wrong. Considering that your interrupt timer >will be called once every 1/18.2 seconds. Now if your pass that tick >onto the OS every fouth time, then the OS gets 1/4 of the clock *NOT* >4X the clock. It WILL work, what was left out of the explanation is this: after you take over the interrupt vector, you have to reprogram the timer to interrupt 4 times as often. THEN, you only pass every fourth one on to the regular interrupt service routine, maintaining the original frequency for the original interrupt service routine, but quadrupling the frequency for yourself. >Tim> Academic types can usually tell you why you can't do something. >Tim> Commercial software developers can usually tell you how to do it >Tim> anyway :) >Academic types in the CompEng field will explain why it is impossible. NEVER say never! (or impossible) Everett Kaser Hewlett-Packard Company ...hplabs!hp-pcd!everett work: (503) 750-3569 Corvallis, Oregon everett%hpcvra@hplabs.hp.com home: (503) 928-5259 Albany, Oregon
Ralf.Brown@B.GP.CS.CMU.EDU (12/13/90)
In article <LEVERICW.90Dec12104852@cheetah.ece.clarkson.edu>, levericw@cheetah.ece.clarkson.edu (Walden Leverich) wrote: }In article <76399@iuvax.cs.indiana.edu> bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) writes: }Tim> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: }Tim> > (wants a faster system clock) } }Tim> This is actually very easy to do. The idea is to hook the clock }Tim> tick interrupt,keeping the original vector and substituting your own }Tim> handler. Then, if you }Tim> want, say, a 4X clock rate (72.8/sec), you call the original handler every }Tim> fourth tick. The rest of the OS has no idea anything has changed..... } }Very interesting. But wrong. Considering that your interrupt timer }will be called once every 1/18.2 seconds. Now if your pass that tick }onto the OS every fouth time, then the OS gets 1/4 of the clock *NOT* }4X the clock. The idea is that you speed up the timer chip to generate the clock tick 72.8 times per sec, THEN pass only every fourth tick to the previous handler. }Academic types in the CompEng field will explain why it is impossible. Better not tell my NLQ-print program, which speeds up the clock tick by a factor of 128 (needed to spool the resulting graphics to the printer in the background as fast as the printer can handle) without affecting the system clock.... -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
wdr@wang.com (William Ricker) (12/14/90)
bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) writes: >filetp@dnlunx.pttrnl.nl (Peter Filet) writes: >> (wants a faster system clock) >This is actually very easy to do. The idea is to hook the clock tick >interrupt, keeping the original vector and substituting your own handler. >Then, if you >want, say, a 4X clock rate (72.8/sec), you call the original handler every >fourth tick. The rest of the OS has no idea anything has changed. Indeed, >from its point of view, nothing has. The rest of the "OS" (if you call DOS that), maybe -- but some other TSR may be peeking at the 8253's registers periodicaly to see how long it has been since the last tick, and they will get mighty confused if you've changed the interupt rate by changing the clock-freqency devisor on the clock-interupt channel of the 8253. >... Commercial >software developers can usually tell you how to do it anyway :) . Assuming the rest of the software is better behaved than theirs'. :-( -- /bill ricker/ wdr@wang.com a/k/a wricker@northeastern.edu *** Warning: This account not authorized to express opinions ***
bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) (12/14/90)
In article <31600011@hpcvra.cv.hp.com.CV.HP.COM> everett@hpcvra.cv.hp.com.CV.HP.COM (Everett Kaser) writes: }/ levericw@cheetah.ece.clarkson.edu (Walden Leverich) writes... } > bomgard@iuvax.cs.indiana.edu (Tim Bomgardner) writes: }>Tim> filetp@dnlunx.pttrnl.nl (Peter Filet) writes: }>Tim> >I am developing an Operating System, in the Protected Mode of the i286 }>Tim> >processor. }>Tim> > (wants a faster system clock) } }>Tim> want, say, a 4X clock rate (72.8/sec), you call the original handler every }>Tim> fourth tick. The rest of the OS has no idea anything has }>Tim> changed..... } }>Very interesting. But wrong. Considering that your interrupt timer }>will be called once every 1/18.2 seconds. Now if your pass that tick }>onto the OS every fouth time, then the OS gets 1/4 of the clock *NOT* }>4X the clock. } }It WILL work, what was left out of the explanation is this: after you take }over the interrupt vector, you have to reprogram the timer to interrupt }4 times as often. THEN, you only pass every fourth one on to the regular }interrupt service routine, maintaining the original frequency for the original }interrupt service routine, but quadrupling the frequency for yourself. } My apologies for leaving out this critical bit of information. The 8254 counter is easily programmed for the desired clock rate, 72.8/sec in this example. }>Tim> Academic types can usually tell you why you can't do something. }>Tim> Commercial software developers can usually tell you how to do it }>Tim> anyway :) } }>Academic types in the CompEng field will explain why it is impossible. } Like I said... :)