M-374 LX wrote:Why the value changes, instead of just using bitwise operators (&, |, ^, ~)?
You don't seem to quite understand how memory-mapped I/O (often abbreviated MMIO) works... you're still thinking in terms of RAM. MMIO doesn't work like RAM, so forget what you know about it. In particular, GFXCNTL doesn't represent a "value" at all. It's actually a port that happens to be written to and read from in the same way as memory.
What you're really doing when you write to GFXCTNL is issuing commands, not writing data. The multiple writes simply represent multiple commands You really need some docs on the VDP (that's what we call the graphics chip) to fully understand it, and even then it may take you a while to understand everything that's going on, but here's the basic idea.
The VDP has 23 registers which are used to control various aspects of the display. When a 16-bit value is written to GFXCNTL, this value is a command to set one of the registers. The high byte specifies the register number, which is 0x00 to 0x17, plus the highest bit is always set, so it reads as 0x80 to 0x97. The low byte is the value that is inserted into the register; what the value means depends on which register you're using. (Note that these registers are write-only. You can read from GFXCNTL, but doing so just gives you a bunch of flags.)
Thus, in the line "*pw = 0x8016;", it's really saying "Set VDP register 0 to 0x16." Here's where you consult your docs to find out what a value of 0x16 in VDP register 0 means.
GFXDATA is sort of similar, but in this case you actually are writing data rather than commands. First, before writing to GFXDATA you must write a 32-bit value to GFXCTNL. Writing a 32-bit value works completely differently from writing a 16-bit value, and it's a bit complicated, but it basically specifies where in VRAM you want to write to or read from. (Consult the docs for The writing and reading is done through GFXDATA, but it can only be set to read or write, not both, depending on the value you sent to GFXCNTL.
The VDP contains an internal "pointer" to VRAM (or CRAM, or VSRAM, but I'll call 'em all "VRAM" for convenience). Every time you write a value to GFXDATA, this pointer is incremented. How much it's incremented depends on the value in VDP register 15 (hex 0f). So by repeated writes to GFXDATA, you will write to the VRAM in a linear fashion. I think the most typical way to do things is to have register 15 set to 2 and to read or write using 16-bit and 32-bit values. So if you do this, supposing you told the VDP to write at 0000, the first word you write will be at 0000, the second will be at 0002, the third at 0004, etc.
Here's where things get odd, and I
might have this completely wrong (I've done very little Genesis dev so far), so be careful, but I
think GFXDATA works like this. GFXDATA accepts 8-bit writes and 16-bit writes. If you do a 32-bit write, it will interpret it as two 16-bit writes. This affects how the VDP's internal pointer gets updated. If register 15 is set to 2, then writing a byte will increase it by 2, and writing a word will also increase it by 2, but writing a dword will increase it by 4 (because it's interpreted as two words, hence it increments twice).
As for docs, google for genvdp.txt for some pretty good docs on the VDP. (Note that C00004 is GFXCNTL and C00000 is GFXDATA.) There's also sega2f.doc, which contains much of the same info (though less in the way of explanations) as well as a bunch of other stuff. Also be sure to refer to genesis.c and genesis.h for some helpful #defines and routines, as well as to help you figure out what's going on.
- Kef
