DExx-vd_isl fw 0.61

[marqs]

DExx-vd_isl firmware v0.61 is now available for download. Most relevant updates since last release include

* added 240p/288p/480p/540p CRT output modes and 1920x1080i mode
* fixed Pure LM processing for 256col modes
* fixed some aspect ratio calculations
* added auto mode for YPbPr source colorspace
* fixed manual phase adjustment for oversampled modes

Links to a few recent topics related to DExx-vd_isl are add below which might be interesting read for owners of the board:
Using DExx on DE10-Nano GPIO1
Horizontal jitter issue and suggested fix

[b0nz0beavis]

I’ve tested the 540p scaler options on my HD CRT, I’ve updated the feature request topic with some feedback.

It would be good if any other owners could test with a NA version of the Sony HD CRT, something like a XBR960 with the HDMI processing bypass. My set is the OCE equivalent (KV-HR36M31) that has the SFP tube but a different chassis that does not have HDMI. So my testing is limited to the component and RGBHV inputs.

[ShllShockArcade]

Running latest firmware and don’t seem to be getting an image while in either scaler mode or line multiplier mode for TMNT arcade PCB.

Running through HAS SuperGun 8-pin mini din to RGB input on the Dexx, hdmi out to my lcd tv. All other PCB’s work in scaler and line multiplier. What could cause this?

Note: TMNT PCB works fine in my arcade cabinet w/ wells Gardner k7000 series 15khz crt

[BuckoA51]

Do you get a black screen or just no signal? Can you open a new thread for that?

[ShllShockArcade]

I get a black screen. Audio of the game still playing in the background. I’ll open a new thread, thanks Bucko 👍🏼

[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.

[marqs]

Additional logic (Interlacer IP) was added on the scaler path for 0.61 which might have had an effect. I’m currently looking if scaler pipeline clock frequency could be reduced to improve stability since overall the issue is worsened by additional switching / power draw (for this reason simpler LM mode is much more robust). Sacrificing 1080i input support would enable reducing clock from 148.5MHz to around 120MHz which could help.

@Papercut: you have applied the GPIO tiedown mod mentioned earlier, right?

[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.

[marqs]

Image getting corrupted / drifted to right after certain scanline sounds like scaler/memory performance issue, but there shouldn’t be any thermal throttle that would make it temperature-dependent. Logic itself gets slower at higher temperatures, but in worst-case that could just lead to timing violations which usually have different appereance (sync loss could be one, though). Which input preset and output mode are you using when that happens?

I’m currently working on a fw which should reduce power consumption a little by reducing clock frequency on HPS side and scaler pipeline if possible. Not sure if that will have a big impact on robustness, but small things like these are best that can be done right now.

[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]

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.

[marqs]

2560×1440 output is not officially supported since it goes way beyond HW capabilities. Any time even a minor RTL change is made, compilation can result to very different timing due to how the Quartus PnR engine works so unfortunately it’s very hard to replicate a ‘working 2560×1440’ configuration for updated design. I only checked 2560×1440 stability on GPIO1 variant of the firmware running on my DE10-Nano and had no issues, but the situation with the standard fw could be different.

[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.

[marqs]

There is still some room for improving performance of the processing pipeline so things might get better in future releases, but testing capabilitity is at limit here. Every numbered release should be compiled (and ideally tested) for 3 different OSSC Pro HW revisions, 2 DE10-Nano configurations and a couple other dev boards…

[spacetime66]

* added 240p/288p/480p/540p CRT output modes and 1920x1080i mode

Is these modes using Adaptive line multiplication?

Will this mode allow an OSSC Pro to output 1080p as 1080i virtually lag free?

• This reply was modified 1 year, 10 months ago by spacetime66.

[Author]

Posts