Is it a habit we prefer mechnical instruments?

Didn't we just go through this.

Digital instruments are easy to program and don't take much computing
resources. Converting the display to a form fit for human consumption
take more computing and programming horsepower.

But it is still very little compared to a PC. With today's "stuff" an
old 6502 would probably have enough power.

Exactly right. Plus two additional problems:
1) Most modern general purpose computers have voluminous operating

What do general purpose computers have to do with flight displays.

With reasonable luck, nothing.


systems and take too much time to cold start (or boot up), even if ROM is

Actually the operating systems can start in seconds. It's all the
other stuff they have to load and interface with that takes the time.

This may be a semantic argument, but we seem to agree that starting with a
general purpose computer and OS would be less than obtimal--to understate
the situation.


substituted for the disk drive. That means a lot more programming.

Programs for flight displays should be relatively simple. Compared to
a "windows" or "Mac" they should be extremely simple.

2) Presently, there is too little standardization, especially of the
NAV

With this I agree to a point, but to say too little? There isn't any!

No argument there.

equipment. And integration of the NAV display(s) is a major reason for
considering electronic displays.

So it's not that we necessarily prefer mechanical instruments, but we
certainly have reason to demand that any replacement be at least as good
in
all ways important to a pilot, such as:
1) Ease of comprehension.

Glass panel

Actually, I agree with you. My point related back to the OP, which seemed
to ask whether our preference for an analog airspeed indicator (as an
example) was merely habitual, or the result of a true preference based on
the nature of use. Obviously the latter, as others described at length
earlier in the thread.

In point of fact, at my rate of progress toward getting a project under way,
I will almost certainly have a glass panel system installed prior to initial
completion; and for all of the usually cited reasons: lighter weight, lower
cost, more advantageous display format, and equal or better redundancy and
reliability of the complete system.

2) Similarity of controls and displays in aircraft a pilot might fly.

Actually with most using Garmin there is a lot of similarity, but for
those moving between different systems it can be more than a little
confusing.

Exactly.
3) Redundancy--at least as good as our old electrical plus vacuum.
4) Immunity from "wash out" in direct sunlight.

A properly configured system should have none of these problems.
LCDs can be constructed to be easily viewable in direct sunlight.

True. It just needs to be included as a specification--no matter how
confident anyone is that "everyone knows."

I own both a mid-range digital camera and one of the supposedly better
camera equiped cellular phones. Both are from respected manufacturers and
the displays become useless in something less than real direct sunlight. I
own other devices that share the problem; however the two that I mentioned
were purchased with the idea that I could use them outdoors...


Glass panels are more reliable, and once the pilot becomes proficient
with one they are easier to interpret than the old mechanical gages. A
good MFD with The AI, Heading, airspeed and altitude is far easier to
scan than mechanical gages.


My only disagreement with you here is one of nomenclature. I believe that
the AI, heading and airspeed are part of what is now being called the
Primary Instrument Display or possibly the Primary Flight Display. Most NAV
data would be part of the MFD, and a lot of redundancy is gained when the
fuctions can be swapped or overlayed in the case of a display failure. I
believe that (display swapping) means of redundancy was first developed for
military use, but has since gained fairly wide acceptance.

In many cases, little if any transition time will be needed when the display
is essentially similar. And there is an added benefit that the display
capability previously available only for fighters and heavy transports can
be economical in light singles in terms of both weight and cost.

Taken in logical order and one step at a time instead of trying to do
everything on the first flight, they are easy to learn as well. The
confusion comes when a pilot jumps into a plane with an unfamiliar
system and then tries to use all the bells and whistles instead of
just flying around for a while getting aquatinted with the system.

Especially dtrue for the current range of NAV equipment; and probably the
radar and COM equipment as well.

Peter Dohm wrote:
What do general purpose computers have to do with flight displays.

With reasonable luck, nothing.

I wouldn't be so quick to dismiss general purpose computers for flight
displays. Note that the richest man in the world got their by making
software for general purpose computers. It's precisely because of
their generic nature that people like them so much. Each person sees
in it what s/he wants, and it does a very good job of being that. And
when it doesn't, they pay an extra $300 for one that does.

A couple of decades ago, some could complain about performance, but
that's no longer the case. For example, each time you pop up Windows
Medial Player and view the psychadelic twirly things, the computer is
computing highly intensive real-time Fast-Fourier Transforms (FFT"s) on
the sound that is being heard. What's suprising is that you can play
10 of these audio files at once on a mid-range ( $1000) PC, and not
only will it work, but you can still type in Microsoft Word as if
nothing were happening.

Considering this, I seriously doubt that there is any computation that
at standard, $500 Dell PC couldn't handle from an aircraft.

In fact, a more likely scenario in an aircraft would be that the
computer could:

* show altitude, IAS, TAS, average velocity, average acceleration, etc.
* show stress all over aircraft as colors correlated to degree of
stress on parts
* show air pressure, humidity, etc.
* control fuel efficiency with exact precision
* play videos
* play music with psychedelic twirly things
* have voice-over-IP (VOIP) conversation with 9 other air-borne pilots
simultaneously
* render 3-D maps of terrain
* render 3-D map of airports
* render 3-D images of flight path
* show precipitation with little colored droplets and clouds
* record images terrain from web cam mounted underneath
* log flight data
* redisplay hotel information that was save in web page at airport
* control the heat warmers in seats
* control transparency of side windows
* control wattage of lights, internal and external
* show tire pressure
* show fuel level
* show oil level
* show hydraulic pressure
* control fuel mixture according to altitude, pressure, etc
* control throttle
* control, trim, pitch, yaw, roll
* control foot heaters
* control defoggers, wipers
* monitor pilot's face and do image recognition to see if s/he's dozing
off
* act as radio for ATC and other communications
* provide verbal warnings for unorthodox maneuvers and suggestions for
improvement
* synthesized verbal training based on actual conditions
* synthesized verbal read-out of current local atmospheric conditions
* synthesized verbal read-out of forthcoming atmospheric conditions
20-miles out
* show 3-D map of all other aircraft in vicinity
* allow kids to play video game in back seats

You could get a bunch of Garmin engineers in a room and ask them to put
this into a customized "device" and wait forever for it to be finished
with a non-general purpose computer. Or you can say, "Hey everyone,
we're going to be controlling this aircraft with a PC", and let
engineers all over the world do what they are good at, then put it all
together. Note that putting it all together would involve putting a CD
in a general-purpose computer 15 times and waiting for SETUP.EXE to
finish.

PC + USB-based mechanical sensors and controls. A powerful
combination.

-Le Chaud Lapin-

On Thu, 20 Apr 2006 22:51:53 -0400, "Peter Dohm"
wrote:


Didn't we just go through this.

Digital instruments are easy to program and don't take much computing
resources. Converting the display to a form fit for human consumption
take more computing and programming horsepower.

But it is still very little compared to a PC. With today's "stuff" an
old 6502 would probably have enough power.

Exactly right. Plus two additional problems:
1) Most modern general purpose computers have voluminous operating

What do general purpose computers have to do with flight displays.

With reasonable luck, nothing.


systems and take too much time to cold start (or boot up), even if ROM is

Actually the operating systems can start in seconds. It's all the
other stuff they have to load and interface with that takes the time.

This may be a semantic argument, but we seem to agree that starting with a
general purpose computer and OS would be less than obtimal--to understate
the situation.

Agreed! It certainly would be "less than optimal" and that is one
drastic understatement.

When you look at what is required for I/O as well as the operating
system these are, or should be, extremely simple systems.
The Basic Input/Output System (BIOS) is something a third year CS
student should be capable of writing in assembler.

Prior to going back full time for a 4 year degree in CS I took quite a
few tech courses. One of the classes (Computer architecture and
design) required we write in machine language no less, a program to
monitor 4 lines in, control 4 lines out, flash a specific text on the
screen for each input line when it was opened, Operate an output line
corresponding to each input line state, have specific keys to
acknowledge the alarm state, stop the alarm message from flashing and
go to highlighted. When the alarm condition was removed the text on
the screen had to go back to a safe state for the specific line. How
much time did we have to write the program? About two hours as it was
on the final exam. BTW it was not only expected to run, but to exit
gracefully so it could be run again. All the programming input was
from an alpha numeric keypad in Hex.

The computing power for everything except the display would be very
basic. Even the displays which we think of as dynamic are small,
relatively low res, and with so little movement that the system could
*almost* treat them as static.

