DOS ain't dead

I remember back in the days of American Megatrend, and Awarf BIOSes, there was often an option to "shadow" the video BIOS into low memory in DOS, to greatly speed up vBIOS routines and calls in DOS.

Now, we are in an age of SOC chips and "Intel Graphics" onboard video embedded in all modern core i3/i5/i7 systems. As a technical point, is it possible to "shadow" the ~60 to 64kb "VGA video BIOS" ROM code portion of such onboard Intel graphics which contains the relevant 16-bit DOS video routines into low DOS memory, so that the code may be modified and corrected of the many bugs and limitations which have occurred in the DOS VBIOS portion of the Intel Graphics chipsets (such as UHD 620, Intel HD 5500-series, etc)? After 2020, Intel sadly removed *all* legacy BIOS support, and this also included all 16-bit DOS VBIOS code.

DOS programs such as DEBUG are capable of finding and dumping the video BIOS code in DOS.

Does the fact the "integrated" graphics on the Intel core i are already "on the chip" mean that the concept of "shadowing" the BIOS in fast RAM is obsolete?

I'm sure there were some DOS utilities from 30+ years ago on Simtel and other sites which could do this "shadow" RAM trick with video BIOSes. However, none of those allowed you to *modify* the code which was shadowed into RAM, nor were there any built-in optimizations.

Scitech did this "optimizing" VGA and VESA support 25 years ago. I'm wondering, for example, if one could "replace" the onboard vBIOS of one Intel Graphics (eg, UHD 620) with another (eg, Intel HD5500 series) which *does* correct some of the bugs introduced with Onboard UHD 620 Graphics (VBE 2.0 errors / black screen at 640x480 and above, lack of 320x240 Mode 13, etc).

Any suggestions, pointers or advice on to "shadow" modern Intel vBIOSes into lower RAM, for modification?

> Scitech did this "optimizing" VGA and VESA support 25 years ago. I'm
> wondering, for example, if one could "replace" the onboard vBIOS of one
> Intel Graphics (eg, UHD 620) with another (eg, Intel HD5500 series) which
> *does* correct some of the bugs introduced with Onboard UHD 620 Graphics
> (VBE 2.0 errors / black screen at 640x480 and above, lack of 320x240 Mode
> 13, etc).
>
> Any suggestions, pointers or advice on to "shadow" modern Intel vBIOSes
> into lower RAM, for modification?

a more reasonable approach would be to write a TSR that intercepts INT 10h, implements the faulty functions, and bounces everything else to the original INT 10 handler.

>> Any suggestions, pointers or advice on to "shadow" modern Intel vBIOSes
>> into lower RAM, for modification?
>
> a more reasonable approach would be to write a TSR that intercepts INT 10h,
> implements the faulty functions, and bounces everything else to the
> original INT 10 handler.

