I got Microsoft LanMan to run under Desqview-X using a very poorly documented TSR bridge to TCP-IP driver that has to be installed before running Desqview. Taken me three weeks of research in ancient document archives to figure this out. Once this was running, I got the X-Windows server working under Desqview-X, which can service up to 6 thin client X-Terminals while Desqview-X is running the real-time I2C sensor monitor I wrote in Turbo C++ 3.0 and started inside Desqview-X. Once this was all running, I was able to boot an NCD Explora device and run DOS programs inside the X-Terminals over TCP-IP to the Explora devices!
I had to remove the IPX and NetBEUI protocols from MS Lanman to free up enough memory to run DesqView-X and just barely skimmed in with about 394K free when entering the Desqview-X loading screen.
I then stood back and looked at a very bizarre spectacle that I may well be the first man on Earth to have had running in about twenty years ... a real-time multitasking multiuser thin client X-Server running on top of DOS servicing NCD Explora thin client boxes with DOS text mode based applications all at the same time. This is a rock solid setup according to old Navy documents on various workstations they built back in the late 80's, able to run for years unattended without breaking down or crashing.
The NCD Explora is rated at a MTBF of 400,000 hours, roughly 39 years of continuous usage before the average box malfunctions in any way. The military hardened Pentium that I installed the server on is rated for 100,000 hours minimum before anything starts to fail.
Wait, there's more.
Inside of DESQview-X, I was able to browse folders on the Windows 2000 server, send mailbox messages (and therefore participate in MSQ Messaging) and exchange TCP-IP packets with the W2000 while the Desqview-X server was running. Turning the Windows OS system on and off (the higher layer in Vault-OS) had absolutely no effect on the Desqview-X system!
Only been working on something like this for about 8 years solid. Third week of February 2011, proof of concept is functional and seems to work as designed.
- A lower layer that never turns off in the shelter. (Runs forever)
- A higher layer that can exist or not exist, depending on whether humans have entered the shelter and require a more sophisticated front end.
It's very, very robust. Very solid. It doesn't take much to get this lower layer running and keep it running on any x86 machine in the world. Compared to the higher layer, maintenance and upkeep of this system is trivial. It probably sounds complicated but the truth is it is unbelievably simple compared to configuring anything in Windows or Linux. You get it running even once, it's going to keep running for you forever without human oversight. Possible a system like this could still be chugging along in 2100 A.D. or thereabouts assuming something keeps the power on all that time.
Incidentally, the Pentium running Desqview-X is on 12 volts, 900 ma draw not counting the display screen, the NCD Explora is running on 12 volts, 750 ma not counting display device. Very, very, very modest power draw. Both devices can be configured for power hibernation steps, including going to sleep and turning off the displays. The NCD Explora can be set up for Wake-On-Lan if desired or just left off altogether until needed.
5 comments:
And what about the solar flares? Won't one cause damage like you said it would do to PS3?
I'd like to try your system on an old 386sx sitting around here. I've got a couple of relay cards that I soldered up back in the 90's, when I tried to use Visual Basic to control them. But I couldn't activate or control the UART serial port through assembler (not nearly enough expertise) just trying to self-teach from the Norton Assembly Language book.
Desqview-X will run comfortably on a 386SX with 4 MB of RAM as a real-time multitasking monitor and a thin client server. If there is anything out there similar for free that is better than that I'd like to know about it.
Are you still planning on using the Netduio as the primary Sentry ?
How much power does it draw just idling or doing an infinite loop ?
I'm trying to figure how this differs significantly from the 8 million other Arduino versions and the only main thing I can come up with is the event based programming which is great, but can you list the particular technical advantages you see with the Netduino over the Arduinos ?
Just building my sensor system now.
Thx
kochevnik
I was giving some thought to maintainability and I think the Netduino is best put to use as a VOS-Talk enabled remote terminal for things like weather station, fuel or water depo, remote clusters. I decided I have to focus on the x86 architecture in order to assure replacements are plentiful and ubiquitous afterwards. No matter what happens, you will be able to find an x86 device. You might not be able to find another NetDuino if it is damaged/broken/fails. If I start leveraging maintenance between Netduino and x86 devices, that's two types of replacements to find in the post-apocalyptic environment. This is also the reason I deprecated the graphic interface to the sensors in DOS. You might not be able to find a video driver right for a certain machine but you will always have access to the text interface mode for any VGA-EGA-CGA compatible x86 device.
Post a Comment