Amiga Support 2

[c0pperdragon]

Amiga Support 2

[IanSB]

Would it be possible to provide a specialized settings menu that can be controlled with a single button? Like press to switch through options and press long to select.

Yes I would think so. There is already long/short press detection to allow multiple options on each button when not in menus like screen grab, NTSC colour on/off, Scanlines, Calibration etc.

[c0pperdragon]

I will start breadbording the thing tomorrow. Will postpone hooking up the C64 to the RGBtoHDMI.
One detail in signal timing: For me it would be easiest to change both the color signals (including sync) and the pixel clock at exactly the same time. The signals will stay 100% stable until the next edge of the clock.
Ist this your expected behaviour?

[IanSB]

One detail in signal timing: For me it would be easiest to change both the color signals (including sync) and the pixel clock at exactly the same time.

That should be OK, At the moment the sync and pixel clock inputs are polled and action taken immediately after a state change so there will be a slight software delay between the state change and reading the RGB values although I am not sure exactly how long that delay is. As previously mentioned, the pixel clock is read on both edges so should be 7.1 Mhz.
BTW I notice you design uses a separate 3v3 regulator but you might be able to power it from the Pi's 3v3 output.

[c0pperdragon]

I know that the RPi provides 3.3 volt, but I don't want to use it, as this could cause problems in case that the RPi is unplugged from/not yet plugged into the mod board. Maybe the LVC parts behave nicely when no power supply is available and the inputs are driven, but I better do not try my luck here.

About signal timing when changing clock and the other signals at the same time: When the sync and pixel clock inputs are polled at the same time (just a read on the port address, I guess), than it could very well happen that the clock has already changed, but the sync did not. Due to the polling normally happening in some regular non-zero intervall, the probabliy to hit just this criticial point in time is quite small. Nevertheless it could happen and I better avoid this by applying a bit of delay (5 ns or so) to the clock signal.
With this delay, there is now also a strong guarantee for the setup-time for both the sync and color signals. Having this, it would be permissible for the CPU to just poll all the GPIO pins until the clock signal changes (I guess fetching 32 bits at a time would be no slower than fetching only a few). Then the other bits must also already contain the newest values. By this you only need to do a single GPIO fetch per pixel in case the CPU is already behind schedule. When the CPU has already catched up, it will still do multiple polls until the clock changes (but none extra to get the pixel data).
Maybe this small optimization is just enough to get 16Mhz without overclocking...
I guess you could make this clocking scheme part of your communication protocol between CPLD and RPi also.

[IanSB]

The GPIO register is polled just to read the sync edge first, then a small amount of processing is done, then the GPIO register is polled to read the pixel clock with that same value read from the GPIO register at that time used to extract the RGB bits.

[c0pperdragon]

I still don't quite get it, why the sync is not also a synchronous signal that is taken at the edge of the pixel clock.
Anyway, I will just add a 5ns delay for the clock. Then the colors and the clock can be reliably read with a single port access.

[IanSB]

I still don't quite get it, why the sync is not also a synchronous signal that is taken at the edge of the pixel clock.

I'm trying to support this with a common codebase and the above cannot work with the CPLD. It is also difficult to have branching in time critical sections so alternate capture versions may require lots of code duplication.

The psync signal (pixel clock) coming out of the CPLD is generated from the hsync pulse and a Pi clock so you can't then use that to sample the hsync pulse.
The Pi software measures the time between hsync pulses and from the geometry menu it knows how many cycles there should be in that time so it can work out the exact pixel clock frequency. It then sets an internal PLL in the Pi to 6x or 8x that frequency which is then output on a GPIO into the CPLD.

This means there are 6 or 8 cycles for each pixel and the CPLD then counts up using a 6 or 8 state counter (which is reset by the hsync pulse) until the count matches an offset value in a register which then triggers the psync output into the Pi and varying the offset value will vary the phase of the psync output with respect to the hsync pulse to get the sampling point correct.

The regenerated psync clock has jitter of 1/6 or 1/8 of a pixel and it can also drift slightly over the duration of a line as the Pi generated clock will never perfectly match the original. The sync timings are continually measured and the pi clock updated so it is effectively a slow software phase locked loop.

The psync signal isn't even a pixel clock in 3 or 6 bit modes as two or four pixels are output on the 12 bit bus for each psync edge.

As the phase of psync can be varied 360 degrees with respect to hsync, the psync signal out of the CPLD is suppressed for a couple of cycles after the active sync edge, to avoid any timing issues which your board won't be doing although in your case the phase will always be fixed. Worst case it may require some software tweaks or even a hardware change if there are issues.

[c0pperdragon]

This really sounds astonishingly sophisticated. I guess the biggest challenge was to divide the work between the CPLD and the RPi given the individual limitations of either one. Just like the most sophisticated retro-gamed and demos work 🙂

[c0pperdragon]

Hi!

I have set up everything on breadboard as discussed and it starts to look quite promising.
But I experience quite some horizontal jitter by one or more pixels.

The first capture was taken with the pixel clock and all other signals being switched at the exact same time.

The second capture was taken with the pixel clock delayed by about 5ns. This looks better, but is not really correct yet. Unluckily delaying the clock signal even further gives no noticeable improvement.

[IanSB]

Is it any different with trailing edge?

There is a potential timing issue with leading edge due to a value being pushed onto the stack:

The code behaves as follows:

For trailing edge:
Wait for sync low
Read timer
Write time to stack
Wait for sync high
Wait for psync/pixel clock

For leading edge:
Wait for sync low
Read timer
Write time to stack
Wait for psync/pixel clock

In trailing edge the stack write time doesn't matter but it is in the critical time path on leading edge and I know from previous experience that such memory writes can cause unpredictable delays.
The only way around this is to rework the code to save the value in a register as all other parts of the code are solely register and GPIO access based with the only memory writes being to screen memory.

BTW I've nearly got single button menu operation working.

[c0pperdragon]

Trailing edge profile (just ,Amiga') is worse. There I also get vertical jitter.

[IanSB]

Could you try overclocking your pi zero with leading edge to see if that improves things.
Edit Config.txt to change
[pi0]
...
core_freq=400
sdram_freq=450

to
[pi0]
...
core_freq=500
sdram_freq=500

Make sure you edit the Pi0 table

To confirm the settings have changed, call up System summary in the info menu. If they hang your Pi, try some lower values, those are the values for 16Mhz pixel clock.

Note to keep these settings under all conditions you also need to edit default_config.txt as config.txt gets rewritten from that file when changing resolution or some other settings.

If that improves things it points to the stack instruction as a possible cause.

[c0pperdragon]

Overclocking actually fixed the horizontal jitter.
Two problems remain: There is glitch in the top line of the screen (looks like it is shifted to left occasionally). This is especially visible in the boot-screen where everything is white with black side borders.
The second problem are sparkly pixels at edges:

I can change the exact apperance of the wrong pixels by varying the pixel clock delay. Sometimes the pixels become cyan, sometimes black, sometimes red.

[IanSB]

Here's a version of the kernel code with the stack instruction removed, can you try that with the overclock removed:
(Unzip and overwrite the existing file on the sd card)
kernelrpi.zip

As far as the sparkly pixels go, I think you will have to match the phase relationship between the rgb levels changing and the pixel clock changing on the CPLD as it seems very sensitive to that, but I will measure it to confirm the timing.

[IanSB]

BTW go to the preferences menu and change the Screencap Size option to "Full Screen" followed by "Save Configuration" in the main menu as that will make bigger screencaps to see these issues.

[IanSB]

On the CPLD the pixel clock changes 11.6ns after the RGB data. This is 1/6 of a 14.3 Mhz pixel clock cycle (due to the x6 clock mentioned above) and is what I expected from the CPLD code but I also measured it to confirm:

EDIT:
I also tried using the x8 clock which gave a delay of ~8.8ns (1/8 of a pixel) and that worked as well so anything between those two values should be an equivalent.

[IanSB]

I see the glitch at the top of the screen very occasionally on the CPLD version but only when switching the menu on and off and it is caused by cacheing issues:
The cpu program cache is pre-loaded by running the capture loop to off screen memory during vertical blanking but it isn't always 100% effective due to the random cache replacement policy. I think you may be seeing this more because your pixel clock pulses aren't suppressed after the active sync edge. If some code takes slightly longer on the first line due to cache reloading you will miss 1 or 2 pixel clocks which results in the left shift.
The CPLD version suppresses those first couple of clocks so there is more time available to load the cache before a clock is missed.

You might be able to achieve a similar result by suppressing the pixel clock fed to the Pi during the hsync period and this may also resolve the first problem above of lines shifting by a couple of pixels without needing overclocking.

[c0pperdragon]

The new kernel did not help much. Without overclocking, the horizontal jitter remains.
With overclocking, the jitter disappears and by fine-tuning the pixel clock delay to about 8ns, the sparkly pixels look least bad.

All this looks more and more like it is not going to work without changing (rewriting?) the sampling loop to directly fit the needs of the non-CPLD input. My circuit is very primitive and in a final product, I can not adjust the various delays to the degree possible right now. Also I can not suppress the pixel clock during hsync - this would probably need an additional IC and I can not squeeze any more onto my target board size.

What I really could do and guarantee is a minimum (but rather short) setup-time and a hold time for nearly the whole pixel duration for both color and csync lines. A loop that just polls all GPIOs at once and when the pixel clock did change use all other (csync, color) bits from the data to do its thing before starting to poll again would be most stable, I think. This would also perfectly account for minor stalls in the program flow (50ns or so ) because the CPU could reliably catch up later, given that no further stall occurs immediatly after. If RAM write is a major headache, the program could collect two pixels together and write them as a single 32bit operation every other pixel. Because of the tolerance for stalls in single pixels, this may improve the matter.

To give you an incentive, I could in return rework the C64 sprite handling - there we are facing just the same problem: Fluky operation that may be solved by a serious implemention effort ;-)

