Smart computing into MS-DOS? Is it possible?

Question

The building I work in has an MS-DOS computer that runs the building's air system. My boss has asked me to make it so that he can use smart devices to make adjustments remotely.

How much would need to go into a solution for this? Is it possible? I assume I would either need to emulate the program on a more advanced computer or use some other more modern device to interact with the MS-DOS system.

The computer is wired directly to the air system. In case it matters, it is a Dell Precision 386DX/33.

I'm a software developer, but a wet-behind-the-ears one, so I'll understand technical responses despite being out of my depth.

Answer 1

You said "The computer is wired directly to the air system". I'm not sure exactly what this means, but I'd infer there is a cable between the PC and the air system, and that cable is most likely connecting RS-232 (or similar) serial ports on the two devices. I think the best starting point would be try to understand THAT interface as fully as possible. I'd begin with the reference manual for the air system that describes how it is remotely controlled by another device, most likely via its serial interface port. Adjust accordingly if it is some other type of port/interface/connection, but RS-232 serial is the usual common denominator for such systems, I think.

Armed with this knowledge, you can start to evaluate whether it is simpler to continue using the old PC, or replace it with a newer computer that will allow you to implement a new control application that just replicates the interface talking to the air system. In other words, you are deciding whether to continue interfacing to the air system through the old PC and its app, or bypass that altogether with a new app that can communicate with the air system. Theoretically, the old PC could be replaced with an IP-to-RS-232 interface, and the new app could actually run on the "smart device" tablet/phone/whatever. It would just send commands to the air system over the network, in that case.

Oh, and don't forget to build in some security too.

Answer 2

Caveat: I have a hard time to consider this an RC question, as it's as well about actual software development as it is about actual hardware and an actual job. Just because the target involves some 386 doesn't mean any retro knowledge is needed or a retro task at hand. Serial or network interfaces are still common technology, aren't they?

---

First of all, as usual with this thing, you may want to define the ways that system can take/deliver information - in other words what are the measures to acquire data from and send commands to this machine?

Do you have access to the source?

No? Then it may get time for hacking.

Are there any documented command interfaces (serial, Keyboard, Sensors)?

No? That may need even more hacking and quite some prayers.

Without further knowledge about the whole system in question - that is the total hardware (not just some base PC) as well as the software - it's at best guessing what can be done. Typical scenarios may be:

1. If the application has interfaces for remote control (into the PC) use them - hopefully they are documented, otherwise add a few weeks of night shifts (*1).

2. If not, does it at least accept keyboard commands and display information? If yes, writing a TSR capturing video data and inserting keyboard input on request from an external system (like via serial) might be a way ... hacking here we come.

3. If neither, maybe the PC is just controlling an embedded system to make it more versatile (nowadays called 'intelligent') - then your task could be replacing the PC with some newer machine offering the connections you need. Depending on the 'intelligence' of the application this might be anything but easy.

If everything fails, call someone who has done it before ... and ask you boss for a real budget first.

---

Bottom line, it depends on what system that is (again, system, not just the PC model), what you want to do, what is supported thereof and most of all, what's your budget.

---

*1 - Don't forget to account for all of them when you want to get paid. Good documentation might be helpful, as this is the typical task of 'hey, coudn't you make X work with Y' where the person requesting it will be totally baffled that you worked a month or two on a simple 'make the heating go lower' Button.

Answer 3

Step 0: Ask the people who set it up whether they know how the DOS program talks to the system.

Step 0.5: Check whether this system is going to be replaced within the next 5 years; the "proper" way is probably not worth the effort if it is.

If that's not possible, the way I'd deal with this system is as follows:

The "proper" way

1. Set up some sort of data logger in between the DOS machine and the system it's connected to. This will vary by connector; it's probably RS-232 but it might not be.

2. Have a play around to gather some data about the protocol they're using to communicate. Try turning the fan up and down, or heating and cooling the temperature sensor on the cooling system.

   Carry a camera around with you while you do this, and keep it pointed at whatever you're interacting with. Make sure the camera's saving the time that it's recording the video. That'll make it a lot easier to work out what action correlates to what signal.

3. Unhook the data logger and read the data from it.
4. Line the data up with the video.
5. Inspect the data.
   • Is there a frequent "I'm still here" signal?
   • What is the default state of the pins?
   • What voltage does it communicate with? This might be different for different pins.
6. Try to isolate a meaning to specific signals. You might need to do another few rounds of testing (see Step 1) to make absolutely sure you've got it right; getting it wrong can trash the equipment.
7. Write a basic script on a [hardware protocol]-compatible device that sends a signal to the system. Does it work?
8. See if you can get output from the system. Perhaps the DOS program was sending a "give me your stats" message to the system, or perhaps it is wired directly into the resistors.
   • If I really couldn't understand what was going on, I'd watch the DOS program running, then pause and play back execution so I could see what it was doing. Step-by-step debugging is not really possible when communicating with a non-emulated device that is not designed for said debugging.
9. Now that you have a basic idea of the protocol, implement what you know and abstract it away. Create a RESTful API or similar on top of it. Make this code as simple as you deem reasonable.
10. Get other things to talk to this.
11. When you need to get that one bit working that you hadn't quite figured out, see Step 1.

The hackish way

1. Emulate the system on a newer device.
2. Get a hardware connection working.
3. Put together a system to stream the display to other devices and accept input from them (modified Shell in a Box might work if it's an in-terminal emulator; tinyVNC might work if it's graphical).
4. ???
5. Profit.

Answer 4

It all really depends on how the device operates the system.

Others here are telling you to tap the interface, and try to emulate it.

As another approach, take a look at the at the program that is used to control the device.

The trick here is instead of decoding some protocol between the computer and the device, instead, tap in to the computer to drive the program that drives the device.

A potential tact for this is to install a TSR (Terminate and Stay Resident). The TSR does several things.

One, it intercepts the keyboard interrupts within DOS, and is thus able to "send commands" to the program. If "turning the fan on" entails going through a couple of menu options, then you can simply mimic the keyboard strokes necessary to navigate the menus, select the fan, and "turn it on".

For example, say if you hit ESC 5 time from anywhere, you get back to the main menu. Then, to get to the fan controller, you go to "Menu 2" which brings up a form listing the fans. You want "Fan 2", and when you arrow down, and hit enter, you get to a form that has a "Fan Status" box with a "ON" "OFF" toggle, which you can TAB to and then hit F2 (yes, I'm making this all up).

So, send it ESC-ESC-ESC-ESC-ESC (gets to main menu from anywhere), 2 (Menu 2), Arrow Down (Fan 2), ENTER (fan screen), TAB (to the field) F2 (toggle).

Two, it can monitor the screen that's shown by the program and then "screen scrape" it to deliver output to your controller.

Third, it can install a serial interrupt handler (assuming one is available) that can be used by you to send and receive commands from your controller to the PC.

If the serial port is unavailable, the printer port might be open -- you can use that too.

You may also be able to install an Network card and a TCP stack (or NetBios, to something else).

If it's running a version of Windows (pretty much any version), it can be even easier as you can tap in to the event stream for the program, and simply send it messages -- mouse clicks, keyboard events, etc. Screen scraping is a little more difficult, but you can even read the values of controls (like text boxes and labels) on the Windows forms from a separate program. Reading the temperature from a bar chart graph is left as an exercise for the reader.

Your controller can be something like a Raspberry Pi, with Wifi. It can present a simple web interface, and interact with the PC via the Serial port and the TSR. The DOS machine will, likely, "never know what hit it" or even know you're there.

All that said, "it's a hack" to be sure. But possible. It may or may not consume a bunch of time, lots of unknowns.