OSSC for PCBs

[Harrumph]

Regarding 390, see my old post here:

Tips & Tweaks: Lx3, Lx4, Lx5 modes

Basically, when normalizing the signal for square pixel displays, all various horizontal total widths are converted to multiples of (roughly) 390 (at 59.94/60Hz framerate).

More examples related to your PCBs (note massive use of integer rounding below, numbers not exact):
Square pixel definition: 6.14 MHz = PAR 1 (derived from rec 601 ntsc video, half rate of 13.5 MHz with 10:11 PAR)
NeoGeo 6.00 MHz = PAR 45/44 (i.e. 6.14/6.00); convert samplerate: 384*45/44 = 393
Toaplan2 6.75 MHz = PAR 10/11; 432*10/11 = 393
Espgaluda 10 MHz = PAR 0.614; 640*0,614 = 393

Edit: Note that these have slightly higher value per line, as they all have lower framerate than NTSC video. I guess in this case it would be more appropriate with multiples of 393…

[videogameperfectionrocks]

Ok I will use 1965 samplerate for all boards where I have to use Generic 4:3 mode due to the optim samplerate being out of my monitor’s range.

I’m experimenting with 512×240 optim in 5x so that the horizontal multiplication is 3x. My monitor gets a 1600×1200 signal which I think is due to this (please correct me if I’m wrong):

“With Line5x, horizontal active and mask are adjusted internally so that frame width of 1600 or 1920 (depending on “Line5x format”) is always generated. In 1920×1080 format, vertical active and backporch are also internally adjusted (-24 and +12) to generate suitable frame height.”

So first the OSSC does 3x and gets 1920 dots for Espgaluda (640 * 3 = 1920) and then downscales that by a factor of 1.2 to fit my monitor at 1600×1200 (1920 / 1.2 = 1600)?

I think this looks a little better than Generic mode. Is this process cleaner than the one Generic mode uses?

I’m surprised to see black bars above, below, and on both sides of the image of Espgaluda in 5x and 512×240 optim although nothing is cropped. I tried changing v.active from 240 to 224 and it filled the width of the screen perfectly (in tate mode) but there are still bars above and below the image. Also v.active 224 seems to distort the image by making it too wide and seems to create a pattern which causes some of the vertical scanlines to look darker than others.

I get no signal from Battle Garegga at 5x in 512×240 optim mode with h.active 320. I can’t get an image from it in that mode with any h.active below 448 (and that’s above the samplerate of 432).

EDIT:

I just thought of something. If 5x mode internally adjusts the outputted resolution to my monitor’s native res of 1600×1200, why does a samplerate over 2110 cause the image to distort? Isn’t the samplerate that’s actually sent to my monitor always 1600 in 5x mode?

[Harrumph]

Ah i see whats going on. Its related to your question also:

No it doesnt downscale, 1920 for full line is kept, but it automatically adjusts the h.active from 1536 to 1600. That’s where the black bars are coming from.

[Harrumph]

And to answer your edit: samplerate and active resolution is not the same thing. Samplerate always reflects the full line length. H.active is what determines what goes on the actual screen. The rest is blanking (frontporch, sync, bacporch).

[videogameperfectionrocks]

Now I understand why the black bars are there in Espgaluda in 512×240 optim mode. You mentioned that 1536 is padded to 1600 with blanking but wouldn’t it be 1350 that is padded to 1600 since h.active is 450?

If Espgaluda has 224 lines, why does changing h.active from 240 to 224 cause the image to stretch and fill the full screen width?

Battle Garegga putting out no image with h.active 320 is the biggest mystery. How can I troubleshoot that?

[videogameperfectionrocks]

Regarding the trouble with Battle Garegga, h.active 320 works in all of these modes:

2x 256×240 (horizontal multiplier: 3x)
4x 512×240 (horizontal multiplier: 2x)
4x 320×240 (horizontal multiplier: 4x)
4x 256×240 (horizontal multiplier: 5x)
5x 320×240 (horizontal multiplier: 5x) <– unstable with samplerate above 422
5x Generic

I don’t see why h.active 320 works in 2x 256×240 and doesn’t work in 5x 512×240 since both have horizontal multiplier 3x.

I also don’t see why the image becomes unstable above samplerate 422 in 5x 320×240 and works fine at the correct samplerate 432 in 4x 256×240 since both have horizontal multiplier 5x.

I’m trying to get Raiden to work too. The only samplerates that make sense to me there are these:

( 20000000 / 2 ) / ( 258 × 60.49 ) = 640
( 20000000 / 3 ) / ( 258 × 60.49 ) = 427
( 20000000 / 4 ) / ( 258 × 60.49 ) = 320

But I can see some blinking and out of place pixels in all three samplerates at every sampling phase setting. What am I missing?

[videogameperfectionrocks]

