UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   Ortonview PCB (https://www.vintage-radio.net/forum/showthread.php?t=181460)

Slothie 28th Jun 2021 12:27 pm

Ortonview PCB
 
1 Attachment(s)
Well since I've been working on this schematic to make an Ortonview PCB so that I can tinker with the firmware which still has a few minor niggles to work out, I thought I'd put the schematic up here in hopes someone will give it a look over and spot any mistakes/bad decisions/missing things that are likely to be in there. The board is intended to plug into the back of a "Issue VI" board using the signals put on the edge connector by the latest release. I have included the essential 1.5k memory hole filler (with optional battery back up) and an option random noise generator clocked from NADS that can be connected to a sense pin or SIN to make random numbers for all those games people are bound to start writing!

I'm going to try to start work on the actual PCB design next week.

SiriusHardware 28th Jun 2021 12:57 pm

Re: Ortonview PCB
 
Just had a quick look, in the short term it is also going to need pads for 4 x SM or through hole (or both) small value capacitors from A8-A11 to 0V as they are they are the essential 'dirty fix' to solve the problem where the system kept writing to address 'n' in one or more pages.

More ideally, add 2 x 74LS365 (6 x bidirectional buffers) in the VDU address bus (same as per the original VDU) so that the VDU address lines are cleanly disconnected from the MK14 address bus when the VDU is not trying to access it. You will remember that on Ortonview, the address line outputs from the VDU are just put into input mode but that does not properly disconnect them from the MK14 address bus and causes some loading on A8-A11.

It would obviously be much more of a chore to wire these buffers up on a veroboard build but if there is to be a PCB, then the two extra sockets and ICs would add no more than five extra minutes on the build. I would say this would be more directly necessary than a noise / random generator although I do like that idea.

Needless to say, you can count me in for one of these if they ever get to the point of being made. If you get to that point let us know how much you are going to want for them and - sorry to have to say this, but I suggest you don't put the design files in the public domain.

Slothie 28th Jun 2021 1:54 pm

Re: Ortonview PCB
 
The buffers are a good idea, I presume they will be enabled by the NENIN signal. The can always be replaced by wire links if not required. The PCB is intended to be an "experimental" board anyhow, so unpopulated parts are already a likelihood likewise I will put pads in for the capacitors - I remembered you and Tim trying them but couldn't recall if they ended up being neededd.
The Random Noise generator is really for my "Twonky" experiments for which the extra memory will also be useful....
I think I will probably keep the design files to myself for a bit at least.

Timbucus 28th Jun 2021 2:04 pm

Re: Ortonview PCB
 
Looking good - I like the way you have fully flexible jumpers for hand control of the options and also to hook up the RAM/IO controls if wanted.

One other idea might be to build in space for the recommended audio out / single step circuits from the manual (1 chip each) so there is an all in one expansion card to what was available at the time? These could be a small patch area that did not tie to specific chips - if space allowed... ?

I of course would also be very interested in one of these and probably sensible to control the making...

I will take a closer look at the circuit as well over the next day or so when time allows to see if I can spot any errors.

SiriusHardware 28th Jun 2021 2:33 pm

Re: Ortonview PCB
 
Quote:

I will put pads in for the capacitors - I remembered you and Tim trying them but couldn't recall if they ended up being needed.
As the firmware currently stands, yes, they really are needed and I am not personally convinced that that problem has a firmware solution since there is no way for the firmware to influence that problem - as the PIC ports used don't have a genuine hands-off (tristate) mode, and can only be input or output. That's why I suggest adopting the same solution as the original VDU - 'proper' tristate buffers in between the VDU 'address bus' and the actual address bus.

It might still be possible to play with the timing of the point at which the port pins switch from input to output, and, as has been pointed out before, the port pin directions can only be changed one port at a time, so maybe changing the order in which the A0-A7 port and A8-A11 port have their directions changed over could also make a difference.

Slothie 28th Jun 2021 3:36 pm

Re: Ortonview PCB
 
1 Attachment(s)
Well I've reworked it so the buffers and experimental capacitors can be added. It will make the layout more of a challenge, but thats part of the fun :-D:o:-D

Mark1960 28th Jun 2021 4:32 pm

Re: Ortonview PCB
 
I think you have the address lines to the RAM from the wrong side of the buffers. This would prevent access to the RAM from the SCMP.

Is the diode supply switching to the RAM something you have already tested? I have experimented with putting the switching in the ground connection using a bc108 to avoid voltage drop as this also disables write enable when main supply is off. I wasn’t convinced this was really working well. I think I prefer to use a MAX818 or similar to also disable chip enable, though it might not be simple to connect the reset output to the SCMP via the edge connector.

If you have space use a small slide switch for the write protect instead of just a two pin header.

I don’t think you want pin 18 and 21 on the ram connected.

SiriusHardware 28th Jun 2021 4:54 pm

Re: Ortonview PCB
 
If you can rework things that fast we'll expect the finished PCB design shall we say...

...Thursday?

I was slightly thrown by the way the A... and UA... lines appear to converge in the same single wire/bus but I guess that's just Kicad's way of doing things, as the sources and destinations of the two groups of signals are indicated at the device pins themselves.

Mark: Notice that there are two address buses, the 'UA... bus and the 'A'... bus. I don't think they are actually connected together although they look as though they are. The only lines passing through the buffers are the UA... lines from the PIC, the 'A' lines I'm guessing go straight between the RAM and the System A... lines. (See above paragraph).

SiriusHardware 28th Jun 2021 5:14 pm

Re: Ortonview PCB
 
The 'Top Page' output needs to be available on more than one pin header because it may occasionally need to be linked to more than just one of the page select inputs - for example it may also be linked to graph / chars to change from one mode to the other half way through the screen and maybe even also to 'swap pages' depending on whether you want the graphics half to be on the upper half rather than the lower half. So right there is an example where you might need to have three jumpers or links going to Top Page.

I would also provide for a modest value series resistor in the 'Top Page' signal output from the chip because with the amount of patchability available it would be quite possible for Top Page (an output) to end up connected to a page select input which is shorted to GND via a closed switch, or to end up in opposition to an 8154 port pin which is set to be an output. That's an especially expensive mistake to make on a real SOC VDU but you don't want to make it too easy for Tim to fry all of his 877s, either.

Slothie 28th Jun 2021 5:34 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1386155)
I think you have the address lines to the RAM from the wrong side of the buffers. This would prevent access to the RAM from the SCMP.

