Page 1 of 1

DOS Program Driving ISA Slot Board Directly

PostPosted: 10. Apr 2021, 02:17
by CAnderson
Am sitting on an OLD piece of code designed to communicate with a custom ISA slot card on a DOS platform. Program is controlled by a second computer over RS-232. Was written in some flavor of *.asm for which I no longer have assembler tools, or likely a machine that would run them! So need to try to get this DOS app running on Windows.

Computer is toast, and customer prefers that we provide a Windows machine with Telnet or similar to operate this program. Telnet is no problem. VirtualBox handles that nicely by just coupling up the Guest's COM1 with port 23 of the host computer. All good there. However, it's the issue of the same DOS program talking straight to the ISA card that has me concerned.

IIRC, Windows long ago (long before XP) virtualized all hardware, and that it is not possible for the DOS program to talk directly to the ISA card within VirtualBox on a Windows XP (last to support ISA) machine. Is this correct? It's been so many years since I've dealt with this kind of issue that I am in a complete fog about solutions. There is no 'Windows driver' for this DOS app -- this is the first time it will ever have been run on a Windows platform.

Re: DOS Program Driving ISA Slot Board Directly

PostPosted: 10. Apr 2021, 10:14
by mpack
Sorry, as far as I know there's no way to do that ISA stuff in VirtualBox, which didn't even exist when ISA was current. For a while VirtualBox had an experimental feature for PCI redirection, but that's PCI, not ISA, and in any case it only ever worked on Linux hosts - and few got it working even there.

The plain truth is that trying to hook physical hardware directly to a virtual machine is a bad bad idea. Fundamentally that's because physical hardware cares about precise timing, and a VM doesn't. Solutions to mate the two just don't work well.

Btw, assembler tools from the era are still easily available, and all modern decendants of the x86 can still run it. DOS still has a bit of a hobby following, probably more so than early Windows.

Frankly, I think you're going to have to keep going with physical DOS. Possibly the FreeDOS project would allow you to move a little bit into the future, maybe even run on modern hardware (that still has an ISA slot??) but this is just a guess: I have never tried to install FreeDOS on physical hardware.

[Edit] Re my "ISA slot??" query (meaning I wondered if any modern boards still had 90s era ISA slots), out of curiosity I just did a search and they do exist, serving industrial markets. I think typically these days you'd buy an ISA backplane with at least two slots, then into that backplane you'd plug your single board computer and your special board.

p.s. What does this special card do? ISTM the best long term solution would be to port the function onto modern hardware with code written in C, assuming the function isn't available off the shelf. I'll bet you that a TeensyLC or similar development board could do this work in its sleep, providing a USB interface to a host computer.

Re: DOS Program Driving ISA Slot Board Directly

PostPosted: 11. Apr 2021, 04:38
by CAnderson
Indeed, you can not only buy motherboards with ISA slots, you can get entire built boxes (incl. rack mount) with them. They build them for just the reason you discovered -- replacements for legacy equipment that operates with proprietary custom control cards in ISA slots. Sometimes, the original company goes out of business. Sometimes, the card was never updated to PCI. Sometimes replacing the ISA card with a newer version (e.g., PCIe) is very expensive (see, for example, WinRadio equipment!) Sometimes a lot of stuff, but people need to keep them running. Some of the replacement cards run upwards of $4,000. In this case, there's no replacement at all!

In this particular instance, the card drives a servo chassis to move a LIDAR scanner, with a DOS program driving the ISA card. The ISA card in turn drives the servo motor driver chassis which in turn drives the motors while watching over the encoders. The ISA card uses an old Galil 1200 servo chip for the servo action. The computer (and hence, the scanner) is controlled remotely over an RS-232 link via proprietary API.

The replacement option (what is currently supplied with new LIDAR scanners) is an entirely new chassis driven over Ethernet by a PC running a Windows app, but the replacement cost for the chassis is quite expensive, and more problematic, the lead time is substantial vs. a PC-only solution.

If it comes down to it, I can buy a brand new ISA capable box with DOS 6.22 loaded, and then stick a Pearle or StarTech or Moxa in front of the serial port to provide TCP remote control of the system rather than RS-232. That's easier than farting around with loading TCP drivers with some kind of 232 redirect software (the app looks only at COM1). Cheaper and quicker to get one of those aforementioned hardware solutions.

Re: DOS Program Driving ISA Slot Board Directly

PostPosted: 11. Apr 2021, 04:50
by CAnderson
I should point out that the timing of the commands over the API aren't super critical. The serious timing based upon those commands is handled by the ISA card itself.

Looking at VirtualBox, it's already capable of handling a number of the more common devices, including high speed serial and things like Telnet links, at much faster speeds than the commands need to be received from the remote computer. The timing isn't as critical because the real workload isn't in the app. The app, for the most part, just passes along commands to the ISA card which it in turn executes in whatever fashion it's been preprogrammed to do. I don't even know if IRQ is being used, or whether the code just polls the card for responses. Perhaps I'll get time to look more closely at the code and card this next week.

Re: DOS Program Driving ISA Slot Board Directly

PostPosted: 11. Apr 2021, 09:58
by mpack
In none of the cases you mention does VirtualBox handle the hardware directly. The host OS does that, per the normal rules for type 2 hypervisors. All VirtualBox is doing is being a VM, i.e. translating what the guest is doing into calls to the host OS. And it only does even that for standard hardware types, and it can't handle any hardware class that the host OS isn't managing.

E.g. "high speed serial" means that VirtualBox asks the host OS to open a COM port and return a handle. The "hardware" seen by the guest OS is entirely simulated and has nothing to do with any actual hardware of the host. VirtualBox can just as easily let the guest see a UART when the actual hardware is a pipe that connects one VM to another, or to a host app.

As I mentioned before, the only instance in which VirtualBox ever allowed a VM direct access to hardware was that PCI redirection feature that never worked properly.

Re: DOS Program Driving ISA Slot Board Directly

PostPosted: 11. Apr 2021, 15:03
by CAnderson
Understood. Unlike DOSBox, there's no source for VirtualBox that could be modified to allow for talking to an OS / Driver to manage this particular problem, performing a function similar to the one you describe for COM support. Would much prefer to have gone the VirtualBox route. At this point, just fishing for alternatives.

Thanks for the confirmation.

Re: DOS Program Driving ISA Slot Board Directly

PostPosted: 11. Apr 2021, 17:17
by mpack
CAnderson wrote:Unlike DOSBox, there's no source for VirtualBox that could be modified to allow for talking to an OS / Driver

I'm not sure what you're saying there. VirtualBox is open source. While you could be interpreted as saying that VirtualBox has no source code module which is close to what you would need, that is true - but it will be even more true of DOSBox.

DOSBox is a simulator, I believe, not a hypervisor. I.e. the CPU is emulated, which incidentally allows easy hardware I/O mapping, and the OS is emulated too: it responds to all the int 21h and BIOS calls, but it isn't actually DOS. I'm not sure to what extent is simulates hardware. I'm a big fan of DOSBox for running generic DOS programs, it's a good way to keep old 16bit code running in 64bit Windows - but you'd never get your special widget running in DOSBox.

As I said earlier, I believe that a physical DOS PC is your only option.