Ancient PC Hardware (apparently) - aka I Need a 386 for Work

[evilspoons]

So I've got a job at work now to restore to working condition a 1992-era motion-controlled machine, hooked to a PC to feed in parameters. Unfortunately, the 386 SX 16 running it seems to have died of old age after sitting in storage for two years.

The 386's been replaced by the owners of the machine with an Athlon 64 4200+ with Windows XP, and the DOS program originally compiled in Turbo C actually still runs. However, it doesn't actually function properly. It's supposed to send serial commands (ASCII text commands) out on COM1 at 9600 bps and receive replies, then interpret the replies into helpful status messages and the like. It's sending the commands because I can read them in on my laptop by hooking it up via a null modem cable, and the commands are valid because I can type them by hand from my laptop into the machine and it sends values back.

The program is the same one as in 1995, the machine is the same as it was in 1995, so the only obvious change is the PC. I tried booting the new machine on the old computer's DOS boot disk, but that didn't fly for whatever reason. I created a new boot disk out of something derived from Windows 98 (DOS 7.x?) and the machine booted and ran the program, but it just failed to work in a slightly different way (incorrect values returned instead of no values returned).

So I spent all morning phoning around town (Edmonton, AB) hoping someone would have a 386 I could buy off them. No dice. Don't really want to go the eBay route because fast shipping will cost too much and nearly everything with appropriate hardware specs is being billed as "vintage" now and being sold for hundreds of dollars(!). Am I really that old? I'm only 26! This is the stuff I played with as a kid!

Any thoughts?

 

[PottedMeat]

(incorrect values returned instead of no values returned)

what do you mean by this? are you getting values and they make sense but are incorrect? or are you getting gibberish?

maybe try a dos 6.22 or win95 bootdisk? did you check the BIOS for serial port settings?

you should be able to get a junk 386/486/pentium to work with this sort of thing if you cant get the software to work.

 

[evilspoons]

It's hard to tell - the machine says it's homed when booted off the disk and it shows '...' (no value) when it's run through Windows. All I know is that (1) it's not actually homed and (2) the homing process is communicated to the PC application via a variable. (Something to the effect of 'STATUS=3').

The only serial port settings in the Athlon 64 PC's BIOS are the memory address, which is set to 3F8 (meaning COM1).

Unfortunately the oldest computer I've been able to source so far is a K6-2 500 or a Pentium II of unknown speed. I'm not really sure they're old enough to justify screwing around with.

 

[Ken g6]

Can you clone the disk of the old 386 machine? If so, run that disk in a VM with access to the COM1 serial port.

If not, find some dos 6.22/win95 disks and try installing everything in a VM.

Edit: I'm thinking QEMU with -serial /dev/ttyS0 Edit2: On Linux, that is.

 

[MagnusTheBrewer]

Many of the problems with running old dos programs stem from the software using the system clock for inputs and outputs. The solution for using a more modern processor that runs at higher speeds is to slow down or throttle the clock speed.

http://www.oldskool.org/pc/throttle
This is just one possibility.

 

[DaveSimmons]

DOSBox has commands for controlling the speed too.

The problem might also be COM port settings, using the wrong number of bits or parity type.

 

[greenhawk]

worst problem I have at work when dealing with older hardware/serial coms is the line signals / voltage levels. Most newer gear generates the negitive voltages as needed, so it can be rather weak. That is assuming it is not the USB style and is more +/- 5 Volts were as older hardware went to +/- 15Volts (and powered some of the receiving hardware).

All valid RS-232 communications, but the different voltage levels can cause issues with older hardware.

When we got new laptops a few years ago, we went through nearly a dozen different usb-serial adaptors to get ones that worked with our hardware. Though we still have a 486 based industrial PC we carry around as needed for the problem devices.

OP, if your laptop is working with comunications, have you tried running the software from it? (and not just individual commands)

 

[Mark R]

worst problem I have at work when dealing with older hardware/serial coms is the line signals / voltage levels. Most newer gear generates the negitive voltages as needed, so it can be rather weak. That is assuming it is not the USB style and is more +/- 5 Volts were as older hardware went to +/- 15Volts (and powered some of the receiving hardware).

