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)

SiriusHardware 16th Aug 2021 9:11 pm

Re: Ortonview PCB
 
I've got my original build of Ortonview on my 'Picduino' veroboard with the original bridge / memory board sitting in between, Vanilla mode (direct address connection and 4 x 200pF caps on A8-A11) and the extra memory is rock steady and reliable, I can load into it over and over again and the only bytes which get changed are the ones which are being loaded into. I can leave it running for ages after that and the images is completely stable, never changes. With the equivalent setup on the PCB version I see random bits being knocked out of the image over time until it eventually becomes unrecognisable.

Having found that the original concept and the original PIC do still work as expected I'll pause for tonight and tomorrow I'll go back to the PCB version and try the RAMs Tim loaned me, I'll also try fitting an electrolytic across the 5V rail because that's one thing the 'Picduino' does have that my PCB currently does not.

Timbucus 16th Aug 2021 9:24 pm

Re: Ortonview PCB
 
Mine does have the Electrolytic fitted although I did bypass the regulator... you will find the problem I am sure.

SiriusHardware 17th Aug 2021 7:12 pm

Re: Ortonview PCB
 
Well, I fitted a 100uF capacitor to the 5V rails and I'm a small step further on, as my 'good' EL6116LP-10 now gives me completely stable results just with that one change.

Going through a selection of the RAMs I have available including Tim's samples, I get:

M5M5117P-15 - completely stable.
EL6116LP-10 (#1) - now completely stable.
EL6116LP-10 (#2 - #5) - slow corruption of the 0200-03FF screen RAM area with the machine just sitting at the 0000 00 prompt.
Hitachi HM6116LP-3 (#1-#2) - system goes haywire.
Hitachi HM6116P-4 - system goes haywire.
MK6116N-15 (#1, #2) - system goes haywire.

So at the moment the one benefit of fitting the electroytic is that it has made a single EL6116LP-10 RAM which was already almost reliable, completely reliable. At the moment I'm obviously a long way away from being able to just drop any old 6116 into the board. One good result is that Slothie's chosen M5M5117P-15 happens to be one of only two ICs which works really reliably.

I'm now going to take all the removable parts off the PCB and just do some basic measuring of, and between, tracks.

Mark1960 17th Aug 2021 8:50 pm

Re: Ortonview PCB
 
M5m5117p-15 spec shows th data hold time 0ns, trec of 10ns looks to be address hold time in the timing diagrams.

Mk6116N-15 spec shows tdh data hold time 0ns, tah address hold time of 10ns.

Hm6116lp-3 and P-4 spec shows tdh data hold time 10ns, twr of 10ns looks to be address hold time in the timing diagrams.

Not much difference between them as far as spec is concerned but its possible the 5117 has more margin to spec.

Slothie 17th Aug 2021 9:04 pm

Re: Ortonview PCB
 
Well I can assure everyone that I didn't design in a "trap" to make only M5M5117P RAMS work on the board! I'm a little surprised its making a difference. Perhaps I should take a closer look at the 6116 data sheets to see if there are any significant differences.

Measurements show that the access time from setting the address to the end of the read/write cycle is 500nS minimum, and the time the read and write pulses are low is still ~250nS of that, so it shouldn't be sensitive. The read cycles from the PIC are even more relaxed than the SC/MP timing, so I really don't think that memory speed is a factor. Perhaps the data bus isn't stable for that entire time, which is why things are not great.
I am beginning to think it might be noise on the NWDS pin, I have been occasionally catching very brief pulses when I wouldn't expect them (for instance, with no NADS pulse before them, or a long time after NENIN has gone high) but they are very brief. Maybe thats enough to corrupt the memory? Also I only seem to be experiencing corruption in the Fxx memory segment when continuously writing to Bxx. I've been trying various scenarios but not really coming to any conclusions, but by putting the program in the RAM/IO, writing to Bxx it will run almost indefinitely with random corruption in the Fxx memory block. After a while running like that looking in the memory at 200-> shows it is completely unchanged.
I currently only have the 2 10k pullups on NWDS but I am going to change one of them to 4.7k since I recall Sirius saying that improved things, but before I do that I will need to find my Bitscope and have a look at the signal so I can get "before" and "after" shots!

SiriusHardware 17th Aug 2021 9:09 pm

Re: Ortonview PCB
 
Thanks for the research, Mark.

I might try your series decoupling resistor idea as that would be easy - just replace the wire hoops I currently have plugged into the buffer sockets with vertically mounted resistors. I wonder if you had a value in mind?

I don't see any DC problems on the tracks on the PCB. Somewhere around here I have one of those cheap microprocessor based capacitance meters - not sure how low in pF value it goes but I'm now wondering if some of the long parallel runs of tracks with very small gaps between are forming low value capacitors (ie, two long parallel conductors separated by a very narrow band of insulator).

I may ultimately sever the address, then data tracks at each end and remake / reroute them with kynar wire to spread them further apart. That's how all the buses are wired on the original build.

Just caught Slothie's post: I assume, Slothie, that you are working with a vanilla install in which you intentionally have not added the A8-A11 capacitors in order to produce the corruption so you can observe it. Unfortunately it would seem that you are accidentally using a best case scenario RAM so you aren't getting the problems I am getting with so many other examples of 6116 types including one (HM6116P-4) which appears to work OK for Tim. Maybe I can send you one of my HM6116P-3s down - one of the ones which stop the system working, to see if it works equally badly in yours? It will give me a better idea of whether I am trying to solve a problem unique to my particular PCB.

Mark1960 17th Aug 2021 9:25 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1399134)
I might try your series decoupling resistor idea as that would be easy - just replace the wire hoops I currently have plugged into the buffer sockets with vertically mounted resistors. I wonder if you had a value in mind?

I was thinking 100 ohm, but that was just to try and put some current limit between the pic and 8060 to try and protect from bus contention if we are making changes to the pic code.

I don’t think it would help with corrupted ram, maybe caps on A0 to A7 in addition to A8 to A11 is worth a try.

SiriusHardware 17th Aug 2021 9:26 pm

Re: Ortonview PCB
 
Quote:

I am beginning to think it might be noise on the NWDS pin
Produced by what, the NWDS pin on OrtonView?

One stunt I have sometimes used when trying to debug or hack i.e., i2c comms, is to put a resistor in series with the data drive pin on the master or slave so that the two devices pull the data line to different low levels - that way I can see which device is 'talking' at any given time, the master or the slave.

You could do something similar here, put a Schottky or ordinary diode in series with the OrtonView NWDS output so that NWDS pulls the write line to a different logic low level than the SC/MP does. If your 'random' NWDS pulses have the same low level as the ones known to be coming from the OrtonView's NWDS output, you know they are coming from OrtonView.

SiriusHardware 17th Aug 2021 9:34 pm

Re: Ortonview PCB
 
If these 'unwanted' NWDS pulses you might be observing are much briefer than 'proper' NWDS pulses of regulation length, then maybe play with a capacitor from NWDS to 0V - value weighted to take out needle-thin pulses, but not 'regular' NWDS pulses?

Mark1960 17th Aug 2021 9:55 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1399146)
If these 'unwanted' NWDS pulses you might be observing are much briefer than 'proper' NWDS pulses of regulation length, then maybe play with a capacitor from NWDS to 0V - value weighted to take out needle-thin pulses, but not 'regular' NWDS pulses?

That might delay the rising edge of NWDS and make the problem fixed by capacitors on A8 to A11 worse, though that would be another useful piece of information.

Slothie 17th Aug 2021 10:10 pm

Re: Ortonview PCB
 
1 Attachment(s)
Well the Ortonview shouldn't be driving the NWDS signal at all, so how it can be affecting NWDS I can't see. So the only way that the PIC can be creating invalid writes is to intefere with the address bus while the SC/MP is using the bus or by rogue NWDS pulses coming from the SC/MP while the Ortonview is reading. Very rarely I observed a 1 sample (250nS) pulse when sampling at 4MHz that happens when the NENIN pin is low but has no preceding NADS pulse - I was under the impression that there was always a NADS at the beginning of a memory cycle, although its possible there is not in a r-w operation such as ILD or DLD. I tried sampling faster but didn't manage to capture one of these pulses. I can't remember, however, if this sample was from when running the code in Fxx (probably is, because of all the reads from Fxx) so I need to try to repeat this with the code running in the RAM/IO and see if I can observe these "rogue" pulses.

I really need to make an organised set of observations.

The one thing really puzzling me is that I dont seem to be able to trigger on write pulses to the Fxx area when it is getting corrupted there. Maybe I need to probe the enables on the RAM chips on the MK14 in case there is some interaction between the timings of the decode logic on the Ortonview and the MK14. I need to think how I can do that.

SiriusHardware 17th Aug 2021 10:12 pm

Re: Ortonview PCB
 
I'm assuming (as suggested above) that at the moment Slothie intentionally does not have capacitors on A8-A11 anyway, so any effect due to a capacitor on NWDS would be due to that alone.

SiriusHardware 17th Aug 2021 10:14 pm

Re: Ortonview PCB
 
Quote:

Well the Ortonview shouldn't be driving the NWDS signal at all
b****r, why do I keep forgetting that?

Tim is the one with the really fast scope, his is a much higher speed version of mine. Maybe we can drag him in on this.

SiriusHardware 17th Aug 2021 11:23 pm

Re: Ortonview PCB
 
Quote:

I dont seem to be able to trigger on write pulses to the Fxx area when it is getting corrupted there
Maybe knock up a little pulse stretcher with a 7412x monotstable, such that a narrow logic-zero pulse on the monostable input makes the monostable generate a longer logic-0 pulse, long enough for the analyser trigger to fire on?

Mark1960 18th Aug 2021 4:36 pm

Re: Ortonview PCB
 
Boards arrived late yesterday, almost completed assembly, just a few more parts needed.

I don’t seem to have any 2k7 resistors left, but I can fit 1k2 + 1k5.

I’ll need to substitute BC107 for the transistor in the output, but should be ok for black/white only.

No 220pF caps, just realised the ones marked 220 are only 22pF, but I can try 100pF.

I’m hoping I can find time to finish the assembly today, checking basic functions will probably need to wait until tomorrow.

SiriusHardware 18th Aug 2021 4:54 pm

Re: Ortonview PCB
 
Glad they got there at last. I don't see why BC107 would not work (that takes me back though - projects in Everyday Electronics, etc!). BC182 - BC184 (not 'L', unless you untangle the pinout) would probably work as well. Don't forget that the orientation outline shown on the PCB is incorrect for BC547, probably for other T092 devices as well. if you are using a transistor with the pins lined up e-b-c, 'e' needs to go to the video connector signal pin.

My original build uses 2 x 100pF (in parallel) on each of A8-A11. SMD parts, stacked, as it happens, because we don't have many capacitors in the pF range at work.

Tim gets away with 47pFs in that position so 100pFs may very well work for you. The minimum value which works reliably for me on my original build is 147pF (100 + 47, obviously).

If you don't fit them straight away, you'll be able to see the problems we are trying to find the cause of, but perhaps you'd prefer to have the reassurance of seeing it work properly first.

Mark1960 18th Aug 2021 5:16 pm

Re: Ortonview PCB
 
I was planning to start with #352, then move to #692 to show the memory corruption. I’ll try 100pf to see if that improves any, but more interested in experimenting with other possible fixes by synchronizing NENIN to mk14 XOUT.

With the legs on a bc107 in a triangle it should be easy to fit to a bce footprint.

The phono sockets I have fit nicely, I don’t even need to straighten the legs.

I started playing with electronics back in the seventies, mostly practical electronics and practical wireless, I think it was before everyday electronics came out. Used to be able to get bc107/8/9s, resistors, capacitors etc from a couple of audio shops in Darlington. This was a few years before Tandy’s opened. No online shopping and placing mail orders by post was a real pain.

Timbucus 18th Aug 2021 5:59 pm

Re: Ortonview PCB
 
Happy to try a scope on something, - that is really the only way but, as it does not have an external trigger trying to capture an event could be tricky. I have used other chips as you know to create a second channel trigger event but, it was pointed out to me that this does not help in the case of runts and out of spec spikes/pulses as they may or may not trigger.

I can also put the HP on the problem to get more accurate diagnosis but, again that may not spot a transient problem caused by signals on the bus fading etc which people seem to be homing in on.

I assume if I desolder my Caps (and patch out the buffers) that it will start to fail - can you confirm Sirius that with the caps yours is stable? I think I have lost the plot about which configuration has the issue :)

Mark1960 18th Aug 2021 6:14 pm

Re: Ortonview PCB
 
I can probably try and capture scope plots on NWDS tomorrow if you don’t want to hack your board. I’ll use socket strip for the bus capacitors.

My scope has external trigger, I just need to find my spare probes. Not sure how much the extra trigger will help as we really need to know if we are triggering on runt or normal NWDS. Maybe trigger on NENIN and monitor NWDS and high address line, and repeat until it captures something of interest.

SiriusHardware 18th Aug 2021 7:53 pm

Re: Ortonview PCB
 
Quote:

can you confirm Sirius that with the caps yours is stable?
Only with two specific 6116 ICs, one being the only one of five otherwise identical RAM ICs which completely works. The other, luckily, is the M5M5117P you loaned me so using one of those would be a good starting point. I have 4 x 220pF in my case but then I always did need a higher minimum capacitance than you.

Just been reading back through the original thread, though, and it seems you had to raise one of the caps to 100pF in order to get yours completely corruption free. The minimum I found I could use was 156pF, not 147pF as I thought.

I've just had another thought about a possible cause for the wide variation in my build's tolerance for different RAM ICs - the linear regulated supply I run my setup on is 7.5V, fixed, regulated. I chose that low voltage to keep the volts drop across the regulator (therefore the watts dissipated in the regulator) at the lowest possible value. I'm wondering now if some of the RAMs draw more current than others, and if they do, whether that is enough to make the 7.5V input supply dip just enough to stop the MK14 regulator from regulating properly.

I'll try a slightly higher input voltage to see if that allows the other RAMs to work: Back shortly.


All times are GMT +1. The time now is 8:27 pm.

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