Common searches

First post, by tuxie

User metadata
Rank Newbie

Starting off with the dosbox specific question first, since it's the only one I am certain about belonging here:

Does anyone know how dosbox handles memory mapped I/O? I have been looking at the source code for the vga adapter, and searching the source with githubs built in search leaves mentions to checking if trapping direct memory access is available, but I can't seem to find where dosbox actually does it 😀. Is it handled some other way, in code generation, or am I blind/searching wrong?

The next question is about graphics specifically:
I am poking around some source code for a classic DOS game, and been toying with getting it working on newer hardware.

https://github.com/smitelli/cosmore/blob/68c6 … wlevel.asm#L342

In that source, it says that it copies to all the EGA planes at the same time while in latched mode. But, in EGA, there are four planes, meaning 4 bits each, or half a byte. It seems to copy just 8 bytes, while to me it should take 8*8/2 = 16 bytes.
Does anyone have a clue what is going on? 😀

Reply 4 of 6, by Ringding

User metadata
Rank Member

Yes, but why would you care? The copying does not happen by going through AL. In fact, what goes into/out of AL does not matter at all. What matters is that the movs trigger reads and writes at the relevant addresses. One byte read copies one byte from each of the four planes into its latch, while the byte write does the opposite (write latch contents into plane memory for each of the four planes).

Reply 6 of 6, by mkarcher

User metadata
Rank Oldbie
tuxie wrote on 2022-05-10, 13:50:

Oooooh! Thank you, I get it now. So that's what those comments meant!

Exactly. To really understand the EGA architecture, you need to be aware that every 8-bit processor read or write cycle causes the 32 bits to be exchanged between the graphics controller and the RAM, which is physically 64K x 32, not 128K x 8. For writes, the timing sequencer can be programmed to only send the write enable to some of the 4 planes, causing the RAM to not care about some of the 32 bits sent from the graphics controller to the RAM chips. On every read cycle, the full 32 bits received from the graphics RAM go into the four 8-bit latch register inside the graphics controller (technical nitpick: As IBM built the original EGA card with no chip with more than 40 pins, they "split" the 32-bit graphics controller into two halves that handle 16 bits each). You can set a "read mode" in the graphics controller, but that mode only determines how the ISA bus is served using the data stored to the latches, it doesn't affect the latching itself. The memory copy code you cited was a very common EGA technique those days: It uses "write mode 1" which instructs the graphics controller to just drop the data from the ISA bus and output the contents of the latches to the RAM chips.

As the actual 32-bit data transfer happens on the EGA card itself with the processor just supplying addresses on the ISA bus, it is very important to use "REP MOVSB" or open-coded MOV instructions here, do not try to "optimize" it to REP MOSVW. As a (standard) EGA or VGA graphics card is an 8-bit device, a word load would first load the 32 bits at the low address to the latches, then overwrite it with the 32 bits at the high address, and the subsequent word store would write the high 32-bits from the source address to the low and the high 32 bits of the destination address.