search

hoglet67 / RGBtoHDMI

Bare-metal Raspberry Pi project that provides pixel-perfect sampling of Retro Computer RGB/YUV video and conversion to HDMI
GNU General Public License v3.0
837 stars 112 forks source link

New PCB ideas #97

Closed IanSB closed 4 years ago

IanSB commented 5 years ago

I thought I'd start a discussion about a new PCB layout or layouts. Minimal changes over current PCB: Add a 9 way 'D' socket for BBC and PC use at the other end of the pcb so it fits into the current case. This will also involve moving the reset button. Using a 9 Way D means that PC users don't need a custom cable. BBC users will always need a custom cable as the standard 6 way connector won't fit in the case. Add a link to switch pin 9 of the D connector between Vsync and +5v. Use in the vsync position for a PC and the +5v position for a BBC. This does mean a potential hazard when plugging a BBC configured board into a PC as that will short Vsync to +5v but one possible way around this would be to fit the opposite gender D connector on the BBC only version. You could treat the PC version as universal and just always power it externally even when connected to a BBC. The alternative is to fit a high density 15 way "D" which has enough pins for 5v and maybe extra control lines for analog front end converters but that means custom cables for PCs as well and invites connecting VGA leads which could also result in damage.

Fit terminating resistors (also helps when some inputs are unused / floating)

Mux options: Using 6 bits means the Mux option no longer works although the pads for the buffer chip could remain with the option to fit it as long as PCs are never connected, perhaps using the reverse gender D connector mentioned above. i.e. BBC build has +5v on pin 9, buffer chip and reverse gender D. Universal/PC version has vsync on pin 9, no buffer chip and standard D.

Other options: Connect CPLD programming lines to the Pi so it can bring up a new system without a programmer. (Also saves the PCB space of the programming header)

Use SIL resistor packs instead of surface mount where possible. Optionally support through hole LEDs

I think that any analog versions will have to be separate PCBs like your Atom converter Three current ideas: Simple mono video using two comparators: This could be implemented on a PCB the same size as the current one with a phono socket on the end of the board. The threshold voltages for the sync and video comparators could be set by D to A converters (I2C etc) so no trimmers required

Amstrad CPC464 Could be implemented on a PCB similar to the Atom board.

Composite colour Again could be implemented on a PCB similar to the Atom board but would require a general purpose TV front end chip.

IanSB commented 5 years ago

I've just been looking at the practical aspects of putting a 9 way dsub connector on the board. I've mocked up a test using a piece of veroboard and it looks promising with the right type of connector although there won't be any mechanical support apart from the soldered legs: 9pin-1 9pin-2 9pin-3

hoglet67 commented 5 years ago

Ian,

Maybe I will pull my finger out and have a go at laying out a V2 PCB.....

Do you have a part number for the 9-pin DSUB connector that you used?

Looking at the photos, it seems to be protruding about 5mm beyond the case, due to having longish pins. Is that the case?

I was wondering whether this kind of D connector might better: image https://uk.rs-online.com/web/p/pcb-d-sub-connectors/0472764/

The pins, with a slight about of bending in, would I think just touch either side of the PCB (a kind of surface mount).

The advantage is that it doesn't foul the reset pins on the Pi Zero.

IanSB commented 5 years ago

Do you have a part number for the 9-pin DSUB connector that you used?

https://uk.farnell.com/mh-connectors/mhdd9f-t-b-m-rbm/d-sub-connector-receptacle-9pos/dp/2533065 The male equivalent is https://uk.farnell.com/mh-connectors/mhdd9m-t-b-m-rbm/d-sub-connector-plug-9pos/dp/2533069

The pins, with a slight about of bending in, would I think just touch either side of the PCB (a kind of surface mount).

The main problem with that would be fitting in the current case as I think there would have to be a large slot cut all the way up the one end of the case and possibly into the top as well.

The advantage is that it doesn't foul the reset pins on the Pi Zero.

The above farnell connectors don't seem to foul the reset connector either. Here are some further pics of the above with the case cut to fit: case1 case2 case3

The end result is a little more clunky looking that I had hoped. It might be better to move the d sub further into the case so the plate is much closer or touching the end of the case which would also mean moving it upwards for clearance (i.e. pins pushed further through the pcb) and increasing the size of the case slot. That might also help with mechanical stablity.

The alternative is to do something like the Atom board in a bigger case which would allow some of the analog mono video options to be added and maybe even a beeb style video connector as well as a 9 way dsub but this off the shelf case is so suitable in other ways with all the precut holes that it would be a shame not to use it.

BTW getting the self programming working would also help with the layout as you could remove the programming header as well as the link and r6 which would free up some space in that area.

I'll try moving the dsub further into the case as mentioned above to see if that's feasible.

IanSB commented 5 years ago

I moved the Dsub further into the case and it looks much better now: (Doesn't appear to foul anything)

new2 The metal part of the dsub should just be touching the PCB. (The end of the veroboard had already been cut away a bit but doesn't need to be so the Dsub will be clamped between the pcb edge, the top of the slot in the case and the bottom edge of the case. (Assuming the slot is cut correctly)

new3 The back 5 pins of the connector need to be roughly in line with the two rightmost pins of the GPIO connector but getting this exactly right might require some trial and error. The bottom of the Dsub is exactly in line with the join between the top and bottom half of the case. NOTE the pins on these Dsubs narrow at the end but the holes will have to be larger than the ends as the main part of the pin will have to pass through the PCB

new4 I overcut the slot on the top part of the case so an unnecessary gap is visible. Also about half each of the two clips that hold that end of the case shut have to be cut away but it still seems to hold securely

IanSB commented 5 years ago

It might be worth adding some unmasked ground plane along the edge of the pcb by the Dsub so that it could be soldered to the Dsub body for additional mechanical strain relief (see ringed area): ringed

hoglet67 commented 5 years ago

I'm not sure when I'll be starting to work on this. I've got some work to do with Roland on Atom2K18 first, and then we have visitors next week. So it may be a couple of weeks before I get started,

I don't think this is going to be a quick tweak to the existing board. Everything is going to need to be moved around, and the signal flow is now in the opposite direction. This also means the CPLD pinout will change to simply the new routing.

I'm still not convinced of two things:

  1. That we should be trying to do everything on a single PCB design.

There are too many conflicting requirements:

I have doubts that all of this will all be possible.

If the Beeb version needs different choices to be made on assembly, there is no real advantage of having a common PCB.

If it were just a few tweaks to the existing design, I think that would be different. But it isn't.

  1. That a 9-pin DSub connector is right for the Beeb.

It's large and somewhat clunky, and the mechanical aspects are a bit of a worry. I was wondering if a 2x5 way IDC connector might work. Either 2.54mm or 2.00mm pitch. Or indeed just a captive cable like you have. (Where does this exit on your case?)

IanSB commented 5 years ago

One way to get around the electron MUX issue would be to buffer all the signals all the time which might add a little protection for the CPLD as well. I recall you mentioning that it affected the error quality to do that but did you try all kinds of 74 series chips (like 74F or 74ALS)? I'm guessing that it primarily affected mode 7 but would the new 24 Mhz sampling help there?

Using a 5x2 IDC is also an interesting idea as that gets around another BBC / PC problem. To support both we really need 10 signals (the 9 way D and +5v) so that would work and making up a 10 way IDC to a 9 way Dsub IDC is easy.

EDIT: The captive cable came out the same end as the proposed new connector

IanSB commented 5 years ago

[repost due to strange timestamp issue]

I'm not sure when I'll be starting to work on this

No problem, just discussing ideas for now.

retain the 74LS08 (so it works with the older Elks which I think are more common)

I've been trying this with my issue 4 electron which doesn't have buffered RGB outputs and it seems fine, I couldn't see any difference with mux on or off. What was the problem you were seeing?

Using a right angle 5x2 IDC connector of some sort on the underside of the PCB at the current RGB end looks feasible in which case only the 10 way captive ribbon cable would have to come out of the case at the other end. This would mean the RGB signals could remain at the same end they are at the moment thus avoiding most of the issues with rework you mentioned above.

I'm going to order some 5x2 connectors to see what is practical. If that works, the minimum changes required would be: Remove programming header (assuming self programming works) Remove link & R6 Move CPLD closer to reset button using space freed up by the above Change 6x1 rgb connector to 5x2 Add terminating resistors (possibly SIL 2x 5 pin or 1x 9 pin) (uses space freed up by moving the CPLD a few mm) Change leds to through hole. This only leaves the 74LS08 and the options would be Leave as is but only fit for an electron with problems Replace with a faster hex buffer / inverter to always buffer all 6 rgb signals.

hoglet67 commented 5 years ago

I've been trying this with my issue 4 electron which doesn't have buffered RGB outputs and it seems fine, I couldn't see any difference with mux on or off. What was the problem you were seeing?

The "high" levels of R,G,B were only going up to about ~1.3v (IIRC), which isn't quite enough to reliably be treated as a '1' by the CPLD. This manifested as very obvious noise visible in large blocks of colour. Buffering through the LS08 worked, because its threshold is lower than the CPLD.

It might also depend on the instance of the ULA, the power supply voltage, what add-ons are present. I think I was using a Plus One at the time as well.

IanSB commented 5 years ago

Using a 5x2 IDC connector looks feasible at the current RGB end of the PCB with a captive cable out of the case. Only bare 5x2 pins would be usable though as a shrouded connector like the one used in the Atom converter is too big: 5x2-a Placement would have to be exact as there are pins from one of the switches on one side and the 40 way connector on the other but it looks like it should just about fit. It fouls the serial debug port but that could be fitted on the other side of the board as long as the pins don't pass through the board. (The pads could be moved or removed entirely as the 3 pin serial debug connector could be soldered directly on to the 40 way header for those that need it)

5x2-b

The pins could be fitted at the other end of the PCB like the 9 way Dsub above to allow direct external connection but again clearance is an issue and also this means a large rectangular hole would have to be cut into the case instead of a simple slot for the cable.

hoglet67 commented 5 years ago

Ian,

You'll be pleased to hear I've got the CPLD programming from the Pi working, and with no GPIO dedicated pins.

I ended up with the following mapping:

SP_CLK    => TCK
SP_CLK_EN => TMS
SP_DATA   => TDI
MUX       => TDO

IMG_1695

In normal use of the CPLD, SP_CLK_EN is high on every riding SP_CLK edge, which is exactly what's needed to hold the JTAG state machine in the reset state.

Edit: I used MUX rather than MODE7 for TDO, as there is an LED attached to MODE7 which will act as an unwanted pulldown. Photo above has been updated.

I've pushed some initial code to a branch: https://github.com/hoglet67/RGBtoHDMI/tree/embedded_cpld_programming/src/jtag

A bit more work is required on the following:

Edit: Works on the Atom Board as well: IMG_1841

IanSB commented 5 years ago

I've got the CPLD programming from the Pi working

Looks good, I'll give it a try soon.

I found another raspberry pi case which might be a suitable alternative. It's aluminium and has a large cutout on the top (I presume for a heatsink) which could be used for a general purpose connector like a 10 way IDC socket although it's position might make routing of other signals to the 40 way header difficult. (Holes for leds and switches would still have to be drilled.)

metalbox

As mentioned above last month, the other idea is a 10 way header under the pcb and a captive ribbon cable which could end either in a BBC / PC / Spectrum128 etc connector or in a cable mounted 10 way IDC plug which would then allow different cables to be swapped around

hoglet67 commented 5 years ago

I'm not sure like the aesthetics of the cable coming out of the top.

On the subject of the subject of the Pi based CPLD programming, I've been doing some more testing, especially looking for ways to "brick" the system that are hard to recover from.

Here are some notes on what I've found....

(1) Once the four wires are in place, it's no longer possible to reprogram the CPLD using the Xilinx Platform cable because of interference from the Pi. To overcome this, it's necessary to force the Pi's GPIOs into a high impedance state. An easy way to do this is to boot the Pi without the SD Card present.

(2) If the erasure step succeeds, but the reprogramming doesn't, then you ended up not being able to have another try because on reboot our software on the Pi detects an invalid CPLD and halts. I've now fixed this by detecting a blank CPLD (the 12-bit version comes back as FFF) and proceeding with a null CPLD driver. This allows access to the OSD menus, and you can try to re-program again. That said, the only time I have had this happen was with a duff .xsvf file that seemed to leave the device in the erased state.

(3) If you reprogram the Beeb RGBtoHDMI board with the Atom CPLD, then you end up with a nicely bricked system. You can't even reprogram it using the Xilinx Platform cable. This is because the CPLD pinouts are very different. It turns out the TMS and TDI end up being connected to CPLD outputs, not CPLD inputs, and the conflicts prevent the JTAG interface from functioning.

The last of these (3) is very nasty. I was able to recover by temporarily disconnecting the wires I had soldered to TMS and TDI. But if these connections has been made on the PCB itself, then the only course of action would have been to lift pins on the CPLD. In a new version of the PCB, there needs to be a means to temporarily disconnect Pi <===> Jtag signals from other pins on the CPLD.

hoglet67 commented 5 years ago

At the moment, I've got separate directories for the Atom CPLD and Beeb CPLD firmware files.

A new profile setting (cpld_firmware_dir) controls which is used by the Pi software. The default is /cpld_firmware/bbc and this is overridden in the Atom CPLD profile to /cpld_firmware/atom.

I would have liked to make this more bomb proof. At the moment, on the Beeb RGBtoHDMI board, I can selected the Atom CPLD profile, and then reprogram the CPLD, which will seriously brick the board as described above.

If there is a CPLD already programmed, then we could infer the PCB type from that. But that doesn't help in the case where the CPLD is initially unprogrammed. Ideally we would have a way for the Pi to identify the PCB version that doesn't involve the CPLD. But I can't think of a way of doing that at the moment that works with the existing PCBs.

I'm also wondering where to place the Update CPLD menu. At the moment it's under Info, which doesn't make much sense. It's rather not place it on the root menu, as that makes it too accessible.

I'l also wondering whether it should be hidden initially, and there should be a setting to make it visible.

IanSB commented 5 years ago

I'm not sure like the aesthetics of the cable coming out of the top.

It's not great but I thought I'd mention the option. My current preferred option is the 10 way header + captive cable from 10May above.

I'm also wondering where to place the Update CPLD menu

Does this work on the Atom board? Maybe rather than having a specific menu option, just detect a CPLD file in the root during bootup and prompt for an update. After a successful update, auto delete the file so the prompt is no longer seen. Perhaps use a filename prefix convention so that the Atom CPLD is prefixed with Atom_ and BBC with BBC_and refuse to program the file unless it has the right prefix.

In a new version of the PCB, there needs to be a means to temporarily disconnect Pi <===> Jtag signals from other pins on the CPLD.

Perhaps hard wired jumper pads so nothing needs to be fitted by default. If required you cut the track links then use solder blobs to repair afterwards. (Laid out on the underside of the board to avoid using up pcb space.)

BTW I thought of a way to use the MUX option without having to permanently buffer all 6 signals: Use a 74LS125 or 74LS126 as the RGB buffer. This has tristate outputs so could be switched to tristate when MUX disabled and the outputs would only be driven when MUX enabled.

IanSB commented 5 years ago

I've tried this and it seems to work well, not had any programming failures so far.

IanSB commented 4 years ago

New 6 bit board implemented so closing this now