This version has the refactored internals, so it most likely runs some (if not all) games slower than the previous versions. It does however now support practically all real-mode 286 CPU opcodes (not including JPE and JPO which require game-specific hacks), and also unsupported graphics opcodes should now be quite rare. The graphics opcodes are now reported as Unsupported EGA opcode or Unsupported Mode-X opcode, and unlike in previous versions, you can continue after such an opcode using the B button. However, it is likely that you will get the same error again and again, so please send me the log file if you encounter unsupported graphics opcodes. If you get a plain Unsupported opcode error, it most likely means that the program is executing data instead of code, so something has gone wrong in the code before this happened, and thus it is not possible to continue running the program. Again, I am interested in the log files produced in these situations.

Besides the refactored internals, this version has various other fixes, based on many games and other programs I have been testing. Here is a list of the programs I tested, and the changes made into DSx86 or other information about why the program fails to run properly.

Alcatraz, Terminator 2 - Judgment Day, Prehistorik and SimFarm all had various palette problems. I debugged each of these, and noticed that they each failed for different reasons, so in the end I decided to rewrite the 16-color palette handling in DSx86 completely. Now at least those games have correct palettes, so hopefully this change fixes the other games with palette problems as well. The palette handling is still not completely correct, as only the first 64 palette registers are supported in 16-color modes. This is OK for EGA emulation, but some VGA games might use special palette tricks that might still fail.
B.A.T. 2 was freezing. This was caused by the game trying to detect AdLib using Timer 2, while I have only emulated Timer 1 behaviour (and even that one pretty badly). I improved the AdLib timer behaviour, but they still don't work properly. I have run out of Nintendo DS hardware timers, so I need to figure out a way to combine some of the existing timers or use the ARM7 timers from the ARM9 side for some less critical timing operations. In any case B.A.T. 2 now does not freeze, but it seems to run some parts of the intro far too fast. I also found and fixed a problem in the 640x480 mode blitting code when testing B.A.T. 2.
Battle Chess 4000 is reported on the compatibility list as crashing after moving a cursor, however moving the cursor seems to work fine for me, both in D-Pad and touchpad mouse mode. So, I can not debug the possible problem.
The Clue! has been on the compatibility list for a long time, so I finally decided to look into it. I found out that the crash is caused by a bug in the game. The game checks whether the system has an XMS memory driver, and stores the call address of the driver if it has. However, if a driver is not found, it still tries to call the driver, which then causes a null pointer call. I verified this behaviour in DOSBox by making it report no XMS driver, and the game crashed in DOSBox as well. So, this game won't work until I implement XMS memory handling.
Curse of Enchantia hang in 0.21. This was caused by a bug in my refactored CMPSW opcode. I fixed that opcode and Curse of Enchantia began to work properly again.
Darkseed uses an internal flag in it's timer INT8 handler to prohibit re-entrance of the interrupt routine. However, it calls the BIOS INT8 routine with interrupts enabled, so it is possible that the next timer interrupt will happen at this phase, and if it does, the game does not perform an End-Of-Interrupt handling properly. This caused DSx86 to stop sending new timer interrupts, causing the game to hang. I fixed this by turning interrupts off in the BIOS INT8 handler before reporting the End-Of-Interrupt, so a new timer interrupt can not happen until the code has returned from the interrupt handler completely. This seemed to fix the Darkseed hanging problem.
Jazz JackRabbit and Tyrian 2000 began failing with a "At least a 286 processor needed" error in 0.21. I found out that Windows 3.00a only uses one protected mode opcode to differentiate between a 286 and 386 processors, so I implemented that opcode and reverted back to the original 286 CPU behaviour, so these games should now detect a 286 processor again.
Maupiti Island behaves somewhat strangely. Running the maupiti.bat it first runs maupan1.exe, which basically just reserves all memory and then returns with a Terminate-and-Stay-Resident call. However, since it has reserved all memory, there is no room for 4DOS to load itself back from the EMS swap, and thus 4DOS crashes with a memory error. Not running the maupiti.bat but running the start.com directly performs an INT F2 call (which probably would be handled by the TSR program), so it crashes when the TSR program does not exist.