OSDev.org

Hi again.
I though that I've reach a point where I would be able to handle most problems myself, but I stand corrected. I've recently been playing around with some very basic VGA stuff in order to load a new font into the VGA memory. My implementation works very well in Bochs and on real hardware, but QEMU seems to be using an entirely different implementation of the VGA hardware.

Well, in text mode standard VGA hardware has the ability to store a total of 8 sets of fonts in the 64 KB memory chunk at 0xA0000. Each font using 0x2000 bytes of memory. The font in use is selected using the Character Map Select Register (03h) in the Sequencer Register (0x3C4/0x3C5). I've chosen to load a 8x8 font at 0xA0000 and a 8x16 font at 0xA2000 which enables me to make quick switches between 80x25 and 80x50 mode. This works as expected in Bochs and on my laptop.

For some time I've tried to figure out how the hell Qemu handles fonts and I partially understand it now, but I doesn't make much sense to me. Qemu uses 0x4000 bytes of memory for each font, but it only uses every second slot, so to speak. First character is stored at 0xA0000, but then it skips a slot (each slot is normally 32 bytes) and stores the next character at 0xA0040. Furthermore it also skips every second byte in each slot, so that each line of a char is stored at e.g. 0xA0000, 0xA0002, 0xA0004 and so on. Finally because each font uses twice the normal size, the values normally written to the Character Map Select Register in order to select a specific font does not match.

I suspect that there's some kind of switch that changes this behaviour? Have anyone got an idea on how I get around this problem, I find it a little odd.

Thanks in advance.

That's not completely correct. The VGA has 4 banks of RAM, each 64k in size. The host-side frontend can map it at some address, either 0xA0000, 0xB0000 or 0xB8000, and it can map offsets directly onto the 64k such that each address maps to four locations, or it can shift those addresses such that you can access 64k of memory interleaved over all four banks without overlap (but you can't get access to the remaining 192k that way)

Text mode uses banks 0 through 2. 0 contains the character data, 1 contains the attribute data, and 2 contains the font data, each font being 256x32 bytes (0x2000). In normal text mode, accesses are interleaved over plane 0 and 1, while plane 2 and 3 are inaccessible. To access the font, you'd normally turn interleaving off (odd/even mode), change the decoded range to 64k, to end up in planar mode where you can select plane 2 and write the font as expected. It worked three years ago, and it does still work in qemu.

qemu did have problems with interleaved modes working different, and based on the description you appear to be using odd/even mode to write the font.

Thanks Combuster, you're absolutely right. Apparently I'd forgotten to disable odd/even access

I've been looking through my code several times without realizing that I was missing a write to the Graphics Mode Register in order to disable odd/even. I had only disabled odd/even in the Miscellaneous Graphics Register.

The following two lines of code did the trick. Apparently Bochs and my laptop doesn't care about the Graphics Mode Register.

Sorry about necro-ing this thread, but as a person from the future I came upon it and there's a subtle, but important, point to be made.

The important part of the solution by zity is in effectively clearing the graphics controller's graphics-mode register's "Host Odd/Even Read Memory" bit.

As far as I can tell, this is incorrect, and points to a bug in QEMU. As its name suggests, that bit affects read operations, not write operations. The correct way to disable odd/even addressing for writes is instead to set the sequencer's memory-mode register's "Odd/Even Host Memory Write Addressing Disable" bit. Indeed, this is all that's necessary for Bochs and VirtualBox.

lol, 7 year bump.. Seen worse though