UK Vintage Radio Repair and Restoration Discussion Forum - View Single Post

SiriusHardware · 25th Oct 2020, 7:52 pm

Tim - none of this explains why yours does this but mine does not, so, as much as asking whether there is a problem in the code which, if there is, should affect mine in the same way, maybe we need to be asking what differences there are between our systems to make this problem occur on yours and not mine.

You've tried an 'A' device and it does not make a difference for you. The only other major difference is that my bridge board has a permanently-on memory expansion mapped at 0200-07FF (A 6116 SRAM) - because this had to be mounted on the underside of the bridge board I mounted the ICs directly on the board with the pins flattened out sideways to get the lowest profile possible, so I can't just unplug the ICs to make them disappear off the bus. A bad decision with hindsight, but when I made it, OrtonView was just a twinkle in Karen's eye.

One other difference I can think of though - remember my confusion over whether it was NRDS or NWDS which required a 4K7 pullup? Of course I eventually put that 4K7 pullup on NWDS when you pointed out that that was where the manual said it should be. I never removed the original 4K7 from NRDS on the bridge board though, so as well as the pullup resistor present on the SOC VDU / On OrtonView, I still have another 4K7 pullup on NRDS on the bridge board - therefore my NRDS is pulled up a little bit more strongly than yours.

Am I right in thinking you have some spare 2111 / 9111 RAM? Try swapping another set of RAMs in to eliminate the possibility that one of the existing ones is a bit too slow for OrtonView's liking. Or move the current set around to see if that changes the nature of the anomaly.

With regard to the reverse-C sometimes appearing on the third from right display cell, I have sometimes seen that occur but although mildly annoying it seems harmless - however I agree of course that it should not be happening and there will be an underlying cause for it.

Mark, Karen posted comprehensive details of the timings she was allowing for various events much earlier in the thread but those may have changed substantially in subsequent versions, so only she will know what the current interval is between the VDU taking NENIN high and subsequently trying to access the bus.

Based on the interval measured (by me) between the rise in NENIN ('I want the bus') and the rise in NENOUT ('You can have the bus') it looks like the VDU has to wait at least 130nS, maybe 150nS post-NENIN before it tries to use the buses.

25th Oct 2020, 7:52 pm	#584
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,586	Re: Mk14 vdu Tim - none of this explains why yours does this but mine does not, so, as much as asking whether there is a problem in the code which, if there is, should affect mine in the same way, maybe we need to be asking what differences there are between our systems to make this problem occur on yours and not mine. You've tried an 'A' device and it does not make a difference for you. The only other major difference is that my bridge board has a permanently-on memory expansion mapped at 0200-07FF (A 6116 SRAM) - because this had to be mounted on the underside of the bridge board I mounted the ICs directly on the board with the pins flattened out sideways to get the lowest profile possible, so I can't just unplug the ICs to make them disappear off the bus. A bad decision with hindsight, but when I made it, OrtonView was just a twinkle in Karen's eye. One other difference I can think of though - remember my confusion over whether it was NRDS or NWDS which required a 4K7 pullup? Of course I eventually put that 4K7 pullup on NWDS when you pointed out that that was where the manual said it should be. I never removed the original 4K7 from NRDS on the bridge board though, so as well as the pullup resistor present on the SOC VDU / On OrtonView, I still have another 4K7 pullup on NRDS on the bridge board - therefore my NRDS is pulled up a little bit more strongly than yours. Am I right in thinking you have some spare 2111 / 9111 RAM? Try swapping another set of RAMs in to eliminate the possibility that one of the existing ones is a bit too slow for OrtonView's liking. Or move the current set around to see if that changes the nature of the anomaly. With regard to the reverse-C sometimes appearing on the third from right display cell, I have sometimes seen that occur but although mildly annoying it seems harmless - however I agree of course that it should not be happening and there will be an underlying cause for it. Mark, Karen posted comprehensive details of the timings she was allowing for various events much earlier in the thread but those may have changed substantially in subsequent versions, so only she will know what the current interval is between the VDU taking NENIN high and subsequently trying to access the bus. Based on the interval measured (by me) between the rise in NENIN ('I want the bus') and the rise in NENOUT ('You can have the bus') it looks like the VDU has to wait at least 130nS, maybe 150nS post-NENIN before it tries to use the buses.