Combined VGA / Tube interface board for Atom

[KenLowe]

I've done a bit more work on the genlock code:
- refactored the code so the bulk of the genlock implementation is in it's own source file
- defined an common interface for genlock implementations
- updated the GENLOCK N command to allow switching between implementions at run time
- replaced the adhoc control code with a properly designed "PD control" based algorithm

<---SNIP--->

The different genlock implementations (selected by the GENLOCK command) are:
- N=0 is genlock off
- N=1 is genlock on, by varying CLKDIV (780ppm step size)
- N=2 is genlock on, by variying HTOTAL (125ppm step size)
- N=3 is genlock on, by varying VTOTAL (1900ppm step size)

<---SNIP--->

Ken, it's possibly worth you retesting the N=2 mode, as the implementation is now a bit better. You may still need to manually tweak CLOCK and PHASE on monitor.

There is also a GENDEBUG <0|1> command that enables/disables debugging to the serial port.

And here's an updated COLTEST program which uses the 0,1,2 and 3 keys to change between modes

There's something a bit strange happening with the updated COLTEST program. Once I've selected a genlock mode, if I then switch between modes I eventually get into a position where the screen goes blank (sometimes the monitor will complain with an 'Input not supported' message). Once this happens, even switching back to mode 0 (genlock off) doesn't work, and I need to reset the Pico and reboot the Atom to get the screen working again.

But, anyway, when it does work...

N=1: I get the usual shimmer / wobble. Adjusting CLOCK of PHASE doesn't seem to make any difference.
N=2: Adjusting the monitor CLOCK setting to 52 and pulling the PHASE setting down very low (below about 5) seems to have nailed it! Rock solid on the Lenovo. I'm now wondering if I haven't been aggressive enough with the PHASE setting previously!
N=3: Produces an up / down wobble by one or two pixel lines.

There is not much more that I can think of doing on this now.

Hopefully there's nothing more to do! I've got my updated PCB on order, that has both HSYCN & VSYNC available to the Pico, so that might give us some more options, if needed?

[KenLowe]

On my Dell monitor:

N=1: Works well. Steady screen
N=2: Shimmer was apparent initially, but reducing the PHASE from 80 (ish) down to about 50 has fixed that, and I now have a steady screen here too.
N=3: I get a blank screen, and (sometimes) need to reset the Pico / Atom to get things back again.

[hoglet]

There's something a bit strange happening with the updated COLTEST program. Once I've selected a genlock mode, if I then switch between modes I eventually get into a position where the screen goes blank (sometimes the monitor will complain with an 'Input not supported' message). Once this happens, even switching back to mode 0 (genlock off) doesn't work, and I need to reset the Pico and reboot the Atom to get the screen working again.

Yes, I've seen this behaviour occasionally during development, but it doesn't happen often enough for me to have tracked it down yet. It's almost certainly the scanvideo code falling over. If you find a way to replicate the failure consistently I would be interested. It wasn't an issue in previous builds because it's assoiciated with changing mode. I would just try to reset the scanvideo library, but there isn't an API that allows you to do this.

N=2: Adjusting the monitor CLOCK setting to 52 and pulling the PHASE setting down very low (below about 5) seems to have nailed it! Rock solid on the Lenovo. I'm now wondering if I haven't been aggressive enough with the PHASE setting previously!

It's good that this is finally working. The new N=2 code does two things differently:
- the "step size" is now 125ppm rather than 250ppm
- the pixels are generated with a fractional clock, so the line should appear to be 800 pixels long
So it's possible it's these changes that have made a difference with the Lenovo.

N=3: Produces an up / down wobble by one or two pixel lines.

This is very much expected - this mode only works well on two out of the nine monitors I am testing with.

Thanks for doing the testing!

I'll see if I can track down the scanvideo stalling issue.

Dave

[KenLowe]

I've just tested an OZMOO game in 80 column mode with N=2, and notice that I lose one or two pixel columns at the RHS of the screen. In the attached photo it's particularly visible of the first line, where the letter 'o' from 'so' is cut off. This doesn't happen on the Dell.

Edit 1: Ah. It seems to be my monitor CLOCK setting that's doing that. But if I adjust that, I start getting the shimmering again.

80 Column screen on Lenovo monitor

