feipoa wrote on 2023-07-06, 16:12:

If we are able to obtain the VGA BIOS image for this phantom card, could we just desolder the ARK1000VL and replace it with an ARK2000PV? Or perhaps we could use the BIOS from the ARK2000PV PCI donor card?

Here's the update DEBUG result:
DEBUG_2.JPG

Ouch, 00FE in AX looks like there is a lockout bit somewhere that prevents access to the register I wanted to access. The result from debug itself isn't that interesting. The most interesting thing is whether you are able to configure 1280x1024 non-interlaced after running it, but 00FE doesn't inspire confidence.

weedeewee wrote on 2023-07-06, 15:41:

feipoa wrote on 2023-07-06, 13:10:

I ran the DEBUG commands, but received an error:

The error being the 'h'. do not type that 'h' .
and the 0, also leave that one out.

Thanks for explaining what went wrong. I accidentally wrote that instruction in MASM syntax instead of DEBUG syntax (which is a kind of limited simplified MASM syntax).

feipoa wrote on 2023-07-06, 13:10:

That is unfortunate news concerning the 1024x768x64K mode having only one option, namely interlaced. Maybe the Bali32 VGA BIOS tries to force non-interlaced mode? I've attached it here.

The design of the ARK1000 cards seems to require to to run that mode as 2048x768 pixels of 8 bits each, and then ask the AT&T RAMDAC to "glue" two 8-bit pixels into one 16-bit pixel. 1024x768 non-interlaced requires a dot clock of 65MHz, so for 64K colors, you need to run the card at twice that frequency which is 130MHz, exceeding the specification of both the 110MHz RAMDAC and likely the ARK chip, too. As a 130MHz clock is available in the CH9294G, one could try to patch the BIOS to use that clock (or use 120MHz at 55Hz non-interlaced), though.

That's a situation the ET4000/W32 seems preferrable over the ARK: It supports double-data-rate output of 8-bit pixel data. The AT&T RAMDAC supports double-data-rate input at up to 66MHz, so 1024x768 @ 60Hz non-interlaced is in spec even for the cheapest 66MHz edition of that chip. The supported clock rate for DDR input doesn't rise on the better editions of the RAMDAC, though. The AT&T RAMDAC doesn't support 16M colors in DDR mode, so for 16M colors the ARK with its maximum pixel clock of around 110MHz is superior to the ET4000/W32i with a maximum pixel clock of just 86MHz.

WJG6260 wrote on 2023-07-06, 15:03:

I suspect you are correct and it is the first—insofar as we’re talking about a 64-bit accelerator in the guise of the ARK2000PV. I also have to say that I find it odd/lazy that the drivers would be shared amongst the two cards, with one being 32-bit and one being 64-bit, but I guess if they’re similar enough in design otherwise, it’s not too much of a stretch.

It's not obvious what exactly is 64 bit about the ARK2000 chip. If the memory interface has been upgraded from 32 bits to 64 bits (which would make sense, as well as providing a wider data path to the DAC), the chip needs to have more pins, so just soldering an ARK2000 chip to an ARK1000 card won't likely physically be impossible (even ignoring the question how much unobtainium you have to spend to get an ARK2000 chip...). On the other hand, maybe the "64 bit" is just achieved by interleaving two 32-bit banks (as the ET4000/W32i does, too). In that case, using the same driver is not that strange. The ET4000/W32 uses the same driver for W32, W32i (with interleaving) and W32p (with interleaving and PCI support), too.

feipoa wrote on 2023-07-06, 13:10:

That is unfortunate news concerning the 1024x768x64K mode having only one option, namely interlaced. Maybe the Bali32 VGA BIOS tries to force non-interl[aced mode? I've attached it here.
Paradise_Bali32_ARKVL1000_BIOS.zip

The Bali BIOS is identical, except for the branding.

Your analysis doesn't sound very encouraging for 1280x1024x256c-60Hz, and even less for 1024x768x64k-60Hz. Were there any LCD's which support this 87Hz interlaced mode?

Depending on the shipping method employed, I should have the 110 MHz RAMDAC in a week, unless it ships by boat, then I don't know when. Canadian port workers have been on strike.

On the other hand, I have what looks like a 130 MHz RAMDAC on my MACH64 VLB card. I'm not sure if the pinouts are the same as the ATT unit. I could not locate a datasheet for STG1702J-13Z.

feipoa wrote on 2023-07-06, 23:52:

Your analysis doesn't sound very encouraging for 1280x1024x256c-60Hz, and even less for 1024x768x64k-60Hz. Were there any LCD's […]
Show full quote

Your analysis doesn't sound very encouraging for 1280x1024x256c-60Hz, and even less for 1024x768x64k-60Hz. Were there any LCD's which support this 87Hz interlaced mode?

Depending on the shipping method employed, I should have the 110 MHz RAMDAC in a week, unless it ships by boat, then I don't know when. Canadian port workers have been on strike.

On the other hand, I have what looks like a 130 MHz RAMDAC on my MACH64 VLB card. I'm not sure if the pinouts are the same as the ATT unit. I could not locate a datasheet for STG1702J-13Z.
Mach64_RAMDAC.JPG

Here’s the only thing I can find on the STG1702. It has the pinout though!

As far as I know, most/all LCDs can’t do 87Hz interlaced. I guess you’d have to use a scaler, in that case.

I read somewhere in the STG1703 datasheet that it can be used as a drop-in upgrade to the STG1702, provided the proper pads are there, and the Chrontel CH8398 is also a drop-in replacement for the ST1703. If you were to strip the RAMDAC off the Mach64, those probably would be your best bet at replacements.

mkarcher wrote on 2023-07-06, 20:29:

WJG6260 wrote on 2023-07-06, 15:03:

I suspect you are correct and it is the first—insofar as we’re talking about a 64-bit accelerator in the guise of the ARK2000PV. I also have to say that I find it odd/lazy that the drivers would be shared amongst the two cards, with one being 32-bit and one being 64-bit, but I guess if they’re similar enough in design otherwise, it’s not too much of a stretch.

It's not obvious what exactly is 64 bit about the ARK2000 chip. If the memory interface has been upgraded from 32 bits to 64 bits (which would make sense, as well as providing a wider data path to the DAC), the chip needs to have more pins, so just soldering an ARK2000 chip to an ARK1000 card won't likely physically be impossible (even ignoring the question how much unobtainium you have to spend to get an ARK2000 chip...). On the other hand, maybe the "64 bit" is just achieved by interleaving two 32-bit banks (as the ET4000/W32i does, too). In that case, using the same driver is not that strange. The ET4000/W32 uses the same driver for W32, W32i (with interleaving) and W32p (with interleaving and PCI support), too.

This is interesting! Thanks for sharing. I think the ARK2000PV PCI card I have uses a similar PCB to the ARK1000PVs sold by Hercules. I don’t know if it’s the same, but Feipoa’s point about interoperability between the two is interesting and your point about what truly constitutes 64-but in the realm of the ARK2000PV is even more intriguing, as I’d never considered that it could just be interleaving to which ARK referred. It’s a shame the datasheet is lost to time. In the case they are talking about DRAM bank interleaving, I guess the card isn’t truly 64-bit, which would be a shame. I don’t think I’ve ever tested mine in Windows, come to think of it…

I wouldn't mind removing the STG1703 from my March64 card if it brings 1024x768x64k-60Hz to the ARK1000VL card.

I think swapping the ARK2000PV onto the VLB card w/BIOS would be interesting, but I don't have the ARK2000PV chip. Sounds like WJG does though. Not sure how you feel about desoldering these ARK chips though.

The ARK2000PV has 48 pins more. So that is not going to work.

feipoa wrote on 2023-07-06, 23:52:

Depending on the shipping method employed, I should have the 110 MHz RAMDAC in a week, unless it ships by boat, then I don't know when. Canadian port workers have been on strike.

you dont necessarily need faster RAMDAC for experimentation (modifying bios as Re: Where to obtain 110 MHz RAMDAC for ARK1000VL graphics card? to force non interlaced mode), even the stock one will display something, just lower quality

Dorunkāku wrote on 2023-07-07, 08:07:

The ARK2000PV has 48 pins more. So that is not going to work.

haha, I guess I should have counted the pins. At quick glance, they looked the same.

rasz_pl wrote on 2023-07-07, 08:44:

you dont necessarily need faster RAMDAC for experimentation (modifying bios as Re: Where to obtain 110 MHz RAMDAC for ARK1000VL graphics card? to force non interlaced mode), even the stock one will display something, just lower quality

It is OK, I made a larger old-stock IC order out of the ordeal.

If someone has a modded BIOS image, I'd be willing to try it out.

WJG6260 wrote on 2023-07-07, 00:55:

This is interesting! Thanks for sharing. I think the ARK2000PV PCI card I have uses a similar PCB to the ARK1000PVs sold by Hercules. I don’t know if it’s the same, but Feipoa’s point about interoperability between the two is interesting and your point about what truly constitutes 64-but in the realm of the ARK2000PV is even more intriguing, as I’d never considered that it could just be interleaving to which ARK referred. It’s a shame the datasheet is lost to time. In the case they are talking about DRAM bank interleaving, I guess the card isn’t truly 64-bit, which would be a shame. I don’t think I’ve ever tested mine in Windows, come to think of it…

Well, internally, it might not just be "bank interleaving". Even if the DRAM interface now runs at bank interleave, still using 32 data lines, it can provide twice the data rate. At the same time, the accellerator core might be clocked at the original data rate, but operate at on 64 bits instead of 32 bits. So you get twice the rate externally by interleaving banks, and twice the rates internally by increasing the width of the logic units.

In the mean time, I found that the X Server source code for XFree86 3.3.6 contains a well commented ARK driver for both the ARK1000 and ARK2000 series chips. It confirms that the ARK1000 can send 8 bits per clock to the RAMDAC, whereas the ARK2000 can send either 8 or 16 bits per clock. This might either be actual 16 pins, or the ubiquitious "data on both clock edges" mode on 8 pins. To get information on that, I just counted the pins of an ARK2000PV chip (it's 208 pins, the maximum pin count on standard PQFP cases) and the ARK1000PV chip (just 160 pins), which is identical to the ARK1000VL chip. I guess "PV" means "PCI/VLB" and "VL" means VL only. As the ARK2000 series has 48 extra pins, you can easily fit 32 video RAM data pins and 8 DAC pixel data pins in there, so the ARK2000 cards might have 64 physical data lines connecting the graphics chip with the video RAM.

feipoa wrote on 2023-07-07, 07:36:

I wouldn't mind removing the STG1703 from my March64 card if it brings 1024x768x64k-60Hz to the ARK1000VL card.

It won't. That mode requires 130MB/s being sent to the DAC. The maximum the ARK chip seems to be specified for is 120MB/s (8 bit pixel port at 120MHz). Also, the STG1702 datasheet WJG attached shows that this chip tops out at 110MB/s when you use a non-DDR 8-bit pixel port. I wonder whether "serializing 16-bit pixel port" in the STG data sheet fragment means the same as I mean when I talk about a DDR (double data rate) 8-bit pixel port, which again other people call "two-edge high color mode". As the 8-bit two-edge (DDR) mode is quite common, it would be strange if the STG1702 wouldn't support it - that's what makes be believe that "16-bit serialized" might be a different name for the same thing.

feipoa wrote on 2023-07-05, 21:24:

@ Dorunkāku
Interesting. I might try this. Was there any speed difference in DOOM or any other games? What memory speed were you running?

With Phils benchmark pack:
DOOM Max Detail: 61,8 fps
Quake: 16,9 fps
3DBench 1.0c: 100.9

Edit:
With the ARK1000VLs original clock speed:
DOOM Max Detail: 61,7 fps
Quake: 16,9 fps
3DBench 1.0c: 100.9

The Doom result is consistently about 2 real ticks slower.

With a AM5x86@160Mhz on a Acer VI15g .

Dorunkāku wrote on 2023-07-09, 08:22:

DOOM Max Detail: 61,8 fps
Quake: 16,9 fps
3DBench 1.0c: 100.9

I think he was expecting before/after comparison 😀 I wouldnt be surprised that overclock only helps with GUI acceleration under Windows.

I learned something from this thread.
I removed the second megabyte from the ARK 1000 VL card. All benchmarks (Dos and Win98SE) stay the same. Usable resolutions under Win98SE are the same, too. I use either 800x600 64k @72Hz or 1024x768 256 @75Hz.

I've received these 110 MHz RAMDAC chips recently. They appear authentic.

When I get some time, my plan is to:
a) test them in the ARK1000VL card without doing anything to the PCB or BIOS

if the result from a) doesn't allow 1280x1024x256c or 800x600x24bit, then
b) modify the BIOS hex per mkarcher's recommendation.

