Legacy ISA Hardware Pass-Through via Custom QEMU/KVM Proxy
This documentation outlines the complete engineering pipeline required to bridge a legacy CIO-DAS08 ISA Data Acquisition Card into a virtualized Windows 98 SE / MS-DOS environment running on a modern Linux host machine with MBATX-CS620-H310C motherboard from DFI. It details the underlying hardware mapping architecture, deployment strategies, and validation protocols.
This documentation is specifically for MBATX-CS620-H310C motherboard running Ubuntu v18.04.5.
1. Hardware Architecture & Electrical Blueprint Map
Modern motherboards lack physical ISA slots. To bridge this gap, the target host machine utilizes a PCIe-to-ISA hardware bridge adapter (e.g., using an ITE or Winbond bridge controller).
The bridge maps the legacy 10-bit ISA I/O space into the host’s modern PCIe I/O Base Address Register (BAR) window.
+-----------------------------------------------------------------------+
| WINDOWS 98 GUEST VM |
| Accesses legacy ISA Ports: 0x390 - 0x39F |
+------------------------------------+----------------------------------+
| (Intercepted by QEMU Memory Region)
v
+-----------------------------------------------------------------------+
| MIFE CUSTOM QEMU ISA PROXY |
| - Tracks memory region offset: addr (0 to 15) |
| - Dynamically calculates host port: 0x5390 + addr |
| - Executes raw hardware assembly: inb / outb |
+------------------------------------+----------------------------------+
| (Kernel space execution via iopl)
v
+-----------------------------------------------------------------------+
| UBUNTU LINUX HOST KERNEL |
| Directly routes outb/inb commands down the PCIe Bus BAR Window |
+------------------------------------+----------------------------------+
|
v
+-----------------------------------------------------------------------+
| PHYSICAL PCIe-TO-ISA BRIDGE |
| Translates Host Port 0x5390 directly into physical ISA Bus 0x390 |
+------------------------------------+----------------------------------+
|
v
+-----------------------------------------------------------------------+
| CIO-DAS08 PHYSICAL ISA CARD |
| Responds across 8-port register layout block |
+-----------------------------------------------------------------------+
Physical-to-Virtual Address Mapping Layout
- Guest Base Address:
0x390(Configured via the card’s physical DIP switches). This is the default setting on the CIO-DAS08 ISA card used by MIFE v1. If different, this is configurable in the MIFE Custom QEMU ISA Proxy. - Host Translation Base:
0x5390(Assigned by the host PCIe bus architecture). This is configurable in the MIFE Custom QEMU ISA Proxy. Make sure this address has not been taken by other devices on the host. - Address Space Window: 16 Bytes (
0x390to0x39F).
We patch a raw I/O listener directly into QEMU to intercept the Windows 98 guest’s legacy 0x390 port calls at the hypervisor level, execute them on the real physical host CPU at 0x5390, and pass the real data back.
2. Deployment
Step 2.1: Copy and Register the Binary on the Target Host
- Transfer the mife-qemu-system-x86_64 binary to the host machine.
- Store the binary in a distinct local directory to prevent accidental package manager overwrites:
sudo cp mife-qemu-system-x86_64 /usr/local/bin/mife-qemu-system-x86_64
sudo chmod +x /usr/local/bin/mife-qemu-system-x86_64
- Grant raw I/O privileges to the binary. Because standard users cannot execute raw hardware assembly inb/outb loops, grant the new binary raw I/O capabilities using Linux file traits:
sudo setcap cap_sys_rawio+ep /usr/local/bin/mife-qemu-system-x86_64
Step 2.2: Updating Your Domain XML Configuration within Libvirt (Virtual Machine Manager)
In QEMU, property assignments are added directly to the device call string separated by commas. Boolean options can be set using on/off or true/false. QEMU accepts both base-10 integers and traditional hexadecimal prefix formats (0x) for the ports.
Open your virtual machine XML configuration profile, scroll all the way to the top of your XML editor in Virtual Machine Manager. Look at the very first <domain> tag.
It usually looks like this:
<domain type='kvm'>
You must inject the QEMU XML namespace attribute into this tag so Libvirt knows how to read custom command-line blocks. Change it to exactly this:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
At the <devices> section, and look for the <emulator> tag near the top of that section. By default, it will look like this:
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
Replace that path with the absolute path to your custom-compiled binary:
<devices>
<emulator>/usr/local/bin/mife-qemu-system-x86_64</emulator>
Scroll all the way to the very bottom of the XML file. Insert your custom command-line arguments right above the closing </domain> tag. You can adjust the debug/host-port/guest-port as appropriate:
<qemu:commandline>
<qemu:arg value='-device'/>
<qemu:arg value='mife-host-isa-proxy,host-port=0x5390,guest-port=0x390,debug=off,log_sample_rate=400'/>
<qemu:arg value='-rtc'/>
<qemu:arg value='base=localtime,clock=host,driftfix=slew'/>
</qemu:commandline>
</domain>
You can adjust the host-port/guest-port/debug/log_sample_rate as appropriate. It’s recommended to ONLY set debug to ON when confirming ports mapping. When turn on debug, it will have performance impact with data acquisition.
3. Verification & Testing Protocol
To ensure full bi-directional pass-through behavior without loading external driver payloads, use the vintage native MS-DOS debug environment.
Step 3.1: Host Side Live Log Monitoring
Before issuing commands inside the guest machine, establish a live trace interface on the Ubuntu Host to bypass systemd tracking blocks: (only do this step if debug option is ON in the VM config XML file for the proxy)
sudo tail -f /var/log/libvirt/qemu/<your VM name>.log
Step 3.2: Executing MS-DOS Debug Sweeps
Boot the Windows 98 guest environment into an MS-DOS prompt window. Initialize the low-level utility tool:
C:\> debug
CRITICAL SYNTAX NOTE: Vintage versions of
debug.exeparse spaces strictly. Separate the target I/O port address and data byte payload using a comma (o port,data).
Execute an sequential sweeping check of the card’s assigned registers:
-i 390
-i 391
-i 392
-i 394
-i 396
-i 397
Step 3.3: Interpreting the Diagnostics Data Profile
If the architecture pipeline is fully intact, the hardware registers will match the factory profile shown below:
-i 390 --> Returns 00 (ADC Low Byte: Expected idle condition state)
-i 391 --> Returns 00 (ADC High Byte: Expected idle condition state)
-i 392 --> Returns 77 (Status Flag: Binary 01110111, indicating steady digital inputs)
-i 394 --> Returns FD (Intel 8254 Counter 0: Live fluctuating value proving clock ticks)
-i 396 --> Returns 00 (Intel 8254 Counter 2: Stable, unassigned background counter clock)
-i 397 --> Returns FF (8254 Control Register: Write-only register; reading forces open-bus floating)
Step 3.4: Verifying Complete Hardware Write Execution
To verify full outbound control pathing to the physical card, attempt to cycle the internal Multiplexer (MUX) configuration lines:
-o 392,00 <-- Sets MUX targeting Analog Channel 0
-i 392 <-- Read status line results back
-o 392,07 <-- Sets MUX targeting Analog Channel 7
-i 392 <-- Confirm changes register on the board hardware
Your host log output will capture every single execution step simultaneously, verifying that your software logic and hardware connection are fully operational.