Driving the PET CRT display directly

[timleach]

Hello, as described in this thread, I'm currently trying to revive a lovely PET 4016.

I'm currently waiting on some help from some people, but in the meantime, I was wondering if it was possible to test out the CRT before getting the main computer working?

I have a couple of Raspberry Pis, and the schematics are quite clear about what the driving signals need to be:

...so I wanted to know if there was any danger of me permanently damaging the display by literally connecting my Pi directly to the wires coming out of the CRT, and attempting to send it the right HBLANK and VBLANK signals, and some data in between?

I am aware that the Pi isn't ideal for exact timing of this short timescale, but I'm exploring some options for getting around that - my only question is, is it possible for me to accidentally break the CRT by sending 5V signals to it, or am I safe to send whatever signals I like as long as they're within that range?

Thanks!

 

[Hugo Holden]

The main pulse to worry about is the Hor.drive pulse, because it determines the amount of EHT generated and the dissipation of the H output transistor and the transistor's peak collector current & H scan amplitude, so if this pulse is too far off in either its frequency or duty cycle, you can damage the VDU. So make sure you have checked this pulse out with the scope to make sure it is close to what is required before you apply it.

 

[daver2]

The three signals are +5V TTL compatible.

Isn't the Pi a +3.3V device? If so, you may need voltage converter buffers between the two.

As Hugo says, the key signal to get right is HDRIVE.

Make sure the Pi generates the correct signals on the bench with an oscilloscope first. Then attempt to connect it to the PET monitor.

Ensure that there is no VIDEO drive (black level) during the blanking and synchronising signals.

Dave

 

[Hugo Holden]

As @daver2 mentioned, it is best to not to illuminate the CRT beam during horizontal and vertical blanking (Retrace). Usually this is done at the logic gate level by making sure the video signal voltage is black during the H and V retrace (blanking) intervals.

If you look at the signals that drive the VDU, the Vertical drive signal as it is can be used as a vertical blanking signal because it corresponds to vertical retrace.

However, the Horizontal drive signal does not correspond to H retrace (H flyback) the H flyback starts when that drive signal falls low and is a pulse about 10uS wide. So if you are going to blank the video properly you will have to set up a pulse (or timing interval) like this, as well as the H drive signal.

 

[johnq]

@timleach This sounds like a interesting idea. Did you ever get anywhere with this?

 

[timleach]

I spent a good few hours on it, but try as I might, I couldn't get it working by driving the screen directly from the pi.

However, my PET model is one with a CRT controller chip, so once I've got the PET itself working again, I may try to drive that chip directly from the pi instead, and see if that works!

 

[timleach]

Hello everyone, I'm back after an extended period trying to get this working again.

First things first, I'm worried I have been a bit slapdash with my testing, as I haven't yet been able to replicate my findings in the other thread.
(Also, truth be told, I was feeling very out of my depth, getting frustrated not making much progress, and I ran out of steam a bit.)

I've ordered myself some components and I'm going to build a riser for the 6502 to make it easier to connect the oscilloscope to it - it was extremely difficult to read the 6502's pins with multiple handheld probes, and I'm quite worried I accidentally shorted the pins while doing it (contributing to my anxiety about bricking the poor thing).

I'm going to revive that thread once I've built myself the hardware, but in the meantime, I'm working on this again as a side-project.



The Pico is capable of direct control of its pins at up to a theoretical maximum of 62.5MHz, I believe, so I'm using it to generate a signal to put straight into the PET's CRT input. See the image above - I've got that little 7-pin header (minus 6) that plugs straight in, plus some extra wires to connect the oscilloscope.




Above we see, in order:

1. Video out (yellow)
2. Vertical drive (cyan)
3. Horizontal drive (magenta)

Now, there are a couple of problems with this output that I'm aware of:

