DS2x86 version 0.23 released!

August 29th, 2011, 18:30 Posted By: wraggster

Via http://dsx86.patrickaalto.com/DSblog.html


This version has the following fixes and changes, more info about some of these can be found in my previous blog post:

1. The DOS file rename functionality was fixed. This will help with Albion save game handling, and very likely with other games and software as well.
2. Fixed a bug in the 32-bit ADC opcode (add with carry) Carry flag handling. This caused the floor and ceiling graphics corruption in Albion. I found the cause for this problem by debugging the ceiling drawing (opcode by opcode) in both DS2x86 and DOSBox, and noticed a difference after executing this opcode. After I found the misbehaving opcode, I searched all my DS2x86 source code for "adc carry" to find other similar errors, and the search resulted in the following:
   Find all "adc carry", Subfolders, Find Results 1, "Entire Solution" C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(396): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(464): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(489): // adc Carry: ((unsigned)lf_val1 < (unsigned)lf_res) || ((flags&1) && (lf_val1 == lf_res)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(510): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(1808): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(1972): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(2339): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); C:\Projects\ds2sdk_r\DS2x86\src\cpu_386.S(2364): // ADC Carry: ((unsigned)lf_res < (unsigned)lf_val1) || ((flags&1) && (lf_res == lf_val1)); Matching lines: 8 Matching files: 1 Total files searched: 99There are actually 8 different code branches in DS2x86 where the 32-bit ADC opcode is handled, depending on the memory/register variations. Curiously, the third match (which is for the version that adds two 32-bit registers) had a wrong comparison order even in the comment! It looks like I have copy-pasted that version from the corresponding subtract operation SBB, and had just forgotten the fact that the carry flag calculation should be reversed! If I had had proper unit tests for all the 32-bit core opcodes (as I have for the 16-bit opcodes) I would have found this problem a long time ago. However, I believe the core opcodes currently have so few bugs that spending weeks in creating full unit tests for all of them is not worth it any more. Anyways, after this fix the 3D areas in Albion began to look correct:
3. The screens are swapped back to the normal order when the Touch Pad Mouse gets turned off, for example when the executable program changes. Previously the screens might have stayed swapped, with no way to swap them back as the code thought the screens were already in normal order!
4. Major internal rewrite to enable virtual memory (paging) support. This mostly affects the graphics opcodes (EGA and Mode-X) for now, as I had to change the method the memory address table values are flagged to make a distinction between normal RAM and graphics VRAM emulation. This may cause some graphics errors if I forgot to change some of the graphics opcodes. Let me know if you notice graphics problems that did not happen in the previous versions.
5. I have also done a lot of work for virtual memory support itself, but this work is not yet finished and thus games that need virtual memory will not run yet. However, in this version I have not disabled the virtual memory completely, instead, the games will attempt to progress further. Since the code is not fully done yet, they will crash or drop into debugger, most likely pretty soon after they turn on paging. You can determine that paging was the cause for the drop into debugger if you see the "Paging=1" text in the debug report, like this:
   
   
   
   The crash logs will be very useful for me when I continue my work on the virtual memory, so please send the debug logs to me again! You can attempt to continue after the drop into debugger with the B button, though this will also most likely fail. I have been using Descent 2 demo in my virtual memory tests, and it currently gets a Page Fault within the Page Fault handler, which makes it quit back to DOS with an error report. This does not happen in DOSBox, so there is something wrong with my paging code. This is what I am currently attempting to fix.

There are 0 comments - Join In and Discuss Here