PIT emulation via pit hack= DOSBox config file param. Added PIT hack for
Project Angel. When the PIT timer is written, the value is forced to one
of two values (18.2Hz or 421Hz). Considering that the demo is constantly
fiddling around with the timer in ways it can lose stability, this
forces the demo to run properly and resolves quite a few issues with
DOSBox.
that when option is set, the private data segment is given to all RAM
from a base segment, then DOS kernel structures are allocated from it,
and then, at the stage where the MCB system is first built, direct the
private segment back up to it's original location (private segment
allocations prior to that point naturally take their place bottom up).
Fixed XMS driver to correctly handle the dynamic case. So far as I can
tell, the dynamic mode does not cause any problems, not even with
Windows 3.1.
longer used). added code to call PAGING_FlushTLB() to ensure that
changes to the memory map take effect. Prior to the fix, the code
changed the map to unmap the regions but the memory was still accessible
because of TLBs.
boot an operating system. Mainline DOSBox behavior is to leave it up
there, while DOSBox-X now defaults to unmapping the UMB (since the OS
will not know it's there and will probably confuse it with adapter ROM).
emperically based on "compatible mapping". Added dosbox.conf setting to
allow overriding the VGA BIOS size. Re-added code to choose private area
segment and position it just past the VGA BIOS. Project Angel is happy
this time, Windows 95 no longer causes numerous "illegal memory read"
errors. So far, so good.
UMB block. When compatible mapping is disabled, it helps pack adapter
ROM usage down and allows up to 176KB of extra space should DOS programs
use any UMBs.
DOSBox was doing at 0xD000 was emulating Upper Memory Blocks. Added code
to memory handler to default map out those pages, then allow the XMS
driver to map them back to RAM. Added options so that you can control
the UMB region and size from dosbox.conf.
region in the 0xF000 segment instead of DOSBox's private segment at
0xC800. Corrected language regarding realbig16, the B (big) bit hack
doesn't allow for 32-bit real mode code, it only allows the code segment
to extend past 64KB (huge real mode).
acknowledged in my code that mapping out D000:0 only causes minor but
possibly significant faults with BIOS routines in F000:0 (would that be
what killed DOSBox-X2?)
DOS demos like Project Angel. To explain: the demo apparently relies on
the same protected mode hack DOS demos usually do to enable Flat Real
Mode, but Project Angel also uses it to enable the B bit to effectively
set up a 32-bit flat real mode (32-bit code in real mode!). At least
that's what I think it's doing. It would explain all the complaints
about not being able to run the demo, and why this patch makes it work.
People (rightfully so) complained that the patch might break virtual
8086 mode emulation. I'm also concerned about whether or not this patch
breaks anything, so the patch is conditional: it's there if you enable
it by setting realbig16=true in the [cpu] section of your dosbox.conf,
otherwise, DOSBox-X retains original behavior of always clearing the BIG
bit in the code segment cache.
