UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (
-   Vintage Computers (
-   -   Ortonview PCB (

Mark1960 29th Jun 2021 10:00 pm

Re: Ortonview PCB
The pull up resistors could probably be increased to 100k as they are only used for a static signal level and don’t need to worry about input capacitance. 47k is probably a good choice, with 4k7 in series with each switch. Then the switches could pull the inputs down to 0.5 v.

There could still be an issue if the PIC is programmed incorrectly and the pins driven as outputs. 1k or 2k series resistors might work but I’m not sure if that would be high enough to protect the 8154.

Slothie 6th Jul 2021 7:05 pm

Re: Ortonview PCB
1 Attachment(s)
Well I've had some progress, still got to try and route the address lines through the buffers which is causing a few layout issues, may result in having to move things about but its getting there....

SiriusHardware 6th Jul 2021 7:53 pm

Re: Ortonview PCB
Woo! Coming along nicely.

It looks quite shallow (front to back) compared to the depth of the original VDU, so if you need more room for buffers etc I think you can allow yourself to extend it back to at least the length of the original VDU card. I'm forgetting you don't have one so...


The front to back depth of an original SOC VDU, front edge to rear edge excluding any projecting connectors, is 16cm exactly. The width of an original SOC VDU is 10cm exactly, but as this board is more likely to be used with an issue VI than any other I think it would look nicest if it was exactly the same width as the issue VI.

I like the fact that the MK14 facing connector is a 0.1" edge connector type as you can solder the pins of either a 32+32 -way edge connector or a 32+32 way DIN connector to those, or you can even use an original 32+32 way edge to edge joiner if such a thing can be found.

Personally, I'd like to see the composite video going out on a PCB-mounted RCA socket.

I never got around to trying to run the OV with its own independent regulator - don't know if Tim did. Running the OV on the MK14 regulated 5V supply does at least have the merit that both units see their supply 'appear' at exactly the same time.

That said, the MK14 and the OrtonView PIC each have their own independent reset circuits so they almost certainly start up at different times even when running from the same supply.

Timbucus 6th Jul 2021 8:26 pm

Re: Ortonview PCB
It is looking nice - being slightly shorter is great as desk space is always an issue - a PCB mounted Video RCA socket is a great idea I think. But I suspect another IC width will not harm.

I never did run it on a different 5V reg it seems to work fine with the onboard one even with my homebuilt external OR commercial onboard expansion RAM... I will not need that with this...

Slothie 6th Jul 2021 8:46 pm

Re: Ortonview PCB
1 Attachment(s)
I did the edge connector pads that way for exactly that reason - it seemed to offer the most flexibility. In my case I will solder a dual-row 0.1" header pin strip edge-on to connect to the socket I soldered to my Issue VI. But you could equally do the same for a DIN style connector or an edge connector with a little massaging of the pins.

The video does have a PCB mounting RCA jack, I just haven't got round to making the 3D model for it and its a bit hard to see in the photo! Its the kind in the photo I got from eBay, but I think Farnell and others stock something with the same footprint.

If you want to run it off of the MK14's power, then I can put in a pad connected to the +5v on the edge connector, and you can wire that to the output of the non-populated regulator. This board is intended to be for experimental purposes, hence the place to put address caps or pin headers for logic probes, there are holes for the data bus too (a bit hidden in the photo) and you could always omit the buffers and link the connections over if required. The "noise" generator is entirey optional and only there because I want it for my experiments and while I'm making a PCB I can use a bit of the spare space!

SiriusHardware 6th Jul 2021 8:48 pm

Re: Ortonview PCB
Actually, looking at it properly I think Ian has provided pads for a PCB mount RCA socket but the socket itself is not 'fitted' in the illustration.

Edit: crossed with Ian.

Slothie 6th Jul 2021 9:10 pm

Re: Ortonview PCB
I think I'm OK for space, the buffer chips are on the board, they're just not connected up. I'm probably going to have to swap about which buffer is on which address line to simplify the routing, because at the moment the rats-nest lines are crossing over like a spiders web! All part of the fun, but I think I will leave it for tomorrow now when I have a clearer head....

Mark1960 6th Jul 2021 10:36 pm

Re: Ortonview PCB
The pinout of the 74ls365 sometimes works better when rotated 90 degrees. That would also avoid having the inputs to one buffer threaded through the pins of the other, depending on which direction the input and outputs are coming from.

Did you try prototyping the buffers to check if it fixes the ram corruption?

Slothie 6th Jul 2021 11:45 pm

Re: Ortonview PCB

Originally Posted by Mark1960 (Post 1388180)
The pinout of the 74ls365 sometimes works better when rotated 90 degrees. That would also avoid having the inputs to one buffer threaded through the pins of the other, depending on which direction the input and outputs are coming from.

Did you try prototyping the buffers to check if it fixes the ram corruption?

No, the reason I'm making a board is my attempts at making prototypes on breadboard and matrix board have just been a hassle. I spent a long time at the beginning of the year with a number of attempts to make a breadboard or protoboard version to allow testing various scenarios to little avail (my eyesight isn't great for fiddling with tiny wires). I had a few health problems in March so the project got shelved, but I've picked it up again. If the buffers don't work or make it worse I'll just remove them and jumper the pads of the buffer. I also want a card that I can attach a logic analyser reliably to while I experiment with the firmware, because I'm pretty sure that Karen got it 99% there and it should be a matter of identifying a timing problem or some quality-of-signal issue somewhere causing unintended memory accesses, all of which will be made easier to diagnose if I'm not battling with loose wires or dodgy test connections! I still think that there may be some obscure bug in the firmware but you can only do so much without being able to do some real tests on reliable hardware!

SiriusHardware 7th Jul 2021 5:08 pm

Re: Ortonview PCB
Just remembered this:


The pull up resistors could probably be increased to 100k as they are only used for a static signal level and donít need to worry about input capacitance
Actually, in typical usage they are not necessarily completely static - for example, one of the four Page Sel inputs is usually connected to TOP PAGE so that the VDU shows the content of two different 256-byte blocks of memory. In addition to this, TOP PAGE can also be connected to the graph / char input, the swap pages input and the inverse video input so that all of those parameters are switched over when the TV scan is half way down the screen.

Mark1960 7th Jul 2021 5:19 pm

Re: Ortonview PCB
I think in those cases the inputs would be driven from the 8154 or some other source, so the pull up resistor is no longer needed. The pull up resistors just make sure the inputs are not floating if disconnected from any other source and the switch is open circuit.

Slothie 7th Jul 2021 6:21 pm

Re: Ortonview PCB
Technically the P4 input is only an input during the vertical retrace period, while pixels are being output P4 becomes the pixel clock output (an unavoidable side effect of using the serial device to output the pixels) hence the decoupling resistor. I would be unwilling at this point to mess with the P4 input.

SiriusHardware 7th Jul 2021 7:32 pm

Re: Ortonview PCB
2 Attachment(s)
I've just thought of another refinement which would be onerous to include on a Veroboard build, but trivial if provided for on a PCB.

One of the few acknowledged drawbacks of OrtonView is that, due to the way the UART is used to generate the video bitstream, there is a thin bright vertical line at the left hand side of the image.

I would therefore propose the addition of a monostable which is triggered from the falling edge of the line sync pulse - the time period to extend to just after the vertical bright line, and the output (via a transistor?) used to hold the video signal at black level until just after the bright line.

If there were any spare pins available on the PIC then one extra port pin + transistor could be used to hold the video output at black level just during the period where the UART output is initially switched on and then released for the rest of the video line.

One way to make this happen would be to use the 44-pin PLCC or flat-pack versions of the 877, as they have several more port pins available. However this would be counter to Karen's stated preference for using DIP parts to make the project easy to hand build.

For some reason Tim never really experienced or was bothered by the left hand vertical bright line, but it is definitely there. It's the leftmost spike on the single video line capture in the first image below. The second image is OrtonView in graphics mode with the screen memory filled with a binary pattern. The bright line is very visible at the left hand side.

On a CRT TV or monitor you can just muck about with the width and picture offset so that the bright line is just off screen out of sight on the left, but on an LCD TV the auto-adjust / auto size feature will no doubt be very pleased with itself for managing to get everything, including the unwanted bright line, on the screen no matter what you do to stop it.

SiriusHardware 7th Jul 2021 8:22 pm

Re: Ortonview PCB
A further thought on this: Tim, when OV is in inverse video mode, is it only the 'active' area which has the white background, surrounded by an all round black border extending to the edges of the screen, or....

Does the white background include the whole of the screen border area? My OV is stored just now so I can't easily answer the question for myself. If it's the latter then any bright line fix would have to 'know' whether the VDU was working in normal or inverse mode, and it would need that information separately for the upper and lower screen halves.

If the PIC was handling this action via a hypothetical extra port pin then it would just allow the bright line (which would blend into the white background in inverse mode) and only blank it in 'normal' (black background) mode.

Timbucus 7th Jul 2021 8:50 pm

Re: Ortonview PCB
Yes it is white all over - that can be seen in the tanks demo which was not very visible as it plays in inverse mode. I think I was just lucky that my Philips CRT has it offscreen - I will set up my MK14 and OV on my new Capture card if I get chance as I am sure that will show the artifact.

I know Karen was battling for Pins so not sure how we will be able to do the signalling - in other designs she has multiplexed some lines. RC0 the VDUOFF line seems like it might be crying out for that use - I am sure the other limitation that those and the PS lines are only sampled at frame start and maybe halfway could be utilized somehow?

SiriusHardware 7th Jul 2021 10:02 pm

Re: Ortonview PCB
Did anyone ever get anywhere with commenting Karen's source? When she posted the first version I started to go through commenting it line by line.

Then along came the major change to the less NENIN-heavy version which improved things so much that it actually slowed the host down less than a real SOC VDU - I felt that in order to understand that fully I would have to start all over again, but so far never did.

Slothie 7th Jul 2021 10:27 pm

Re: Ortonview PCB
You could use a 74121 style monostable triggered from the negative edge of the sync on pin 24 (RC5) and an AND gate from the ~Q output and the pixel output on pin 26 (RC7) so that when the monostable is triggered the video is a 'black' level, without requiring any extra pins on the PIC. Such a kludge would be easy to test out with a stripboard "daughter board". I was going to add a prototyping area on the PCB but I wanted to keep the size of the board down to take advantage of low cost PCB processing. Perhaps I should have placed it where my PRNG is :)
I've finished the layout now, I'm going to put it aside for a day and take a look at it again at the weekend, I find that letting things sit for a while makes it easier to spot mistakes before you send them off...

Mark1960 7th Jul 2021 10:47 pm

Re: Ortonview PCB
Is the white band caused by initialising the serial output as output before any data is output?

I was wondering if adding a ‘74 register to the output, clocked by the serial clock output, would work instead of a monostable? Maybe with the ‘74 also cleared by the sync output.

SiriusHardware 7th Jul 2021 11:03 pm

Re: Ortonview PCB
The white band is an unavoidable by-product from when the UART wakes up, it happens to produce white level at that point and it takes a finite amount of time to then turn the state of the output to the other (black) level under program control.

It always happens at exactly the same interval after the sync pulse so triggering a monostable from the sync pulse and using its output to gate the pixel data off until just after the UART initialises will fix this for 'normal' (white on black) video, but from what Tim said we'd also have to deal with the case where the background is intentionally white, ie, inverse video mode. If we just apply the solution which works for normal video, in inverse mode the whole first quarter of the screen left of the active area will be black and the upper, lower and right hand borders will be white, which would not be correct.

Throw into the mix the fact that the upper and lower halves of the screen can be one inverse, one not, and it's increasingly likely that the drive signal for the video signal gate will have to be generated by the PIC

Slothie 8th Jul 2021 10:51 am

Re: Ortonview PCB

Originally Posted by SiriusHardware (Post 1388429)
Throw into the mix the fact that the upper and lower halves of the screen can be one inverse, one not, and it's increasingly likely that the drive signal for the video signal gate will have to be generated by the PIC

Yes, I was thinking that we could use the inverse signal on the option connector, but that is sampled during vertical retrace (twice, with TOP in both states) so we cant rely on the value of the INV pin while the actual pixel data is being displayed.

All times are GMT. The time now is 9:57 am.

Powered by vBulletin®
Copyright ©2000 - 2022, vBulletin Solutions, Inc.
Copyright ©2002 - 2021, Paul Stenning.