opinion on this VGA box?

[alexh]

They say CGA but they really mean 15KHz analog RGB.

As for the 16-bit vs 24-bit, I'd have to see what chip was inside. From Ambrey's response I'd say it is a 16-bit Averlogic AL250A with an AL875.

It says "Automatic 50Hz to 60Hz conversion". That is going to make your scrolling suck, but at least it will work on all LCDTV's

[alexh]

Dont you just love technical responses from non-technical staff who's first language isnt English!

so the sample rate of 8-bit is applied for most instances

Sample rate, yeah sure ;-)

[alexh]

Muzungu wrote:
It uses a 16MB SDRAM chip (W9816G6CH-7) for buffering.

That rules out an Averlogic AL250 as it has the RAM built in.

Muzungu wrote:
MST9883C-LF

A 9883 chip is a triple 8-bit ADC. (It converts analog RGB to Digital).

Muzungu wrote:
I used SotB as my test game figuring that its touted 50 fps frame rate [snip]things in motion seem fairly smooth. [Snip] scrolling text (during the between level segues in SotB) was not as smooth as it could've been, due to separation, ghosting and shimmer.

I would recommend a smooth scroll text in a demo to see the effects of the scandoubler on motion.

Does this scandoubler always output 60Hz? If that is the case, the conversion of 50Hz input to 60Hz output will explain why the scrolling was not smooth.

Muzungu wrote:
In workbench I detected a slight ghost trail behind the pointer, likely the result of lossy compression.

Scandoublers don't compress. If you were in a non-interlaced mode, no idea what it could be.

Muzungu wrote:
Slight color separation is noticeable in hard edges

I think you'll find this is a side effect of the conversion from analog to digital and back to analog.

Muzungu wrote:
At 60Hz

Amiga at 60Hz, or scandoubler at 60Hz?

[alexh]

Muzungu wrote:
The ghosting looks exactly like video compression; my guess is that something funky is going on in the DAC, although this device could possibly be using compression in order to maintain performance by sacrificing video quality.

No scandoubler uses compression. Why would it? The only reason would be to save RAM or bandwidth. Both of which in the case of a scandoubler are MUCH MUCH cheaper than video compression/decompression hardware.

Muzungu wrote:
It uses a 16MB SDRAM chip (W9816G6CH-7) for buffering.

A scandoubler requires approximately 3 lines of 24-bit video, 720*24*3 = 0.42Mbytes. Flicker fixer needs much more 720*576*24*3 = 3.56Mbytes. Both are well below the 16Mbytes in this scandoubler. That chip is 16-bit and has a max effective clock rate of 100MHz = 200Mbyte/sec.

This system has more than enough memory and more than enough bandwidth not to need to compress video.

Muzungu wrote:
HP's RGS-based thin client systems use this to maintain frame rate, so it's not out of the question.

Yes it is out of the question. The system you describe uses a medium which is neither dedicated, nor high bandwidth. A scandoubler doesnt suffer from such constraints. It has it's own dedicated RAM interface which can run at full video speed!