• Please review our updated Terms and Rules here

VGA BIOS at other than C000 (E000!)

maxtherabbit

Veteran Member
Joined
Apr 23, 2019
Messages
2,153
Location
VA, USA
I have recently acquired a very interesting 486 motherboard based on the Zymos POACH chipset. That's right, the 286 chipset. It has a crapload of PALs and glue logic to handle the 32bit DRAM and cache, resulting in a full AT footprint.

The 1990 AMI BIOS (pre color BIOS) only offers 2 extra options specific to this configuration, cache on/off and whether to enable a 128kB shadow RAM region. When you enable the shadow RAM, it shadows the system BIOS in the F segment as usual, but also copies the contents of the C segment to the E segment, and executes the VGA BIOS at E000. The original ROMs remain accessible at their original addresses in the C segment.

Where it gets strange is when I get into DOS and examine the IVT. Int 10h points to an entry point in the E segment as expected, but ints 1Dh and 6Dh both still point to the C segment. I can only speculate that either some code in the ROM itself has hard coded values since the VGA card has no ability to change the ROM address, OR DOS is doing something which expects VGA at C000.

I wrote a tiny little device driver to change the IVT values for 1D and 6D to the E segment, which works fine and all video functions are still good. However, when I try to use EMM386 to "take over" C000-CBFF for UMB use, the system hangs. Could there be some other value I need to change?
 
If the original ROM remains accessible in the C segment, then telling EMM386 to use it as UMB would result in ... a read-only UMB?
You might be able to use the VBIOS in the C segment for video, and the shadow copy in the E segment for UMB.
 
If the original ROM remains accessible in the C segment, then telling EMM386 to use it as UMB would result in ... a read-only UMB?

EMM386 can be told to “include” areas that have ROM in them and it works, the paging registers handle redirecting access to that area to whatever region of Extended memory it’s using for the backfill pool. But, yeah, bad things will happen if you plop a UMB down on top of a ROM that’s actually being used.

(I have a VIA C3 box that I set up as if it were a ridiculously fast DOS-only 486 and I use EMM386 include statements to cover up a ton of ROM that has things like the legacy USB emulation, PXEboot, and BIOS self test and menus code. Otherwise the machine would only have about 24k of unoccupied UMBs. But of course doing that means I have to have anything that requires those ROMs disabled in the BIOS.)
 
Running QEMM's optimize process -- the full one, which prompts you to run a few programs in "observation mode" -- might be informative. It might show you that some of the ROM space should be left alone, and other parts can be overlaid with RAM.
 
Doesn't QEMM (and, actually, doing a Google it looks like EMM386 from DOS 6 and newer can do it too) have a ROM shadowing function built in? If the BIOS is doing it wrong (IE, trying to copy the VGA bios to the E-page and then said copy doesn't actually work) I wonder if it would be better to disable ROM shadowing in the BIOS and rely on the memory manager to do it.
 
Disabling BIOS ROM shadowing and using a memory manager is contrary to my objective. EMM386 will not even be used most of the time (boot menu). My true goal here is to rely on the built in shadowing feature and eliminate all vestiges of calls to physical ROM

I'd like to underscore that the BIOS shadowing does work, in a practical sense. Enabling it improves the BIOS video throughput measured in checkit by a factor of 10
 
Last edited:
... when you mentioned that the computer went pear-shaped when you tried to use C000-C800 as a UMB I guess I naturally assumed that your goal involved having upper memory blocks available.

If you have one around it might be an interesting experiment to try a different VGA card and see if it's more amenable to being relocated, it's possible this is an issue specific to the card you have. Outside of that... *shrug*? It's certainly an interesting idea to try copying the ROMs and executing them from another location, I was not aware that there were any motherboards that tried *relocating* ROMs instead of having the shadowed copy show up in the original space. Was that a common thing? C000 seems to be really set in stone as where VGA lives so it wouldn't surprise me if any given VGA bios took the shortcut to hard-code references to some data structure.(*)

(* But, really, I have no idea.)
 
Last edited:
Yeah I don't blame you for focusing on the UMB. I am interested in being able to use it with EMM386, but that is really a secondary goal. My main goal in starting this thread was to see if anyone knew a comprehensive list of DOS data structures that may reference VGA ROM code
 
There are no DOS data structures that reference VGA ROM code.

Built-in shadowing is almost always terrible. QEMM can shadow the C800 ROM in-place which means you don't have to re-vector anything.
 
There are no DOS data structures that reference VGA ROM code.
So if I've already edited the IVT, the only other thing that may be hanging me up is the ROM code itself.

Built-in shadowing is almost always terrible. QEMM can shadow the C800 ROM in-place which means you don't have to re-vector anything.
I understand that. Being able to run the processor in real mode is important to me
 
I understand that. Being able to run the processor in real mode is important to me

I guess the question that sort of comes up is if you want the CPU in unencumbered Real Mode and aren’t caring about upper memory, etc, does it really matter if the VGA bios shadowing is buggy and the computer still randomly bangs on the non-shadowed copy? I’m not sure what kind of application would really be hitting the BIOS hard enough to materially matter. It’ll affect benchmarks that measure bios/dos text writes, but don’t most performance-matters programs just tickle the hardware directly anyway?
 
No it doesn't matter that much, the system is fine as is. This is just an exercise in curiosity really
 
Thinking about disassembling the video ROM and system BIOS to see what's going on and maybe modify them. What disassembler y'all recommend?
 
Try the free version of IDA 5. After that recent thread about the PS/2 ROM dump, I've used that to disassemble bits of the Model 30-286's VGA BIOS code to answer some of my own questions.

It may interest you to know that the video stuff (INT 10h) lives in E000 on the non-MCA 286 PS/2s. So AMI's pick of that segment to shadow the video BIOS may not be totally random after all. :)
 
Back
Top