One of the really neat things about DOS Quick Basic for real
time programing is it has hardware interrupt capabilities.
In other words regardless of what the program is doing
it can be interrupted by an external electrical signal and forced
to run a sub program to deal with it. For example we could
interrupt the QB program every time the rotary hit TDC on
rotor one. At 7500 RPM this happens only 125 times a second.
A piece of cake for a PC processor that is 25 times as fast as
your average CPU found in a typical EFI system.

One trick is to use a USB to RS232 adapter and use the Clear
To Send signal as an input to QB from the crank angle sensor.

The QB command is: ON COM(1) GOSUB ServiceTDC

--------------------------------------------------------

I ran into a snag using ON COM.

The ON COM handler doesn't really tell you a lot about what
caused you to get there, just that a COM port event happened.
The best you can do is see what the last position written in
the buffer is using LOC , and try to pull that many characters
off using INPUT$.

The ON COM response appears pretty slow, as some times 3
characters can build up at 9600 baud before it responds.
It can take anywhere from .3 seconds to .1 seconds for ON COM to
work. That is 100 to 300 ms while the engine rotates once in
7 ms at 7500 RPM. Totally unworkable.

So I switched to Power Basic for DOS which is more or less
a clone of QB. Not quite as good a user interface IMHO but
not bad either and it is still being maintained.

Enhanced communications support.  Support for COM1 through COM4 at up
to 115200 bps.  Even support for non-standard addresses and IRQs as
well as 16550 FIFO support. This is 12 times faster or 8 ms. It is
likely PB can do hardware interrupts in some other way that is more
direct and that take full advantage of the speed of the processor.
We shall see.

------------------------------------------------------------
I just had the bright idea for implementing 31 high speed
external hard ware interrupts for our DOS-BASIC EFI system.
No more ON COM(x).

Both QB and PB have an ON KEY(xx) hardware interrupt.
Some of the key board keys implemented are F1, F11 and F12.
Key F11 could be rotor 1 TDC and F12 rotor 2 TDC.

Key boards are super cheap and they all have a single chip
computer inside that can detect a key switch closure and convert it to
a code and send that code to the mother board. We will build a
device that goes between the key board output connector and the
keyboard input connector on the mother board that sends out
the code. This will have 31 input lines and solid state switches
that in effect will close the 31 key switches.

The ON XXXXXX function in QB and PB check for this code automatically
between each normal instruction so it is super fast.

This is a major step forward for the use of DOS BASIC's for real time
hardware control. This is another idea from the old SuperKIM days
back in 1975 but I only had 8 hardware interrupts in those days.

Patent applied for.


--------------------------------------------------------
On further research on exactly how BASIC implements ON EVENTs I have
decided to do away with ON EVENTs. What happens is the compiler
inserts bit checking code between all and every instructions. If
you turn off ON EVENT your code runs nearly twice as fast. If I wanted
to check some bits on an input port some place I merely need to
PEEK the port and check the bits between each instruction. I
can now detect top dead center in as little as 10 micro seconds
or so.

This drastically simplifies the code and the number of BASIC
commands the programmer needs to learn. IMHO the entire program
can be done with about a dozen different commands. Anybody
can learn just 12 BASIC commands. That is not to say there
are only 12 instructions in the program. However my guess
is the program will be less than 100 instructions total.

Lets say I find out when Rotor one is at TDC at 7500 RPM. I don't need
to keep checking for rotor one arrival as I know it will not happen again
for 7,000 micro seconds or about 14,000 BASIC instructions in this computer.
I am not talking about assembler instructions. I am talking about
BASIC instruction commands as they can execute in as little as
one half micro second. I have proven that so far. A one gig
processor (as this board has) can probably execute one
assembler instruction in as little as .2 microseconds.

Around half of that 14,000 BASIC instructions I know TDC on rotor 2 will
appear so I can start checking for the arrival of TDC on rotor 2.

This means I can do away with the keyboard computer for interrupt service
as well as the RS232. No ON COM or ON KEY.

I am now down to only the printer port hardware. The printer port
has 13 output pins or bits and 9 input pins or bits to work with.
I only need 2 output pins for injectors as both injectors on one
rotor are fired at the same time. Another 2 output pins can fire
CD ignition systems with advance if desired. One for each rotor.

I need 4 input pins for the digital throttle position sensor
and 2 pins for the crank angle sensors. Thats it for a simple
system. No A to D required.

More than enough pins in the printer port alone to do the entire EFI
system. I just need some power transistor to switch the injectors and
some signal conditioning circuitry for the two crank angle sensors.

Here are the printer port addresses in hex and decimal.
This brand of mother board has a printer port on card. You
can see it just to the right of the video connector and
bit higher.

What you see here is what a programmer has to deal with when
writing real time code to control hardware. This is exactly
what the people that designed the fly by wire F16 and Airbus
had to deal with. It is not so much what is done but how much
time it takes to do it and when it is done.

Paul Lamar