wraggster
September 1st, 2013, 22:21
via http://rpix86.patrickaalto.com/rblog.html
This version does not have that many changes as I have still been focusing on the zerox86 (http://zerox86.patrickaalto.com/) version. Actually I think the biggest change in this version is that I changed the automatic 4DOS.COM download to fetch the program from my web pages, as it seems that the JP Software site is not working properly at the moment. This is just to help new users install and use rpix86.
The only other noteworthy change is that I fixed the garbled graphics problems in the CNC milling software NSW.EXE. The cause of this problem was quite interesting. The game goes to VGA 640x480 16-color mode (for which the BIOS graphics mode byte value is 0x12), but then almost immediately sets the BIOS graphics mode byte to 0x06 using the following code:
1993:00003E63 1E push ds1993:00003E64 33C0 xor ax,ax1993:00003E66 8ED8 mov ds,ax1993:00003E68 BB4904 mov bx,0449 ; DS:BX = 0:0x0449 = BIOS graphics mode byte address1993:00003E6B 8A27 mov ah,[bx] ; Get current BIOS graphics mode byte into AH1993:00003E6D B006 mov al,06 ; AL = 0x06 (CGA 640x200 2-color graphics mode byte)1993:00003E6F 8807 mov [bx],al ; Set current BIOS graphics mode byte from AL1993:00003E71 1F pop dsI have used the BIOS graphics mode byte in a C language switch statement to easily determine which screen blitting function to use, as I have separate functions for each color depth. When the program changed the BIOS graphics mode byte, it made rpix86 switch to using the 2-color screen copy routine, even though the actual graphics mode in use was still the 16-color VGA mode.I fixed this by coding a small hack into the 0x06 case statement, so that it checks also the vertical screen size, and if that is 480 lines, uses the 16-color VGA 640x480 screen copy routine. This seemed to fix all the symptoms, but this is a bit of a nasty hack in the code.
I just got a new project that I need to spend my free time on, so it looks like it will take some more time before I have time to look into the problem games that you have reported. Sorry about that, but sometimes things like this happen. I will get back to improving both rpix86 and zerox86 as soon as I get the other project finished.
This version does not have that many changes as I have still been focusing on the zerox86 (http://zerox86.patrickaalto.com/) version. Actually I think the biggest change in this version is that I changed the automatic 4DOS.COM download to fetch the program from my web pages, as it seems that the JP Software site is not working properly at the moment. This is just to help new users install and use rpix86.
The only other noteworthy change is that I fixed the garbled graphics problems in the CNC milling software NSW.EXE. The cause of this problem was quite interesting. The game goes to VGA 640x480 16-color mode (for which the BIOS graphics mode byte value is 0x12), but then almost immediately sets the BIOS graphics mode byte to 0x06 using the following code:
1993:00003E63 1E push ds1993:00003E64 33C0 xor ax,ax1993:00003E66 8ED8 mov ds,ax1993:00003E68 BB4904 mov bx,0449 ; DS:BX = 0:0x0449 = BIOS graphics mode byte address1993:00003E6B 8A27 mov ah,[bx] ; Get current BIOS graphics mode byte into AH1993:00003E6D B006 mov al,06 ; AL = 0x06 (CGA 640x200 2-color graphics mode byte)1993:00003E6F 8807 mov [bx],al ; Set current BIOS graphics mode byte from AL1993:00003E71 1F pop dsI have used the BIOS graphics mode byte in a C language switch statement to easily determine which screen blitting function to use, as I have separate functions for each color depth. When the program changed the BIOS graphics mode byte, it made rpix86 switch to using the 2-color screen copy routine, even though the actual graphics mode in use was still the 16-color VGA mode.I fixed this by coding a small hack into the 0x06 case statement, so that it checks also the vertical screen size, and if that is 480 lines, uses the 16-color VGA 640x480 screen copy routine. This seemed to fix all the symptoms, but this is a bit of a nasty hack in the code.
I just got a new project that I need to spend my free time on, so it looks like it will take some more time before I have time to look into the problem games that you have reported. Sorry about that, but sometimes things like this happen. I will get back to improving both rpix86 and zerox86 as soon as I get the other project finished.