Edit 2: Right, I seem to have found a better monitor setting with N=2. Setting CLOCK back to 50 brings all 80 text columns within the screen boundary, and dropping PHASE below about 15 eliminates the shimmering. Ignore the fact that I've used different foreground and background colours for this second 80 column test. The colours don't make any difference.

80 Column screen - updated CLOCK and PHASE settings

One other thing I've noticed with these settings is that when I load the ASA menu screen, the far RHS pixel column is missing in the upper and lower border section of the screen, but other than that, the picture is very stable. I think this is a very minor issue we can live with!

Missing far RHS pixel column in upper and lower border area

[hoglet]

Hi Ken,

Regarding the Monitor CLOCK setting, in Genlock Mode 2 you may well get a good result with the clock setting back in the middle (50?), because the timing of the pixels should be close to what's expected with a standard line length of 800.

Regarding the hang, I've narrowed this down to changing from MODE 3 to MODE 2, and interestingly it only appears to happen when the serial debug is enabled. So if you edit COLTEST and change line 10 to set GENDEBUG to 0, then it should be more reliable. I would be interested if you can confirm this is the case for you as well.

Dave

[KenLowe]

Regarding the hang, I've narrowed this down to changing from MODE 3 to MODE 2

I can get it to fail without ever going into MODE 3.

interestingly it only appears to happen when the serial debug is enabled. So if you edit COLTEST and change line 10 to set GENDEBUG to 0, then it should be more reliable. I would be interested if you can confirm this is the case for you as well.

I've disabled serial debug, but I can still get it to fail. Most recently it failed when switching from MODE 2 to MODE 1, although I was switching between modes 1, 2 & 3 a few times before it eventually failed. I wasn't always waiting for genlock to occur before switching mode, and I'm not sure if that makes a difference.

[hoglet]

I've disabled serial debug, but I can still get it to fail. Most recently it failed when switching from MODE 2 to MODE 1, although I was switching between modes 1, 2 & 3 a few times before it eventually failed.

Sounds like your system is failing much more frequently than mine.

The code I'm most suspicious of is the code that enters/leaves MODE 2.

Does it ever fail when MODE 2 is not involved?

Does it ever fail when going back-and-too between MODE 2 and MODE 0?

(Make sure you have disabled the debug option)

Dave

[KenLowe]

Does it ever fail when MODE 2 is not involved?

Yes, I can get it to partly fail, but it takes a few random switches between 0, 1 & 3 before it fails. Last test failed on the switch to 1 (can't remember which mode I switched from). I do seem to be able to recover from this by switching back to MODE 0 again (which is why I'm saying that it's only partly failing). I don't seem to be able to get it to fail if I just switch between MODE 1 and MODE 3, so MODE 0 seems to be implicated in the fail. Similarly, I don't seem to be able to get it to recover by just switching between MODE 1 and MODE 3. It looks like I need to switch into MODE 0 to get it to recover.

Does it ever fail when going back-and-too between MODE 2 and MODE 0?

I've been able to get it to partly fail a couple of time. On both occasions it failed when switching from MODE 0 to MODE 2. On both occasions I never gave it very long in MODE 0 (short enough that the characters didn't actually appear on screen) before switching back to MODE 2. And on both occasions switching back to MODE 0 recovered the situation.

(Make sure you have disabled the debug option)

All these tests were done with the debug option disabled (line 10 edited).

Edit: Is there an 80 column version of COLTEST anywhere? I'm pretty sure I've seen a post somewhere showing an 80 column version of COLTEST, but I couldn't find anything in the Archive.

[hoglet]

Thank Ken, all useful input which I need to ponder on...

I've never seen this partial failure mode - very wierd. Possibly grasping at straws here, but is there any chance that's the monitor rather than the Pico.

I can't get my system to fail at all at the moment. I think I'll write a random mode change program and leave that running for a while.

Edit: Is there an 80 column version of COLTEST anywhere? I'm pretty sure I've seen a post somewhere showing an 80 column version of COLTEST, but I couldn't find anything in the Archive.

There is a character set test in Chapter B called GODIL 80x40 DEMO.

Genlock is currently disabled when entering 80-column mode, because I found it impossible to get a clean image. It also didn't seem that useful. Can you think of any good applications for it? I guess in non-attribute mode, the foreground and background colours could be changed.

Dave

[KenLowe]