• As @daver2 pointed out earlier, the pico is a 3.3V device, so all of these signals are only 3.3V. I have some transistors arriving tomorrow to build a rough-and-ready voltage converter to fix that.
• The video output and hdrive signals continue through the vdrive blanking interval, which I understand can be dangerous for the display. I'm going to modify the code to make sure that doesn't happen (or, failing that, I'll just use an AND gate or two).
• The signal looks really noisy on the scope - that might just be interference since the wires are quite long, but is there anything else I ought to be aware of that could be causing this?

But for now, I wanted to confirm a few things with the experts!

Firstly, is the video input active high or active low? The pin is labeled /VIDEO in the schematics, which implies active low:

...but the page indicating the input voltages seems to imply the opposite:

Which way round is it supposed to be?
This discrepancy is also making me worry about the hdrive and vdrive signals, which are also shown as active high:

and I'd really like to make sure I know which way round it's all supposed to be.

Finally, I'd like to know how much flex there is in the timings of these signals - how exact are the indications of the periods in the above diagram? And how are they supposed to line up with each other - must they both go active at the same time, or can there be a bit of a gap like in my first oscilloscope screenshot above?

Thanks for all your help and I'll update you all as I get closer to the goal!

 

[Hugo Holden]

On the video signal polarity it was swapped between different models of VDU, you need to check you have the correct schematic. If you look at the video circuit in the VDU, at the transistor stages and signal inversions, its easy to work out anyway, because when the CRT cathode goes positive the CRT beam goes toward black, when negative the CRT is illuminated.

The horizontal and vertical retrace blanking issue is nothing that is bad for the VDU & CRT. It is just that if you don't have the video pulses corresponding to black during Vertical retrace time, you will have multiple diagonal slanted lines on the scan (retrace lines) and with no H blanking there can be interesting effects during H retrace.

As noted before, the only potential for major damage is an incorrect H drive signal and I think the polarity of that should be double checked because it was also different on different model VDU's as they had a different number of driver transistors leading to the H output transistor. Just make sure you have the correct schematic for your VDU.In any case with that signal, the shorter section of the wave corresponds to when the H output transistor should be switched off, the longer section is when it should be switched on and that is the same for any VDU.

Perhaps one other point, if the vertical drive pulse goes awol, the vertical scan collapses and you end up with a persistent extremely bright horizontal line. There can be enough energy to burn the CRT phoshophor so run the brightness low and if that happens turn the brightness way down to protect the phosphor.

 

[timleach]

Just make sure you have the correct schematic for your VDU.

I know for a fact that I have the CBM Model 4016, but is there any variation within that model that I need to be extra careful to look out for?
I'm working off the schematics found here, which says it's for the 4016 and 4032, but that file seems to contain three different circuit diagrams and two different diagrams for the video circuit (although as discovered on a previous thread, my machine is one of the ones that has a CRTC, so does that narrow it down to the first of the diagrams?)

 

[Hugo Holden]

I know for a fact that I have the CBM Model 4016, but is there any variation within that model that I need to be extra careful to look out for?
I'm working off the schematics found here, which says it's for the 4016 and 4032, but that file seems to contain three different circuit diagrams and two different diagrams for the video circuit (although as discovered on a previous thread, my machine is one of the ones that has a CRTC, so does that narrow it down to the first of the diagrams?)

I think the PET computers and their VDU's must have more variations than Professor Klump's random nucleotide polymorphisms.

 

[timleach]

No dice. I double-checked the schematics, double-checked my signal output, turned everything on - and nothing so much as a flash or a flicker on the screen.

I'm quite concerned that I must have provided an incorrect HDRIVE at an earlier stage last year, because at one point when I was experimenting (but not being as careful) I did get the dot to appear very briefly and only a couple of times, not reliably at all. At one stage it "collapsed into a line" as you said, but I couldn't figure out what I was doing to cause that to happen... and now I can't get it to happen again.

This is such a shame! What I may do is attempt to measure the voltages at the "test points" shown on the schematic, to see which ones are the same and which are different, but I'd be at a loss for what to do if I find something wrong.

In the unfortunate event that I have provided an incorrect HDRIVE and fried something, are there any options for fixing it (e.g. replacing a burnt-out capacitor), or is it a situation where they don't make the part I'd need anymore?

 

[timleach]

I opened the back of the CRT for the first time (I didn't know you could do that!) and I don't see anything obviously broken or fried. This seems to give me better access to the test points, but honestly I'm reluctant to start trying to fiddle around with the scope probes without even being certain I'm feeding it the right signal.

I think what I'm going to do is shelve this sub-project for now until I've learnt more about why the rest of the PET isn't working. Once I've got the hardware outputting something to the CRTC, it'll be much easier to start diagnosing problems in the video display since I'll know the inputs are exactly correct!

 

[daver2]

Sounds like a plan to me.

Most of the faults with a PET monitor are repairable. Most of the components (or their equivalents) are easily available. The only two that are not are the line output transformer and the CRT itself. In general (whilst these get the bad press) they rarely go wrong if they have been working and you haven't 'bounced' the monitor or hit it with a hammer!

Dave

 

[timleach]

Oh phew, what a relief! I'll kick that particular can down the road for now, then.

In case anyone who finds this thread in the meantime would like my Pico code to generate the output, I have uploaded it as a GitHub gist here - but please note it is a work-in-progress, and will definitely need tweaking before it's fit for general purpose!

If you do try this on a real PET, please let me know so I can verify it should be working on mine!