[c0pperdragon]

One additional complication with the current setup is the fact that my circuit together with the Amiga hardware produces a rather non-50% duty cycle on the pixel clock. It is about 60ns - 70ns right now.

On the other hand, I found a way to reliably use the rising edge of the sync: Only consider the sync signal that is taken at the rising edge of the pixel clock as valid. This reduces the resolution for the sync to 7.1 Mhz. Color values still come at double this speed.

(all this was already assuming a specialized sampling route, of course) ;-)

[IanSB]

If RAM write is a major headache, the program could collect two pixels together and write them as a single 32bit operation every other pixel.

I'm already doing that with 8 pixels being written by a single four word burst write instruction.

A loop that just polls all GPIOs at once

It already does that for the pixel clock and pixel data. It only separately polls the sync and I think the double GPIO read when switching from sync detection to pixel clock detection is causing the problem as GPIO reads are relatively slow. Overclocking the core rather than the CPU seems to speed up GPIO reads which is why that works.

Can you try this version which polls the pixel clock for the sync detection so there is no double GPIO read:

kernelrpi.zip

I can't test this properly as it doesn't work with the CPLD signals due to jitter between the sync and regenerated pixel clock.

Also in the zip is the file "One_Button_Mode". If you put that in the root of the SD card and reset the pi it will switch to one button operation to drive the menus.
Hold down SW1 to call up menus and select menu lines and briefly press SW1 to move down menu options and adjust values. You can drive the entire menu system with just the one button.

[c0pperdragon]

I have used this kernal, and I can get stable horizontal sync when I just overclock the core_freq to 440. with sdram at nominal 450.

The glitch in the very first line is still apparent but very strangely it depends on the actual color of this line. When using the color sliders in the preferences, I can easily make it disappear by making the background color darker.
The same thing happens to the sparkly pixels which totally go away when darkening all the colors, so there are no high-contrast edges anymore. Tried this also with interlaced mode which also worked without glitches, besides on the mouse cursor which still has high contrast colors (combing artefact looks kind of funny on the mouse cursor).

Both things hint at the problem being just the transmission wires and my overall breadboard setup. I trust that this will completely disappear with a proper PCB with short traces lower contact resistances.

The one-button interface works nicely, with the exception of setting numerical values which can only be incremented seemingly forever. I will update the adapter board schematics accordingly.

If we are OK with overclocking the RPi in this rather mild manner, the next step would be to produce a complete adapter and see if this fixes the sparkly pixels.

[c0pperdragon]

The delay between signal change and the clock change is now about 7ns which seems to be the sweet spot. 5 ns also work, and I guess it would also go lower with better transmission lines.

[c0pperdragon]

I have finished work on the PCB and have already create the gerber files. Could you have a look at the schematics if everything we discussed is now as it should be? Then I would place the order for the PCBs.

[IanSB]

I think there are only two possibilities for the sparkly pixels:

