> > Ughh, DOS. Just kidding (sort of)..
> >
> > Anybody here work with a Real-time OS? I have always
> been kind of
> > curious about how a real time version of Linux differs
> from a regular
> > one. Just stripped out? I'd think a real-time OS would
> be good for
> > something like engine management and monitoring..
> >
> > http://en.wikipedia.org/wiki/Real-time_operating_system
> >
> > http://www.realtimelinuxfoundation.org/
> >
> >
> >
> > Matt-
> >
> > Me. I wrote my own real time OS back in 1976 on a 6502
> in assembly
> > language.
> > My road test system would take in data every few milliseconds
> process it,
> > display on the instrument panel with an LCD, and send it
> to the
> printer in
> > real time while the printer is printing. All using a ONE
> megahertz > processor
> > and 2K of EPROM and ONE K of RAM! I also designed and
> manufactured the
> > SuperKIM
> > mother board. Probably the first commercial application
> of an
> embedded
> > microprocessor.
> > For sure the first real time multitasking microprocessor
> software. Before
> > the Apple II.
> > Read all about it:
> >
> > Microprocessor-Based System for Roll-Down and
> Acceleration Tests
> > by D.K . Lynn, C.R. Derouin, and Paul Lamar
> > Los Alamos Scientific Laboratory
> > Published in IEEE Proceedings 29th Vehicular Technology
> Conference > (The technical details of the Lamar
> Instruments real time road test
> > system.
> > The Phd's get to have their name before mine :))
> > Arlington, Illinois, March 28-30, 1979
> >
> > http://www.computer-dictionary-online.org/?q=6502
>
> > http://www.hansotten.com/indexkim.html
> > http://www.kim-1.com/docs.html
> >
> > Well When Windows came out they busted a lot of real time
> applications
> > because
> > you could directly access the hardware using QB running
> on DOS.
> > There were instructions called IN and OUT that directly
> accessed the
> > hardware at light speed. PEEK and POKE did the same thing.
> > All that is gone.
> >
> > Paul Lamar ...No rotor no motor.
> >
> >
> > Here is the prototype Matt. I went out to the hangar and
> dug it up.
> > Road & Track used it for about five or ten years to
> > test cars. This is one of the very first Kim 1s.
> > Note; the ceramic packaging and gold pins on the CPU
> > and ROMs. I now have it back. The Superkim computer was used
> > in the production model for years and then we redesigned it
> > keeping most of the features but doing away with the keyboard
> > and six seven segment LED.
> >
> > John Dinkel (on here) wrote a few articles about it.
> >
> > Computerized Slalom & Skid Pad Testing by John Dinkel
> > (Article about the Lamar Instrument Road Test equipment.)
> > Road & Track May 1977
> >
> > Road Testing by John Dinkel
> > (Article about the Lamar Instrument Road Test equipment.)
> > Road & Track Buyers Guide 1978
> >
> > Other articles were written in other magazines.
> >
> > --
> > Paul Lamar ...No rotor no motor.
>
> Real-time UNIX is a very different beast than "regular"
> UNIX. Or Linux.
>
> Both UNIX and Linux are time-sharing OSes. They have a
> scheduler that
> decides which process (program) should run next. The
> scheduler has a
> round
> robin with priority system but it is not adequate for real-time
> because a
> process is allowed to run until it has used up its quota of
> CPU time or
> until it is blocked or waiting for a I/O operation. This
> means that
> a high
> priority process might have to wait until the currently
> running process
> gives up the CPU. UNIX used a 2 second time quota. Two
> seconds is an
> eternity for a real-time application.
>
> Real-time OSes can force the running process to give up the
> CPU to a
> higher
> priority process whenever the higher priority process needs
> the CPU.
> This is
> a major modification to a time-sharing OS. It is not just a
> matter of
> changing the scheduler, and of course this has to be done.
> Experience has
> shown that there are lots of places where the code assumes
> the original
> scheduling scheme. Sometimes in strange places and at strange,
> unexpected
> times. And they don't all show up at once. Very difficult
> to de-bug.
>
> Doc Custer
> Retired Software Engineer and sometime Audiologist
>
> That is why I designed the hardware priority interrupt structure
> in the SuperKim. If an external event (a rising edge of a pulse)
> came along that needed instant response it set one of eight
> latches. These latches were connected to a priority encoder.
> The encoder would
> then signal the interrupt request pin (IRQ) on the 6502.
> The 6502 would
> stop what it was doing and read the priority encoder to
> find out
> which of
> the eight latches was requiring service. The 6502 would
> then reset
> the latch
> allowing another event to set it again. This part of the
> code took about
> 20 or 30 instructions and happened in 20 or 30 micro
> seconds. The
> 6502 then processed the request.
>
> One of the latches was connected to a real time clock pulse.
> This interrupted the CPU every .001 second. Another was
> connected to
> the fifth wheel. The fifth wheel put out 100 pulses per foot
> so at 200 FPS the CPU was being interrupted by the fifth wheel
> at 20,000 times a second or every 500 microseconds. Way
> more than
> enough
> to process that request. This scheme can be used as a super fast
> hardware multiply
> and divide. If a FPS pulse comes in, sets a latch and
> reads the fifth
> wheel counter at precisely .1 seconds the counter will
> contain 2000
> pulses.
> Guess what? That is 200.0 Feet Per Second accurate to one
> part in 2,000
> and that number is merely sent to the display and printer. Takes
> only a few
> microseconds. Obviously the display and printer are updated
> at 10
> times a
> second which is a blur to the human eye. This is only part
> of the
> system.
> There were hardware interrupts that came in at other times.
> The 6522
> timer
> counters were used to generate these tones fed to the latches.
>
> This was all done with a 1 MHz processor. When the 2 MHz
> 6502 came out
> we were in seventh heaven. The PhD's at Los Alamos
> Scientific Labs were
> so impressed with this system after they read John Dinkels
> article in Road & Track magazine that Doctor Dave Lynn
> called me up and asked if
> he could study the system. I wrote all the code in hex
> (took me a
> year) so he offered
> to translate it to assemble language and assemble it on the 6502
> cross assembler
> they had working on the Cray 1 computer back at LASL and
> send it
> back to me.
> I said yes so Dave flew over to Hermosa Beach and studied
> the hex
> code on my
> kitchen table for two weeks.
>
> He then went back to LASL and wrote the IEEE paper
> mentioned above.
>
> About the time I got the 6502 assembly language code back
> from LASL
> the Apple II
> mother board became available with out the case, keyboard
> and power
> supply.
> I bought one and got it up and running.
>
> Bob Bishop from Jet Propulsion Labs in Pasadena contacted
> me and
> said he had
> a 6502 cross assembler working on the Apple II. We then
> used that
> assembler to
> further develop the code in the road test system. We
> started another biz
> called Microproducts to sell that assembler and hit a gross sales
> number
> of 200K a year within a year. First assembler available for the
> Apple II.
> Many Apple II programs were written using that assembler.
> Another story.
>
> I owe it all to John Dinkel for giving me the contract to
> develop the
> road test system for Road & Track in the first place.
> Thanks again
> John.
>
> I also owe it to my ex wife Rhonda and her cat Kubla (for
> walking on
> the Kim 1 keyboard at night) for supporting me for the year
> or so
> it took to write the code and design the SuperKim. Thanks Rhonda.
>
> A rotary engine fuel injection system built around the SuperKim
> would be a piece
> of cake.
>
> Paul Lamar ...No rotor no motor.
>
>
> Thanks Doc for reminding about task scheduling.. I used to
> think about
> stuff like that.
>
> Interesting history Paul. I didn't realize you were a computer geek.
> :) With that background, forget the all mechanical FI system.
> A little
> electronics can make things much nicer..
>
>
> Regards,
>
> Matt-
>
> BTW here is an interesting aside. This road test system was so
> accurate(1/100 of a foot) it was bought by a company called
> Interstate Electronics,
> as I recall, that was building and calibrating missile firing
> submarines inertial navigation systems long before GPS became
> available. If a missile
> fired at Moscow missed it would have been my fault :)
>
> --
> Paul Lamar ...No rotor no motor.

Scary!!! I did know about the 2nd or 3nd computer store you opened.  But
like Doc is saying Paul you are a computer geek.  Paul I'm happy you got
involed in Rotary engine and about the newsletter.  Thank you :)))

Marc J.
Nexus Mustang


The Rotary Engine NewsLetter. Powered by Linux.
ACRE NL web site. http://www.rotaryeng.net
Copyright 1998-2006 All world wide rights reserved.