Mk14 vdu

[Timbucus]

I have discovered how to do combination triggers it seems the event where NENIN is HIGH and NWDS is low occurs 21 times in each frame with both the 10K and 4K7 pullups on NWDS - there is no difference in that side of it.

The difference is shown here (all copies look the same) first at 4.7K then at 10K





Obviously on the latter image has the screen corruption - in a perverse way it looks like the 4.7K has the write later which on our theory would make it more susceptible to the random write which is not the observed effect...

[Mark1960]

Originally Posted by Timbucus

It may help anyway - with it fully hooked up though I do not get the corrupt character on CHARSET in F27 under the M of TIMBUCUS - the extra capacitance and effect of the measurement tool means no effect to see.

Cheaper just to add capacitors

[SiriusHardware]

Maybe because the 4K7 pulls the line up harder, it pulls down more slowly. As you say, you would think that delaying the NWDS pulse and therefore moving it further inside the NENIN pulse would do more damage, not less.

Regarding the way merely adding the monitoring hardware seems to improve the operation of the system, well, if that's the case, remove the input lines from the system one by one and find out if it is only one of them which is causing the difference in reliability. That might give us an area for investigation.

I think I've told this story before but when I was quite young (probably around ZX80-era) my friend had built a Z80-based Powertran Sci Comp 80 but it wasn't working well - however quite by chance we found that if we put a scope on one of the bus or control lines (I forget which) it made the machine work. We used every means at our disposal to find the real cause of the problem but failed, so in the end what we did was, we soldered a 1M resistor and 50pF capacitor - a 'scope simulator' - from the offending line down to 0V. The last I heard, it was still working.

[Timbucus]

Originally Posted by Mark1960

Cheaper just to add capacitors

Yup

In fact that was a suggestion from Sirius to try earlier in the thread which I did experiment with on the signals I had on the breadboard - the one I tried on NWDS did not really help in the same way as these - in vain I looked for some data on the device and its inputs - there is nothing - the device it is a clone of assuming it is based on the version 1 says:

The original Logic is the only Saleae device to have internally pulled up inputs. All other Saleae devices had an internal resistance to ground. The original Logic's inputs float at about 2.4 volts, with over 100 K ohms of pull-up resistance, producing a very small pull-up effect.

Disconnecting one of the clips seems to have a zero reading so I suspect it is the internal resistance to ground taking effect - this in itself may give a clue where we are looking certainly that small spike was starting from around 1v so the pull down may make it reduce

Obviously we still get the 7 segment corruption so there is still a marginal case where it is happening to deal with.

I will hook up the scope and LS chip as well and see if I can still detect the spikes.

[SiriusHardware]

Originally Posted by Timbucus

In fact that was a suggestion from Sirius to try earlier in the thread which I did experiment with...

Actually, it was Karen who suggested .. er ... I forget what her exact expression was, but putting capacitors from NRDS and NWDS to GND. That was back before she discovered the port-A issue which was the real cause of the optimised firmware displaying random characters in locations 18-32 on each half screen.

I did suggest trying weak pulldowns on A8-A11 but Mark said it wasn't all that easy to pull down TTL lines (would require quite a low resistance which in turn would probably prevent the lines from being driven by the SC/MP).

As I said, just lift off the connections between the system and the analyser one by one and see if it is one particular line which is really making a difference.

[Mark1960]

I’ve been looking at the schematic in #3 on and off over the last few days to try and figure out the timing. Not easy with the very poorly drawn schematics, no annotation of the functions of inputs and outputs.

Thinking why the original vdu didn’t show the corruption and is it due to having the clock synchronised.

It looks to me that the output of the 80L95 buffers does not have any guard time from raising NENIN. I think I remember Karen mentioned that she does have guard time between NENIN and driving the bus.

Is it bus contention that stops the original vdu from corrupting RAM?

[Timbucus]

Originally Posted by SiriusHardware

Maybe because the 4K7 pulls the line up harder, it pulls down more slowly. As you say, you would think that delaying the NWDS pulse and therefore moving it further inside the NENIN pulse would do more damage, not less.