This could well be the problem.
Serial ports are meant to be -12 V for a "0" and +12 V for a "1". However, increasingly, modern equipment is abandoning this high-voltage signalling and going for low-voltage 0 V for a "0" and 5V for a "1".

Technically, they should still be outputting the correct, or nearly correct, voltages - but it's quite possible that the manufacturers have cheaped out, and just gone for a 5V output, instead of 24 V.

The problem is that almost all modern equipment will treat the 0-5 V signals as valid, and correctly interpret them. However, old equipment may not recognise them as a valid signal.

If you have an oscilloscope to hand, it might be worth checking whether the serial port voltages are sufficiently high.

 

[evilspoons]

I have already attempted DOSBox, but it didn't work out since the HMI software requires a hardware authentication dongle on the parallel port. DOSBox has no parallel port support, as far as I can tell.

This is the same reason I haven't tried out the software on my laptop - no parallel port.

It's probably not the serial voltage levels (although that is a very interesting piece of information I'll have to remember) because I am able to use the new terminal software - the same that I was using on my laptop - on the new Athlon 64 HMI machine to issue commands manually, and I receive the same replies as when on my laptop.

I tried to use the "Slowdown v2.00" program to launch the HMI app while both in Windows XP and on the DOS boot disk, and the program did indeed slow down, but the behaviour didn't seem to change.

 

[yinan]

Try it in a VMware workstation VM. It supports parallel and serial pass through.

 

[Ken g6]

Try it in a VMware workstation VM. It supports parallel and serial pass through.

So does QEMU. Plus, since QEMU emulates in software rather than hardware, it's easier to throttle if necessary.

 

[mfenn]

So does QEMU. Plus, since QEMU emulates in software rather than hardware, it's easier to throttle if necessary.

I think that you meant, "since QEMU emulates in software rather than hardware, it's self-throttling."

I guess that my "helpful" advice is just to pay the couple hundred for a 386. I'm betting that the machine that it is interfacing with is worth far more than that!

Nitpicky tangent: the difference between what QEMU and classic VMWare does isn't the difference between software and hardware, as both are software. It's the difference between emulation and virtualization.

 

[Paperdoc]

Not the same hardware etc, nor application, but maybe my experience with a retail Point-of-Sale system can shed some light. The root of the problem I had to solve is that Win XP and later (and maybe a few earlier) takes complete control of the Parallel and Serial ports of the mobo. It completely blocks attempts by app software to manipulate those ports directly.

We run a retail store opened in 1993. Point of Sale (and many other) functions are done by a software package we bought at that time and ran on a 486-based machine under DOS 6.22 originally, and later Win 3.1. Later updated to Win 98. The software was originally written mostly in optimized machine code 'way back when people spent time to do that stuff, and it is a very well-behaved DOS app. I have run it successfully under DOS 6.1, DOS 6.22, Win 3.1, Win 98 (original and SE), and now Win XP. But the Win XP part is where my problem surfaced.

