Amiga Support 2

[c0pperdragon]

Continuation of https://github.com/c0pperdragon/Amiga-Digital-Video/issues/3

@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. For the internal installation in an Amiga 500 I would like to place the HDMI port at the small unused area on the backside and put the single push button next to it. Its main purpose would just be to select different output resolutions and maybe the framerate.

[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 https://github.com/c0pperdragon/Amiga-Digital-Video/issues/8