User Feedback and Experiences

[c0pperdragon]

User Feedback and Experiences

[gaspafen]

With such a waiting list for ordering one I ordered some PCB's from eurocircuits and parts from mouser. Had a local supply of the RPi. Forgot to order the resistors so I scrounged a 5k from old broken electronics. Put it all together and it works great. Fits fine in the A500 case together with the vampire v2+. This could be because the pin headers I used have a bit longer pins. Will be ordering some other pin headers to use if I solder another together. Need to get a HDMI switch now :)

Using extension pin headers for the RPi would get that higher up if there would be a clearance issue with an accellerator.

[de-nugan]

Following on from above, my Pi is now soldered to the adapter to get the shortest possible data path and this has successfully fixed the colour sparkles and glitches. The picture is now superb on my Rev 5 A500.

I soldered the adapter board in place of the Denise socket for reliability and compactness, so it's now a permanent daughter board. A couple of caps and a resister pack needed to be nudged out of the way but overall it was a pretty easy fit and takes a minimum of space. The boards now sit low enough to go underneath the CPU expansion card without any additional risers, so the case can go back together as normal.

I'm using a short mini male to std HDMI female cable from the Pi, it was necessary to cut the molding from the mini plug end to fit the cable between the ROM and CPU. It's tight but fits together pretty well. I have had some CF card errors since the installation, don't know yet if EMI from the adapter is causing issues with the expansion card above.. needs more testing.

[Osmund]

I was lucky and secured a couple before the Jan Beta videos. To make it fit with my tf534 I soldered the pinheader on the pi zero on the bottom with one row on the outside of the adapter. I then connected the outside pins to the second row on the pi. I can now mount the pi to the adapter with the hdmi facing towards the back of the case. With a tower of pisa stack of cpu sockets, the tf534 fits over the pi. It works great, have not had any termal issues. The amiga top case fits as well.

[FluffyRedLobster]

Reporting great success with installation alongside a TF536 accelerator on a rev 6a A500 😃 . This was with a v1 board but I'm sure the concept will apply to v2.

As others have found, space is tight if using a CPU relocator. I considered options that others have mentioned in this thread - GPIO flex cable, or osmund's method of offsetting the headers and mounting the zero on it's back. I experimented with using 2 x 90 degree pin headers to achieve something similar but was worried about the extra connections and additional signal distance given some of the reports here.

Ended up with a pretty simple solution - 2 sets of machine pin headers to lift the CPU relocator and the TF536 (one set for each gives the required clearance and still allows the keyboard to fit without fouling on the relocator), and gently angle the GPIO pin headers on the adapter so the Pi Zero points toward the mainboard by 10 degrees or so. The mini HDMI cable then outputs under the relocator to be routed to wherever it's needed. I soldered the Pi directly to the angled pin headers but probably could have used a female header strip if I thought about it... it's not like the Pi is going anywhere else... Lastly as I had a fairly chunky mini HDMI cable (the officialy Raspberry Pi one)I removed some of the plastic shroud to ensure there is no pressure on the solder joints from the cable. I slimmer cable probably wouldn't need this.

The output quality is astonishing! I'm using an old 17" Iiyama Prolite that syncs at 50Hz and scrolling is perfect too. This easily beats the indivision mk2 in my A1200 in that regard. Thanks c0pperdragon, hoglet67 and IanSB for this great mod 👍

Hope the approach helps some other CPU relocator users out there.

[Markcalibrav6]

Tested on a A500+ with a TF536(TF536/Lazarus relocator) OS3.1 4 Rom workbench 3.9 CGX(native driver) Hi Res laced 16 colours.Standard A500 psu

The adapter was well made and compact design....the jumper on the back is perfectly placed to enable selection of OCS/ECS Chipset....😁

The RPI Zero takes its power from the Amiga so no psu is needed on the RPI side....😉

Easy SD card setup...makes this adapter a dream to setup and use...first power on and you are thrown into a Awesome pixel perfect screen...crisp clear colours.

WHDload games all work well so far...with no artifacts or ghosting at all...no lag no issues when screen modes are changed....however only standard OCS/ECS screen modes are currently supported....no wide screen options yet or Super72/SuperPlus(800x600)

My Indivison ECS V2 has config tools to tweek the settings that are saved to the device....this would be nice on the RPI side.

Mabe a short GPIO extension cable would be good as the RPI Zero faces the 68000 socket....add the HDMI lead and there is no room for popular CPU cards for the A500...(TF series..with relocator) however if your CPU card can fit directly into the 68000 socket you might be onto a winner.

Overall this adapter is a great option given its low cost compared to other options out there.

[c0pperdragon]

You can optionally connect a push button to the two angled pins on the adapter board. With such a button you can call up a settings menu (long press) and switch through the various options and modify quite some things (using short presses and long presses). This rich feature set comes from the RGBtoHDMI software that can do much more than just support the Amiga.
But for the Amiga I found that there is normally not much use in trying to tweak the settings. Output resolution is already autodetected and the 4x upscaling looks 100% crisp and accurate. But you may want to turn on scan-line overlay or some interpolation filter. So you actually can do this. Settings are stored on the SD card.