I've never seen this partial failure mode - very wierd. Possibly grasping at straws here, but is there any chance that's the monitor rather than the Pico.

I guess it's possible that the monitor is working at the edge of its limits, and will works sometimes, but not others. When it does go wrong, the monitor reports 'Input Not Supported'. I've just tried again this morning, and switching a few times between MODE 1 and MODE 3 got it to fail in this way, but continued switching between MODES 1 & 3 brought it back to life again, so it looks like I don't need to switch to MODE 0 to get it working again, after all.

There is a character set test in Chapter B called GODIL 80x40 DEMO.

Genlock is currently disabled when entering 80-column mode, because I found it impossible to get a clean image. It also didn't seem that useful. Can you think of any good applications for it? I guess in non-attribute mode, the foreground and background colours could be changed.

Thank you. That's what I was looking for. Having noticed the cropped characters when running the Ozmoo games in 80 character mode, caused by my adjustment of the monitor CLOCK setting, I was looking for something that would run in 80 character mode and help me check for any other issues. Nothing noticed!

[hoglet]

When it does go wrong, the monitor reports 'Input Not Supported'. I've just tried again this morning, and switching a few times between MODE 1 and MODE 3 got it to fail in this way, but continued switching between MODES 1 & 3 brought it back to life again, so it looks like I don't need to switch to MODE 0 to get it working again, after all.

When it goes into this partial failure mode, can you try:
- plugging / unplugging the monitor
- then, power cycling the monitor
- then, swapping to a different monitor

It would also be very useful to look at the hsync and vsync signals on a scope when this happens.

Dave

[KenLowe]

When it goes into this partial failure mode, can you try:
- plugging / unplugging the monitor
- then, power cycling the monitor
- then, swapping to a different monitor

Right, this might introduce another layer of complexity that I've not specifically mentioned before. When I swap between monitors the COLTEST display is often replaced with the Pico Start Up message, which forces me to reset the Atom to get back to a command prompt. I hadn't given this much thought up until now, and had assumed this was designed behaviour. But thinking about this now, I'm not sure how the Pico would know that the monitors have been swapped, for it to reset itself - because the only signals that go to the monitor are RGB, Hsync and VSync. There's no feedback. Hmmm...

I'm not sure if power cycling and just plugging / unplugging does the same. Further testing will be required. Would the Pico serial debug help understand what's happening here?

Edit 1: So, just unplugging the VGA cable and plugging it back in again is enough to cause the Pico to reset back to the Pico Start Up message. Not every time, but most times. I see this behaviour with both the Lenovo and the Dell.

Edit 2: On the other hand, power cycling the monitor (from the button on the front of the monitor, or by removing AC power) doesn't cause the reset, and what was displayed before I turn the power off reappears when I power it back on again.

It would also be very useful to look at the hsync and vsync signals on a scope when this happens.

I've got to head out for the day soon, but will get back to this later this afternoon / evening.

[hoglet]

Right, this might introduce another layer of complexity that I've not specifically mentioned before. When I swap between monitors the COLTEST display is often replaced with the Pico Start Up message, which forces me to reset the Atom to get back to a command prompt.

That's rather unexpected... I wonder if this is somehow causing a pretty sizable glitch on the power supplies?

It would be interesting to measure the voltage between the Atom ground and Monitor ground with the two devices seperate. If either is using a switching power supply that's floating, there could be a fair fair difference (~100V).

Dave

[KenLowe]

It would be interesting to measure the voltage between the Atom ground and Monitor ground with the two devices separate. If either is using a switching power supply that's floating, there could be a fair fair difference (~100V).

About 90VAC between the two GNDs!

[hoglet]

About 90VAC between the two GNDs!

Can you check if it's the Atom or the Monitor by measuring to mains earth?

This is not particularly unusual - but it's useful to know which device is responsible.

Once you know, you can be careful about hot-plugging cables that are not intended to be hot plugged. One of my monitor's does this, even when in standby mode.

Dave

[KenLowe]

Can you check if it's the Atom or the Monitor by measuring to mains earth?

Sorry. I ran out of time earlier this morning to test that. My new Atom 5V PSU is measuring 90VAC between signal GND and mains earth. I might try and source a different 5V PSU, to see if that solves the Pico reboot issue, when plugging / unplugging VGA connectors.

[hoglet]