1. transmission line issues as you mentioned. There was a similar problem when someone hand built a prototype of the CPLD design which is mentioned here:
   https://stardot.org.uk/forums/viewtopic.php?f=3&t=14430&start=1110#p275202
   with solution here:
   https://stardot.org.uk/forums/viewtopic.php?f=3&t=14430&start=1110#p275917
2. Timing issues caused by the asymmetric clock

Also maybe the need to overclock is required because of the asymmetric clock.

I've changed to detect only one edge of the pixel clock during hsync detection which should double the available processing time so can you try that:
There are two versions for the different edges:
falling.zip
rising.zip

Can you try these with leading and trailing sync detection with no overclock. Don't be too worried about any vertical jitter as that will be something else and should be fixable if the horizontal looks good.

Is there any way you can test with a symmetric clock even if you have to get it from elsewhere on the board just to see if it makes any difference?

[IanSB]

Could you have a look at the schematics if everything we discussed is now as it should be?

The board looks OK as far as I can tell.

The one-button interface works nicely, with the exception of setting numerical values which can only be incremented seemingly forever

They will wrap eventually but it is not very usable for adjusting such things. I will add a menu option to reverse the direction of adjustment for short keypresses which should help a little but it would still be painful to use for anything except a minor tweak of numerical values. It is still quite useful for setting resolution, scaling and other preferences though.

[IanSB]

Here is a further update:
kernelrpi.zip

This has two changes:

1. The sync edge setting in the sampling menu now has six options
   "Trailing with +ve PixClk",
   "Leading with +ve PixClk",
   "Trailing with -ve PixClk",
   "Leading with -ve PixClk",
   "Trailing with +- PixClk",
   "Leading with +- PixClk"

The +ve or -ve PixClk settings only check on those edges of the pixel clock and the +- ones check on both edges
This incorporates the different builds above into one build.

Please try all six options to see if any are glitch free without overclocking

2. There is now a "Button Reverse" option in the main menu which only shows up in single button mode and that reverses the direction of short button presses when enabled.
   You can use this to increment or decrement values which makes the whole system more usable for tweaking settings.

[c0pperdragon]

I have tried the various sync edges without overclocking, and quantify these from 10 (flawless) to 0 (totall unusable):

Trailing with +- PixClk 9 (rare jitter, about once every few seconds)
Leading with +- PixClk 8 jitter more often but sometimes with a second between glitches
Trailing with +ve PixClk 1 very jittery, about every third line is wrong
Leading with +ve PixClk 3 about every 10th line is wrong
Trailing with -ve PixClk 3
Leading with -ve PixClk 2

By fine-tuning the clock duty cycle to 50%, I got the option "Trailing with +- PixClk" to work without any jitter at all.
But it was very difficult to find the perfect spot and it is not completely stable, either.

Still have sparkly pixels when having colors on high-contrast edges.

[c0pperdragon]

I guess it makes not much more sense to try to get it working any better on the unreliable breadboard wiring. I have just now placed an order for the PCBs.

[IanSB]

By fine-tuning the clock duty cycle to 50%, I got the option "Trailing with +- PixClk" to work without any jitter at all.

I think it only just works with a perfect 50% duty cycle so any variation may require some amount of overclock to compensate.

I guess it makes not much more sense to try to get it working any better on the unreliable breadboard wiring

Yes I think we are close to a solution but there is too much likelyhood of prototype wiring causing issues so a pcb is the next step.

However I found there was a bug in the +ve and -ve sync edge options which actually made them level sensitive, not edge sensitive so I have fixed that:

kernelrpi-edge-fix.zip

With the CPLD, two of the new +ve and -ve options are better than the +- versions and two are worse so maybe worth a test.

[c0pperdragon]

Hi!

I received my PCB for the adapter board yesterday and completed the build. Pictures of the process can be found directly in the Repo.

The results are just perfect. With the short traces and good contacts I have not experienced a single visual glitch in several hours of testing and playing. I used your latest firmware patch with the setting to "Trailing with +ve PixClk".
Directly after switching this option there normally is a short period with one single line (roughly in the middle of the screen) having glitches. This dies down quite quickly and then I have a stable picture for basically any of your sampling options.
Only in one instance this glitchy line remained permantently until I switched the mode again.

I am not sure how to test situations where the clock duty cycle is more unbalanced than on my machine. With this small board and everything wired on the PCB, I have not much possibility to influence any of the signals.

Even worse, I can no longer use my Amiga without the adapter board, because the Denise chip is now directly soldered to it.
This was necessary, because I managed to break a leg of the chip in a way that only the slightest sliver of metal was still visible on the side of the package. This in turn happened due to the most infernal stroke of bad luck I have ever experienced with ICs: Somehow one pin of the Denise got stuck inside the socket on my prototype board and would not come loose, no matter what I tried. I even melted the socket pin out of the plastic to isolate the problem, but still no luck. The IC pin totally disintegrated but its tip is still inside the socket pin.

[IanSB]

I received my PCB for the adapter board yesterday and completed the build.

I received my PCBs today, including your Amiga, Atari XL and C128 boards as well as my new 12 bit external version of RGBtoHDMI. (I haven't ordered the components yet so it will be some days before I can test your boards)

The results are just perfect.

That's great!

I am not sure how to test situations where the clock duty cycle is more unbalanced than on my machine.

Are you still overclocking your Pi?

I've added menu driven overclocking to the latest build of the software so you can dynamically vary the overclocking and observe the effects. I've been experimenting with 12 BPP capture using a 16 Mhz pixel clock and it works well with a 100Mhz overclock of the Core frequency (the CPU and SDRAM clock speeds don't seem to have much effect so it looks like the Core is the bottleneck).

I assume the Core clock affects the internal bus transfer speed but it is also used as the clock for the GPU which would normally limit the maximum overclock without heatsinking. However as the GPU isn't used, it looks like you can easily overclock the core by up to 200Mhz. (I have about 20 Pi zeros so I will do some tests to see how reliably the core can be overclocked.)

I'll get a new beta build ready in the next day or two.

I might also add an initial attempt at Atari XL support, would you be able to test that?

[c0pperdragon]

It is very good that you want to try the C128 modification, So far I have received no feedback from anyone who actually tried this.

I am using the beta4 release with your latest kernal patch. I have not set any overclocking for this.
Measuring the pixel clock duty cycle now shows me it is pretty even. It is about 69 ns to 72ns.
Also there is now a 3ns delay between the data signals changing and the edge of the pixel clock. This seems to be enough for your software to work properly as the signals are now traveling short distances and through good connectors.

It is good to know that there is some margin that can be gained by overclocking for cases where the duty cycle is more off.

I am using the single-button user interface to tweak the settings. But for casual users of just the Amiga variant it would be easier to use the button exclusively to change the target resolution. Maybe when the single button file is not present in the Amiga configuration, there will be no menu at all. Just switching through output modes.

And yes, I will of course test your Atari 8-bit configuration. I am looking forward to watch the "Joyide" demo in perfect quality.

[c0pperdragon]

I am basically done with my test on the Amiga.
I imagine I had very ocassional sync glitches (once every hour or so) when using "LeadingEdge +- clock", so I switched to "LeadingEdge -ve" and I did not notice any problem from then on.
I have created a pull request for the adapter design and included the resolutions files for 1680x1050 as well.

[IanSB]

You can extend the micro SD card to allow access outside the case or to put it near the ram expansion slot internally to make it easy to do upgrades or recover screencaps without disassembling the Amiga using something like this:

https://www.ebay.co.uk/itm/TF-Micro-SD-To-SD-Card-Extension-Cable-Adapter-Flexible-Extender-For-Car-GPS/383658051187

The above is just an example, they come in different lengths so you can usually find one that is suitable for the location.

[c0pperdragon]

It may sound strange, but after more or less completing the Amiga solution, I am actually thinking about a different approach that is more in the spirit of the RGBtoHDMI project:
To use the external converter box with 6 bit of color input and multiplex the 12 bits on these lines, very much like we do for the Atari 800 now.
By re-purposing some of the basically unused pins of the Amgai video port, this could be done without any changes to the case. The relevant signals for analog video would still be there for use as normal.

I am pretty sure your CPLD is up to the ask, as you already managed to process EGA data in a comparable bit rate.

The internal modification requires soldering. Unsolder register packs RP402 and RP403, solder leads to the various pins of the Video Hybrid (as you did for testing) add a small mod board and feed the output signals into the holes left by RP402 and RP403.
Additionally get the two system clocks from somewhere and that should be it. The board should also be fairly cheap with some flip-flops and multiplexers (need to think of this in more detail).

Externally a custom cable is needed. This could be a bit of a problem because the D-SUB 23 seems to be out of production for ages . But a D-SUB 25 can be sawed down to fit (did work with my Amiga-to-YPbPr adapter)

[c0pperdragon]

nonono.
Just forget my previous comment. This is just too complicated and serves no real purpose.

[andriodious]

Just tried the internal board and I must say the results are spectacular compared to the external monitor connector via SCART. Fantastic job guys!

[andriodious]

Now with a tweak to the settings, time to shut down and start drilling the case 👍

[IanSB]

Just tried the internal board and I must say the results are spectacular compared to the external monitor connector via SCART.

Looks great!

[IanSB]

One suggestion for the pcb:
Extend the end of the board by pin 1 / pin 48 of the denise chip by a couple of mm then put a hole in the corner by pin 48 to match the hole in the raspberry pi so an 11mm threaded spacer can be bolted in there to provide some mechanical support for the Pi

[IanSB]

I got the Atari ST working as well using some overclocking including the hires mono mode and it auto detects which mode is in use and switches to the correct profile (I connected the unused 3 RGB bits to the mono output)

(Screencaps moved to the new Atari thread)

An internal simple board might work in the same way as the Amiga but there will be some clearance issues with the shielding.

Also a totally external solution would work for the mono mode as H&V sync and mono are available on the Atari's video connector at TTL levels.

[IanSB]

I imagine I had very ocassional sync glitches (once every hour or so) when using "LeadingEdge +- clock", so I switched to "LeadingEdge -ve" and I did not notice any problem from then on.

Can you post your final saved Amiga profile

[andriodious]

Looks great Ian.

I imagine I had very ocassional sync glitches (once every hour or so) when using "LeadingEdge +- clock", so I switched to "LeadingEdge -ve" and I did not notice any problem from then on.

Can you post your final saved Amiga profile

These are the config and profile I'm using BTW
config.txt
Amiga_500.txt

[c0pperdragon]

I am now using a 720x288 sample area with the standard workbench centered in the middle.
This contains enough overscan to not lose relevant parts but also does not look stupid on a big screen.
And for a 1280x1024 screen, the workbench now fits pixel-perfectly.
720x576 is also exactly the resolution for DVDs (PAL).

Amiga.txt

I am using a monitor with 1680x1050 and this now is absolutely perfect. It works especialy well with my 1990th program "Revolution Demo" which has a text scroller at the end that uses interlace mode to get half-pixel scroll steps. The weave de-interlacer works without any glitches with that. I have not seen an emulator yet that can do that so well. And of course emulators also still have the issue of frequency conversion.

[c0pperdragon]

My HDMI plug install looks quite similar

[c0pperdragon]

One suggestion for the pcb:
Extend the end of the board by pin 1 / pin 48 of the denise chip by a couple of mm then put a hole in the corner by pin 48 to match the hole in the raspberry pi so an 11mm threaded spacer can be bolted in there to provide some mechanical support for the Pi

Actually I prefer this connector to be not too rigid, so there is less stress on the connection between the adapter to its socket.

[IanSB]

There is now an updated pre-release on hoglet's github which includes all the recent changes, can both of you check that on your Amiga boards as a clean install (haven't built mine up yet). You will have to explicitly select the output resolution from the menu as it defaults to "Default@60Hz" but it should default to one button mode without having to change anything else.

https://github.com/hoglet67/RGBtoHDMI/releases
https://github.com/hoglet67/RGBtoHDMI/releases/download/20200908_ff298ac/RGBtoHDMI_20200908_ff298ac.zip

Also update your RGBtoHDMIs with it as well (clean install), reprogramming the CPLD if necessary.

I think I've worked out a way of auto setting the correct monitor resolution and refresh rate for the profile but I haven't implemented it yet.

Please let me know if you see any issues

[c0pperdragon]

This now works pretty good for me.
Before setting display mode to 50Hz (it was at least set to my monitors resolution, but 60Hz of course), I noticed a tiny flicker at the right top pixel. Of course the scrolling was jumpy, but there was no tearing of any sort visible.

After switching to 50Hz the display is perfect. Thanks for setting the active display width to 720. It really looks much better without this large empty blue area at the left. And using a 1280x1024 screen really gives you the impression that the Amiga was actually designed for exactly this.

The only incorrect thing in the display I notice is that in interlace mode, the display is shifted down just one line, leaving a thin strip of blue at the top edge of my 1280x1024 display. On the bottom edge, the last visible pixel row of the mouse pointer is only half as thick. I guess you need to change the positions of the even and odd lines in your display buffer.

I tried capturing other images and in non-interlaced mode, the resulting png is just the dump of the buffer without doubling the lines, so it looks squashed.

Also the size of the capture depends on the selected output display mode. I would very much prefer always having a capture size of 720x576.

[c0pperdragon]

I just noticed that complaining about the capture feature makes me sound like a hypocrite, as I always said, I would not use it because the SD card is burried so deeply in the machine.
Now I notice it is actually really nice, even if I have to take the top off the machine.

[c0pperdragon]

I wanted to mention that this upscaler solution now feels so fast and responsive , that I actually managed to get to about 3 seconds to winning Marble Madness in difficulty 7 - which is basically "god mode" :-)

[IanSB]

I tried capturing other images and in non-interlaced mode, the resulting png is just the dump of the buffer without doubling the lines, so it looks squashed.

That's actually a bug in the capture scaler. You can work around it by setting the Video Type to Progressive in the geometry menu but I will fix it for the next beta.

I always said, I would not use it because the SD card is burried so deeply in the machine. Now I notice it is actually really nice, even if I have to take the top off the machine.

That's why I suggested the SD extender ;-)

[andriodious]

Good news is that the new build works fine.

Bad news is that when I tried the software (earlier and new build) on my A500+ I get sparkly pixels.

First things I tried were overclocking, then training and leading edge options. No improvement was seen.

The only and main difference I can see is that I have a Super Denise Chip in the A500+ vs my A500

... so I swapped out the rock-steady OCS Denise on my A500 and the sparkly pixels appeared as they did on the A500+.

Suggestions welcome :) -- Happy to post my ECS Denise out on loan for debugging if needed.

[c0pperdragon]

Its a very good thing that you tried the SuperDenise in the A500. That means the problem is not the clock signal which may cause issues if its duty cycle is too far off 50%.

The way the adapter board is designed, it always latches the new color data at the rising or falling edge of the CDAC signal, which is a 90 degree shifted CPU clock. The Denise changes its output roughly 30 ns after this signal switches (40 ns before the next switch), so the latches can get perfect data. Overall the output circuit of the Denise seems to be directly driven by this CDAC signal.
If my circuit now gets unreliable data from the SuperDenise this can only mean, that this chip is instead driven by the CPU clock. With a peviously measured signal delay of about 30ns, the signal switch then happens very close to the rising or falling edge of CDAC. One solution is of course to design a specific board that uses the CPU clock instead, or one that has a jumper to select one of both.
For a quick test of this hypotesis, you could manually rewire this signal on the adaper board: From pin 34 of the Denise, there is a single trace running on the underside of the board to a nearby via. There is not much going on at this spot, so you could cut this trace fairly easily. Connect pin 35 of the Denise to either this via (it is quite small and there are other vias nearby, so this may not be the best choice), or scrape the solder mask from the trace and solder to this.