[Markcalibrav6]

Added a button to the Zero....super cool picture....

https://youtu.be/-gxpG8moEEI

[ryanm101]

With wicher508i HDMI cable is a tight fit, I've ordered some right angle adaptors to see if that helps.

[dahabakuk]

i wonder if anyone is using an turbocard with this mod... looks like the hdmi cable will be a really tight fight? can someone share a picture with turbocards installed?

[Osmund]

Tried to get it to fit with a tf card but there is no clearance. Is it possible to rotate the header for the pi zero 180 degrees, so that the hdmi points to the back of the amiga?

[c0pperdragon]

I don't have a design for this. I original thought about stacking the Pi directly on top of the Denise, but this would become a problem for the heat dissipation, so I now used this more spread out layout.
But I have designed a smaller adapter which can be used more universall,y but needs soldering of many individual wires. If you can do that, this may be the solution for you (but I don't build these boards either).

[de-nugan]

I've built two V2 boards from PCBWay. Mine have a couple of differences to the original design:

1. I couldn't source the exact regulators so used these => https://au.rs-online.com/web/p/low-dropout-voltage-regulators/7968322/
2. The Pi is connected with an extremely short (~1cm) IDC cable for now so it fits with the Kipper 2K 8MB+IDE board in the A500 and also because I can't find the 40-pin female IDC PCB headers anywhere around here :(

Both boards show a sharp and clean image at the 3.1 boot screen, but both have sparkly interference patterns on a grey workbench screen. The colour "sparkles" are mostly green and red, and appear on the trailing edge of black to grey (left to right) transitions. I've seen one or two references to minor cases of this but mine is pretty severe and impossible to ignore.

A few tests so far:

• Change length of the IDC cable to the Pi => sparkles seem to get worse with a longer cable, lines start to flicker more
• Change from original to ATX PSU => no change in symptoms
• Connect additional ground from Pi to A500 chassis => no change

So far I can't tell if the problem is some colour bits staying low for an additional clock cycle OR additional bits going high. I'm wondering if any of the engineers here could offer some insights as the the cause of this problem?

A couple of additional issues are the top scan line flickering left to right, and the geometry is off, but I'm assuming these can be tuned out.

Really impressed by this project though, kudos to everyone involved!

[hansliss]

I ordered PCBA cards from JLCPCB and they look really good. I used 74LVC574APW, 74LVC86APW,118 and TLV74333PDBVR from LCSC - I had to solder on the voltage regulator myself since the PCBA service didn't have those in stock. It all looks very professional, including my own solder work. :)

As far as I could determine, the silkscreen markings on JP1 are wrong; for a Denise (such as my A2000 has), JP1 should be strapped as 2-3, judging from the schematic. If I don't do that, I get unsynchronized garbage - the correct colours, but it scans very slowly and appears to be lacking a clock.

With JP1 strapped 2-3, I get a picture, but it's flashing slowly on and off, has a few artifacts, and isn't properly positioned. Any ideas? I managed to get a screenshot.

/Hans

[c0pperdragon]

@de-nugan : There are two general sources of pixel errors:

1. The latch in the adapter is triggered too close to the time when color lines change. This can be adjusted by moving the Denise/SupeDenise jump to the other position.
2. The color lines going into the Pi are not stable enough when the clock input to the Pi toggles. This can be caused by serveral things:
   2a. Higher capacitance/inductance caused by the longer data path due to the ribbon cable. You could try to compensate that by artifically adding a small capacitor to the PiCLK line.
   2b. Bad grounding. In your setup the GND for the Pi is proved through the ribbon cable. You could add some extra GND connection with a short (and reasonably thick wire) to some GND point on the main board.
   2c. Different behaviour of the logic ICs. I only designed an tested the circuitry with parts from TI. Maybe parts from other manufacturers have different dynamic characteristics.

[c0pperdragon]

@hansliss
I doublechecked JP1. The setting 1-2 is indeed correct for a standard Denise. With the setting 2-3 it would use the inverted 7Mhz as clock which is the best choice for a SuperDenise.
When the 1-2 setting does not work at all, there is something wrong with your adapter. Maybe solder bridging or no contact.

[hansliss]

@c0pperdragon Thanks for checking! I think the CDAC signal might be the problem, after all. The thing is, judging from the schematics for the A1000, on which my ancient German A2000 is apparently based, the Denise socket doesn't have pin 34 connected at all. It is indeed connected to CDAC on later models. Does that sound plausible?

EDIT: Rephrased the whole message to make it more coherent.

[IanSB]

@hansliss

A flashing screen usually means the sync timing doesn't match any of the available profiles.
What software version are you using?

The latest beta is here in case that helps:
https://github.com/IanSB/RGBtoHDMI/releases

[hansliss]

@hansliss

A flashing screen usually means the sync timing doesn't match any of the available profiles.
What software version are you using?

The latest beta is here in case that helps:
https://github.com/IanSB/RGBtoHDMI/releases

Thanks, I've tried the latest beta. No difference.

[hansliss]

@c0pperdragon Thanks for checking! I think the CDAC signal might be the problem, after all. The thing is, judging from the schematics for the A1000, on which my ancient German A2000 is apparently based, the Denise socket doesn't have pin 34 connected at all. It is indeed connected to CDAC on later models. Does that sound plausible?

I've checked the CDAC pin on the Zorro II bus now, and there's a ~7MHz clock signal there, as well as on pin 35 on Denise, but I didn't find anything on pin 34.

[c0pperdragon]

Hmm, this could really mean that the very early model versions did not have the _CDAC signal connected to the Denise socket.
I am not sure where you can find this signal on your specific machine, but you can probably figure this out with an oscilloscope and then retro-fit this signal to the Denise socket with a botch wire as well.

[hansliss]

Hmm, this could really mean that the very early model versions did not have the _CDAC signal connected to the Denise socket.
I am not sure where you can find this signal on your specific machine, but you can probably figure this out with an oscilloscope and then retro-fit this signal to the Denise socket with a botch wire as well.

I'm going to start by verifying the adapter in an A500. I'm awaiting delivery now. I'll build a couple more adapters tomorrow and then I'll continue this once the A500 arrives. After that I may go back to the A2000 and try again - I don't like it right now. :)

[hansliss]

Hmm, this could really mean that the very early model versions did not have the _CDAC signal connected to the Denise socket.
I am not sure where you can find this signal on your specific machine, but you can probably figure this out with an oscilloscope and then retro-fit this signal to the Denise socket with a botch wire as well.

On the Wikipedia page about A2000 (of all places), I found this: "[...] the early 2000 motherboard [...], cannot be upgraded with newer versions of the chipset [...]". To me, this confirms that what I've found may very well be correct - that there really is no CDAC signal on the Denise socket.

[hansliss]

Hmm, this could really mean that the very early model versions did not have the _CDAC signal connected to the Denise socket.
I am not sure where you can find this signal on your specific machine, but you can probably figure this out with an oscilloscope and then retro-fit this signal to the Denise socket with a botch wire as well.

I just saw a schematic that was a bit legible than what I've seen before, and found that another signal is missing on the A1000/A2000-A motherboards: Pin 32 is NC instead of /CSYNC, which seems to be used by the RGBToHDMI adapter.

[tk-amiga]

Made a few V1's and my own works very nicely in a rev6a motherboard with Super Denise. I guess V2 is more for the rev8 motherboard. Will get those soon too.
https://nextcloud.amigaaa.com/s/q7dRdWoordnTmDY
https://nextcloud.amigaaa.com/s/23kHYkrD59GKCZm
Luckily my turboboard is in the sideslot.

[IanSB]

@hansliss

A1000/A2000-A motherboards: Pin 32 is NC instead of /CSYNC, which seems to be used by the RGBToHDMI adapter.

Yes, CSYNC is required, one thing that is a little confusing is that your screencap above is horizontally locked which it shouldn't be if sync was missing completely but it looks like the floating sync input is picking up crosstalk from the RGB signals and interpreting noise from the start of video as the edge of the sync pulse which would explain the shift to the left.

[hansliss]

Hmm, this could really mean that the very early model versions did not have the _CDAC signal connected to the Denise socket.
I am not sure where you can find this signal on your specific machine, but you can probably figure this out with an oscilloscope and then retro-fit this signal to the Denise socket with a botch wire as well.

I just saw a schematic that was a bit legible than what I've seen before, and found that another signal is missing on the A1000/A2000-A motherboards: Pin 32 is NC instead of /CSYNC, which seems to be used by the RGBToHDMI adapter.

I got this working. See #28 for details.

[IanSB]

@de-nugan

The colour "sparkles" are mostly green and red, and appear on the trailing edge of black to grey (left to right) transitions.

What revision motherboard is your system?

[de-nugan]

I think it’s rev 5 or 6, but can’t be sure as I’m away at the moment. Also I found the flipflops I used were Nexperia parts. I have some TI parts on order to try when I get back mid-month.

…

On 5 Feb 2021, at 8:05 am, IanSB ***@***.***> wrote:  @de-nugan The colour "sparkles" are mostly green and red, and appear on the trailing edge of black to grey (left to right) transitions. What revision motherboard is your system? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[lilwashu]

I have noticed "sparkling" but only on pink text in Indiana Jones and the Fate of Atlantis game. The "sparkles" are white. I'm running an A2000 rev 6.2 motherboard with a rev.1 adapter from seller "r3ne3gad3mast3r" on eBay and Terriblefire TF536 accelerator.

[c0pperdragon]

Chances are that you have a SuperDenise on your board. This is not working well with the Rev.1 adapter. The Rev.2 has a jumper to select between original Denise and SuperDenise.
If you are good with a soldering iron you could try to botch the adapter to
make it somehow work. If you want I can give you instructions.

[lilwashu]

Thanks for the reply - I have an 8362R8 OCS Denise. I haven't seen the issue before or since so I'll see if I can reproduce it in something else, trying to do so in e.g. DPaint has so far failed. The installation is a pretty tight fit in the A2000 so I'll also see if removing the PSU frame makes any difference, there is light pressure on it.

I've attached a pic of the text in question, you can see the white pixels on the S and P that jump about only within the purple/pink bit of that text. I have a savegame in the relevant position if it would be of any use.

[solarmon]

@c0pperdragon

What did you mean by:

2a. Higher capacitance/inductance caused by the longer data path due to the ribbon cable. You could try to compensate that by artifically adding a small capacitor to the PiCLK line.

How would the cap be added? In parallel (with what?) or in series? What value would you propose?

[IanSB]

For sparkly pixel related problems, especially with rev5 or earlier A500s or other models, try replacing the 74LVC parts with 74VHC parts. These are slower and fixed the sparkly problem on my rev5 which doesn't have the clock filtering components that are fitted on rev6 & later boards and which slightly delay the clock signals. You may get away with just changing U1 (74LVC86) to VHC so try that first.

Note they must be 74VHC parts which are 5v tolerant, not 74HC parts which are not 5v tolerant when powered at 3.3v

[c0pperdragon]

@solarmon
To make the clock signal to the Pi running a tiny bit slower, you could try to add a capacitor (lets say 10pF or a bit higher if this does not yet work) between pin 16 (GPIO23) and pin 0 (GND) of either the Pi or the adapter.

[solarmon]

@c0pperdragon I only had "22" (27pF) ceramic cap to hand. This didn't seem to make any noticeable difference all (good or bad). So I'll have to source some smaller caps to try them out. When you sat 'or a bit higher' - how big a difference is this? Can I go from 10nF to 20nF, for example, or should the jump be smaller than that (i,e. 10, 12, 15, 18, 20, etc)?

[c0pperdragon]

1 nF is for sure too much already. If 68pF does not yet work, I would give up on the idea.

[solarmon]

Sorry, I should have said "10pF to 20pF". As stated, I've already tried 27pF.

[c0pperdragon]

I did a bit of read-up on the matter of output capacitance for LVC parts, and it seems that to get a significant change in switching time you should actually use something like 200pF. This should delay the output for about 5ns which seems about right to me.

more details and diagrams could be found here:
https://www.ti.com/lit/ug/scba010/scba010.pdf?ts=1615205272167&ref_url=https%253A%252F%252Fwww.google.com%252F

[solarmon]

I had a bag of small 27pF ceramic caps. I put a load of them in parallel (probably about up to 30/40) and it didn't seem to make any noticeable difference at all. Not sure if what I'm doing is right - I thought putting caps in parallel adds up their capacitance. (Just to be clear, this is testing with my relocator adapter).

[c0pperdragon]

Yes, putting capacitors in parallel does add the capacitance.
I am not sure what is going on here. I would expect it to make at least some difference, either for better or worse.
Could you post a picture or your installation?

[seb132]

Has Edu Arana (Arananet) released his PCB of the official repository ?
He said on Facebook that he would -- after he presented his very neat redesign of the adapter for the A500, compatible with Vampire, etc. But so far I haven't seen it yet, just in pictures.

[solarmon]

@seb132

As an alternative option, once I've tested my design, I will be releasing it.

[dgoswick]

What does this mean? I verified that my build is right. This is on a stock Amiga 500.

Edit: Okay, I figured it out. It means I didn't have the latest software! I'll leave this here in case someone makes the same mistake I did.

[mthiesen]

I can add another datapoint. I have ordered a board from eBay and installed it into my Amiga 500 Rev. 5. It works almost perfectly, but I am experiencing the same pixel sparkling that @lilwashu reported. It only seems to happen on very special color transitions and always from very dark to bright.

This is a screenshot from the Monkey Island intro:

I can also reproduce the issue with Deluxe Paint IV and the example image ReferencePalette.LoRes. In this case only the medium saturation and low saturation rows are affected. The effect is by far the strongest in the last two boxes of the medium saturation row.

[c0pperdragon]

When you have sparkling pixels, check out this thread for a very detailed discussion an possible solutions:
#40

[jock-mcbufty]

Hi there!

When I have installed the RGBtoHDMI and Raspberry Pi Zero on my A2000

i get this output! Any ideas anyone?

[LinuxJedi]

Hi there!

When I have installed the RGBtoHDMI and Raspberry Pi Zero on my A2000

i get this output! Any ideas anyone?

Are you using the A2000 board or the original A500 board? Make sure you have the jumper set correctly for the Denise you have in the A2000 (some surprisingly do have a Super Denise in them when you least expect it). Beyond that your board may need some tweaks.

[jock-mcbufty]

Hi there!
When I have installed the RGBtoHDMI and Raspberry Pi Zero on my A2000

i get this output! Any ideas anyone?

Are you using the A2000 board or the original A500 board? Make sure you have the jumper set correctly for the Denise you have in the A2000 (some surprisingly do have a Super Denise in them when you least expect it). Beyond that your board may need some tweaks.

—

Hi!

Yeah 2000 board Rev 6. I guess I can try popping the jumper back to Super Denise. I’m very much a super novice so if it’s soldering etc I will pass. The whole thing was propping up the PSU & FDD caddy anyway. Shame though it was a good idea. So this device is really only guaranteed for A500 & 1200s?

cheers!

[hansliss]

Hi there!
When I have installed the RGBtoHDMI and Raspberry Pi Zero on my A2000
i get this output! Any ideas anyone?

Are you using the A2000 board or the original A500 board? Make sure you have the jumper set correctly for the Denise you have in the A2000 (some surprisingly do have a Super Denise in them when you least expect it). Beyond that your board may need some tweaks.

—

Hi!

Yeah 2000 board Rev 6. I guess I can try popping the jumper back to Super Denise. I’m very much a super novice so if it’s soldering etc I will pass. The whole thing was propping up the PSU & FDD caddy anyway. Shame though it was a good idea. So this device is really only guaranteed for A500 & 1200s?

cheers!

I'm awaiting 500mA regulators and will soon build five boards with those, for five different people (myself not included since my A2000 is to old for the video slot version). I will encourage all of them to write about their experiences here.

[LinuxJedi]

Hi!

Yeah 2000 board Rev 6. I guess I can try popping the jumper back to Super Denise. I’m very much a super novice so if it’s soldering etc I will pass. The whole thing was propping up the PSU & FDD caddy anyway. Shame though it was a good idea. So this device is really only guaranteed for A500 & 1200s?

cheers!

If the Denise is a chip with the model 8373 (will have an R3 or R4 after it) then you have a Super Denise, if it is 8362 (likely an R8 after it) you have a regular Denise.

It should work with A2000, but there is a specific card version for it (which I'm working on an improved version of) that goes in the slot to the right of PSU as the front of the machine faces you instead of under it.

[jock-mcbufty]

Hi!
Yeah 2000 board Rev 6. I guess I can try popping the jumper back to Super Denise. I’m very much a super novice so if it’s soldering etc I will pass. The whole thing was propping up the PSU & FDD caddy anyway. Shame though it was a good idea. So this device is really only guaranteed for A500 & 1200s?
cheers!

If the Denise is a chip with the model 8373 (will have an R3 or R4 after it) then you have a Super Denise, if it is 8362 (likely an R8 after it) you have a regular Denise.

It should work with A2000, but there is a specific card version for it (which I'm working on an improved version of) that goes in the slot to the right of PSU as the front of the machine faces you instead of under it.

—

I appreciate all the replies, I find modding fairly stressful when you are as clueless as myself. This setup looked fairly straight forward so I had a go.

I will check tonight what chip I have, just in case! Again thanks for the tip regards versions. Can I quickly check that I haven’t fitted the whole thing the wrong way round? I made sure the slightly nick or circle on the side of the device matched the hole below it on the motherboard itself.

thanks!

[jock-mcbufty]

It looks like I have a super Denise so I will switch jumpers and have another go!

[hansliss]

I will check tonight what chip I have, just in case! Again thanks for the tip regards versions. Can I quickly check that I haven’t fitted the whole thing the wrong way round? I made sure the slightly nick or circle on the side of the device matched the hole below it on the motherboard itself.

Since you get a picture at all, I'm sure you've basically done it correctly. There are some weird issues with sparkling edges and similar that might or might not be related to what you get. For now, some suggested changes have been to use another technology for the three chips on the adapter board (74VHC* instead of 74LVC*) and (although this may be only for the video slot version) to use a beefier voltage regulator. I don't think there's any final solution for that particular problem, though.

[hansliss]

It looks like I have a super Denise so I will switch jumpers and have another go!

Oh, would be great if it's that simple.

[LinuxJedi]

Since you get a picture at all, I'm sure you've basically done it correctly. There are some weird issues with sparkling edges and similar that might or might not be related to what you get.

You would get a picture with the jumper set incorrectly, just a significant amount of noise as seen here.

[jock-mcbufty]

Since you get a picture at all, I'm sure you've basically done it correctly. There are some weird issues with sparkling edges and similar that might or might not be related to what you get.

You would get a picture with the jumper set incorrectly, just a significant amount of noise as seen here.

—

cheers! Would it also sort out the shrunken resolution as well?

[jock-mcbufty]

hi guys, quick update - I swapped the jumper over to Super Denise to no avail. It still brings up a thin, distorted image. So I’ve gone back to my semi-reliable scart upscaler. For anyone who braves an A2000 mod, be aware that my PSU ‘tray’ touched the rasp pi. Thanks for all the replies guys!

[hansliss]

hi guys, quick update - I swapped the jumper over to Super Denise to no avail. It still brings up a thin, distorted image. So I’ve gone back to my semi-reliable scart upscaler. For anyone who braves an A2000 mod, be aware that my PSU ‘tray’ touched the rasp pi. Thanks for all the replies guys!

Before you give up, could you please do a quick test using a different monitor or TV? I've seen examples of when a monitor distorts the image - not quite that badly, but pretty bad.

[lilwashu]

hi guys, quick update - I swapped the jumper over to Super Denise to no avail. It still brings up a thin, distorted image. So I’ve gone back to my semi-reliable scart upscaler. For anyone who braves an A2000 mod, be aware that my PSU ‘tray’ touched the rasp pi. Thanks for all the replies guys!

Apologies if this is stating the obvious but have you put insulating material (I used a thin bit of card and electrical tape) between the Pi pins and the metal PSU sled?

[LinuxJedi]

Apologies if this is stating the obvious but have you put insulating material (I used a thin bit of card and electrical tape) between the Pi pins and the metal PSU sled?

Beat me too it, those pins shorting on the metal there could definitely cause these kind of issues.

[jock-mcbufty]

Apologies if this is stating the obvious but have you put insulating material (I used a thin bit of card and electrical tape) between the Pi pins and the metal PSU sled?

Beat me too it, those pins shorting on the metal there could definitely cause these kind of issues.

—

apologies that’s the output with the metal tray not on the pi. Yes if it worked I would have had to put something in between. Cheers for the answers though. It’s not just the distortion that’s the issue, it the thin resolution as well. Thanks.

[mthiesen]

A little update from me: I just build a V2 for my Amiga 500 Rev. 5 with VHC parts, as was suggested (by far the most difficult solder job I ever did, BTW). I am happy to report that the sparkling problem is almost completely gone. In fact, I have yet to see any sparkling with non-artificual image content.

However it is not gone completely. The Deluxe Paint IV example image ReferencePalette.LoRes still produces a few and very faint sparkles every few seconds. This is so rare that I was not able to capture this so far. Also only the Medium Saturation / B cell seems to be affected this time.

I guess this is good enough for me for the time being.

[solarmon]

A little update from me: I just build a V2 for my Amiga 500 Rev. 5 with VHC parts, as was suggested (by far the most difficult solder job I ever did, BTW). I am happy to report that the sparkling problem is almost completely gone. In fact, I have yet to see any sparkling with non-artificual image content.

However it is not gone completely. The Deluxe Paint IV example image ReferencePalette.LoRes still produces a few and very faint sparkles every few seconds. This is so rare that I was not able to capture this so far. Also only the Medium Saturation / B cell seems to be affected this time.

I guess this is good enough for me for the time being.

@mthiesen What are the actual VHC chips you used? I got my TI ones from RS:

https://uk.rs-online.com/web/p/logic-gates/1713480/
https://uk.rs-online.com/web/p/flip-flop-ics/1713428/

I too have the same experience in that the sparkles are mostly gone, apart from in the LoRes reference pallette in DPaint - specifically in the Medium Saturation Blue edge - you can just make our a few sparkles in the screen capture below:

[mthiesen]

@solarmon I used the exact parts you linked to. And I also experience the exact issue you are. I don't know how persistent it is for you, in my case, there is a flurry of sparkles every few seconds.

[solarmon]

@mthiesen In my case the sparkles are very frequent - several times a second. I'll see if adding a cap to the PiCLK line will improve it in any way.

[solarmon]

@mthiesen I added a 47pF cap between PiCLK and GND and that seems to have resolved the issue - I don't see any sparkles in the LoRes reference palette.

I also have another VHC based board that was also showing sparkles in the Medium Saturation V edge too, but a 47pF cap also resolved the issue and no sparkles are appearing.

[mthiesen]

@solarmon I just did the same and soldered in a little 47pF cap between PiCLK and GND on the Pi header and the sparkling pixels are indeed completely gone!

Does anybody know whether this is a universal solution for Amiga 500s? Or do different board revisions need different configurations (VHC / LVC, cap / no cap)? It would be nice if there was a universal version of this adapter or at least one that is configurable enough to make it work for all board revisions.

[solarmon]

@mthiesen

I will be testing various tweaked versions of the adapter with an optional (via a jumper) delay to the PiCLK signal. I'm still waiting for the PCB boards before I can test it. (It's seems like it has been on a slow boat from China, going via the Suez canal...)

I'm hoping that the tweaked boards can then still use either VLC or VHC parts.

I may also tweak it further to have the cap on the PiCLK signal and have that configurable via a jumper too, just for good measure.

[IanSB]

@mthiesen

The universal solution is to use the original CPLD design as that has software adjustable timing of the sampling point. I think someone is doing a revised board layout using that.

[LinuxJedi]

@mthiesen

The universal solution is to use the original CPLD design as that has software adjustable timing of the sampling point. I think someone is doing a revised board layout using that.

That would be me, prototype boards should be with me middle of next week.

[culexus8]

@mthiesen
The universal solution is to use the original CPLD design as that has software adjustable timing of the sampling point. I think someone is doing a revised board layout using that.

That would be me, prototype boards should be with me middle of next week.

Do you have any testing done on it? I might seen a post at FB about this one :)

[LinuxJedi]

@mthiesen
The universal solution is to use the original CPLD design as that has software adjustable timing of the sampling point. I think someone is doing a revised board layout using that.

That would be me, prototype boards should be with me middle of next week.

Do you have any testing done on it? I might seen a post at FB about this one :)

