* dBase/Clipper/CLARION/Paradox/other DOS RAD environments on period hardware to run business processes?
* CNC mills/spectrometers/microscopes/other industrial instruments controlled by ISA cards (either bespoke or standards like GPIB)?
* Anything with a parallel port dongle?
If so, I'd be very interested in hearing your experience here, or feel free to send me an email at the address in my profile. I'm not trying to sell anything, just doing some research for an idea around keeping these going on modern hardware.
The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control.
The original software was written back in the 80's, when the plant was originally commissioned, for AmigaOS. Of course, it's hard to buy Amigas anymore, and the original one died long ago (nobody remembers when).
So in the mid '90s, the utility purchased an AmigaOS emulator that ran on Windows NT 4.0, which was current at the time. The emulator (IIRC) was developed by a firm in the UK. The firm went out of business sometime in the late '90s. The control rod monitoring software ran under this emulator on top of NT4.
Windows NT 4.0 was the last OS to allow the emulation software direct access to the physical hardware that produced the status signal. Later versions of Windows abstracted the hardware access away, and the monitoring software broke. Because the emulation company had gone belly up, there was no way to fix the incompatibility.
So the utility had a choice: get new hardware/software certified (by NRC?), or keep doing what they were doing with the software (and hardware) that they had. They chose the latter.
So this is how, in 2007, during a tour of the facility, I stumbled across a Pentium 1 system running an AmigaOS emulator on Windows NT 4.0 that was responsible for displaying the status of the control rods of a nuclear power plant.
Spare hardware for this setup was purchased off of eBay and stocked on an adjacent shelf.
Thats far more advanced than the systems I worked with, one of which reported rod position via resistance measurement on a brushed cylinder (one for angular and one for depth).
Cleaning and calibrating those was a constant maintenance item every time the reactor was shut down.
Then their ancient Honeywell(?) mainframes reached end-of-life they scouted for compatible hardware, of which there was none. The cost of certifying new software, plus the time involved, was astronomical. So, after consulting with the FAA, they paid a hardware company to clone the ancient mainframes in modern silicon. The FAA signed off on it, and they had all-new computers - much smaller than the originals - running the old stack.
I am interested in how firmware is treated, since perhaps in the case of these old machines it's small enough to be analyzable or at least cloned bit-for-bit.
(Probably not literally true. But functionally true in the sense that they were likely transmitted via infected floppy disks, of which there'd be virtually none left in the wild in 2007)
I completely get the decisions over time here, but it's unsettling having a relevant piece of software (reports are important too!) working on with parts from ebay, in 50 years time they might be gone.
That's to say nothing about opinions of open source that rival early 2000s Microsoft.
For old ass critical software and hardware, the org can always have a backlog of hardware and contingency plans (paying someone to fix the hardware, paying someone to create a fully certified and modern solution..) for when they start running out of parts.
lol. I know a ... factory, that had a BBC model B (with a rather complicated wiring loom) still doing a job around that time.
The IT supplier at the same factory went to a museum in Cambs. around late '90s, early '00s to ask if they could buy an exhibit because something had failed locally. The museum gave them the part.
That was just aerospace and nothing fancy like your nuke plant!
Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://web.archive.org/web/20231114211656/http://www.gareth...>
(Heck, recently I migrated a VM to its third hypervisor. It began as a physical machine a quarter century ago.)
We've already got it running on modern hardware. It's running under qemu. And the dBase stuff gets ripped out and sent to a REST server for broad monitoring and so on.
We... Have one small oddity? There's a tape backup system, that throws everything through the soundcard. (Sound Blaster only.)
Would be nice if onboarders didn't see dBase and just throw everything at AI instead of actually learning the skills they'll need when data migrations happen. But that's a people problem that can't be solved with tech.
I have a client with some business software that runs on DOS. They have a dozen seats. A single Linux server gives serves a dozen VNC sessions with the software running in DOSEMU. Printing is done with the Linux print stack and three Ethernet print servers.
It has been working without a hitch since 2008. Oh, so has the server, which is a VirtualBox VM.
In 30 years time it will all be outdated... But emulators will exist and a business process in 2050 that still depended on something I built today could still run with minimal effort or risk.
The Field PG has also another special port called "MPI/Profibus" for S7 PLCs, 2 Ethernet ports and a DVD drive.
https://support.industry.siemens.com/cs/document/109766662/d...
Edit: There is no required hardware, however maintaining a stable serial connection through a VM and timing issues due to faster hardware has been fun.
To give you an idea of the complexity of the manufacturing lines, shutting the machines down and starting them back up again was measured in days. Upgrading them would be obscenely expensive, let alone replacing them, just in the opportunity cost of not making anything alone.
I'm pretty sure they moved on from them, but a while ago I did seasonal work for a company that rented out scanners for year end inventory (tax related, IIRC). The scanners had to be "cooked" (flashed) on racks, boxed, and sent. The flashing usually worked, but on occasion, the scanner would fail the checksum or something and drop you into a DOS prompt.
Your use of “when” is interesting - suggests it’s not that occasional. Wonder what people are doing with these nowadays.
I suspect he could have found a way to use a newer computer, but if it ain’t broke…
The cost of upgrading to modern software and hardware is substantial, plus the learning curve for something I only do rarely nowadays.
It was a test/repair bench for military aircraft avionics, with the only flying platform left using it being the legacy F/A-18 (A/B/C/D). Harris H-100 minicomputer hooked to an HP terminal and several full racks of GPIB test equipment with half of a rack of solenoids for switching between stimulus and response and which pin.
Not what you asked, but the question brought back memories.
Keeping old hardware running is very fragile. Most spare parts are decades old now too, and nobody knows if they still work properly.
The DMA might actually be the easy part.
The main concern is how many VM exits per second a modern CPU can handle. Even though the interface is "slow", you can probably do ~500k to 1 million IN/OUTs or MOVs per second to ISA. You'd have to trap (VM exit) every access to a IO port or memory within the ISA window.
During the pandemic I cobbled together a KVM-accelerated emulator for an old 386EX based board I had and trapping every memory access to IO was slower than the real hardware.
ISA motherboards still work and have been mass produced in the hundreds of millions. (I have about a dozen in my retro closet.)
The esoteric ISA expansion cards would be the bottleneck, not the motherboards.
https://www.reddit.com/r/vintagecomputing/comments/jbaw38/is... (2020)
ISA-over-USB, using real ISA cards in an emulator
https://github.com/Manawyrm/ISASTM/
The company I worked at in the late nineties, used Managing Your Money (MYM) for bookkeeping - initially on a dedicated DOS machine. My colleague set up a DOSEMU-based emulator and moved the software to it (bye-bye, dedicated DOS machine!). Later, he re-wrote it in STk (Scheme w/ Tk bindings, running natively in Linux) as ageneral-purpose transaction storage. ¯\_(ツ)_/¯
My opinion is that if these guys are still running this gear, they already have a strategy in place (no matter how flawed) and would likely retire before throwing money at something they consider a non problem.
Good luck with the idea. It likely is a tiny niche market with customisation for every customer and given they are normally hardware constrained AI may not be much of a help.
All of them have no money as well.
The BASIC code is very simple by modern standards, and Tcl overlaps BASIC neatly, making conversion easy.
Unfortunately it's just a short-term stopgap to add some features management suddenly can't live without, that weren't practical to implement in BASIC/DOS. They'll replace the whole stack with a commercial product and support contract when they find something they like.
Most of the stuff I've moved over to run in DOSbox but it's still in use occasionally for the software that's difficult to port over.
In other words, these are embedded systems.
In a world that requires security audits etc here's some notes that might help:
Scenarios: You have a device that only talks NetBIOS or even NetBEUI for file sharing. You need to get files to and from it and your CAD workstations run Windows 11 and anything less than SMB 3, with signing and sealing and all that jazz is laughable.
... Devices requiring ftp, telnet, serial over carrier pidgeon
Solution options:
Networking: The first job is to segregate your industrial gear from your general network and you might want to create two or more industrial gear and internet of things type networks with differing access policies. Start with one for now, you can improve it later.
You use 801.1Q VLANS logically or physically (why the hell did I want to write literally?) separate via separate switches.
Please do not skimp on this step. Buy a network bod to sort it out or put your IT bod on a course or hopefully they will have labbed this up at home already!
Comms: Samba is bloody wonderful and speaks everything that MS has ever done and deprecated. Even Samba does need to be asked to start speaking some of those dialects again but it will.
Put a Linux (other Unices are available) box on the same VLAN as your machines. You will need to set quite a few options relating to the minimum version for its server version. When talking to the machines, Samba is the server and when talking to your file server, Samba is the client.
Create a data share on a Windows box on the corp LAN. For example it might be on a file server for multiple access or just a single CAD PC.
Get the Samba box to mount that share to itself at say /srv/data_share_mc1
Now get the Samba box to create a share from /srv/data_share_mc1 which it calls DAT_MC1 (8.3 chars for NetBIOS)
With luck, you should be able to map DAT_MC1 on your machine.
If it goes down, the company gets fined. It happened in the gap between my predecessor leaving, and me being hired.
Fortunately, I don't have to deal with swapping parts. There's an outside contractor on call 24/7 for that.
The last time I saw it was about two years ago when I taped yet another piece of paper to the filing cabinet it sits on reading "DO NOT TURN OFF UNDER PENALTY OF LAW!"
Someone keeps taking the paper down.
These were for some industrial CNC machines with a poorly version-controlled app (send us the single-file .c for the program, we'll make changes & recompile for you, then send back a new .c and .exe file) that would just malloc() all the memory on the machine for a million element array instead of tracking the 1k or so unit IDs a more efficient way. They were six digits long, it worked... mostly.
I kept a 3.5 floppy with the contents of sys a: that I used to run sys c: after restoring a machine from backup in my office.
EDIT: oh, and of course by "restoring from backup" I mean reversing the xcopy to copy everything from the network drive's copy back to C:
EDIT2: My memory is going, they didn't use malloc() at all, anywhere in the programs, they just had a static million element array.
The box running the QEMU emulators had a bunch of old US Robotics modems hanging off it via USB serial dongles.
https://news.ycombinator.com/item?id=46849567