Regarding the way merely adding the monitoring hardware seems to improve the operation of the system, well, if that's the case, remove the input lines from the system one by one and find out if it is only one of them which is causing the difference in reliability. That might give us an area for investigation.

I think I've told this story before but when I was quite young (probably around ZX80-era) my friend had built a Z80-based Powertran Sci Comp 80 but it wasn't working well - however quite by chance we found that if we put a scope on one of the bus or control lines (I forget which) it made the machine work. We used every means at our disposal to find the real cause of the problem but failed, so in the end what we did was, we soldered a 1M resistor and 50pF capacitor - a 'scope simulator' - from the offending line down to 0V. The last I heard, it was still working.

Good call, I removed them one by one - it was of course practically the last - removing CE1B00 which is just A10 from the system makes the characters appear again below the M - putting the scope on the signal shows the difference between having it in circuit or not - note that the noiser signal is seen when the logic analyzer is plugged in - this would make me think it should cause the effect but, no removing it brings it back!!! - It has been Halloween so there must be Ghosts in there. These are all A10 clipped onto _CE1 on B00 over NENIN clipped onto the MPU.



Note that with just the scope on there the character does not change either so your story is relevant to recount again and your young self may have found a solution we can use... - it can even likely be fitted on the VDU board as A10 goes there. Maybe the PIC RA2 line has some effect we cannot see... it is designated AN2/VREF- in its alternate roles... I will try probably tomorrow now and see if MINEFIELD lets me play a few rounds...

[Slothie]

I treated myself to a "bitscope" last week, it has 2 analogue channels and 6 digital. I'm going to look at the timings of Karens software and check the relationships between the various signals and look for exceptions. This is something I can do without my MK14 while you guys are looking for the elusive pulses.

[SiriusHardware]

Is it bus contention that stops the original vdu from corrupting RAM?

Not quite sure what you mean, you mean perhaps that the SOC VDU does not allow the address bus any time to float off into an undetermined state? BAM! straight onto the address bus as soon as it raises NENIN?

Attached, a capture I posted a while ago showing SOC VDU NENIN over activity on the A0 line, the SOC VDU appears to wait for quite a while after raising NENIN before it cycles through each of the addresses it wants to read from, but between the rising edge of NENIN and the commencement of A0 activity the A0 line looks like it could be in a held-high state. If we assume the SOC VDU hits the whole address bus at the same moment then the same may apply to how it drives A8-A11.

[Timbucus]

Originally Posted by Slothie

I treated myself to a "bitscope" last week, it has 2 analogue channels and 6 digital. I'm going to look at the timings of Karens software and check the relationships between the various signals and look for exceptions. This is something I can do without my MK14 while you guys are looking for the elusive pulses.

Sounds very useful best of both worlds and like we are both having an early Christmas...

[SiriusHardware]

Er, yes, I've just ordered one of those 8-channel logic gizmos that you have. I'll have to quiz you about software to use with it when it arrives (perhaps off topic for this thread).

[Timbucus]

I went to have a glass of milk and a biscuit as by the time I return from the kitchen the reverse C has usually appeared - no sign of it. So I unplugged the rest of the equipment and the corrupt character towards the end of B block began appearing.

Anyway to cut a long story short plugging back in the leads I showed that the INS8154 CS lines were the ones and they are A8 and A11 - connecting either to the analyzer will stop the character - so we are back to the weak pulldowns on A8-A11 I think...

[Timbucus]

Originally Posted by SiriusHardware

Er, yes, I've just ordered one of those 8-channel logic gizmos that you have. I'll have to quiz you about software to use with it when it arrives (perhaps off topic for this thread).

Indeed PM perhaps - is it the same AZ-Delivery one?

[SiriusHardware]

The very same. Should be here next week, I'll ask you for more info then. One thing I did wonder is whether the software supports multiple input devices, ie, two or three of these things paralleled up.

[Slothie]

Well I've spent several hours reading through this entire thread, collecting the 10 different firmware versions and taking a peek to see if I can get some understanding of how it works. Although I'd be lying if I said I understood everything (!) I must say its very cunning in the way it does seem to work. After all this reading I'm beginning to wonder (as others have mentioned in passing) if the problem is actually the delay between NENIN being asserted and the address bus being driven is too long. Sirius's screenshots of the SOC VDU seem to show it asserting NENIN and immediately doing stuff on the bus. Perhaps the delay should be really short so as not allow the address bus to "drift" but long enough to allow the SC/MP to abort a write (~250nS ?).