[andriodious]

Applied the mod:

... and

Bingo, perfect image. Thanks so much! You now have a fix for Super Denise!

[c0pperdragon]

Very good. Thank you for reporting this and for trying this modification.
Now I need to think about which solution is best: Special board for SuperDenise or some kind of jumper. I don't want to user solder bridges, because I still want a 100% no-solder solution.
By the way: I see you already had to get creative to finally somehow the metal shielding on again.

[andriodious]

For the shielding mods, I bent the shield foot that joins with the edge connector nearest the adapter 90 degrees and cut the excess. I then bent the shielding that runs over and along the edge connector to 90 degrees -- no need to cut this bit.

Just to be sure I insulated the Pi with black tape. Fits nicely after that! :)

[IanSB]

Here's an updated kernel.pi
kernelrpi.zip

I was getting occasional mis-identification of simple mode so I've made some changes to improve that, can you check it on your Amiga boards. It should also have the screencap scaling bug fixed so you should get full height screencaps.

[c0pperdragon]

@andriodious
I just noticed that on your image with the workbench screen in 1280x1024 resolution shows a thin line of blue at the left border. This is in contrast to what I can see when using the "normal" Denise, where the picture fits pixel-perfectly.

Earlier tests have shown that the csync signal is not always switching at the same time as the color signals. That is one of the reasons there are different options where the sync is taken.
Maybe this is also a difference between Denise and SuperDenise. Could you tell me which option you were using for this picture? How does it look like when using the default options after a fresh install, switching only the output resolution?

