Anonymous Coward wrote:

Just to be clear, the 64-bit cards are not using memory interleaving. With 1MB installed, these cards are technically crippled by a 32-bit memory bus. When 2MB is installed, the memory data path is running at full 64-bit capacity. It's not to say that a 64-bit card couldn't be designed to use interleaving (effectively 128-bit), just that nobody ever bothered to make one.
There are only a few 32-bit VGA chips I am aware of that use memory interleaving. One is the Tseng ET4000W32i/p, and the other is the S3 805i. Neither were high-end products at time of release. Memory interleaving does not make the board truly 64-bit, but is said to provide up to 85% of the bandwidth of a 64-bit board. As far as I know memory interleaving was a trick that manufacturers used to cut down on development/production costs while remaining somewhat competitive with actual 64-bit products.

As for an explanation why running 2MB boards with only 1MB installed does not seem to impact DOS performance, I am led to believe that perhaps the VGA core is somehow unable to take advantage of the extra features provided by 64-bit and 32-bit interleaved VGA cards. At least according to documentation I read for the ARK1000 (32-bit) and 2000PV(64-bit) documentation, both chips have an identical VGA core. It might have to do with the way that DOS accesses VGA memory through a 64kb window in the UMB region.

elianda wrote:

It might also be that through PCI only 32 bit at a time is transferred and typical DOS stuff uses a PIO like approach with e.g. REP STOSD to VGA RAM. (If the graphics RAM internal bandwidth is higher than the PCI transfer speed.) So 64 bit memory might start playing a role if you do BitBlt from VRAM to VRAM. But that is all part of the 2D windows acceleration...
I mean vspeed bench goes up to 32 bit accesses only and does not bother testing with 64 bit accesses probably because you wouldn't see a difference anyway as the 64 bit would be split up to two 32 bit accesses.

Another point is likely that a 64 bit memory data path on the graphics card helps to reduce the time needed where the DAC reads, especially in demanding modes. Such that the card doesn't get much slower from programmers side. (DRAM vs. VRAM gets also important here)

I ran speedsys on those setups and here are the results.
ARK2000 1MB, 16601KB/s:

ARK2000 2MB, 16464KB/s:

SiS 530 2MB, 29764KB/s, with penalty on the system memory:

Trident 9680 2MB, 11160KB/s, the upper portion of the window was out of the screen:

Is speedsys measuring the speed between CPU and VRAM, or the speed between GPU and VRAM?

Keep in mind, the P100 is holding back performance somewhat when you compare between cards. But I think the lack of difference between 1MB and 2MB would hold with a faster CPU. It would be interesting to see, though, just out of curiosity.

The SiS lead is likely due to its bandwidth advantage, being on AGP.

Any luck yet with newer versions of UniVBE? Sorry, I missed your previous reply where you addressed this. 😊

clueless1 wrote:

Keep in mind, the P100 is holding back performance somewhat when you compare between cards. But I think the lack of difference between 1MB and 2MB would hold with a faster CPU. It would be interesting to see, though, just out of curiosity.

The SiS lead is likely due to its bandwidth advantage, being on AGP.

Any luck yet with newer versions of UniVBE? Sorry, I missed your previous reply where you addressed this. 😊

I will try that and faster platform if I have some spare time tonight.
Also my card has a 3-pin jumper for enabling PCI timeout, but it came without a cap on it. Does your card have that jumper? I tried no jumper, 1-2 and 2-3, but saw no difference in Quake 320x200 and only 1~2 ticks apart in Doom Min.

@lazibazyer -- off the top of my head, I don't remember if mine has that jumper. I'll have to open up my system this evening to check. I did go back to my thread and zoomed in on my opening pic, and I can see what looks like it might be the jumper in question. But zoomed in it gets pretty fuzzy.

Here's a clue I found regarding 64-bit performance:

An added unique feature is that 64-bit wide systems can be offered with only 1 Mbyte of memory by using 128Kx16 DRAMs.

I wonder if most card were built with these memory chips, thus getting max speed with 1MB configurations.
Found here: http://web.archive.org/web/19970530024419/htt … ews/freemov.htm
BTW, it looks like yours is the MT, based on your Speedsys results. You get free MPEG acceleration. 😉 Mine is the PV.
Kinda cool to browse the old arklogic.com site through the Wayback Machine. Looks like various Windows drivers are available as well as some of the news releases.

clueless1 wrote:

@lazibazyer -- off the top of my head, I don't remember if mine has that jumper. I'll have to open up my system this evening to […]
Show full quote

@lazibazyer -- off the top of my head, I don't remember if mine has that jumper. I'll have to open up my system this evening to check. I did go back to my thread and zoomed in on my opening pic, and I can see what looks like it might be the jumper in question. But zoomed in it gets pretty fuzzy.

Here's a clue I found regarding 64-bit performance:

An added unique feature is that 64-bit wide systems can be offered with only 1 Mbyte of memory by using 128Kx16 DRAMs.

I wonder if most card were built with these memory chips, thus getting max speed with 1MB configurations.
Found here: http://web.archive.org/web/19970530024419/htt … ews/freemov.htm
BTW, it looks like yours is the MT, based on your Speedsys results. You get free MPEG acceleration. 😉 Mine is the PV.
Kinda cool to browse the old arklogic.com site through the Wayback Machine. Looks like various Windows drivers are available as well as some of the news releases.

