DS2x86 progress

August 28th, 2011, 01:50 Posted By: wraggster

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

For the past week I have mostly been working on the virtual memory support in DS2x86. The biggest part of this work has been to convert all the memory access routines (in each of the opcodes) to work with the new 4GB addressable memory. This work has progressed well, and practically all the opcodes have now been converted. The next step was the new InitPage routine which will copy the memory address from the paging-related two-level tree to my linear memory address table. This has also been done, and I have even managed to reach up to the first actual Page Fault exception in the Descent 2 Demo (which I use for my virtual memory tests). I have tested the same game in my debug-version of DOSBox, and luckily DOSBox gets the same Page Fault at the exact same address, so it looks like my code is correct at least up to that point.
When handling the Page Fault, the Descent 2 Demo performs a Task Switch. I had not yet implemented any task switch functionality into DS2x86, so this is what I am currently working on. The task switch routine is somewhat complex, and I have been having some trouble getting it to run properly. I am currently debugging it, so hopefully it will start to behave properly soon.
I also realized that the method I have been using for mapping certain memory locations to EGA or Mode-X RAM is not quite sufficient for virtual memory. When the whole 4GB of RAM is mappable, I can not simply use the sign bit of the 32-bit memory address to tell whether the address is in RAM or in graphics memory. I have an idea for a new system that should be just as fast, but have not had time to implement it yet.

I have also made a couple of small fixes to DS2x86, which will be included in the next release:

1. The swapped screens are reset when a program changes (or you switch to a new configuration which does not have TouchPadMouse active). This feature was missing from DS2x86, as the system had I used in DSx86 for this was not compatible with the DSTwo SDK. I had just commented it out when I originally ported the code from DSx86, and had forgotten about it since.
2. The file rename functionality did not work. This was caused by one of those annoying duplicate symbols in DSTWo SDK. The standard C library has a file rename function int rename (const char *from, const char *to) which I tried to call from my C routine. However, looking at the dump file, I noticed that it actually called a very different "rename" routine, which looked like this:
   80201e88 <rename>:80201e88: 24020fc6 li v0,403880201e8c: 0000000c syscall80201e90: 14e0fffb bnez a3,80201e80 <_IO_sscanf+0x30>80201e94: 00000000 nop80201e98: 03e00008 jr ra80201e9c: 00000000 nopThat is, it first performed some system call with value 4038 (I have no idea what that does), and then jumped to some generic _IO_sscanf() error handling routine if the syscall failed. I went through some of the include headers, and found out that the correct file rename function to call is actually fat_rename, and after I changed my C code to call that the file rename functionality began to work.

There are 0 comments - Join In and Discuss Here