wraggster
October 10th, 2010, 21:40
Pate has posted more news concerning his Dos Emulator for DS:
This week my work on DS2x86 has been much less frustrating. The DS2x86 framework seems to be mostly working. I still get an occasional black screen when starting DS2x86, but that happens only once in every 20 starts or so. I decided to work on the actual emulation core for now and worry about the hangs later. Early this week I tried to decide on whether to continue porting the existing DSx86 features (like graphics and audio features), or to start working on proper 386 opcodes and protected mode support. I decided to go for the 386 and protected mode direction, as that is much more interesting and lets me study and learn new things.
I decided to start by trying to make my old Trekmo demo from 1994 run. Pretty much like I started with DSx86 by attempting to run my LineWars II game on it, I again use one of my old assembly language programs for testing. Having assembler source code available makes it much simpler to compare the debug output of DS2x86 with the original sources, to see where I am in the code and what is supposed to happen there. My Trekmo demo uses the PMODE DOS protected mode extender created by Thomas "Tran" Pytel. PMODE is small, simple and straightforward, but still supports various methods of entering protected mode (like DPMI, VCPI, and direct custom code). The good thing is that it also works without any memory managers present, so I can immediately concentrate on the low-level protected-mode support without having to worry about virtual memory and things like that. I still haven't coded proper support for the touchscreen keyboard to DS2x86, but that is not a problem as I can put the launch of Trekmo to the 4START.BTM file, so it starts running immediately when I launch DS2x86. It runs until it reaches a yet unsupported 386 opcode, and so I spent the last week iteratively adding new 386 opcodes and running DS2x86 again and again.
I also noticed that adding all the 386 opcodes means quite a lot of work. In addition to the new opcodes (that do not exist at all in a 80186 processor), all the existing opcodes have three new address or size variations. There are two new prefixes, 0x66 and 0x67, the first of which converts the size of the values handled from 16 to 32 bits, and the latter converts memory addresses similarly from 16 to 32 bits. So, with all the combinations there are 4 different cases for almost every existing opcode, and only one of them (with neither prefix) currently exists. The worst case result is that the executable size will more than quadruple after I have added all the new opcodes! A huge amount of work, so I am looking into other ways to handle these. I do need to code some of them using the current method, to get a feel for how they should work and what I can do to optimize the amount of work, though.
Anyways, as you can see from the screen capture above, by this morning I have just reached the location where PMODE.ASM enters protected mode. Entering protected mode means doing four things:
Enabling the A20 address line. This is done by setting bit 1 (with value 2) of I/O port at 0x92, called System Control Port A. This is where I was at yesterday, and I had to do some changes to the memory address calculation routines to be able to directly address memory above the first megabyte in DS2x86.
Setting up the Global Descriptor Table. This is done using the lgdt ASM command.
Setting bit 0 (with value 1) of the CR0 Control Register. This actually puts the processor in protected mode.
Performing a far jump using a CS segment selector (looked up from the GDT we set up before) to clear the prefetch input queue of the processor.
The steps 2 to 4 are seen in the debug output above, and this is where I am currently at. I need to do some major changes to all code that uses segment registers (including all far jumps, calls and returns) to be able to distinguish between real-mode segments and protected-mode segment selectors. This will keep me busy for quite a while, but a good thing is that I can always look at how DOSBox handles these and then copy the features that seem to suit the DS2x86 architecture.
http://dsx86.patrickaalto.com/DSblog.html
This week my work on DS2x86 has been much less frustrating. The DS2x86 framework seems to be mostly working. I still get an occasional black screen when starting DS2x86, but that happens only once in every 20 starts or so. I decided to work on the actual emulation core for now and worry about the hangs later. Early this week I tried to decide on whether to continue porting the existing DSx86 features (like graphics and audio features), or to start working on proper 386 opcodes and protected mode support. I decided to go for the 386 and protected mode direction, as that is much more interesting and lets me study and learn new things.
I decided to start by trying to make my old Trekmo demo from 1994 run. Pretty much like I started with DSx86 by attempting to run my LineWars II game on it, I again use one of my old assembly language programs for testing. Having assembler source code available makes it much simpler to compare the debug output of DS2x86 with the original sources, to see where I am in the code and what is supposed to happen there. My Trekmo demo uses the PMODE DOS protected mode extender created by Thomas "Tran" Pytel. PMODE is small, simple and straightforward, but still supports various methods of entering protected mode (like DPMI, VCPI, and direct custom code). The good thing is that it also works without any memory managers present, so I can immediately concentrate on the low-level protected-mode support without having to worry about virtual memory and things like that. I still haven't coded proper support for the touchscreen keyboard to DS2x86, but that is not a problem as I can put the launch of Trekmo to the 4START.BTM file, so it starts running immediately when I launch DS2x86. It runs until it reaches a yet unsupported 386 opcode, and so I spent the last week iteratively adding new 386 opcodes and running DS2x86 again and again.
I also noticed that adding all the 386 opcodes means quite a lot of work. In addition to the new opcodes (that do not exist at all in a 80186 processor), all the existing opcodes have three new address or size variations. There are two new prefixes, 0x66 and 0x67, the first of which converts the size of the values handled from 16 to 32 bits, and the latter converts memory addresses similarly from 16 to 32 bits. So, with all the combinations there are 4 different cases for almost every existing opcode, and only one of them (with neither prefix) currently exists. The worst case result is that the executable size will more than quadruple after I have added all the new opcodes! A huge amount of work, so I am looking into other ways to handle these. I do need to code some of them using the current method, to get a feel for how they should work and what I can do to optimize the amount of work, though.
Anyways, as you can see from the screen capture above, by this morning I have just reached the location where PMODE.ASM enters protected mode. Entering protected mode means doing four things:
Enabling the A20 address line. This is done by setting bit 1 (with value 2) of I/O port at 0x92, called System Control Port A. This is where I was at yesterday, and I had to do some changes to the memory address calculation routines to be able to directly address memory above the first megabyte in DS2x86.
Setting up the Global Descriptor Table. This is done using the lgdt ASM command.
Setting bit 0 (with value 1) of the CR0 Control Register. This actually puts the processor in protected mode.
Performing a far jump using a CS segment selector (looked up from the GDT we set up before) to clear the prefetch input queue of the processor.
The steps 2 to 4 are seen in the debug output above, and this is where I am currently at. I need to do some major changes to all code that uses segment registers (including all far jumps, calls and returns) to be able to distinguish between real-mode segments and protected-mode segment selectors. This will keep me busy for quite a while, but a good thing is that I can always look at how DOSBox handles these and then copy the features that seem to suit the DS2x86 architecture.
http://dsx86.patrickaalto.com/DSblog.html