A couple of us have done testing on several different revision Amigas (A500 rev 5, rev 6 and A500+, Denise R8, Super Denise R3 & R4). Works great. Yes, that FB post was about me from one of the testers.

The initial setup / CPLD flash is difficult, in part due to a software bug with button management in recovery mode, I'm actually manually JTAGing it for now. But it is pretty rock solid from there. No sparkles. Needed to hit the auto calibration on two of the machines due to it being out of phase (image a little wavy). Once you save that you are golden.

Otherwise, standard progressive Hi-Res works, there is no profile for interlaced Hi-Res (640x512) yet. I got some of the way there yesterday but I'm not an expert in the fine tuning yet. @IanSB speculated that some Super Denise resolutions would work but I've not even begun to try creating a profile for that.

I have a bunch of things to document, particularly setup. I'll Open Source it all at some point next week.

[culexus8]

LinuxJedi: This looks sweet just using the cpld flash and keep it simple :) When you say manualy flashing the cpld firmware you think of the option inside the rgb2hdmi software OSD menu to flash it that is not working? So you need to use ISE Design Suite to program it I guess?

[culexus8]

And for the CPLD you are using is that an XC9572xl ?

[LinuxJedi]

LinuxJedi: This looks sweet just using the cpld flash and keep it simple :) When you say manualy flashing the cpld firmware you think of the option inside the rgb2hdmi software OSD menu to flash it that is not working? So you need to use ISE Design Suite to program it I guess?

