SiDi128: rotate module using the second SDRAM by robinsonb5

[gyurco]

Credits to Alastair M. Robinson (https://github.com/robinsonb5/) for his rotating scandoubler extension, using the SDRAM as a framebuffer.

[gyurco]

I noticed that some cores use a DIPBASE=8, which is not good, since many options are in the 8-15 range, so I removed them (need new MRAs, too, but AFAIK they're automatically updated).

[jotego]

I have to review it but removing the dip base should be ok. That macro comes from the old times when MiST could not handle so many dip switches.

The CPSx cores timing is failing. We need the timing to be clean before merging. 🙏🏼

[jotego]

And thank you!!

[gyurco]

They failed even before, for ages. It can be made clean, with "STANDARD EFFORT", but it slows down the compiling a lot, so we agreed to not apply it some time ago.

[jotego]

But the daily compilation works. So I think it is the PR content. If using standard effort works, we could enable that for compilation with the JTFRAME_RELEASE macro set.

[jotego]

If my understanding is correct, this uses the second SDRAM chip and does not interfere with the operation of the first SDRAM chip. Is that right?

[jotego]

On MiSTer, there is a way to disable the display of this line when the game is not vertical. So a core that handles both vertical and horizontal games only displays it when needed.

[gyurco]

There's no feedback to the OSD from the core in the MiST firmware. It won't be hard to do it, just the urge wasn't too strong to implement it.

[jotego]

This requires unsetting it manually on the horizontal games.
Maybe this could work instead:

`ifdef SIDI128
`ifdef JTFRAME_VERTICAL
`define JTFRAME_SDRAM_ROTATION
`endif
`endif

Added to the relevant files.

Another option is to have jtframe add it conditionally for SIDI128+JTFRAME_VERTICAL compilations. This function will need to be modified. I think modifying jtframe is cleaner.

[gyurco]

It won't do any harm on non-vertical games, but I can disable it for them, also.

[jotego]

One more question, this only affects the HDMI output, right? The regular VGA output will be kept as it is, isn't it?

[gyurco]

It rotates the scandoubled output, so HDMI and VGA are rotated. 15kHz video is unchanged.

[gyurco]

If my understanding is correct, this uses the second SDRAM chip and does not interfere with the operation of the first SDRAM chip. Is that right?

Yes, that's true. The only game which already uses the second SDRAM is Outrun, but rotating is not needed for it.

[gyurco]

But the daily compilation works. So I think it is the PR content. If using standard effort works, we could enable that for compilation with the JTFRAME_RELEASE macro set.

You meant with JTFRAME_RELEASE?
As with the PR's, they already failed:
#898

[gyurco]

This one:

{{ if (index .Macros "JTFRAME_RELEASE") -}}^M
set_global_assignment -name OPTIMIZATION_MODE "HIGH PERFORMANCE EFFORT"^M
{{ else -}}^M
set_global_assignment -name CYCLONEII_OPTIMIZATION_TECHNIQUE BALANCED^M
{{ end }}^M

doesn't seem to work:

set_global_assignment -name CYCLONEII_OPTIMIZATION_TECHNIQUE BALANCED^M
.
.
.
set_global_assignment -name VERILOG_MACRO "JTFRAME_RELEASE=1"

[gyurco]

It works with jtcore -d JTFRAME_RELEASE=1 ..., but not with jtcore -d JTFRAME_RELEASE ...

[gyurco]

Added a patch to CPS, which eliminates the worst paths starting from rst_video. Now it builds well with -d JTFRAME_RELEASE=1

[jotego]

Thank you!
JTFRAME_RELEASE=1 was already set by jtcore --nodbg so we should be good to go

[rp-jt]

Hello @gyurco,
I'm trying to test this, but I don't see any changes when I select "Screen Rotation: Yes" in the SiDi128 menu for the latest compile all.
Is there any further step I should do?

I'm using VGA output with scandoubler

[gyurco]

Hi,
In which game did you try?
Maybe you have to update the MRAs/ARCs, too, because of the removing of JTFRAME_DIPBASE from some cores.

[gyurco]

Just took this screenshot from current master from cps2:

[jotego]

I can confirm it work.