Is the diode supply switching to the RAM something you have already tested? I have experimented with putting the switching in the ground connection using a bc108 to avoid voltage drop as this also disables write enable when main supply is off. I wasn’t convinced this was really working well. I think I prefer to use a MAX818 or similar to also disable chip enable, though it might not be simple to connect the reset output to the SCMP via the edge connector.

If you have space use a small slide switch for the write protect instead of just a two pin header.

I don’t think you want pin 18 and 21 on the ram connected.

The annotations on the buses are correct, so the memory will connect to the unbuffered address bus, but your right in that the diagram is misleading. I will have to redraw the blue line connecting the memory to rest of the circuit to make this clearer. perhaps changing the labels from UAx to BAx would be more appropriate too.

I have tried using diodes to route power to chips but not this one specificaly. However the M5M5117 operates down to 4.5v so the ~0.2v schottky diode drop should not cause problems. If it does, I'll just remove the battery function and jumper the diodes.

Nice spot on pin 18/21, not sure how that happened.

Thanks for spotting these things, its exactly why I post this!
Ian

Mark1960 28th Jun 2021 8:13 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1386177)
The annotations on the buses are correct, so the memory will connect to the unbuffered address bus, but your right in that the diagram is misleading. I will have to redraw the blue line connecting the memory to rest of the circuit to make this clearer. perhaps changing the labels from UAx to BAx would be more appropriate too.

OK I see that now, I never did like showing a bus connection in a schematic with more than one type of signal in the bus. I saw you had a separate bus for data and just assumed you were following the same standard.

