Home windows 3.x VDDVGA | OS/2 Museum
Whereas engaged on my Windows 3.x display driver, I ran right into a vexing drawback. In Home windows 3.1 operating in Enhanced 386 mode, I might begin a DOS session and swap it to a window. However an try and set a mode within the DOS window (e.g. MODE CO80) would destroy the Home windows desktop, stopping additional drawing from occurring correctly. It was potential to get well through the use of Alt+Enter to change the DOS window to full display screen once more after which returning to the desktop, however clearly that wasn’t going to chop it.
Oddly sufficient, this drawback didn’t exist in Home windows 3.0. And in reality it additionally didn’t exist in Home windows 3.1 if I used the Home windows 3.0 suitable VDDVGA30.386 VxD shipped with Home windows 3.1 (plus the corresponding VGA30.3GR grabber).
There was clearly some distinction between the VGA VDD (Digital Show Driver) in Home windows 3.0 and three.1. The draw back of the VDD is that its operation just isn’t significantly properly defined within the Home windows DDK documentation. The upside is that the supply code of VDDVGA.386 (plus a number of different VDD variants) was shipped with the Home windows 3.1 DDK.
First I attempted to seek out out what was even occurring. Evaluating unhealthy/good VGA register state, I quickly sufficient found that the sequencer registers contents modified, switching from chained to planar mode. This is able to not matter if the driving force used the linear framebuffer to entry video reminiscence, however for good causes it makes use of banking and accesses video reminiscence by the A0000h aperture.
However how might that even occur? The VDD is supposed to virtualize VGA registers and never let DOS purposes contact the actual {hardware}. One thing needed to be very mistaken.
I additionally suspected that the issue was doubtless attributable to my driver doing one thing mistaken, or maybe not doing one thing essential to accurately arrange the VDD. The Video 7 pattern driver that I based mostly my code on was meant to work with its personal customized VDD, not with VDDVGA; judging from the supply code within the Home windows 3.1 DDK, I believe that V7VDD.386 was successfully forked from the Home windows 3.0 VGAVDD and at most barely up to date for Home windows 3.1. Which may additionally clarify why my driver labored with VDDVGA30.386 however not with the newer VDDVGA for Home windows 3.1 (VDDVGA.386 is generally constructed into WIN386.EXE and doesn’t exist as a separate file, though a standalone VDDVGA.386 can be utilized).
After poking by the VDDVGA supply code for some time, I spotted that it nearly actually wasn’t register entry from a DOS session leaking by. It was the VDD itself!
And I additionally discovered that the lacking hyperlink was a small part of code that was defined as “Name VDD to specify latch deal with” within the Home windows 3.1 VGA driver. It’s protected-mode service entry level 0Ch in VGAVDD, and it’s known as VDDsetaddresses within the VGA show driver (VGA.ASM) however DspDrvr_Addresses within the VDD (VMDAVGA.INC).
The Home windows 3.1 DDK doesn’t seem to doc the DspDrvr_Addresses operate. Though as a result of inconsistent naming, it’s tough to be fully sure.
On the similar time, I attempted to method the issue from a distinct angle. The Home windows 3.1 DDK does doc a set of INT 2Fh calls, a few of them with promising descriptions, similar to “Save Video Register State (Interrupt 2Fh Perform 4005h)” and the corresponding “Restore Video Register State (Interrupt 2Fh Perform 4006h)”.
However there I hit the other drawback. Regardless that the DDK paperwork these features, and the VGA show driver implements 4005h/4006h callbacks, I couldn’t discover any code within the VDD calling these features! And the debugger confirmed no signal that anybody else is asking them, both.
Word: It’s potential that the save/restore registers INT 2Fh callbacks have been specified for OS/2. Certainly the OS/2 2.1 DDK defines INT2F_SYSSAVEREGS (0x4005) and INT2F_SYSRESTOREREGS (0x4006) within the digital video gadget driver supply code… however once more there isn’t any signal of these getting used within the code.
There’s additionally “Allow VM-Assisted Save/Restore (Interrupt 2Fh Perform 4000h)” and “Disable VM-Assisted Save/Restore (Interrupt 2Fh Perform 4007h)”. The VGA and Video 7 name these features and identify them STOP_IO_TRAP and START_IO_TRAP. And VGAVDD.386 actually implements these in VDD_Int_2F (the INT 2Fh intercept in VGAVDD.386). Curiously, STOP_IO_TRAP corresponds to “VM is aware of restore the display screen” logic, and START_IO_TRAP naturally corresponds to “VM doesn’t know restore the display screen”.
However how does that make any sense? Why would the {hardware} entry from the Home windows show driver ever be trapped?
Why Oh Why?
Though I couldn’t discover any clarification within the DDK documentation, ultimately I spotted what the explanation needed to be: Home windows/386 (aka Win386).
Home windows/386 was basically an add-on for Home windows 2.x, including the flexibility to pre-emptively multitask DOS periods. Solely, within the Home windows 2.x days, Home windows itself was successfully a type of DOS periods.
That’s, Home windows 2.x show drivers had (nearly) no clue about Win386. That solely got here with Home windows 3.0. Due to this fact the Win386 VDD needed to handle Home windows itself as simply one other DOS session, save and restore all EGA/VGA registers, and in addition handle video reminiscence contents. In reality within the “regular” Home windows 2.x Adaptation Information, there’s nearly no point out of Win386 (there was a separate growth equipment for Win386 which coated digital gadget drivers).
I/O trapping was particularly necessary on EGA adapters which didn’t have readable registers. As a consequence, it was unimaginable to learn the present EGA {hardware} state; the one approach was to shadow the state of EGA registers as they have been written.
Home windows 2.x show drivers did implement one fascinating piece of performance, switching Home windows to/from the background. This was in no way meant for Win386 however moderately for OS/2 (that’s, OS/2 1.x, at the least initially). The switching was applied within the show driver by hooking INT 2Fh and looking ahead to focus swap notifications.
In Home windows 3.0, Enhanced 386 mode applied the beforehand OS/2-only INT 2Fh callbacks that indicated switching out of and again to the Home windows desktop. On the way in which out, the show driver might restore some form of sane VGA state, and on the way in which again to the desktop it might re-establish the required {hardware} register state. As well as, the show driver might drive a redraw of the whole display screen, which prevented the necessity to save any video reminiscence (which was good, as a result of the video reminiscence may very well be comparatively massive).
Sadly I don’t have the Home windows 3.0 DDK (and nobody else appears to, both) so I can’t have a look at the three.0 VDDVGA supply code. However it’s clear that whereas Home windows 2.x show drivers knew little or no about Win386, Home windows 3.0 drivers usually have some degree of cooperation with the VDD by the INT 2Fh interface.
Home windows 3.1 VDDs
In Home windows 3.1, Microsoft added an entire new degree of complexity to VDDs. Particularly, video reminiscence could be paged. Microsoft article KB80901 states the next:
In Home windows model 3.1, the usual digital show gadget (VDD) for VGA is modified to demand web page video reminiscence. Thus, you may run graphical MS-DOS-based purposes in a window or within the background on VGA methods. This VDD should observe video reminiscence utilization, so it isn’t suitable with any of the tremendous VGA show drivers that should entry greater than 256 kilobytes (Okay) of video reminiscence. To run these show drivers, a consumer should use both the VDD supplied by the show adapter producer or the VDDVGA30.386, which is included with Home windows model 3.1. Demand paging of video reminiscence could break TSRs that labored with Home windows model 3.0. The distinction is that the VDD virtualizes entry to video reminiscence; in Home windows model 3.0, the show driver had full reign over reminiscence.
I’m not fully sure why Microsoft did that. It appears so as to add plenty of complexity in return for not rather a lot.
The Home windows 3.1 VDDVGA.386 launched a brand new idea of ‘CRTC VM’ and ‘MemC VM’, that’s, the VM that owns the graphics card’s CRT controller (what’s displayed on the display screen) and the VM that owns the graphics card’s reminiscence controller, i.e. what’s learn from and written to video reminiscence.
Within the typical case, the CRTC VM can also be the MemC VM; that may be the Home windows desktop (aka System VM) or a full-screen DOS field. Issues get fascinating for windowed DOS packing containers. The desktop stays the CRTC proprietor as a result of the desktop is what must be displayed. However a DOS field can quickly change into a MemC VM, instantly accessing video reminiscence.
Evidently, this will get fairly difficult. VDDVGA.386 wants to avoid wasting the previous MemC VM state, merge the brand new MemC VM state with it and replace the {hardware} registers, let the DOS field execute, after which restore the unique MemC VM state earlier than the System VM can do any drawing to the Home windows desktop.
So far as I can inform, of the drivers shipped with Home windows 3.1 solely VDDVGA.386 has this complexity. Not one of the different VDDs, together with the Video 7 particular V7VDD.386, implement this logic. As talked about above, I strongly suspect that the Video 7 VDD within the Home windows 3.1 DDK (supply code in VDDV7VGA listing) is definitely very near the Home windows 3.0 VDDVGA.386, and thus to the Home windows 3.1 VDDVGA30.386.
It’s a Tie
Evidently, the register saving/restoring logic in VDDVGA.386 is kind of fiddly and tough to debug. In the long run I’ve not been capable of finding out why register modifications “leak by” to the System VM (i.e. Home windows desktop). I came upon the place within the code that occurs, however not why, or forestall it.
What I did discover is that the DspDrvr_Addresses operate does in no way do what the feedback counsel. The operate is supposedly used “to specify latch deal with” in video reminiscence. Nearer examination of the Home windows 3.1 VGA show driver confirmed that whereas it does outline a byte for the latches, and sends its deal with to the VDD, the show driver does nothing with that byte.
However much more fascinating is that VDDVGA.386 doesn’t use the latch byte both. As an alternative, VDDVGA.386 assumes that the latch byte lives someplace very near the tip of the video reminiscence utilized by the show driver, and expects that any following pages can be utilized by the VDD. (That logic doubtless comes from the Home windows 2.x EGA/VGA drivers.)
A corollary is that passing 0FFFFh because the latch byte deal with to the VDD (one thing that SVGA256.DRV does) tells VDDVGA.386 that there isn’t any video reminiscence to share. In that state of affairs, VDDVGA.386 doesn’t strive any hair-raising schemes to change the VGA register state behind the show driver’s again.
It’s not good both. The system does survive MODE CO80 in a windowed DOS field with out bother, however beginning (in a window) a DOS software which makes use of a number of pages of video reminiscence triggers an fascinating warning:
The warning seems to be innocent. As soon as it’s dismissed, the appliance works high quality. The warning additionally solely pops up the primary time the appliance is began (in the identical windowed DOS field). It’s not preferrred, however it’s one thing I can stay with.
I think about this preventing VDDVGA.386 to a draw. I’m not impressed with the Home windows 3.1 DDK documentation—it omits sure issues whereas documenting different issues that seem like fictional. That stated, the precise DDK supply code saves the day, at the least within the video space, as a result of it’s potential to see kind of the entire code concerned.
And the Home windows 3.0 DDK could be very nice to have.