I turned on the crosshatch test pattern in Raiden (reset while holding both start buttons) and with the samplerate at 432 and sampling phase at 157 I don’t see any issues except for positioning. I can’t use 320×240 optim because the samplerate will multiply too high for my monitor and in 512×240 optim I tried to lower h.active from 512 to fix the positioning but I get no image below 364. Very similar behavior to Battle Garegga in 512×240 optim which leaves me at another dead end unfortunately.

[Harrumph]

I don’t see why h.active 320 works in 2x 256×240 and doesn’t work in 5x 512×240 since both have horizontal multiplier 3x.

I also don’t see why the image becomes unstable above samplerate 422 in 5x 320×240 and works fine at the correct samplerate 432 in 4x 256×240 since both have horizontal multiplier 5x.

Well it’s not samplerate by line that matters really, but rather the total pixel clock. I was talking only in context of x5 line multiplication earlier, so it was implicit, sorry if that confused you.
422*5*263*5*59.37 = 165 MHz
432*5*263*4*59.37 = 135 MHz

And as a comparison, the pixel clock of VESA 1600×1200 is 161MHz, so it makes sense at some point above that your monitor does not accept the signal anymore.

You mentioned that 1536 is padded to 1600 with blanking but wouldn’t it be 1350 that is padded to 1600 since h.active is 450?

Correct, I forgot that you had changed the h.active already.

If Espgaluda has 224 lines, why does changing h.active from 240 to 224 cause the image to stretch and fill the full screen width?

That is your display scaling. You’re telling it ”vertical height is 1120” and your display says ”I better stretch that to full (1200) height”.

[videogameperfectionrocks]

Got it, thank you. That all makes sense to me.

The OSSC not putting out a signal at lower h.active values in 512×240 optim is blocking this project. Could it be an OSSC bug? How can I unblock this and get back to posting PCB data?

[videogameperfectionrocks]

I have Raiden looking perfect like this:

Line5x mode 320×240 optim.
Sampling phase 202 deg
H. samplerate 384
H. backporch 24
v. backporch 8

I stumbled upon that samplerate accidentally. I think this means the dotclk is 6Mhz:

6000000 / ( 258 × 60.49 ) = 384.457

But how could that dotclk have been calculated from the MAME sources?

https://github.com/mamedev/mame/blob/master/src/mame/drivers/raiden.cpp

[videogameperfectionrocks]

I think I have definitive evidence that the problem I’m having with Battle Garegga is an OSSC bug.

The following settings display the full image but it is squashed vertically:

Line5x mode 512×240 optim.
Sampling phase 202 deg
H. samplerate 432
H. synclen 41
H. backporch 46
H. active 450

Lowering h.active causes the OSSC to stop outputting an image at all, unless I increase h.synclen and h.backporch like this (although then about 25% of the image is cropped from the bottom and it is still squashed vertically):

Line5x mode 512×240 optim.
Sampling phase 202 deg
H. samplerate 432
H. synclen 75
H. backporch 77
H. active 320

In both cases my 1600×1200 monitor reports it is receiving 1280×1200 resolution which should never be the case in Line5x mode:

“With Line5x, horizontal active and mask are adjusted internally so that frame width of 1600 or 1920 (depending on “Line5x format”) is always generated.”

http://junkerhq.net/xrgb/index.php?title=Optimal_timings#Horizontal_multiplication_factors

Can we agree this is an OSSC bug?

[Harrumph]

Not a bug. You are sending a signal that has too low samplerate to ever be 1600 horizontal active.
432*3 = 1296

The output is not valid, you get a negative frontporch.
To get a valid mode, sync and h backporch need to be less than 112 together (so that h frontporch can be at least 1).

You are trying to use a mode which is not really intended for such low samplerates, nor the aspect ratio of that video. If the signal is multiplied 5x vertically, but only 3x horizontally, it will be way way too skinny (or not tall enough, in the case with TATE game content, which is exactly what you describe already).

[videogameperfectionrocks]

Is there anything I can do to get a board with samplerate 432 (or anything between 423-532) working in a Line5x optim mode on a 1600×1200 monitor with 2110 maximum samplerate?

Also if multiplying this board’s image by 5x vertically and 3x horizontally throws off the aspect ratio, why does it retain the correct aspect ratio with other boards (Espgaluda for example)?

[marqs]

The sum of horizontal active, synclen and backporch should definitely not exceed samplerate, otherwise all kind of undefined behaviour may occur. If 2110 samplerate is the maximum the monitor can accept, then I’d recommend just using Generic mode or line4x for those boards where optimal samplerate is 423 or higher. Line5x 512×240 with 320 H.active might work with valid synclen+backporch, but even then you’d end up with width of 960 so the monitor would need to be able to stretch that properly.

[videogameperfectionrocks]

It’s tough to go back to Generic after getting used to optim mode which looks incredible. 4x isn’t an option due to higher lag (surely from my monitor).

Strangely, dropping h.synclen any lower than 75 or h.backporch any lower than 77 kills the video output from the OSSC if h.active is 320. I wish I could get a small image in optim mode while still sending my monitor 1600×1200 to keep lag low.

Is a 4x horizontal multiplier possible for Line5x mode in the future?

[Author]

Posts