Sorry. I ran out of time earlier this morning to test that. My new Atom 5V PSU is measuring 90VAC between signal GND and mains earth. I might try and source a different 5V PSU, to see if that solves the Pico reboot issue, when plugging / unplugging VGA connectors.

I wrote a short test program this afternoon to randomly change genlock mode every half a second or so.

With GENDEBUG 0 I left this running for an hour didn't manage to hit the permenant loss of video issue.

With GENDEBUG 1 it hit the issue almost immediately.

I still have no idea what's going on here, or why your system seems to fail much more readily.

I'll try to add some code to more cleanly stop and start the video when changing genlock modes.

Dave

[KenLowe]

It would also be very useful to look at the hsync and vsync signals on a scope when this happens.

Right, I eventually managed to get a scope hooked up, and I'm not seeing anything particularly obvious as I change genlock MODEs. But the monitor doesn't like these switches and quite often reports 'Input Not Supported'. I can see the HSYNC pulse shorten from 2.6us to 2.5us and then stretch back out to 2.6us as I change between MODEs 1 & 2 but this happens with both a good switch and a bad switch. These tests were with GENDEBUG set to 0.

When it goes into this partial failure mode, can you try:
- power cycling the monitor

So, power cycling the monitor (via the power button on the front of the monitor) will sometimes bring the display back. Interestingly, if I have a good display, and then power cycle the monitor I can also get it to occasionally do the opposite, and report 'Input Not Supported'. This does seem like a different issue to the permanent lock out issue we get when GENDEBUG is set to 1.

The scope is measuring a HSYNC period of 31.8us (31.45kHz). Is that a little bit slow for VGA? I understand the HSYNC pulse of a 640x480 60Hz VGA signal should have a frequency of 31.5kHz. It feels like one of the Pico signals is on the edge of a tolerance for the Lenovo monitor. As mentioned previously this monitor supports older 15kHz RGB modes. I wonder if this makes it more sensitive at the 31.5kHz frequency?

Let me know if there's anything in particular I should be looking for in these traces.

Blue trace: HSYNC
Yellow trace: VSYNC

VSYNC / HSYNC - Zoom in of VSYNC pulse

VSYNC / HSYNC - Zoom out

[hoglet]

The scope is measuring a HSYNC period of 31.8us (31.45kHz). Is that a little bit slow for VGA? I understand the HSYNC pulse of a 640x480 60Hz VGA signal should have a frequency of 31.5kHz. It feels like one of the Pico signals is on the edge of a tolerance for the Lenovo monitor. As mentioned previously this monitor supports older 15kHz RGB modes. I wonder if this makes it more sensitive at the 31.5kHz frequency?

The ideal 640x480 timings have:
- pixel clock of 25.175MHz
- line length of 800 pixels
- hsync period of 31.778us

What you have measured is pretty close to that, and a +/-0.5% tolerance is normally not a problem.

The genlock implementation is trying to adjust the timing such that two VGA lines exactly match one Atom line. An Atom line is 63.695us, so the VGA line should be half this, which is: 31.8475us. If there is any deviation from what your Atom is outputting, then the genlock point will drift.

The other big difference is there are only 524 lines, where as there should be 525. That might be more significant.

Let me know if there's anything in particular I should be looking for in these traces.

Not really, I was hoping there would be something obviously amiss.

Dave

[KenLowe]

