UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 27th Oct 2020, 10:42 pm   #661
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Mk14 vdu

So it seems the corrupted address is always in the other Ram chip at the same address, is it a problem in the address decoding delaying release of chip select or activating chip select when it shouldn’t?
Mark1960 is offline  
Old 27th Oct 2020, 10:46 pm   #662
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Mark1960 View Post
So it seems the corrupted address is always in the other Ram chip at the same address, is it a problem in the address decoding delaying release of chip select or activating chip select when it shouldn’t?
It must be affecting it as the address lines are starting to be driven but, with my 10K pullup above my copy of charset writes a character to BOTH F and B blocks (in the wrong place BC7 and FC7 for me)... so I think it is both, the previous CS has not yet pulled up and yet the new one has already gone low.

Who knows I may be able to scope that in detail later this week - someone who shall remain nameless has been persuading me to spend more money... luckily as I often need a push to do the right thing.
Timbucus is offline  
Old 27th Oct 2020, 10:54 pm   #663
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Possibly . Actually I would only need to pull up D4-D5 as the character generator ignores bits 6-7. Something else to throw into the mix, I 'converted' the program to fill the extra-extra RAM area 0200-03FF with '?' and render the rolling character at 0327. It has been running for ~20 minutes now and I have seen no alteration to 0227. So maybe this has something to do with RAM speed, as that RAM area is supplied by a 6116, specifically an ELECAP EL6116LP-10 (so presumably 100nS?)
Funny enough I had all the bits out earlier to convert my not really working CMOS RAM expansion to a 7402 based decoded one a bit like yours... Project for tomorrow now and I can try similar tests like running minefield in that RAM.
Timbucus is offline  
Old 27th Oct 2020, 11:13 pm   #664
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I'm going to make a brave suggestion here: Run charset, pointing at its original locations in 0F00- and 0B00- without the VDU connected and see if the 'matching' location still gets changed away from its default value - ie, let it run for a while and then use the monitor to inspect the value in the 'ghost' memory location.

Maybe the reason 'minefield' falls over is because it runs in 'original' ram and writes to 'extra' RAM., whereas charset runs in I/O RAM which has its own _CS signal.

If you could adapt 'Minefield' to run in the I/O RAM (probably too big) or in extra-extra RAM but still write to the extra-ram at 0B00- with the upper half displaying 0F00-, I suspect the game would run fine in the lower half of the screen but you would see the upper screen area getting little bits knocked out of it every now and then - harmlessly, as the game code would be somewhere else.
SiriusHardware is offline  
Old 28th Oct 2020, 7:11 pm   #665
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

My non-A 877s arrived today, a good excuse to resume testing. I'm going to revert to the last 'mainstream' firmware which Karen posted the .asm of in #523, and which I posted the .hex of in #532.

I'm going to do the test I mentioned above as well, namely running 'charset' for a while without OrtonView even connected. As Mark rightly pointed out, we have to at least consider the possibility that there is an address decoder problem on the MK14 which occasionally enables CE on the two ICs which hold the 'base' RAM (0F00-0FFF) when the two ICs which hold the 'extra' RAM (0B00-0BFF) are being written to.
SiriusHardware is offline  
Old 28th Oct 2020, 7:29 pm   #666
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

..and I'm pleased to be able to confirm Tim's observation that with the 'plain' 877 device, there is NO SHUDDER PROBLEM in graphics mode.

If all interested parties agree, I think we will now draw a line under that issue and say that this project HAS to use an 877 and is not suitable for the 877A due to subtle differences in the architecture of that IC.

Which leaves us only with the problem of the occasional unwanted memory writes - let's now focus on that problem and try to nail down the exact circumstances under which it happens, whether writes to addresses in the range 0F12-0FFF also occasionally enable the corrresponding cell in any other 256-byte blocks, etc.
SiriusHardware is offline  
Old 28th Oct 2020, 7:50 pm   #667
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
My non-A 877s arrived today, a good excuse to resume testing. I'm going to revert to the last 'mainstream' firmware which Karen posted the .asm of in #523, and which I posted the .hex of in #532.