Quote:

Originally Posted by Slothie (Post 1386177)
I have tried using diodes to route power to chips but not this one specificaly. However the M5M5117 operates down to 4.5v so the ~0.2v schottky diode drop should not cause problems. If it does, I'll just remove the battery function and jumper the diodes.

One thing to watch out for is that the chip enable will be held low when 5v supply is off. Some ram chips will lock out the chip enable when their supply is below a threshold. I’m not sure if the M5M5117 does that. If it doesn’t then the chip is enabled on battery supply and can run the battery down a bit quicker than it should.

Slothie 28th Jun 2021 8:42 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1386205)
One thing to watch out for is that the chip enable will be held low when 5v supply is off. Some ram chips will lock out the chip enable when their supply is below a threshold. I’m not sure if the M5M5117 does that. If it doesn’t then the chip is enabled on battery supply and can run the battery down a bit quicker than it should.

Good point. Maybe I need to look at the enable logic, or put a pullup on /S so that when power is taken off U1 the chip is not enabled, although I'd have to check that won't cause problems if U1 is not powered. As I said, the battery backup was a kind of "nice to have".

Mark1960 28th Jun 2021 11:26 pm

Re: Ortonview PCB
 
I think parasitic diodes in the output of U1 would still pull the chip select down when 5v is turned off.

R1, R2 and R3 are also probably going to be draining the battery when 5v is off.

I think R1 and R3 could pull up to 5v instead of the battery supply.

You could power U1 from the battery supply and remove R2, but then you probably don’t want to use the spare gate as an inverter for the address buffer enable.

The 74hc02 might not work with address input levels from the SCMP, and might be better to use 74hct02. I wasn’t sure if you deliberately picked the hc or if that was just a package that was available. Then the 74hct02 probably shouldn’t be powered from the battery as it might not behave itself at battery supply voltages.

If you have 74hct4070 instead of the 4070, or 74hct86, you could use the spare gate as an inverter. I don’t think a cd4070 would be fast enough for the address buffer circuit. But this would mean the prbs generator is not completely separate from the rest of the board.

Slothie 29th Jun 2021 11:22 am

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1386266)
I think parasitic diodes in the output of U1 would still pull the chip select down when 5v is turned off.

I'm going to have to get a 74HCT02 and test it before pushing the button on the PCBs! In any case, this iteration of the PCB is meant to contain "experimental" features so I can see how it works in practice. But it won't be too hard to get a 74HCT02, not power it and measure the voltage on the output when it is pulled up via a resistor. This will also tell me how much current is being pulled through the resistor and if that is excessive and likely to cause problems for the IC or battery. I already have a couple of memory chips so I can wire those up to see the effect of R1,2,3 on battery consumption too.
Quote:

Originally Posted by Mark1960 (Post 1386266)
R1, R2 and R3 are also probably going to be draining the battery when 5v is off.

I think R1 and R3 could pull up to 5v instead of the battery supply.

They are deliberately large values, so this is mitigated somewhat. They are intended to pull up to whatever the Vcc pin of the memory chip is, whether it is from the PSU or battery.
Quote:

Originally Posted by Mark1960 (Post 1386266)

You could power U1 from the battery supply and remove R2, but then you probably don’t want to use the spare gate as an inverter for the address buffer enable.

The 74hc02 might not work with address input levels from the SCMP, and might be better to use 74hct02. I wasn’t sure if you deliberately picked the hc or if that was just a package that was available. Then the 74hct02 probably shouldn’t be powered from the battery as it might not behave itself at battery supply voltages.

The HC part was what came up tbh. I would probably use the HCT part in practice. I will amend the diagram appropriately.
Quote:

Originally Posted by Mark1960 (Post 1386266)
If you have 74hct4070 instead of the 4070, or 74hct86, you could use the spare gate as an inverter. I don’t think a cd4070 would be fast enough for the address buffer circuit. But this would mean the prbs generator is not completely separate from the rest of the board.

