Project Linux MFD (Updated 120616)

Artlav

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,814
Reaction score
869
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
-You can't install Linux on DeltaGlider's computer.
Click to expand...

Aprom Designs, Department of Abnormality presents:
Linux MFD, a Linux "port" to Orbiter:
lmfd-110815.png


Download here:
orbides.org/orbf/linuxmfd-110815.zip (2.2 Mb)
https://orbides.org/orbf/linuxmfd-120616.zip (9 Mb)
Latest is 120616, info in post #38.

This is a completely random waste-an-evening-to-make geek toy - a Linux kernel running in an Orbiter MFD with some programs in it to interface with Orbiter.
Sources and patches included.

If anyone have any idea how this can be useful in any way (besides writing autopilots in bash scripts), you're welcome.

Manual:
Linux runs independent of the vessel and opennes of MFD, the MFD acts as a terminal.
The interfacing to the vessel is updated to reflect currently focused one.

Keys:
INP - input a line into console, with enter on end
SUS - save state, saved to boot/vmstate
RSM - resume saved state
RBT - reboot machine
UP,DWN - scroll up and down
FWD - scroll all the way down

Config:
boot directory contains boot.txt, where you can specify what to boot.

Programming:
The VM is MIPS32R1, little-endian, 32Mb of RAM.
IOMEM area 0xB4000000..0xB4010000 is interfaced with the plugin and can be used for Orbiter control.
initrd is cramfs, easy to make and read. Can be gzipped, can be ext2, etc.

Examples of interfacing are in /obin (in PATH), sources are in orbitersdk/samples/linuxmfd
myvessel - print vessel name
prograde, retrograde, killrot - toggle autopilots

Performance:
rate parameter in boot/boot.txt
If the Orbiter lags, reduce.
If the Linux lags, increase.
Must be power of 2 (reduce or increase by factors of 2)
If not, it will crawl slowly.
 
Last edited:
"In Soviet Russia, Linux runs on Orbiter" :rofl:

Just hilarious, Artlav. Great idea! :thumbup:
 
Last edited:
The Zen part of me wonders what happens if I manage to install WINE and run Orbiter inside the Linux MFD, and then activate Linux MFD inside that installation, well you guess the routine... :tiphat:
 
Wishbone said:
The Zen part of me wonders what happens if I manage to install WINE and run Orbiter inside the Linux MFD, and then activate Linux MFD inside that installation, well you guess the routine... :tiphat:
Click to expand...
Eventually you get a :hailprobe: MFD.


All :hailprobe: !
 
What about taking systems simulation to a new level - you don't just simulate a presence of a spacecraft control computer, you simulate an actual computer with actual software?

If you were making such a computer for real, why not use Linux on it?
True, it's not a real-time OS, but neither does Orbiter represent a real spacecraft.

That would basically mean a spacecraft control program running on it, with UI and all.

An UI that would represent an MFD...
A program that would do what a regular MFD would do...
Explosive-decompression-scale sucking of resources for externally indistinguishable tasks...

Impractical, but adds some serious you-know-you're-addicted-to-Orbiter points.
 
This depends. Can you plug back into the vessel from the Linux? For instance, a /dev/hovengineleft or so? Mount the devices in a specific pattern and allow scripts to control the component thusly... Might be more complex than it's worth, though.
 
Xyon said:
Can you plug back into the vessel from the Linux? For instance, a /dev/hovengineleft or so? Mount the devices in a specific pattern and allow scripts to control the component thusly... Might be more complex than it's worth, though.
Click to expand...
I've mapped a part of memory between linux and orbiter, and made it userspace-accessible.

The meaning of the mapped parts is defined on the side of orbiter plugin (sources provided) - in the demo it gives the current vessel name and have autopilot toggle bits. Under Linux the demo programs like myvessel, prograde, etc, read and write there to do their functions.
So, you can link whatever you want both ways.

Making it into device nodes only adds complexity at cost of adherence to standards.
 
Last edited:
Oh my God, its full of stars...
 
LOL, I do something similar on the Black Dart computers, but contrary to your MFD, you will never notice there that the core interfaces of the computer VM are POSIX. :lol:
 
1. Am against mapping everything to inodes.
2. There should be some visible feedback when the VM is suspended (three stars across the screen?)
3. When I call the command input box by Shift-I, the I gets input into the box (it is not eaten inside the callback function).
4. Will be looking for a gcc cross-compiler, but will be much obliged if someone has got a linky handy.
 
Next step: Orbuntu.
 
One quick question: Whats the resolution of an MFD? :lol:
 
Same as your screen, but this is all in text mode. Off-topic: The only thing I miss with Orbiter MFD's is the ability to show greek letters.
 
It can also be used, maybe, to provide some external communications - with a text browser that will identify as mobile, and something like a jabber protocol...
And implement the optional signal :shifty: lag-to-earth.
 
¿A gcc toolkit for .dll developing, or run Blender for meshing?.
 
You must log in or register to reply here.
Back
Top