wraggster
January 17th, 2011, 21:07
News via http://dsx86.patrickaalto.com/DSblog.html
For the past week I have been adding the protected mode opcodes for the games I have been using for my tests. The current status of the test games is as follows:
Zone 66 is still on hold, waiting for my implementation of the Virtual 8086 mode.
Jazz Jackrabbit is also on hold, waiting for some improvements to the protected mode segment handling and then for the addition of proper General Protection Fault handling. This is a bit bigger issue so I have not worked on Jazz Jackrabbit any further during the past week.
After putting those two games on hold, I wanted to add a new game to test so that I can hopefully add two different opcodes before testing the new version again. I took Warcraft II as the other game. However, pretty soon I had to put it on hold as well. It turns on the 386 CPU paging system, which is yet another feature that needs a lot of extra work to support. I had thought that only Windows would use the paging (virtual memory) system, but looks like some games do that as well.
Doom is currently progressing fine. It is already in 32-bit protected mode, using the flat memory model, so hopefully it just needs more of the 32-bit opcodes implemented to actually run. Currently it looks very promising, but of course I may encounter something difficult to implement at any moment.
The problem in Doom that I mentioned in the previous blog post, where it jumped to a row of INT 3 opcodes, turned out to be a simple issue. I had forgotten to remove an instruction pointer masking (to a 16-bit value) from one of the jump opcodes I copied from the 16-bit protected mode code, so when Doom attempted to jump to offset 0x00101234 (near the beginning of the extended memory) it jumped to 0x00001234, which happened to have some data containing 0xCC (INT 3) bytes. However, after fixing this issue and adding a few new opcodes, I fought for two days with a problem where Doom suddenly attempted to return from a subroutine to a segment that was not marked executable. Finally after a lot of debugging I found the problem in my LEA opcode handling. I had used the output register as a temporary register in the opcode handler, which was not a smart thing to do when the input and output registers could be the same register! For example, with opcode LEA EBP, [EBP+12], both the input and output register is EBP. I first loaded the immediate byte 0x12 into the output register (EBP), then added the input register (EBP) value to that and finally put the result to the output register (EBP)! After fixing this problem I have been able to add opcode after opcode without any new problems.
Pretty much all of yesterday went to other things besides working on DS2x86. I rearranged the furniture in my appartment, which also meant rerouting all the cabling for my home theater system. That took quite a long time, so I had practically no time left to do any programming. Finally today I have been adding the opcodes that Doom needs, but it keeps encountering new opcodes that I haven't yet implemented for 32-bit protected mode.
That's it for this short update, let's see if I can get Doom actually running by the next weekend!
For the past week I have been adding the protected mode opcodes for the games I have been using for my tests. The current status of the test games is as follows:
Zone 66 is still on hold, waiting for my implementation of the Virtual 8086 mode.
Jazz Jackrabbit is also on hold, waiting for some improvements to the protected mode segment handling and then for the addition of proper General Protection Fault handling. This is a bit bigger issue so I have not worked on Jazz Jackrabbit any further during the past week.
After putting those two games on hold, I wanted to add a new game to test so that I can hopefully add two different opcodes before testing the new version again. I took Warcraft II as the other game. However, pretty soon I had to put it on hold as well. It turns on the 386 CPU paging system, which is yet another feature that needs a lot of extra work to support. I had thought that only Windows would use the paging (virtual memory) system, but looks like some games do that as well.
Doom is currently progressing fine. It is already in 32-bit protected mode, using the flat memory model, so hopefully it just needs more of the 32-bit opcodes implemented to actually run. Currently it looks very promising, but of course I may encounter something difficult to implement at any moment.
The problem in Doom that I mentioned in the previous blog post, where it jumped to a row of INT 3 opcodes, turned out to be a simple issue. I had forgotten to remove an instruction pointer masking (to a 16-bit value) from one of the jump opcodes I copied from the 16-bit protected mode code, so when Doom attempted to jump to offset 0x00101234 (near the beginning of the extended memory) it jumped to 0x00001234, which happened to have some data containing 0xCC (INT 3) bytes. However, after fixing this issue and adding a few new opcodes, I fought for two days with a problem where Doom suddenly attempted to return from a subroutine to a segment that was not marked executable. Finally after a lot of debugging I found the problem in my LEA opcode handling. I had used the output register as a temporary register in the opcode handler, which was not a smart thing to do when the input and output registers could be the same register! For example, with opcode LEA EBP, [EBP+12], both the input and output register is EBP. I first loaded the immediate byte 0x12 into the output register (EBP), then added the input register (EBP) value to that and finally put the result to the output register (EBP)! After fixing this problem I have been able to add opcode after opcode without any new problems.
Pretty much all of yesterday went to other things besides working on DS2x86. I rearranged the furniture in my appartment, which also meant rerouting all the cabling for my home theater system. That took quite a long time, so I had practically no time left to do any programming. Finally today I have been adding the opcodes that Doom needs, but it keeps encountering new opcodes that I haven't yet implemented for 32-bit protected mode.
That's it for this short update, let's see if I can get Doom actually running by the next weekend!