wraggster
March 13th, 2011, 23:21
News via http://dsx86.patrickaalto.com/DSblog.html
For the past week I have been working on the original DSx86 instead of DS2x86. I began implementing the required changes in order to enable running in 286 protected mode (for Windows 3.0 Standard Mode). I have changed the memory access method to enable access to full 16MB of memory (of which around 12MB would be actually available in DSi mode, and some hundred kilobytes in the normal DS mode). It looks like Windows 3.0 only requires 24KB of extended memory to be able to run in Standard Mode, so this should make it possible to run Windows 3.0 in this mode also with DS Lite and the original "phat" DS. It will run much better on a DSi when using DSi mode, though.
The current status is that Windows 3.0 enters protected mode fine, does some setup operations, then returns to real mode (which on a 286 processor means resetting the processor using a Triple Fault (http://en.wikipedia.org/wiki/Triple_fault) exception). After that things start to go wrong somewhere in my code, but I need to add better protected mode debugging features before I can properly start working on this problem.
I had some trouble implementing proper triple fault handling, as my first information source, the DOSBox source code, was of no help. I tried to force DOSBox to report that the processor is a 80286 when Windows 3.0 checks for processor type, but when Windows 3.0 then causes a triple fault, DOSBox simply crashes with a stack overflow. Thus, I had to hunt the net for better description about what exactly should happen when the CPU gets reset in a 80286 machine. The best source I have found so far is the Protected Mode Basics (http://www.rcollins.org/articles/pmbasics/tspec_a1_doc.html) document by Robert Collins. However, it seems that the actual behaviour that happens after a reset depends on the system BIOS, and this document only shows a method where the CMOS Shutdown Byte is set to a value of 0x05. Windows 3.0 however gives it a value of 0x09, which does not seem to work similarly. I think I have now been able to determine what the BIOS is supposed to do for Windows 3.0, but since something still goes wrong there I am not absolutely sure. I am still hunting for more information, and also debugging the Windows 3.0 code further.
Besides this problem, it has been quite easy and fun to work on the old DSx86 code, as I have been able to use No$GBA and iDeaS for testing, so that I haven't needed to copy anything to real hardware. With iDeaS I can even debug and trace through my code, which has been a great help when implementing the more difficult protected mode features. I even found a bug in a code I ported from DS2x86, so this will help me in improving DS2x86 protected mode features as well.
I will probably not be able to make the code run completely by the next weekend, so I plan to switch to working on DS2x86 for the next week. It has a lot of opcode and other work still remaining, thanks for all the debug logs you have been sending since the last version! Those should keep me busy for the next week.
For the past week I have been working on the original DSx86 instead of DS2x86. I began implementing the required changes in order to enable running in 286 protected mode (for Windows 3.0 Standard Mode). I have changed the memory access method to enable access to full 16MB of memory (of which around 12MB would be actually available in DSi mode, and some hundred kilobytes in the normal DS mode). It looks like Windows 3.0 only requires 24KB of extended memory to be able to run in Standard Mode, so this should make it possible to run Windows 3.0 in this mode also with DS Lite and the original "phat" DS. It will run much better on a DSi when using DSi mode, though.
The current status is that Windows 3.0 enters protected mode fine, does some setup operations, then returns to real mode (which on a 286 processor means resetting the processor using a Triple Fault (http://en.wikipedia.org/wiki/Triple_fault) exception). After that things start to go wrong somewhere in my code, but I need to add better protected mode debugging features before I can properly start working on this problem.
I had some trouble implementing proper triple fault handling, as my first information source, the DOSBox source code, was of no help. I tried to force DOSBox to report that the processor is a 80286 when Windows 3.0 checks for processor type, but when Windows 3.0 then causes a triple fault, DOSBox simply crashes with a stack overflow. Thus, I had to hunt the net for better description about what exactly should happen when the CPU gets reset in a 80286 machine. The best source I have found so far is the Protected Mode Basics (http://www.rcollins.org/articles/pmbasics/tspec_a1_doc.html) document by Robert Collins. However, it seems that the actual behaviour that happens after a reset depends on the system BIOS, and this document only shows a method where the CMOS Shutdown Byte is set to a value of 0x05. Windows 3.0 however gives it a value of 0x09, which does not seem to work similarly. I think I have now been able to determine what the BIOS is supposed to do for Windows 3.0, but since something still goes wrong there I am not absolutely sure. I am still hunting for more information, and also debugging the Windows 3.0 code further.
Besides this problem, it has been quite easy and fun to work on the old DSx86 code, as I have been able to use No$GBA and iDeaS for testing, so that I haven't needed to copy anything to real hardware. With iDeaS I can even debug and trace through my code, which has been a great help when implementing the more difficult protected mode features. I even found a bug in a code I ported from DS2x86, so this will help me in improving DS2x86 protected mode features as well.
I will probably not be able to make the code run completely by the next weekend, so I plan to switch to working on DS2x86 for the next week. It has a lot of opcode and other work still remaining, thanks for all the debug logs you have been sending since the last version! Those should keep me busy for the next week.