Running QNX2 on 2012 CPUs

we have been running QNX2 in the industrial equipment we sell for almost 25 years; our equipment uses old 386 and 486 SBCs. it is getting difficult to find 386 and 486 SBCs, so i asked why we were were still using them; i was told that QNX2 could not run on modern computers. QNX2 is a 286-based OS, and i have been running it in a QEMU VM for several years, so i didn’t believe it. I tried booting an Intel Core i7 laptop from a boot floppy, but i just got the spinning arrow for a while, after which the boot stopped; i was able to type 255 characters (i’m assuming), but CTRL-Z would not bring up the login prompt). i then tried a working bootable QNX2 HDD using a circa 2002 SBC, but got the same result. when a co-worker of mine heard that i was running QNX2 in a QEMU VM, he tried to get it to run in VMware, but the boot diskette image would not boot (he, too, got the spinning arrow, which stopped after a few times around).

it occurred to me that the QNX2 second-stage bootloader might have some kind of loop counter in it that faster CPUs finish too quickly. QEMU uses what Fabrice Bellard, the author of QEMU, calls “micro-operations” to be able to simulate many processors, and it may default to that mode for x86 OSs as well. VMware probably attempted to run native x86 code when my co-worker tried to boot QNX2, and the ca. 2002 SBC was definitely running “bare metal.” i haven’t yet had a chance to finish investigating this, but i was wondering if anybody else has encountered this issue (and if so, if they have been able to work around it).

I have a lot of background with this issue. A few details.

The original QNX 2 did a test at boot time to determine the speed of the processor. The value was stored a a 16 bit value, maximum of 0xffff. This value was used by the floppy driver. Somewhere around a 100Mhz 486 processor, this value wrapped around causing a problem reading the floppy drive. This does not occur during the primary boot or the secondary (partition) boot because both of these us the BIOS to read the floppy. You run into problems when the system tries to read the sys.init file. If you are booting off of a hard drive, the problem does not occur, however you cannot read or write a floppy disk.

The first solution to this problem came in the form of program called speed_control. After booting off the hard drive, speed_control was run in the sys.init. This would set the timing value to 0xffff. In order to install the system on the hard drive, one would need to slow the processor down. The fastest process I was able to do this with was a 300Mhz PII on a lap top. The BIOS allowed for the disabling of the processor cache. Note that after installation I was able to enable the cache, but at this speed even the value 0xffff was too slow for the floppy driver to work properly.

There is an additional known problem related to processor speed when using the QNX network. A race condition that occurred when breaking down virtual circuits occasionally left a dead circuit on one side. If this recurred enough, the entire virtual circuit table would be used up and no new circuits could be used. There were three ways to mitigate this.

  1. Write the application so it created virtual circuits once and keep them alive.
  2. Reboot when the table filled up
  3. Run a program to remove these dead circuits. QNX once supplied this program to me, but I was never able to get it to work.

Finally, I’ve had no problem running QNX 2 under VM using a Pentium IV and an i7 processor. On the PIV I was able to load my old data using a parallel port and a Zip drive. The i7 does not have a parallel port but I am able to use the image floppy to exchange data, although it is tedious.

It is quite possible that there are other speed related issues with modern processors. The speed of processors is now on almost two orders of magnitude faster than the ones that QNX 2 worked well on. The success using virtual machines does suggest otherwise.

It might be worth looking at the Vortex86, which I think is a 486.

On the other hand, the time invested getting QNX2 to run on current hardware might as well be invested into porting the QNX2 application to QNX6. Many features could be added.