wraggster
January 20th, 2013, 11:45
Pate has posted some new WIP news of his DOS emulator for the Android, whats Dos you ask well its a way of playing old PC games via emulation, damn cool really :)
Heres his newspost:
During the past two weeks I have been working on the Mode-X and EGA graphics mode support. I got Mode-X support working already last weekend. As soon as I got the most common Mode-X graphics mode opcodes implemented, I wanted to see whether Doom would run in ax86. The first problem I ran into with Doom was that it tried to detect the type of the floating point coprocessor. This is part of the DOS4GW initialization routines, so even though Doom itself does not use floating point operations, the DOS extender wanted to detect the FPU type. I have not yet added any floating point support into ax86, so I had to add some hacks to simply bypass those FPU operations that DOS4GW uses. This allowed Doom to progress slightly further.
The next problem was that Doom complained "Not enough available XMS memory", which was a bit weird since I had allocated (or so I thought) 16MB of RAM for XMS emulation. After some debugging it turned out that I had made a silly mistake, I meant to allocate 16MB of memory but I only allocated 16KB of memory for the XMS emulation! No wonder that was not enough for Doom to run. Next I ran into an unsupported protected mode far call opcode. I had not implemented all protected mode opcodes when I ported the 386 features from DS2x86 to the Raiden Legacy core, and this was one of those unimplemented versions. Implementing it was pretty easy, but then I ran into a more difficult problem.
I fought the whole of last Saturday with a weird problem where protected mode SS (stack segment) register got an invalid value. I used both my DS2x86 and DOSBox to help me in checking what the correct value should be, but the problem was that those two did not even call the routine where this invalid SS value problem happened! So, this was obviously some more serious and difficult to find problem in my code. After a considerable amount of backtracking I finally found a routine that does get called, and was then able to follow the program flow and see where the code paths differ. Finally I found the problem. There are five similar opcodes that load both a segment register and a general purpose register simultaneously. These are called LES, LDS, LSS, LFS and LGS. I had separate 16-bit and 32-bit handlers for each of those, but for some peculiar reason the 16-bit LDS handler did not have the protected mode code at all! I don't quite understand how and why I could have skipped implementing that, but at least doing that fixed the problem in Doom.
After fixing that I ran into an architectural problem that was caused by my using statically allocated first megabyte of RAM, but a dynamically allocated XMS memory block. This caused those two memory blocks not to be adjacent, which in turn caused problems in some of my memory handlers. I decided to have all my emulated RAM be dynamically allocated (as there is no proper reason why any of it should be statically allocated), and fixing that let Doom to start up and run the demo games fine!
http://ax86.patrickaalto.com/ablog.html
Heres his newspost:
During the past two weeks I have been working on the Mode-X and EGA graphics mode support. I got Mode-X support working already last weekend. As soon as I got the most common Mode-X graphics mode opcodes implemented, I wanted to see whether Doom would run in ax86. The first problem I ran into with Doom was that it tried to detect the type of the floating point coprocessor. This is part of the DOS4GW initialization routines, so even though Doom itself does not use floating point operations, the DOS extender wanted to detect the FPU type. I have not yet added any floating point support into ax86, so I had to add some hacks to simply bypass those FPU operations that DOS4GW uses. This allowed Doom to progress slightly further.
The next problem was that Doom complained "Not enough available XMS memory", which was a bit weird since I had allocated (or so I thought) 16MB of RAM for XMS emulation. After some debugging it turned out that I had made a silly mistake, I meant to allocate 16MB of memory but I only allocated 16KB of memory for the XMS emulation! No wonder that was not enough for Doom to run. Next I ran into an unsupported protected mode far call opcode. I had not implemented all protected mode opcodes when I ported the 386 features from DS2x86 to the Raiden Legacy core, and this was one of those unimplemented versions. Implementing it was pretty easy, but then I ran into a more difficult problem.
I fought the whole of last Saturday with a weird problem where protected mode SS (stack segment) register got an invalid value. I used both my DS2x86 and DOSBox to help me in checking what the correct value should be, but the problem was that those two did not even call the routine where this invalid SS value problem happened! So, this was obviously some more serious and difficult to find problem in my code. After a considerable amount of backtracking I finally found a routine that does get called, and was then able to follow the program flow and see where the code paths differ. Finally I found the problem. There are five similar opcodes that load both a segment register and a general purpose register simultaneously. These are called LES, LDS, LSS, LFS and LGS. I had separate 16-bit and 32-bit handlers for each of those, but for some peculiar reason the 16-bit LDS handler did not have the protected mode code at all! I don't quite understand how and why I could have skipped implementing that, but at least doing that fixed the problem in Doom.
After fixing that I ran into an architectural problem that was caused by my using statically allocated first megabyte of RAM, but a dynamically allocated XMS memory block. This caused those two memory blocks not to be adjacent, which in turn caused problems in some of my memory handlers. I decided to have all my emulated RAM be dynamically allocated (as there is no proper reason why any of it should be statically allocated), and fixing that let Doom to start up and run the demo games fine!
http://ax86.patrickaalto.com/ablog.html