I've already put my testbed away for the summer, so not sure when I can fit this in, but I'll update the thread when that time comes. Many thanks for all the suggestions so far.

I'm starting to get back into testing this ARK1000VL card.

I replaced the RAMDAC with a 110 MHz piece and swapped the CLK GEN with an ARK1294A. Then booted to w95 and tried 1280x1024x256c. The system is still trying to run interlaced mode. So I booted to NT4, which lets me specify that I want 60 Hz, but the screen still looks to be interlaced mode.

Next, I altered the 2themax's VGA BIOS per mkarcher's analysis, namely,

offset 4391h, turn 74h into EBh
offset 7FFFh, turn D8 into 61h

Programmed this to a W27E257-12 EEPROM, installed into VLB card, then ran the above test again.

The screen still jitters at 1280x1024x256c at 60 Hz, but it jitters in a different manner compared to how the non-edited BIOS was jittering.

The file:
1280x1024x256c_i43hz.zip contains a video showing the expected interlaced mode jitter on an unsupported monitor. This is also what 60 Hz looks like with the non-edited BIOS.

With the edited bios, 1280x1024x256c_60hz.zip shows how this jitter has changed quite a bit. Unfortunately, the display is still not as it should be, but the editing of the BIOS changed something.

feipoa wrote on 2023-07-06, 23:52:

Your analysis doesn't sound very encouraging for 1280x1024x256c-60Hz, and even less for 1024x768x64k-60Hz. Were there any LCD's […]
Show full quote

Your analysis doesn't sound very encouraging for 1280x1024x256c-60Hz, and even less for 1024x768x64k-60Hz. Were there any LCD's which support this 87Hz interlaced mode?

Depending on the shipping method employed, I should have the 110 MHz RAMDAC in a week, unless it ships by boat, then I don't know when. Canadian port workers have been on strike.

On the other hand, I have what looks like a 130 MHz RAMDAC on my MACH64 VLB card. I'm not sure if the pinouts are the same as the ATT unit. I could not locate a datasheet for STG1702J-13Z.
Mach64_RAMDAC.JPG

Outside of possible niche modes designed for retrofitting a CRT with an LCD in"industrial" type application, I doubt that there were. And if there were, they had an internal scaler.

Speaking of scalers, the Extron unit mentioned here VGA adapter to convert a graphics card interlaced mode to non-interlaced mode on LCD? would probably do the job .

instead of recording videos slap an oscilloscope on V H VGA pins to verify what is being generated