feipoa wrote on 2023-09-30, 12:24:

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 "60Hz jitter" looks like an issue with the memory clock. Either the memory clock is too high for the memory chips, so they can't provide data fast enough, or the memory clock is too low for 1280x1024x256c at 60Hz, so the card gets "buffer underruns" on the video memory FIFO all the time. I told you to patch the part of the BIOS code that inhibits the 60 Hz mode is the BIOS is not configured for a 110MHz DAC, which obviously worked as intended. If I didn't miss anything while re-checking the BIOS code, the BIOS does not do anything about programming MCLK, but MCLK is selected by extenally choosing a clock on the clock chip. You might need to increase the memory clock by re-configuring the clock chip to get sufficient bandwidth.

Upon reviewing the manual for the ARK1000VL card again, it seems like no hackery should be required. In short, it mentions to insert the missing 256Kx16 memory modules, and have access to 1280x1024x256c. I'm attaching two scanned pages from the manual, the first shows where it says 110 MHz RAMDAC for 1280x1024x256c non-interlaced; the second page shows where it says to simply insert the RAM to unlock the additional resolutions.

The other curious note it mentioned was that the DIP and SOJ DRAM must be of the same speed. Is this true? I thought as long as the SOJ RAM was at least as fast as the DIP RAM that it would be sufficient, but this is not how the manual is worded.

Next, I got to looking at the speeds of the DRAM on my card. It originally came with 70 ns DIP, and 60 ns SOJ (added by another user). I replaced the 70 ns DIP with 50 ns DIP, but left the SOJ. Is the speed difference here an issue? I don't have any 60 ns DIP 256kx4.

Next, I wanted to look up the datasheet for the SOJ DRAM on my board, which is 256kx16 with part M514265BSL-60J , found here: https://pdf1.alldatasheet.com/datasheet-pdf/v … M514265BSL.html
Upon quick glance, I thought nothing the matter, but looking at it a second time, it mentions "hyper page mode type", which I believe is EDO??? Ut oh. Further poking around, I see this old eBay listing for these modules, in which it also lists them as FPM with EDO, https://www.ebay.com/itm/121782871693

I take it these upgrade modules won't work and that I need FPM only chips?

I went looking thru all my cards and the only 256kx16-FPM I have are soldered to a Trident card, one of the faster ISA cards. They are 70 ns.

If the warning about the same memory speed in the manual is correct, then I'd also need 70 ns DIP, of 256Kx4, for which I have these:

I'd rather not desolder the SOJ DRAM on the Trident, so I will try to source some alternate 50 ns 40-SOJ 256Kx16-FPM or 70 ns 40-SOJ 256Kx16-FPM, provided you guys think the issue is with the "hyper page mode" DRAM I have installed.

feipoa wrote on 2023-10-01, 03:11:

Upon reviewing the manual for the ARK1000VL card again, it seems like no hackery should be required. In short, it mentions to insert the missing 256Kx16 memory modules, and have access to 1280x1024x256c.

Which you do. Unless you use the patched BIOS, you just install the missing memory, and you get access to 1280x1024x256c (albeit interlaced). On the other hand, the manual does not claim that the PCBs for the 80MHz and the 110MHz version is identical. I see that you compared your card with the 110 MHz Bali card, and those cards were identical - but this doesn't necessarily mean that the Bali card actually makes use of the 110MHz DAC (although buying the high speed DAC and running it at lower speed only would seem strange). The DAC is no user-servicable part, so the manual doesn't need to contain the instructions required to adapt the card to a DAC of a different speed.

feipoa wrote on 2023-10-01, 03:11:

The other curious note it mentioned was that the DIP and SOJ DRAM must be of the same speed. Is this true? I thought as long as the SOJ RAM was at least as fast as the DIP RAM that it would be sufficient, but this is not how the manual is worded.

