Combined VGA / Tube interface board for Atom

[KenLowe]

As you may be aware, I've been upgrading my Atom with various modern addons. Most recently, I got a second processor running, and that allowed me to run some other pretty cool software. When running this software, I discovered that others were running the software in an enhanced 80 column mode, whereas I could only run it in a 40 column mode. Well, that's no good!

So, it turns out that I was missing an upgrade! What I needed was the AtomGodilVideo, which would provide me with the glorious 80 column functionality. Unfortunately, the heart of that upgrade is a GODIL FPGA that is now obsolete, and can no longer be purchased, so that solution is now off the table . However, more recently another awesome solution has been developed that uses the modern Pi Pico. The only issue with this option is that it plugs into the same connector as my second processor.

So, it's time to mash the two boards together into a single board...

Combined VGA / Tube board for the Atom

There's still quite a lot of work to be done on this yet, but this is a first pass layout. I've designed the board with tube level shifters on board, so it only needs a Pi Zero to be attached to get the Co-Pro function. However, I thought it would be useful to also provide a 40 pin tube connector so that a normal tube device can be plugged in, in place of the Raspberry Pi.

I'll update progress on this thread.

[hoglet]

There is possibly a third way to implement an 80 column text mode, and that's to add it to RGBtoHDMI in a similar manner to how it supported the VideoNULA modes.

The Atom hardware would output a CLEAR 4 video signal, which would be digitised by RGBtoHDMI to get back the original frame buffer contents. If a particular magic number was detected in the frame buffer, then RGBtoHDMI would format it as an 80 column display rather than a CLEAR 4 display.

The new mode would be limited to 0x1800 bytes of memory (6K, same a CLEAR 4), where as the current VGA80 mode uses 0x1900 bytes. So the new mode would be 80x38 not 80x40, which I think would be fine.

Not promising this is possible, or that it would happen soon, but it's a possibility.

Dave

[KenLowe]

There is possibly a third way to implement an 80 column text mode, and that's to add it to RGBtoHDMI in a similar manner to how it supported the VideoNULA modes.

<------ SNIP ------>

Not promising this is possible, or that it would happen soon, but it's a possibility.

That would be pretty cool. Having different options is good, so I'll still progress this VGA solution.

[KenLowe]

I have a couple of quick clarification questions on databus resistors, if anyone can help...

My current tube installation includes a small PCB that provides an interface between the PL7 connector on the Atom motherboard, and one of my standard Tube level shifters attached to a Raspberry Pi Zero. The Tube level shifter has an in line 33R resistor on each of the data lines between the CPU and the tube data level shifter. That all seems to work well with the Atom, so I am proposing to retain that on the new board.

So, the question is, should I have an equivalent set of in line 33R resistors for the VGA data level shifter? This isn't in the original design by @cjm, but I'm wondering if it would be useful / safe addition?

Assuming it is appropriate to add inline resistors, the follow on question is... can the one set of resistors be used to feed both data level shifters, or should each level shifter have it's own set of resistors?

Early schematic of VGA / Tube board

And a couple of unrelated questions about the PLD on the existing Atom Tube board that I'm hoping to drop...

• The PLD generates the nTUBE signal, but I'm hoping I can generate this from the Pico (I've not investigated how to do that, yet, and might need a bit of guidance here too!). However, I can't find any detailed specs for the GPIO voltage levels, so I'm not sure if it would be able to drive 5v devices that might be attached to to the external tube socket without any additional level shifting or buffering. Can anyone offer any guidance on this? I'm assuming the GPIO will be able to drive the 74LVC245 level shifters that I use in my standard Tube level shifters (and the 74LVC4245 level shifters that I'll be using on this board)?
• The PLD also provides a buffering function for the Phi2 clock, and a jumper allows you to switch between the raw Phi2, and this buffer Phi2. For the external tube socket I'm proposing to put a jumper in that allows you to select between the unbuffered Phi2 and the level shifted Phi2. Default will be the unbuffered Phi2. Everywhere else, I'll be using the level shifted Phi2. Does that sound reasonable?

[hoglet]

So, the question is, should I have an equivalent set of in line 33R resistors for the VGA data level shifter? This isn't in the original design by @cjm, but I'm wondering if it would be useful / safe addition?

The resistors are an attempt to slow down the very-fast 74LVC edges, which reduces noise and ground bounce. They would be a useful addition I think to any design that uses LVC logic driving a data bus with several loads.

Assuming it is appropriate to add inline resistors, the follow on question is... can the one set of resistors be used to feed both data level shifters, or should each level shifter have it's own set of resistors?

If you are pushed for space then one set of resistors would probably be OK, as most of the data bus load I think will be on the Atom main board.

The PLD generates the nTUBE signal, but I'm hoping I can generate this from the Pico (I've not investigated how to do that, yet, and might need a bit of guidance here too!). However, I can't find any detailed specs for the GPIO voltage levels, so I'm not sure if it would be able to drive 5v devices that might be attached to to the external tube socket without any additional level shifting or buffering. Can anyone offer any guidance on this? I'm assuming the GPIO will be able to drive the 74LVC245 level shifters that I use in my standard Tube level shifters (and the 74LVC4245 level shifters that I'll be using on this board)?

This actually might be harder than it first looks.

The nTUBE signal logic needs to test most of the address bus (13 bits I think), and the Pico can't see all of the address bus at once. So it would have to:
- wait for the falling edge of the clock
- wait ~150ns for the address bus to settle
- sample half the address bus
- select a different address multiplexer
- wait ~20ns for the multiplexer to settle
- sample the other half of the address bus
- compare address against 0xBFEx

This needs to happen well before the rising edge of Phi2

At 1MHz operation you probably have enough time to do this, but it's still going to be significantly slower than an nTUBE signal generated by traditional means. But at 2MHz operation I think you will have problems.

Also, as there are a wide range of possible tube devices (both old and new), it's not clear that they would all be tolerant of a delayed nTUBE signal.

As far as voltage levels, I think a Pico should be able to drive an LVC245 (powered off 3.3V) or the 5V side of a 74LVC4245, which has 0.8/2.0V TTL input levels.

The PLD also provides a buffering function for the Phi2 clock, and a jumper allows you to switch between the raw Phi2, and this buffer Phi2. For the external tube socket I'm proposing to put a jumper in that allows you to select between the unbuffered Phi2 and the level shifted Phi2. Default will be the unbuffered Phi2. Everywhere else, I'll be using the level shifted Phi2. Does that sound reasonable?

This clock jumper was always a bit of a fudge. It's not clear to me why it makes such a difference. I'm not even sure I know whether the unbuffered (north) or the buffered (south) version is the better. It seems to depend on the processor that fitted. The idea was the buffering might help remove noise/glitches, but GALs are pretty fast so they could actually be having the opposite effect. It's probably worth doing some more experimentation with this.

Dave

[KenLowe]

Thank you for the detailed response!

If you are pushed for space then one set of resistors would probably be OK, as most of the data bus load I think will be on the Atom main board.

I don't think I'll be pushed for space, so I'll add them in initially, so ssee how the layout goes.

The nTUBE signal logic needs to test most of the address bus (13 bits I think), and the Pico can't see all of the address bus at once. So it would have to:
- wait for the falling edge of the clock
- wait ~150ns for the address bus to settle
- sample half the address bus
- select a different address multiplexer
- wait ~20ns for the multiplexer to settle
- sample the other half of the address bus
- compare address against 0xBFEx

This needs to happen well before the rising edge of Phi2

At 1MHz operation you probably have enough time to do this, but it's still going to be significantly slower than an nTUBE signal generated by traditional means. But at 2MHz operation I think you will have problems.

I, possibly naively, assumed the Pico was having to do this already for the VGA functionality, but your point is noted.

Also, as there are a wide range of possible tube devices (both old and new), it's not clear that they would all be tolerant of a delayed nTUBE signal.

