VRAM corruption when background / windowed VM pagefaults (aka "Green line" file sharing bug)

[cml37]

First of all, wow, amazing project!

So, one issue I thought I would log is that it seems that the driver has the same issue that the "SVGA Patch" variant has: on startup, with file sharing enabled in Windows for Workgroups 3.11, green lines appear at the top of the screen. You can see what I mean in the video clip here: https://x.com/RetroTechChris/status/1875631757942517959/video/2

[PluMGMK]

First of all, wow, amazing project!

Thank you! 😄

So, one issue I thought I would log is that it seems that the driver has the same issue that the "SVGA Patch" variant has: on startup, with file sharing enabled in Windows for Workgroups 3.11, green lines appear at the top of the screen. You can see what I mean in the video clip here: https://x.com/RetroTechChris/status/1875631757942517959/video/2

I see, thanks for the report! That's interesting that it affects both drivers the same way... I'll see if I can get WfW up and running on something to try and reproduce!

[cml37]

Awesome! By the way, getting a lot of views on X. I did two threads today.... one has over 8000 views!! This is a popular topic.

[PluMGMK]

I still haven't had a chance to get a WfW VM up and running with working network support… Does this still happen on the latest version? With all the changes to VDDVBE since this came up, maybe this has already been accidentally solved…

[cml37]

Hey there! No worries on that, I am happy to try this out anytime you like

Just tried v0.2.8 and yea, sadly, still have the "green lines" distortion.

[PluMGMK]

OK, thanks! I'll see if I can spin it up in VBox this week to reproduce, and hopefully figure out what's causing this…

[PluMGMK]

Memory corruption is occurring directly in VRAM, not in any buffers controlled by VBESVGA.DRV – note that the contents of VRAM (middle dump) don't match either the back (first dump) or front buffer (third dump):

Shouldn't be too hard to figure out when / where that's getting modified 🤞

[PluMGMK]

This happens when a DOS VM running in the background (or windowed) pagefaults in text mode and the VDD needs to allocate a new save page for it. For some reason, it "restores" the offending page into physical memory before reading it back into the newly-allocated save page. Since the save page doesn't exist, "restoration" involves filling the physical page with words 0x720, which in text mode are blank character slots.

Since a new VM only seems to get one page by default, any access to pages B9000h - BF000h triggers a fault like this, which can be seen in non-WfW Windows by opening a windowed DOS VM and using debug to dump memory in this range (e.g. d b900:0).

In the case of WfW with file sharing, the OS apparently creates a background VM to act as a file server, which carries out a mode switch on initialization, causing most BIOSes to access the entire range B8000h - BFFFFh, triggering the offenting pagefaults.

Basically, I think an overhaul of the pagefault logic (or at least this specific part of it) is needed here…

[cml37]

Fantastic! I might try and build this.. or will be lazy and look for the next binary release :)

[PluMGMK]

Some of that code was written when I was tired and had been fighting with the computer for about three hours, so maybe I should clean it up a bit before doing another binary 😆

Also, even though the green lines are gone, you still get a little white dot near the end of where they used to be. This is because the VDD requires four bytes (one per plane) of VRAM for saving / restoring the VGA latches. Ideally it should be off-screen VRAM, but currently it has to be within the first 64k. Moving it out of the first 64k would require a bigger overhaul of the VDD. Maybe I'll create a new issue to track that, but it'll probably be lower priority…

[cml37]

Haha, totally get that! I did build it and test it out, looks great! https://threadreaderapp.com/thread/1890621520302531045.html