That's unlikely. If reading and writing works within the time given by the /RAS, /CAS, /WE signals, the card should work. Note that the ET4000W32i is relying on a non-zero hold time (data still valid for some nanoseconds after the cycle seems complete), and massively faster RAMs can be too fast in turning the data off (we had something likely related to this effect in the homebrew ET4000 thread), but as the ARK1000VL doesn't seem to do bank interleaving, I don't think it is as picky. 60ns RAM should be fine even if the original DIP RAM was 70ns.

feipoa wrote on 2023-10-01, 03:11:

Next, I wanted to look up the datasheet for the SOJ DRAM on my board, which is 256kx16 with part M514265BSL-60J , found here: https://pdf1.alldatasheet.com/datasheet-pdf/v … M514265BSL.html
Upon quick glance, I thought nothing the matter, but looking at it a second time, it mentions "hyper page mode type", which I believe is EDO???

Exactly. "hyper page mode" is EDO. I think I read that the ARK1000 does support an EDO mode, and can actually make use of the faster EDO burst read access method. Of course, this EDO mode only works if all RAM on this card is EDO. In your case, the EDO mode is obviously not enabled. Nevertheless, this means the chip needs to implement row access patterns that are compatible with EDO, and using this pattern with FPM too wouldn't be too surprising. If "page mode" is only used during a single burst, and the page is closed after the burst (like refilling the display FIFO or flushing the CPU write FIFO) is done, EDO vs. FPM wouldn't matter. Furthermore, you already used more than 1M successfully on the card (in the 1280x1024 interlaced mode), so it definitely seems to be EDO compatible.

feipoa wrote on 2023-10-01, 03:11:

I'd rather not desolder the SOJ DRAM on the Trident, so I will try to source some alternate 50 ns 40-SOJ 256Kx16-FPM or 70 ns 40-SOJ 256Kx16-FPM, provided you guys think the issue is with the "hyper page mode" DRAM I have installed.

Before you try this, try just desoldering R36 next to the clock generator to get 70MHz instead of 55MHz memory clock.

mkarcher wrote on 2023-10-01, 05:57:

Which you do. Unless you use the patched BIOS, you just install the missing memory, and you get access to 1280x1024x256c (albeit interlaced). On the other hand, the manual does not claim that the PCBs for the 80MHz and the 110MHz version is identical. I see that you compared your card with the 110 MHz Bali card, and those cards were identical - but this doesn't necessarily mean that the Bali card actually makes use of the 110MHz DAC (although buying the high speed DAC and running it at lower speed only would seem strange). The DAC is no user-servicable part, so the manual doesn't need to contain the instructions required to adapt the card to a DAC of a different speed.

Is the user's manual for the Bali32 available?

AC:
User WJG6260 owns the printed Bali32 manual. A few months ago, he sent me some select pages concerning the video modes and the 2MB upgrade. Unfortunately, it had been scanned it as large resolution colour images, so the PDF size is too large to attach. However, I have been able to convert it to 1-bit PDF, which is far more ideal. This process was time consuming for me on Linux, probably because I don't have the ideal software. Anyway, here is the conversion:

mkarcher:
User Dorunkāku had reported previously that removing R35 sets 70 MHz, not R36. However, looking at the traces, I think it is indeed R36. It looks to me like MS2, MS1, MS0 = R37, R36, R35.

I will connect the scope to MCLK to first measure the memory clock, then remove R36 and reconfirm the memory clock is 70 MHz. I will do this with the original, unmodified, VGA BIOS. If results not desirable, try with modified VGA BIOS. If results still not desirable, then desolder the 70 ns FPM SOJ-40 DRAM from my Trident card and place into the ARK1000VL card. I will also swap the 50 ns DIP DRAM for 70 ns DRAM, even though you stated it is almost certainly not required to do so. If results still not desirable, measure Vclk, Hsync, and Vsync with scope.

You mentioned that the ARK1000VL has support for EDO. Were there any DIP-20 256Kx4 EDO DRAM modules?

How would EDO detection work? Does video Bios test ram several times trying different init incantations? If that is the case does it test whole ram (I imagine not, too slow) or just a small slice, and does it test all banks separately?
You could always try Re: List of open-source PC hardware projects to mod those EDO into FPM for consistency.

