I'm trying to get an understanding about the how various registers control the way data read/writes to vga memory workodd/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".

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.

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.

_________________"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie[ My OS ] [ VDisk/SFS ]

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.

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.

Quote:

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).

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.

_________________"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie[ My OS ] [ VDisk/SFS ]

Who is online

Users browsing this forum: No registered users and 15 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum