[Papercut]

Understood.

The lower resolutions such as 1080p are also more unstable for me with 0.61 and 0.62 though, but obviously not as bad.

[Papercut]

I thought I’d tweaked the settings more, but the only significant change from default is turning frame lock off, and using 60 Hz fixed frame rate for scaling. I tested again using only that change.

0.61 behaves consistently as described, it takes about 120 seconds to lose sync while scan lines slowly start drifting right. If I then power cycle, it takes about 15 seconds to lose sync again. Lower output resolutions above 720p will also occasionally lose sync, but don’t drift right in the same way.

0.60 is rock solid, no sync loss at all unless the mega drive is turned off (and even then not always).

0.62 can’t manage 2560x1440p at all, and the other resolutions above 720p occasionally lose sync similarly to 0.61. I updated both the rbf file and u-boot.scr files.

I’m beginning to wonder if my display is part of the issue, a Samsung S95B, but then 0.60 doesn’t seem to have any issues with it. I’ll try with a PC monitor instead if I get the chance.

[Papercut]

Thanks for responding again @marqs

I’ll try once more with 0.61, I suspected perhaps throttling as the problem appeared worse after power cycling, but it’s possible the sync didn’t hold as long for whatever reason the second time around, making it seem worse. It does sound like like the sync loss due to heat that you describe in fact – I’ll check if this happens consistently.

I’m using generic 4:3 input, and 2560×1440 output options with the scaler, and I’ve tweaked the input sightly for the Mega Drive. I’ll check the full config and post the details here, thanks.

*Edit* A-ha, I’ll check 0.62 at the same time, cool.

[Papercut]

Hi @marqs, that’s right I have applied the GPIO tiedown mod, which resolved instability with the scaler on 0.60.

The instability in 0.61 is very different, the image drifts right horizontally from the bottom of the frame without losing sync and without the same kind of jitter, when first powered up, until after a few seconds when the sync is lost.

This is what made me think it might be performance related, it’s as if each line isn’t being rendered in time, and performance is being throttled more as the FPGA heats up – this is obviously just a guess on my part though. Power cycling doesn’t help much, sync is then lost almost immediately.

[Papercut]

Performance seems to take a hit for me with fw v0.61 compared to v0.60 and earlier – higher scaler resolutions begin drifting horizontally to the right as the de10 nano heats up, until sync is lost. This is particularly noticeable on 1440p, with 1080p a little unstable.

Is anyone else experiencing this?

Switching back to v0.60 brings back stability to the scaler.

[Papercut]

Thanks, that change has made scaling mode just as stable as line multiplier mode for me now.

[Papercut]

Some Dreamcast 240p games actually run at 640×240. From what I could see the games tend to be 320×240, but menu’s, text overlays etc. sometimes run at 640×240.

After forcing third strike into 240p with Start+L, these settings worked for me:

Sampling Opt.
– 480p in sampler: DTV 480p

Adv Timing: 512×240
– H. samplerate: 858
– H. synclen: 62
– H. backporch: 106
– H. active: 640
– V. synclen: 3
– V. backporch: 14
– V. active: 240

Sync opt.
– H-PLL Post-Coast: 1

Output opt.
– 240p/288p proc.: Line5x
– Line5x mode: 512×240 optim.
– Line5x format: 1920×1200

You could actually optimise this further for most 240p Capcom games, as they draw something like 614×224, rather than using the full 640×240 display. I think the horizontal resolution is integer scaled internally from 384×224 to 614×224, without interpolation, so it is always going to look a bit inconsistent.

[Papercut]

Nice, I’ll try that.

For me 3x doesn’t look very different to the Retrotink in line doubling node, slightly softer than using the OSSC maybe, but better video quality/less jitter when connected directly.

512×240 optimised in the latest firmware might be a good fit though, I need to give that a go.

[Papercut]

Were those captured using the OSSC in 4:3, or one of the optimised modes? Did you try optimised, or tweak any of the sampling options?

[Papercut]

I’ve been playing around with the OSSC + Retrotink2x with a PAL C64 (Reloaded Mk II) too.

The main thing I was interested in was trying to get optimised mode setup. I think I have something, but the picture isn’t clean enough over using the Retrotink2x on it’s own – which does a pretty good job with s-video.

The settings I have for optimised are:

Output opt.
240p/288p proc.: Line5x
Line5x mode : 320×240 optim.
Line5x format : 1920×1080

Sampling Opt.
Adv Timing
320x240LB
– H. samplerate: 504
– H. synclen : 63
– H. backporch : 31
– H. active : 384
– V. synclen : 3
– V. backporch : 36
– V. active : 240

Is there a better optimised configuration? Perhaps we need something like 384×272 optimised, which is meant to be the maximum drawable area of the C64 display.

This config is a bit weird because of the way 1080p mode works in 5x, it fills the 16:9 frame by chopping off quite a bit of the horizontal borders. The aspect ratio isn’t right, but it is surprisingly close.

If you wanted 320×240 Optim. in one of the other line multiplier modes, you’d probably need to set H. active to 320, and H. backporch to 63 for it to work (or stand a chance of it working – only 3x did for me), although that cuts off the vertical borders completely.

I think some horizontal tremor is introduced by the HDMI->VGA adaptor and the C64 Reloaded itself, but I don’t know which is most to blame. The Retrotink2x by itself produces a much steadier image, and I haven’t experienced the same kind of shifting as demolition.

Also a GameCube over composite with the same setup (Retrotink2x > HDMI-VGA Adaptor > OSSC) was much steadier in 240p, not perfect, but much less ‘interference’ at pixel edges than the C64.

[Papercut]

@eric90000 yeah, in reply to your question about the KS7000 – I’ve not had any problems with the 1220 firmware.

All the previous modes I was using work (2x, 5x), but as I say I’ve not tried the SNES since, which occasionally de-syncs because of the known jitter issue. That is most likely to be affected, if anything.

*EDIT* No issues with the SNES either, other than occasional sync drop out on the TV.

2x, 3x, 4x, 5x all work for me on 240p sources as well, and passthru for some systems – same as before 🙂

[Papercut]

I’ve not had any issues with Master System, Mark iii, and a GameCube.

I haven’t tried the SNES since updating though, which is the most finicky.

What have you heard?

[Papercut]

I’m able to run NTSC-U Uniracers on my Super Famicom without any problems, using OSSC 1.6 (so 0.78-aud firmware) on default settings, and a Nintendo RGB cable (rewired from JP-21 to Scart).

It was called Unirally in Europe, so I can only assume the NTSC version was being used here. I don’t think it was released in Japan.

[Author]

Posts