e820 map: Do not reserve VGA frame buffer #95
Conversation
|
Sorgelig modified this intentionally almost 2 years ago. There must have been a specific reason. |
|
Ah. Hopefully with Sorgelig’s input we can gain some understanding around this change and hopefully find something which satisfies both. |
|
unfortunately i don't remember why i modified it. Too much time passed already. Does Win95/98 still work after these changes? Amount of RAM is the same? |
|
I'm getting closer to understanding why this change has an effect. It appears to be the very first line which is important. In the current version it's reserving 0x0009f000 until 0x000d0000, whereas the Bochs version stops at 0x000a0000. Well, 0x000a0000 just so happens to be where the VGA frame buffer is. It looks like what's happening is NT is respecting that this memory is reserved and therefore can't talk to video at all. I haven't noticed any differences to the amount of reported memory. I'm going to do a couple more things and get back to you:
|
|
Probably it's related to linear frame buffer in some VGA mode. But not sure already. This is completely cleared from my memory :) |
|
what max resolution/color you get on WinNT with these fixes? |
|
Built-in Tseng ET4000 drivers do not work and so I've currently only got it usable in 640*480 in 16-color mode. I'm getting closer to getting a community VBE driver working now that I understand the memory map a little better (the driver has a registry key to set the base address). That driver is currently giving me high resolutions with high colors, but most of the screen is cut-off. It looks to me like the driver isn't trying to use a linear framebuffer but is expecting bank-switching (even though it says linear buffer is supported). More to come on this. |
|
You SHOULD use bank switching mode for correct work. Linear mode is very specific to implementation. |
|
Oh interesting. Well the driver is supposed to take care of selecting the right mode anyway, but it may only support linear mode for VBE 1.x devices. This might indicate that this driver isn't suitable. |
|
I'm testing a version which changes only the first line and leaves everything else unmodified. So far looking good. Will update the PR if no issues. Windows 3.1: Working |
Revert all values but one to mister-main
alexoughton
changed the title
|
Windows 98: Working This PR has been updated to only change this single value, and the title has been updated accordingly. |
(changes from upstream commit 6aeddc3)
|
after merging i finally realized reserve was for shared folder driver! This PR will break shared folder driver... |
|
I've removed this commit, sorry.. It will totally break shared folder. |
|
OK, I'll experiment with that and get back to you. However I haven't had any problems using MisterFS with my updated BIOS. |
|
It's coincidence. misterfs writes and reads in that region, so if it's not reserved then some app (or even OS) may place its data/code and it will be corrupted sooner or later. |
|
Understood, thanks! |
|
Updated version raised as #97 |
This is a solution for running Windows NT 4 on ao486, with full instructions here: https://misterfpga.org/viewtopic.php?p=44432#p44432
After solving "inaccessible boot device" messages in NT setup (with third-party drivers), I found that there were then errors initializing video (even just for text mode setup). I found that the same error occurs when using the ao486 BIOS with Bochs, but that the currently-released Bochs BIOS does not have this problem.
I compared the current state of the Bochs upstream BIOS source code with that of ao486, and found that this change to the e820 map is the critical difference. I performed basic testing and did not find any detrimental effect on DOS, Windows 3.1 or Linux. However I do not have any specific knowledge of e820 to fully understand the change. I have only taken the working values from the upstream source and applied them here.