The address buffer uses the spare gate from the 74HC(T)02, which previously was inverting the TOP signal as I could no longer remember why I wanted to do this.

Slothie 29th Jun 2021 11:23 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1386172)
The 'Top Page' output needs to be available on more than one pin header because it may occasionally need to be linked to more than just one of the page select inputs - for example it may also be linked to graph / chars to change from one mode to the other half way through the screen and maybe even also to 'swap pages' depending on whether you want the graphics half to be on the upper half rather than the lower half. So right there is an example where you might need to have three jumpers or links going to Top Page.

I would also provide for a modest value series resistor in the 'Top Page' signal output from the chip because with the amount of patchability available it would be quite possible for Top Page (an output) to end up connected to a page select input which is shorted to GND via a closed switch, or to end up in opposition to an 8154 port pin which is set to be an output. That's an especially expensive mistake to make on a real SOC VDU but you don't want to make it too easy for Tim to fry all of his 877s, either.

Series resistors shouldn't be a problem, about 1k? Wouldn't like to deplete Tims supply any further :D

Timbucus 29th Jun 2021 12:20 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1386172)
an output. That's an especially expensive mistake to make on a real SOC VDU but you don't want to make it too easy for Tim to fry all of his 877s, either.

In my defense I have only fried 2 8154, 1 74L86 and two 877's before I learned my lesson :)

Slothie 29th Jun 2021 1:47 pm

Re: Ortonview PCB
 
RIP 8154's. Looks like the replacement project just got a bit more urgent :laugh1:

SiriusHardware 29th Jun 2021 3:11 pm

Re: Ortonview PCB
 
Seriously though, this is why adding these little safety catches - a 2p resistor (which might potentially save an old bit of silicon costing 100 times as much) is worthwhile. There is an ever decreasing supply of these expensive old devices out in the wild.

Maybe the pulldown switches on the page select and mode select inputs should also have low value series resistors in case 8154 outputs are ever accidentally connected to them when the switches are in the short-to-ground position.

Slothie 29th Jun 2021 6:20 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1386417)
Seriously though, this is why adding these little safety catches - a 2p resistor (which might potentially save an old bit of silicon costing 100 times as much) is worthwhile. There is an ever decreasing supply of these expensive old devices out in the wild.

Maybe the pulldown switches on the page select and mode select inputs should also have low value series resistors in case 8154 outputs are ever accidentally connected to them when the switches are in the short-to-ground position.

How low a resistance will protect the 8154? The data sheet I have for the 8154 doesn't specify a maximum output current, and I'd worry if the resistance was too high then the 8154 wouldn't be able to pull down the option pins enough to register as a '0' on the PIC.. Even a 500 ohm resistor would only limit current to 10mA but would require the 8154 to pull the pin down to less than ~0.5v.

SiriusHardware 29th Jun 2021 7:59 pm

Re: Ortonview PCB
 
Well, I was suggesting putting the resistors in series with the pulldown switches rather than in series with the 8154 port pins, so their only function is to stop 8154 pins which are in output mode (Or indeed Flag outputs, which Tim likes to use) being shorted directly to GND in the event that any pulldown switch gets moved to the closed position.

Obviously the ratio of the switch series resistors and the pullup resistors will have to be such that closing a switch still imposes a valid logic 0 level when there is nothing else (8154 output, Flag output) driving the line to 5V or 0V.

Don't worry too much about the actual values, just provide somewhere to insert them or insert links and we will experiment for best value.

Mark1960 29th Jun 2021 11: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 8: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 8: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...

(...rummage...)

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 9: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 9: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 9: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 10: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 11: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 7th Jul 2021 12:45 am

Re: Ortonview PCB
 
Quote:

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 6:08 pm

Re: Ortonview PCB
 
Just remembered this:

Quote:

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 6: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 7: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 8: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 9: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 9: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 11: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 11: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 11: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 8th Jul 2021 12:03 am

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 11:51 am

Re: Ortonview PCB
 
Quote:

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.

Slothie 8th Jul 2021 11:59 am

