The testing can be done by using the TESTVLR utility from my repo: https://github.com/hmatejx/vstr/releases.

Testing instructions:

If settings are found that work nicely on your 1024x768 panel, please report here. Thanks!

I can try it at least with Nec Versa 6200MX

Thanks!

If you need any pointers about how to use the VLRTEST utility, let me know.

Basically, play around with the H, h, L, and l keys (or alternatively +/- keys) and the graphics mode, and see if you get the display maximized. If you can then report back the value of the FR4D register that works best, I can bake it into the VSTR utility as a preset.

I meant TESTVLR and not VLRTEST...

Sorry for the delay in testing, but my laptop is experiencing some problems, possibly due to a faulty memory module, thanks to you I finally downloaded the manual and understood where they are located (under keyboard), I replaced one large 32Mb with couple Nec modules with more common size and reinstall Windows, will let you know after success run test program

I did some testing, for 640x400 and 640x480 I think [10] and [11] values works best for me and here maximum height I can get. For 800x600 it is [00].

How can I check modes loading TSR in actual games?

Or for example can you add this JPEG picture to this test, to see how is it actually looks?

With some options I see weird yellow lines on the left side of the screen:

Thank you for following up, this is very valuable.

I need some time to study your output, any may come back.

Regarding the picture idea, thanks for that as well, I may add an option to show the image instead of the bars.

The bars are useful for me because by zooming in I can see which lines get replicated. The CT6555x chips can only do "replicate every N-th line" for vertical scaling. For horizontal scaling the chip does nearest neighbor interpolation implemented through a phase accumulator. The FR4D register controls them minimum and maximum N for the vertical scaling algorithm, with the chip using the smallest allowed N that still fits the vertical screen size, i.e. 768, or abort the scaling if none fit.

A picture would be also very valuable for a visual judgement which settings result in less artefacts. Because based on the crude nature of scaling, there will always be artifacts. But on a 800x600 screen I can hardly notice them during gaming. Of course I can see them if I look, because I know exactly where to look, but otherwise it is quite OK.

If you want, I can record video what's happen when I change values.

Actually script with automatically checking each value (each 2 seconds, for example) would be easier in use, instead of play with keyboard.

By the way, are you able to adopt yours TSR to Silicon Motion SM712G video chip? Datasheet attached.

I have SM910 inside Asus L7400 notebook, which could potentially be similar and don't have any scale functions 🙁 can't find datasheet for it.

Here some ASM script example to do something with resolution on assembler:

MAZter wrote on 2025-09-05, 01:08:

I did some testing, for 640x400 and 640x480 I think [10] and [11] values works best for me and here maximum height I can get. Fo […]
Show full quote

I did some testing, for 640x400 and 640x480 I think [10] and [11] values works best for me and here maximum height I can get. For 800x600 it is [00].

The attachment 1.jpg is no longer available

How can I check modes loading TSR in actual games?

Or for example can you add this JPEG picture to this test, to see how is it actually looks?

The attachment heroes.zip is no longer available

With some options I see weird yellow lines on the left side of the screen:

The attachment 2.jpg is no longer available

So to confirm, when testing 640x400 or 640x480, the best values of FR4D was [10] and [11]? This is interesting, because this would essentially mean to repeat every line, resulting in 800 or 960 vertical lines. This does not fit into 768 lines of the LCD, and the chip should not do scaling at all when the result does not fit (at least according to the docs).

What would really help is if you could first use the 'w' key and type '00' (two zeros) t the FR4D register, and then use '+' key to increase FR4D from [00] to [11], [22], etc, all the way up to [FF], and observe the result each time.

I will also add another option to the utility to leave the register settings when exiting. This should in principle allow testing in games, no need for a TSR.

Regarding adopting to SM712 / SM910, I could not find the SM910 data book. Comparing the SM721 and the SM712 manuals, at least these use the same scaling logic and control. Maybe this extends to 910, but hard to tell without a document.

I could work on that, but would first really want to finish the CT6555x stuff, because this is something I can actually test, albeit in a limited fashion.

I have released a simplified TESTVLR utility, that can be driven by up and down arrows (+ and - keys still work), and by exiting via the 'x' key, the settings remain in effect, allowing testing in games.

https://github.com/hmatejx/vstr/releases/tag/v0.1.1

These are the optimal FR4D settings on 800x600, and this is how the screen looks

