DSX86 News - Dos Emulator for DS - Slow DS2x86 progress

Pate has posted more news of his Dos Emulator for DS

Last week was a very busy week at the office (first customer deployment of the software I have been working on), so I did not have much time (nor strength) to work on DS2x86 during the evenings. Yesterday I then worked on DS2x86 again, and in the end got it to compile and link. I had to comment out a lot of code, though, which I then need to write specifically for the DSTwo hardware environment.

I have run into various problems while trying to make the code build, so progress has been rather slow. Here is a list of various annoyances and other obstacles I have had to overcome.

One big annoyance is the fact that every test build needs to be tested on the actual hardware. The DS2 SDK is quite a lot bigger than libNDS, and DS2x86.plg is already over 1.5 megabytes in size (while the current DSx86.nds file is around 0.7MB). Transferring a new build to my DS Lite using FTP takes almost 5 minutes, and it is really annoying to wait for the transfer to finish. I could keep swapping SD card between the DSTwo and the PC USB adapter, but I don't want to kill the mechanical contacts with too much use.
Another annoyance is the unaligned access exception. There is an exception handler in the DS2 SDK, but it does not seem to do anything useful, the code just hangs whenever there is an unaligned memory access. These are easy to avoid in my ASM code (as it assumes everything is unaligned), but I have seen several cases where the compiled C code causes an unaligned memory access and hang.
My Makefile skills are pretty rusty, and the Makefile that comes with the SDK is very basic. Thanks to an idea by another SDK user I was able to enhance the Makefile to be able to include binary data (as there is quite a lot of included binary data in DSx86), but this also resulted in unaligned memory access whenever the bin file size was not divisible by four. Looks like the mipsel-linux-as puts the 32-bit size value immediately after the actual binary data, with no regard to alignment! I had to pad all my binary files because of this.
The default Makefile also does not handle dependencies properly. When a header file changes it does not compile all the C or C++ files that include that header file. I changed the makefile to use Advanced Auto-Dependency Generation and that finally seemed to fix the compilation problems. Before that I fought many times with weird compilation or linking problems, as I had not realized it did not compile everything it should have.
While working on making the code build, I have also tried to study the hardware more closely. If the processor in the DSTwo is not exactly Ingenic Jz4732, it is something very similar to that. I found a nice overview about coding for the Dingoo A-320, which among other things has a header file with all the processor I/O address definitions. I have found out that the processor in DSTwo only seems to have 6 timers instead of 8. The timers that the SDK makes available are timers 4 and 5, and timer 0 is in use for some internal stuff. That leaves timers 1..3 free for software use. DSx86 needs several timers, so that was a useful find.

Anyways, I have now managed to output the boot strings (using the 6x8 pixel text font) onto the screen, but the screen update system in DSTwo SDK is still somewhat unclear to me. It uses double-buffering, but I don't need (nor want) to use double-buffering in text modes, so I am currently looking into ways to bypass the double-buffering scheme and be able to only update one buffer. The SDK does not include sources for the more hardware-specific stuff, so I have to look into the dump file to see what the internal routines do. All in all, quite slow progress, but at least I am getting forward.

http://dsx86.patrickaalto.com/DSblog.html