My proposal is that the faulty code might happen to work anyway if the A20 gate were temporarily turned off in that case because the 8088-like 1MB wraparound would then work around the bug. The faulty code in the EXE packer fails if the EXE is loaded lower than 64KB from the base of conventional memory, which is why LOADFIX is a remedy for it. If the code is faulty in specific conditions then it should fail just like it would on real hardware and real MS-DOS. It emulates the x86 instructions one by one. How does Daum "ignore the bugs"? DOSBox in general is an emulator. Dosbox Daum may possibly be emulating a lot less of a DOS system, so that too much memory doesn't trigger an error. Meanwhile, Dosbox Daum gives no error when running CIV with too much memory, so it doesn't need LOADFIX at all. So 608K Free would allocate until 576K (64K * 9) is available, instead of allocating 64K. So I think my suggestion would be to change LOADFIX to allocate down to the next 64K multiple instead of always allocating 64K. Making the change "minimum mcb free = 1" makes Dosbox-X instead provide 627K of conventional memory, and running CIV triggers LOADFIX again, which results in 563K of available conventional memory. Now it has 544, which is under 551, so there's not enough memory. Attempting to run CIV with this much memory triggers running LOADFIX, which allocates 64K of memory. Under default settings, DOSBox-X provides 608K of conventional memory. CIV 1 needs 551K of free conventional memory to run, but won't start on DOSBox-X (triggers LOADFIX) unless 576K or less is available.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |