c0pperdragon
User Feedback and Experiences
I created this thread as a means to collect feedback about your experiences using this solution. Installation pictures and screenshots are highly welcome.
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.
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.
Added a button to the Zero....super cool picture....
https://youtu.be/-gxpG8moEEI
With wicher508i HDMI cable is a tight fit, I've ordered some right angle adaptors to see if that helps.
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?
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?
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).
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.
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.
I've built two V2 boards from PCBWay. Mine have a couple of differences to the original design:
- I couldn't source the exact regulators so used these => https://au.rs-online.com/web/p/low-dropout-voltage-regulators/7968322/
- 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!
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
@de-nugan : There are two general sources of pixel errors:
- 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.
- 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.
@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.
@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.
@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
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.
@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.
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.
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. :)
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.
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.
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.
@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.
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.
@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?
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 [email protected] 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.
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.
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.
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.
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.
