Funny enough, Virtual Pool uses the same trick as Dawn Patrol. I am not sure if it is split screen implementation that is failing, or odd/even, or something else -- I am getting part of the screen rendered in incorrect position... Again, so close... Currently working on theory that line compare is correct (the problem is not consistent with that feature) and it is odd/even thing. So, I am in vga_memory land once more.
Great that you have it nearly working, vasyl.
I first tested it with version on sf.net,probably without modifications for dawn patrol (btw. it's possible to update(replace) uploaded file there).
I guess that also VESA mode in virtual pool isn't working because of those unimplemented vga features...
Voting for paradise 🤑
founded 2/89
first spec 8/89 mode 6ah 800x600 16 color (what I christen as vbe 0.0):)
vbe 1.0 10/89
vbe 1.1 6/90
vbe 1.2 8/91
vbe 2.0 11/94
vbe 3.0 9/98
version changes summaries are given in an appendix in each doc.
Definitively, the dates are in the title pages and make up the standard #.
Oh, though they said they wouldn't define any more mode numbers from 2.0 on, 2.0 adds Special Mode number 81FFh. It's a function and not a video mode but it is a "mode" added to the mode list. Being pedantic, their sentence is wrong, but obviously they were referring to new video modes:) vbe 2.0 spec also defines vga standard modes 0-7, d-13 for setting them by vesa. They included this mode block info only in the vbe 2.0 spec.
Great research! IMHO, VESA was "too little, too late" kind of standard. In 1990 there were dozens of different video cards. Some manufacturers never bothered to update BIOS with VESA, extra TSRs were considered evil. So, most graphics libraries had coded support for many chipsets. I only vaguely remember playing with UniVBE on ET4000 but I don't think I ever had any game that actually required VESA. But again, it was fifteen years ago...
Thanks about DOSEMU tip, somehow I've missed that feature. Last time I checked DOSEMU it could barely run text mode apps. Looks like they've got a lot since.
As for Virtual Pool -- the broken part is definitely in basic VGA functionality so it does affect all SVGA implementations. I would speculate that this issue affects quite a few other SVGA games and probably a few VGA games running in hacked 320x200 modes. IIRC, Quake had a few of those. I still have the very first edition of Quake, let's see what it does.
This is great, thanks. I had no time to do anything on DOSBox lately 🙁
I double-checked Quake and all hacked modes work fine so whatever's broken, it does not affect non-SVGA modes. Very interesting, considering how simple Virtual Pool driver actually is -- it must be something very fundamental that breaks it but I still cannot tell exactly what's wrong. I will try your fixes and see how's that going.
All right, I've integrated your changes with mine. Funny, I recalled both VGA testing tools. I even vaguely recall that my Tseng ET4000 actually failed some test in VGATEST... Your changes apparently improve compatibility but Virtual Pool is still broken 🙁 Actually, I expected that -- everything point to sequencer, not CRTC in that case. More work to do.
It may be mode-x or "special" paradise(aka uses pvga1a registers/mode for setup/running). Won't really know until someone gets ahold of a copy of the paradise version or find a description of it's video option. mobygames categories are general so you can't assume by their title.
Speaking of special versions, I'd love to get the GUS version of Chuck Yeager's Air Combat again but havn't found a copy online in my searching(a lot). Too bad I don't have the disks anymore:( Still have my Ultrasound though:)
Looked to no avail for the original install disks too(have lots of the later versions).
Last edited by ih8registrations on 2005-05-12, 14:20. Edited 1 time in total.
I may have found the cause for the virtual pool issue by the sequencer. I'm looking at the datasheet for the C & T 65510 vga controller and it says the sequencer has a horizontal character counter reset register: SR07(r/w), that is a standard VGA register which was not documented by IBM. It's not implemented by dosbox. Dun, dun, dun:) It should be case 0x07 in read_p3c5 & write_p3c5.
vgadoc describes it as well. bochs and qemu don't have it implemented.
I'm 95% sure that I have that Paradise version of Indy: Last Crusade game on original 5.25" disks. Unfortunately I don't have a 5.25" disk drive.
I remember running it on a non-Paradise video card though, and it still runs. It doesn't use any special modes that I can see. I think it was just bundled with some Paradise video cards and they pretended that it was special somehow. Or, maybe it runs better if it detects a Paradise card, so I never got to see the difference?
I'll do that. The theory is very plausible but that particular index is not used in the initialization routine:
1seg000:00FF mov ax, 2Eh ; '.' 2seg000:0102 int 10h ; - VIDEO - SET VIDEO MODE 3seg000:0102 ; AL = mode 4seg000:0104 mov dx, 3D4h 5seg000:0107 mov ax, 9 6seg000:010A out dx, ax ; Video: CRT cntrlr addr 7seg000:010A ; maximum scan line 8seg000:010B mov ax, 8F18h 9seg000:010E out dx, ax ; Video: CRT cntrlr addr 10seg000:010E ; 11seg000:010F mov ax, 0Dh 12seg000:0112 out dx, ax ; Video: CRT cntrlr addr 13seg000:0112 ; regen start address (low) 14seg000:0113 mov ax, 0Ch 15seg000:0116 out dx, ax ; Video: CRT cntrlr addr 16seg000:0116 ; regen start address (high) 17seg000:0117 mov dx, 3C4h 18seg000:011A mov ax, 604h 19seg000:011D out dx, ax ; EGA: sequencer address reg 20seg000:011D ; 21seg000:011E mov dx, 3CEh 22seg000:0121 mov ax, 4005h 23seg000:0124 out dx, ax ; EGA: graph 1 and 2 addr reg: 24seg000:0124 ; 25seg000:0125 mov dx, 3C4h 26seg000:0128 mov al, 2 27seg000:012A out dx, al ; EGA: sequencer address reg 28seg000:012A ; map mask: data bits 0-3 enable writes to bit planes 0-3 29seg000:012B retf
The blit routine does not mess with the sequencer besides enabling/disabling planes. So, one of the indexes above is not implemented correctly. Odd/even (3c5 index 4) is not doing anything at this moment, that's why I think it is the cause. Of course, that's unless the game actually does some VGA magic outside of the driver, and I did not dig that far yet.
As for Indy3, I don't think it is really Paradise-specific. The original PC version was EGA. That makes VGA "special." I would not be surprised if WD had OEM deal that allowed it to include VGA version very early, even before the retail release. A few games were like that but I did not know that Lucasarts did that as well.
Is that Hong Kong Mahjong, by any chance? That one was pretty good. There was later Windows 9x version but the port was quite lame.
BTW, I've asked freddie from Lucasarts Museum (http://lucasarts.vintagegaming.org/) about that Indy3 Paradise version. He is almost positive that the only difference was that Paradise version was on 5.25" floppies.
Did not get much time lately to deal with this, had a grand total of about 40 minutes in last seven days. Virtual Pool has proven to be quite tricky. I've tried a few hacks and did not get far. I am pretty positive that it requires proper implementation of odd/even addressing which we don't have at the moment. Looks like it also does some kind of split screen which does not work either -- the implementation is there but it must be incomplete. Can anybody suggest good link to VGA programming documentation, more verbose than VGADOC? I looked through DOSEMU sources but its VGA implementation is less featured than the one in DOSBox.
I am planning to refresh my patch on SF and update it to complete Dawn Patrol support some time this week.