This is the type of programming that needs to be done in either
assembler or machine language to keep it compact. It is definitely not
for the "visual" languages. Maybe straight C which is *relatively* low
level.
..


substituted for the disk drive. That means a lot more programming.

Programs for flight displays should be relatively simple. Compared to
a "windows" or "Mac" they should be extremely simple.

2) Presently, there is too little standardization, especially of the
NAV

With this I agree to a point, but to say too little? There isn't any!

No argument there.

equipment. And integration of the NAV display(s) is a major reason for
considering electronic displays.

So it's not that we necessarily prefer mechanical instruments, but we
certainly have reason to demand that any replacement be at least as good
in
all ways important to a pilot, such as:
1) Ease of comprehension.

Glass panel

Actually, I agree with you. My point related back to the OP, which seemed
to ask whether our preference for an analog airspeed indicator (as an
example) was merely habitual, or the result of a true preference based on
the nature of use. Obviously the latter, as others described at length
earlier in the thread.

Actually, I find the digital airspeed as easy to use as the analog and
the same is true for altitude and even VSI. The reason for this is the
lack of precision or rather the lack of need. If you have three
digits for airspeed and altitude the right most digit (most precision)
can be a blur while the second one is ticking away either up or down
and this is usually sufficient. In this case the pilot sees the
instrument very much like an analog unit. OTOH once you've gone that
far it requires little extra to create the analog graphic so you can
have both pretty much in the same spot and with much better
reliability than the old mechanical.

Still, there will be a certain % who just plain like the old
mechanical gages better. Of course with the younger generations you
may find many that prefer the electronic gages.

In point of fact, at my rate of progress toward getting a project under way,
I will almost certainly have a glass panel system installed prior to initial
completion; and for all of the usually cited reasons: lighter weight, lower
cost, more advantageous display format, and equal or better redundancy and
reliability of the complete system.

Yup although a full, redundant, glass panel is considerably more
costly than the old steam gage panel. At least I haven't found one
yet that I'd consider less expensive. OTOH they may do a *lot* more.

For non-certified glass panels I want to know how they are programmed.
That in itself will tell me whether I want to purchase one or not.

Once purchased and installed, I'll be testing that panel as much as
the rest of the airplane during the required test phase.
2) Similarity of controls and displays in aircraft a pilot might fly.

Actually with most using Garmin there is a lot of similarity, but for
those moving between different systems it can be more than a little
confusing.

Exactly.
3) Redundancy--at least as good as our old electrical plus vacuum.
4) Immunity from "wash out" in direct sunlight.

A properly configured system should have none of these problems.
LCDs can be constructed to be easily viewable in direct sunlight.

True. It just needs to be included as a specification--no matter how
confident anyone is that "everyone knows."

Been there, done that, and I know that "not everyone knows":-))

I own both a mid-range digital camera and one of the supposedly better
camera equiped cellular phones. Both are from respected manufacturers and
the displays become useless in something less than real direct sunlight. I
own other devices that share the problem; however the two that I mentioned
were purchased with the idea that I could use them outdoors...

I have two digitals. An Olympus E-20N which is a great camera, but man
is that thing slow. The other is the Nikon D70 dSLR. Both work well
in direct sunlight, but I never use the LCD displays.



Glass panels are more reliable, and once the pilot becomes proficient
with one they are easier to interpret than the old mechanical gages. A
good MFD with The AI, Heading, airspeed and altitude is far easier to
scan than mechanical gages.


My only disagreement with you here is one of nomenclature. I believe that
the AI, heading and airspeed are part of what is now being called the
Primary Instrument Display or possibly the Primary Flight Display. Most NAV
data would be part of the MFD, and a lot of redundancy is gained when the
fuctions can be swapped or overlayed in the case of a display failure. I
believe that (display swapping) means of redundancy was first developed for
military use, but has since gained fairly wide acceptance.

No argument.
The system I'm looking at only has two screens and they are redundant
MFDs. You can set the PFD to either or both. You can even
compartmentalize the display and put the engine instruments on either
one or both. Why any one would want them all on one I don't know, but
it can be done say in case one display fails.

In many cases, little if any transition time will be needed when the display
is essentially similar. And there is an added benefit that the display
capability previously available only for fighters and heavy transports can
be economical in light singles in terms of both weight and cost.

