DSx86 News - Dos Emulator for DS - INT and CGA fixes

DSx86 News - Dos Emulator for DS - INT and CGA fixes

Since my main development PC is somewhat broken, I installed the latest devkitARM on my laptop. I have been using the same old devkitARM version for DSx86 development since I started the project (as I hadn't dared to upgrade in case DSx86 stops working), but I had only a couple of very minor issues when compiling DSx86 with the latest development kit (r27). Also, it seems that the disk access (SD card access, actually) using libFAT is much faster in this version than in the old version I had been using, so the 0.05 version of DSx86 should load games faster than before.

My laptop is quite old and not very ergonomical to work on, so I didn't spend as much time coding DSx86 as I usually do on weekends. I concentrated my efforts on finding a couple of problems in the old Sopwith 1 CGA game. I had noticed that it does not go to graphics mode at all on DSx86, so I debugged it in DOSBox in trying to find out what method it uses to go to graphics mode. Turns out it uses IRET opcode to call the BIOS INT 10h address! I hadn't coded any support for such a weird calling method, I only checked the INT and JMP opcodes to determine if the address is in the reserved area in the BIOS where all the emulated interrupt handlers of DSx86 are.

This problem made me realize that my current method of trapping the interrupt addresses is not very robust, so I changed the method completely, now I use the undocumented opcode 0xD6 (SETALC) as a flag to mark a software interrupt entry. If the CS:IP is between F000:0000 and F000:00FF when this opcode 0xD6 is handled, it means an entry into an emulated software interrupt, else the opcode behaves like SETALC opcode normally does. This method is quite similar to how DOSBox handles the software interrupts, except that DOSBox uses the unassigned modrm bytes of opcode 0xFE to flag software interrupt entries. Having a single-byte opcode as a flag suited the DSx86 architecture better.

After that fix the game went into CGA graphics mode fine, but there was still a problem with a REP MOVSB command it used to draw the land. I noticed it used segment address B900 instead of the CGA graphics memory start address B800 to move the data, and this made me realize that I had a problem in the way I handle the graphics memory addressing. I assumed (stupidly) that the segment register always points to the start of the graphics memory and the actual location is determined solely by the index register (SI, DI or BX). Of course this does not need to be the case, so I had to fix all my CGA memory addressing so that it is based on the correct physical "segment*16+offset" address. I believe I still have this same problem in the other graphics modes besides CGA, so this I need to fix before releasing version 0.05. Anyways, after those fixes Sopwith 1 runs on DSx86, however the game does not seem to have any adjustment for the speed of the PC, so it runs really fast and is pretty much unplayable, same as in DOSBox. I don't think that is much of a problem, though, as there is a Nintendo DS version of the game.

I also went through a couple of the log files I have received from 0.04 (thanks for those!) and fixed the easy issues. I noticed a couple of unsupported graphics opcodes in the logs where I could not determine which graphics mode this happened in, so I need to add a current graphics mode indicator to the log information for the next version. Most of the issues in the latest log files are not fixed yet, though, so this work I'll continue during the next week, while waiting for the new parts to arrive for my development PC.

For more information and downloads, click here!