Virtual PC 2004 or 2007 Video Card Support for DOS programs

Discussion in 'Virtual PC' started by PlanNine, Mar 9, 2007.

  1. PlanNine

    PlanNine Guest

    I have 2 old DOS legacy applications that I'd hoped to move from their old
    computers to modern hardware running XP SP2 by using Virtual PC. These are
    applications which MUST be kept running, there is no money or resources to
    change or update. It's either keep separate computers for them or find a way
    to run them on a virtual machine. But I have 3 concerns:

    1. They use the PharLap 386 DOS Extender

    2. One needs to talk to a hardware key on the parallel port

    3. The BIGGEST problem is they talk directly to the video card and have 21
    supported cards that run at 1024x768 or 1280x1024 (none of which includes any
    S3 chips). They need to run at least at 1024x768 and just 16, 256, or 64K
    colors (8 or 16-bit).

    I can run the applications in MSDOS 6.22 or Windows 98SE in full screen mode
    (ie, without rebooting to DOS mode). The current computers are setup as
    follows:

    Windows 98SE

    4 have Hercules Dynamite 128 PCI cards with the ET6000 chip and 4MB MDRAM.
    Windows 98SE runs an ET6000 driver, the applications run an ET4000
    driver (ET3000 driver is also compatible with the ET6000).

    1 has an ATI Graphics Pro Turbo PCI card with the mach64 chip, ATI RAMDAC
    (not IBM), and 4MB VRAM.
    Windows 98SE runs the mach64 driver, the applications run the VGA
    Wonder + driver (as long as the card has the ATI RAMDAC).


    So I'm hoping the PharLap Extender won't be a problem. What I'm worried
    about is the hardware, especially the video card. I DON'T need 3D, DirectX,
    or Overlay support etc. I just need straight forward 2D support. But I need
    to have virtualization or some support for one of the cards in the
    applications list. S3 was not included in the applications.

    Here is the complete list of supported cards and the maximum resolution:

    Video Card Resolution

    ATI VGA Wonder + 1024x768
    (Runs on ATI Graphics Pro Turbo (mach64 with ATI RAMDAC (not IBM)) )
    ATI Ultra (mach8) 1024x768

    Elsa Alpha 1024x768
    Elsa Spectra 1280x1024

    Genoa SuperVGA HiRes 1024x768
    Genoa SuperVGA 70Hz HiRes 1024x768

    IBM 8514A 1024x768

    Metheus UGA 1104 1024x768
    Metheus UGA 1124 1024x768
    Metheus UGA 1224 1280x1024

    Orchid ProDesigner VGA 1024x768
    Orchid ProDesigner II VGA 1024x768

    Paradise VGA Card 1024x768

    STB VGA Extra/EM 1024x768

    TI TIGA 1024x768
    TI TIGA 1280x1024

    Trident VGA 1024x768

    Toucan VGA 1024x768

    Tseng Labs ET3000 1024x768
    Tseng Labs ET4000 1024x768
    (Both run on ET6000)

    Video-7 VRAM VGA 1024x768
    Video-7 1024i VGA 1024x768


    Is it possible the S3 is compatible with one of the cards in the list, such
    as the IBM 8514A, ATI mach series, or TI TIGA?


    The MS main page for Virtual PC 2007 and 2004 make it sound like the
    perfect answer, except they don't say much about hardware virtualization.
    One of the white papers mentions parallel and serial ports and CDROM drives,
    but that's it. So I go digging through the discussion threads and all I see
    is virtualization for an obscure S3 chip (the Trio). Am I missing something?
    Is there a way to virtualize other video cards? Or is this otherwise great
    software rendered useless by a lack of video card virtualizations? I know
    the application won't be talking to the video card on the new computer, so
    the virtual machine must virtualize the video card that the application wants
    to talk to. If the only video card virtualization that exists is the S3
    Trio, then Virtual PC is virtually worthless for supporting older legacy
    applications. It may work if all you want to do is run a Windows 2000
    application on XP or Vista. But it doesn't help at all for any DOS or early
    Windows 9x applications. And those are the applications that have the most
    need to shift to new systems. The ones still running are typically unique,
    can't be replaced, but have to be kept running.

    Please tell me I'm wrong and that Virtual PC will do what I need and how
    to do it. If not, do you know if VMWare, SVista, or any other virtual
    machine will work for me? And if Virtual PC won't work, someone needs to
    point out right on the main page that the S3 Trio is the only virtualized
    video card or at least put it in the Product Specifications page so everyone
    doesn't go through having their hopes raised, only to be disappointed by this
    huge limitation. Or perhaps someone could consider adding just a few more
    mainstream video card emulations such as the 8514A, ATI mach series, and
    Tseng Labs ET4000 and 6000 (and maybe the VESA 1024 driver)?

    Thanks
     
    PlanNine, Mar 9, 2007
    #1
    1. Advertisements

  2. PlanNine

    PlanNine Guest

    Thanks for the quick reply.

    I haven't tried VPC yet. I saw the posts about video limitations and wanted
    to get some expert opinions so I wasn't just beating my head against the wall
    spending time trying to do something that would never work.

    I guess all I can hope for is that the S3 Trio will be close enough to an
    8514A that it might work. I seem to recall that a lot of early XGA chips
    were basically 8514 clones with non-interlaced 1024x768 modes.

    As for the nVIDIA reference, I don't care what's in the actual host machine.
    I'm only concerned about what video card the virtual machine can provide to
    the guest OS, in my case Windows 98SE (or MSDOS 6.22). If it would help to
    run a dual video card system, I'd do it. Although, the main reason for
    looking at using VPC is to do away with separate PCs AND especially to get
    away from the older hardware which is getting harder to replace. The actual
    supported video cards are getting harder to find even on eBay.

    I'll try to find the right place on the VPC page to leave a suggestion about
    putting the video card limitation right up front, so to speak.

    As for your last comment, I thought I was clear that I already have PCs
    running the applications. What I want to do is reduce the number of PCs and
    phase out the old hard-to-get hardware. Also, from what I've been reading,
    some of the newer motherboards won't run Windows 98SE or DOS natively. So I
    was looking at VPC to work around that. If I can't run 98 on new
    motherboards and VPC can't virtualize a card that will work, then I'll just
    have to try to maintain the current PCs. It's just unfortunate about the
    video limitation. I'm still going to try VPC and at least use the 8514A in
    the application to see what happens and let you know. Do you think it would
    be better to use VPC 2007 or 2004?

    Thanks
     
    PlanNine, Mar 9, 2007
    #2
    1. Advertisements

  3. PlanNine

    Robert Comer Guest

    Hi PlanNine (interesting reference. <g>)

    The problem is that Virtual PC, and all of the other current virtualization
    products that I know of, don't virtualize the hardware except for the CPU,
    they emulate it which is quite a different thing. There just no way to
    emulate another video card without starting from scratch and programming the
    new emulation in. (it might be nice to have plug-in device emulation code,
    but that's not the way they are built now.)

    It's always worth a shot to try you program to see if it can handle the
    video, but I fear that it's not going to be similar enough. There may be
    problems with the parallel key too...

    As for if you should use VPC2004 or 2007, I'd try VPC2007.

    --
    Bob Comer <Microsoft MVP Windows - Virtual Machine>
     
    Robert Comer, Mar 9, 2007
    #3
  4. PlanNine

    Wesley Guest

    PlanNine,

    What is the name of your application? We have a extended DOS Cadd program
    (GCD) running in a VPC Win98se DOS mode window with 1280X1024 graphics.
     
    Wesley, Mar 9, 2007
    #4
  5. PlanNine

    PlanNine Guest

    Hi,

    Actually there are more than 2, but I'm concentrating on the hardest. One
    is proprietary and only supports the Tseng Labs ET4000 and 6000 and the other
    is PADS Perform v6 which supports the 21 cards listed. There are others
    including OrCAD 386 which has more video card support than PADS and even has
    working VESA 1024x768 drivers. OrCAD 386 even works at 1280x1024 on an ATI
    Graphics Pro Turbo mach64GX card in Win98SE and has some S3 support (the 9xx
    series), so I'm not as worried about it.

    Is GCD Generic CADD? Did it have a driver for the S3 Trio or did you find a
    way around it? If so, it could be very helpful.

    I've also been looking into Ronald Phillips suggestion about DOSBox. It
    also officially supports the S3, but one of the supporters has been writing
    additional video card emulations and has working ET3000 and ET4000 emulations
    as well as a Paradise PVGA1. The ET4000 emulation would solve a lot of
    problems. And other contributors have a way to access the parallel port for
    hardware keys. So DOSBox is looking interesting.

    Let me know if you got a non-S3 driver to work.

    Thanks
     
    PlanNine, Mar 9, 2007
    #5
  6. PlanNine

    Wesley Guest

    PlanNine,

    GCD is "Personal Designer" produced by 4D, previously distributed by CV.
    Along with various dedicated graphic adapters (VMI and Pixelworks), it came
    with a VESA driver that is installed by the application making it S3
    compatible. The application runs about 4xs faster in a Win98se VPC then the
    previously dedicated DOS machine.
    The host is a WinXP, 3 GHz P4. While GCD doesn't have the instant screens
    that current CADD programs have, the screen refresh is fast enough. I have a
    lot of custom file management and drafting programs created for the system
    and I am reluctant to switch to a WinXX CADD program for those functions.

    Any application that works with a VESA compatible display adapters, should
    run the emulated S3.

    GCD utilized a security device attached to the parallel port. The VPC can be
    setup to see the host's physical ports. It can also see any USB device that
    can be shared on the net. If you install your app in DOS along with
    "Workgroups for DOS" , you will be able to see and print to any shared device
    on the net. Under Win98, you will need to install Win98 drivers for your
    printers. I have a WinXP tiff printer driver on the host that can not be
    networked with the Win98 VPC, but all of my other printer and plotter drivers
    are OK.

    With VPC, GCD is hardware and OS independent. The great thing is that on one
    workstation, with a 24 inch display, I am able to put up multiple windows
    including the GCD app (1280X1024), other CADD programs, specifications and
    calculators at one time. The GCD VPC communicates with the host via the net
    and I am almost paperless until I plot/print to present or publish. My
    digitized is attached to the host serial port and communicates with GCD. When
    I click the mouse over any window, including GCD, it becomes the active
    application and will take input from the mouse (digitized in the case of GCD)
    and keyboard. The other application run in the back ground finishing whatever
    may be assigned to them.

    My application runs about 1.3xs faster in Win98se "Boot to DOS" VPC window
    then in a DOS VPC window and about 2.5xs faster then the Win98se "command
    DOS" window. In the first example, the network can not see the guest although
    the guest can see the host. In the second and third install, the net is fully
    accessible both ways. Some of the installations run best without the Vmadds
    and in the case of DOS, with the exclusion of some of the Vmadds.
     
    Wesley, Mar 10, 2007
    #6
  7. PlanNine

    PlanNine Guest

    Thanks for the information. I don't recall the GCD cad program you're
    using, but you are lucky for it to have a VESA application driver. And since
    it works, that means the emulated S3 Trio in Virtual PC must have a VESA
    hardware driver included in the emulation. And that is good to know. Of the
    3 applications I mentioned, only OrCAD has VESA drivers and the highest
    resolution one goes up to 1024x768, which is fine. The problem is that the
    other 2 applications don't have VESA drivers.

    The VESA drivers tried to do for DOS what the Windows and OS/2 OSes do for
    reducing the video driver work for applications developers. The idea was
    that the application could write a single VESA driver using calls to the
    "standard VESA API". Then the video card manufacturer could write a single
    low level VESA driver to be shipped with the card which provided the APIs
    which took care of things from the API level down to the hardware. Both
    sides only have to write 1 driver and everybody's happy. Except most apps
    still had to provide all the other direct-to-video-card video drivers for
    various reasons. And then OS/2 and Windows came along and so a lot of
    developers never got around to doing the VESA drivers or getting them
    debugged.

    So, some apps provided the application side VESA driver, some don't. You
    were lucky with GCD. I'm lucky with OrCAD, not so lucky with the others. At
    one time, I used the OrCAD VESA 1024x768 driver to run OrCAD in OS/2 v3 and 4
    on the ATI Graphics Pro Turbo mach64GX card. It's good to know that the VPC
    S3 emulation provides VESA support.

    It's interesting about the different speeds for the different virtual
    machines in terms of DOS versus DOS in Win98. I remember when I moved PADS
    from native MSDOS v6.22 to a DOS Full Screen in Win98SE, the printing speed
    increased dramatically. That's how all the apps are currently running, in a
    DOS full screen in Win98SE (not rebooting to DOS mode) and the speed is fine
    on a 500MHz machine.

    And thanks for the information on the parallel port. That was another
    concern. Now I know I'll be able to get the apps to see the hardware keys.
    Was there anything tricky or obscure about the VPC settings needed?

    By the way, did GCD use the PharLap 386 DOS extender or a different one
    and did you have to do anything special to get it running? I'm assuming I'll
    just be able to use the same config.sys and autoexec.bat settings as in the
    native setup.

    Thanks
     
    PlanNine, Mar 10, 2007
    #7
  8. PlanNine

    PlanNine Guest

    Hi,

    I'm suprised it was available, being such a classic. Sorry for mixing the
    terminology, but at least you got the idea. I understand you would have to
    write each emulation since each video chip had anywhere from some to a lot of
    different registers beyond the VGA set. But it would seem to make sense if
    the VPC team had added just 1 or 2 cards per year you could've had the 5 or 6
    most common video card families by now, which would make VPC more usable to a
    LOT more people. Having just 1 video card emulation is so limiting.

    The better option, which is the easiest for the VPC team, is to provide a
    way for outside contributors to add video card emulations. Of course, they
    would be unsupported by MS, but all you would have to do is provide links to
    the contributors and say "You're on your own with these". Before you laugh,
    that is exactly what is done with DOSBox which is an open source virtual
    machine. DOSBox officially supports the S3 only, but one of the supporters
    has been writing additional video card emulations and has working ET3000 and
    ET4000 emulations as well as a Paradise PVGA1. The ET4000 emulation would
    solve a lot of problems for me obviously. And other contributors have
    provided a way to access the parallel port for hardware keys. So DOSBox is
    looking interesting to me because of the ET4000 addon from an outside source
    and the parallel port support also from an outside source. (Thanks to Ronald
    Phillips in previous post).

    In another post, Wesley pointed out 3 things that worked for him:

    1. He has a DOS Extended application running in a VPC Win98SE guest on a
    WinXP host and it's 4 times faster than when run natively in DOS
    2. The application included a VESA driver and he's using it to run at
    1280x1024
    3. The application uses a parallel port hardware key and he was able to set
    VPC to use the host's physical port.

    So, is it looks like:

    1. DOS extenders aren't generally a problem
    2. The S3 Trio emulator includes emulation of the Trio's VESA driver or
    utility, which makes VPC's video compatible with any application that has
    either the S3 Trio driver OR the VESA driver. That's a BIG plus. You should
    be sure to point this out. It opens up VPC to a lot more applications.
    3. Directly accessing the parallel port is possible. Or at least there's
    enough access to let a hardware key work.


    I'm still going to try VPC 2007 with the 8514A selection in my
    applications and let you know what happens since my apps don't have a VESA
    driver (except for 1). But if that doesn't work, then it looks like I'll
    have to try DOSBox. I'm sure it won't be as easy to set up, but that ET4000
    emulation is hard to resist.

    Please pass along the suggestion to the VPC team to open up VPC's video
    emulation to 3rd party contributors. If DOSBox can do it, it seems there's
    no reason for VPC not to.

    Thanks


    P.S. It looks like SciTech has thrown in the towel and their SNAP Graphics
    and audio driver source code is up for sale. Perhaps a way to get lots of
    video and audio emulations in VPC for cheap? Just a thought.
     
    PlanNine, Mar 10, 2007
    #8
  9. PlanNine

    Robert Comer Guest

    I agree, it would be nice, and I will pass the suggestions along.
     
    Robert Comer, Mar 10, 2007
    #9
  10. PlanNine

    Robert Comer Guest

    I don't know about that, there seems to be more and more requests for
    support of specialized hardware and software in a virtualized environment...
     
    Robert Comer, Mar 10, 2007
    #10
  11. PlanNine

    Plan9 Guest

    Hi Mark,

    I think you misinterpreted my earlier request:

    "The better option, which is the easiest for the VPC team, is to provide a
    way for outside contributors to add video card emulations. Of course, they
    would be unsupported by MS, but all you would have to do is provide links to
    the contributors and say "You're on your own with these". Before you laugh,
    that is exactly what is done with DOSBox which is an open source virtual
    machine. DOSBox officially supports the S3 only, but one of the supporters
    has been writing additional video card emulations and has working ET3000 and
    ET4000 emulations as well as a Paradise PVGA1. The ET4000 emulation would
    solve a lot of problems for me obviously. And other contributors have
    provided a way to access the parallel port for hardware keys. So DOSBox is
    looking interesting to me because of the ET4000 addon from an outside source
    and the parallel port support also from an outside source. (Thanks to Ronald
    Phillips in previous post).

    Please pass along the suggestion to the VPC team to open up VPC's video
    emulation to 3rd party contributors. If DOSBox can do it, it seems there's
    no reason for VPC not to."

    MS would change VPC to provide hooks for adding video emulators and
    provide some documentation. Then MS is done. There is no involvement by
    hardware companies. The point here is to be able to provide emulation for
    hardware long out of production. Users who have some background in writing
    video drivers would write the emulators for themselves and others. And don't
    laugh, that is exactly what has happened with DOSBox as I pointed out above.
    DOSBox officially supports the S3 Trio64 and VESA. But a user has written
    emulators for the Tseng ET3000 and ET4000 and the Paradise PVGA1. No
    hardware vendor was involved.

    The point is: open up VPC enough that the user community can add to it
    where it has limitations, such as video support. Look at how many of the
    posts keep asking about video support or video limitations. Users are doing
    it for DOSBox, why not VPC?

    Thanks


    P.S. Read Wesley's second post concerning USB and Parallel support:
    "It [VPC] can also see any USB device that can be shared on the net".
    I would take that to mean printers and flash drives at the least.
     
    Plan9, Mar 10, 2007
    #11
  12. PlanNine

    Robert Comer Guest

    So do you think there would be a market for a version of Virtual PC which
    Yes, I do think there's a market for that, look at any other healthy
    software line and you'll probably find they have plug ins of some kind for
    extensions. This just takes that idea to the VM. (and nobody else but
    DOSBOX has it yet..)
    There's nothing in it for hardware vendors, only software people...
     
    Robert Comer, Mar 10, 2007
    #12
  13. PlanNine

    Robert Comer Guest

    I will.
     
    Robert Comer, Mar 10, 2007
    #13
  14. PlanNine

    Wesley Guest

    PlanNine,

    Activating the VPC's ports is done via its menu under edit settings where
    you simply assign the port to the VPC. If you have a printer attached to it,
    I would guess that you can access from the net as as a shared device
    connected to the guest. I have never tried that.

    GCD is compiled with the PharLap 386 DOS extender. In order to get some of
    its screens to run in a Win98 VPC "command window", I had to disable some of
    the windows special keys by editing the pif. While this may not be an issue
    for you, I encourage you not to assume that the way you did things in a
    physical machine will be the same for a VPC. While they are functionally the
    same, the additional interfaces occasionally require a unbiased mind to see
    the best approach. After I got up and running in a Win98se "boot to dos
    mode", it took another 5 months to get around to editing the pifs so that
    GCD's command line would function in a Win98se "command window". I still
    think however that the best GCD speed / network access combo for GCD will be
    via a DOS VPC. Because my system is a production system, I do not have a lot
    of free time and it may be a while before I get around to tewaking a DOS VPC.
    I do not recall having to change my autoexec and config files to get GCD
    running but did so later.

    I have seen drivers that claims to make most display adapters VESA compliant
    but that doesn't seem to apply to your situation regarding VPCs. Except as a
    user, the subject of drivers is a black, not gray area for me. It is my
    understanding that MS selected the S3 because it had the greatest degree of
    compatibility with video cards in general. I would give it a try.

    We use CADD to model buildings and produce working drawings, what do you do
    with your systems ?
     
    Wesley, Mar 11, 2007
    #14
  15. PlanNine

    Plan9 Guest

    Hi Wesley,

    Thanks for the good information. Now I know the PharLap 386 DOS Extender
    will work, though I understand I may have to make adjustments in its or the
    application's settings or in config.sys. I still have documentation on them
    so I think I can get that part going.

    The parallel port setup you described seems straight forward. I always
    keep the key on a separate LPT from the printer and PADS will only print to
    the LPT ports. So the VM is going to have to give real access to the hosts
    LPT1 and LPT2. I tried a suggestion from HP one time on how to trick some
    DOS programs into printing over the network when they only support LPT ports
    and write directly to them. When you create the Standard TCP/IP port for the
    printer, you give the port the name of an LPT port such as LPT2. I tried
    LPT1-4, but PADS would never work except on a real LPT. HP did say it only
    works with some programs. But there are ways to make a file and then print
    it in the Windows XP host. I'm really only concerned about the application
    getting access to the hardware key. If it can, then that hurdle is overcome.
    But printing on the real parallel port would be nice.

    Yes, I need a driver that makes the DOS application "VESA compliant"
    rather than the display adapter. In other words, I need a driver which
    intercepts the application's video accesses to the selected/supported video
    card (ET4000 for example) and translates them to VESA API calls. It has to
    work on the application side. Then the drivers VESA API calls to the OS/VM
    would be acceptable to most of the VMs since most of them seem to emulate the
    VESA standard. I imagine it would be difficult to write a driver that does
    that, but I haven't written video drivers so I'm not sure. But then not all
    of a chips video modes would have to be supported. If the application
    doesn't use it, you could ignore 32-bit color modes for example. Or you
    could choose to only support 1024x768 8-bit 256 color and 16-bit 64K color
    and ignore 800x600 and 1280x1024, etc. Even MS's S3 Trio emulation leaves
    out the 24-bit 16M color modes because they are slower than 16-bit and 32-bit
    color modes.

    Someone gave me a tip that the Window 3.1 SVGA driver (SVGA.EXE containing
    SVGA256.DRV and SVGA256.3GR) supports several video cards at 1024x768 256
    color, including the ET4000. And someone wrote a program to patch the .DRV
    file to make the driver VESA compliant. If they mean the back-end that talks
    to the video card, then it could be very useful. If they mean the front-end
    that talks to the application, I'm left with the same problem and it doesn't
    help me.

    In trying to evaluate the available virtual machines that support my host
    and guest OSes (WinXP and Win98SE (full screen mode) or MSDOS 6.22), I've
    made the following table of video emulation support:


    VM Program Video Cards Emulated User Contributed Video Emulation

    Bochs VESA VBE, Cirrus Logic SVGA
    CL-GD5430 ISA with 2MB VRAM
    CL-GD5446 PCI with 4MB VRAM

    DOSBox S3 Trio64, VESA 2.0 Tseng Labs ET3000, ET4000,
    Paradise PVGA1A

    Parallels Workstation VESA 3.0

    QEMU VESA VBE,
    Cirrus Logic CLGD5446 PCI

    SVISTA VESA 3.0

    VirtualBox VESA
    Custom Graphics Driver in
    Guest Additions (Windows+Linux)

    VirtualPC 2007 S3 Trio32/64, VESA

    VMware Workstation VESA 2.0


    VBE = VESA BIOS Extension


    They all seem to support VESA and some support either the S3 Trio64 or the
    Cirrus Logic CL-GD5446. DOSBox is the only one which supports the Tseng Labs
    ET4000 (via an addon), which all of my apps have drivers for. But being open
    source, the documentation is thin and I'm sure it will be the hardest to
    install and get running. And I'm not sure if it will support the PharLap 386
    Extender properly. Whereas the 4 main commercial programs (VPC, VMware
    Workstation, Parallels Workstation, and VirtualBox) have good documentation
    and good installation programs to get running quickly and easily. But only
    one of my applications has a VESA driver, so I'm trying to decide which VM to
    tackle first. I know VPC will run the PharLap 386 Extended apps. Then I
    also have to worry about the parallel port hardware key. I now have feedback
    that DOSBox (with an addon and PortTalk driver) and VPC will support it and
    most of the others indicate some sort of parallel port support in the
    documentation. I've collected information and programs and will soon have
    time to try them out.

    Most of my applications are involved in electronic design: circuit design,
    PCB design, etc., so that a PCB can be made and the circuit assembled.


    Thanks again for all the help,
    Plan9
     
    Plan9, Mar 12, 2007
    #15
  16. PlanNine

    Plan9 Guest

    The table in the previous post got messed up, so here it is again:

    In trying to evaluate the available virtual machines that support my host
    and guest OSes (WinXP and Win98SE (full screen mode) or MSDOS 6.22), I've
    made the following table of video emulation support:


    VM Program -----------> Video Cards Emulated ---------> User Contributed
    Video

    Emulation

    Bochs ----------------> VESA VBE, Cirrus Logic SVGA
    + _ _ _ _ _ _ _ _ _ _ + CL-GD5430 ISA with 2MB VRAM
    + _ _ _ _ _ _ _ _ _ _ + CL-GD5446 PCI with 4MB VRAM

    DOSBox ---------------> S3 Trio64, VESA 2.0 ----------> Tseng Labs ET3000,
    ET4000,
    + _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + Paradise PVGA1A

    Parallels Workstation > VESA 3.0

    QEMU -----------------> VESA VBE,
    + _ _ _ _ _ _ _ _ _ _ + Cirrus Logic CLGD5446 PCI

    SVISTA ---------------> VESA 3.0

    VirtualBox -----------> VESA
    + _ _ _ _ _ _ _ _ _ _ + Custom Graphics Driver in
    + _ _ _ _ _ _ _ _ _ _ + Guest Additions (Windows+Linux)

    VirtualPC 2007 -------> S3 Trio32/64, VESA

    VMware Workstation 6.0 > VESA 2.0


    VBE = VESA BIOS Extension

    Plan9
     
    Plan9, Mar 12, 2007
    #16
  17. PlanNine

    Plan9 Guest

    This is an update detailing what I've tried and what worked, 4 Cases in
    order of worst to best:


    Target Application: PADS Perform DOS v6.0.1
    Original OS: DOS
    Challenges:
    1. Uses Phar Lap 386|DOS-Extender v5.1,
    2. Uses -REALBREAK command-line switch so it needs DPMI v1.0 host with
    Map Conventional Memory in Memory Block function (INT31h AX=0509h),
    3. Supports 21 different video cards at 1024x768 or 1280x1024, BUT NO S3
    cards
    or VESA selections,
    4. Uses a parallel port hardware key.

    Numbers 2 and 3 are the biggest problems by far.



    *** Win XP SP2 Retail, native ***

    Main Problem: Lack of DPMI v1.0 host with Map Conventional Memory in
    Memory Block function (INT31h AX=0509h)

    I tried to get PADS Perform to run in Win XP SP2 without a VM, but there is
    one incompatibility with the Phar Lap 386|DOS-Extender (later called TNT
    DOS-Extender) involving DPMI v0.9 versus DPMI v1.0 support. PADS Perform
    used an Extender or DPMI option called the -REALBREAK command-line switch.
    This requires a DPMI v1.0 host which provides the Map Conventional Memory in
    Memory Block function (INT31h AX=0509h). But MS only provides support for
    DPMI v0.9 with EMM386.EXE or later, DOSX.EXE (HIMEM.SYS is the XMS host).
    DPMI v0.9 doesn't support INT31h AX=0509h.

    The purpose of the -REALBREAK switch is to request that some of the code and
    data be placed in conventional memory. One of the things this allows is to
    mix Real-mode and Protected-mode code.

    There appears to be 2 reasons to use -REALBREAK to load some of the
    application in conventional memory:

    1. Having some of the application in conventional memory can apparently
    improve the performance for some programs.

    2. Mixing Real-mode and Protected-mode code. Apparently Real-mode code can
    be mixed with Protected-mode code if the Real-mode code and data are 64K or
    less and they are loaded in conventional memory.

    If the reason is number 1, then the program will work in the NT series by
    using "-REALBREAK 0" which tells the Extender to load 0KB in conventional
    memory. I believe Autodesk's 3D Studio Release 4 falls into this category
    since people have reported that this makes it work in Win 2000 and XP,
    although the performance is cut in half. (If the DOS-Extender is bound with
    the application to have only one .EXE, use CFIG386.EXE to change the
    -REALBREAK switch, ex. "CFIG386.EXE 3DS.EXE -realbreak 0". If using a
    separate loader such as TNT.EXE, use "TNT.EXE -REALBREAK 0 Program.EXE").

    If the reason is number 2, then you're screwed. Period. The application
    will never run in the NT series. It appears PADS Perform falls into this
    category.

    The -REALBREAK switch is the worst way to load mixed code together. There
    are two other ways to deal with loading mixed code mentioned by Phar Lap.
    The preferred way is to use the realcopy() function shown in DOX-Extender's
    MDRAW sample program. "Using realcopy() avoids any potential compatibility
    problems with -REALBREAK.". If it were possible to reverse engineer enough
    of PADS Perform to add the realcopy() function and eliminate the need for
    -REALBREAK, then PADS Perform would probably work in the NT series. However,
    that is well beyond my capabilties. As the professors always used to say
    "It's left as an exercise for the student".


    Here's what happens:

    If your program uses the -REALBREAK command-line switch, DOS-Extender will
    refuse to load it unless the DPMI host provides the Map Conventional Memory in
    Memory Block function (INT31h AX=0509h).

    (See Phar Lap -> Ardence -> Citrix Tech Note 43 and 44 and the TNT
    DOS-Extender Reference Manual).

    When PADS Perform is started, the DOS-Extender starts to load and quickly
    displays the following infamous error:

    Phar Lap err 74: Can't use -REALBREAK under this version of DPMI
    Error TNT.20074: Can't use -REALBREAK under this version of DPMI


    With -REALBREAK set to 0, the DOS-Extender loads. PADS Perform starts to
    load, but quickly displays the following error:

    Panic!!!!
    cannot reach real mode vector
    EAX ........ 0000250F
    EBX ........ 00000000
    ECX ........ 00008DC0
    EDX ........ 002D0008
    Exiting ...


    PADS Perform uses the Phar Lap 386|DOS-Extender v5.1 bound into the main
    PADS executable so that there is only one .EXE to run, PPERFORM.EXE. I also
    tried using the TNT DOS-Extenders v7.0 and V8.02, TNT.EXE, as a loader to
    load PADS Perform with "TNT.EXE PPERFORM.EXE" so I would have the features of
    the newer version, in case that provided something more compatible to the Win
    NT series. In fact, I'd always had to use the TNT.EXE loader method just to
    get Perform to run in Win 98SE. PADS didn't provide a PHARLAP.386 VxD, so
    Perform didn't originally run in Win 9x. I had access to the DOS-Extender
    SDK v7 and v8. I tried v7.0 and v8.02 TNT.EXE loaders paired with their
    respective PHARLAP.386 VxD in the SYSTEM.INI file's [386Enh] section and they
    both worked. So I've always used v8.02 to run in 98SE. I tried all these
    variations in Win XP but nothing worked. I tried all combinations of the
    Memory and Compatibility settings in the shortcut used to start the program
    and still nothing worked (EMS must always be None).

    There was never any file from Phar Lap for Win NT that was equivalent to
    PHARLAP.386 for Win 9x.

    I've even tried other DPMI v1.0 hosts such as DPMIONE and HX DOS-Extender.
    HIMEM.SYS must be loaded to give an XMS host. But with or without DOSX.EXE
    loaded, DPMIONE and HX will refuse to load with the following messages:

    DPMIONE:

    The CPU is in Virtual Mode and there's no VCPI host.
    DPMIONE.EXE not installed.

    HX DOS-Extender:

    HDPMI32: CPU is in V86 mode, but no VCPI/DPMI host detected.

    These are similar to Phar Lap error 35 that results from loading
    DOS-Extender without loading DOSX.EXE:

    Error TNT.20035: The 386 chip is currently executing in virtual 8086 mode
    under
    the control of another program. You must turn off this
    other
    program in order to use TNT DOS-Extender to run in protected
    mode.

    Therefore, I could never get DPMI v1.0 support in Win XP.


    Final Results: The program will not run natively in any Win NT series.



    See next post for results from Virtuel Machines...
     
    Plan9, Jul 18, 2007
    #17
  18. PlanNine

    Plan9 Guest

    Continued from previous post:

    (The previous post covered the attempt to run in Win XP SP2 natively,
    without a Virtual Machine).


    This is an update detailing what I've tried and what worked, 4 Cases in
    order of worst to best:


    Target Application: PADS Perform DOS v6.0.1
    Original OS: DOS
    Challenges:
    1. Uses Phar Lap 386|DOS-Extender v5.1,
    2. Uses -REALBREAK command-line switch so it needs DPMI v1.0 host with
    Map Conventional Memory in Memory Block function (INT31h AX=0509h),
    3. Supports 21 different video cards at 1024x768 or 1280x1024, BUT NO S3
    cards
    or VESA selections,
    4. Uses a parallel port hardware key.

    Numbers 2 and 3 are the biggest problems by far.



    *** Virtual PC 2007 ***

    Host - Win XP SP2, Retail
    Guest - Win 98SE, Retail
    Video support - S3 Trio32/64 PCI (732/764) (with VM Additions), VESA
    standard up
    to 1024x768 and 1280x1024

    Main Problem: Lack of Video Support

    I tried this since I thought I might get lucky and have one of the 21
    supported cards be compatible with the S3 Trio32/64 or the VESA standard. I
    was of course dreaming. Only 4 selections even drew garbage on the screen at
    1024x768: the Tseng Labs ET4000 and ET3000, the ATI VGA Wonder +, and the
    Paradise VGA. The IBM 8514A and the ATI Ultra (mach8) were well behaved,
    displaying "NO 8514 PRESENT" and exiting. All the others drew nothing and
    left the window blank and hung, needing an Alt-Del to get back to the VM
    Desktop. Only the IBM VGA setting worked which restricted the resolution to
    an unacceptable 640x480.

    Aside from the video, it was easy to get PADS Perform running. After
    installing Windows 98SE and the VM Additions, the network was already
    working. So I copied all the PADS Perform application directory as well as
    my old System.ini, Config.sys, and Autoexec.bat files from the host which
    shows up in Network Neighborhood to the VM C: drive (I had copied the files
    from an old computer to the host ahead of time for this experiment). I
    copied the line needed by PADS Perform to the System.ini file in the VM
    C:\WINDOWS and the whole Config.sys and Autoexec.bat to C:\ of the VM 98SE.
    I remmed out lines that were only needed by other applications. Mainly I
    needed:

    SYSTEM.INI [386Enh] - DEVICE=C:\PADS\PHARLAP.386
    CONFIG.SYS - DEVICE=C:\WINDOWS\HIMEM.SYS
    DEVICE=C:\WINDOWS\EMM386.EXE NOEMS
    DOS=HIGH
    DOS=UMB
    AUTOEXEC.BAT - PATH as appropriate
    Loadhigh C:\WINDOWS\COMMAND\DOSKEY.COM /bufsize=1024
    SET environment variables as appropriate for PADS
    Perform

    (DOSKEY was only for convenience and not required).

    I also set the LPT1 Setting to Physical parallel port: LPT1 (378h-37Fh) in
    the Settings for the Virtual Machine.


    Final Results: Application runs perfectly, but only at an unacceptable
    standard
    VGA 640x480 resolution. Slower than DOSBox, but the
    speed is
    acceptable.



    *** VMware Workstation v6.0.0 ***

    Host - Win XP SP2, Retail
    Guest - Win 98SE, Retail
    Video support - VESA 2.0 standard

    Main Problem: Lack of Video Support

    I didn't try this since I thought it would have the same results as Virtual
    PC. It has the same type of video limitations for PADS Perform so I assume
    it will run but at an unacceptable standard VGA 640x480 resolution.



    *** DOSBox v0.7 ***

    Host - Win XP SP2, Retail
    Guest - None, DOSBox emulates MSDOS 5.0 inherently
    Video support - VGA and VESA built-in; Tseng Labs ET4000, S3 Trio32/64, and
    Paradise VGA (with Vasyl's SVGA Additions)

    Main Problem: Slight color problem at 1024x768, corrected with ANSIPLUS

    This program is really impressive. The hardest part is collecting the
    pieces you need from various sites. Sourceforge handles the official build,
    currently DOSBox v0.7. There is a site for "unofficial" CVS builds posted
    daily which have fixes and possible additions. This is mainly for beta
    testers and comment. Then there are builds produced by people in the DOSBox
    community which use the official source and add various features in code
    contributed by other people in the DOSBox community. Three often used ones
    are:

    Gulikoza - with Direct3D, OpenGL-HQ, Vasyl's SVGA support, plus others
    ykhwong - with Direct3D, OpenGL-HQ, Vasyl's SVGA support, plus others
    HAL 9000 - Direct Parallel and Serial Port access


    For PADS Perform DOS, I needed to download the following:

    The official DOSBox v0.7 Win32 installer,
    The latest build from either YKHWong or Gulikoza,
    ANSIPLUS v4.06 from Kristofer Sweger,
    PortTalk v2.2 from Beyond Logic

    I ran the DOSBox installer. Then I unzipped the YKHWong and Gulikoza builds
    so I could try each one. I copied the YKHWong files into the DOSBox
    directory and replaced DOSBox.exe and DOSBox.conf and any other files that
    were older. Then I studied and edited the default .conf configuration file
    to make changes as follows:

    [sdl] - fulldouble=true
    fullresolution=1024x768
    windowresolution=1024x768
    [dosbox] - memsize=64
    [vga] - svgachipset=et4000
    videoram=1024
    [dos] - ems=false
    [autoexec] -
    mount c c:\
    path=C:\;C:\BAT;c:\pads;c:\pads\files;c:\pads\cam;C:\DOS;C:\WINDOWS;C:\WINDOWS\system32;C:\Programs\ANSIPLUS;C:\Programs\PortTalk;C:\ECED;C:\XTGOLD;

    SET dosx=-swapdir C:\PADS\SwapFile
    SET TMP=C:\temp

    C:\PROGRAMS\ANSIPLUS\ANSIPLUS.exe

    C:
    cd C:\PADS
    C:\PADS\PERFDOS6.COM
    del c:\PADS\SwapFile\PP*.SWP
    C:\pads\PPERFORM.EXE /S

    Then create a shortcut from the DOSBox.exe and set Start in: to C:\PADS.
    Compatibilty is all default, nothing checked. Copy the edited DOSBox.conf
    file to C:\PADS. DOSBox looks for a DOSBox.conf in the Start in: directory.

    When I first started, I wasn't using ANSIPLUS and there was a problem with
    having some colors wrong at 800x600 and 1024x768 in PADS Perform. The colors
    were perfect without using ANSIPLUS in XTree Gold v3.0 and an editor called
    EC which both run at 640x480. The first thing I thought of to fix the colors
    was ANSI.SYS but I couldn't load it in DOSBox even with loaders like Devload
    and CTload. So I started going through loadable ANSI.COMs. None worked
    until I came across the program ANSIPLUS, which is loadable as a device
    driver or a TSR. I loaded it in DOSBox before the application and the colors
    were almost perfect. I had to configure ANSIPLUS from the default palette to
    the "I" option of IBM-OEM colors and then the colors were perfect. (I'm not
    sure why the author didn't set the IBM-OEM colors as the default). Both
    Gulikoza and ykhwong builds worked equally well and had the same color
    problems. Both were fixed with ANSIPLUS.

    One thing was odd, I had to run the original bound PPERFORM.EXE without the
    TNT.EXE loader. When I tried to start PADS Perform with the TNT.EXE loader,
    it and PADS loaded and PADS was at its initial graphic screen ready to go.
    But then it would exit back to the DOS Prompt and display a message about not
    being able to read the key. This never happened when using just
    PPERFORM.EXE. Perhaps it has something to do with not having the matching
    PHARLAP.386 driver loaded since Win XP can't use a VxD.

    One thing that didn't work was the Paradise VGA support. PADS Perform has a
    selection for "Paradise VGA" which I selected. I set the DOSBox.conf to:

    [vga] - svgachipset=pvga1a
    videoram=1024

    PADS would display a line of text as usual before it normally goes to its
    graphic screen. But then the cursor would sit at the left under the text
    line and never get any further. PADS was running, just not able to display
    the correct thing. I could use the keyboard exit sequence "blind" and PADS
    would exit and return to the DOS Prompt.

    Finally I have PADS Perform DOS running in Windows XP SP2. Now the old
    hardware and Win 98SE can be retired.


    Final Results: Application runs perfectly at 1024x768. Faster than Virtual
    PC.



    DOSBox is the program that worked for me, rather than Virtual PC 2007 or
    VMware Workstation, because of the ET4000 video support. Both run PADS
    Perform DOS. But only DOSBox will let me run at 1024x768, which is a must
    have item.

    A big thanks to the DOSBox Team and especially Vasyl!!!
     
    Plan9, Jul 18, 2007
    #18
  19. PlanNine

    Plan9 Guest

    This is an update detailing the progression of what I've tried and what
    worked, 4 Cases in order of worst to best:


    Target Application: PADS Perform DOS v6.0.1
    Original OS: DOS
    Challenges:
    1. Uses Phar Lap 386|DOS-Extender v5.1,
    2. Uses -REALBREAK command-line switch so it needs DPMI v1.0 host with
    Map Conventional Memory in Memory Block function (INT31h AX=0509h),
    3. Supports 21 different video cards at 1024x768 or 1280x1024, BUT NO S3
    cards
    or VESA selections,
    4. Uses a parallel port hardware key.

    Numbers 2 and 3 are the biggest problems by far.



    *** Win XP SP2 Retail, native ***

    Main Problem: Lack of DPMI v1.0 host with Map Conventional Memory in
    Memory Block function (INT31h AX=0509h)

    I tried to get PADS Perform to run in Win XP SP2 without a VM, but there is
    one incompatibility with the Phar Lap 386|DOS-Extender (later called TNT
    DOS-Extender) involving DPMI v0.9 versus DPMI v1.0 support. PADS Perform
    used an Extender or DPMI option called the -REALBREAK command-line switch.
    This requires a DPMI v1.0 host which provides the Map Conventional Memory in
    Memory Block function (INT31h AX=0509h). But MS only provides support for
    DPMI v0.9 with EMM386.EXE or later, DOSX.EXE (HIMEM.SYS is the XMS host).
    DPMI v0.9 doesn't support INT31h AX=0509h.

    The purpose of the -REALBREAK switch is to request that some of the code and
    data be placed in conventional memory. One of the things this allows is to
    mix Real-mode and Protected-mode code.

    There appears to be 2 reasons to use -REALBREAK to load some of the
    application in conventional memory:

    1. Having some of the application in conventional memory can apparently
    improve the performance for some programs.

    2. Mixing Real-mode and Protected-mode code. Apparently Real-mode code can
    be mixed with Protected-mode code if the Real-mode code and data are 64K or
    less and they are loaded in conventional memory.

    If the reason is number 1, then the program will work in the NT series by
    using "-REALBREAK 0" which tells the Extender to load 0KB in conventional
    memory. I believe Autodesk's 3D Studio Release 4 falls into this category
    since people have reported that this makes it work in Win 2000 and XP,
    although the performance is cut in half. (If the DOS-Extender is bound with
    the application to have only one .EXE, use CFIG386.EXE to change the
    -REALBREAK switch, ex. "CFIG386.EXE 3DS.EXE -realbreak 0". If using a
    separate loader such as TNT.EXE, use "TNT.EXE -REALBREAK 0 Program.EXE").

    If the reason is number 2, then you're screwed. Period. The application
    will never run in the NT series. It appears PADS Perform falls into this
    category.

    The -REALBREAK switch is the worst way to load mixed code together. There
    are two other ways to deal with loading mixed code mentioned by Phar Lap.
    The preferred way is to use the realcopy() function shown in DOX-Extender's
    MDRAW sample program. "Using realcopy() avoids any potential compatibility
    problems with -REALBREAK.". If it were possible to reverse engineer enough
    of PADS Perform to add the realcopy() function and eliminate the need for
    -REALBREAK, then PADS Perform would probably work in the NT series. However,
    that is well beyond my capabilties. As the professors always used to say
    "It's left as an exercise for the student".


    Here's what happens:

    If your program uses the -REALBREAK command-line switch, DOS-Extender will
    refuse to load it unless the DPMI host provides the Map Conventional Memory in
    Memory Block function (INT31h AX=0509h).

    (See Phar Lap -> Ardence -> Citrix Tech Note 43 and 44 and the TNT
    DOS-Extender Reference Manual).

    When PADS Perform is started, the DOS-Extender starts to load and quickly
    displays the following infamous error:

    Phar Lap err 74: Can't use -REALBREAK under this version of DPMI
    Error TNT.20074: Can't use -REALBREAK under this version of DPMI


    With -REALBREAK set to 0, the DOS-Extender loads. PADS Perform starts to
    load, but quickly displays the following error:

    Panic!!!!
    cannot reach real mode vector
    EAX ........ 0000250F
    EBX ........ 00000000
    ECX ........ 00008DC0
    EDX ........ 002D0008
    Exiting ...


    PADS Perform uses the Phar Lap 386|DOS-Extender v5.1 bound into the main
    PADS executable so that there is only one .EXE to run, PPERFORM.EXE. I also
    tried using the TNT DOS-Extenders v7.0 and V8.02, TNT.EXE, as a loader to
    load PADS Perform with "TNT.EXE PPERFORM.EXE" so I would have the features of
    the newer version, in case that provided something more compatible to the Win
    NT series. In fact, I'd always had to use the TNT.EXE loader method just to
    get Perform to run in Win 98SE. PADS didn't provide a PHARLAP.386 VxD, so
    Perform didn't originally run in Win 9x. I had access to the DOS-Extender
    SDK v7 and v8. I tried v7.0 and v8.02 TNT.EXE loaders paired with their
    respective PHARLAP.386 VxD in the SYSTEM.INI file's [386Enh] section and they
    both worked. So I've always used v8.02 to run in 98SE. I tried all these
    variations in Win XP but nothing worked. I tried all combinations of the
    Memory and Compatibility settings in the shortcut used to start the program
    and still nothing worked (EMS must always be None).

    There was never any file from Phar Lap for Win NT that was equivalent to
    PHARLAP.386 for Win 9x.

    I've even tried other DPMI v1.0 hosts such as DPMIONE and HX DOS-Extender.
    HIMEM.SYS must be loaded to give an XMS host. But with or without DOSX.EXE
    loaded, DPMIONE and HX will refuse to load with the following messages:

    DPMIONE:

    The CPU is in Virtual Mode and there's no VCPI host.
    DPMIONE.EXE not installed.

    HX DOS-Extender:

    HDPMI32: CPU is in V86 mode, but no VCPI/DPMI host detected.

    These are similar to Phar Lap error 35 that results from loading
    DOS-Extender without loading DOSX.EXE:

    Error TNT.20035: The 386 chip is currently executing in virtual 8086 mode
    under
    the control of another program. You must turn
    off this other
    program in order to use TNT DOS-Extender to run
    in protected
    mode.

    Therefore, I could never get DPMI v1.0 support in Win XP.


    Final Results: The program will not run natively in any Win NT series.



    What to do? Perhaps a Virtual Machine could solve the problem.
    See the next post for results from 3 Virtual Machines...
     
    Plan9, Jul 19, 2007
    #19
  20. PlanNine

    Plan9 Guest

    Continued from previous post:

    (The previous post covered the attempt to run in Win XP SP2 natively,
    without a Virtual Machine).


    This is an update detailing the progression of what I've tried and what
    worked, 4 Cases in order of worst to best:


    Target Application: PADS Perform DOS v6.0.1
    Original OS: DOS
    Challenges:
    1. Uses Phar Lap 386|DOS-Extender v5.1,
    2. Uses -REALBREAK command-line switch so it needs DPMI v1.0 host with
    Map Conventional Memory in Memory Block function (INT31h AX=0509h),
    3. Supports 21 different video cards at 1024x768 or 1280x1024, BUT NO S3
    cards or VESA selections,
    4. Uses a parallel port hardware key.

    Numbers 2 and 3 are the biggest problems by far.



    *** Virtual PC 2007 ***

    Host - Win XP SP2, Retail
    Guest - Win 98SE, Retail
    Video support - S3 Trio32/64 PCI (732/764) (with VM Additions), VESA
    standard up to 1024x768 and 1280x1024

    Main Problem: Lack of Video Support

    I tried this since I thought I might get lucky and have one of the 21
    supported cards be compatible with the S3 Trio32/64 or the VESA standard. I
    was of course dreaming. Only 4 selections even drew garbage on the screen at
    1024x768: the Tseng Labs ET4000 and ET3000, the ATI VGA Wonder +, and the
    Paradise VGA. The IBM 8514A and the ATI Ultra (mach8) were well behaved,
    displaying "NO 8514 PRESENT" and exiting. All the others drew nothing and
    left the window blank and hung, needing an Alt-Del to get back to the VM
    Desktop. Only the IBM VGA setting worked which restricted the resolution to
    an unacceptable 640x480.

    Aside from the video, it was easy to get PADS Perform running. After
    installing Windows 98SE and the VM Additions, the network was already
    working. So I copied all the PADS Perform application directory as well as
    my old System.ini, Config.sys, and Autoexec.bat files from the host which
    shows up in Network Neighborhood to the VM C: drive (I had copied the files
    from an old computer to the host ahead of time for this experiment). I
    copied the line needed by PADS Perform to the System.ini file in the VM
    C:\WINDOWS and the whole Config.sys and Autoexec.bat to C:\ of the VM 98SE.
    I remmed out lines that were only needed by other applications. Mainly I
    needed:

    SYSTEM.INI [386Enh] - DEVICE=C:\PADS\PHARLAP.386
    CONFIG.SYS - DEVICE=C:\WINDOWS\HIMEM.SYS
    DEVICE=C:\WINDOWS\EMM386.EXE NOEMS
    DOS=HIGH
    DOS=UMB
    AUTOEXEC.BAT - PATH as appropriate
    Loadhigh C:\WINDOWS\COMMAND\DOSKEY.COM /bufsize=1024
    SET environment variables as appropriate for PADS
    Perform

    (DOSKEY was only for convenience and not required).

    I also set the LPT1 Setting to Physical parallel port: LPT1 (378h-37Fh) in
    the Settings for the Virtual Machine.


    Final Results: Application runs perfectly, but only at an unacceptable
    standard VGA 640x480 resolution. Slower than DOSBox, but
    the speed is acceptable.



    *** VMware Workstation v6.0.0 ***

    Host - Win XP SP2, Retail
    Guest - Win 98SE, Retail
    Video support - VESA 2.0 standard

    Main Problem: Lack of Video Support

    I didn't try this since I thought it would have the same results as Virtual
    PC. It has the same type of video limitations for PADS Perform so I assume
    it will run but at an unacceptable standard VGA 640x480 resolution.



    *** DOSBox v0.7 ***

    Host - Win XP SP2, Retail
    Guest - None, DOSBox emulates MSDOS 5.0 inherently
    Video support - VGA and VESA built-in; Tseng Labs ET4000, S3 Trio32/64, and
    Paradise VGA (with Vasyl's SVGA Additions)

    Main Problem: Slight color problem at 1024x768, corrected with ANSIPLUS

    This program is really impressive. The hardest part is collecting the
    pieces you need from various sites. Sourceforge handles the official build,
    currently DOSBox v0.7. There is a site for "unofficial" CVS builds posted
    daily which have fixes and possible additions. This is mainly for beta
    testers and comment. Then there are builds produced by people in the DOSBox
    community which use the official source and add various features in code
    contributed by other people in the DOSBox community. Three often used ones
    are:

    Gulikoza - with Direct3D, OpenGL-HQ, Vasyl's SVGA support, plus others
    ykhwong - with Direct3D, OpenGL-HQ, Vasyl's SVGA support, plus others
    HAL 9000 - Direct Parallel and Serial Port access


    For PADS Perform DOS, I needed to download the following:

    The official DOSBox v0.7 Win32 installer,
    The latest build from either YKHWong or Gulikoza,
    ANSIPLUS v4.06 from Kristofer Sweger,
    PortTalk v2.2 from Beyond Logic

    I ran the DOSBox installer. Then I unzipped the YKHWong and Gulikoza builds
    so I could try each one. I copied the YKHWong files into the DOSBox
    directory and replaced DOSBox.exe and DOSBox.conf and any other files that
    were older. Then I studied and edited the default .conf configuration file
    to make changes as follows:

    [sdl] - fulldouble=true
    fullresolution=1024x768
    windowresolution=1024x768
    [dosbox] - memsize=64
    [vga] - svgachipset=et4000
    videoram=1024
    [dos] - ems=false
    [autoexec] -
    mount c c:\
    path=C:\;C:\BAT;c:\pads;c:\pads\files;c:\pads\cam;C:\DOS;C:\WINDOWS;C:\WINDOWS\system32;C:\Programs\ANSIPLUS;C:\Programs\PortTalk;C:\ECED;C:\XTGOLD;

    SET dosx=-swapdir C:\PADS\SwapFile
    SET TMP=C:\temp

    C:\PROGRAMS\ANSIPLUS\ANSIPLUS.exe

    C:
    cd C:\PADS
    C:\PADS\PERFDOS6.COM
    del c:\PADS\SwapFile\PP*.SWP
    C:\pads\PPERFORM.EXE /S

    Then create a shortcut from the DOSBox.exe and set Start in: to C:\PADS.
    Compatibilty is all default, nothing checked. Copy the edited DOSBox.conf
    file to C:\PADS. DOSBox looks for a DOSBox.conf in the Start in: directory.

    When I first started, I wasn't using ANSIPLUS and there was a problem with
    having some colors wrong at 800x600 and 1024x768 in PADS Perform. The colors
    were perfect without using ANSIPLUS in XTree Gold v3.0 and an editor called
    EC which both run at 640x480. The first thing I thought of to fix the colors
    was ANSI.SYS but I couldn't load it in DOSBox even with loaders like Devload
    and CTload. So I started going through loadable ANSI.COMs. None worked
    until I came across the program ANSIPLUS, which is loadable as a device
    driver or a TSR. I loaded it in DOSBox before the application and the colors
    were almost perfect. I had to configure ANSIPLUS from the default palette to
    the "I" option of IBM-OEM colors and then the colors were perfect. (I'm not
    sure why the author didn't set the IBM-OEM colors as the default). Both
    Gulikoza and ykhwong builds worked equally well and had the same color
    problems. Both were fixed with ANSIPLUS.

    One thing was odd, I had to run the original bound PPERFORM.EXE without the
    TNT.EXE loader. When I tried to start PADS Perform with the TNT.EXE loader,
    it and PADS loaded and PADS was at its initial graphic screen ready to go.
    But then it would exit back to the DOS Prompt and display a message about not
    being able to read the key. This never happened when using just
    PPERFORM.EXE. Perhaps it has something to do with not having the matching
    PHARLAP.386 driver loaded since Win XP can't use a VxD.

    One thing that didn't work was the Paradise VGA support. PADS Perform has a
    selection for "Paradise VGA" which I selected. I set the DOSBox.conf to:

    [vga] - svgachipset=pvga1a
    videoram=1024

    PADS would display a line of text as usual before it normally goes to its
    graphic screen. But then the cursor would sit at the left under the text
    line and never get any further. PADS was running, just not able to display
    the correct thing. I could use the keyboard exit sequence "blind" and PADS
    would exit and return to the DOS Prompt.

    Finally, with the ET4000 support, I have PADS Perform DOS running in Windows
    XP SP2 at 1024x768. Now the old hardware and Win 98SE can be retired.


    Final Results: Application runs perfectly at 1024x768. Faster than Virtual
    PC.



    DOSBox is the program that worked for me, rather than Virtual PC 2007 or
    VMware Workstation, because of the ET4000 video support. Both run PADS
    Perform DOS. Virtual PC was easier to find and setup than DOSBox. But only
    DOSBox will let me run at 1024x768, which is a MUST have item.

    A big thanks to the DOSBox Team and especially Vasyl!!!

    And a big wish that the VPC team can find a way to increase the video
    support. I'm not the only one would like to run my old program in VPC, but
    can't solely because of the lack of video support. Perhaps as DOSBox does,
    the video could be opened up to outside support. Only a few more cards need
    to be supported in order to cover the vast majority of legacy programs from
    this era. The ET6000 (which also runs any ET3000 and ET4000 program) and the
    ATI mach64 GX with ATI Spectra RAMDAC (which also runs any VGA Wonder +
    program) were high volume chips that dominated the market in their era and
    cover multiple chips due to their family compatibility.
     
    Plan9, Jul 19, 2007
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.