Taken in logical order and one step at a time instead of trying to do
everything on the first flight, they are easy to learn as well. The
confusion comes when a pilot jumps into a plane with an unfamiliar
system and then tries to use all the bells and whistles instead of
just flying around for a while getting aquatinted with the system.

Especially dtrue for the current range of NAV equipment; and probably the
radar and COM equipment as well.

Agreed and you now have the option of downloaded weather RADAR as well
which can be displayed as an overlay on the moving map display. I
sure would like something like that in the Deb but the panel would be
worth more than the plane. :-))

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

On 20 Apr 2006 19:16:22 -0700, "Le Chaud Lapin"
wrote:


Peter Dohm wrote:
--------snip---------

Digital instruments are easy to program and don't take much computing
resources. Converting the display to a form fit for human consumption
take more computing and programming horsepower.

Exactly right. Plus two additional problems:
1) Most modern general purpose computers have voluminous operating
systems and take too much time to cold start (or boot up), even if ROM is
substituted for the disk drive. That means a lot more programming.

I think if you're about to take a trip, waiting the whole 17 seconds
for the OS to boot (Windows) won't hurt too much.

2) Presently, there is too little standardization, especially of the NAV
equipment. And integration of the NAV display(s) is a major reason for
considering electronic displays.

This is true. Also, I have looked at some of the gadgets that are
produced by Garmin (and Raymarine for you boat-lovers). I think it is
important to realize that, when a software engineer at one of these
companies sits down to make software for their gadgets, the complexity
presented to them is often more than that which is presented to someone
who programs a regular PC. This started changing a bit when Microsoft
started selling embedded versions of their OS's, and now, a

Even imbedded Windows is far too complex and particularly a full
featured version. That kind of complexity is neither needed or
desirable in a glass panel, or any of the instruments in that panel.
Windows was designed to be flexible and programmer friendly. The DLL
which is both its strong point and the weak point is the reason code
written to run in windows is generally so bulky. Often called "bloat
code" and for good reason. I still do some programming. One we
used in the home builders center for a few years. That program would
do a search on N#, Owner, Row and position where parked, Make and
model, Home town, State and even country although as you can imagine
the number of returns increased rapidly as we go through that list. .

The thing is I only had about 32K of source code, but when compiled
into a stand alone program it was many megabytes and virtually all of
that bloat came from DLLs.

full-feature version of XP that is meant for embedded system. Yet
still, there are many devices that uses unconventional hardware, and
then hire programmers to work really hard to tweak it just right.

XP as an embedded OS is an oxymoron as the usual reason for embedding
is simplicity and compactness.


Compare that to going to a young programmer who knows how to make fancy

Careful, that's age discrimination :-)) There are a few of us old
guys out there that do that kind of programming too.

graphics on standard PC using C++, and you can see the difference.
S/he would probably be able to create almost anything you can imagine,
with much, much less cost than there would be with custom device. I

These are "Object Oriented" languages and much of the work is already
done.

cannot emphasize enough that the young people who program and know

There you go with that age thing again.

computer graphics can create graphical presentations that are far
beyond what Garmin is currently making. And everytime you get into a

And there is a big reason for that. It's called available memory and
the available memory is constrained by the actual design. GPS, MFDs,
and other electronic displays in the cockpit need to be kept simple.
Certified instruments need a minimum of code to be certified so the
smaller the better.

The complete OS in a glass panel probably contains less code than just
one DLL in windows. The BIOS is going to be just about the absolute
minimum to get the job done.

They want to keep the memory "density" down as well as using the
minimum number of chips.

simulator that is rendered by a digital display showing analog
controls, you are convincing yourself that it is "ok" that the analog
controls are rendered digitally.

To me that makes no sense, but I'm sure it does to some.
I don't care how the thing is rendered, whether it's a needle mounted
on bearings or a graphic display showing a needle. They are both
analog displays. One just happens to be an analog display that was
digitally rendered.

But again, the real power comes from the possibility of letting the
computer open up more of your plane and your environment to you.

Here it depends on how the information is used and how it's presented.
There is nothing in a light plane that requires much computing power.
That remains true if you use a glass panel and render every single
instrument digitally, or add strain gages to monitor the health of the
fuselage. Add GPS, moving map display, weather RADAR, inertial nav
with solid state gyros as a back up to the GPS. With the exception
of the display (which is handled separately) it's quite likely the old
Commodore 64 or even a VIC 20 would have had enough computing power
for the job.