Tom's suggestion is the only one that will really work. The purpose of Shadow RAM is to make things faster (RAM is faster than ROM). Shadow RAM also needs to be integrated and enabled in the hardware, and once the ROM has been copied into RAM you can't (or at least shouldn't) mess with it. You can't use "regular" RAM as Shadow RAM. E.g., if some parts of Shadow RAM are not enabled and used as Shadow RAM, the UMBPCI program can turn at least some of the unused Shadow RAM into "usable" RAM.

Your problem does not appear to be speed (which is the main purpose of Shadow RAM), but the fact that the ROM code is "broken" and doesn't work right. You're going to need to write a TSR (or Device Driver) to fix the problem areas as Tom suggested. You could also install an external video card and bypass/disable the Intel graphics.

> You could also install an external video
> card and bypass/disable the Intel graphics.
Yes, this will work on a Desktop system, but not so much in a laptop, where the intel onboard graphics drivers share system RAM and are the only option.

In regards to Intel (and by extension, Microsoft) completely disabling / removing legacy BIOS on all systems after 2020, I believe there are still some UEFI BIOses which allow a "Compatibiliy Support Module" (CSM) Option .ROM to be loaded / added which could be contained on a standalone video card manufactured after 2020. This is somehow sideloaded into the Desktop system's UEFI-only bios to allow legacy booting to DOS or other 16-bit system, because now the CSM module does have the necessary 16-bit code for VGA and INT calls.

Your suggestion about intercepting INT10 calls via a TSR is a great one. I'll have to get to work tinkering. I know others are interesting in "bare-metal" DOS support on modern systems as well. I very much dislike having to use imperfect, cumbersome, slow emulators like DosBox, which is trying to re-invent a wheel which already exists in these "modern" Intel systems, with speed and memory to burn. Legacy does work, just imperfectly because of borked onboard video drivers. Another problem, as discussed multiple times before, is getting a generic audio compatibility working with onboard "modern" audio on the SoC on such systems (Intel High Definition audio, etc).

Direct modification of any BIOS is possible. You can use the UMBPCI driver (source code available by email upon request) to temporarily unprotect the memory, modify the BIOS, and return the memory protection to the state it was before. Plus, it's reversible and you don't need to flash the BIOS. This way you can load your fonts into the video BIOS and you don't need any additional drivers to load them because when you change the video mode, the BIOS will load them automatically.

Try load this UMBCPI.SYS driver with param /C to copy font to BIOS.

https://megawrzuta.pl/download/db4914cf6fc38deeb3af2bca1b0ee8fc.html

> This way you can load your fonts into the video BIOS and you don't need any
> additional drivers to load them because when you change the video mode, the
> BIOS will load them automatically.

What Zyzzle is trying to do is much more complicated than loading new fonts. In addition, UMBPCI is very hardware dependent and may not even work at all on some computers. Your solution may be applicable to certain situations, but probably not this one.

> > This way you can load your fonts into the video BIOS and you don't need
> any
> > additional drivers to load them because when you change the video mode,
> the
> > BIOS will load them automatically.
>
> What Zyzzle is trying to do is much more complicated than loading new
> fonts. In addition, UMBPCI is very hardware dependent and may not even
> work at all on some computers. Your solution may be applicable to certain
> situations, but probably not this one.
Yes, but I still appreciate CandyMan's input. I previously didn't know UMBPCI could "offload" fonts into the vBIOS font area. I tried this on two laptops (one Apollolake, one Kabylake) and in both, UMBPCI said I had incompatible chipsets and could not continue.

Sideloading / injecting custom VGA 9x16 fonts into the vBIOS ROM code is exciting. I use keyRUS v. 8.0 to "replace" my generic, ugly 9x16 DOS VGA font into something much more attractive, but it still consumes ~8kb low memory. If I could accomplish this without losing any valuable memory, it'd be even better, and this is what I understand UMBPCI with the /C parameter seeks to do, according to CandyMan's post above.

> Sideloading / injecting custom VGA 9x16 fonts into the vBIOS ROM code is
> exciting. I use keyRUS v. 8.0 to "replace" my generic, ugly 9x16 DOS VGA
> font into something much more attractive, but it still consumes ~8kb low
> memory. If I could accomplish this without losing any valuable memory, it'd
> be even better, and this is what I understand UMBPCI with the /C parameter
> seeks to do, according to CandyMan's post above.

I wanted to show that you can do something like this (inject your fonts).
Maybe you can also add some function to the JEMM driver that would modify the BIOS mapped as ROM. This should work on any computer where the UMBPCI trick can't be done.

Maybe I’m missing something, but why does loading a BIOS font take extra memory or interaction with a memory manager?

Don’t you just need to call Int 10.11?

https://stanislavs.org/helppc/int_10-11.html

> Maybe I’m missing something, but why does loading a BIOS font take extra
> memory or interaction with a memory manager?

Some people use a TSR that catches interrupt 10h and after changing the video mode reloads their font which is stored in conventional memory. At the expense of XMS memory, using a memory manager (eg JEMM) you can make a video copy of the BIOS (see memory mapping and paging) and store the font there (function 10h.1130.es:bp) which the BIOS will load itself. In this case, the TSR program becomes redundant and we have more free conventional memory (an 8x16 font takes up 16*256=4K).

> > Maybe I’m missing something, but why does loading a BIOS font take
> extra
> > memory or interaction with a memory manager?
>
> Some people use a TSR that catches interrupt 10h and after changing the
> video mode reloads their font which is stored in conventional memory. At
> the expense of XMS memory, using a memory manager (eg JEMM) you can make a
> video copy of the BIOS (see memory mapping and paging) and store the font
> there (function 10h.1130.es:bp) which the BIOS will load itself. In this
> case, the TSR program becomes redundant and we have more free conventional
> memory (an 8x16 font takes up 16*256=4K).

this font - and probably most of the TSR's code - should be swapped out to XMS.

actually - as this INT 10 is never called from the kernel - the code and font data could be reloaded from disk.

> I wanted to show that you can do something like this (inject your fonts).
> Maybe you can also add some function to the JEMM driver that would modify
> the BIOS mapped as ROM. This should work on any computer where the UMBPCI
> trick can't be done.

Finally got the /C parameter to work on my Kabylake system with i5 8250 CPU. JEMM detects the chipset properly, and this /C option saves me 6k of low memory which used to be taken up by KEYRUS v. 8.0.

Thanks for the tip. I'm looking at JEMM and the possibility of modifying it to map the vBIOS ROM code using a similar "trick" as is done with the /C parameter in moving the 4k BIOS font to (modifiable) XMS memory instead.

> Thanks for the tip. I'm looking at JEMM and the possibility of modifying it
> to map the vBIOS ROM code using a similar "trick" as is done with the /C
> parameter in moving the 4k BIOS font to (modifiable) XMS memory instead.

;JEMM must be loaded similarly like this (C=specify BIOS fonts region to shadowing):
;DEVICE=JEMM386.EXE C=C800-CDFF
        org     0100h
        xor     eax,eax
        mov     fs,ax
        cmp     [fs:4*67h],eax
        jz      .Exit
        mov     ax,1130h
        mov     bh,6
        int     10h
        mov     eax,es
        shl     eax,4
        movzx   edi,bp
        add     edi,eax
        mov     eax,cs
        shl     eax,4
        lea     esi,[eax+Fonts]
        mov     ecx,256*16
        mov     ax,0xDEFF
        int     67h
        or      ah,ah
        jnz     .Exit
        mov     ax,3
        int     10h
.Exit:  ret

Fonts:  file    "special.f16"

https://megawrzuta.pl/download/a77122f5e01d9d929aa79e761b365f7a.html