VOGONS


First post, by dvwjr

User metadata
Rank Member
Rank
Member

After spending about three months learning about the initial levels of Intel assembly language as my New Year's resolution - I thought that I would post a patch I wrote for the old DOS SVGA/VESA screen-capture program PCXDUMP which has problems with the faster CPUs of today. It appears that this former shareware program is now abandonware and has had no code updates since the 1996 release of version 9.31 of the program.

The PCXDUMP program requires that the registered name and serial number be input while the DOS clock is set to some date/time in 1996. After that registration action is performed the actual date/time do not matter but the program will then NOT function properly on the faster CPUs of today because of a 'divide overflow' error - but a fairly simple patch can correct the 'divide overflow' error that occurs when the TSR portion of the PCXDUMP program attempts to go resident.

The PCXDUMP author used a home-grown EXE packer to compress his program, so the CODE patch listed below will only function after the program is successfully UNPACKED. Use Google to find the unpack utility CUP386 and use the code fragments listed below to UNPACK version 9.31 of PCXDUMP.EXE so that the patch listed below may be used. Once the PCXDUMP program is patched no further CPU speed increases will cause the same 'divide overflow' failure.

PCXDUMP version 9.31 (abandonware?)

(as an example)
Name: mxxxxxx xx [uCF]
S/N: MDSxxxxxxxxxxxxxx

The PCXDUMP.EXE version 9.31 has a home-grown DOS EXE packer. Can be unpacked with CUP386 version 3.4 which can be found somewhere on the Internet...

To unpack PCXDUMP v9.31 properly with CUP386, the code line "MOV AX, CS" shown below should be the REAL entry point for the program after the in-memory UNPACK. Use this information with CUP386 to UNPACK the PCXDUMP.EXE properly.

0001:B1FD  8C C8                                mov     ax,cs                   ;start Unpack HERE
0001:B1FF 8E D8 mov ds,ax
0001:B201 2E: 8C 06 15CF mov cs:[data_284],es ; (0001:15CF=369Dh)
0001:B206 2E: C7 06 47C7 38D3 mov cs:[data_446],38D3h ; (0001:47C7=0)
0001:B20D 2E: 81 06 47C7 00A0 add cs:[data_446],0A0h ; (0001:47C7=0)
0001:B214 E8 E4C2 call sub_204 ; (96D9)
0001:B217 E8 D723 call sub_180 ; (893D)
0001:B21A E8 DE22 call sub_187 ; (903F) Sub does not return here

Now here is the old PCXDUMP.EXE code which caused the problem:

; OLD CODE:  FILE OFFSET at byte: 0x982C  of the UNPACKED version of PCXDUMP.EXE v 9.31
;**********************************************************************************************************************
; This original code will cause an Intel 'divide overflow' error on FAST CPUs...
0001:914C B8 0000 mov ax,0
0001:914F BA 0000 mov dx,0 ; DX start at ZERO too much for fast CPUs
0001:9152 2E: C7 06 9184 0000 mov cs:[data_588],0 ; (0001:9184=0)
0001:9159 loc_821: ; xref 0001:9166
0001:9159 40 inc ax
0001:915A 3D 0000 cmp ax,0
0001:915D 75 01 jne short loc_822 ; Jump if not equal
0001:915F 42 inc dx ; the DX portion of DX:AX too BIG!
0001:9160 loc_822: ; xref 0001:915D
0001:9160 2E: 83 3E 9184 09 cmp cs:[data_588],9 ; (0001:9184=0)
0001:9166 72 F1 jb loc_821 ; Jump if below
;**********************************************************************************************************************

Code Patch for today's FASTER Intel/AMD CPUs:

; NEW CODE:  FILE OFFSET at byte: 0x982C  of the UNPACKED version of PCXDUMP.EXE v 9.31
;**********************************************************************************************************************
; Below is new Patch to prevent DIVIDE OVERFLOW with a Timer Counter on FAST CPUs...
0001:914C 31 C0 xor ax, ax
0001:914E 31 D2 xor dx, dx
0001:9150 2E A3 9184 mov cs:[data_588], ax
0001:9154 loc_821:
0001:9154 40 inc ax
0001:9155 3D 0000 cmp ax, 0
0001:9158 75 01 jne short loc_822
0001:915A 42 inc dx
0001:915B loc_822:
0001:915B 2E: 83 3E 9184 09 cmp cs:[data_588], 09
0001:9161 72 F1 jb loc_821
0001:9163 81 E2 09C3 and dx, 09C3h ; prevent the DIVIDE OVERFLOW in DX
0001:9167 90 nop
;**********************************************************************************************************************

Hope this helps,

dvwjr

Reply 1 of 3, by gerwin

User metadata
Rank l33t
Rank
l33t

Thanks dvwjr!
I have used pcxdump on every dos game I own, with the right settings it manages to work with all of them (except armoured fist 2). It still runs fine on my pentium III 600MHz. So I was not yet aware of the divide overflow.
how big is the modified exe anyways, posting it as an attachment would make it much easier for me 😉

Reply 2 of 3, by dvwjr

User metadata
Rank Member
Rank
Member

