This weekend I worked on the various unsupported DOS interrupts that I have noticed on the debug logs I have been receiving. So far I have added about half of the dozen or so unsupported DOS features on my TODO list. During the past week I debugged some games that behaved strangely in DSx86, and found and fixed several bugs in the code while doing this:

Moraff's World just quit back to DOS immediately when trying to run it in DSx86. This was caused by a bug in my memory reallocation code. It should have returned the largest available block if a program requested more memory than was available, but it returned the requested amount. Fixing that problem allowed the game to start.

Simcity demo quit with "Division by zero" when it tried to load the San Francisco map. This was caused by a bug in my unsigned div opcode handling. I used the ARM 32bit/32bit division feature, which gave a wrong result if the numerator was >= 0x80000000. I switched to using int64/int32 division for this situation, and that fixed the problem in Simcity demo.
Ultima 3 seemed to hang at the start. I added a new debug feature into DSx86 where it shows all the called interrupt functions when running with the debugger screen visible. Here I noticed that it tries to open a file using the (nearly obsolete) DOS 1.0 File Control Block functions. I had coded that function to simply return error, but Ultima 3 did not expect an error return. I added the basic FCB functions (open, close, read, write) using FreeDOS sources as a reference. FreeDOS handles those functions by wrapping the normal DOS file functions, so I did it similarly. This means that calling these FCB DOS functions in DSx86 is rather inefficient, as they are wrappers over the normal DOS file functions, which in turn are wrappers over the C standard stdio file functions, which are wrappers over the functions provided by LibFAT. Anyways, after adding these functions Ultima 3 seems to run properly.

Electranoid crashed DSx86 completely. I still don't know what exactly it did that caused a total crash (where NO$GBA shows a popup "The rom-image has crashed"), however I noticed that it used the DOS internal SYSVARS - GET LIST OF LISTS call that returns a pointer to DOS internal data area (but which did nothing in DSx86). The game tried to use the pointer to the start of the allocated memory block chain, and went to random locations in the memory when this pointer did not contain any valid data. I added support for this call (though many of the other pointers are still marked as invalid) and the game stopped crashing, but then it reported "Critical error - Out of EMM memory." I tried adding the amount of EMS memory DSx86 reports, which just changed the error message to "Critical error - No Microsoft compatible mouse found", so I stopped working on this game for now.
Norton Sysinfo used to work on my specially hacked version of DSx86 back in November of last year, before even the 0.01 alpha version release. I am now trying to make it work in the proper version. The first problem was that it stopped with "Division by zero" when it tried to measure the CPU speed, and I noticed that my improved timer code (which I coded for version 0.01) did not handle the timing method that Sysinfo used properly. I fixed that, but now it crashes DSx86, and I am currently debugging the cause for that. It is not all that surprising that it crashes, as it uses quite an extensive array of tests for various hardware and software on the PC. A good testbench for DSx86 compatibility, in other words. :-)

I haven't started on the mouse emulation yet, and I doubt I'll add that for the next version. My first priority is to get more games running properly and without weird crashes. Perhaps I'll work on the mouse emulation on my Easter vacation. For now, I'll continue adding the missing DOS features and fixing other problems in the debug logs I have received.

This weekend I worked on the various unsupported DOS interrupts that I have noticed on the debug logs I have been receiving. So far I have added about half of the dozen or so unsupported DOS features on my TODO list. During the past week I debugged some games that behaved strangely in DSx86, and found and fixed several bugs in the code while doing this:

Moraff's World just quit back to DOS immediately when trying to run it in DSx86. This was caused by a bug in my memory reallocation code. It should have returned the largest available block if a program requested more memory than was available, but it returned the requested amount. Fixing that problem allowed the game to start.

Simcity demo quit with "Division by zero" when it tried to load the San Francisco map. This was caused by a bug in my unsigned div opcode handling. I used the ARM 32bit/32bit division feature, which gave a wrong result if the numerator was >= 0x80000000. I switched to using int64/int32 division for this situation, and that fixed the problem in Simcity demo.
Ultima 3 seemed to hang at the start. I added a new debug feature into DSx86 where it shows all the called interrupt functions when running with the debugger screen visible. Here I noticed that it tries to open a file using the (nearly obsolete) DOS 1.0 File Control Block functions. I had coded that function to simply return error, but Ultima 3 did not expect an error return. I added the basic FCB functions (open, close, read, write) using FreeDOS sources as a reference. FreeDOS handles those functions by wrapping the normal DOS file functions, so I did it similarly. This means that calling these FCB DOS functions in DSx86 is rather inefficient, as they are wrappers over the normal DOS file functions, which in turn are wrappers over the C standard stdio file functions, which are wrappers over the functions provided by LibFAT. Anyways, after adding these functions Ultima 3 seems to run properly.

Electranoid crashed DSx86 completely. I still don't know what exactly it did that caused a total crash (where NO$GBA shows a popup "The rom-image has crashed"), however I noticed that it used the DOS internal SYSVARS - GET LIST OF LISTS call that returns a pointer to DOS internal data area (but which did nothing in DSx86). The game tried to use the pointer to the start of the allocated memory block chain, and went to random locations in the memory when this pointer did not contain any valid data. I added support for this call (though many of the other pointers are still marked as invalid) and the game stopped crashing, but then it reported "Critical error - Out of EMM memory." I tried adding the amount of EMS memory DSx86 reports, which just changed the error message to "Critical error - No Microsoft compatible mouse found", so I stopped working on this game for now.
Norton Sysinfo used to work on my specially hacked version of DSx86 back in November of last year, before even the 0.01 alpha version release. I am now trying to make it work in the proper version. The first problem was that it stopped with "Division by zero" when it tried to measure the CPU speed, and I noticed that my improved timer code (which I coded for version 0.01) did not handle the timing method that Sysinfo used properly. I fixed that, but now it crashes DSx86, and I am currently debugging the cause for that. It is not all that surprising that it crashes, as it uses quite an extensive array of tests for various hardware and software on the PC. A good testbench for DSx86 compatibility, in other words. :-)

I haven't started on the mouse emulation yet, and I doubt I'll add that for the next version. My first priority is to get more games running properly and without weird crashes. Perhaps I'll work on the mouse emulation on my Easter vacation. For now, I'll continue adding the missing DOS features and fixing other problems in the debug logs I have received.