Open joncampbell123 opened 6 years ago
These graphical issues do not occur in DOSBox SVN when machine=pcjr, so SVN should be examined to see what it is doing right.
One of the very first games I've played ... 30 years ago !
@joncampbell123 I want to test this, but can you describe the graphic corruption to look for? Is it on the top-of-screen menu bar? When I press ESC in either SVN or DOSBox-X, the game will pause but no menu bar appears.
Actually the issue was probably the text at the bottom of the screen, right? Looks like it carried over the copyright text and "Press any key to continue." text from the starting screens over into the start of gameplay. It doesn't do that now, either in SVN or in DOSBox-X, before or after the recent PCjr changes.
Here is a screen using b032480.
Is there a way to display that text at the top of the screen with the score and sound status? I thought maybe there were graphical issues there but I don't know how to display it to test it. Or was the fact that it was showing itself a bug?
It's working here. machine=pcjr. Although to get it to run I have to first run "loadfix -60" to make sure it loads above the 128KB boundary.
EDIT: Tandy mode also works, machine=tandy.
Apparently KQ1.COM, if it detects a PCjr, will read the "real memory size" from 40:15 (which I just implemented!), convert to a segment value, then directly modify the memory control block for KQ1.COM so that the memory region extends to the end of real memory. Then it calls INT 21h AH=4Ah to resize the block. If KQ1.COM's memory region is NOT the last one in the MCB chain, this triggers a "Corrupt MCB chain" error.
If you use LOADFIX to force KQ1.COM to load above 128KB, then KQ1.COM is the last memory block and that hackery doesn't cause the corrupt MCB chain error.
It does not do this if machine=tandy.
If KQ1.COM is below 128KB, then KQ1 is not the last block, because it's loaded below the 32KB block reserved for PCjr video memory, and you get "Corrupt MCB chain".
Which reminds me: The 32KB reserved block is there only because more than 128KB of RAM is there in PCjr mode. In fact the default, inherited from DOSBox SVN, is 640KB. If memsizekb=128 and memsize=0, then what DOSBox-X should do is just report 32KB less the total memory from the BIOS, and the DOS kernel should just make a normal MCB chain out to (128KB - 32KB). Then when KQ1.COM is loaded, and memsizekb=128, it is the last block in the chain and should work normally.
I think the reserved block trick for video memory is there to emulate how various DOS drivers were used on real PCjr hardware to allow sidecars to add memory while keeping video RAM intact.
Hey, just thought of something also:
These PCjr DOS drivers modify the MCB chain to add memory, but do they change the "size of available memory" fields of the BIOS data area?
Also worth noting is that KQ1 trashes the MCB list if loaded too low in memory, but that may be true on real hardware or real MS-DOS as well since executables usually weren't loaded that low in memory. It happens in DOSBox-X and DOSBox SVN.