This is the first 'proper' release of my Rubik's Cube game for the DS. Although it is currently a little way from completion, it is intended to be a fairly fully-featured Rubik's Cube simulator with saving and loading, scrambling, painting and solving features. You can download the rom here.

Working as of this release:
* Saving and loading
* Scrambling
* Palette editing
* Painting

Still to do:
* Step-through solving
* Background decoration (colours, wallpapers)

Any and all feedback is appreciated, and for those interested, the full source can be found here

Cheers,
Mark.

Firstly, in case you haven't noticed this yet, DSx86 now has a Compatibility WIKI page where each of you can mark games that work or don't work on the current DSx86 version. Special thanks to Master_Thief for setting up that wiki page and for testing the majority of games on it! With the wiki in place there is no need for you to report working games to me any more. :-) Please send me bug reports about games that don't work, though, especially with a debug log if applicable, so that I can attempt to fix the problems before releasing the next version.

The past week was mainly spent fixing various bugs in the emulation code. I also added several missing (mainly graphics) opcodes that have been mentioned in the debug logs I have received, thanks again for those! The biggest (and scariest) change was that I rewrote the IRQ handling (again!) to fix a problem that was revealed by a game called Galactix.


The problem in Galactix was that it usually only played the first note of the game music, and then later it would hang at a random time during the intro. I had noticed that when it did hang, it was always running a tight loop that checked whether a certain memory location had a zero. It obviously expected this memory location to change value (based on a timer, most likely), but when it had hung the memory location value never changed. After some debugging and tracing the memory access I got a pretty clear understanding of the timer handling behaviour of Galactix, and after some thought I suddenly got an idea (or rather a theory) about what might be wrong in DSx86.

Galactix uses a "Task Service Manager" (that is part of an error string very close to the memory location it checked, so I believe that is the name of the utility code that handles the timer interrupt in the game) which works by incrementing a variable every time a timer interrupt occurs, and then calling various functions in a function pointer table, each of which have their own incrementing variables, with adders that are not always one. For example, one of the functions might only get called every tenth timer interrupt. Now, the main timer interrupt increments the overall timer interrupt counter at the very start of the timer interrupt, and then each of these functions test if their counters are equal to the global counter value, and if they are, this functions get called and gets it's counter incremented by the adder value, to be ready for the next call etc.

Every time I use something similar in my own code, I have a habit of checking whether the counter value is equal or larger than the value I am waiting for, just to be sure I don't miss a timer increment. This then brings us to my theory, I thought that perhaps some of those functions take such a long time to run that a new timer interrupt happens and starts again running the timer code, first incrementing the global counter. In this situation it would be possible for the functions to miss their next timer tick, and stay waiting for it for the next (almost) 65536 timer ticks.

I decided to implement a new feature to the DSx86 debugger with which you can change the byte in the memory using a syntax E AAAA:BBBB CC where AAAA:BBBB is the segment and offset of the byte and CC is the new byte value. I used this new debugger feature to change the JE opcode to JAE opcode in Galactix, and indeed, after this change the music played fine and the intro did not crash. (Well, not immediately, it crashed after a couple of loops, but that was not unexpected as the IRQ handlers are not meant to be re-entrant.) This test did prove my theory that I did not handle the "End-Of-Interrupt" command properly, but instead allow new interrupts to re-enter the interrupt routine.

So, I spent some time implementing proper IRQ handling to avoid this situation in the DSx86 IRQ code, and I also (finally) moved all the interrupt-related stuff to a new source code file. Now it is not scattered around the emulator code but in a single place, so if I still need to make changes to it, it will be easier (and not as scary!). After this rewritten IRQ handling Galactix looks to be running fine.

I also fixed the graphics problems in Catacomb Abyss. I had not implemented the split screen handling in the EGA modes, only in the Mode-X graphics modes, and Catacomb Abyss wanted to use a split screen for the low part of the screen. I also found a problem in the EGA Write Mode 2 handling with 16-bit opcodes. After these fixes Catacomb Abyss began to look correct. Also, the LOADFIX command I added into the previous version only worked with EXE programs (silly me), which is why it did not help with Ultima 4, for example. I implemented it also for COM programs and now Ultima 4 goes to the actual game properly.


Finally, I managed to fix the problems preventing the Sysinfo program from Norton Utilities 8.0 to start. I had used Sysinfo 5.0 in my own tests, which did not need some of the additional