As far as voltage levels, I think a Pico should be able to drive an LVC245 (powered off 3.3V) or the 5V side of a 74LVC4245, which has 0.8/2.0V TTL input levels.

Perhaps what I can do is make space on the board for a GAL and provide a jumper to switch between the GAL and the Pico. If we can demonstrate that the Pico is reliable, then I drop the GAL at a future board revision (if there is one).

This clock jumper was always a bit of a fudge. It's not clear to me why it makes such a difference. I'm not even sure I know whether the unbuffered (north) or the buffered (south) version is the better. It seems to depend on the processor that fitted. The idea was the buffering might help remove noise/glitches, but GALs are pretty fast so they could actually be having the opposite effect. It's probably worth doing some more experimentation with this.

Understood.

[hoglet]

I, possibly naively, assumed the Pico was having to do this already for the VGA functionality, but your point is noted.

Yes, it is doing exactly this already, but it's doing it later than is ideal for nTUBE:
https://github.com/hoglet67/pico_atomvg ... ga.pio#L23

Specifically. it's not starting this process until the Phi2 clock changes from 0 to 1, which guarantees the address is stable.

But this rather late for nTUBE, which needs to be asserted well before this edge clock (I know the Matchbox Co Pro will break if that's not the case, and I suspect PiTubeDirect will as well).

Dave

[KenLowe]

Right, here's my first attempt. Points to note:

• This board includes the GAL for generating the nTUBE and Buffered PHI2 signals. To help with the board layout, I've changed the pin assignment from that used on the current Atom Tube interface board.
• The nRDS signal was missing from the original VGA board, and had to be patched in. I've addressed this on my board, and I've wired the nRDS signal to the DIR input of both Pico data level shifter & Tube level shifter. On the Tube level shifters for my beeb, I'm using RnW, but this is because it's wired in the opposite direction. I'm assuming nRDS will be suitable for this tube level shifter.
• Both data level shifters have their own set of series resistors on the data lines.
• I've provided a jumper that lets you select the source on nTUBE, coming from either the GAL, or the Pico (gp22 / pin 29).
• I've provided a jumper that lets you select either buffered PHI2 or unbuffered PHI2.
• I've provided a jumper to disable the internal Tube data buffer. When the jumper is removed, the nOE signal for the internal Tube data level shifter is held high via a 10k resistor to the 3V3 rail. I assume this is ok, even when the internal Tube data level shifter is being driven by a 5v GAL. Perhaps I should use the level shifted version of nTUBE to drive nOE instead of the unshifted version.
• I've provided a jumper to remove power from the external tube port. This is to prevent the Atom / level shifter board from powering up a remote Co-Pro that has it's own power supply.
• I was convinced I was going to have to go 4 layer, but I've managed to squeeze everything into 2 layer. Most congestion is around the level shifters that sit underneath the internally fitted Raspberry Pi.
• To squeeze it all in I had to reduce the track thickness from the default 0.25mm down to 0.2mm. This is the minimum that the PCB manufacturer will accept. I reduced the via size accordingly - again within the PCB manufacturers minimum tolerance.
• Power (+3V3 & 5V) and Ground tracks are a minimum 0.4mm, going up to 0.5mm where space allows. There is also a ground pour both top and bottom.
• I've still to add in the facility for a pushbutton, for a possible future screen capture function.
• I'm going to make a small cutout in the PCB around the PICO USB socket to provide enough clearance to fully insert a USB cable - similar to what I did with the PicoTube adaptor.
• I'm going to move the 40 pin external Tube socket so it's closer to the edge of the PCB.
• I'm going to modify the Pico footprint so it will accept either surface mount of through hole Pico board - similar to what I did with the PicoTube adaptor.

As always, comments and feedback welcome!

PCB layout with ground pour visible

PCB layout with ground pour removed

3D render - rear

3D render - front

3D render - front with Pi removed to show level shifters

Schematic

[hoglet]

On the Tube level shifters for my beeb, I'm using RnW, but this is because it's wired in the opposite direction. I'm assuming nRDS will be suitable for this tube level shifter.

I think there is a possible issue with this...

nRDS is high for the first half of a tube read cycle, so the level shifter will be driving towards the Pi Zero. This may conflict with data being driven by the Pi Zero, which also starts driving during the first half of the read cycle. This kind of conflict is bad for reliability, because it creates a big noise spike.

Existing PiTubeDirect level shifters avoid this conflict by:
- using the RnW signal instead, but this needs inverting with the 74LVC4245
- gating the level shifter nOE signal with Phi2

I'm not sure what your Level Shifters do here, and couldn't locate a schematic to check.

I don't think this problem arises on the AtomVGA side, because the Pico PIO software waits for the rising edge of the clock before it starts driving the bus.

I think it's worth using the GAL to generate two control signals for the Tube level shifter:
- DIR = !RnW
- nOE = !(A15 & !A14 & A13 & A12 & A11 & A10 & A9 & A8 & A7 & A6 & A5 & Phi2)

I think there are enough pins if you drop A3.

Dave

You might need to drop A

[KenLowe]

I think there is a possible issue with this...

nRDS is high for the first half of a tube read cycle, so the level shifter will be driving towards the Pi Zero. This may conflict with data being driven by the Pi Zero, which also starts driving during the first half of the read cycle. This kind of conflict is bad for reliability, because it creates a big noise spike.

Existing PiTubeDirect level shifters avoid this conflict by:
- using the RnW signal instead, but this needs inverting with the 74LVC4245
- gating the level shifter nOE signal with Phi2

I'm not sure what your Level Shifters do here, and couldn't locate a schematic to check.

I don't think this problem arises on the AtomVGA side, because the Pico PIO software waits for the rising edge of the clock before it starts driving the bus.

I think it's worth using the GAL to generate two control signals for the Tube level shifter:
- DIR = !RnW
- nOE = !(A15 & !A14 & A13 & A12 & A11 & A10 & A9 & A8 & A7 & A6 & A5 & Phi2)

I think there are enough pins if you drop A3.

Thanks Dave.

In my beeb level shifter, nOE isn't gated. It just uses nTUBE:

Tube Schematic

[BigEd]

I have the impression that the price difference for 4 layer is much less than it used to be - and it might help pre-emptively avoid various noise and crosstalk problems which keep cropping up in retro projects. Is it worth reconsidering? (Ground pour is not felt to help very much. It helps save on etchant!)

[KenLowe]

I have the impression that the price difference for 4 layer is much less than it used to be - and it might help pre-emptively avoid various noise and crosstalk problems which keep cropping up in retro projects. Is it worth reconsidering? (Ground pour is not felt to help very much. It helps save on etchant!)

Yes, I've certainly not ruled it out. It would be very easy to add now that I've managed to squeeze everything into 2 layers. I'll create a separate 4 layer board, and check the price difference!

[KenLowe]

I think it's worth using the GAL to generate two control signals for the Tube level shifter:
- DIR = !RnW
- nOE = !(A15 & !A14 & A13 & A12 & A11 & A10 & A9 & A8 & A7 & A6 & A5 & Phi2)

I think there are enough pins if you drop A3.

I notice you have PHI2 connected to both pins 1 & 2. Is it not possible to route PHI2 to pin 1 only, and free up pin 2? Coupled with pin 11, that would give me the two free pins I need to play with, whilst retaining A3.

As an alternative, I could switch to the larger GAL22V10. I should have enough space to fit it.

[hoglet]

In my beeb level shifter, nOE isn't gated. It just uses nTUBE.

Ah, your level shifter uses a 74LVC245 which avoids the need to invert RnW.

The only case where it's absolutely critical to gate nOE is with a internal Master level shifter, because the Master uses the first half of the clock cycle for video data over the same data bus.

If you want to stick with the 74LVC4245, I think the minimum you need to do is to replace nRDS with an inverted RnW.

My other general worry, especially with lots of LVC parts, is signal integrity issues due to fast edges. These are worse on a two layer board than on a four layer board, because there isn't a solid ground plane

I notice you have PHI2 connected to both pins 1 & 2. Is it not possible to route PHI2 to pin 1 only, and free up pin 2? Coupled with pin 11, that would give me the two free pins I need to play with, whilst retaining A3.

Yes, if you are using the GAL for combinatorial logic only, then you only need Phi2 connected once.

Dave

[KenLowe]

If you want to stick with the 74LVC4245, I think the minimum you need to do is to replace nRDS with an inverted RnW.

Ok. I'll make that change now. From a routing perspective, it would be easier if I changed both data level shifters to use an inverted RnW. Do you see any issue with doing that, or would that actually be preferable?

My other general worry, especially with lots of LVC parts, is signal integrity issues due to fast edges. These are worse on a two layer board than on a four layer board, because there isn't a solid ground plane

Understood. As mentioned in my last post, I'll create a 4 layer board, and see what the price difference is. As BigEd has indicated, it's probably not going to make much difference, and if not, I'll go with the 4 layers. So, the next question is - along with the GND plane, should I use 3V3 or 5V for the other inner layer?

nRDS Routing

GND Routing

5V Routing - Part 1

5V Routing - Part 2

3V3 Routing

[hoglet]

From a routing perspective, it would be easier if I changed both data level shifters to use an inverted RnW. Do you see any issue with doing that, or would that actually be preferable?

I don't see any issue with that.

Dave

[roland]

I'll create a separate 4 layer board, and check the price difference!

Are two layer boards still being produced

The price difference is quite small, especially when the board is within 100x100mm. I have all my latest boards in 4 layer. Much easier in power and ground routing and no issues with signals. Up till now at least - I still have to build my mode7 board for the Elk

[KenLowe]

I'll create a separate 4 layer board, and check the price difference!

Are two layer boards still being produced

The price difference is quite small, especially when the board is within 100x100mm. I have all my latest boards in 4 layer. Much easier in power and ground routing and no issues with signals. Up till now at least - I still have to build my mode7 board for the Elk

Haha. Give me a chance. I've only just recently moved on from single sided veroboard! Anyway, 4 layer to follow shortly. I've just been updating with all the changes discussed earlier:

• Changed to dual footprint for Pico board so it can be surface mounted, or installed with headers.
• RnW signal routed to PLD, and new inverted RnW signal generated in PLD. New inverted RnW signal routed to nOE of data bus level shifters. Can also be gated, if required.
• Fixed error in PHI2 / Buffered PHI2 routing .
• Added diode, and powering Pico from Vsys instead of Vbus.
• Pico USB shielding now tied to GND.
• Moved external tube connector closer to board edge.
• Renumbered level shifters.
• Further tidy up of signal routing.

Edit: Right, before taxes and shipping, a batch of 5 bare PCBs:

2 Layer: £1.64
4 Layer: £5.73

3.5 x More expensive for the 4 layer board! ...but still pretty cheap .

Latest Schematic

Latest 3D Render

[KenLowe]

Whilst walking the dog last night, it dawned on me that connecting the Pico +3V3 supply to the Pi Zero +3V3 supply is possibly a bad thing. So, I've now disconnected the Pi Zero +3V3 pins from the board. All +3V3 devices on the board are now being powered solely from the Pico. It's easy to revert back if the view is that these feeds can be run safely in parallel. I didn't want to put in extra blocking diodes, because I didn't want to introduce an extra voltage drop that may impact TTL logic.

Updated routing of +3V3 supplies

[KenLowe]

Ok, I think I'm just about there with the board. I have got one final question...

Can't you use the HS and VS signals of the 6847 to sync the PiPico?

Theoretically yes, but in practice it's quite a challenge to do this. You are effectively building a "genlock" system, where the PLL that's clocking the Pico (at 125MHz) is continuously varied so the Pico frame is locked to the 6847 frame.

RGBtoHDMI does this, but it's pretty complex!

But looking at the capabilities of the PLLs in the Pico, they don't seem to support fractional ratios. So it's not possible to adjust them in very small steps. There is some fractional division possible downstream of the PLL, but that is implemented by toggling between two integer ratios. I don't know if the effects of this would be visible or not.

Dave

Should I bring in the VSYNC signal (nFS???) from the 6847? I don't have any spare connections on my level shifters, so I'd probably go for a basic MOSFET implementation

If not, is there anything else I should add to the board just now to make it easier to address the VSYNC 'issue'?

[hoglet]

If not, is there anything else I should add to the board just now to make it easier to address the VSYNC 'issue'?

I can thing of two different ways to fix the VSYNC issue:

- Have the Pico take in the nFS signal from the 6847, then dynamically adjust the system clock so that the VGA video is gen-locked to this (like RGBtoHDMI does). This is not easy, because the system clock PLL in the Pico has less resolution than the Pi PLLs. Another option would be to use the fractional clock dividers in the PIO blocks. These work by skipping whole system clock cycles, which may cause visual artifacts. The bottom line here is that no one has done this, and it may not work well.

- Have the Pico generate a seperate VSYNC output that could be connected to the 8255 PC7 input (e.g. by bending out the PC7 pin and soldering a jumper wire to it). Ideally this would have a mark-space ratio identical to that generated by the 6847, which is different to VGA vsync.

It would be good if the board allowed exerimentation with both options.

For a simple level shifter you could just use a resistive divider, as VSYNC is slow.

Dave

[KenLowe]

It would be good if the board allowed experimentation with both options.

For a simple level shifter you could just use a resistive divider, as VSYNC is slow.

I've added the MOSFET circuit to the board. I think it's bi-directional, so it should cater for both the scenarios you've outlined. I had already pretty much laid it out before I saw your note about resistive divider, so I've just left that in place. It adds virtually nothing extra to the cost.

MOSFET Level Shifter Circuit

3D Render - Front

3D Render - Rear

[KenLowe]

New boards arrived yesterday, and first error found already #-o.

I've managed to misconfigure the GAL16V8 and have configured pins 15 & 16 as inputs, when they can only actually be used as outputs when the GAL is configured for used in simple mode. It doesn't work in complex mode either, because pin 19 is an input, and this pin can only be an output. Duh!

I think I'll make a little adaptor board to rearrange the pins, which should avoid me from having to cut tracks. I should have enough space around the IC to do that. I'll make it using breadboard first, so I can at least test out the rest of the board first.

Edit: Actually...

I think it's worth using the GAL to generate two control signals for the Tube level shifter:
- DIR = !RnW
- nOE = !(A15 & !A14 & A13 & A12 & A11 & A10 & A9 & A8 & A7 & A6 & A5 & Phi2)

I think there are enough pins if you drop A3.

Pin 19 is A3, so if I don't use A3 in the GAL, then I should be able to program it in complex mode! At least for initial testing...

Edit 2: Bigger problems! I've managed to get the PL7 header 180 degrees out of position! Aaargh. That's a total rework of the PCB :oops:.

It took my Atom 5v PSU out with it, but everything else on the Atom seems fine when hooked up to my bench supply! As a minimum, a new axial fuse will be required to fix the PSU.

Ah well. Back, literally, to the drawing board. At least i can also now fix my GAL16V8 pin assignment error at the same time :roll:.

[hoglet]

Ah well. Back, literally, to the drawing board. At least i can also now fix my GAL16V8 pin assignment error at the same time .

That's a shame about PL7, and you can see this on the render you posted earlier. I should have spotted this, as I'm very familiar with the orientation of PL7.

As well as orientation, make sure you get rows A and B right. It's worth beeping out a couple of signals (e.g. RnW on the 6502) to make sure you have this right after rotating.

Regarding the GAL, definitely run the design through WinCUPL before committing to a new pinout. I find the different 16V8 GALs modes very confusing, and have to return to the data sheet each time.

Dave

[roland]

Edit 2: Bigger problems! I've managed to get the PL7 header 180 degrees out of position! Aaargh. That's a total rework of the PCB .

This is the nightmare of every PCB-for-the-Atom designer. I always print my PCB and place it on the Atom just like I would insert the final board and the I check if the power lines are correct and also if some of the other lines match. And I (re)do this check mostly a day after I finished the design so that I check it with a clear mind.

In most cases I also place the components on the print out to see if the footprints physically match.

That's not a guarantee that all is well but I have prevented a lot of PCB errors this way. But still .... the first versions of EENT and EVAA also had footprint errors, despite all my attempts to make it the first time right. It's part of the job

[KenLowe]

I'm confident the pin assignment of my PL7 footprint is correct. It's just orientated wrong. I did some spot checks against my existing AtomTube interface board to validate this last night. However, I will do a full pin to pin check before I commit to another order.

Regarding the GAL, it was when I tried to build the jed file in WinCPUL that I discovered the pin assignment issue. I had looked at the datasheet during the design stage, but clearly not in enough detail! Again, I will double check this before placing an order.

All a bit careless, but as you say, it comes with the territory .

[KenLowe]

So, all's not lost! I'm at least able to test the basic functionality of the board by rotating the whole board around by 180 degrees and plugging it into J7. I'm just using standard pin headers, so there's keying to worry about. Ok, so it doesn't fit in the case, but at least I can check that everything else is working!

So far I've just tested the tube function, and that seems to be working fine using both the Raspberry Pi 40 pin GPIO header connector (just plug the Raspberry Pi directly into header U2 on my board), and the 40 pin tube header (needs an actual tube device plugged into J2 on my board - for example, Raspberry Pi with level shifter, or Matchbox Co-Pro, or real BITD Co-Pro).

Testing the VGA section will take a bit more time. I'm still waiting for some box headers & IDC connectors (due Friday), so I can connect the main board to the VGA connector board.

[roland]

I work the same way, try to get it to work for finding more faults. When it’s all finished I am also interested in a board

[KenLowe]

That's the board redesigned with PL7 correctly orientated now. I basically had to start from scratch. It's almost an exact mirror of my original board. Not only did I have to mirror all the main parts, but I also had to mirror a lot of the individual pins of the level shifter IC. Anyway, that's everything fitted and routed again. I've still been able to keep everything in 2 layers, but will go with a 4 layer board when it comes to fabrication to give myself nice clean ground and power planes.

Once again I've swapped the pins around on the GAL to help with routing. However, this time I've double checked that design compiles ok, and it does!

The only thing I'm a little bit concerned about is the position of the VGA header. The ribbon cable will come very close to the edge of the cutout at the rear of the case for the P6 header.

At some point this weekend I'll hopefully get a bit of time to test the VGA function on my original board. The various box headers & IDC connectors I was waiting for haven't arrived yet, so I'll just use standard double row header and some dupont wires instead.

Updated PCB Layout. PL7 orientated correctly now!

3D render without PiZero

3D render with PiZero

3D render of rear

[KenLowe]

At some point this weekend I'll hopefully get a bit of time to test the VGA function on my original board. The various box headers & IDC connectors I was waiting for haven't arrived yet, so I'll just use standard double row header and some dupont wires instead.

Right, I've installed atomvga.uf2 on my Pico and plugged it into my board, and I've had some success. When I initially power on the Atom, I can see a screen full of random characters and blocks on my VGA monitor. These are the same random characters and blocks I see via the RGB2HDMI adaptor when I have it connected. When I then press break to initialise the Atom, I get a green border and black screen with a few green horizontal lines at the top of the screen that jump about a bit. If I then blind type CLEAR 4 I get a full green screen, but no text. Pressing break again doesn't do anything more.

I'm guessing I need a ROM or some other software to get it running properly? Any pointers???

Edit: Duh, hold on. I need to bypass one of the buffer ICs...