The firmware recovery menu itself doesn't support single button mode properly so you can't physically select the firmware to flash without soldering extra wires on for the missing buttons (which I did on the first prototype).

I didn't use ISE Suite to program, I used xc3sprog (I use it on a bunch of projects), but the suite should work too.

And for the CPLD you are using is that an XC9572xl ?

Yes.

[culexus8]

Ah thanx for clearing I now understand :) I do have some XC9572xl in stock so this is just perfect if it gets out. Then I only need the pcb files to try it :)

[patracy]

Has anyone else had issues with the rgb2hdmi adapter with a 2000 video slot adapter and the RPi simply locking up? I'm using the card adapter with a RPi 0. The hdmi output is going into a hdmi to vga adapter, then into my GBAPII++ video card. (This makes switching automatic instead of having to flip from vga/hdmi on the monitor) The amiga keeps running just fine, as I can see the output on the composite output. But at times the output from the rgb2hdmi simply freezes. I have also ran the adapter with only a hdmi cable to the monitor. No issues that way. I thought perhaps the hdmi to vga adapter was pulling too much current through the rpi/rgb2hdmi, so I cut its power lead from the hdmi cable and powered it from a 5v rail from a molex connector. It still randomly froze. Also I'm certain the RPi is freezing since I can plug the monitor hdmi cable into the pi and see the same frozen screen as before. The selector button doesn't change anything either. I have also tried a brand new sd card to see if it works any better. No difference. I have another pi0 (but wireless) that I could try. But I'm at a loss over it seemingly working fine directly over a hdmi cable and having the hdmi to vga converter externally powered.

[c0pperdragon]

Strange thing, that the receiving device (monitor vs. capture card) should make a difference. Could be that they have different pixel resolutions which would make the Pi do slightly different things. You could try to force the output resolution to a specific value (can be done in the configuration menu) and check if there is still a difference.

[IanSB]

@patracy

Can you post a photo of the source summary page in the info menu when connected to the vga adapter.

Are you using the standard Amiga profile or the variable intensity scanlines profile? The latter significantly overclocks the Pi zero so a heatsink is recommended but even the standard Amiga profile slightly overclocks the Pi to provide some "headroom" due to marginal timings. I've not previously come across a Pi that had problems with that but you can try disabling it.

To disable it on the standard profile, call up the main menu, go to the button reverse setting and switch it on, then go into the settings menu and reduce the core overclock setting to 0, finally go back to the main menu and save configuration. Use restore default configuration to go back to normal. You can also try fitting a heatsink to the Pi zero chip or try another Pi zero.

If none of that helps, the software might be locking up due to something unusual about the vga adapter's EDID so you could go into the info menu and use the save log and EDID option and post the resulting files.

[patracy]

It would seem that perhaps the HDMI to VGA adapter was the fault. I brought home another one (but I had to use a mini to standard hdmi adapter to make it work) and it has worked perfectly. Even changing in and out of RTG. I played around with it for about 20 minutes and couldn't get it to misbehave. Prior it would hang/crash in a matter of only a few minutes. Perhaps I just had a dud adapter from the start and it's been the fault all along. If it does act up again I'll bring it up. And I'm using the amiga profile.

[quantum8]

I've installed the video slot version 2.2 in my a3000 running b19 and the screen is flashing on and off, but works fine when the menu overlay is active. The source video is 50hz, main refresh 50hz and the profile and sub profile is set to Amiga 50Hz. Is there anything I can change to get a stable picture?

[IanSB]

@quantum8

the screen is flashing on and off, but works fine when the menu overlay is active

That usually means the video timing doesn't match any of the preset profiles so it is continually hunting through the profiles looking for a match. Could you use the save log and EDID function in the info menu and post log.txt and also a screenshot of the source summary page.

[patracy]

Guess I spoke to soon on my issue. It froze up again today. Tomorrow I'll bring home a different pi 0 to see if it behaves the same.

[quantum8]

@IanSB
That usually means the video timing doesn't match any of the preset profiles so it is continually hunting through the profiles looking for a match. Could you use the save log and EDID function in the info menu and post log.txt and also a screenshot of the source summary page.

Log.txt

Here you go @IanSB

[IanSB]

@quantum8

Thanks for the log. It looks like you are using a hybrid machine with an NTSC crystal but which is outputting PAL video signals so the timings are all wrong (see the clock error). There is already an additional profile for the other way around (PAL crystal with NTSC video) but not your combination. Normally PAL machines have a 14187580 Hz pixel clock and NTSC machines have a 14318181 Hz pixel clock.

