Ortonview PCB

[SiriusHardware]

...Nope. That wasn't it.

The same RAMs do and don't work to the same degree when there is plenty of headroom on the input voltage to the regulator.

[Mark1960]

If you have a diode in the supply to the ram you could try linking it out. It might also be worth putting a decoupling cap directly across the ram pins 24 and 12, the traces from the decoupling cap to the ram look a bit long and thin.

[SiriusHardware]

I believe I mentioned earlier that I don't have a diode in the supply to the RAM, it is fed directly from +5V. Interestingly though, Tim does (or did) have a diode in his +5V supply to the RAM and it seems that on his first attempt his board was working really well in vanilla mode - no buffers, and even with the buffers (with the delay enable mod in place) as long as he still had the caps on A8-A11.

Ref: Supply traces, this was another line of attack I was considering, thickening the supply traces and running them more directly from point to point, but even that would involve cutting the original supply traces to avoid any potential problems caused by the currents going via two paths, one long and one short.

I agree a cap directly on the RAM supply pins would be simpler and faster to try first. I have already populated all of the positions for supply decoupling caps but as you say, none of them are particularly 'close' to the RAM in the electrical sense. The fact that fitting an electrolytic to the rails brought one borderline RAM into the 'fully working' zone does suggest that maybe more can be done in this area.

[Timbucus]

I run mine on a 9V so you could be on to something. ****** didn't refresh the screen so posted without seeing the posts after the pub - ignore me.

[Mark1960]

I don’t think you need to cut traces, multiple paths for supply and ground shouldn’t make any big difference.

[SiriusHardware]

One other thing I've just noticed about my original build is that I have a 0.1uF across the +5V supply very close to the video output transistor. The video input of my Philips monitor has a (measurable) 75R termination resistor from input to GND so the video transistor will be supplying significant current from 5V.

I may try a close mounted decoupling cap on the video output stage supply on the PCB version as well.

[Slothie]

I must confess decoupling was a bit of a last-minute affair so I might have missed something. A cap near the output transistor makes sense.

[SiriusHardware]

I appear to have zero 0.1uF disc ceramics here - typical - but I know I have a component drawer full at work so I'll take the PCB in tomorrow and fit decoupling capacitors directly on the pins of the RAM and the video output stage supply rails.

I might also route the latter more directly back to the +5V / 0V connections at the edge connector so that the fast switching currents for the video output stage aren't travelling out and back down the same tracks as the supply to the ICs.

I don't think the decoupling caps for the PIC and the 74HC02 could be placed any better than they already are, both are sited very close to their respective ICs with short track runs to the supply pins.

[SiriusHardware]

I tried one last thing - with the monitor connected the output load being driven by the video output stage is 75R (=the resistance of the video input of the monitor) and the 1K emitter resistor in parallel.

If the theory is that the switching currents being drawn by the video output stage are the cause of the problem, then I could have a go to prove this by unplugging the monitor and putting one of the 'bad' RAM ICs in - I don't need to see what's on the output of the VDU to know whether the machine is working, because the MK14 display goes haywire if it is not.

So I tried that, fitted one of the less stable RAMs and unplugged the video output cable so that the load being driven by the video output transistor was a respectable 1K instead of something less than 75R.

Unfortunately, no difference. System is haywire with and without the 75R load of the monitor input connected. I think I'll call it a night and have another go tomorrow with the extra decoupling caps fitted.

[Mark1960]

I now have an ortonview running with firmware #352, random characters on the tv and the mk14 display is not correct due to the longer delays in #352. All as expected on reading the original mk14 vdu thread. I get a white bar about half character wide down the left edge of the tv, probably picture adjustment but I’m going to ignore that for now and switch to firmware #692.

I didn’t fit the extra extra ram yet, so I may add the 8154 and try Slothie’s ram test from there.

[SiriusHardware]

We didn't persevere for long with #352 because of the really heavy system slowdown it caused - going back though the old thread it held NENIN high for a very high percentage of the time, even more so than the SOC VDU.

Fortunately, Karen to the rescue, she found a way to keep NENIN active for a far smaller percentage of the time, hence the 'fast' versions we have now, culminating in #692.

The white bar, LHS, is a by product of the UART being used to generate the video bit stream - when first enabled at the beginning of each line it unavoidably generates a 'bit of white' until such time as the output can be turned black again under software control.

At the moment I just adjust the width / height and horizontal position of the image on my CRT video monitor so the bright line is just off the LH edge of the screen. If you were using a typically auto-adjusting flatscreen TV, that would probably insist on including the bright line onscreen since it is part of the video image.