I'm going to do the test I mentioned above as well, namely running 'charset' for a while without OrtonView even connected. As Mark rightly pointed out, we have to at least consider the possibility that there is an address decoder problem on the MK14 which occasionally enables CE on the two ICs which hold the 'base' RAM (0F00-0FFF) when the two ICs which hold the 'extra' RAM (0B00-0BFF) are being written to.
Its also possible the address lines are changing after the CS goes low, because the address isn't latched on 2111's
Slothie is offline  
Old 28th Oct 2020, 7:58 pm   #668
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Sounds good to me - 877 not A version.

As to the last remaining bug, I am pretty certain it will not happen on a standard MK14 as it does not occur with the SOC VDU and some quite complex games like SEGTRIS would suffer.

I am working with the #523 version on my non A chip but, I do not think there is an issue to move forward from the ASM version in #621 as it was only slightly tweaked - the diff is really small:
Code:
1717d1716
< 	BSF	RCSTA,SPEN
1718a1718
> 	BSF	RCSTA,SPEN
1757d1756
< 	BSF	RCSTA,SPEN
1758a1758
> 	BSF	RCSTA,SPEN
1797d1796
< 	BSF	RCSTA,SPEN
1798a1798
> 	BSF	RCSTA,SPEN
1837d1836
< 	BSF	RCSTA,SPEN
1838a1838
> 	BSF	RCSTA,SPEN
Timbucus is offline  
Old 28th Oct 2020, 8:20 pm   #669
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I've just had another slightly changed version of CHARSET running, this time flooding all unallocated bytes in the 0F12-0FFD and 0B00-0BFF blocks with 0x00 = '@' so that any characters which get morphed into one having a code of xF are easily seen on the VDU screen.

It's writing (intentionally) to 0B1B and occasionally unintentionally to 0F1B, as has been observed before. If I stop it when the 'occasional' character has been turned from '@' to '/' and look at the actual code of that '/' character I find that the memory location contains 0xEF, but as stated before the character generator is only interested in bits 0-5 of any code handed to it. That was with OrtonView connected and active.

I've also tried running the program without OrtonView connected and so far, even after a run of 20 mins+, I have not seen a single instance of 0F1B being altered when 0B1B is being continually written to.
SiriusHardware is offline  
Old 28th Oct 2020, 8:39 pm   #670
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
I've also tried running the program without OrtonView connected and so far, even after a run of 20 mins+, I have not seen a single instance of 0F1B being altered when 0B1B is being continually written to.
From my perspective thats a relief... perhaps someone should have a look at the timing from CE to/from address changes?
Slothie is offline  
Old 28th Oct 2020, 8:39 pm   #671
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Second experiment - now this is interesting

-VDU displaying 0F00- and 0B00-
-Charset writing continually to 031B

The occasional corruption now happens to the same character in BOTH of the displayed blocks, that is, it appears in locations 0F1B (as before) and 0B1B. When the displayed character is 'O' the actual code in both of those locations is 0x4F.

If I change the target address for the continual write to 021B instead of 031B, then strangely enough the program then runs indefinitely without any corruption to 0F1B or 0B1B.

I'll try writing to the ..1B offset in a few more valid RAM areas to see which ones do and do not cause writes to 0F1B and 0B1B.

Slothie: Yes, it's good that the bare machine is not showing this behaviour but you know we had to rule it out.

Last edited by SiriusHardware; 28th Oct 2020 at 8:48 pm.
SiriusHardware is offline  
Old 28th Oct 2020, 8:59 pm   #672
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I've now tried writing to the following addresses and observing the effect, if any, on addresses 0F1B and 0B1B by looking at the VDU display.

021B - No effect on either
031B - Both are affected (same character always shown in both)
041B - No effect on either
051B - only 0F1B is affected, 0B1B is not
061B - No effect on either
071B - only 0F1B is affected, 0B1B is not
SiriusHardware is offline  
Old 28th Oct 2020, 9:09 pm   #673
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Nice results on testing that were consistent with my findings on the effects.