We need to be careful about what we put into our panels. Software for
PCs has been in a vicious cycle for some years now where the software
manages to use up all of the computing power which leads to more
powerful CPUS which lead to more powerful computers which leads to
larger programs. When we were limited by computing resources, bloat
code wasn't a problem as it didn't exist. Side effects (unexpected
results) were minimal as there were few modules interacting with each
other in programs.

Most students become intimately aquatinted with side effects when they
start working with pointers. It was great in the old straight C
programming days as C made the assumption the programmer knew what
they were doing and would let you do virtually anything. Today's
languages are strongly typed. That means you can only add an integer
to an integer. You can only use floating points with floating points
and addresses (pointers) with addresses. Straight C let you add an
integer to a floating point to an address to a string or any thing
else you can imagine.

For a number of reasons we have to keep the code used in aircraft
compact. Just two reasons are safety/reliability and ease of
certification.

So it's not that we necessarily prefer mechanical instruments, but we
certainly have reason to demand that any replacement be at least as good in
all ways important to a pilot, such as:
1) Ease of comprehension.
2) Similarity of controls and displays in aircraft a pilot might fly.
3) Redundancy--at least as good as our old electrical plus vacuum.
4) Immunity from "wash out" in direct sunlight.

True about the redundancy. We can't have a bad transistor bringing
down the aircraft. But digital sensors are cheap, lightweight, and and

Not when they are certified for use in aircraft. They may be light
weight and accurate, but adding them to an aircraft took away the
"cheap"

accurate. If it fails, the computer will know immediately. With

Only if the system is programmed to know and how are you going to
program it to know. An open or shorted sensor is just another input
unless there are valid limits programmed into the system. But that is
not enough either. The system has to have a way of notifying the
pilot that the oil pressure, or CHT, or EGT reading has gone bad AND
it's the sensor, not the actual oil pressure that had gone. Zero oil
pressure and an open or shorted sensor may and probably will appear
the same to the input of the A/D converter. It has to do this
immediately, but without interrupting, or obscuring vital data the
pilot may need at the moment. Sure it can be done and reliably, but
each step adds complexity and cost.

standard interfaces like USB, it would be a simple matter of finding
the faulty part, throwing it in trash (as opposed to repairing it), and
replacing it with a new one. The computer would tell you if the new
one is OK.

The problem is that what looks good when it is used here on the desk
may not be good for us out there in the real world. What appears
simple at first glance, isn't, or what appears simple with the system
on my desk isn't out in the real world. It's best to think of it this
way. If it looks simple it probably isn't, you don't have enough data,
or you forgot something.

Right now I'm setting in front of a 20.1" (gotta remember that point
one) LCD which is driven from a video card that will also serve as an
output to my TV, take signals from the TV, has a tuner for off the air
signals, has S-video inputs and outputs as well as composite and
digital. That video card is in a 64 bit computer with more on board
cache than my first computer had memory. The computer has over 1.6
terabytes of hard drive storage. My computers back up to each other
across a gigabit, hard wired CAT5e network. I use external hard drives
connected via USB for OS backup. I use USB2 for camera and memory
card input. With all that sophistication, absolutely none of this
would be worth beans in an airplane.

BTW as a side note. This big computer cost less than half my first
computer which was a one MHz 6502 with 48K of dynamic RAM and dual
360K, 8" floppies and that was before getting a monitor and keyboard.
The whole system here didn't cost a lot more than that first simple
computer.

-Le Chaud Lapin-

The point I'm trying to make is for glass panels the code is kept as
compact as possible which means custom software that has to be
certified. These things are a long way from what sits on our desks.


Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

My primary concern with the glass panel in light planes is -

what happens when the lights go off?

My antiquated mechanical steam powered gizmos will still work.

If the airspeed indicator clams up, the altimeter still works.

There was once an old saying about putting all your eggs in one
basket - You can do it, but you have to watch that basket carefully.


Richard

"Le Chaud Lapin" wrote

I wouldn't be so quick to dismiss general purpose computers for flight
displays. Note that the richest man in the world got their by making
software for general purpose computers.

PC + USB-based mechanical sensors and controls. A powerful
combination.

