How can I access the VGA card's ROM fonts with interrupt 10h operation 1130h in protected mode C?

Question

I'm using Open Watcom 1.9 to write some 286 real mode, and 386 protected mode software for DOS in C.

In real mode, I can retrieve a pointer to the system ROM character bitmaps in real mode using int 10h where AX = 1130h:

const uint8_t far *video_get_font_pointer(int font_type)
{
   union REGPACK regs;
   regs.w.ax = INT_VIDEO_10_GET_FONT_INFORMATION;
   regs.h.bh = font_type;
   intr(INT_VIDEO_10, &regs);
   
   seg_off_ptr ptr; // union with seg/off consecutive
   
   ptr.seg_off.s = regs.w.es;
   ptr.seg_off.o = regs.w.bp;
   
   return (const uint8_t far *)ptr.ptr;
}

I've tried using the same approach in protected mode (under the assumption that conventional memory/memory mapped devices like VGA can be accessed flat in Open Watcom), but the resulting es and bp don't seem to be correct if I manually combine them to make the pointer value ((es << 4) + bp).

I've tried setting ds, es, fs, gs to zero in regs before calling intr() as they're unimportant but it didn't help.

How can I access these system font bitmaps in protected mode?

Answer 1

In OpenWatcom, which was used in the example given in the question, the intr function performs transparent translation between segment values and protected-mode selectors, presumably using DPMI service 0x0002. This means that for example this program runs correctly whether compiled for real or protected mode:

#include <stdio.h>
#include <string.h>
#include <i86.h>

int main(int argc, char *argv[]) {
    union REGPACK r;
    unsigned char _far *font;
    int i;

    memset(&r, 0, sizeof(r));
    r.w.ax = 0x1130;
    r.h.bh = 6;
    intr(0x10, &r);

    printf("%04x:%04x\n", r.w.es, r.w.bp);

    font = MK_FP(r.w.es, r.w.bp);
    for (i = 0; i < 64; ++i) {
        printf("%02x ", font[i]);
        if ((i & 15) == 15)
            printf("\n");
    }

    return 0;
}

Its output on my laptop when compiled for real mode (with wcl) is:

c000:9761
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 7e 81 a5 81 81 bd 99 81 81 7e 00 00 00 00 
00 00 7e ff db ff ff c3 e7 ff ff 7e 00 00 00 00 
00 00 00 00 6c ee fe fe fe 7c 38 10 00 00 00 00 

And this is the output when compiled for protected mode (with wcl386) and run under DOS/4GW’s DPMI host:

01c8:9761
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 7e 81 a5 81 81 bd 99 81 81 7e 00 00 00 00 
00 00 7e ff db ff ff c3 e7 ff ff 7e 00 00 00 00 
00 00 00 00 6c ee fe fe fe 7c 38 10 00 00 00 00 

While this is the output when the protected-mode program is run under Windows 3.11:

0287:9761
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 7e 81 a5 81 81 bd 99 81 81 7e 00 00 00 00 
00 00 7e ff db ff ff c3 e7 ff ff 7e 00 00 00 00 
00 00 00 00 6c ee fe fe fe 7c 38 10 00 00 00 00 

The only difference is the value of the ES register, which is a segment value in real mode and a selector in protected mode. The actual interrupt handler returns a real-mode segment; it’s the DPMI host which translates it to a protected-mode selector on behalf of the C library. The selector points to the same memory as the segment does in real mode; the only difference is that you cannot perform segment arithmetic on selectors.

Other APIs may fail to perform such transparent translation. When that happens, you may have to either manually invoke the appropriate DPMI calls to allocate selectors (service 0x0000 to allocate, then service 0x0007 to set the base address and service 0x0008 to set the segment limit), or use a pre-allocated selector for the entire range of conventional memory, and use linear memory addresses as offsets relative to that selector. Open Watcom C/C++ Programmer’s Guide §5.4 describes how DOS extenders provide such pre-allocated selectors for that purpose, but you will need to check whether you are in fact running under that extender’s DPMI implementation to know whether you can actually use them. (While under DOS/4GW selector 0 addresses conventional memory, in a Windows DOS box it is an unusable null selector that will crash your program! Beware.)

Answer 2

I've accepted user3840170's answer as it solved my issue but I want to add a second answer that contains just the concepts that I lacked in order to solve my problem:

• The far keyword is still applicable in protected mode, having a similar role to its role in real mode. It allows a pointer to point to another segment through a selector as well as an address. Most pointers in 32-bit protected mode code are not far – they work in the same large segment as the rest of your own code, but it is possible for pointers to regions outside of that segment to exist. In this case, the const uint8_t * pointer into the Video BIOS I'm trying to retrieve must be a const uint8_t far *.
• In real mode the relation between segment, offset and the machine address space is linear, and can be manipulated with shifts (to get the linear address, as a DMAC parameter) or unions (assigning the two components of the pointer to fields to produce a far pointer when they're combined). In protected mode, that relationship is not valid. The MK_FP macro or :> operator (which MK_FP uses) are necessary to combine the separately obtained two parts of a far pointer together. (You should use these in real mode code anyway instead of trying to be clever with either of the other two methods. :)
• The interrupt correctly returns the segment in es and the offset in bp as usual. Zeroing the REGPACK before the intr() call is necessary. The es is a segment selector in protected mode, and the pair es:bp forms a valid far pointer in protected mode when MK_FP is used. That's the main difference between the code in my question and the code in user3840170's answer, and why theirs works!