search

joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.78k stars 382 forks source link

King's Quest I machine=pcjr graphical issues #804

Open joncampbell123 opened 6 years ago

joncampbell123 commented 6 years ago

kq1_000

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.

joncampbell123 commented 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.

aybe commented 6 years ago

One of the very first games I've played ... 30 years ago !

Allofich commented 3 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.

Allofich commented 3 years ago

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.

guest os_000

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?

joncampbell123 commented 3 years ago

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.

kq1_000

joncampbell123 commented 3 years ago

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.

joncampbell123 commented 3 years ago

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.

joncampbell123 commented 3 years ago

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?