Support of Amiga 50 Hz ECS clock frequencies?

[mutedsounds]

Can the RGBtoHDMI support the Amiga ECS Super High-Res modes, 1280x256 and 1280x512 ?

According to this thread https://eab.abime.net/showpost.php?p=1251298&postcount=13, the ECS Super High-Res pixel clock frequency is doubled, to 28375160 Hz.

Creating a new profile derived from the Amiga_2000_50Hz.txt profile, doubling the clock frequency and setting the clock multiplier to x6 doesn't seem to be sufficient to get a stable image using auto-calibration. Did anyone succeed to define working settings to support the Super High-Res modes?

[IanSB]

@mutedsounds

Can the RGBtoHDMI support the Amiga ECS Super High-Res modes, 1280x256 and 1280x512 ?

In theory it should be able to support higher resolutions like that and 640x480 progressive but only with CPLD based hardware (not the c0pperdragon style board) and then only at 6 bits per pixel or less rather than the 12 bits per pixel of of 640x256 / 640x512 interlaced. I don't have any ECS type hardware myself so I've never been able to test it but if someone with suitable hardware and a CPLD based RGBtoHDMI wants to do some tests, I could create a few profiles to try.

[mutedsounds]

@IanSB I installed a CPLD-based RGBtoHDMI board in the RGB slot of an ECS A2000. I can test somes profiles if you wish. I also have an oscilloscope if necessary.

You will find attached three photos of the Super Hi-Res:

• Super HiRes Amiga 2000 14MHz: with the standard Amiga 2000 profile, this looks like there is a (expected) horizontal 1:2 sub-sampling

• Super HiRes Amiga 2000 28Mhz 12bpp, copy of the standard profile with the clock frequency forced to 28MHz 12 bits per pixel, it seems the video doesn't sync well horizontally; I tried to play with the geometry and sampling parameters without much success

• Super HiRes Amiga 2000 28 Mhz 6bpp, copy of the standard profile with the clock frequency forced to 28MHz 6 bits per pixel, the video syncs well horizontally, however for some reason I couldn't figure out yet, the Pi reverts to the standard Amiga 2000 profile when I quite the menu

[IanSB]

@mutedsounds

Here is an experimental profile:

Amiga_1280-test-v1.zip

Unzip and put the Amiga_2000-1280 profile in the /Profiles/6-12_BIT_RGB/Commodore folder (Assuming latest stable release which has a new folder structure) Then select the Amiga_2000-1280 profile from the select profile menu.

You will probably have to adjust the h offset in geometry and h pixel offset in sampling to get horizontal alignment especially if using a 1280x1024 monitor.

If the screen flashes then there is something wrong with the timing. Post the source summary page and also read the Help flashing screen page in the info menu.

[mutedsounds]

@IanSB Impressive. It is stable. Thanks a lot.

At this resolution, is it possible to raise the number of bits per pixel to 12? Or is there a way to avoid manually changing the profiles when an app lowers the width to 320 or 640?

[IanSB]

@mutedsounds

At this resolution, is it possible to raise the number of bits per pixel to 12?

No, the max clock for 12bpp is around 16Mhz, (32Mhz for 6bpp, 64Mhz for 3bpp etc.)

Or is there a way to avoid manually changing the profiles when an app lowers the width to 320 or 640?

As the 320/640 modes have the same sync timing as the 1280 modes there is no easy way to auto detect and switch between them but there is an option to make manual switching a little easier: In general any profile can have two timing sets and this is used with some systems like the BBC micro (where modes0-6 and mode7 use different clocks) and Apple IIGS (there are 16Mhz and 14Mhz modes) but there are ways to auto detect and switch between those sets. However there is also a manual mode where pressing SW3 toggles between the two timing sets and I have enabled that with this profile:

Amiga_1280-test-v2.zip

Set1 = 1280 modes Set2 = 320/640 modes

Press SW3 to toggle

If you can vary the timing for the 1280 modes e.g. by changing the number of lines per frame by a couple of lines or changing the number of clock cycles per line then it should be possible to auto detect them as the timing will then be different between the standard 320/640 modes and the modified 1280 mode.

It would probably be useful to add the 640x480 mode as well so can you switch to that mode and post the source summary page for that.

EDIT: Changing the sync polarity might also work for identifying the two profiles

[mutedsounds]

@IanSB You will find attached some preliminary settings I found to view the ECS Productivity 640x480 @ 60 Hz using the 1280 mode. These may not be the optimal settings. However there is an unexpected artefact on a line (this artefact doesn't appear when using OSSC):

[IanSB]

@mutedsounds

I think the glitch is some sort of memory bandwidth contention between the screen DMA and the capture code. I have seen a similar but less significant glitch with the 1280 modes. This is likely because of the higher bandwidth of the 28Mhz pixel clock. I will have to investigate this but in the meantime you can try varying the following in the settings menu to see if it helps: Changing the Genlock Line may move the glitch up or down and possibly off screen. Changing the overclock settings may eliminate or reduce it.

[mutedsounds]

@IanSB I confirm. Changing the Genlock Lines moves the glitched line up or down. Setting the core overclock to 100 makes the glitch disappear (at 90 the glitched line is still there).

[IanSB]

@mutedsounds

It looks like it is caused by the start of video display DMA which due to the ~3.6ms latency affects capture of a line part way down the screen. Does changing any of the other overclock settings have an effect (i.e. Core or SDRAM) or any combination that results in a lower CPU overclock?

I will see if it is possible to fix this without the overclock but at least that is available as a workaround.

BTW I don't think this glitch would occur with a Pi zero 2W or Pi 3 as they have much higher overall system bandwidth.

[mutedsounds]

@IanSB I made a mistake in my previous comment. It was the core overclock and not the cpu overclock. I edited my previous comment to correct it.

I tried several combinations of the CPU/Core/SDRAM overlocking parameters. The only parameter which resolved the issue is the core overclocking. The CPU and SDRAM overclocking didn't resolve it. Once the core overclocking is set to 100, the glitching line no longer appears.

Could the Pi Zero 2W also enable the support of 12-bit per pixel at 28 MHz ?

[IanSB]

@mutedsounds

Can you try the Alpha 59E release here: https://github.com/IanSB/RGBtoHDMI/issues/18#issuecomment-1634837666

This has some changes to the Amiga 2000 profiles that might eliminate the glitches without overclocking.

[IanSB]

@mutedsounds

The latest beta now has ECS support: https://github.com/IanSB/RGBtoHDMI/releases

Additional info: This supports PAL 1280x256 and NTSC 1280x200) plus the 640x480 productivity mode as well as the standard 640 pixel modes. (Also includes the interlaced variants of those modes)

The 1280 pixel modes only support 6bpp rather than 12bpp used in the 640 pixel modes but from the info I have seen online, the ECS chipset is limited to that in 1280 modes anyway. Unfortunately it is not possible to auto detect between 640 and 1280 pixel modes so you have to manually select the right timing set using SW3 or the menu option (640x480 should be auto detected) Set1 = 640 pixel modes Set2 = 1280 pixel modes

[mutedsounds]

Hi @IanSB I apologize for my late reply. I missed the notification from GitHub. The new modes work fine. Thank you very much for your support. I could get a Pi Zero 2W. Do you know if it is possible to increase the sample rate to 12bpp in 1280 mode with a Pi Zero 2W?

[IanSB]

@mutedsounds

I could get a Pi Zero 2W. Do you know if it is possible to increase the sample rate to 12bpp in 1280 mode with a Pi Zero 2W?

No, The GPIOs on all the Pi models are limited to about the same max frequency which is around 16 Mhz @12bpp and 1280 would require around 28Mhz

You can switch between Set1/ Set2 using a voltage level on the unused Vsync input by setting Auto Switch to "Sub + Vsync" rather than "Sub + Manual" (assuming composite sync is used for the actual video signal) so if you can find or generate such a voltage level on a spare output port with a software driver in the Amiga that changed state between 640 and 1280 modes you could get fully automatic switching.

[mutedsounds]

@IanSB Thanks a lot for your explanation. I was in hope the GPIO rate was improved enough in the Zero 2W.

I don't know if that is actually doable with the CPLD : could there be a way to use both edges of the PiCLK, sampling on the rising edge and on the falling edge using parallel processes in the vhdl code, providing 2 pixels (2x12 bits) per cycle on the Pi side through the remaining unused GPIO ports (0,1,14,15;19,20,21,22;24,25,26,27)?