My new PCBs arrived today, so took some time out this afternoon to solder everything up. Annoyingly, I soldered the PL7 header 180 degrees out of position, so (because it's keyed) it wouldn't plug into the Atom .

I snipped off the keyed plastic surround, and managed to plug it in and test it. Everything working as it should, so that was a bonus .

I then decided to (destructively) remove the incorrectly fitted header and replace it with a new one in the correct orientation. Just as I soldered the final pin, I realised I had fitted the header to the wrong side of the PCB. Aaargh . I threw the PCB across the room and cursed for about 5 mins, then decided to solder up a second board. Got this one right first time, and it's all working nicely in the Atom .

What I have subsequently realised, and this is probably the route of all the errors I've been making, is that the PL7 header actually needs to be installed 180 degrees out of position, when compared to the footprint printed on the PCB. As a consequence, the two securing holes on the header now don't align with the equivalent holes in the PCB. It's a very minor point, but I'll fix it in the Kicad PCB layout. Alternatively, it could be argued that the PL7 socket on my Atom is actually soldered 180 degrees out of position.

Earlier this evening, I recovered the original PCB that I had launched across the room, and after inspection decided to (destructively) remove the PL7 header for a second time. I've been able to do that without too much issue, but I've run out of headers, so will need to order up some more to finish off this board! Other than the missing header, this board is also fine!

Anyway, other than my stupid soldering mistakes, these new boards are working perfectly. 80 column mode is working nicely, the co-pro is working nicely (using both the internal level shifter, and the external header), and genlock is working nicely with my Lenovo monitor. I don't have any 2 x 6 pin box headers for the RGB header, so I've not been able to test that to a RGB2HDMI board yet. I'll need to get some of those box headers ordered up, or maybe just use some standard pin headers. Other than that, I think I can declare this as 'Mission Accomplished'!

New PCBs. One with SMD stuff only, and one with all headers and GAL attached.

New PCB with Pi Zero and Pi Pico attached.

[KenLowe]

What I have subsequently realised, and this is probably the route of all the errors I've been making, is that the PL7 header actually needs to be installed 180 degrees out of position, when compared to the footprint printed on the PCB. As a consequence, the two securing holes on the header now don't align with the equivalent holes in the PCB. It's a very minor point, but I'll fix it in the Kicad PCB layout. Alternatively, it could be argued that the PL7 socket on my Atom is actually soldered 180 degrees out of position.

I've been looking into this a bit further, and I suspect the PL7 socket on my Atom motherboard is probably the wrong way round. Currently, pin b1 of the DIN41612 2x32 pin socket is connected to the Atom 5v. This then translates through to pin b32 on the pin header of my PCB. If I rotate the PL7 socket around by 180 degrees, then pin a32 will connect to the Atom 5v, which then translates through to pin a1 on my PCB, which seems a bit more logical.

The issue here seems to be the odd translation of pins from the female to male header. I've provided a bit more detail in this post:

viewtopic.php?p=387375#p387375

Female PL7 socket is probably 180 degrees out of orientation!

[Louis.m]

Hi Ken,

The problem is that the designers at Acorn were probably not aware of the fact that the right angle male connector PL6 was and is manufactured in one model only and therefore (in full compliance with Murphy's Law) couldn't be mounted correctly in the Atom

Up to this day there are 10 kind of Atomists:
• Those who believe Acorn is always right.
• Those who use the internationally accepted Deutsche Industrie Norm.

I count myself among the latter because DIN 41 612 is from the first half of the nineteen hundreds (much older than the Acorn Atom).

See: viewtopic.php?f=44&t=9280
and: viewtopic.php?f=44&t=22068

[Louis.m]

Hi Ken,

After some research I came to the conclusion that, according to the following two pages from a manufacturer's catalogue,

ERNI DIN 41612 Katalog p.32.pdf

(133.25 KiB) Downloaded 44 times

and

ERNI DIN 41612 Katalog p.22.pdf

(170.03 KiB) Downloaded 38 times

,both connectors PL6 and PL7 in your picture are mounted completely correct.

Picture from Ken

The Female PL7 socket is probably 180 degrees out of orientation [20230311_092818].jpg (33.55 KiB) Viewed 2613 times

See also these pictures of an uninhabited Atom motherboard below.
The two rows from PL6 and PL7 closest to each other are Rows B, the outer two are Rows A (ABBA easy to remember ).
When you zoom in on the "Solder Side" picture you can see the copper traces that connect PL7-B to PL6-B and in-between those are traces that connect PL7-A to PL6-A

PL6/7 top left

Atom Board Bottom "Component Side".

PL6/7 top right

Atom Board Top "Solder Side".

An other thing is that according to the original Atom diagram Pin(B)1 of both connectors must be +5V.

A good help to find certain connections (pins and holes) on PL6/7 is the diagram below, print it if necessary and then fold it over the middle and place it next to the connectors.

PL6-7 Connectors - Horizontal.png (9.28 KiB) Viewed 2607 times

[KenLowe]

I don't think there really is a right answer here.

A good help to find certain connections (pins and holes) on PL6/7 is the diagram below, print it if necessary and then fold it over the middle and place it next to the connectors.

If I concentrate on PL7 for now, the problem with the arrangement you have shown is that when you come to design a board to plug into it, for the mating to work correctly the pinout for the male connector on the daughter board needs to be as follows (+5v on b32!):

Daughter board pinout if using ABBA convention for PL7 / PL6

On the other hand, if you rotate the PL7 connector around by 180 degrees, so it's BABA, then you end up with this much more sensible pinout for the male connector on the daughter board (+5v on a1):

Daughter board pinout if using BABA convention for PL7 / PL6

This is because we are using different families of straight through connectors for the male (DIN41612 Q) and female (DIN41612 B) parts. As highlighted by @hoglet in the PL6 / PL7 thread, the families use different pin outs and if trying to mate them, then you end up with this translation issue. See bullet at the bottom of the datasheet extract below:



I would be much more comfortable with rotating the female PL7 connector around 180 degrees, so that when designing a board that plugs into it, we would be using the much more conventional a1=5v, a32=GND instead of the b1=GND, b32=5v for the male connector. Much less prone to error!

Just my tuppence worth!

[PhilYoung]

Picture from KenThe Female PL7 socket is probably 180 degrees out of orientation [20230311_092818].jpg

That is how I soldered PL7 on my Atom (in 1981). So another vote for it being the 'correct' way. I think the only practical problem would be if someone had more than one Atom and at least one Atom had PL7 reversed with respect to the other(s). Which would make it difficult to swap daughter boards between them.

Cheers,

Phil Young

[KenLowe]

Picture from KenThe Female PL7 socket is probably 180 degrees out of orientation

That is how I soldered PL7 on my Atom (in 1981). So another vote for it being the 'correct' way. I think the only practical problem would be if someone had more than one Atom and at least one Atom had PL7 reversed with respect to the other(s). Which would make it difficult to swap daughter boards between them.

Ok, so just to be clear on this...

If the keyed PL7 connector is orientated as shown in the above photo then any daughter board that is going to attach to PL7, using a similar keyed connector of the opposite gender, needs to be designed such that the power and gnd are on the 'b' side of the daughterboard connector, as shown on a snip from one of my Kicad projects below (because of the different family pin outs that have been previously discussed):



This seems very counter intuitive, and for anyone designing a board to plug into this header, it is very likely to result in the connector footprint on the daughterboard PCB being 180 degrees out of orientation. This is exactly what's happened with my AtomVGA board.

Assuming someone does end up in this situation, like I have done, it's actually possible to work around this in a couple of different ways:

• firstly, by just rotating the daughterboard connector around by 180 degrees, but then the PCB mounting holes either side of the connector don't line up.
• secondly, by not using a keyed connector on the daughterboard and just using standard pin header instead (assuming you've got a socket in PL7).

...but I personally would rather not have to work around things! So I need to either accept that I got my design wrong for my daughterboard, and should have had the power / gnd signals on the 'b' side of the connector - with 5v on b32 and gnd on b1 (yuk!). Or, I rotate the header on the Atom so it faces the other way.

I think rotating the header is the correct thing to do. However, if that then makes my Atom different to what everyone else has, then that's clearly the wrong thing to do!

Hmmm ...

[PhilYoung]

Maybe the option of fitting a couple of rows of header pins is a more universal solution.

I think the only thing that could have been fitted at the time would be a system board, in which case the 90deg connector would have had to be replaced with a straight one in any case. Probably on the 'wrong' side of the system board to avoid the components clashing. In which case it would be soldered in to match whatever orientation PL7 was.

It's a pity the Atom Econet board didn't use PL7, that would have been an indication assuming they were supplied with a connector fitted.

Did Acorn ever supply PL7 factory fitted ?

Cheers,

Phil Young

[KenLowe]

Did Acorn ever supply PL7 factory fitted ?

viewtopic.php?p=337344#p337344

Which doesn't support my argument in the slightest!

[hoglet]

viewtopic.php?p=337344#p337344

Which doesn't support my argument in the slightest!

Here's another data point:

Chris Oddy has a riser card that will only work with PL7 oriented as you currently have:
https://theoddys.com/acorn/replica_boar ... _card.html

This then allows Eurocards with right-angle male connectors to be fitted internally.

Dave

[PhilYoung]

The Atom Technical Manual component layout shows the 'pin1' dot for PL7 at 'a1' with it in what seems to be the conventional (ABBA) orientation.

It's not on the board silk screen though.

Cheers,

Phil Young