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 https://shmups.system11.org/viewtopic.php?p=1391686#p1391686 )
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 
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?
2 Likes
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 https://www.bandainamcoent.co.jp/cs/list/guncon/bce.html. 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.
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.
http://drhell.web.fc2.com/ps1/
https://problemkaputt.de/psx-spx.htm#graphicsprocessingunitgpu
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.
https://www.zophar.net/fileuploads/2/10731bgqkx/playstation.htm
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.
2 Likes
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.
2 Likes
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:
Hey all. Finally attempting to get around to replacing the Extron DSC 301 HD that I had that seems to have died out unfortunately. I was using the device to take the 960p signal of the OSSC and scale it to 1080p for my TV to work more easily with. I may consider just buying another but I thought I’d ask if any of you know of a device that may be able to accomplish the same thing for cheaper. I tried a little HDMI powered DVDO Micro scaler but it didn’t seem to want to attempt to scale the 960p signal at all.
1 Like
So I finally discovered that the issue I was having with my N64 was caused by my Otaku Games Switch.
It’s no longer accepting the RGB sync on luma signal, and just outputs a buzzing blue image but I borrowed a SCART to BNC break out and hooked it up directly to my 20L2 and it worked first time with no issues. The interesting thing is that all my other consoles work, I’ve mixed and matched inputs, tried a new cable, a new power supply.
I’ve started the return process with Otaku games so it will be interesting to see how this pans out. I’ll be sure to post my experiences here.
1 Like