Old minicomputers in ~1970.

[qwseyvnd 0]

How do they simulate the full flight simulator?

Do they use a lot of cpu to connect them serial, for example altitude from 0 to 255 feet, then switch to next CPU from 256 to 511 feet, and so on ?

Do they make many small CPU parts for each instrument ?

Specialist computer ?

[untoweechja 35]

Interesting question -- hopefully someone with experience in that area will chime in.

 

I could well be wrong, but I'm guessing there were more people than computers involved in running full flight simulators of that era, especially outside of the military.  There was probably a lot of "pretend" going on, too.

[JRBarrett 3,076]

Back in those days, digital computers were not used in full-sized flight simulators. I had some experience with that - In the late 1980's, I used to work on a Link GAT-1 simulator at the local FBO, that was originally manufactured in 1969

 

It used strictly analog technology - all of the flight instruments in the cockpit used electric servo motors to move the various dials and pointers - all of the "flight model" calculations were done using variable voltages, phase comparators, variable resistors etc.

 

Mini and main-frame computers WERE used in the aircraft industry 40 years ago, but mainly for solving mathematical equations used in the design of aircraft structures. None of the computers of that era would have had the processing power or memory capacity to serve as the core of a full flight simulator.

 

Computers were used to solve complex navigation and trajectory equations on things like the Apollo command module and lunar lander, but even those "state-of-the-art" real-time computers were extremely primitive by today's standards. A modern hand-held calculator probably has far more processing power than any of the mainframe computers used in NASA in the 1960's

[tf51d 284]

I use to operate, and later programmed a Digital PDP 11/70 mini-computer. You think working with FSX 4GB VAS limit is bad, try working with 16bit with a limit of 64KB!. There was 2 ways to do it. One was to write multiple executables with 1 or more common data libraries (Also executables). The main application would act as the traffic cop, and transfer control between the other apps, which would all use the same data areas to process. When finished each app would transfer control to the main app, which will then proceed to the next step in processing. As you can imagine, good housekeeping was essential for this to work properly. You could easily run into address space over runs, or overwriting data in a common data area, corrupting your output. Or if the one app didn't transfer control properly, the app could stall or go into a processing loop. Since each app was separate, debugging was a little easier, then the second method. That is overlays. This is where routines as needed would be paged out and the address space overlaid with the next routine and so on. Again proper cleanup was essential. When a problem did occur you got a program dump this would be in Octal. First you would have to determine what routine and data areas was in memory at the time, then determine if the problem was in that routine, or data passed on from previous executed routines. Sometimes it was like finding a needle in a haystack. This was all in assembler, and you didn't have the debug tools you have today.   

[spesimen 135]

this video has some info about a general purpose sim from 1970, at around 9 minutes they discuss the architecture which was a pdp-1 running the graphics and controls and a networked pdp-10 to do the physics/flight calculations! it's quite curious and amusing, it looks about like how fs1 looked on the early apple 2 machines

 

 

 

cheers

-andy crosby

[JRBarrett 3,076]

Or the original "Spacewar" written for the PDP-1 by Slug Russell at MIT in the early 1960's. One of the inspirations for "Asteroids" many years later.

 

Spacewar was amazingly fast and graphically elegant - remarkable (considering the hardware of the day). All done using vector graphics in hand-coded and highly optimized assembler.

 

When I entered the Air Force in 1973, the A.F. was still operating the SAGE system, which was a key part of the U.S. air defense system mainly concerned with detecting and tracking incoming nuclear missles and bombers.

 

One of my friends at the Air Force tech school at Keesler AFB was training to work as a SAGE computer technician - the training course was almost 1 full year long.

 

The SAGE system was designed in the 1960's, and each site in the network had an enormous mainframe computer system housed in a building as large as a modern-day sports arena - (and which used as much electrical energy as a small town) - and yet an early 1990's vintage 486DX desktop computer had far more raw computing power than an entire SAGE site from 20 years before...

[qwseyvnd 0]

I use to operate, and later programmed a Digital PDP 11/70 mini-computer. You think working with FSX 4GB VAS limit is bad, try working with 16bit with a limit of 64KB!. There was 2 ways to do it. One was to write multiple executables with 1 or more common data libraries (Also executables). The main application would act as the traffic cop, and transfer control between the other apps, which would all use the same data areas to process. When finished each app would transfer control to the main app, which will then proceed to the next step in processing. As you can imagine, good housekeeping was essential for this to work properly. You could easily run into address space over runs, or overwriting data in a common data area, corrupting your output. Or if the one app didn't transfer control properly, the app could stall or go into a processing loop. Since each app was separate, debugging was a little easier, then the second method. That is overlays. This is where routines as needed would be paged out and the address space overlaid with the next routine and so on. Again proper cleanup was essential. When a problem did occur you got a program dump this would be in Octal. First you would have to determine what routine and data areas was in memory at the time, then determine if the problem was in that routine, or data passed on from previous executed routines. Sometimes it was like finding a needle in a haystack. This was all in assembler, and you didn't have the debug tools you have today.   

 

Hmm, just 64kb RAM? I saw a DC-10 full flight simulator with PDP-11 computer if you see in this internet-page http://www.dc10.no/

So, it is possible... So, I thinking those have a lot of "hand-held calculators" in each of instruments, and some mechanical components. Therefore, it is might possible.

 

Any thoughts ?

[SouthPawPaul 11]

Years ago, (79ish) I had the very rare privilege of "flying" a full motion RAF Harrier Simulator out in Germany. That particular simulator was a projection screen that was displaying the image of a moving camera on a gantry that was "flying" over a physical model landscape. This model landscape was was enormous and was housed in a separate building next door. 

 

How the actual systems were controlled though I couldn't say. It was a heck of an experience though!

[qwseyvnd 0]

Hmm... That is interesting...

[qwseyvnd 0]

I investigated about 64KB limit, now I understood that 64KB for the 8-bit is not much. So, I'll find a 16-bit microcontroller.

[qwseyvnd 0]

I have one more question.

Is that possible to make a simulator of just electromechanical components ?

[qwseyvnd 0]

I have one more question.

Is that possible to make a simulator of just electromechanical components ?

No one knows ?