wraggster
April 18th, 2011, 21:06
News via http://dsx86.patrickaalto.com/DSblog.html
After I got DSx86 version 0.31 released, I went back to improving DS2x86. It has been on a small hiatus, so I first needed to remind myself at what state I left it when I began working on the DSx86 enhancements. First I changed the Scaled screen mode to use the same speed enhancements as DSx86, as that was a simple and straightforward change. Next, I went thru the debug logs that you have sent me for version 0.06, and implemented some simple still missing opcodes.
I also spent a couple of hours trying to get rid of the "stuck key" problem, that is, the intermittent problem where not all key presses/releases get recognized. I suspected that my use of the timer interrupt handler for performing the DSTwo SDK screen and audio refresh stuff might be the cause, so I hacked together a version where the timer interrupt only sets a variable to request a screen refresh, and the actual refresh routine is called in the main code. However, sadly this did not have any effect on the key problem, the keys still got stuck. But at least I found out that the timer interrupt does not cause this problem. The next thing I tested was changing the timer interrupt speed from the original 60Hz speed to 59Hz. Curiously, that seemed to help at least somewhat. It seems like the key reading issue is caused by some synchronization problem between the SDK timing and my internal timer. I think I will leave the timer interrupt running at 59Hz in the next version, and I'll let you test and report whether the "stuck keys" are still a problem.
The next step was to download some games that have some more difficult problems, like hanging, jumping to zero segment or BSOD exceptions. I found five games to test; Pinball Fantasies, Xargon, The Chaos Engine, Micro Machines and Zool 2. This is the current status with those test games:
Pinball Fantasies hung at the start. After some debugging I found out that it hangs in a routine where it tries to sync the timer interrupt to the screen horizontal blanking signal. I had emulated the screen vertical blanking signal with a reasonable accuracy, but the horizontal blanking was just a simple on/off toggle without any proper timing behind it. This seemed to overflow the variable that Pinball Fantasies used in an attempt to sync, and thus it never found a correct sync value and kept trying forever. I changed the horizontal blanking bit in VGA register 0x3DA to report something closer to the proper interval, and Pinball Fantasies progressed further. However, now it jumps to zero segment (null pointer), and I haven't yet figured out what causes that.
Xargon was just missing one port input opcode, after which it went to the start menu and began a demo game. However, something is still wrong with it, as the timing seems to be seriously messed up. The main menu only displays for a fraction of a second before the demo game begins, and in the demo game the character moves extremely slowly. This issue still needs more study.
The Chaos Engine begins loading the game, but then jumps to zero segment (null pointer). It looks like the pointer should contain the address of the XMS driver (HIMEM.SYS), but as DS2x86 does not yet have an XMS driver, the game gets a null pointer and then calls it. This should get fixed after I implement the HIMEM.SYS emulation, similar to what I did for DSx86.
Micro Machines caused a BSOD. I checked the reported address from the map file, and found out that this happens when returning from a forked program when the stack pointer is not aligned. I changed my DOS emulation code to allow for unaligned stack pointer in this situation, and Micro Machines seems to run fine after that change.
Zool 2 wanted to use an lss opcode in real mode, which I had not implemented yet. I implemented that, but my version of Zool 2 wants to run from a CD-ROM, so I could not test whether the game would work properly after that change.
Currently I am working on the Jazz Jackrabbit game, or more generally, the Borland RTM DOS extender support. I last worked on it during January, and it has not progressed further since that. I have now been debugging it for a few hours, and have determined that some data that it copies from the low memory to the extended memory does not contain the values that it should, but I haven't yet determined where the original data is loaded and why it is different in DS2x86 to what it contains in DOSBox.
During the next week I plan to continue working on Jazz Jackrabbit, and possibly implement the HIMEM.SYS emulation for DS2x86. There are also some opcodes whose implementation is still missing, so all these will keep me busy for the next week. After these fixes I think it is time to focus on the audio features. I hope to release a new version of DS2x86 during the next (Easter!) weekend.
After I got DSx86 version 0.31 released, I went back to improving DS2x86. It has been on a small hiatus, so I first needed to remind myself at what state I left it when I began working on the DSx86 enhancements. First I changed the Scaled screen mode to use the same speed enhancements as DSx86, as that was a simple and straightforward change. Next, I went thru the debug logs that you have sent me for version 0.06, and implemented some simple still missing opcodes.
I also spent a couple of hours trying to get rid of the "stuck key" problem, that is, the intermittent problem where not all key presses/releases get recognized. I suspected that my use of the timer interrupt handler for performing the DSTwo SDK screen and audio refresh stuff might be the cause, so I hacked together a version where the timer interrupt only sets a variable to request a screen refresh, and the actual refresh routine is called in the main code. However, sadly this did not have any effect on the key problem, the keys still got stuck. But at least I found out that the timer interrupt does not cause this problem. The next thing I tested was changing the timer interrupt speed from the original 60Hz speed to 59Hz. Curiously, that seemed to help at least somewhat. It seems like the key reading issue is caused by some synchronization problem between the SDK timing and my internal timer. I think I will leave the timer interrupt running at 59Hz in the next version, and I'll let you test and report whether the "stuck keys" are still a problem.
The next step was to download some games that have some more difficult problems, like hanging, jumping to zero segment or BSOD exceptions. I found five games to test; Pinball Fantasies, Xargon, The Chaos Engine, Micro Machines and Zool 2. This is the current status with those test games:
Pinball Fantasies hung at the start. After some debugging I found out that it hangs in a routine where it tries to sync the timer interrupt to the screen horizontal blanking signal. I had emulated the screen vertical blanking signal with a reasonable accuracy, but the horizontal blanking was just a simple on/off toggle without any proper timing behind it. This seemed to overflow the variable that Pinball Fantasies used in an attempt to sync, and thus it never found a correct sync value and kept trying forever. I changed the horizontal blanking bit in VGA register 0x3DA to report something closer to the proper interval, and Pinball Fantasies progressed further. However, now it jumps to zero segment (null pointer), and I haven't yet figured out what causes that.
Xargon was just missing one port input opcode, after which it went to the start menu and began a demo game. However, something is still wrong with it, as the timing seems to be seriously messed up. The main menu only displays for a fraction of a second before the demo game begins, and in the demo game the character moves extremely slowly. This issue still needs more study.
The Chaos Engine begins loading the game, but then jumps to zero segment (null pointer). It looks like the pointer should contain the address of the XMS driver (HIMEM.SYS), but as DS2x86 does not yet have an XMS driver, the game gets a null pointer and then calls it. This should get fixed after I implement the HIMEM.SYS emulation, similar to what I did for DSx86.
Micro Machines caused a BSOD. I checked the reported address from the map file, and found out that this happens when returning from a forked program when the stack pointer is not aligned. I changed my DOS emulation code to allow for unaligned stack pointer in this situation, and Micro Machines seems to run fine after that change.
Zool 2 wanted to use an lss opcode in real mode, which I had not implemented yet. I implemented that, but my version of Zool 2 wants to run from a CD-ROM, so I could not test whether the game would work properly after that change.
Currently I am working on the Jazz Jackrabbit game, or more generally, the Borland RTM DOS extender support. I last worked on it during January, and it has not progressed further since that. I have now been debugging it for a few hours, and have determined that some data that it copies from the low memory to the extended memory does not contain the values that it should, but I haven't yet determined where the original data is loaded and why it is different in DS2x86 to what it contains in DOSBox.
During the next week I plan to continue working on Jazz Jackrabbit, and possibly implement the HIMEM.SYS emulation for DS2x86. There are also some opcodes whose implementation is still missing, so all these will keep me busy for the next week. After these fixes I think it is time to focus on the audio features. I hope to release a new version of DS2x86 during the next (Easter!) weekend.