[Mark1960]

Originally Posted by SiriusHardware

Not quite sure what you mean, you mean perhaps that the SOC VDU does not allow the address bus any time to float off into an undetermined state? BAM! straight onto the address bus as soon as it raises NENIN?

Attached, a capture I posted a while ago showing SOC VDU NENIN over activity on the A0 line, the SOC VDU appears to wait for quite a while after raising NENIN before it cycles through each of the addresses it wants to read from, but between the rising edge of NENIN and the commencement of A0 activity the A0 line looks like it could be in a held-high state. If we assume the SOC VDU hits the whole address bus at the same moment then the same may apply to how it drives A8-A11.

Yes thats whats I was thinking. I was calling it contention because it doesn’t look like there is any time waiting for the SCMP to stop driving the address lines before the VDU starts driving them which might stop the wrong RAM being enabled at the end of an interrupted write cycle.

Maybe the 80L95 is not strong enough drivers to damage the SCMP outputs, but it doesn’t seem like a good idea.

Not sure which would be the winner between a PIC and an SCMP.

[Mark1960]

Originally Posted by Timbucus

I went to have a glass of milk and a biscuit as by the time I return from the kitchen the reverse C has usually appeared - no sign of it. So I unplugged the rest of the equipment and the corrupt character towards the end of B block began appearing.

Anyway to cut a long story short plugging back in the leads I showed that the INS8154 CS lines were the ones and they are A8 and A11 - connecting either to the analyzer will stop the character - so we are back to the weak pulldowns on A8-A11 I think...

74ls input current to pull to low level is 0.4mA max, I don’t remember seeing typical current quoted. Maximum input voltage for low level is 0.8v, so for a single 74ls input a pull down resistor should be maximum of 2k which is not leaving any margin but possibly ok at room temp. For two 74ls inputs that would be 1k. I think the high address lines drive two or more 74ls inputs.

Those address lines only need to be pulled down long enough for NWDS to be released and pulled high, so a capacitor might do that and have less impact than a resistor.

[SiriusHardware]

The PIC outputs have very strong drive capability, so one possibility is to insert lowish value series resistors in the address drive lines from the OrtonView so that if there is contention the conflict can happen across the resistors, avoiding the possibility of two opposing outputs battling with each other directly.

I think we are close to the point of needing to understand the code well enough to try moving address-drive-enable much closer to the point of NENIN activation.

[Mark1960]

Originally Posted by SiriusHardware

The PIC outputs have very strong drive capability, so one possibility is to insert lowish value series resistors in the address drive lines from the OrtonView so that if there is contention the conflict can happen across the resistors, avoiding the possibility of two opposing outputs battling with each other directly.

I think we are close to the point of needing to understand the code well enough to try moving address-drive-enable much closer to the point of NENIN activation.

I think this method would need to drive A8 to A11 low when driving NENIN high, then driving the VDU memory address a little later, to make sure all RAM was deselected while NWDS might still be active. That then raises the question of problems attempting to write to PROM due to MK14 address decoding for the PROM which does not qualify NRDS.

I’m using Slothie’s circuit diagram from #122 of the MK14 schematic revisions thread as the original S of C schematics are not so clear.

NWDS or the chip enables could be gated by NENIN, but that would be quite a major mod on the MK14.

I think capacitors on A8 to A11 might be the simplest solution. These are the address lines connected to 74ls inputs of the address decoding, where the input current of the 74ls inputs could be pulling the floating address lines high faster than NWDS is pulled high. Capacitors could help to hold the address of the interrupted write cycle, which would be repeated when NENiN is returned low.

Not sure if the lower address lines for the display interface should also be considered.

[SiriusHardware]

Looking back again at the image I reposted in #789, it looks to me as though the VDU possibly imposes its initial output levels on the address bus slightly BEFORE it takes NENIN high which of course should be a no-no.