A2000 slot adaptor build observations

[LinuxJedi]

I've built several of these boards for friends and have been using 3 different IC for U1/U5:

• Nexperia 74LVC86
• TI SN74LVC86
• Toshiba 74VHC86

The ones using the Nexperia ICs after a while fail with random bursts of this pattern for a second or two when in Super Denise mode:

I can think of two possible reasons for this:

1. U5 IC has inputs that are left floating, this typically causes issues with CMOS ICs. I believe the VHC's design makes this less of an issue.
2. The specified regulator is 300mA, there are 4 ICs on the board and judging by the data sheet they can draw up to 100mA each for the LVC range. Again VHC can probably help here as they are rated for 50mA (75mA for the 574 if you want to switch that too).

It could even be a combination of both, the floating input causes a high power draw which is causing too much load for the regulator.

I have a reworked design for the PCB I'll test in a few months time which:

1. Pulls the unused U5 inputs high
2. Uses a ground fill both sides
3. Moves things around a little so they are closer to where they need to be
4. Removes a ton of unneeded signal vias

I'd also probably recommend using at least a 400mA regulator.

If anyone wants to test this before I get a chance, the work in progress is here (I haven't updated the Gerbers there yet): https://github.com/LinuxJedi/RGBtoHDMI/tree/amiga-slot-fixes

[IanSB]

You need to look at the sync pulse (Pin 16 / GPIO23) and pixel clock (Pin 11 / GPIO 17) going into the Pi zero to see what changes when the problem arises. If it's only one board with the problem it might be an intermittent solder joint on one of those signal paths.

[LinuxJedi]

You need to look at the sync pulse (Pin 16 / GPIO23) and pixel clock (Pin 11 / GPIO 17) going into the Pi zero to see what changes when the problem arises. If it's only one board with the problem it might be an intermittent solder joint on one of those signal paths.

If it was one, yes. When it was 5 of a batch and they were the only ones with NXPs I figured that might be a pattern.

[LinuxJedi]

Well, my observations are flawed. Now getting similar issues with more boards, just taking longer to hit them (a few seconds in a few hours). I'm guessing the double inversion of C1 XOR C3 is causing additional latency.

[IanSB]

@LinuxJedi

That looks like the pixel clock is running at twice the expected frequency which could be the result of spurious spikes in the clock generation circuit.

[LinuxJedi]

To mitigate against this and other issues I've observed, particularly with A2000 and R3 Super Denise (which I didn't even know was a thing), I've designed an updated modified version here: https://github.com/LinuxJedi/RGBtoHDMI/tree/amiga-slot-fixes

It:

• Uses a ground fill
• Is manually routed instead of autorouted
• Makes U5 entirely optional (using U5 gives v1 Super Denise behaviour, without it you eliminate a couple of XORs for the 7MHz by having the Super Denise gate of U1 do it)
• Adds an optional R and C for timing delay
• Moves some of the ICs into places closer to where they actually do things for shorter traces

And has several other changes. I'll see in a couple of weeks how this works out.

I'm tempted to look into whether or not just an XOR of 7MHz and CDAC works to give 14M (and if it does what extra delay that needs). Plus I may make the board a little smaller so things are closer together / traces are shorter.

[LinuxJedi]

Closing this, finding much better reliability with my new layout, I'll upstream it with build instructions when I get time to write them next week.