Graphics Controller bitmask into account. Add code to switch to this
slower version if the graphics controller bitmask register is changed
while running in 320x200x256 mode. This fixes two parts of Impact
Studio's "Legend" demo that rely on the GC bitmask and VGA DAC pel mask
registers to do "bitplane flipping" in 320x200x256 VGA mode. Prior to
this fix, those two parts failed to render properly and would instead
draw a flickering ball on the screen instead of the intended 3D rotating
object.
Note that most demos and games do not use the bitmask register in
320x200x256 mode (not even mode-X) and abusing it that way is very
unusual, though apparently supported by most VGA hardware.
why and when it triggers a "MCB list is corrupt" error message in
DOSBox and how to reconfigure your dosbox.conf to work around it.
It turns out the demo (perhaps the graphical effect routines) clears and
overwrites memory in the 0xC0000-0xCFFFF range. If DOSBox has any
private areas or upper memory blocks there, the data there will be lost.
If upper memory blocks exist up there, they will be lost and DOSBox will
E_Exit() with a message stating that the MCB list is corrupt. When I
added code to dump the MCBs, I saw that when this happens, the MCBs
below the 640KB boundary are OK, the MCBs in the upper memory are zeroed
out.
if the guest OS or application uses the standard method through the
keyboard controller. This fixes Windows ME's inability to reboot the
system when you select "restart system". Windows 95 and 98 apparently
happened to work regardless because they contained code to fallback to
calling INT 19h from real mode... or something.
the demo is using for animation is NOT PIT timer #0, but PIT timer #2.
Yes, the one normally used to drive your PC speaker. And it doesn't let
it tick so much as it uses it for a delay loop. DOSBox's emulation
apparently counts down too slow, which is why the demo runs too slow.
The PIT hack written for it forces the value to count down faster,
allowing the demo to run at full framerate.
twice are related to the ability to choose the private area size,
meaning that if the private area is too small, the demo (or DOSBox?)
causes memory corruption or overruns the buffer?