Here is an additional profile to test:
Amiga_50Hz_NTSC.txt

Put this file on the SD card in the \Profiles\Simple\Amiga folder and power cycle the board

If that works OK I'll add it to a future release.

[quantum8]

Thanks @IanSB this worked perfectly

[RamsesUTL]

Hi.
I use an Amiga 2000 (PAL) with the RGB2HDMI on a Samsung Full HD TV (1920x1080). The picture is just brilliant, I love it. For the normal 256 lines everything is just fine with the 20210322_f771e51 release.
But many games and demos use some additional lines in the overscan area and I'm not sure which parameters I need to change to show these few more lines without compromising the pixel perfect output.
Also it confuses me a little that the top line of the menu is cropped. Seems just like the lines that I'm missing.
Could some please point me in the right direction? Thanks in advance!

[IanSB]

@RamsesUTL

If the menu is being cropped like that, you need to change a setting on your TV.
Many TVs will zoom in by 5% or so when displaying a TV picture in order to remove any 'garbage' from around the edge and you have to change the scaling setting on the TV to get an exact 1:1 pixel mapping. This is called something like "just scan" or "exact scan" or "PC mode" etc and the option name will vary with manufacturer.

The min and max settings above show the range of possible vertical capture sizes which will vary from 256 to 270 depending on the resolution of the TV. In the case of a 1080p TV the capture resolution will be 270 pixels (1080/4 = 270). The system summary in the info menu shows the current capture size.
If you switch to interpolated scaling then only the max values control the capture size.