I have been trying to get my RAM expansion running to do some similar testing but, I think I have a pair of fake or dead 6116 chips so it probably wasn't the CMOS CS generation that was the issue...

I will hopefully have a better scope by Friday to take a look at relative timings of signals.
Timbucus is offline  
Old 28th Oct 2020, 9:23 pm   #674
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
I've now tried writing to the following addresses and observing the effect, if any, on addresses 0F1B and 0B1B by looking at the VDU display.

021B - No effect on either
031B - Both are affected (same character always shown in both)
041B - No effect on either
051B - only 0F1B is affected, 0B1B is not
061B - No effect on either
071B - only 0F1B is affected, 0B1B is not
So it is only affected when A8 is '1' which is interesting because on the rams, a8 is NANDed with A9 & A11 and fed to all the RAM chips /CE2 pin - (i.e. all the ram). Which chip is selected is determined by A10. Looking to me like it could be insufficient time between the address lines being setup and the NRDS signal going low. Of course, on the SoC VDU this wouldn't be a problem since it does this once for the whole line.
Slothie is offline  
Old 28th Oct 2020, 9:44 pm   #675
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Yep, on that interesting note I think I will have the rest of the night off and tomorrow I'll try looking at when _CE signals are happening relative to NWDS pulses. If I trigger on _CE of the RAM which shouldn't be getting written to then hopefully we'll see what is going on on the address buses before and after the _CE pulse.

Tim should be able to join in with this soon because he seems to have had a sudden mad urge to buy himself a new storage scope, a much better SPECed version of mine as it happens. Hopefully we can both then bring some artillery to bear on this problem.
SiriusHardware is offline  
Old 28th Oct 2020, 9:44 pm   #676
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Mk14 vdu

Is it possible to scope chip enable that is unique to the block that should not be written and NWDS. Trigger on the chip enable and monitor NWDS.

Hopefully show if NWDS is truncated with a glitch on the chip enable.

If I remember correctly, the difference in chip enable is only an inverter on one address line. If only one ram block shows the issue it might be pointing at the delay in this inverter, or the input switching threshold compared to switching threshold of the other ram chip.

As we already see an intermediate logic level on earlier scope captures of A0, maybe the address line input to the inverter is at a level that can enable both ram chips at the same time.

Why it only happens with ortonview could be timing relative to floating address line.
Mark1960 is offline  
Old 28th Oct 2020, 9:48 pm   #677
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Quote:
Originally Posted by Mark1960 View Post
Is it possible to scope chip enable that is unique to the block that should not be written and NWDS. Trigger on the chip enable and monitor NWDS.
Will do Mark, but I'm going to have a rest from this for the rest of the evening and pick it up again tomorrow evening.
SiriusHardware is offline  
Old 28th Oct 2020, 9:53 pm   #678
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Mark1960 View Post
If I remember correctly, the difference in chip enable is only an inverter on one address line. If only one ram block shows the issue it might be pointing at the delay in this inverter, or the input switching threshold compared to switching threshold of the other ram chip.
The RAM chips have 2 chip enables, CE1 = /(A8.A9.A11) CE2=A10 on one bank and /A10 on the other
Slothie is offline  
Old 28th Oct 2020, 9:59 pm   #679
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

If you think A8 is the significant address line, does that mean we can initially rule out _CE2 (driven by A10) and concentrate on _CE1 on the affected RAM bank?
SiriusHardware is offline  
Old 28th Oct 2020, 10:44 pm   #680
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
If you think A8 is the significant address line, does that mean we can initially rule out _CE2 (driven by A10) and concentrate on _CE1 on the affected RAM bank?
Possibly... the address signals on CE1 go through more gates, hence there is more propagation delay, so if the timng is marginal it will be more obvious there.
Slothie is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 8:43 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


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