This is a variation of RTLinux for kernel 2.0.33/35 by Barabanov, Yodaiken and
company, NMT, New Mexico, USA. (http://rtlinux.cs.nmt.edu/~rtlinux/)
People at NMT must be praised for their nice work without which this variant
would not be possible. 
It fixes the fpu supports so that all the stuff now works, without causing
unpredictable jitters, either if the fpu is used or not.
This new version of the variant is for uniprocessor (UP) PCs and allows now 
to chose between a periodic and a oneshot timer, not to be used together.
The periodic ticking is less flexible but, with the usual PC hardware (UPs
cannot use APICs), much more efficient. So it is up to you which one to choose. 
It should be noted that in the oneshot mode the time is now measured on the
base of the CPU clock (TSC: time stamp clock) and not on the 8254 chip, that is
used only to generate interrupts.
The periodic mode is instead timed by the 8254 chip only. However the CPU clock
is still used in such a case for setting the time to the next Linux tick
required in time.c. 
In this way slow I/O to the ISA bus are limited as much as possible with a 
sizable gain in efficiency. The one shot mode has just 20-25 % more overhead 
processing than the periodic one.
I think that the TSC is not available on 486 machines and thus this variant
requires Pentiums and onward machines. 

This variant needs to calibrate the cpu clock. You have two choices:
- the first, and less precise, is to get the cpu frequency from bogomips. Just
  type "cat /proc/cpuinfo" and read it (I've been warned that on some Pentiums
  cpuinfo gives the double of the cpu frequency ???!!!);
- the second, and reccomanded mode, requires running the module "rt_cal.o"
  from the directory "calibration" included in this distribution. Yuo'll get
  something better than bogomips in about ten seconds. If you want to get full
  precision let it run till the least significant digit is stabilized. See 
  README in "calibrate" for a more precise description. Note that this must be
  done just once for all.

Note that this version of rtlinux has also more system services including:
timings, semaphores, messages and remote procedure calls, that makes it easier
to develop complex real time applications.

Its installation requires that you already know how to install the patch for
rtlinux-0.6.

What to do:
	1 - Apply the rtlinux-0.6 patch for linux 2.0.33 (yes use the 2.0.33
            patch even for kernel 2.0.35), as explained in the NMT official
            distribution, delete the file ...../include/linux/version.h, do
            "make menuconfig" but do not "make zImage" immediatly;
	2 - Copy the files rt_time.c, rt_time.h, time.c, ksyms.c, rt_sched.h
            and rt_prio_sched.c of this distribuition over, i.e.replace,
	    their corresponding in the appropriate linux directories.
	    Note that the functions are for version 2.0.35, if you want to
	    patch kernel 2.0.33 remove time.c and ksyms.c and move the 
	    corresponding ?????.c.33 to their place.
	    The file "copyto" (included), edited, to address the appropriate
            directories, and made executable, can be of help;
	3 - Carry out the compilation of the kernel by "make zImage";
	4 - Get the cpu frequency as described above and set the macro CPU_FREQ
	    (first line) in rt_prio_sched.c accordingly.
	5 - Do "make modules";

Before carrying out step 2 it is suggested to save the original file to be
overwritten. Note again that the script file "copyto" does this already.
The file "ldmod" and "remod" can be used to insmod and rmmod the scheduler and
the fifo modules with the default parameters. For the scheduler these are:
the cpu frequency as set in the corresponding macro, a periodic scheduler 
and Linux assumed not to use the fpu. You can change any of the above at module 
either by setting the corresponding macros in rt_prio_sched.c or at 
installation: just type the extended command:
"insmod /usr/src/linux/modules/rt_prio_sched.o CpuFreq=<x> LinuxFpu=<y>
OneShot=<z>", where x is the cpu freqency in hz, y==0 Linux does not use the fpu
y!=0 does, z==0 periodic timer z!=0 oneshot timer. Clearly you can set any
combination of the above parameters. While the cpu frequency can be changed
just by compiling the scheduler module or at its installation, the functions:
rt_linux_use_fpu(int yes_no), rt_set_periodic_mode() and rt_set_oneshot_mode(),
can be used to set/reset the scheduler dynamically. Note that setting the timer
mode stops any already running timer.

Now you are done and can try the test cases.
Be carefull in setting the macro TICK_PERIOD (nanosecs) in the various examples
to a value appropriate to your machine. The one now used works for a 200Mhz
PentiumPro and can be too demanding for lower class Pentiums.
In all the tests the choice of which timer, periodic or oneshot, use is done
by commeting/uncommentig the macro ONE_SHOT. It is important to remark that
since in all tests a oneshot timer is set specifically at module load time, any
choice made at the scheduler installation is overridden.
It should be remarked that if the timer mode is chosen at module installation
that must be done by adding a call to "rt_set_[oneshot/periodic]_mode()"
before any time conversion or service is requested to the scheduler.
Thus in the case of a multi module application set the mode in the very first
module to be loaded.

You will not see any copyright whatsoever in this software and you can use it
as you like but I would like "to be remembered" if you'll find it usefull. 
As usuall it is "as it is" and I assume no responsability if anything goes
wrong. However comments and any feedback are warmly welcomed, email them at:
"mantegazza@aero.polimi.it".