Ortonview PCB

[Timbucus]

Yes I had thought about exchanging boards as a solution but, I have a DIN on mine. Anyway I will put some RAM's in the post tomorrow that I know work my end.

[SiriusHardware]

Thanks Tim, happy to send them back once they have proved things one way or the other. I suppose the other thing I can try is to program one of my Spare 877s to see if that makes a difference.

[Slothie]

It might be worth checking the continuity of the A10 line from the edge connector to the buffers. I was assuming I damaged mine removing the capacitor, but its possible theres a marginal connection due to some manufacturing/design defect. When A10 was broken it did some really wierd things....

[Timbucus]

Indeed as I said over on the Uploader thread one of the Vias was not fully connected.

[SiriusHardware]

Will do. It would be hilarious (not) if the A10 track turns out to have about 1K resistance between A and B. Were these made by JLCPCB? I know the uploader PCBs were made by a different outfit.

[SiriusHardware]

Nope. Nice low resistances from A0-A11 to the buffer pins and onwards to the PIC pins. Also good low resistances from A9-A11 to the address decoder IC (HCT02) pins.

One thing I did notice while I had the LS02 in, if I fitted my 'best' 6116 RAM and uploaded Clive and watched for a while the image slowly started to get little bits knocked out of it - in other words it continues to get slowly corrupted even when the monitor is not writing to or reading from that area - and the Ortonview is only reading that area.

With the HCT in I wasn't noticing that, but maybe it would have happened, just more slowly, had I let it run for long enough.

Throughout all of this the OS / MK14 continue to run normally as far as I can see as long as the 6116 in the Ortonview is one of the ELCAP ones.

[Slothie]

The Ortonview PCB was made my JLCPCB and the uploader ones by AllPCB.

[SiriusHardware]

I wasn't sure about the OrtonView PCBs as the quality of the screen printing seems a bit more 'draft mode' than on the MK14 issue VIs where it was very clearly and densely printed.

When I was trying to buzz out the A0-A11 lines last night I did miss having the names of the signals printed on the underside of the PCB as well as the top side.

[Slothie]

Originally Posted by SiriusHardware

I wasn't sure about the OrtonView PCBs as the quality of the screen printing seems a bit more 'draft mode' than on the MK14 issue VIs where it was very clearly and densely printed.

When I was trying to buzz out the A0-A11 lines last night I did miss having the names of the signals printed on the underside of the PCB as well as the top side.

The last couple of things I've had done by JLCPCB have had poor screen printing, maybe its just coincidence, it used to be really good (as on the MK14 PCBs that you had made). They do a good job otherwise. I was impressed with AllPCB but then they knew I was a new customer

Just after I had sent the files off I thought I should have labelled all the connections on the back, but there you are!! They've been useful on the MK14 several times for me.

[SiriusHardware]

I've removed everything from the PCB that is not vanilla, such as the RC timing mod on the output of the HCT02 buffer enable gate, in case that is somehow upsetting the operation of the other gates in the HCT02 (though I would expect not).

I've also removed the turned pin sockets meant for the capacitors and soldered 4 x SMD 220pF directly to the pads to remove any doubt about whether the capacitors are properly connected.

I'll have another tilt at it tonight. If there is no change I'll drop one of my spare 877s in, and if still no change I'll pause until Tim's RAM samples arrive.

[Timbucus]

The RAM's went in the first class post lunchtime so hopefully not too long.

[SiriusHardware]

Cheers Tim - in that case I might give myself a night off and do the next round of testing when those are to hand.

[SiriusHardware]

Against my better judgement I powered the system up again only to notice that the gradual corruption of screen memory 0200-03FF was suddenly a lot worse, with the Clive image slowly deteriorating over time even when the system was doing nothing but waiting at the 0000 00 prompt. This was much worse than when I was playing last night, so what had I done?

Then I remembered one significant difference - a while ago, fellow forum user kan_turk sent me another pair of 27S13 PROMs which I bought with a view to comparing their power consumption with that of the 82S131 / DM74S571, both of which run quite hot. As I had the device programmer down anyway to test all my 6116s, I took the opportunity to program the 27S13s with the 'new' OS, put them in, made sure the machine came up with the correct prompt, then put the machine away.

Just now, when the Clive image was looking very much like a breakout demo, I still had the 27S13s in. So I changed back to the usual DM74S571s and it was back to almost completely stable with my 'best' 6116 in.

From this, I conclude that among other things the fault is causing the system to try to write to addresses in the ROM area 0000-01FF - you'll remember that the address decoding is so primitive that it does allow an attempt to write to that area, and I also conclude that for some reason this causes more 'harm' when trying to write to 27S13s than it does when trying to write to 74S571s.

[Slothie]

Originally Posted by SiriusHardware

From this, I conclude that among other things the fault is causing the system to try to write to addresses in the ROM area 0000-01FF - you'll remember that the address decoding is so primitive that it does allow an attempt to write to that area, and I also conclude that for some reason this causes more 'harm' when trying to write to 27S13s than it does when trying to write to 74S571s.

Except that the PROM enable on an Issue VI is gated on NRDS so writing to 000-1FF does not enable the PROM.

[Timbucus]

Oh the mystery deepens...

[SiriusHardware]

Except that the PROM enable on an Issue VI is gated on NRDS so writing to 000-1FF does not enable the PROM.

You had to go and spoil it. Now I'm really stumped.

[SiriusHardware]

Luckily I haven't really dismantled the original bridge / memory board and lashup Ortonview so as a fallback I will reassemble it over the next few days and see if it still works perfectly. The main problem there is that the 6116 RAM is soldered flat on to the underside of the bridge / memory board so I can't easily play with the RAM type.

[Mark1960]

I wonder if the problem you are having is also due to interrupted write cycles, not only affecting the high address lines but also the lower address lines. The 27S13 might have a slightly different effect on address line loading.

[SiriusHardware]

I can't remember how long your PROMs took to get there Mark, would expect possibly up to another week or so before the boards seem overdue. It'll be interesting to see if yours 'just works' in Vanilla mode.

One thing I have observed is that some of the bus lines on the board run parallel and very, very close to each other at times which could give rise to the possibility of crosstalk / mutual induction between one signal line and the others next to it, but if that was my problem, why only for me and nobody else?

[Mark1960]

Yes, the boards might not arrive for another week or two, but they could also turn up any day now.

I think its unlikely to be a problem with crosstalk at the kind of frequencies the mk14 and ortonview are running. Edge transition times from the PIC might be fast enough to cause ringing but should be settled before the control signals are active at these kind of access times. I was thinking about adding series resistors in place of the buffers but I’ll stick to the basic design until I confirm the memory corruption without the address bus capacitors, verify the capacitor fix and then try some experiments.