OSDev.org

Hi all,

I'm trying to get an understanding about the how various registers control the way data read/writes to vga memory work
odd/even, chain4, etc. I'm writing some basic assembly programs to test my understanding of the documentation.

Referring to the Wiki https://wiki.osdev.org/VGA_Fonts (the section titled Get from VGA RAM directly), I've managed to write to the vga memory in text mode, turn off odd/even mode, and read from plane 0, expecting to get back the text I've already written.

My problem is, no matter what I try, the data read back is always the same - font data from plane 2 (I know it's font data because I've used it to render text output). For testing I'm using Dosbox 0.74, with the setting "machine=vgaonly".

The basic steps I use are:
[*]Disable odd/even mode - Clear bit 1 of Graphics controller Miscellaneous Graphics Register (0x3ce Index 06)
[*]Graphics mode (Shift256/Shift Reg/Host O/E/Read Mode/Write Mode) all to 0 (0x3ce Index 05)
[*]Sequencer - Disable Chain 4/Disable Odd/Even Host Memory Write Addressing (0x3c4 Index 04) - Clear bit 3, Set bits 2 and 1
[*]Graphics controller Read Map Select (0x3ce Index 04) - set to 0 to select plane 0 (this is not mentioned in the Wiki)

Curiously the last step isn't in the Wiki code snippet I mentioned, however 0x3ce Index 02 (Memory Plane Write Enable) is. This has me puzzled since we're reading from vga memory not writing. I've tried setting this register to various values as well but it has no effect.

Right now I'm stuck and don't know what else to try. I've put the current nasm source file at https://bitbucket.org/snippets/DrSly/Ee ... ext-mode-3 if anyone is interested in having a look.

I really hope someone here still remembers how to read from vga in planar mode

DosBox is an emulator, and employs a rather different way of doing VGA. It probably keys different settings to "mode to read and write the text font", and as a result gets you bugs that only occur on emulators - just as qemu or Bochs might land you into trouble.

In fact, I've cross-referenced my font reading code and it explicitly swaps to full-on Mode X before the read, rather than doing the least possible steps you'd expect based on the manual. That means that even without DosBox - which I never actually used for OS testing - I needed that kind of logic to make emulation, VMs, as well as real hardware do the right thing.

Thank you for the reply, this really helped. I have tested on real hardware and I can see something closer to the results I was expecting.

I should have known the emulation is not 100% accurate but didn't realise how bad it is actually. I find it interesting that the emulator will run old dos programs successfully and yet show such incompatible behavior when programmed at the register level. Did any of the old dos programs ever program non-standard values into the vga registers?

I guess there is no choice but to cross-check the results on real hardware every time - something which I hoped I could avoid... oh well.

Btw I was reading in a thread from 2007, in which you posted about deficiencies in the implementations of various emulators and chain4. As a new member it's nice to see a response from someone who's been around that long.

All the best

Sylvester

Hi,

Happy days. I understand now how the Sequencer Memory Mode Register (Index 04h) works regarding Chain4 and Odd/Even Host Memory Addressing.

Now I need help deciphering the Graphics registers (Index 05 & 06).

According to http://www.osdever.net/FreeVGA/vga/graphreg.htm

Index 05, bit 4:
Host O/E -- Host Odd/Even Memory Read Addressing Enable
"When set to 1, this bit selects the odd/even addressing mode used by the IBM Color/Graphics Monitor Adapter. Normally, the value here follows the value of Memory Mode register bit 2 in the sequencer."

I have another reference which says "Even CPU addresses access planes 0 and 2, while odd CPU addresses access planes 1 and 3." This confuses me, since I thought that there is a "Read Map Select" register which determines the plane that is accessed.

My testing, on real hardware, shows this register has no effects when reading vga memory.

Index 06, bit 1:
Chain O/E -- Chain Odd/Even Enable
"When set to 1, this bit directs the system address bit, A0, to be replaced by a higher-order bit. The odd map is then selected when A0 is 1, and the even map when A0 is 0."

That's complete nonsense. Which higher order bit is A0 replaced by? And then the map selection is based off A0 before or after being replaced? Can someone explain how this works?


Regardless, the testing I've done shows neither register has any effect on reads/writes to the vga memory.


Maybe I missed something, my tests are flawed, or maybe I didn't understand the docs (which I don't).


What do I need to do to see the effects of these registers???

Anything related to odd-even is a leftover of EGAs wanting to emulate CGAs. You'll see this being used in text mode where character and attributes live on separate memory banks, but where bit 0 is used to select plane 0 or 1 (even and odd) rather than having to write registers to toggle between text and attributes - and the same mechanisms exist for reading. There will probably be some other settings that makes

The one place where Chain odd-even was apparently used, is for backwards-compatible support for 4-color modes - which of course nobody wants to do nowadays. A quick review across the internet states that A0 would get replaced with the most significant bit corresponding to the installed memory size, and might thus well be beyond reach on VGAs that have 256k compared to the original 16k that this emulation was meant for.

I haven't done much with tests regarding odd-even things, and there isn't anything relevant in my VGA validation code either so I'd have to do my own homework just as much over this.