boreland pascal 7 and WinXP

Hi,
I have made a grapical program using 640x480x256 SVGA. This run fine under DOS, WIN95, WIN98 and WINNT. Now I'm using WinXP and the program doesn't work anymore. On one computer this error message is given "NTVDM-CPU found invalid instruction" on an other the program simply hangs. I have been using 2 different VGA drivers, SVGA256.BGI and BGI256.BGI, but both with the same result.
Anyone suggestions?

Thanks

Comments

  • : Hi,
    : I have made a grapical program using 640x480x256 SVGA. This run fine under DOS, WIN95, WIN98 and WINNT. Now I'm using WinXP and the program doesn't work anymore. On one computer this error message is given "NTVDM-CPU found invalid instruction" on an other the program simply hangs. I have been using 2 different VGA drivers, SVGA256.BGI and BGI256.BGI, but both with the same result.
    : Anyone suggestions?
    :
    : Thanks
    :
    :
    Possible solutions:
    - Switch back to WinNT or Win9x. WinXP is known for a poor backward compatibility, especially towards DOS programs.
    - Rewrite your code to be compiled using Delphi. This will make your program completely 32bits and should run fine on all windows version, but sadly not under DOS.
    - Try to use the 640x480x16 mode, although this might not solve the problem at all.
  • : Possible solutions:
    : - Switch back to WinNT or Win9x. WinXP is known for a poor backward compatibility, especially towards DOS programs.
    : - Rewrite your code to be compiled using Delphi. This will make your program completely 32bits and should run fine on all windows version, but sadly not under DOS.
    : - Try to use the 640x480x16 mode, although this might not solve the problem at all.
    :

    Thanks for your reply, but alas none of your possible solutions is really an option. The program must be able to run under all Windows Versions and DOS and I need 256 colors. At this point only XP is a problem. Isn't there an other BGI driver (cause I think that's the problem) that allows me to run in 640x480x256 in XP.
  • : : Possible solutions:
    : : - Switch back to WinNT or Win9x. WinXP is known for a poor backward compatibility, especially towards DOS programs.
    : : - Rewrite your code to be compiled using Delphi. This will make your program completely 32bits and should run fine on all windows version, but sadly not under DOS.
    : : - Try to use the 640x480x16 mode, although this might not solve the problem at all.
    : :
    :
    : Thanks for your reply, but alas none of your possible solutions is really an option. The program must be able to run under all Windows Versions and DOS and I need 256 colors. At this point only XP is a problem. Isn't there an other BGI driver (cause I think that's the problem) that allows me to run in 640x480x256 in XP.
    :

    You could use BP7 for the DOS version and Delphi for the Windows version. It may mean some code changes to make it compilable with both tools, but in the long run I think that is your best option.
  • : Hi,
    : I have made a grapical program using 640x480x256 SVGA. This run fine under DOS, WIN95, WIN98 and WINNT. Now I'm using WinXP and the program doesn't work anymore. On one computer this error message is given "NTVDM-CPU found invalid instruction" on an other the program simply hangs. I have been using 2 different VGA drivers, SVGA256.BGI and BGI256.BGI, but both with the same result.
    : Anyone suggestions?
    :
    : Thanks
    :
    :
    Hi, I had exactly the same troubles. XP hangs completely after calls to Turbo's GetPixel function and PutPixel subroutine, but I found a way to solve this problem. Of coarse, the XP screen looks scrambled when I exit the Command-Box, but I can live with this.
    I use SVGA256.BGI. Writing the following code in the implementation part of a unit which is called AFTER the last unit containing "uses GRAPH" will overwrite the TP7 calls:

    function GetPixel(x,y:longint):word;
    label L10;
    begin
    if x<0 then begin Getpixel := 0; goto L10; end;
    if y<0 then begin Getpixel := 0; goto L10; end;
    if x>MaxX then begin Getpixel := 0; goto L10; end;
    if y>MaxY then begin Getpixel := 0; goto L10; end;
    Getpixel := ($0000 and Graph.Getpixel(x,y)+Graph.GetPixel(x,y));
    L10:;
    end;


    procedure PutPixel(x,y:longint;Colour:byte);
    label L10;
    begin
    if x<0 then goto L10;
    if y<0 then goto L10;
    if x>MaxX then goto L10;
    if y>MaxY then goto L10;
    Graph.PutPixel(x,y,Colour);
    L10:;
    end;

    My GetPixel function calls Graph.GetPixel only for coordinates that are indeed on the screen. The Graph.GetPixel function is called twice, but the value returned from the first call is ANDed with zero. (Wooow :-)

    My PutPixel procedure calls Graph.PutPixel only for coordinates that are indeed on the screen.

    MaxX and MaxY are from GetMaxX and GetMaxY.

    I put only this 2 funcs in my "personal" graphic unit and recompile the unchanged programs. Until now, all my (very) old programs run under XP...
    Good look, Ed
  • : : Hi,
    : : I have made a grapical program using 640x480x256 SVGA. This run fine under DOS, WIN95, WIN98 and WINNT. Now I'm using WinXP and the program doesn't work anymore. On one computer this error message is given "NTVDM-CPU found invalid instruction" on an other the program simply hangs. I have been using 2 different VGA drivers, SVGA256.BGI and BGI256.BGI, but both with the same result.
    : : Anyone suggestions?
    : :
    : : Thanks
    : :
    : :
    : Hi, I had exactly the same troubles. XP hangs completely after calls to Turbo's GetPixel function and PutPixel subroutine, but I found a way to solve this problem. Of coarse, the XP screen looks scrambled when I exit the Command-Box, but I can live with this.
    : I use SVGA256.BGI. Writing the following code in the implementation part of a unit which is called AFTER the last unit containing "uses GRAPH" will overwrite the TP7 calls:
    :
    : function GetPixel(x,y:longint):word;
    : label L10;
    : begin
    : if x<0 then begin Getpixel := 0; goto L10; end;
    : if y<0 then begin Getpixel := 0; goto L10; end;
    : if x>MaxX then begin Getpixel := 0; goto L10; end;
    : if y>MaxY then begin Getpixel := 0; goto L10; end;
    : Getpixel := ($0000 and Graph.Getpixel(x,y)+Graph.GetPixel(x,y));
    : L10:;
    : end;
    :
    :
    : procedure PutPixel(x,y:longint;Colour:byte);
    : label L10;
    : begin
    : if x<0 then goto L10;
    : if y<0 then goto L10;
    : if x>MaxX then goto L10;
    : if y>MaxY then goto L10;
    : Graph.PutPixel(x,y,Colour);
    : L10:;
    : end;
    :
    : My GetPixel function calls Graph.GetPixel only for coordinates that are indeed on the screen. The Graph.GetPixel function is called twice, but the value returned from the first call is ANDed with zero. (Wooow :-)
    :
    : My PutPixel procedure calls Graph.PutPixel only for coordinates that are indeed on the screen.
    :
    : MaxX and MaxY are from GetMaxX and GetMaxY.
    :
    : I put only this 2 funcs in my "personal" graphic unit and recompile the unchanged programs. Until now, all my (very) old programs run under XP...
    : Good look, Ed
    :

    Hi,
    Looks like your funcs works, many thanks Ed, but now I have an other problem. I wrote also a mouse unit years ago, works fine in DOS, Win9x, WinNT, but not in XP :(
    System exits the program and gives an error in windows when executing this function:

    procedure mouse_on;
    var reg:registers;
    begin
    reg.ax:=1;
    intr($33,reg);
    end;

    This is probably not the only procedure in the mouse unit that causes problems, but it's the first the program encounters.
    Anyone suggestions?

    Thanks, Frans


  • Windows XP runs DOS programs inside emulated PC (virtual dos machine, VDM). This makes DOS programs run slower and more unstable. Generally DOS programs can't access any hardware, VDM captures I/O instructions and then passes them to corresponding WDM driver (if any). For example if your PC has good SB Pro card, DOS programs are unable to use it, but they have to use XP's horrible sounding SB 2.0 (8-bit only) emulation.

    When it comes to display modes and video memory access, things get even worse. VDM is able to emulate standard VGA video modes:
    320x200 8-bit, 256 colors
    640x480 4-bit, 16 colors
    These modes work always fine. But when DOS program wants to use higher resolutions and color depths, VDM allows direct access to videocard hardware. Program is able to read hardware BIOS information for example and set VESA(SVGA) display modes, but doing so, causes conflict with XP's own videocard driver and screen comes total garbage.

    However there's a workaround to this, not very good though. Your program can use SVGA modes under XP by using only VESA 1.0 standard (no linear frame buffer) by using only bank-switched modes, where video memory is divided into $FFFF sized segments. The screen will be fine and program running without errors, but when your program quits, the screen will become messed up and system is almost unusable :(
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories