Amiga Support 3

[c0pperdragon]

Amiga Support 3

[andriodious]

@c0pperdragon

Before I saw the above post I had a chance to run my A500+ this evening and the resulting pixel perfect profile was a default build i.e. "Leading with -ve PixClk" edge sampling, but with a delay of 2 instead of 3 with the A500.

Amiga_ECS_Denise.txt

I tried the Amiga_LeadingEdge_+ve.txt and had to adjust the delay to 3 which is hopefully consistent with what was expected between the A500 with a delay of 3 but using the Leading -ve edge.

[c0pperdragon]

I am trying to find one setting that works both with the Denise as well as the SuperDenise. If my other considerations are correct, it can only be one of the +ve variants.
As Leading Edge does not work for this (SuperDenise needs delay 3, Denise needs delay 2). maybe Trailing Edge is different. It is a bit hard to reason through this complex signal timing. Please try "Trailing +ve". Also tell me which horizontal offset you need to set for this (if it is different from my profile).

[c0pperdragon]

I am still struggling to understand the sync timings on your machine. An oscilloscope view of csync in respect to CDAC would really be helpful. Maybe your ECS Agnus is really different in some unexpected way...

[andriodious]

Sure I can scope these out but will be tomorrow night at the earliest. Will post a waveform.

[IanSB]

If you switch to trailing edge, you will need to adjust H Offset in the geometry menu to compensate for the picture shift.

[IanSB]

I always thought that +ve would mean the rising edge of the pixel clock and -ve is the falling edge.

That is what it is supposed to be and I couldn't see anything obviously wrong in the code. However, as the timings for this are so marginal, the response to the edge might be delayed enough that it appears to be responding to the other edge.

[c0pperdragon]

Maybe I am still making the wrong assumptions here. Let me explain how I envisioned the Pi software to work:
A tight loop reads the GPIO (all pins at once) and as soon as it detects that the pixel clock input has a different value than at the previous read it also uses the other bits as data. I am pretty sure this is how the color data input is working.

For the sync detection I assumed the same thing: Read until the clock changes to positive (the +ve option) or to negative (the -ve option) and then use the (already received) sync signal to determine what to do next.
If this assumption were correct, the "-ve" option would be safe to avoid jitter. And also the SuperDenise adapter board should work with the same settings as the board for the Denise.

As these results are now obviously not true, something else must be going on. Maybe you are doing it this way instead:
Poll the GPIO pins until the first time the sync is low (assuming the "Leading" option here) as well as the pixel clock is high (assuming the +ve option). This is then the synchronization point.

The difference between the two methods is quite subtle, but the second can lead to glitches because the pixel clock input changes just a bit later (a few nanoseconds) than the sync input. This delay is by design to make the color inputs always stable when the sampling takes place. The second method could well do the sampling just in the small time slot where sync has changed, but the clock not yet. This could lead to jittery sync in certain combinations (specifically "Trailing -ve" on a standard Denise board).
This jitter would be on top of any jitter that could additionally be introduced by the adapter board latching the sync signal at a "dangerous" point. As it now looks (assuming your are indeed using the second method here), this was never an actual problem and I was chasing the wrong issue, while this theoretical issue can very well become visibile on some other matchines.

The takeaway of all this is, that when you indeed use the second method I can not find a really "safe" sampling configuration any more, as I am now constrained in too many ways.

[IanSB]

For the sync detection I assumed the same thing: Read until the clock changes to positive (the +ve option) or to negative (the -ve option) and then use the (already received) sync signal to determine what to do next.

Yes, that's correct for simple mode with no CPLD however, reads of the GPIOs are relatively slow so there may be only one or two reads per half cycle so the actual sampling point when it detects the edge change could be sometime after the edge has actually changed.

Poll the GPIO pins until the first time the sync is low (assuming the "Leading" option here) as well as the pixel clock is high (assuming the +ve option). This is then the synchronization point.

This is more or less how the normal CPLD reads work because the sync pulse and regenerated clock are not phase locked but the CPLD stalls the clock for a few cycles after the sync edge so there are no glitches. I tried this first with simple mode but it always had glitches so had to switch to the first method instead.

As these results are now obviously not true, something else must be going on.

As mentioned above, due to the slow GPIO reads, if only one read is made per half cycle, worst case it could be detecting the +ve edge change immediately before the clock goes low again.

It won't work at all with a 16 Mhz pixel clock (8 Mhz psync) unless you overclock the core which speeds up GPIO reads. You can change the core clock in the settings menu.

[IanSB]

Looking at the code again, the edge detection may be the wrong way round. It enters the loop with the correct edge state set in a flag but it gets inverted before doing the comparison.

[c0pperdragon]

Actually the buffer board latches the color signals as well as the csync signal, so your read loop should only run into troubles when taking more than 70ns twice in a row. Still, all that is very hard to reason about in conversation.
Maybe you can point me to the actual program code responsible for doing this?

[IanSB]

The capture code is here:
https://github.com/hoglet67/RGBtoHDMI/blob/dev/src/capture_line_fast_simple_16bpp.S
Most of the macros are here:
https://github.com/hoglet67/RGBtoHDMI/blob/dev/src/macros.S

The mistake was setting PSYNC bit in R3 to the required edge when it should be the inverted state as there are two uses of WAIT_FOR_PSYNC_EDGE_FAST, the first waits for the wrong edge and the second waits for the right edge.

I have fixed this on my system but not committed the code yet. The fix effectively only changes the text so that the same profile will work on the older code and newer code without requiring any changes although the text will only be correct on the newer code.

[c0pperdragon]

Very good that you solved this strange mystery.
I had a quick look at the code to understand this better and I it is basically as I imagined.
So with the current software +ve is the "safe" point, which will turn into "-ve" with the next software version.
One thing about the implementation: You need to do quite some bit reshuffling to get the 12 input bits into the correct positions. Maybe for an internal Atari ST variant, you could feed the relevant bits directly to the most suitable GPIO pins to save some instructions. Don't know if this could be just enough to match the time budget without overclocking.

[c0pperdragon]

@andriodious
With the +ve / -ve confusion finally cleared up, I think I also understand the differences between Denise and SuperDenise a bit better. As it looks, the SuperDenise generates the color signals about 35 ns earlier. With the other clock input (I will build a board with a jumper to select the type) the sync signal and the color clocks are then out of phase by one pixel.
This normally makes no real difference, except for 1280x1024 resolution. There manual adjustment of the delay value is needed.

[andriodious]

Okay cool, thanks both. I assume you don't still need me to disassemble my A500+ and scope out the SYNC and CDAC. If you do please let me know as I need to find some time now over the weekend to do that.

[c0pperdragon]

Actually I would still like to collect data on the behavor of Agnus variants. I have a 8372A, so there is no need to test this. If you happen to have different versions, it would be very useful to gather data for these.

[andriodious]

I have 8375R0 as well as the 8372A

[c0pperdragon]

Measurements of the 8375 would be very appreciated If you could scope the relation of both the falling and the rising edge of CSYNC to the CDAC clock.
I then would only need measurements of the 8371 to get a fairly complete picture of the PAL variants

[andriodious]

Sure, might be a couple of days as I am travelling ATM

[c0pperdragon]

It is really not urgent. It would just be nice to have confirmation that my assumptions are correct in this regard.

@IanSB - I can see on the picture of your Amiga that you actually have an 8371 Agnus chip! Would you mind, to also scope the signals, I am interested in? This would then give a pretty complete picture (for PAL variants at least).

[IanSB]

@IanSB - I can see on the picture of your Amiga that you actually have an 8371 Agnus chip! Would you mind, to also scope the signals, I am interested in? This would then give a pretty complete picture (for PAL variants at least).

OK

Do you know anyone with an NTSC Amiga who might be interested in testing this board in 60Hz modes as the profiles will need changing for 525 line sources?

Same with the other systems, do you know anyone that has built your YUV mod for 525 versions of C64 or Atari that might be interested in testing it with RGBtoHDMI?

FYI the software can auto select profiles if they have different frequency sources. You create a folder in the appropriate profiles sub-folder and put all the profiles you want to auto switch in that sub-folder and the software will pick the one that matches in incoming frequency and sync polarity. This was primarily used for IBM PC mode switching but could also be applied to 50/60 Hz versions of other computers like the C64.

If I can get the auto display mode selection working, this would mean the entire solution would be then be fully auto detecting.

[c0pperdragon]

Unluckily I have no contact with anyone with an NTSC Amiga.

About the C64, there are the creators of the BeamRacer (https://beamracer.net/) - @madhackerslab, who basically have all conceivable variants of the C64 and also installed and properly tested my mod board. Maybe they would also be interested to attach the RGBtoHDMI as an add-on.

Autodetecting the monitor resolution and using it in 50Hz would be so cool.
Input frequency detection is also a good thing for a plug-and-play solution, but actually less important because this would not change after an install. It is fairly easy to provide two different software versions.
My main intention here is of course to have a solution that does no longer require to adjust any settings. So no need to install the button in addition to the HDMI connector and no need to give the users too much possibility to mess up.

One small annoyance is still this one-pixel offset of the SuperDenise. There is absolutely no way the Pi could auto-detect this based on the signals alone. As I need to change the adapter board anyway I could set some configuration pins, but I doubt you still have any free pins. So yet another software setting - this already gives 4 different combinations.

[IanSB]

As I need to change the adapter board anyway I could set some configuration pins, but I doubt you still have any free pins.

It might be possible as there are several unused GPIOs in simple mode.

[laubzega]

Re: Amiga NTSC - as long as you have ECS, you can switch frequencies in software:

move.w #0,$dff1dc ;NTSC mode
move.w #$20,$dff1dc ;PAL mode

I remember using it back in the day to give games that 60Hz arcade look. :)

I will gladly test RGBtoHDMI with C64 VideoMod, if you can send the board to me - I am too overloaded to build it myself right now. I can provide my own Pi, though.

[c0pperdragon]

I happen to have an Amiga 500, Rev.6 which already has the Agnus 8372A. Does that mean, I can already switch to 60Hz mode with this software switch?
I haven't done any programming on the Amiga since 1995 or so. Will get an assembler first...

[c0pperdragon]

I have come up with a solution for an adapter board that can be configured with a single jumper. In one mode it works like the current board (for use with a Denise). In the second mode (for use with SuperDenise) it will not use the _CDAC (normal board) or the CPU clock (andriodius' modded board), but the inverted CPU clock instead.
From the perspecitive of the Pi, the pixel clock is then in the same phase relation to the color signals as usual. And when using the right configuraiton for the csync sampling, the trigger also happens at the same relative position.
When the other Agnus variants are not too different (we will know when we have the data for this), the software can work identically with both configurations.

[c0pperdragon]

I found out that by shorting pin 41 of my Agnus during reset I can start up with 60Hz mode. The Pi can handle this quite well already,- after re-adjusting all the geometry of course.
There is one strange thing, though: The outmost pixel of the right overscan area actually alternates between blue and black. Need to investigate how the Agnus generates the csync in thos situation.

[IanSB]

Does an NTSC Amiga have a different pixel clock / different number of clock cycles per line as those will need to be set in a proper NTSC profile as well but your pin 41 tweak should allow the H & V offsets in geometry to be determined.

[c0pperdragon]

By dividing the offiical NTSC line frequency by the quart frequency used in NTSC machines, it actually should have 455 clocks per line in contrast to the 454 clocks of PAL machines.
The strange jagged look of the rightmost color column (low-res) is not some bug of your Pi software, but is actually present on the color signals, as my scope showed.
By reducing the visible range to 712 pixels, this is hidden anyway.

You mentioned something about having two configurations from which the Pi automatically takes the correct one depending on input frequency. How can I set this up exactly?

[IanSB]

it actually should have 455 clocks per line

If that value is set wrong you get sampling errors which show up as vertical columns of noise in the pixels.

How can I set this up exactly?

I just did some checking and found the auto switching didn't like composite or interlaced syncs (it was designed for PC syncs).
I've fixed that so you will have to update the kernel for this version:
kernelrpi.zip

Before creating the auto switch folder you must make sure your profiles are setup correctly and at the moment they most likely won't be as the lines_per_frame setting in the geometry menu will be wrong.
On the 625 profile it's currently set to 312 but it looks like the Amiga uses 313 lines for progressive mode so change that value. and save the profile. You will have to make a similar change in 525 as well (When you change that value some status info is shown at the top of the menu which shows the number of lines detected so you can use that to set the value - should be done in progressive mode)

Create a folder called "Amiga" in \Profiles\Simple and put both your saved 625 and 525 profiles in there (remove any existing profiles from \Profiles\Simple but leave default.txt). You will also need to create another file in the "Amiga" folder called "default.txt" containing the following line:
auto_switch=1

After rebooting, the software should auto switch between 525 and 625 and it will show the profile it has selected in the sub-profiles line. (You may get a flashing screen if it can't find any match.)
Post any profile folder you come up with and I'll add it to the next release.

[c0pperdragon]

I followed your instructions and have created this auto-switching profiles.
Amiga.zip

This works perfectly now. I did actually not expect the Pi to switch the resolution at arbitrary times, but yes, this works. I can easily force the Amiga into a different mode on each reset (not only on power cycle) and this works just great with the upscaler.
It seems it is not even necessary to exactly configure the line length and lines per frame values. By having everything locked to the pixel clock, the sampling is very reliable.

Now, the only missing piece in the puzzle for a true no-hassle, plug-n-play solution would be autodetection of the screen resolution. For 60Hz this works very good already. Even if there is no screen attached at power-up the software just retries detection until a screen is present. This auto-detection mode already somehow works for my 50Hz amiga, but then of course there is no genlock and the scrolling is stuttering.
I have no idea, how difficult it is to add a "Auto (50Hz)" resultion option. It is perfectly fine to manually set this option at installation time (probably by patching the SDcard content of no button is installed). For your unified RGBtoHDMI software release it may probably be better to keep the Auto (60Hz) setting if this is the standard.

[IanSB]

You can actually get the video output to auto switch between 50 & 60 Hz.
First select the 60Hz version of the resolution in the main menu and exit to reboot, then go to the settings menu and change "Genlock Adjust" from "-5%to+5%" to "Full Range" then save settings. You will have to do this for the 50Hz profile.

After that, the genlock code will slow the HDMI pixel clock down until the output goes from 60Hz to 50Hz. You can use this to track any input refresh rate but it may not always work because it produces very non-standard timings which some monitors can't lock.

You can also try the other way: i.e set the display mode to 50Hz and change the 60Hz profile to Full Range but this is not advised when using 1080P50 because that mode has the same pixel clock as 1080P60 but with huge front porches and when speeded up it will exceed original HDMI pixel clock standards. Slowing down 60Hz is safer as you are not overclocking the HDMI signal.

EDIT:
Actually if you leave the resolution on "Default@60Hz" in conjunction with "full range" that will give you your full auto everything but it might not work on all monitors.

[IanSB]

Here is an update with full auto resolution/refresh support.
There is a new resolution file: "Auto". Put that in your resolutions folder and update the kernel file.
When that resolution is selected it overrides the Genlock Adjust setting and uses the Default resolution from the monitor so it will always follow the source frequency. If you can't get a display on a particular monitor then hold down the menu button during power on and it will set the resolution back to Default@60Hz:
kernelrpi.zip

[c0pperdragon]

This automatic mode is absolutely awesome!

I did test it with 7 different devices with all 4 Amiga display variants: 50Hz/60Hz, Interlaced/Non-interlaced
Three 1280x1024 displays
Two 1920x1080 displays (one of which is a TV)
One 1680x1050 display
One HD capture device.

Everywhere the Pi detected the correct native resolution with the capture device working at 1920x1080.
60 Hz output worked on all devices without issues.
50 Hz did not work on two of the 1280x1024 displays. But there also manually selecting the correct 50Hz mode did not help. One of those displays just had a black screen with an error-message. Most annoyingly, the second display could actually show 50Hz without any glitches, but it kept displaying a box with "Invalid frequency" bang in the middle of the otherwise perfectly working display.
Most interestingly the HD capture device would only with with 50Hz when it was nearly exactly this frequency. Progressive mode from the Amiga did not work (having one line too much every second frame), but with interlaced mode, the frequency was correct. When manually setting the output to 50Hz but running the Amiga at 60, the capture device also worked, as then there was no genlock and the 50Hz were also hit exactly.

My conclusion: Automatic mode is perfect for all devices I have tested it with. Where this did not work, there was no other way to make gen-locked 50Hz work, anyway.
It seems that the output devices just do not care about the pixel clock or relative size of the front porch. The thing that really matters is the frame rate and the resolution. Maybe the line frequency is also important, but by just slowing down the official 60Hz modes this seems to be OK. Looking through some modeline tables, it seems that the vertical distribution to vsync, back porch, image, front porch are more or less identical for different frame rates.

[IanSB]

Most interestingly the HD capture device would only with with 50Hz when it was nearly exactly this frequency

You can actually get a true 50Hz output if you want to capture the Amiga:

1. Set 1080P 50Hz output mode and reboot
2. Go into settings and change "V lock mode" from Genlocked to Unlocked.
3. Optionally set Num Buffers to "Triple Buffered" also in the settings menu to hide tearing

The output should now be exactly 50Hz and there will be no genlocking so it won't change frequency.
As the input and output aren't locked there will be tearing and this can be eliminated by increasing the buffering to Triple Buffered but that will also increase the lag to several frames. With the buffering, you will get frame drops or repeats instead of tearing.

50 Hz did not work on two of the 1280x1024 displays.

Old HP monitors seem to be the best for 50Hz, my HP LP2065 1600x1200 DVI 4:3 monitor has no issue displaying 50Hz modes.

My conclusion: Automatic mode is perfect for all devices I have tested it with

Do you want this to be the initial mode on first install? The only disadvantage is that if the monitor you are using doesn't support 50Hz you won't get an output at all unless you hold the menu button down on power up to set Default@60Hz.

[c0pperdragon]

No need to make my capture device work with slightly off 50Hz. As it is not cabable to record this, anything we would force on it would always lead to tearing or frame jumps. This is just not he kind of perfection I want to achieve. As the capture device is a pretty cheap one and actually captures only every second frame in 1080p anyway, there is no need to support it.

These monitors that refused to work with 50Hz were pretty cheap ones and I actually don't see the reason why their engineers chose to arbitrarily refuse 50Hz. On one it is obvious that it would work perfectly well, would not the error message now be in the way.

The automatic mode is perfect and should be default. To provide users a 60 Hz fall-back, holding the button at startup is pretty usable. But it should not have a permanent effect, so at next reboot it would again be in auto mode.
To still keep installing a button optional, I would recommend to any user who has the problem, to just put a jumper on the button contacts. I don't know what the software does in the case of a permantently pressed button. Maybe showing and hiding the menu all the time? If you could fix this detail, this would then be the complete solution.

[IanSB]

But it should not have a permanent effect, so at next reboot it would again be in auto mode.

OK here is another update and two resolution files:
kernelrpi.zip

Put the two auto files in the resolutions folder, delete the old Auto one and update the kernel

The two Auto resolution files work as follows:
Auto@50Hz-60Hz - restricted so it can't go above 60 Hz.
Auto@Unlimited - no limits on input to output tracking.

The reason for the two options is that if you input a >60Hz source (e.g. 70Hz) into a system with a DVI or HDMI v1 monitor it will try to generate a video signal that will exceed DVI and HDMI v1 specs and not be displayed. This happens on my vintage PC with EGA/VGA output when VGA text mode is selected. This allows the 60Hz CGA and EGA graphics modes to genlock while still giving a usable output with VGA text. If your monitor will work with later HDMI specs then you can try the Unlimited option.

In simple mode:
Auto@50Hz-60Hz will be selected as the default resolution when holding the menu button down during power up.
Also holding the button down during power up temporarily restricts the genlocking to the old +-5% so you will only get 60Hz genlocking.
Power cycling after the above will return to normal Auto@50Hz-60Hz mode and you can also fit a link that will permanently restrict genlocking to 60Hz (the permanent button press is ignored by the menus).

In normal mode, holding down the menu button selects Default@60Hz as before.

[c0pperdragon]

I have tried this and it works very nicely.
Will the Auto@Unlimited then be the default option on a clean install? So for a capable monitor this is a perfect all-in-one configuraiton. Permantenly switching to the Auto50Hz-60Hz mode with the emergency-fallback makes no difference on the Amiga as its framerate does not exceed the limits anyway. The additional effect of also disabling gen-lock is what we need here.
So this solutions now seems to cover all possibilities.

[c0pperdragon]

I habe already designed and ordered an adapter board PCB that supports SuperDenise as well. If this works, I will make a pull-request to include this also in the RGBtoHDMI repo.

The Amiga-Digital-Video repo needs some update as well, with better installation instructions and all. If this is OK for you, I will try to send samples to some Youtube channels for review to get a bit more attention for the solution. As my own contribution was actually fairly small, I will just promote it as the RGBtoHDMI upscaler project.

[IanSB]

Will the Auto@Unlimited then be the default option on a clean install?

Yes, but in a slightly modified way. Here is the updated version to try:
kernelrpi.zip
As before, replace the kernel and auto files with the new ones.

This version can now read the EDID and will only try 50Hz modes if the EDID indicates that 50Hz will work. This is a bit more "failsafe" so you will be more likely to get an image on the screen after first install but there will be some monitors that will work at 50Hz even if the EDID indicates otherwise so there are now 3 Auto modes:

Auto@50Hz-60Hz - reads the EDID and only selects 50Hz modes if the EDID allows it.
AutoForce@50Hz-60Hz - Ignores the EDID and always selects 50Hz modes if required.
AutoForce@Unlimited - Ignores the EDID and always selects any output frequency if required.

The default will be Auto@50Hz-60Hz as both simple and normal boards share the same new install default.
In normal mode, that will also be selected on menu-reset, however in simple mode for the Amiga, menu-reset will select AutoForce@50Hz-60Hz which means if you put the link on you will force 60Hz modes and then subsequently removing the link will force 50Hz modes.

Also note some monitors will accept forced 50hz input but do an internal 50-60Hz conversion before display so you still get frame judder on smooth scrolling and there is no benefit from using 50Hz. e.g Dell 2007FP (1600x1200)

Can you test this with your monitors, especially the ones that didn't give a display at 50Hz.

[c0pperdragon]

Before doing a new test run on all monitors (it is quite a hassle to set this up all over again), I would like to clarify and discuss the possibilities a bit.

An important thing for the solution to work as I envisioned is that adding the jumper link should be fully reversible. If the behaviour is different after temporarily installing the jump link, this becomes incredibly hard to troubleshoot.

So maybe this solution is possible (considering the Amiga mode without menu only):

By default the board uses the safest approach and will only allow the use of the output frequencies (and resolutions of course) explicitly listed in the EDID. It will also directly use the specified timing parameters for maximum compatibility. But it will allow the +-5 genlock, even if this means that some stubborn devices will not handle it.
It should even switch between supported output modes when the incomming signal changes between 50Hz and 60Hz (could be happening because of a hardware mod or even by software alone).

Installing the jumper should force a complete lock to input frequency. I guess this could be done as before by just using the 60 mode definiton from the EDID (60Hz must be supported at least for some resultion) and slow it down or speed it up as necessary. Adding the jumper will not have any lasting effect, so after removing it and restart, the board is in the previous safe mode again.

[IanSB]

By default the board uses the safest approach and will only allow the use of the output frequencies (and resolutions of course) explicitly listed in the EDID

It doesn't exactly do that, it just checks that 50Hz is supported because it won't be using the actual 50Hz preferred timings listed in the EDID, just the 60Hz timing slowed down so there is still a slight possibility that the monitor won't display the 50Hz output. The above solution allowed a reasonably failsafe starting point and then allowed the option to force 60 or force 50 without using the menus.
I could revert the link behaviour to the previous way, so fitting it forced 60Hz but there would be no way to force 50Hz without using the menus.

Installing the jumper should force a complete lock to input frequency

Then there would be no way to recover if there was no output with the link removed.

[c0pperdragon]

Somehow this gets a bit too "hacky" already.
What about this approach for the jumper: Providing two distinct Amiga configurations (each with two sub-modes).
When the pulldown resistor is present then, either the one or the other is pre-selected, depending on the jumper (or mode-switch) at startup. No write to the SDcard will ever take place only because of the jumper setting.

You can have a genlock mode (selectable by the configuration) that would follow a 50hz input only if the monitor supports 50hz at least in some way. The "safe" Amiga profile (without jumper) would use this.
A full range genlock and the +-5 could be other possibilities, with the "precise" Amiga profile using full range genlock.
In any case, 50hz would always be done by slowing down the 60hz video mode.

[IanSB]

A full range genlock and the +-5 could be other possibilities, with the "precise" Amiga profile using full range genlock.

To select which option to use in "precise" mode you would need to use the menus or edit config.txt on the SD card in which case there seems to be no point as you can select exactly what you want in the menu anyway.

I have reverted to operating the same as normal mode
i.e. default to Auto@50Hz-60Hz which selects 50Hz if EDID supports it and holding the menu button / link reselects that mode if you have changed it and temporarily forces 60Hz until next reboot or until link removed.
If you want to force 50Hz you will either have to use the menus or edit config.txt on the SD card:
kernelrpi.zip

[IanSB]

I was looking at the ECS amiga modes which you mentioned are on the Super Denise chip:
https://github.com/c0pperdragon/Amiga-Digital-Video

According to the info here:
http://amiga.lychesis.net/knowledge/ScreenModes.html
Most of those modes are different refresh rates and only 6 bits per pixel.
How are those modes output from the Super Denise? If they use the higher 6 bits of the 12 bits then they could be made to work with the CPLD version because that supports higher pixel clocks at 6 or 3 bits per pixel and the different refresh rates would mean auto switching mostly. However some sort of additional signals would be required for some modes to support auto switching as they are the same refresh rates as the existing modes.

[c0pperdragon]

My idea with the two profiles was that the firmware could provide a "safe" and a "precise" profile, both aready doing the "right" thing (for "precise": full range genlock).

But your solution now may also be ok. I will try tomorrow to test which of my monitors actually list 50Hz in their EDIT.

[c0pperdragon]

I find it very strange that the Amiga should artifically restrict the color depth in the ECS modes. The system is designed to use 12-bit wide palette registers for all color indirection in all modes except old-and-modify. What reason could it have to somehow suppress some of the bits when they are already available. Maybe this information is inaccurate?

I don't think it it is easily possible to know if the Denise uses the super-high-res modes. For this you would need to monitor the writes to its internal registers. Other modes could probably be detected by monitoring the CSYNC signal alone.
If it is really true that the Denise only uses 6 of the 12 color bits in certain modes (but with higher speed), it could even be possible to extend the adapter board to collect two pixels together and transfer them in a single burst. Maybe with use of a CPLD, but it may already work with 74-series logic alone.

But I don't have a SuperDenise, so I can not do much experimenting here. I also do not really think that there has ever been much use of the ECS screen modes in the first place. Using the "normal" interlaced high-res without flicker is already a great achievement.

[laubzega]

Could it be that DACs are not fast enough to produce accurate voltages in higher frequency?

[c0pperdragon]

I would not think. I don't know the exact inner working of the "Video Hybrid" that actually turns the 12 color bits into an analog voltage, but this most probaly uses an array of 12 resistors to do that. There is would make no difference if the lower pins are 0 or some correct value. From the system design it would surely be extra effort to not support 12 bit colors.
But I guess this can only be answered by someone actually trying on the real hardware.

[IanSB]

I find it very strange that the Amiga should artifically restrict the color depth in the ECS modes.

Yes it's quite strange. One explanation could be that they intended them be used with an EGA style 6 bit digital connector but I think EGA was already out of date by the time the Super Denise was introduced although EGA connectors were still on most monitors in addition to VGA.

Maybe this information is inaccurate?

It seems to be repeated here:
https://wiki.amigaos.net/wiki/AmigaOS_Manual:_Workbench_Monitors

Maybe with use of a CPLD, but it may already work with 74-series logic alone.

It would be possible to do experiments with an external RGBtoHDMI board like I did with my A500. I don't have a Super Denise based machine but if I ever get one I'll look at it.

One other way that has been used to determine mode changes is to analyse the sync pulses to look for subtle differences in timing between modes. This is already used on the BBC micro profile where the 12 Mhz teletext mode requires a very different profile to the 16 Mhz graphics modes but both are normal 50Hz modes. Fortunately there is a slight difference in sync pulse timing so it is easy to detect.

[c0pperdragon]

But for the Amiga super-high-res modes there is surely no difference in the overal timing. The Agnus that is responsible to generate the CSYNC signal still runs at 7.1MHz and delivers the same amount of data to the Denise which then divides the bits up in a different way to get the pixels. Maybe a CPLD could actually compare the color bit values of two super-high-res pixels and and when they are consistently different (and maybe the lower bits are always zero?) it would know that the super-high-res mode has been entered. Similiarly you can detect that the mode has been exited when the lower bits start to be non-zero. This would work of course only if the bits indeed are zero (or some other fixed pattern).

For experiments with super-high-res you would only need the SuperDenise, as the OCS Agnus would not do anything different. Don't known how to set up this mode from software, tough.

[c0pperdragon]

I am not sure if I am doing something wrong but with the new kernal and the Auto@50Hz-60Hz resolution, both of monitors I have tested so far run at 60Hz (would also work with 50 without issue).
The profile (Amiga 50Hz is activated) uses the Genlock Adjust -5% to +5% option
With the "Unlimited" option, they show 50Hz without problem.

Or does the new kernal now prevent the Amiga 50Hz mode to be auto-selected in case that the EDID does not allow 50Hz?
In this case it would be OK, I guess. And I would have to just set the genlock to unlimited in the 50Hz profile and to +-5% in the 60Hz profile.

[c0pperdragon]

But this can also not be true. The 60Hz profile has completely different offsets and would not work with the 50Hz input.
So you see, that I am terribly confused now.

[c0pperdragon]

Oh my! This compatibility-hell was exactly the thing I deliberately avoided with the C64 Video Enhancement and only went for analog output...

[IanSB]

I am not sure if I am doing something wrong but with the new kernal and the Auto@50Hz-60Hz resolution, both of monitors I have tested so far run at 60Hz.

What make/model and resolution are they and are they DVI or HDMI?

Or does the new kernal now prevent the Amiga 50Hz mode to be auto-selected in case that the EDID does not allow 50Hz?

When any of the Auto resolution modes are selected, they override the Genlock Adjust -5% to +5% setting if the following conditions are met: (Text doesn't change)

Auto50Hz-60Hz - override if EDID allows 50Hz
AutoForce50Hz-60Hz - override if source equal to or less than 60Hz
AutoForce@Unlimited - override always

Oh my! This compatibility-hell was exactly the thing I deliberately avoided with the C64 Video Enhancement and only went for analog output...

Running monitors at 50Hz has always been a problem although it is better with more recent ones.

[IanSB]

There might be bugs in the EDID parser so here is a version that dumps the EDID data to the file "EDID.bin" in the root of the SD card on each bootup. Please post the EDID files from your monitors:
kernelrpi.zip

[c0pperdragon]

These are the two files:
EDID.zip

[IanSB]

They both only claim 55 or 56Hz minimum support and are quite old as they don't have any HDMI EIA/CEA-861 extension block to the EDID. I think that virtually all old DVI monitors except HP ones will fail the 50Hz test and all more modern HDMI ones will likely pass the test.

I have figured out how to set different config.txt defaults for simple and normal mode so I could set the default for simple mode to "AutoForce@50Hz-60Hz" if you would prefer that so it will always try 50Hz and you can use the link to fix any no output problems (i.e. same as before EDID detection).

Normal mode is keeping the default as "Auto@50Hz-60Hz" as that is more likely to always give an image on initial startup and then the menu can be used to set any desired output mode.

One thing you might want to check: One of the monitors I tested was also a Dell (2007FP) which didn't allow 50Hz support in the EDID although it worked at 50Hz when forced but it did an internal 50-60 conversion so smooth scrolling still juddered. Maybe check your Dell for the same thing?

Another idea might be to have a list of monitors known to work at 50Hz based on User feedback and if one of those is detected then "Auto@50Hz-60Hz" would ignore the EDID and use 50Hz anyway.

[c0pperdragon]

Both screens for which I sent you the EDID data run perfectly smooth with 50Hz.
So using the EDID is pretty useless to decide on 50Hz. I am sure we dont' want to build and maintain a database for 50Hz compatibility.

All these considerations are becoming much too complex already. Maybe you could revert to a more simple overal solution:
Previously the output resolution Default@60Hz worked nicely in conjunction with unlimited range genlock for all my monitors that were even somehow able to show 50Hz.
This is for sure exactly the mode of operation everyone would like to use, except when the monitor does not work and the user has no other monitor. But in this case the whole upscaler solution is already completely missing the point.
To still provide some sort of fallback in this already pretty useless scenario, the jumper link can be used to at least check if the board is working at all (no need to bother installing a button in this case).

I would suggest the jumper/button at startup should actually just disable any genlock completely for this session. This would give just the best behaviour. It would even allow a super-compatible 60Hz output on NTSC Amigas for any monitor that is so picky to not even tolerate the slight deviation in frame rate.

I think this would completely remove the need to have any special output modes besides the dedicated ones (resolution + framerate) and the one default@60hz. In the Amiga profiles there would be just genlock set to unlimited, which could be temporarily overriden by the button/jumper.

[IanSB]

Here is the latest test version:
AmigaTest-v0-06.zip

This is a full set of files as several others have changed. Wipe the SD card and unzip.

Changes:
There are still 3 new Resolution files but they have been renamed:
Default@EDID - Selects 50Hz if EDID indicates it is OK (will likely fail 50Hz on most DVI and work on most HDMI monitors)
Auto@50Hz-60Hz - Forces 50Hz if source is 50Hz otherwise 60Hz
Auto@Unlimited - Output always tracks input frequency.

On first startup of a fresh install:
Simple (Amiga) mode selects Auto@50Hz-60Hz as the resolution.
CPLD mode selects Default@EDID as the resolution.

Fitting the link in Simple mode or holding down Menu during bootup forces 60Hz and reselects the above resolution combinations.

I think this covers what is needed:
In simple mode you always get 50Hz to test without requiring the menu and if you get no output you fit the link.
In CPLD mode you get a safer default output that is more likely to produce a display on first startup at the expense of sometimes getting 60Hz but it then allows the menu to be used for further experimentation.

I called the EDID mode "Default" rather than "Auto" to indicate that it shouldn't be relied upon to select 50Hz (although it will get it right a lot of the time).

EDIT: I also added a message at powerup to display the output resolution and refresh rate.

[c0pperdragon]

I have tested the fresh install, and everything works perfect. I really like the startup-message to show the resolution and frame rate. The message about recovery mode is also a very nice touch.
So basically the Amiga solution is finished now. Will try to get reviews on some youtube channels. No luck yet...

I'm right in the process of soldering a bunch of adapter boards. To test the boards without the need to install them into the real Amiga (which would be difficult, because my Denise still has a broken leg), I rigged a test circtuit with an Arduino to generate test signals. The Arduino runs at 16MHz and creates an 8MHz pixel clock. By overclocking the Pi core to 450Mhz, this gives a stable picture. 430Mhz is just too little. So I also guess, the Atari ST should be no problem in this regard.

[IanSB]

There is a new full build of the software available:
https://github.com/hoglet67/RGBtoHDMI/releases/tag/20201010_4c8ca86
Direct link:
https://github.com/hoglet67/RGBtoHDMI/releases/download/20201010_4c8ca86/RGBtoHDMI_20201010_4c8ca86.zip

This is a release candidate for the next official version and has various additional changes from the above test version including a new log saver feature in the info menu which saves the serial port log to the SD card to aid in debugging any problems users might have.

There haven't been any specific changes to simple mode but can you do a clean install to check that everything still works OK.

[c0pperdragon]

I have tested this release (clean install on the SDcard) and everything I tried just works flawlessly: 1280x1024/1640x1050, 50Hz/60Hz, interlace/non-interlace in all possible combinations. The recovery mode also works fine.

Then I have updated the software download link in my repo to point to this prelease version.
As I have already sent one adapter board to "Jan Beta" for review on his youtube channel we may get some user feedback in the future (depending on the outcome of this review, of course).

[IanSB]

There is another new build available here:
https://github.com/hoglet67/RGBtoHDMI/releases/tag/20201113_0471da6
Direct link:
https://github.com/hoglet67/RGBtoHDMI/releases/download/20201113_0471da6/RGBtoHDMI_20201113_0471da6.zip

The main change that will affect the Amiga is improved menus in interlaced mode. Previously they were a flickery mess, now capture is switched to progressive mode when the menus are on so you don't get any flicker but only 1 field is displayed under the menu so reduced vertical resolution. Interlaced capture is re-enabled when the menu is switched off.

Also there is a "Test monitor for 50Hz" option which is mainly for the normal CPLD version as that uses Default@EDID so it will default to 60Hz with many monitors and you can use this to check if the monitor works at 50Hz easily.
Also the quick start guide and reference guide in the wiki have been updated to reflect all the recent changes.

Can you do a clean install to test and confirm it is OK with your board.