Retro AV |OT| RGB, CRTs, Upscalers, and more

pSX, which is what i’ve been using to test, misreports 384 and 368 which is why it’s not on the list atm. Need to use another testing method to double check every game i’ve got as 384. I don’t personally know any games that use it, so I obviously haven’t tested one.

Oh, i’m pretty sure games don’t actually use 224 verticle resolution, either. It’s just a smaller active area. At least that’s the impression i get going through various games and looking at old documents. Not sure, though, my understand of the underlying tech is woefully insufficient to actually confirm anything against tech specs.

This is a confusing one as the PS1 definitely has a 384 mode, yet in a discussion on the Mednafen forums about the PS1 aspect ratio the admin who I can only presume is the main dev doesn’t mention it but “366(approx.) width” when going through the supported modes.

Yet in the forum for the emulator you are currently using 384 is the mode that is mentioned.

My hunch is that the horizontal resolution is 384 but like you said the active area is another thing altogether, which is why people report 368 for Tekken 3 and X-Men vs SF.

368 would also not draw into the overscan area like 384 does, you crop 8 pixels from each side so that could well be why that visible area is used.

That’s fantastic - I used the same debug menu in pSX to get the internal resolution. I’ll go through my collection but I think you’ve already got all of them in your document.

My suspicion (propelled by Dark Aries’ own theorizing) is that either 364/366/368 are the result of rounding errors in 384, OR they are all smaller active areas which are programmed as 384. The confusing bit is that some games will give different results across emulators. So one game might show 368, 364, AND 366 depending on the software.

1 Like

Please test anyway if you can. All the information i have is from older resources or testing with an emulator, so if you can verify either using a different emulator (if so, please tell me how you checked resolution, they can misreport or are hard to find the function), or an actual OSSC (you can use the timings on junkerHQ’s OSSC optimal timings page for a PS1, or my PS2 timings here )

1 Like

Unfortunately I sold my OSSC. But prior to that I was using the pSX debug window to check the resolution and I had four (or five I can’t remember) pre-made PSX optimal timing profiles (320x240, 512x240, 384x240 etc) that I would switch to when I booted the game, I was using CDRs at the time so I’d just scrawl the resolution on the top but I also have an excel spreadsheet somewhere.

Anyway, keep up the great work!

if you find that spreadsheet, please share!

1 Like

I’ll have a dig around - I thought it was on my Google drive but I think it’s still on my laptop which my partner is using to work from home at the moment.

That said it wasn’t as detailed as yours - I only notated the gameplay resolution and didn’t bother noting things like 480i menus etc.

1 Like

anything that helps to check against error is helpful.

1 Like

Hello everyone, first time poster here :slight_smile:

I have a modded Playstation and a US copy of Point Blank.
I dug up my old CRT and hooked up my console and, of course, the image is in black and white.
I have another adapter that shows the correct colours, but I can’t use it with the GunCon, since it needs the composite cable yellow component to work.
What options do I have to play with colours, beside finding another CRT?


What’s the other cable? If your PS has the multi AV port I think you can use the SCPH-1160 adapter similar to the third picture here I haven’t tried this myself but was looking up the info for how to play Guncon games in RGB a while ago.

Thanks for the reply.
My other cable is a scart cable like the one in this picture (it’s not the original one, but I think it works the same way).

My Playstation has the AV Multi OUT, I will try to find the SCPH-1160 adapter, as you recommended. :slight_smile:

Was looking at some emu docs and like Mednafen both Xebra and Nocash make no mention of 384 at all, only 368. This is also reflected in the width option that Xebra allows you to select from in the video options.

The Nocash one is interesting as 368 is set apart from the other horizontal resolutions but I’m not bright enough to parse the rest of the text beneath it to work out why!

The weird thing is that emulator docs seem to always mention 368 but more general overviews like the below always mention 384 instead.

yeah I recently moved to Xebra for testing, and noticed this as well. I’m pretty sure they’re the same thing, but I can’t explain why there’s such confusion in terms between the two. This is helpful, though, thanks.

In the nocash doc it lists the 10 resolutions possible on the PSX GPU. Framebuffer section quite near the top.

H: 256, 512, 320, 640, 368
V: 240 or 480

(368 having a horizontal frequency of 7.603200MHz)

The “bit” (1, not 0) that activates 368 mode is nothing of concern IMHO. Imagine it like a dip switch, for 368 it needs to be on (1 ) and for all other horizontal modes it needs to be off (0).

A little lower down it also mentions dot clocks, where Namco GunCon chip has a slightly higher frequency of exactly 8.0MHz and scans 385 horizontal pixels.

This implies that an emulator whose GPU code isn’t absolutely accurate could produce different horizontal scan line widths. To get 384 horizontal width, the frequency would be 7.933774MHz.

I would say 384 is a mistake that has propagated.

1 Like

more and more this seems to be the case from looking around, and having the more math-y aspect explained to me. One of those long-lasting myths around retro A/V it would seem. Appreciate you guys talking it over. I’ve decided to use 368 in my spreadsheet. I think there might be games that use something a bit weird that isn’t typical 368 (Tekken 3 was giving us really odd numbers, for example), but that’s TBD.

Otherwise, while there are quite a few games that use a million resolutions (I’ve seen games which are regularly using as many as 4 resolutions, including interlaced ones), things seem to stay within the described spec for the most part.


The PS1 outputs horizontal padding with every single resolution. You can see this in Mednafen as by default it shows this in the 4:3 frame, which is why in the earlier link I posted people were saying it was incorrect by showing a diamond shaped bios logo and too skinny aspect ratio.

“By default, Beetle PSX includes horizontal padding (black bars or ‘pillarboxes’ on either side of the screen) to emulate the same black bars generated in analog video output by real PSX hardware. This horizontal padding can contain garbage pixels that are generated when the game’s width mode is smaller than the display area width in the emulated GPU registers.”

The crop over scan option removes this padding and makes all the resolutions display correctly at 4:3, showing you only the active area. You can see this yourself with Xebra as 368 crops and misaligns the image with Street Fighter Zero 3’s arcade resolution mode whereas Medanfen with crop overscan off displays it correctly.

So I don’t think 384 is a mistake but a resolution that can only be achieved if you go beyond what is the normal active area for that mode and draw into the padded area. Something that as far as I can tell only Capcom did for a very small number of games.


Good catch! The nocash document says Pandemonium 2 uses a larger width, but doesn’t specify exactly what that is. Do we know?

384 being the total and 368 being active makes sense to me, and would explain the confusion, yeah. given 368 seems to be the ‘official’ spec, I’ll keep with that.

I haven’t checked Pandemonium 2 but it was referenced as exceptional in another document I saw, too. Guess I should do that.

1 Like

If the time sleuth is too expensive for you, there’s also a nearly free if more time consuming alternative using a raspberry pi: