This library contains functions to emulate a real-mode 80x86 processor.
This is accomplished in one of two ways, the opcodes are either
interpreted, executed in virtual mode (Neutrino ONLY) or executed
in real-mode (QNX 4 only).
With the interpreter, a.k.a. Emu86, all opcodes are interpreted and all
memory may be virtual, parts of the “real-mode” machine are overlayed into
the emulator’s memory space. This approach has allowed QNX to maintain
compatibility with the changing video card markets by using the video card
vendor’s video BIOS supplied with the video card instead of hard-coding
modeswitching code for every new video card. Although the primary
purpose of this is to interpret calls to int10h, many other
applications are possible.
*** Definitions
Emu86 - The part of VBIOS that interprets 80x86 opcodes and performs
the operations on a virtualized memory space
VM86 - The part of VBIOS that uses either virtual mode under Neutrino or
real-mode under QNX4
From ModeSwitcher.doc
Document Title: Building a Video Mode Switcher
Author : David Rempel and Pete Patterson
Filename : ModeSwitcher.doc
Location : MSToolkit/docs/
Date : October 25 1997
Building a Video Mode Switcher
------------------------------
1 Introduction
This document covers the purpose of a QNX Video Mode Switcher (referred
to as QVMS or Mode Switcher from now on) in the QNX/Photon or Neutrino/Photon
environment, and how to go about making one for a specific video card.
It also gives a rundown of the libraries included in the Mode Switcher
Toolkit (MSTK) to help with the various commonalities of QVMS writing.
This all sounds vaguely familiar. It used to be the case that a video card would come with a bios that had a call to change it’s mode. The manufacturer could provide any hardware specific code needed without providing a driver.
The problem with this way of doing things came about when OS’s started using protected mode. The code in the bios was real mode. I think this issue went away with the VESA standard. Just about every video card these days can be controlled as a VESA video card. This “default” driver typically doesn’t perform very well, but it works.
So what I’m saying is that unless you are using a very old system with old hardware, I don’t know why you would need to mode-switch the graphics with the toolkit you are describing.
Thx for the valuable input - good to know.
Our original developer who brought us to QNX is gone, and any other developers are also gone - so no one left here really knows how this all works.
Our existing devekopment system is quite old and is not getting backed up.
It has no writtable CD, no USB ports, a single drive that’s 97% full.
This is our only QNX station.
I’m pursuing a few avenues to better protect this station, including recursive FTP to an NTFS share (Windows network) and bootable Ghost to capture the drive image.
A thrid option is to recreate the environment onto newer station hardware (with CDRW, USB, 2nd HD, plenty of HD space) - and so the source of my question.
Upgrading the QNX OS is not an option at this time.
Thanks for asking. Any good ideas out there are welcome!
I’m not familiar with the first item “sector duplication”. Is that using the ‘dd’ command? if so - can’t do it on the QNX machine - not enough drive space.
If not, is there info in one of the documents? I’ve downloaded them all I think.
Hmmm - hadn’t thought of virtualizing the system. Don’t use that much here. I’ll look into it. The only device access I need it to write to a CF card.
Right!?! Saw that 97% and kicked this up the priority list! I’m trying to NOT touch the original system - at least until I have a backup I have 100% confidence in. And that’s sorta what I’m trying to do - but the whole system.