It's quicker for me to desolder the DRAM from my Trident card, then buy replacements on eBay for $4 shipped.

I can confirm that removing R36 yields 70 MHz on MCLK. Unfortunately, I started to see some colour distortions in Windows. Perhaps 65 MHz will work. For now, I've put R36 back onto the PCB. The colour distortions at 70 MHz MCLK are as follows:

I also tried to set 1280x1024x256c at 60 Hz, but it shows up as interlaced.

In viewing the ARK datasheet, it only mentions EDO support in the 2000PV; not the 1000VL or 1000PV.

No change in results when using 70 ns 256kx16 (SOJ) and 70 ns 256kx4 (DIP).

No change in results whether or not I use the ARK1294A or the CH9294G clock generator chip.

When using the original VGA BIOS, here are the Vclk values at various resolutions:
800x600x64k @ 60 Hz, Vclk = 80 MHz
1024x768x256c @ 60 Hz, Vclk = 65 MHz
1280x1024x256c @ 60 Hz, Vclk = 77 MHz (failed attempt, screen looks like interlaced mode, see previous video)

When using the modified VGA BIOS,
800x600x64k @ 60 Hz, Vclk = 80 MHz
1024x768x256c @ 60 Hz, Vclk = 65 MHz
1280x1024x256c @ 60 Hz, Vclk = 110 MHz (failed attempt, screen looks jittery, see previous video)

According to the Bali32 manual provided a few posts ago,

1Mode 43 - 1280x1024x256c - VCLK=[b]110MHz[/b], Hsync=66.7 KHz, Vsync=60 Hz

It looks like mkarcher's hack has allowed for 110 MHz, while the original BIOS does not.

feipoa wrote on 2023-10-01, 13:57:

In viewing the ARK datasheet, it only mentions EDO support in the 2000PV; not the 1000VL or 1000PV.

I might have mixed that up, sorry for the misdirection there.

feipoa wrote on 2023-10-01, 13:57:

1280x1024x256c @ 60 Hz, Vsync = 110 MHz (failed attempt, screen looks jittery, see previous video) […]
Show full quote

1280x1024x256c @ 60 Hz, Vsync = 110 MHz (failed attempt, screen looks jittery, see previous video)

According to the Bali32 manual provided a few posts ago,

Copy code to clipboard

1Mode 43 - 1280x1024x256c - VCLK=[b]110MHz[/b], Hsync=66.7 KHz, Vsync=60 Hz

It looks like mkarcher's hack has allowed for 110 MHz, while the original BIOS does not.

Please don't write Vsync when you intend to write VCLK. Vsync is usually used for the vertical refresh rate, not for the dot clock.

feipoa wrote on 2023-10-01, 11:09:

I can confirm that removing R36 yields 70 MHz on MCLK. Unfortunately, I started to see some colour distortions in Windows. Perhaps 65 MHz will work. For now, I've put R36 back onto the PCB. The colour distortions at 70 MHz MCLK are as follows:

Looks like the accelerator isn't happy at 70MHz. This might be a limit imposed by the RAM, or the ARK1000 itself. That generation of accelerators had no distinction between memory clock and core clock, so the whole accelerator core is clocked at 70 when you change MCLK (and that's why Tseng calls this clock SCLK for "system clock" in their data sheets).

Did you test whether the image gets stable at 1280x1024x256c @ 60Hz with 70MHz MCLK with my modified BIOS? If this improves, the reason for the artifacts is in fact insufficient memory bandwidth. Possibly this can be combatted by re-programming the FIFO configuration of the 1280x1024x256c mode (I would check how to patch the BIOS to achieve it). Maybe the 110MHz modes in the BIOS just don't work, and that's why the Bali card is configured just like the 2themax card?

mkarcher wrote on 2023-10-01, 19:11:

Did you test whether the image gets stable at 1280x1024x256c @ 60Hz with 70MHz MCLK with my modified BIOS?