Thanks for your effort. You may forget it if it's too much trouble.
I don't think 128Kx16 was a common configuration... I can only find one manufacturer, Mosel Vitelic, that makes this chip (V53C16128H series). The same company is also the only one that I can find who makes the chips for your ARK2000's expansion sockets, V53C8256H in 256Kx8 configuration. Most 1MB cards come with two 256Kx16 or eight 256Kx4 chips.
Free MPEG acceleration! Yay!

Plot twist! I finally got SDD/UniVBE working and 2MB is consistently 0.4 FPS faster in Quake 640x480.

I have also found a solution to the screen flickering problem. After changing the VRAM size and plugging the card back to the same PCI slot, SDD/UniVBE will skip model analysis and cause screen to flicker. I don't know how to force them to reconfigure but swapping PCI slots will trigger the reanalysis process.
With the card being present in PCI Slot 2 and UniVBE 6.7 loaded there is sometimes no resolution support between 360x480 and 800x600 in Quake. I have encountered this at least once with 1MB VRAM and at least once with 2MB VRAM. I have yet figured out why.
I tried to benchmark with a faster system to eliminating processor bottlenecking but Dimension 8100 refused to boot with my 170MB DOS drive, not even with manual hard drive geometry configuration.

lazibayer wrote:

Plot twist! I finally got SDD/UniVBE working and 2MB is consistently 0.4 FPS faster in Quake 640x480. […]
Show full quote

Plot twist! I finally got SDD/UniVBE working and 2MB is consistently 0.4 FPS faster in Quake 640x480.

Screen Shot 2017-09-14 at 11.04.00 PM.png

I have also found a solution to the screen flickering problem. After changing the VRAM size and plugging the card back to the same PCI slot, SDD/UniVBE will skip model analysis and cause screen to flicker. I don't know how to force them to reconfigure but swapping PCI slots will trigger the reanalysis process.
With the card being present in PCI Slot 2 and UniVBE 6.7 loaded there is sometimes no resolution support between 360x480 and 800x600 in Quake. I have encountered this at least once with 1MB VRAM and at least once with 2MB VRAM. I have yet figured out why.
I tried to benchmark with a faster system to eliminating processor bottlenecking but Dimension 8100 refused to boot with my 170MB DOS drive, not even with manual hard drive geometry configuration.

Cool. 😎

Thanks for reporting back! Regarding UniVBE, have you tried re-running UVCONFIG right after you put the card in?

clueless1 wrote:

Cool. 😎

Thanks for reporting back! Regarding UniVBE, have you tried re-running UVCONFIG right after you put the card in?

No... I am not familiar with UniVBE or DOS benchmark in general... I will try it this weekend.

Previously I reported that changing VRAM size and/or PCI slots will cause flickering or resolution loss in Quake if UniVBE was loaded directly after the change, and @clueless1 mentioned uvconfig. So tonight I tried all possible transitions and found cure for each one of them:

The top 4 rows apply to all versions of UniVBE, and the bottom 8 rows apply to only UniVBE 6.7.
Resolution loss implies that there is no resolution between 360x480 and 800x600 in Quake.
Run uvconfig means that uvconfig needs to be called before loading UniVBE.
Delete files means that the two files, univbe.drv and uvconfig.dat, needs to be deleted before calling uvconfig, which itself should be done before loading UniVBE.
The two on-the-fly cases are the most tricky ones. At first I couldn't find a solution except bridging through other transitions, until I accidentally deleted the two files and re-ran uvconfig while UniVBE is still running. I then verified that just running uvconfig on-the-fly without deleting the two files doesn't work.
In the bottom 8 cases loading UniVBE will trigger model analysis, which I reckon is done through uvconfig. In the four flicker cases loading UniVBE doesn't trigger model analysis and UniVBE reports VRAM size from preceding states.
I have also repeated the benchmarks and the numbers are exactly the same.

Next I tried Quake on the much beefier Dell Dimension 8100:

CPU: lightning fast Pentium 4 1.3GHz
Motherboard: almighty i850
RAM: gigantic 1GB PC-800 RAMBUS
Video card: ARK2000MT with free MPEG acceleration
Hard drive: Seagate U8 the 10GB special version that is not documented on official datasheet

The result is... complicated when UniVBE is involved. 800x600 is surprisingly fast with 1MB VRAM but also surprisingly slow with 2MB VRAM. 640x480 is surprisingly slow with 1MB VRAM and less so with 2MB VRAM. Plus SDD53A will cause my Dell LCD monitor freak out at 1024x768.
So I think it's safe to say adding one more meg doesn't affect sub-VGA performance, and the VGA+ performance has probably more to do with software than hardware.

Back in the day, 2MB VRAM was important when I wanted to run high color / high resolution in either Win3.1 or Linux. The framebuffer limit at 1MB was 1152x864 at 8 bpp or something like 800x600 at 16 bpp. 2MB allowed 1152x864 at 16 bpp which was much more acceptable.

@lazibayer -- one thing to double-check. Quake sometimes will appear to change resolutions through the UI, but actually fail to a lower resolution. I wonder if something like that is happening at 800x600 in the 1MB configuration. It might make sense to verify you're in each correct resolution with the monitor controls. There's a way in Quake to change resolutions via command line, that might be another method to employ if that's the case.

clueless1 wrote:

@lazibayer -- one thing to double-check. Quake sometimes will appear to change resolutions through the UI, but actually fail to a lower resolution. I wonder if something like that is happening at 800x600 in the 1MB configuration. It might make sense to verify you're in each correct resolution with the monitor controls. There's a way in Quake to change resolutions via command line, that might be another method to employ if that's the case.

I just verified that at every setting the monitor is reporting the correct resolution.