Re: Ortonview PCB
 

Ah! I didn't catch that. Maybe NENIN and XCLOCK do need syncing somehow.

Re: Ortonview PCB
 

You had it in a different sense as well, when you were hanging one of those parallel logic sniffers on the high address lines - doing that made the fault clear. In that specific instance I think you narrowed it down to the A10 line being the one which was making the difference.

The capacitors were ultimately Mark's suggestion but the idea may have come from your original observation that hanging something on those lines made the fault go away, plus my own (much earlier) experience of having 'fixed' a computer fault which went away when a scope probe was put on a particular pin, by soldering a 1M resistor and 50pF capacitor from the pin to 0V (To make the pin 'think' it had a scope connected to it).

Re: Ortonview PCB
 

Well I've just received some 74LS74's and found a few other spare gates so I might be able to do some experiments tomorrow. looks like its proto-board time!

Now I am wishing I'd made the top corner of the board a prototyping area after all :D

Re: Ortonview PCB
 

It kind of already is, just lop a few of the existing interconnecting tracks... power pins will still be in the right place.

Re: Ortonview PCB
 

That sounds correct - better memory than me...

Re: Ortonview PCB
 

I think adding the 74ls74 as described in #275, possibly also connect NENIN from PIC to clear on the 74ls74 so that when NENIN goes low there is not so much of a delay in NENIN going low to the 8060. This would also add a little setup time from NENIN going high prior to rising edge of the clock.

I’m hoping there is no need to fine tune the delay of NENIN to the 8060 with any RC delay.

Pure guesswork but suspect there is a setup time inside the 8060 for NENIN high to the rising edge of xout, or its internal equivalent, and the setup time might be different for the address and NWDS control. Registering NENIN to xout should give maximum set up time to the next rising edge so that both the address control and the NWDS control are triggered on the same clock cycle.

Suspect Slothie might beat me to it, but I’ll also try adding a 74ls74 on protoboard.

Re: Ortonview PCB
 

The other thing I noticed yesterday is that the address lines are not pulled high to give good high logic level. It might be good to add pull up resistors, though that would make the corrupted write issue worse. Maybe if adding the 74ls74 works we can see if it still works with pull up resistors, that should make it worst case for the corrupted write issue.

Re: Ortonview PCB
 

Well if it does work then it would explain why its so random and it varies over time.

Re: Ortonview PCB
 

Do you mean when OrtonView is actively trying to drive the address lines? I would be surprised if so, as the PIC has very strong output drive. I thought I remembered the address lines being driven from rail to rail when it is the PIC which is driving them.

Re: Ortonview PCB
 

No the PIC drives them rail to rail, probably too strong, I might still put in series resistors later.

8060 doesn’t drive the outputs very high, I guess that should be expected for nmos.

Re: Ortonview PCB
 

I connected a 74hct74 as in #446, so synch the rising edge of NENIN to rising edge of Xout, but with no improvement. If anything it is now more repeatable.

I think next attempt is to synch to the falling edge of clock.

Re: Ortonview PCB
 

Keep up the good work, Mark. This problem will fall eventually, as long as we keep hacking away at it.

Re: Ortonview PCB
 

I tried syncing to the rising edge as well, I even made a post about it with a video 2 days ago but I either stuffed up making the post or it got deleted. With the "testmem" program assembled to run at E80 and using variables in the I/O RAM and writing only to Bxx (i.e. no writes to Fxx) the memory in Fxx can clearly be seen to be being corrupted, except this time it seems more "regular" and evenly spread across the page, whereas before the corrupted locations seemed to bunch around F00 and F80 locations. It did seem to be happening more though.

https://youtu.be/Zwh369ewhzc

Re: Ortonview PCB
 

I notice you still have the buffers installed - my problems, although undoubtedly exaggerated by having no power supply to the 6116(!!) seemed a lot worse when the buffers were installed, I had rows of characters rolling at that point.

I would suggest simplifying it to the 'no buffer' arrangement while trying these other tweaks - I think that's probably how Mark has his configured at the moment anyway.

Re: Ortonview PCB
 

Thats a good point, it didn't occur to me. I'm also going to try putting in an inverter for the clock signal, got to get the glue gun warming up!

Re: Ortonview PCB
 

just tried taking out the buffers and installing the links and it doesn't make a difference. Sorting through my chips for something I can use as an inverter now!

Re: Ortonview PCB
 

Inverted XOUT with a 74HCT02 NOR gate and it doesn't appear to have made a difference.

Re: Ortonview PCB
 

I don’t have the buffers fitted and no capacitors on the address lines.

I was using a tight loop using ILD on B10, This gives unwanted writes to both F10 and also B30, and I can see the early rise of both A10 and A5 on the scope. Also I can see the NENIN is definitely rising on the rising edge of xout, so the synch to xout was working.

I was going to try the second half of the 74hct74 as an inverter, input to preset, output from Q and all other inputs grounded. As Slothie already tried an inverter without success I’ll skip that.

Next attempt is RC from Q output of 74hct74 to clock second half of 74hct74. D and preset held high and clear to PIC NENIN. I think a 100pF cap and a 5k preset should give me a 0 to 250ns range.

Re: Ortonview PCB
 

Hmm variable delay. Well that would certainly give the opportunity to see if it is the delay between XOUT and NENIN,

I was wondering if we could use the rising edge of NADS to gate NENIN, as every read/write operation is always preceded by NADS, the downsides to this is that it is an ugly kludge, and that executing DLY statements would probably break it, as I don't beleive the SC/MP processes any memory cycles during a DLY. Also the original board didn't need NADS, so we shouldnt need it. I get the feeling that our friends at SoC might have had to do some "fine tuning" of their circuit to get it to work. It seems to me it is using NENIN in a way it wasn't intended to be used, ignoring NENOUT and NBREQ. Although you shouldn't be able to break the system by just asserting NENIN at an inopportune moment.

Re: Ortonview PCB
 

Oh for the record, I am operating at 4.433619Mhz with no capacitors and no buffers. Firmware #692.