X300 w/DVI-to-component + emucrt drivers=15khz goodness??

[dmarcum99]

I was wondering if anyone has taken the plunge and tried to get a X300, X600, or X1050 to display 15khz on a TV using the DVI-to-component dongle??  Would there be any reason these would not work since these cards use the same core as the radeon 9500, 9700, & 9800's(R300)??

I was thinking that Calamity's drivers might work since you're taking a signal from the DVI and outputting....just like using a DVI-to-VGA adapter...

I just ordered an ATI dongle to experiment, but I have to order another X300 as the one I just bought only has VGA.

[Calamity]

I guess you mean one of these: http://www.monoprice.com/products/product.asp?p_id=2398&seq=1&format=2

Well the specs explicitly talk about certain radeon models and drivers, so it's probably software driven to some extent, but who knows. However it doesn't look like a proper transcoder could fit inside that, I'd say that some specific drivers use the analog R-G-B pins in the DVI to output component signals natively, so if that is the case then it won't work with other cards than the ones designed for it.

[Mo]

I've gotten one of those adapters to output 240p component on an x700 card after a bunch of tinkering around in Powerstrip, so it's possible to some extent.     I'm still running into problems I haven't been able to solve, though, which I'm hoping someone can help me with.   

The issue I'm running into is that once I switch over to the 240p mode the driver seems to become really unstable.   Windows itself works fine at 320x240 desktop resolution, but if you change resolutions after that the system freezes, even if you're trying to go back to a standard mode.    Also, any program or emulator that attempts to Vsync with DDraw or D3D freezes, which makes the whole thing pretty useless really.     I'm open to any suggestions..  I'd hate to quit now after getting a nice 240p picture on the screen. 

My setup:
Windows XP x64
x700 PCI-E card
crt_emudriver 6.5 (also tried 9.3)
Display is a Sony KV-24FS100

[Calamity]

Wow, that's really odd. If you post your Powerstrip's custom timings for that 240p mode, it might give us a clue (just paste the line here with the numbers, there are some clipboard icons in Powerstrip that let you copy this).

[Mo]

I'll paste the whole thing even though it's basically the same info 4 times.

Code: [Select]

PowerStrip timing parameters:
320x240=320,56,48,88,240,4,3,15,8048,278

Generic timing details for 320x240:
HFP=56 HSW=48 HBP=88 kHz=16 VFP=4 VSW=3 VBP=15 Hz=60

VESA detailed timing:
PClk=8.05 H.Active=320 H.Blank=192 H.Offset=40 HSW=48 V.Active=240 V.Blank=22 V.Offset=4 VSW=3

Linux modeline parameters:
"320x240" 8.048 320 376 424 512 240 244 247 262 -hsync -vsync
It doesn't quite fill the screen horizontally on my tv because it won't accept changes that take it below an 8Mhz pixel clock, but I'm not really worried about that at the moment. 

[Calamity]

Ok, just some ideas, probably wrong...

Well the x700 doesn't support low dotclocks under Windows, that may be part of the problem. You can set "DotClockMin = 8.0" in vmmaker.ini and recalculate the modes. That will duplicate the width of low resolution modes in order to keep above 8 MHz. Emulators like MAME can then just scale the width seamlessly without artifacts.

That said, I can't see anything special in that modeline that would make it work while the others don't. I'm not sure how you are testing this. After creating the modelines, try selecting 640x480@60 for the desktop, and the reboot, but do this with only the CRT attached, NO LCD or PC monitor attached or its EDID will ruin our settings. The idea is use the driver's native modelines, not Powerstrip.

Also, launch dxdiag and check that DirectDraw's and Direct3D's acceleration are enabled (this is for the vsync issue).

[Mo]

Well, the mode I'm using has a dot clock a bit over 8Mhz, and the same freeze problems occur using a squished (big front/back porch) 240p mode with ~13Mhz dot clock, so I don't think that's the cause.  Good to know that the issues I had going below 8 were due to the Windows drivers, and the MAME resolution workaround will be handy if I ever get the rest to work.   

I haven't been able to get it to display anything but 640x480 interlaced without using Powerstrip, even though all the 15khz modes are listed when looking with arcade_osd and other tools.   Lower resolutions it will put centered on the 640x480 output with huge black borders, and higher resolutions it goes into panning mode around the larger desktop.   This includes booting up with only the component connector connected.   I think at this point it's something to do with the driver trying to treat it more like an s-video tv out than vga, and it may not be something fixable.

Dxdiag is reporting acceleration enabled for d3d and ddraw.  It completes its test fine as long as I haven't switched it into a 240p mode with powerstrip, in which case it will complete the first two tests that are overlaid on the desktop then freeze the system when trying to change to a full screen resolution like everything else does.


I'd be just as happy sidestepping all these Windows issues by going with Linux, but I haven't the slightest idea how I'd enable the component video out on the card under Linux, if it's even possible.  It seems like the Windows drivers is somehow triggering the switch to YPbPr video out of that port, so unless the Linux driver developers have figured that out there may not be a way.   The GroovyArcade live disc just looks like it's outputting RGB over the component connector, for what it's worth. 

[Calamity]

I think at this point it's something to do with the driver trying to treat it more like an s-video tv out than vga, and it may not be something fixable.

Yes, that's probably it. When the component ouput is active, the drivers are probably forcing 640x480 and resampling everything, that's too bad. Powerstrip works because it's bypassing the driver and reprogramming the CRTC on its own. But because 320x240 uses a different frame buffer size than 640x480, this probably leads to a unstable situation.

You may have better luck with an external transcoder.