[andriodious]

@c0pperdragon

Fresh install (using @IanSB) latest kernel. Only mod was my change of resolution.

@IanSB

New software seems to function as expected thanks. Here is a screen capture, and a snap of the screen to confirm:

And another one in interlace mode -- looks fantastic vs the flickering we used to have to put up with by default:

Finally, fitted the SD-Card adapter for easy trapdoor access when needed

[IanSB]

I just noticed that on your image with the workbench screen in 1280x1024 resolution shows a thin line of blue at the left border. This is in contrast to what I can see when using the "normal" Denise, where the picture fits pixel-perfectly.

If this problem isn't fixed with selecting different edges in the sampling menu I might be able to add a fine delay option in software. The H offset adjust in the Geometry menu is limited to a 4 pixel minimum adjustment with the fine adjustment of 0-3 pixels done in the CPLD because worst case if you are capturing at 3 bits per pixel, four pixels are transferred on a single psync edge on the 12 bit bus so that can't easily be adjusted in software. However in 12bpp mode only one pixel is transferred so doing a fine adjustment in software should be possible.

[andriodious]

All good now, the Leading with +ve PixClk edge sampling fixed the left border. Looks like that should be the default SuperDenise option then.

Thanks again @IanSB and @c0pperdragon for all your help.

Much apprecaited. Now I must go and mow the lawn to keep the boss happy!

[IanSB]

Here is an updated kernel with pixel delay adjustment the same as the CPLD versions. Although it has been worked around by changing the edge, that might not always be possible on any other simple boards for other computers so this is a more flexible option)
Go into the sampling menu to adjust the delay.

Before adjusting, change the "Setup Mode" from "Normal" to "Set Delay". This reduces the capture area to the minimum size (which will be 640x256) so you can check if the delay is set correctly. Adjust the delay so there is no blue line on either side.
(Setup mode is auto set to normal when you leave the menu)

Post any saved profile after doing this as there might be different profiles for Denise and SuperDenise.
kernelrpi.zip

[andriodious]

@IanSB

Thank you I installed the latest on my Amiga 500 tonight and all good. I needed to set a Delay of 3 to get it pixel perfect.

I will try the my Amiga 500+ with ECS_Denise when I next get a timeslot.

Amiga_OCS_Denise.txt

[IanSB]

Thank you I installed the latest on my Amiga 500 tonight and all good. I needed to set a Delay of 3 to get it pixel perfect.

Thanks for the update.

Although you got Super Denise working by changing to Leading with +ve PixClk, I'm not sure if that is the correct edge to be sampling on. If it is then it is likely that the delay will also be 3.
If however there are any noticeable glitches in the video, you could try the original Leading -ve or Trailing -ve / +ve which will probably introduce a pixel shift that can be corrected by adjusting the delay.

[c0pperdragon]

I have again measured the various clock signals and the phase relation with the csync signal.
The CSYNC is produced by the Agnus chip and may depend on the exact revision. As I only have an 8372A, I would request you to check which variants you have and also do an oscilloscope measurement to get more data.

I am using the rising edge of the _CDAC signal (available on pin 34 of the Denise) as reference point. The CPU clock is visible on pin 35 and the CSYNC is on pin 32.
_CDAC rising: 0ns
_CDAC falling: +70ns
CPU clock rising: 38 ns
CPU clock falling: +108ns
CSYNC rising: +5ns
CSYNC falling: +35ns

With a "normal" adapter board, data is latched at about +2ns (the +ve pixel clock point) and +72 ns (the -ve pixel clock point). Because the rising edge of CSYNC is relatively close to +2ns, the combination "Trailing +ve" and "Trailing +-" should be avoided.

With the adapter for the SuperDenise, the data is latched at about +40ns (+ve) and +110ns (-ve). Here then the falling point of CSYNC is close to +40ns. So it is better to avoid "Leading +ve" and "Leading +-".

For a setting that works on both adapters, this leaves the following safe options:
"Trailing -ve", "Leading -ve"

All this is valid of course only of other Agnus revisions behave similar in this respect, so please try to collect the timing data.

[c0pperdragon]

I have adjusted the settings with the new firmware for both "safe" sync options in turn:
Amiga.txt
Amiga.txt

[c0pperdragon]

This thread is too long already, please use #8