> > 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

WOW! Writing in assembler is difficult. Writing in absolute Hex or Octal is
so difficult it is impossible to describe. I know of only a handful of
people who have done it successfully. By successfully I exclude trivial
programs. Paul is now added to the list. My hat is off to you Paul!

Needless to say I am profoundly impressed by people who can write in
absolute Hex or Octal. I am equally impressed by people such as John Dinkels
who can read absolute Hex written by another person! Most programmers I know
have difficulty reading some one else's code, or for that matter, their own
after they have been away from it for a few months.

We should all be thankful that we have such a valuable resource in Paul.
Thanks, Paul.

Doc Custer
Retired Software Engineer and sometime Audiologist

John Dinkel cannot read hex code :) At least I don't think so. Can you John?
Doctor Dave Lynn of LASL can or could. I have not heard from him in 30 years.

We had no other choice in those days. I did not know what an assembler was nor could
I have afforded a teletype machine and computer to use one if I had an assembler:)
All we had was the hex keypad and the four seven seg LEDs for the address and
two seven seg LEDs for the instructions and data. You could store programs
on audio tape but that did not work all that great. I retrofitted the
Road & Track computer with an EPROM later.

The trick is you memorize the most used instructions like LDA(A9), JSR(20), JMP(4C),
RTS(60)  and STA(8D) and expand your tool box from there :) There are "only" 65 instructions
in the 6502. Plus of course five or more variations on each instruction depending on the addressing mode.

I would use blocks with NOP(EA)s in the last third so I could insert instructions if needed.

It took me a year :(

Later I invented a method of programming using pre printed bar code labels that you
pasted down with wax and used a light pen to read them in. HP started manufacturing
the method and I had to sue. I won but the lawyers got all the money. Another story.

John Dinkel cannot read hex code. At least I don't think so. Can you John?
John wrote a description of the system and its use a lay person could understand.
Doctor Dave Lynn of LASL can or could. I have not heard from him in 30 years.
I was in my early 40s and Dave Lynn was ten years older than me I would guess.
Of course since he was on the kitchen table and I was in the spare bedroom
or the garage he could ask me questions at any time.

Thanks for the complements Doc.
-- 

 > Paul Lamar

OOPS! Sorry I got the names confused. My apologies to Dr. Lynn.

Memorizing the instructions is only part of the problem, in my mind a minor
part. The parts that I found the most difficult were dealing with absolute
addresses. Any change in the code causes address changes unless you use one
of the ways of dealing with it as you describe: put in lots of NOPs so
address changes are restricted to the local code, unless of course, you use
them all up. Then you have to put in a JMP to a block of unused memory.
Variable space had to be allocated in a place that the addresses were
unlikely to change because if you change the address of a variable, all the
instructions that reference it will have to be changed unless you have a
micro with some kind of hardware help for this problem; I didn't. A linking
and relocating loader is the key to solving this problem. The assembler
helps with the symbols, including the instruction mnemonics and provides an
easy interface to the linking and relocating loader. But the loader is the
guy who does the real work. The use of these tools almost requires some kind
of mass storage, i.e., paper tape, mag tape or a disk. I HATE paper tape.
For small computers, the floppy disk (now obsolete) changed programmer's
lives dramatically. It was the first low cost, fast (compared to paper tape
or cheap mag tapes) random access and compact mass storage device. With two
floppy disks, you could operate not only an assembler and loader, but even a
FORTRAN compiler! What luxury!

Doc Custer
Retired Software Engineer and sometime Audiologist

Yes those are the techniques I used. Lots of NOPs. In the case of the Apple
II our Microproducts assembler came before the advent of the Apple II floppy disk.
We still had to use the silly audio tape recorder to save our programs
just like the Kim 1 and the SuperKim. I still have a bunch of those tapes.

MicroProducts had the first printer interface for an Apple II and the first
Eprom programmer. Here is a scan of early Microproducts ads. I think Microproducts
contributed greatly to the early success of the Apple II however somebody else would
have done it sooner or later. This add is from issue No. 10 March 1979
MICRO The Magazine of the APPLE, KIM, PET and other 6502 Systems.