The cash receipt printer is a Star SP300 (3" wide paper roll, dot matrix print head) on an RS-232 Serial port. The software has a setup menu to choose which printer you are using and on what port, and it apparently writes directly to the port. It also reads limited info back, since it can detect printer malfunctions. In 1999 we updated to the latest version of that software in prep for Y2K, and got the last version of it that was still an update of the DOS software. (The company already had a new Windows version of the software coming onto the market.) All worked just fine until I had to replace the computer in 2007 - it had only been working nonstop for 14 years! - and in the new one I installed Win XP Home Edition. Appeared to work just fine, except that it could not print anything! Tech Support at the software supplier quickly recognized the issue: the DOS software was writing directly to the COM port, but Win XP intercepts that and does not pass it on. Their solution was not too difficult. One uses NETUSE commands to re-direct an app's output to a printer to another printer port. This is Network Redirection. I just put the NETUSE commands into the beginning of the little DOS batch file that is used to start up the app in a DOS box. But there were three tricks to getting it working.

1. You cannot re-direct app output sent to a COM port to the COM port. I had to set the software by lying to it and telling it the printer was a Star SP300 on the LPT1 (Parallel) port, then having the NETUSE command trap all traffic for the LPT1 port and redirect it to the COM1 port.
2. Note that I made use of easily-available menu settings in the software to have it print to the LPT1 port. I don't know if that is possible in OP's case.
3. This only works because NETUSE can re-direct traffic on a computer that is part of a network. But there is no network in our retail store! The Tech Support guys pointed me to the rest of the puzzle's solution. For a very long time all Windows installations have included a file used for testing network functions in a stand-alone machine. It is executed during start-up of the computer by putting it into an autoexec file or something, and it creates a virtual network by running a virtual stack. All traffic sent by apps and Windows out on this virtual network connection are handled and returned just as if there really is a network connection, and Windows is blissfully happy. So our old DOS software prints to the LPT1 port, Win XP intercepts it and re-directs it to a different network resource, the COM1 port, and it all works. Data returned by the printer on the COM1 port does get fed back to the app properly.

Right now I can't remember the specific file that does the network simulation. In fact, if the computer already DOES have a network connection, the simulator is not needed. (That's another option I did not pursue - connect the computer's network port to a router that is powered up and does nothing, configure the network connection, and Win XP "sees" an existing network.) But if this interests you, let me know. I can go look closely into the little batch files that run this on our store's computer and copy them for you.

 

[dbcooper1]

If it is a timing loop causing the problem, you might be able to disable the cache on the CPU from the BIOS; that will slow it down to 386 speeds or close to it. I believe the only cache from that era was on the board itself.

 

[piasabird]

I wonder if there is some program or interface you can use to create using a modern computer and run it in a 16 bit compatability mode. I remember we use to put a second collection of dos commands in a folder and then make a shortcut that tells the program to start in a specific folder so it looks in that folder for the system commands first.

I know this is possible because we use to use a PIII server with emulation software to run our IBM MAINFRAME operating system. It is like taking a computer and then you have some firmware that tells your older operating system how to talk to your newer hardware. Maybe look for emulation software.

http://www.buyc**********/us/result.jsp?ga=us3&q=386+motherboards

 

[Knavish]

Depending on how big the program is, could you re-write the software in something like Python and use a modern computer? Serial I/O is pretty easy stuff.

If there are no software people around to rewrite the program, vendors still sell many embedded / industrial computers that are DOS compatible. (Perhaps a PC104 system would work.) These might cost ~$500 to $1000 with all the necessary peripherals, though.

One example that claims DOS compatibility:

They look somewhat complicated, but you buy a cable set to adapt all the pin headers to your standard keyboard, com, vga, etc...

If you go this route, just be sure the salesman you talk to gives you a step-by-step procedure for getting DOS operating on the system. This board at 500Mhz might still have a clock speed issue, too.

EDIT...

This might be an even better idea. It looks like this guy (http://blog.smartelectronics.ca/?p=42) got an eBox-2300 to load DOS onto its compact flash disk via a bootable USB installer. The eBox is a cute little x86 CPU that runs at 100s of MHz, but some models do not have a floating point unit. (They're equivalent to a 386sx or a 486sx...lol).

http://www.compactpc.com.tw/ebox-2300SX.htm

Also, eBox systems start around $100.

 

[BadThad]

Obvious question, but what are your port settings, i.e. baud rate, etc?

I've dealt with similar issues at work and I'm about to hit another one next week....running on COM port to an old laboratory instument under Win7....fun stuff. LOL

 

[evilspoons]

Thanks for all the information, everyone.

I had a 386 SX/25 lined up from a supplier in the States but the customer started whining about money and decided not to continue with my help. I would have liked to see this old machine up and running, but what're you gonna do, haha.

Paperdoc: that's actually really interesting. If I run into any DOS compatibility crap again I'll have to keep all that in mind.

Knavish: a rewrite was actually on the table as the next step. The controller I'm talking to has an ethernet interface with much more modern communications libraries. I'd whip up something shiny in VB2010 with WPF graphics and a touchscreen. The eBox looks fun to play around with too. My rebuild would've had an industrial PC with no moving parts that comes from a similar train of though, just with a bit more processing power (low voltage Core 2 Duos right now, probably moving to i3s soon.)

BadThad: port settings were hardcoded in the app I was trying to use. All I remember right now is that it was 9600 baud, but I have the rest of the settings somewhere because I can successfully connect with a terminal... just not the HMI application with hardcoded settings.