no display - bbc model B 12 bit board 1360x768 60hz raspi zero

[smith844]

I got a bbc model b and thought i would build a rgb to hdmi adaptor but have hit a wall. I built as per the instruction, I connected my RGB plug to the 12 way as per the cables page and put on the latest software. the pi powers on, the monitor detects an input and the D2 led lights on the board but i get no output. I tried a previous version of the software and get a 4 coloured square briefly when it appears to boot, but no output beyond. Update i have managed to get onto the CPLD recovery mode but when i select 6-12_bit_BBC_CPLD_v79 by long press sw 1 it says: Current=Simple v0.0: Confirm ? when i then long press sw1 again it flashes identifying but then goes back to Manual CPLD recovery: select correct CPLD. Could it be my CPLD is not working on the board. I used a solder station with reflow heat gun, the connections seem ok. I can only select Amiga on the profile page as well... is this related ?

[IanSB]

@smith844

No, you don't need to setup anything prior to initial bootup. If you have a TTL serial to USB adapter, you can connect the serial input of that to TxD and Gnd marked on the 40 way connector and display the debug log on a PC. You will need to run a terminal program set to 115200 baud, 8 data bits, one stop bit, no parity and this will show what is happening during bootup.

Assuming there are no shorts/assembly errors, one other possibility is that the CPLD you have is already programmed with some other code that stops the system from booting properly. Where you get your CPLD? If you got it from ebay/ali express etc there is a possibility of that happening because they sometimes sell surplus stock which has been pre-programmed with other code. There are procedures to recover from that so let me know and I'll detail them.

[IanSB]

@smith844

Could it be my CPLD is not working on the board. I used a solder station with reflow heat gun, the connections seem ok. I can only select Amiga on the profile page as well... is this related ?

This can happen when using a CPLD pre-programmed with unrelated code so where did you get your CPLD?

EDIT: Note you will not be able to erase such a CPLD without using a special procedure and new software.

[smith844]

@IanSB Thank you for the quick reply. I did indeed get my CPLD from Aliexpress. I have a TTL to USB adaptor so could get some debug information but would it do me any good. I have checked and rechecked the connections and they appear to be OK. I had to guess the connections for to DIN plug as i couldn't find a useful pin out. If i had somehow reversed the connections to the DIN plug i am guessing the board just wouldn't power up.

EDIT: I also built a second one as i bought 2 CPLD in case I made a hash of soldering it. This is the same, as far as being able to program CPLD. In system info, system summary it says CPLD Version: Simple V0.0 which is identical to first. that was powered direct into pi with no output cable attached, hopefully this shouldn't matter for programming CPLD.

[IanSB]

@smith844 I have seen similar reports over the past year and suspected that the issue was pre-programmed CPLDs but I only recently got some chips from Ali Express myself and confirmed this. Note I don't think these are recycled chips (i.e. salvaged from old boards) and I think it is more likely that they are surplus chips sold on by the original purchaser into the grey market but after they had been pre-programmed with the original purchaser's firmware.

One issue I discovered is that the firmware is write protected and the existing programming code didn't override that so reprogramming always failed.

Here is a test version of RGBtoHDMI which will override the write protection: Alpha54A.zip

It also has other changes to ensure that an erase is successful but also to ensure that it works you need to cut the three "JPx" solder bridges on the back side of the PCB. This is because the reprogramming GPIOs are also connected to other inputs and if the rogue firmware makes them outputs they will conflict with the GPIOs and these cuts isolate those pins.

You can try reprogramming from the CPLD recovery menu using the three button hold down but again sometimes the software will not get that far due to the rogue firmware so another way to erase the firmware is to go into the cpld_firmware folder on the SD card and delete the file "Delete_This_File_To_Erase_CPLD.txt". After deleting this file, on the next reset the CPLD will be erased and the file will be re-created.

So the full procedure with the most likelyhood of success is the following:

1. Installl the above alpha software
2. Cut the three "JPx" solder bridges (make sure you actually have broken the connections)
3. Delete "Delete_This_File_To_Erase_CPLD.txt" from the cpld_firmware folder on the SD card
4. Reset / repower RGBtoHDMI

If successful you should get the recovery menu to select the correct firmware After programming, re-make the three "JPx" bridges with solder blobs (The converter will not work without them remade)

You can try skipping the solder bridge cutting the first time in case you are lucky and the 3 signals don't conflict but if that doesn't work you have to re-delete the file as it is always re-created on each reset.

Let me know how you get on.

[smith844]

@IanSB Sorted. I followed the instructions, and did indeed need to cut the solder links. All soldered back and working as expected. Thank you so much for the help. Do i need to put the new software back on the SD card or will it run ok on alpha ?

[IanSB]

@smith844 The alpha should be OK but it's just a snapshot of my work in progress and hasn't had much testing so you can revert to the most recent beta or stable if you want to. I will be releasing this code soon as a new beta once it's been tested a bit more but you have helped to speed up that process by confirming the recovery procedure works. (I had run out of pre programmed CPLDs to test before finalising the code so haven't been able to fully confirm it works until now)

[luciust]

@IanSB Thanks man, this is exaclty what I needed:

1. Got Ali chips
2. No bueno :( Simple v0.0
3. Found your Alpha software, deleted te file for erase, cut the three JPs: JP2, JP4 and JP1
4. And it... works - CPLD got finally programmed!

[IanSB]

@luciust

Beta54 now has the updated erase code as well: https://github.com/IanSB/RGBtoHDMI/releases

Also if you are thinking of building an analog board, don't get MAX9144 chips from Ali Express as they may not work: https://stardot.org.uk/forums/viewtopic.php?p=358072#p358072

[luciust]

@luciust

Beta54 now has the updated erase code as well: https://github.com/IanSB/RGBtoHDMI/releases

Also if you are thinking of building an analog board, don't get MAX9144 chips from Ali Express as they may not work: https://stardot.org.uk/forums/viewtopic.php?p=358072#p358072

Thanks on both accounts! I'll on Beta54 and confirmed two more CPLDs got erased nicely.

Now - I'm in process of adapting the STE and have 3 questions:

1. The standard Shifter Pickup board is 9-bit compatlible, right? I want to use it since I'm even more concerned with having a proper bus transciever designed by you to protect both STE Shifter and the RGB2HDMI.
2. I'm asuming that STE would work with just 9-bits?
3. Are you going to create 12-bit pickup board for STE - but not as addon, but just as a slight modification of the ST/9-bit board? I would just like to solder all of the 12 cables from STE resitors and have the signal protected. Seems we have exact the number of gates on 74HC245 to do that?

[IanSB]

@luciust

I'm asuming that STE would work with just 9-bits?

Yes but obviously colours using those missing least significant bits will only be displayed approximately

Are you going to create 12-bit pickup board for STE - but not as addon, but just as a slight modification of the ST/9-bit board?

The main problem is that I don't have an STE so it's difficult to create a suitable PCB of the right shape without having something physical to experiment with. e.g. depending on the STE layout and number of PCB variations it might be possible to design a pcb that sits on top of the resistors with the pickup pads in the right order so that it only requires a short jumper from each resistor.

I would just like to solder all of the 12 cables from STE resitors and have the signal protected. Seems we have exact the number of gates on 74HC245 to do that?

If you are looking for a generic pcb then you could use the Amiga external pickup PCB which is the same principle as the Atari board but already picks up all 12 bits plus composite sync: https://github.com/hoglet67/RGBtoHDMI/tree/master/Kicad_Amiga_12Bit_Buffered_Pickup/V1 (The readme.md is wrong for that and refers to the Commodore 128 for some reason) Note this board is not the same as the c0pperdragon boards designed for use with an internal Pi zero.

Here is the schematic: Amiga_External.pdf

You would still need to modify this board slightly by lifting up Pin 7 of U3 (G1_I) and connecting it to the mono input so that it ends up on the VSYNC signal. (G1_I is also on U2 but was fed to the Vsync buffer as there is an option for 9 bit capture with G1 on vsync). Cutting the track is not so easy because the G1_I signal passes on to U2.

The best solution would be for someone with an STE to design a suitable pick up board

[luciust]

@IanSB Thanks again for tips!

1. I think that there's no need for the pickup board that would "sit" on STE. Mainly because the PSU is on top of the resistor ladder, and the fit would be nearly impossible (thigh fit, heat).

2. Great idea with Amiga pickup! I have them in shipping, so in meantime I used the RGB0-RGB2 approach and the results are not bad! You can notice the cyan tint for sure in color mode but it's NOT THAT bad.

MONO: COLOR:

(Lotus STE version by: https://github.com/jonathanopalise/lotus-ste)

[luciust]

@IanSB

You would still need to modify this board slightly by lifting up Pin 7 of U3 (G1_I) and connecting it to the mono input so that it ends up on the VSYNC signal. (G1_I is also on U2 but was fed to the Vsync buffer as there is an option for 9 bit capture with G1 on vsync). Cutting the track is not so easy because the G1_I signal passes on to U2.

OK, I get it - lift it and put a kynar wire (doable under microscoper) to i.e. unused pin and connect MONO there. I think I'll use two cheap sockets to get the the connection.

[luciust]

@IanSB The boards came (in yellow this time) - can you confirm - the PIN 7 on the chip should be lifted and soldered to MONO signal from STE? The pad on PCB should not be connected?

[IanSB]

@luciust

can you confirm - the PIN 7 on the chip should be lifted and soldered to MONO signal from STE? The pad on PCB should not be connected?

Correct. There is another signal on the track going to the other chip

I think I will design a general purpose buffer board some time that can be used with the STE and maybe other systems but this should work for now.

[luciust]

@IanSB Is there a Amiga Pickup board pinout description? I can of course run the multimeter to find the right holes, but maybe there's an easier way?

[IanSB]

@luciust

The schematic is posted above (Amiga_External.pdf)

[luciust]

Right! Got it.

[luciust]

@IanSB How about HSYNC signal? I've checked the SYNC_I - it seems to be the BLANK (don't know Amiga that well - it seems that Denise has NC here on most schemas). What is the STE equivalent?

[IanSB]

@luciust

Composite sync from the Atari STE should connect to pin 32 of the Amiga board

[luciust]

OK, so I got STE with modulator which gives out Composite signal. I think I need - for the Amiga board at least use the Composte Sync generator just like this one:

or.. since STE is also using 74LS86 here - try to find the Composite sync there on the schematics...

[luciust]

Hmm... It seems that PIN 2 of U403 (the MC1377P on STE) with modulator has the H-SYNC and V-SYNC mixed, which seems to be a good composite sync candidate!

[luciust]

Yup, this is it!

[luciust]

OK, I got picture, but it's not really 12-bits, checking with the latest build