[RamsesUTL]

@IanSB Damn do I feel stupid right now. I looked for an option like that on my TV for a few times and came to the conclusion it does not have it. Turns out I downloaded the manual today and found that option there. It's called "Screen fit" on the Samsung. I overlooked it before because of the cheap german translation (without explanation) .... grrrr.
Thanks for making me look again ;-) And really big thanks to you and @c0pperdragon for that great device that lifts my 30 years old Amiga 2000 to a whole new level!

[lyzanxia]

I'm trying to enable scanlines by choosing the amiga_blk scanlines profile. At 720x576 I get this "double" screen. If I turn scanlines off it's perfect. What can I try to get this to display ok?

[hohteri]

My apologies if this has been addressed but what you can see in this video is called pixel sparkling and should be fixable by adjusting timing? Thanks!

IMG_8016.MOV

[c0pperdragon]

There are mainly two distinct possible causes for this effect. The most probable is that your adapter is jumpered to the wrong Denise type. If you hava a Rev.2 adapter (which are nearly all that are in existance for the Amiga 500) there is a jumper link on the underside to do this.
If you have some other setup, please specifiy you hardware (adapter, mainboard, Denise variant).

[hohteri]

The jumper is in Denise setting, board rev is 2, amiga is rev 6A and Denise is 8362R8.

Thanks.

[LinuxJedi]

The jumper is in Denise setting, board rev is 2, amiga is rev 6A and Denise is 8362R8.

Might be worth swapping the jumper anyway. I've had an A2000 with an R8 before that worked better on the Super Denise timings. You won't damage anything by doing this, either the image will get better or worse :)

[hohteri]

The jumper is in Denise setting, board rev is 2, amiga is rev 6A and Denise is 8362R8.

Might be worth swapping the jumper anyway. I've had an A2000 with an R8 before that worked better on the Super Denise timings. You won't damage anything by doing this, either the image will get better or worse :)

IMG_8017.MOV

Definitely better that way. Still some but way less.

[solarmon]

Try a 47pF cap between PiCLK and ground.

Also make sure all flux has been cleaned off between and under connector and chip pins.

[LinuxJedi]

I haven't tested for sure, but I suspect when this happens on 6As C403 and alike are likely suspects.

[hohteri]

Try a 47pF cap between PiCLK and ground.

Also make sure all flux has been cleaned off between and under connector and chip pins.

Finally got the 47pF cap. Unfortunately it didn’t change a thing. I used the image from A2000 issue as a reference. Also I used IPA and a toothbrush to clean the board. I bought the board preassembled locally in Finland but he also sells them on eBay. I could try it in my CDTV if it is Amiga board issue. I think I also have a super Denise somewhere if you guys think that would make a difference.

[solarmon]

@hohteri I have some spare RGBtoHDMI boards I can probably send you for comparison. I'm UK based. PM me if you are interested.

[Jola78]

Hello!
I sat up all night yesterday trying to install my rgb2hdmi but i have run into some problems.
When i boot up the Amiga the RPi flashes its green led two times and i get a glimpse of the rainbowcoloured splashscreen and then it turns black and the no signal sign appears on the screen.
I have a brand new sd card in the PI. I have cleaned the legs on Denise with IPA and reseated the adapter a few times but with the same result every time. I unplugged everything and tried powering on with the rgb to scart cable and everything is working fine.
If i long press on the button to bring up the menu nothing happens.
This is what my setup looks like.