Re: Ortonview PCB
 
This is starting to sound like a "V2" thing... You could free up pins on the PIC by using a multiplexer or shift register to sample the option pins during retrace. It does rather damage the "single chip" concept though (not that its at important!)
The vertical bar thing will be important in the long run, it appears Tim has avoided it by adjusting the overscan on the TV, but an LCD TV might not have this luxury. For now I'm content just to pretend its not there for the time being until we can sort out the firmware. Until then we'll supply Sirius with a strip of black paper and some sellotape!

SiriusHardware 8th Jul 2021 12:26 pm

Re: Ortonview PCB
 
Quote:

It does rather damage the "single chip" concept
I think that was quite a big deal, almost a non-negotiable point of honour for Karen, to be able to make her beloved PICs do so much that virtually nothing else was required. The buffers are an unfortunate after-necessity (possibly, I know you still harbour hopes that the problem can be coded around) because not even Karen could have anticipated the problem of the PIC port pins 'leaning' on the high address bits when in input mode - I think the buffers are an acceptable after-modification to this project because they are exactly how the SOC VDU handled its connection to / disconnection from the address bus. If the PIC pins could just be put into 'tristate' (high impedance) state that would be the first thing to try in firmware, but I don't think they can.

The 'dirty fix' (200pF capacitors from A8-A11 to 0V) works perfectly for me and has no known side effects, and actually Karen did have form there, early on she suggested 'slugging' (her term) some of the signal lines with capacitors to see if they solved issues and she may well have preferred that minimalist cure rather than using extra ICs to solve the problem more elegantly / correctly.

Same with the bright line blanking, if we can find a pin which can be used in output mode, you can probably just add a couple of resistors and a transistor to do the video line clamping during the 'bright line' period.

Regarding the 'hardware' solution to the problem, why use two items when you can do it with one? Black electrician's tape....

Timbucus 9th Jul 2021 1:17 am

Re: Ortonview PCB
 
Indeed I think she would have been impressed with this as well https://hackaday.com/2021/07/08/c64-demo-no-c64 no bright white line on the left of that!

Slothie 9th Jul 2021 10:04 am

Re: Ortonview PCB
 
So are you saying we should just forgo the PIC and connect the video to the SC/MPs F0 & F1?

Slothie 9th Jul 2021 1:05 pm

Re: Ortonview PCB
 
1 Attachment(s)
Well I've done some tidying up and played with FreeCAD to make some models for the missing components and a a pic of the (hopefully) final board. The models are a bit Dire Straits "Money for Nothing"-esque but I'm no Leonardo with CAD and FreeCAD is a bit quirky....

Here's a link to the non-mangled-by-the-forum version -> ******************************an2Yk6deezBT6gc59

Timbucus 9th Jul 2021 5:23 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1388686)
So are you saying we should just forgo the PIC and connect the video to the SC/MPs F0 & F1?

Well I did wonder if overclocked as we have been informed it can be, if it could be made to display something... Cool project idea

Mark1960 9th Jul 2021 6:38 pm

Re: Ortonview PCB
 
I was looking at that possibility but I think the 8060 is too slow even at 8MHz. Each microcycle is 1us at 4MHz. Fastest instruction is 5 microcycles, so that would be 5us per pixel at 4MHz or 2.5us at 8MHz.

It might just be possible to drive an external character generator, similar to zx80, drive nop to the 8060 while the data goes to the character generator, but would still be very large pixels, maybe 16 characters by 8 lines.

Slothie 9th Jul 2021 8:39 pm

Re: Ortonview PCB
 
Well, I've done it. 5 PCBs on the way to try out!

Timbucus 9th Jul 2021 9:15 pm

Re: Ortonview PCB
 
Nice - I shall look forward to your first photo of it working...

SiriusHardware 10th Jul 2021 11:40 pm

Re: Ortonview PCB
 
Obviously, we will want to help to offset the cost of the five test PCBs so please let us know details via PM.


All times are GMT +1. The time now is 10:03 am.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.