I remember testing 70 MHz MCLK with 1280x1024x256c-60hz, but the jittery image was still present. No change in appearance. I thought I wrote about this, but looks like I forgot. Thus, I do not recall if I tested it with the original BIOS or the modded BIOS. So I will have to test it again. I'll try 65 MHz this time. :(

mkarcher wrote on 2023-10-01, 19:11:

Please don't write Vsync when you intend to write VCLK. Vsync is usually used for the vertical refresh rate, not for the dot clock.

I agree. It was a typing error as I quickly tried to wrap things up.

feipoa wrote on 2023-10-01, 09:58:

AC:
User WJG6260 owns the printed Bali32 manual. A few months ago, he sent me some select pages concerning the video modes and the 2MB upgrade. Unfortunately, it had been scanned it as large resolution colour images, so the PDF size is too large to attach. However, I have been able to convert it to 1-bit PDF, which is far more ideal. This process was time consuming for me on Linux, probably because I don't have the ideal software. Anyway, here is the conversion:
Paradise_Bali32_select_pages_on_video_modes.pdf

According to the pages from this manual, the RAMDAC equipped is 80MHz, and the modes supported are identical to that of the 2theMax.
Has it been determined if the Bali32 cards with 110MHz are an upgraded version (supporting higher refresh rates), or if Paradise ran out of 80MHz RAMDACs and just used whatever they had lying around? I suspect that the cards were not actually assembled by WDC/Paradise. Probably they all came directly from ARK.

It is possible that the written claim for 1280x1024x256c-60Hz was made in error or was made correctly, but not properly tested. I'm hoping the statement was correct, just that there's something we're missing. I'm going to pull out another motherboard for testing rather than the M919 I've been using.

feipoa wrote on 2023-10-02, 11:42:

It is possible that the written claim for 1280x1024x256c-60Hz was made in error or was made correctly, but not properly tested.

I'm confident that 1280x1024x256c at 60Hz is possible with the ARK1000 chip. As we don't have all the required technical documentation, I don't know yet how this is supposed to work in detail. As this is likely close to the limit of what the chipset supports, the margins are likely quite low. This means we need optimal memory timing configuration, properly adjusted FIFO refill threshold, suitable MCLK and a PCB layout that works good enough at 110MHz pixel clock.

While I currently assume that the issue with the "60Hz distortion" is somewhere between the video RAM and the ARK1000 pixel output to the DAC, I can't be sure whether the issue is improper conservative memory timing due to wait states configured into the ARK1000 chip, insufficiently high MCLK, bad FIFO thresholds in the BIOS, the requirement for RAM chips meeting very specific set-up and hold times, or improper routing or unsuitable termination resistors of the /RAS and /CAS lines. Probably the best way forward would be some experimentation with the chip settings, and especially trying to run the 1280x1024c-60Hz mode at just 1MB video RAM (of course, this will display garbage at the bottom of the screen, or it will repeat the top), to find out whether the issue is just "too much load on the memory bus".

Success!

I'm impressed with mkarcher's ability to view a 1 second video clip of a jittery image and determine the issue was too low of memory clock.

A combination of factors were required for 1280x1024x256c to be realised: faster MCLK, faster FPM DRAM, faster RAMDAC, and a modified VGA BIOS.

A 65 MHz MCLK is required for 1280x1024x256c at 60 Hz. 70 MHz was too fast for my 70 ns Fast Page DRAM modules; there was immediate corruption in the display right at system power-on. Even at 65 MHz with 70 ns DRAM, if left running for a few minutes, I started to see some red pixels appear when moving the Display Properties box around in circles. Refreshing the page fixes it, but it was not ideal. I resolved this by using my 50 ns DIP DRAM and 70 ns SOJ DRAM. I don't have any faster SOJ-40 FPM modules, but I placed some on order.

Will there be any visible benefit in running MCLK at 70 MHz or 80 MHz, like sharper image, less shadowing, etc?