DOS screen-capture programs used to be a necessity before and during the dawn of the age of Windows. Since this website is primarily devoted to those older DOS games - some type of screen capture program or capability is still necessary. The current version of DOSBOX (v0.65) fills those DOS game/application screen and video capture needs quite nicely and I would recommend it in most cases. However, the current SVGA implementations of DOSBOX currently stops at around the 1024x768 (VESA mode 0x105) dimensioned video mode. What does one do when trying to grab that rumored and elusive 1600x1200x8bpp screen-shot of say - the 1994 December release of SYSTEM SHOCK? There is also the case of a DOS game only functioning under an real version of MS-DOS on a PC workstation of the proper CPU speed, sound card and video adapter/monitor capable of properly supporting said game, you therefore would need a DOS Terminate-Stay-Resident screen-capture program in order to perform any in-game screen-shots.

Probably the best version of the DOS screen-capture program available was (is) the shareware program named PCXDUMP published by Viper Software. This program saw many release versions during its life - with the last version published and available on the Internet being v9.31 dated September 28th, 1996. The only problem is that support seemed to stop in 1997 - with the unregistered shareware version 9.31 refusing to function after July 1999. Furthermore, as CPUs got faster and faster - a speed dependent timing-loop appeared on PC workstations with CPU speeds in excess of roughly around 1.2 MHz because an error message "divide overflow" from the PC BIOS would appear on the text-mode screen BEFORE the PCXDUMP.EXE was able to install itself in memory as a TSR. So this quite efficient program would no longer be availble to use on today's and tommorrow's much faster CPUs.

The first message in this thread details the steps necessary to decompress and patch the version 9.31 of PCXDUMP.EXE to make it function again - now and for whatever future lifespan it might enjoy. However, since most folks do not wish to undertake patching older DOS programs I decided (against my better judgement) to release an patch update to the last released shareware version 9.31 Zip-file. The details of this patch update are listed below - with the resultant Zip-file version being updated from v9.31 to v9.32 upon its release on this VOGONS PC Forum.

This patched update in NO way 'cracks' the shareware restrictions of the PCXDUMP program. This means that those individuals or corporations who hold a valid license to the PCXDUMP software would be able to use their Registration Name and Number on this 'v9.32' release of PCXDUMP. Everyone else must find their own solution...

Version 9.32  (dvwjr)  June 2006

- Patched version 9.31 to remove the July 1999 Shareware
"too old" date restriction - instead made the drop dead
date a more reasonable date of July 2097.
- Patched version 9.31 to eliminate "divide overflow" error
on PC workstations with CPU speeds around 1.2 MHz+ so
that this bug will not occur at any future CPU speeds.
- Patched version 9.31 date from Sep. 28th, 1996 to Sep. 29th.
- Patched version 9.31 title to: "PCXDUMP 9.32" to reflect the
above patches to allow for recognition of patched version.
- Patched version 9.32 of PCXDUMP.EXE is 76,791 bytes.
- The Shareware requirements for Registration Name and Number
still apply. This is not a 'cracked' version of the Viper
Software product PCXDUMP v9.32, you must supply a valid
Registration Name and Number to active. (Not my problem)
- The other included PCX viewer program: PCXLAB.EXE suffers
from a "Runtime error 202 at 0000:9AA3." fatal error at
startup on faster CPUs. This program was NOT fixed. Use
the Win32 freeware program IRFANVIEW to view/convert the
PCX files generated by PCXDUMP v9.32 to modern formats.
- The PCXDUMP.EXE v 9.32 is virus free in its ZIP-file.

- Do not ask me ONE question about PCXDUMP v9.32 - take it or
leave it AS IS. Not my program or problem. Not ONE question.

With the permission and concurrence of Snover - the VOGONS site owner/hoster I will attach to this message an updated 132kb Zip-file by the name: PCXDP932.ZIP which has the version 9.32 of the PCXDUMP.EXE program as explained above. Given the truism that "No good deed goes unpunished" I reluctantly attach the PCXDP932.ZIP file to this message - subject to any VOGONS restrictions, you are welcome to download the file for whatever use you see fit on ONE condition:

You (that would be YOU) agree to NEVER ask 'dvwjr' (that would be me) ANY questions about PCXDUMP v9.32 - at any time and in any fashion. Period. If you do not agree to these terms then you do not have permission to download the attached Zip-file. Yes, yes - this means the "I'm the center of the Universe" you. If you do not understand this concept in your world-view or language, I am sure that with the kind help of the multi-cultured and multi-lingual moderators of this fine forum - you will be able to understand the high concept of: POUND SAND.

Hope this helps,

dvwjr

Attachments

  • Filename
    pcxdp932.zip
    File size
    131.27 KiB
    Downloads
    3026 downloads
    File comment
    PCXDUMP version 9.32 update
    File license
    Fair use/fair dealing exception

Reply 3 of 3, by gerwin

User metadata
Rank l33t
Rank
l33t

Thanks! Always nice to "update" such a classic old program. you also did something about the date check nag, that's even better. I am still trying to make sence of the lower part of your post....

Not that I have questions about it, I would not dare. 😉