Is anyone (besides me) beginning to think that we are on the receiving end
of a real practical joker?

Too many things don't add up. Statements about things in China that are not
realistic, or possible. (homebuilt airplanes in China? I don't think so.)

Use of English that is on a level that someone might expect for a poster
from China, then this last bit of this post. No mistakes, use of phrases
and English vocabulary (psychedelic twirly things?) that would not be
typical of a foreigner, unless they had very good control of English, then
there would not have been all of the earlier mistakes.

Totally far out ideas, that nobody would want to even consider, and for
someone making instruments, they would have a better idea of what is desired
and possible.

There is more to make me come to this conclusion, but I don't feel like
going back and digging it all out.

I don't know about ya'll, but I've had enough of this one. Some of you can
continue to play, if you want, but not me.
--
Jim in NC

On Fri, 21 Apr 2006 07:08:31 GMT, cavelamb
wrote:

My primary concern with the glass panel in light planes is -

what happens when the lights go off?

Battery backup.
You can have an internal back up that will keep the instruments
running for some time. Plenty of time to look for an airport and land
safely which I'd be doing with either type of gages. :-))

My antiquated mechanical steam powered gizmos will still work.

If the airspeed indicator clams up, the altimeter still works.
You could carry it to the extreme like an F-16. If they lose power
they only have a few minutes to get on the ground before the computers
that fly the airplane quit.

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com
There was once an old saying about putting all your eggs in one
basket - You can do it, but you have to watch that basket carefully.


Richard

Morgans wrote:

"Le Chaud Lapin" wrote

I wouldn't be so quick to dismiss general purpose computers for flight
displays. Note that the richest man in the world got their by making
software for general purpose computers.


PC + USB-based mechanical sensors and controls. A powerful
combination.


Is anyone (besides me) beginning to think that we are on the receiving
end of a real practical joker?

Too many things don't add up. Statements about things in China that are
not realistic, or possible. (homebuilt airplanes in China? I don't think
so.)

Use of English that is on a level that someone might expect for a poster
from China, then this last bit of this post. No mistakes, use of
phrases and English vocabulary (psychedelic twirly things?) that would
not be typical of a foreigner, unless they had very good control of
English, then there would not have been all of the earlier mistakes.

Totally far out ideas, that nobody would want to even consider, and for
someone making instruments, they would have a better idea of what is
desired and possible.

There is more to make me come to this conclusion, but I don't feel like
going back and digging it all out.

I don't know about ya'll, but I've had enough of this one. Some of you
can continue to play, if you want, but not me.



It crossed my mind...

This is a job for Assembly language.

There is just so much to do (more than you expect) and so
little time to do it in.

A modern team would probably prototype in C (+/-) but only to flesh
out what they were trying to do. Then they would start coding the
inner loops in Assembly until it ran fast enough (that's a joke!).

In the end, it winds up all Assembly anyway, just compiled rather
than assembled. And using the compilers STDLIB, rather than mine.


I dug up this old Clunky CGA graphics hack, but it demonstrates some
of the processing power (and the technique) needed to do vector graphics
for something like an attitude display.
This started out on a 16 Mhz AT.

I think it showcases my high speed line drawing routines quite well.
Which is really why it was written.
(one of my "acquired" computer skills - Multi-lingual programmer

http://www.home.earthlink.net/~tp-1/HUD/HUD01.ASM
http://www.home.earthlink.net/~tp-1/HUD/HUD01.COM

Files:

HUD01.ASM 56192 bytes long.
Assembly language source code for a clunky CGA Heads Up Display Demo.
Straight forward assembly with MASM 5.1
Copyright reserved. Non commercial use (unless I get to play too)


HUD01.COM 4785 bytes long
Caution! Executable file!!!


It was clean when I put it up on the web, but you might take note of
the file size, and scan if you feel you should.

The slider displays (vertical read out?) are driven from the keyboard.
Top row - Q to P.
UC INCREASES, lc decreases.
G toggles the gear.
ESCAPE key to quit.

Flight is via the keypad keys: 1- 9

It does weird barrel rolls....


Richard


;Update header from HUD01.ASM
;======================= COMMENTS ========================
;
; Due to the large number of variables needed, and the rather limited
; register architecture of x-86 processors, all variables, flags, etc.
; are located in main memory. No attempt is made to keep certain things
; in specific registers. Subroutines protect the contents of registers
; when necessary. Most of the storage locations are defined at the
; end of this file, however, the circle coordinates are located in an
; external file: "HUD01G.CIR", which was generated by "CIRCLE4A.BAS".
;
;======================= UPDATES =========================
; 09/27/89 * Started HUD01 attitude display program.
; Program uses CGA graphics screen and direct video memory
; writes for maximum speed.
; 09/28/89 * HUD01G1.CIR file generated by CIRC4.BAS
; 09/30/89 * Preliminary program working properly ok.
; Drawing rate is a bit slow due to the complexity of the
; calculations required for direct screen update.
; 10/10/89 * HUD01G1.CIR modified to include markers every 90 degrees
; to make it easier to find horizontal/vertical coordinates.
; 10/13/89 * killed bug in line drawing routine that caused fuzzy circles.
; 10/16/89 * modified X_LINE to make S_LINE routine.
; X_LINE uses XOR, S_LINE just plots...
; 10/22/89 * Pitch bar wraps around at 90 degrees.
; 10/25/89 * Roll and Pitch interaction working smoothly.
; 11/08/89 * Added routines to interface to the external sensors via X-BUS.
; 11/10/89 * Killed the final bugs (?) involving table wrap
; 11/12/89 * Doubled control response rate (by cheating).
; 11/14/89 * Rewrote keypad parser for simultaneous pitch/roll
; Keyboard parser uses numbers 1-9 for inputs.
; 11/18/89 * Numlock turned on/off automatically on entry/exit.
; 11/20/89 * Added vertical readout boxes to screen
; Added EOC and BOC routines to reduce size of code (about 1k).
; These check End Of Table and Beginning Of Table.
; 11/22/89 * Added INVERTED indicator, gear displays.
; 11/25/89 * Added vertical display indicators, slight modifications to
; panel layout to allow simple character indicator.
; Uppercase input moves indicator UP, lowercase moves down.
; 11/28/89 * Moved attitude display to seporate routine.
; Flags used are P_Invert & R_Invert
; 12/02/89 * Fixed minor bug in PrintC (wrong print interupt)
; * Modified Show_Cross to get pitch value from P_BAR.
; Pitch and Roll now run continously (0-360).
; P_Bar wraps at 90 degrees to correct horizion motion.
; 12/04/89 * Added Heading/Reciprocal display

;************************************************* ********
; This routine simulates sensor inputs via keyboard.
; In fully implemented form, the sensor inputs would come from
; the vertical gyro instrument, probably through an ADC S80 chip,
; since the gyro outputs normally drive a synchro-resolver motor.
;
; When sensors are used for input, the local processing found here
; (upper and lower limits) would be added to the sensor driver code.
; The keyboard routine is implemented as a linked list below.
;

On Wed, 19 Apr 2006 15:10:53 -0400, "Peter Dohm"
wrote:

I think we're being told a lot of digital stuff is "better"
when it really isn't in some ways. Digital stuff is much cheaper to
manufacture, because machines can assemble almost the entire thing,
while analog devices have small moving parts that usually need to be
put together by hand. The profit on digital equipment must be a lot
higher, especially on the cheap stuff.
I can't use digital meters while troubleshooting electrical
problems. The digital VOM I can afford only samples the voltage or
whatever about once a second, making any rapid adjustments or quick
readings impossible. The old analog meter goes immediately to the value
and shows any changes instantly. In cold weather the LCD digital
display gets sleepy but my mechanical needle still works faithfully.

Dan

Good points, one and all. And my experience as well.

Peter


There is one area where an electronic display could offer something
better than a mechanical instrument.

if you are fault finding something a history can be priceless. in
many(most) of the Citect industrial controls environments we provide a
popup graph mechanism which shows the value over the last couple of
minutes.
"how long has that oil pressure been dropping like that?" is something
that is answered immediately by a small trend graph of the value.

btw it is worth noting that most good pilots are long sighted and
quite often have a less than crystal clear view of nearby items so
having large graphical items on the instrument faces makes them easy
to read, especially in turbulence.

my flight watches(timepieces), for instance, I evaluate on the basis
of being able to recognise the time with just a momentary glance.
they are all analog and have very plain faces.

Stealth Pilot