I then tried to run my original ARK1491 RAMDAC instead of the 110 MHz ATT RAMDAC. While it worked for the few minutes I tested it, the texted seemed blurrier and was starting to irritate my eyes.

Next I tried to use the original 2themax VGA BIOS again, with MCLK set to 65 MHz, but it insisted on interlaced mode at 1280x1024x256c.

I tested both the CH9294G-N and ARK1294A clock generators with no discernible difference in output.

The resolution sheet provided in the Bali32 manual states that 800x600x16M colours is possible at 56 Hz and 60 Hz, however I could not get this mode to display. This is the result:

Is a BIOS hack also required for this mode?

For anyone who is interested in running their ARK1000VL at 1280x1024x256c (e.g. because that's the native resolution of your LCD), I am attaching the modification I made following mkarcher's guidance, here:

feipoa wrote on 2023-10-03, 10:48:

I'm impressed with mkarcher's ability to view a 1 second video clip of a jittery image and determine the issue was too low of memory clock.

Thanks for awarding me some extra nerd points 😀 The clue is: The image contents are correct, but some lines are shifted (at least at some point) to the right, by a multiple amount of pixels. If there were issues with the dot clock (VCLK) itself, you would have got single pixel jitter. I didn't count the amount of shift, but as a single pixel is 8 bits, and the memory is accessed in chunks of 32 bits, a single missed memory read would cause a shift of 4 pixels.

That's what happening here: To coordinate the display scanout, the accellerator and the CPU accessing the same video RAM, all "modern" video chips have FIFO buffers, and the memory is read/written at a fixed speed (the memory clock, MCLK). Whenever the display FIFO has "too little data", the display unit request video RAM access to refill the FIFO. The memory unit will "finish what it is currently doing until it is finished or interruptible" and then refill the display FIFO. The nice thing about refilling the display FIFO: The read will access consecutive addresses, which can (most of the time) performed in fast page mode. The time it takes the memory unit to "finish what it is currently doing" takes a fixed number of memory clocks. The time that is still backed by the display FIFO when the memory request starts is a certain (configurable) number of video clocks. If the display FIFO runs empty before the memory unit is ready to serve re-filling the display FIFO, you get a buffer underrun just like you had with old CD writers: The display unit will repeat pixels, display black or display garbage until the FIFO is re-filled. It is the job of the card/BIOS/driver designers to make sure that the refill request happens early enough so that the memory unit is guaranteed to be able to finish its current task and start re-filling the display FIFO. There is an optimal value for the "refill threshold" given the video clock and the memory clock. You want to refill the FIFO as late as possible, because this makes longer bursts, which will improve memory throughput. On the other hand, you must not refill the FIFO later than memory access latency allows.

feipoa wrote on 2023-10-03, 10:48:

A combination of factors were required for 1280x1024x256c to be realised: faster MCLK, faster FPM DRAM, faster RAMDAC, and a modified VGA BIOS.

A 65 MHz MCLK is required for 1280x1024x256c at 60 Hz.

At the FIFO threshold included in your BIOS. This threshold is adjustable. Programming the card to use earlier FIFO refills will allow lower memory clocks, possibly at severe cost of drawing performance, though. As I undestand the ARK chip from reading the X-Server source, the display FIFO on that chip is 8 "words" of 32 bits (4 pixels at 256c), and the BIOS requests a refill threshold of "start refilling when 4 words are free", so refill is requested at 16 pixels still in the FIFO. This threshold is equal for 87i and 60p. You might be able to go back to 55MHz memory clock if you patch 47FF from 0C to something lower (but still 8 or higher). The Linux X Server XFree86 uses 0C as "standard configuration", and uses 0A if you set the option "fifo_conservative". Using 0A at 47FF will be a good start. (of course, you also need to increase another byte by 2 if you decrease this byte by 2).

feipoa wrote on 2023-10-03, 10:48:

70 MHz was too fast for my 70 ns Fast Page DRAM modules; there was immediate corruption in the display right at system power-on. Even at 65 MHz with 70 ns DRAM, if left running for a few minutes, I started to see some red pixels appear when moving the Display Properties box around in circles.

This seems to indicate that reading still worked at 65MHz, but when the accellerator started high-speed writes at 65MHz, the RAM couldn't cope with it. Issues like this are typical for RAM chips that are too slow (and note how "memory chips too slow to follow MCLK" looks completely different from "MCLK to slow to satifsy video output").

feipoa wrote on 2023-10-03, 10:48:

Will there be any visible benefit in running MCLK at 70 MHz or 80 MHz, like sharper image, less shadowing, etc?

As you likely understand by now, MCLK does not directly affect the display. It affects the total available memory bandwidth. If MCLK is high enough for the given VCLK and FIFO refill threshold, the ARK1000 chip produces "pixel perfect output", increasing MCLK further doesn't change anything. So there won't be any image quality advantages by increasing MCLK. On the other hand, the speed of the accellerator scales linearly with MCLK, so the operation of copying a window when "moving it around in circles" gets faster with higher MCLK. Furthermore, higher MCLK allows more aggressive FIFO settings, increasing the band width available to the accellerator (or the VL bus) even more.

feipoa wrote on 2023-10-03, 10:48:

I then tried to run my original ARK1491 RAMDAC instead of the 110 MHz ATT RAMDAC. While it worked for the few minutes I tested it, the texted seemed blurrier and was starting to irritate my eyes.

So it seems that the chip is able to process the digital data at 110MHz correctly (you would get miscolored or flickering pixels if it does not), but the analog output stage is not up to the job for 110MHz signals. This is likely not a "manufacturing quirk", but done on purpose. If you include higher frequencies in the display output, the whole system (graphics card, monitor cable, monitor itself) will radiate more radio interference. To reduce radiated emissions and get FCC certification (or other regulatory bodies around the world), it makes a lot of sense to not create "sharper" signals than required.

feipoa wrote on 2023-10-03, 10:48:

Next I tried to use the original 2themax VGA BIOS again, with MCLK set to 65 MHz, but it insisted on interlaced mode at 1280x1024x256c.

I bet one of the 4.7k resistors on the card tells the BIOS to enable the 110MHz mode. The BIOS will read a configuration strap register whenever you try to set a video mode, and lock out the highest refresh rates on 1280x1024 if it find the "low-speed DAC" bit set. It is likely that R1, R2 and R3 are configuration straps. As R1 is connected to the 0WS jumper, this one is definitely not the 80/110 selection resistor. Usually, configuration straps have internal pull-ups (this is the native behaviour for TTL I/O pins anyway), and the external resistor is a pull-down to ground. As a "zero" in this bit means: "high speed DAC" and a "one" mean "low speed DAC", it is more likely that a "missing" resistor indicates "low speed". If the "left" pad of R2 is connected to ground, the chance is quite high that installing a 4k7 at that position will unlock the 60Hz mode even with the original bios. My BIOS patch makes the BIOS ignore this configuration strap.

feipoa wrote on 2023-10-03, 10:48:

The resolution sheet provided in the Bali32 manual states that 800x600x16M colours is possible at 56 Hz and 60 Hz, however I could not get this mode to display. This is the result:
ARK1000VL_at_800x600xtrue_failure.jpg.JPG

Is a BIOS hack also required for this mode?

800x600x16M is also hidden behind the 110MHz lockout. As my BIOS patch disables the lockout completely, it also enables this mode. The original BIOS without strap adjustment will ignore any request to switch to this mode.

Last but not least, there also is a 1600x1200x256 interlaced mode (mode number 44h) which is also gated by the 110MHz DAC option.

Thank you very much for this level of detail. I'm sure others appreciate it as well.

I will look into R2 and R3. If the configuration strapping has an internal pull-up (like 10K ) to set 80 MHz DAC mode, wouldn't we want this strap to go to GND via a 0-ohm resistor, or at least some resistor value substantially less than the internal pull-up value, to send the configuration to the low state? That is, place 0-ohm on R2? Perhaps the configuration inputs are left internally floating.

The left-most pads for R1, R2, and R3 are GND.

The right pad of R3 goes to ARK1000VL pin 61

The right pad of R2 goes to ARK1000VL pin 62

Someone PM'd me stating that 800x600x16M is the mode of interest for him. Do you think adjusting MCLK further, that is, once I receive 50 ns SOJ FPM modules, will enable this mode to work? Or is it preferred to make adjustments to the byte at 47FF?

feipoa wrote on 2023-10-04, 00:59:

Thank you very much for this level of detail. I'm sure others appreciate it as well.

I will look into R2 and R3. If the configuration strapping has an internal pull-up (like 10K ) to set 80 MHz DAC mode, wouldn't we want this strap to go to GND via a 0-ohm resistor, or at least some resistor value substantially less than the internal pull-up value, to send the configuration to the low state? That is, place 0-ohm on R2? Perhaps the configuration inputs are left internally floating.

These straps are shared with video RAM data pins, there are no dedicated configuration pins. You don't want to have them shorted to ground! The internal pull-up is weak enough to make 4k7 work perfectly as pull-down. Sharing video memory data and configuration straps is an approach also used by S3 (sure) and Tseng (IIRC), you can look at the respective datasheets for confirmation, if you like. I would go as far to call the approach of 4k7 pulldowns on video memory data lines an "industry standard". More pins increased the costs of making the graphics chip (and at 208 pins like the ARK2000, you hit the peak pin count available in mass production for PQFP) and possibly also the graphics card PCB if it needs finer traces to route the extra pins.

feipoa wrote on 2023-10-04, 00:59:

Someone PM'd me stating that 800x600x16M is the mode of interest for him. Do you think adjusting MCLK further, that is, once I receive 50 ns SOJ FPM modules, will enable this mode to work? Or is it preferred to make adjustments to the byte at 47FF?

800x600x16M should work out-of-the-box with my patched BIOS. The byte at 47FF does not affect that mode at all, that patch suggestion was just to lower the MCLK requirement for 1280x768x256c specifically.

I tried the 4 possible combinations for R2 and R3, namely,

R2, R3
open, 4.7K ------> default config
4.7K, 4.7K ------> garbage displayed (see image)
4.7K, open ------>blank screen, beeps
open, open ------>blank screen, beeps

Based on mkarcher's reply, I did not try any configuration which placed 0-ohms on R2 or R3.

Do you think there are any other suitable candidates to enable 110 MHz VCLK with the unmodified VGA BIOS? Looking at other empty 1210 solder pads, there are:

R47
left side of pad is 5V
right side of pad goes to GND on VLB connector

R48
left side of pad is 5V
right side of pad goes to RDYRTN# (Ready Return) on VLB connector

R56 (located under PLL)
these pads have a factory PCB trace connecting them together. not sure why this pad is here

R50
top side of pad connects to 33-ohm resistor (R49), which then connects to ARK1000VL pin 93
bottom side of pad connects to ARK1000VL pin 94

R51
left side of pad connects to 33-ohm resistor (R6), which then connects to ARK1000VL pin 94
right side of pad connects to ARK1000VL pin 93

R52
top side of pad connects to ARK1000VL pin 59
bottom side connects to GND

Other than adding components (as above), there's the option of removing components. The usual suspects being 0-ohm and 4.7K?

0-ohm
R39, R59, R61, (R57, R58, R60 - near VGA conn.)

4.7 K-ohm
R16, R17, R18

feipoa wrote on 2023-10-04, 10:32:

I tried the 4 possible combinations for R2 and R3, namely, […]
Show full quote

I tried the 4 possible combinations for R2 and R3, namely,

R2, R3
open, 4.7K ------> default config
4.7K, 4.7K ------> garbage displayed (see image)
4.7K, open ------>blank screen, beeps
open, open ------>blank screen, beeps

So R3 open breaks the VL bus interface or disables the video BIOS. That's not a configuration bit we are looking fore.

And R2 closed seems to put the card in a completely useless mode. Is that screenshot during the POST or after booting Windows?

feipoa wrote on 2023-10-04, 10:32:

R47 left side of pad is 5V right side of pad goes to GND on VLB connector […]
Show full quote

R47
left side of pad is 5V
right side of pad goes to GND on VLB connector

R48
left side of pad is 5V
right side of pad goes to RDYRTN# (Ready Return) on VLB connector

You are reading the pinout the wrong way. Those resistors do not pull up GND and RDYRTN# (B48/B49), but LDEV# and LRDY#. One usually has pull-ups on these pins on the mainboard. Adding a pull-up on the card might be a customer-specific workaround for a mainboard missing those pull-ups. They are clearly unrelated to the "110MHz" configuration strap.

feipoa wrote on 2023-10-04, 10:32:

R56 (located under PLL)
these pads have a factory PCB trace connecting them together. not sure why this pad is here

Makes no sense to me, too. Furthermore, it is in series with R37, so even if the factory trace was not there, having both R37 and R56 seems pointless.

R50 top side of pad connects to 33-ohm resistor (R49), which then connects to ARK1000VL pin 93 bottom side of pad connects to AR […]
Show full quote

R50
top side of pad connects to 33-ohm resistor (R49), which then connects to ARK1000VL pin 93
bottom side of pad connects to ARK1000VL pin 94

R51
left side of pad connects to 33-ohm resistor (R6), which then connects to ARK1000VL pin 94
right side of pad connects to ARK1000VL pin 93

These seem to make it possible to flip banks 0 and 1. The way the resistors are configured now, the DIP RAM is bank 0 (needs to be present) and the SOJ RAM is bank 1 (optional). If you de-populate R49 and R6, and instead populate R50/R51, the SOJ bank will become the mandatory bank and the DIP bank will become the optional bank.

R52
top side of pad connects to ARK1000VL pin 59
bottom side connects to GND

That one is a possible hit.

Other than adding components (as above), there's the option of removing components. The usual suspects being 0-ohm and 4.7K?

0-ohm
R39, R59, R61, (R57, R58, R60 - near VGA conn.)

R61 is most likely part of a supply voltage filter (you could add some ohms there to dampen high-frequency spikes, especially if a cap on the same line). I get this idea because there is an inductor next to it.

R59 can is a series termination resistor for the pixel clock from the ARK1000 to the RAMDAC. The thick trace clearly indicates this is either a clock trace, a supply voltage trace, or an analog R,G or B trace. R59 is obviously connected to the pixel clock input on the ARK1000, so the purpose is obvious.

I guess R39 is somehow related to the clock generation circuit, so I don't think that resistor will affect the 110 MHz option.

4.7 K-ohm
R16, R17, R18

They are so close to R52 that considering those resistors is worth a shot. On the other hand, they are close to the feature connector. The feature connector needs pull-up resistors on pins 17, 18 and 19, and I suspect those are these pull-ups. They are essential for proper operation of the card if nothing is connected to the feature connector, removing them will possibly cause a lot trouble, but doesn't help with the 110MHz strap.

So adding 4k7 to R52 is the only option that seems valid at the moment.

The LCD image shown above, which corresponded to R2 and R3 both being populated with 4.7K, occurs immediately at system start-up. Sometimes the white background screen would flicker to a teal green colour, but it is off-white most of the time. The blackish noise on the sides changed in location and amplitude as well.

I tried populating R52 with 4.7K, but the screen stayed blank. I also tried removing R39, but the screen stayed blank.

Unless there are any of these locations in which you think 0-ohm would be worth trying instead of 4.7K, it looks like progress was halted until further notice. For the time being, the hacked VGA BIOS will have to suffice.

I will do a little more testing when my 50 ns SOJ-40 FPM modules arrive, just to see where the upper limit on my card is and to see if the garbled screen display at 800x600x16M -56/60 Hz changes any.