To be honest, I don't see benefits compare VEXP with my 1024x768 screen, and like before, 11 value best for 640x480 or 640x400. For 800x600 best value is 33.

640x480:

640x400 (or 320x200):

800x600:

Additionally I tested utility with Sager Model 86 (800x600, Chips&Tech 65548) and it does not change anything (VEXP tool not working with this model too). It's probably use complete different registers.

And this resolution really bothers me, but I think it's a feature of the laptop model. I will be glad if you expand compatibility with Chips&Tech 65548.

MAZter wrote on 2025-09-06, 23:17:

To be honest, I don't see benefits compare VEXP with my 1024x768 screen, and like before, 11 value best for 640x480 or 640x400. […]
Show full quote

To be honest, I don't see benefits compare VEXP with my 1024x768 screen, and like before, 11 value best for 640x480 or 640x400. For 800x600 best value is 33.

640x480:

The attachment 2025-09-06 19.05.06.jpg is no longer available

The attachment 2025-09-06 19.05.37.jpg is no longer available

Many thanks for the pictures, very revealing and surprising. I don't understand how 480/400 vertical lines can fit into 768 when doubled to 960/800 lines with FR4D = 11. I can clearly see some black border on top and bottom...

According to the CT65550 manual, FR4D = 11 means to insert a repeated line every 1 input line, which is doubling each vertical line.

MAZter wrote on 2025-09-06, 23:19:

640x400 (or 320x200):

The attachment 2025-09-06 19.07.13-1.jpg is no longer available

The attachment 2025-09-06 19.06.31.jpg is no longer available

Thank you also for providing the 320x200 (640x400) pictures. This makes (kind of) sense, and is apparently the maximum the chip can do on a 1024x786.

Let me explain. The 320x200 image gets automatically doubled to 640x400. The horizontal compensation can apparently only do a

• 8 pixels to 9 pixels stretch, a block of 8 pixels p1p2p3p4p5p6p7p8 becomes p1p2p3p4p5p6p7p8p8, a horizontal stretch factor of 1.125.
• 8 pixels to 10 pixels stretch, a block of 8 pixels p1p2p3p4p5p6p7p8 becomes p1p2p3p4p4p5p6p7p8p8, a horizontal stretch factor of 1.25.

This is actually not explained in the manual for graphics modes, and is only briefly mentioned for text modes. I saw this same approach also used for the Silicon Motion chipsets. So my depiction above about which pixel gets duplicated may not be fully accurate. Nevertheless, this perfectly explains the vertical blank border on the left and right. The 640 horizontal resolution (also when using 320x200 because of automatic doubling) input becomes 960, which leaves a vertical border of (1024 - 960)/2 = 32 on each side. This also explains why on a 800x600 panel, there are no vertical blank borders, as the 1.25 horizontal stretch factor fits the common DOS modes perfectly into 800 pixels.

it seems that the CT6555x chips are limited to these factors of scaling and do not do real interpolation 🙁 There is literally nothing I can do to make the vertical borders go completely away on 1024x768, but they can be minimized. Can you please confirm that basically this is what the VEXP utility can already achieve on your laptop, am I getting that right?

Regarding what still does not make full sense to me, is the fact that FR4D=11 seems to work the best, while according to manual, as well as the calculation, FR4D=22 should make the job. Repeating every 2nd line results in a stretch by a factor of 1.5, resulting in 600 vertical lines, leaving (768 - 600)/2 = 84 blank lines on top and bottom. Which corresponds really nicely to what your photo shows.

MAZter wrote on 2025-09-06, 23:39:

Additionally I tested utility with Sager Model 86 (800x600, Chips&Tech 65548) and it does not change anything (VEXP tool not working with this model too). It's probably use complete different registers.

And this resolution really bothers me, but I think it's a feature of the laptop model. I will be glad if you expand compatibility with Chips&Tech 65548.

The attachment 2025-09-06 19.35.07.jpg is no longer available

According to the CT65548 manual, this may not be possible.

While vertical compensation uses the same repeat every N-th line algorithm that can be tuned by changing N, the horizontal compensation only mentions doubling for graphics modes. For text modes it does mention expanding 8 pixels to 9 or 10, but it is not stated if this applies to graphics modes as well.

We could definitely give it a try, but I suspect that both horizontal and vertical compensation are already being used here to maximum effect. What can be done is to reduce the vertical stretching to keep the 4:3 aspect ratio, but that would also make a blank border on top and bottom, basically a 640x400 picture centered within 800x600 😒