While I would eventually like to see the bright line suppressed, we have more fundamental problems to solve first.

[Slothie]

As Sirius pointed out. Black Electrical Tape will cure the white bar for now

I've been distracted for the last couple of days by the arrival of a 3D printer.... Normal service will be resumed when I run out of filament, which will not be long.

I think that my next step might mean I'm going to hook up my logic analyser to the chip enables of the Fxx RAMs to see if the problem is there and what difference the running of the Ortonview makes to it. At the moment what I am seeing with my admittedly primative equipment does not make sense, and that's not good for reaching a diagnosis.

I'll try to document my experiments so that (a) I can remember exactly what I did and (b) I can share my ruminations with the rest of you.

[Mark1960]

Switched to #692, I think, using the hex file from Slothie’s dropbox to save time installing mplab and compiling.

I still see F09 and F11 rotating as expected with the mk14 monitor running, but for a minute or two after power on and reset The content of B20-B3F, B60-B7F, BA0-BBF and BE0-BFF are going wild. This then stops for a while and then returns again after another 5 minutes.

I just went back and tried again with reset pressed, now I only see the changes in Bxx when reset is pressed, and only in the last 4 characters of each range, so for some reason its no longer as bad as it was 30 minutes ago when its been powered off.

Tried triggering off NWDS with reset pressed, at 500MSa I see a few ripples but nothing less than 4v.

I think this is similar to what Sirius saw with extra extra ram.

I’ll take another look later, I need to work for a while.

[SiriusHardware]

When you come back could you just state whether you are running in 'vanilla' (original Ortonview circuit mode minus buffers) or buffered mode (buffers fitted).

If you have the buffers fitted do you also have your / Slothie's buffer enable RC delay fitted?

If you don't have the buffers fitted and you instead have them bypassed, do you have the 4x capacitors on A8-A11 to 0V?

[Mark1960]

Original ortonview mode, no buffers, and no capacitors yet, but the parts of Bxx changing do not correlate with writes to Fxx, so not just A8-A11 involved.

I need to make sure Bxx is being written with bad data and not just being read incorrectly by the pic.

[Mark1960]

Typical, I just tried again and now the display of Bxx is not changing anymore.

I took a look at NENIN and A11 or NWDS. I really need to find a third probe for trigger as I can’t tell if A11 is during read or write. What I can see is a wide variation between rise of NENIN and rise of A11 or NWDS, anything between about 150ns and 400ns, so suspect the effect of NENIN on A11 or NWDS is synchronous to the 8060 clock. They also seem to have a faster rise time if they rise earlier after NENIN rises, as if being driven high, compared to looking like they only float high if they rise later.

[Mark1960]

Adding a couple of scope plots.

Yellow is NENIN on both.

Purple is A11 on the first and NWDS on the second.

Using persistence to show a range of response with different timing.

[SiriusHardware]

A bit late to the party tonight so I didn't get as much time to experiment as I would have liked. I dropped a 4mm long black M2 screw on the carpet here and it took me most of the night to find it. But find it I did.

So: Today, I fitted 0.1uF caps across the supply to the video output stage and the 6116 RAM socket. My 'good' EL6116LP-10 still works solidly, no surprise, but now the other four EL6116LP-10s appear to work solidly as well - I can leave the machine running with OrVw displaying 0200-03FF with any of those ICs in and I don't seem to be seeing any pixels changing by themselves, which was the case before with four out of five of those ICs.

Against this, there is the fact that my two Hitachi HM6116LP-3s still cause heavy disturbance to the system but the disturbance, while it still makes the system go nuts, seems less aggressive.

So now I'll take it back to work again tomorrow and this time I will fit 0.47uFs or 1uFs in those positions. In fact I may populate all of the positions provided with 0.47s, if I can find any, rather than the 0.1uFs currently fitted.

Following this observation I would suggest that everyone else beefs up the decoupling for the 6116 and the video output circuit as well. If taking mine up to higher values still doesn't fix it for the worst case RAMs I am going to start thickening and rerouting the 5V and 0V rails.

[Mark1960]

I wonder if the reason Tim didn’t have a problem with the extra extra ram was because he did have the diode fitted in the supply and the combination of the diode and the decoupling cap gives a better supply to the ram.

Maybe this is linked to the problem I had with the display of Bxx.

[SiriusHardware]

Yes, I visualised it as the 'one way valve' action of Tim's diode helping to maintain a 'reservoir' of power to the RAM in the RAM's decoupling capacitor.