UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio 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.

Reply
 
Thread Tools
Old 26th Oct 2020, 10:39 pm   #641
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Possibly the first example of a 'cheat mode' in a game?

Quote:
That is great news
Hmm, you seem pleased by odd things but I guess you mean you're glad it's not only you seeing these problems.

I'm just about to have a go to scope NENIN vs. NWDS with Minefield running to try to get an idea of the relative timing of MK14 NWDS pulses vs. OrVw NWDS pulses. The assumption is going to be that any NWDS within the NENIN high period are from OrVw and any outside the NENIN high period are the SC/MP. The main thing is to see how close together they ever get.

I could probably get a steadier signal to look at by writing a small program which just writes the same data to the same screen location over and over again - being compact it might take a bit longer for the random corruption to damage it and give me more time to look around - a bit like 'Battleships' - always easier to score a random hit on a big ship than a small one.
SiriusHardware is offline   Reply With Quote
Old 26th Oct 2020, 10:45 pm   #642
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 677
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Possibly the first example of a 'cheat mode' in a game?

Quote:
That is great news
Hmm, you seem pleased by odd things but I guess you mean you're glad it's not only you seeing these problems.

I'm just about to have a go to scope NENIN vs. NWDS with Minefield running to try to get an idea of the relative timing of MK14 NWDS pulses vs. OrVw NWDS pulses. The assumption is going to be that any NWDS within the NENIN high period are from OrVw and any outside the NENIN high period are the SC/MP. The main thing is to see how close together they ever get.

I could probably get a steadier signal to look at by writing a small program which just writes the same data to the same screen location over and over again - being compact it might take a bit longer for the random corruption to damage it and give me more time to look around - a bit like 'Battleships' - always easier to score a random hit on a big ship than a small one.
Actually that was why I suggested the 10K resistor on NWDS as if your CHARSET behaves the same as me you will see the failed memory write on a regular basis but CHARSET does not corrupt as it reliably just puts the two copies of the character (mostly barring bit 6 and 7 corruption) into the BC and FC memory range and does not seem to affect the 8154 memory where it runs.
Timbucus is online now   Reply With Quote
Old 26th Oct 2020, 10:48 pm   #643
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 677
Default Re: Mk14 vdu

I have an early start in the office otherwise I would have looked at a collision detector of an AND gate for NWDS and NENIN triggering a single shot 555 so I could see the longer pulses on my little handheld.

Instead I am focusing on putting my JMP back together and restoring all the swapped chips to the correct place.
Timbucus is online now   Reply With Quote
Old 26th Oct 2020, 10:54 pm   #644
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Quote:
MK14 NWDS pulses vs. OrVw NWDS pulses
What am I saying? There are no OrVw NWDS pulses! Just have to look at the proximity of OrVw NENIN to SC/MP NWDS pulses I guess.

Last edited by SiriusHardware; 26th Oct 2020 at 11:01 pm.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 12:47 am   #645
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Some more captures:

Images 1,2,3 OrtonView NENIN vs. SC/MP NWDS, the third image showing that the VDU does not mind where or at what stage in the cycle it interrupts the SC/MP.

Image 4, already seen image of SOC VDU NENIN vs. A0, showing the VDU asserting NENIN, waiting about 16uS then activating the address bus and scanning through 16 addresses (one line) and reading them before releasing NENIN.

Image 5, the closest equivalent from OrtonView, again NENIN Vs. A0 - here we see that OrVw asserts NENIN for much shorter periods and reads perhaps 2 addresses (one even, one odd?) per NENIN pulse, with the address bus being asserted about 8-9 uS after the rising edge of NENIN. The activity on A0 to the right of the second NENIN pulse is the A0 line being driven by the SC/MP, not the VDU.
Attached Thumbnails
Click image for larger version

Name:	OrVw_Nenin_and_NWDS_1.jpg
Views:	8
Size:	87.8 KB
ID:	218963   Click image for larger version

Name:	OrVw_NENIN_and_NWDS_2.jpg
Views:	6
Size:	86.1 KB
ID:	218964   Click image for larger version

Name:	OrVw_NENIN_and_NWDS_3.jpg
Views:	13
Size:	88.8 KB
ID:	218965   Click image for larger version

Name:	SOC_VDU_NENIN_A0_1_Line.jpg
Views:	17
Size:	92.6 KB
ID:	218966   Click image for larger version

Name:	Orview_NENIN_and_A0.jpg
Views:	18
Size:	93.5 KB
ID:	218968  

SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 11:27 am   #646
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

With the exception of image #4 above the captures were all taken with MK14 + OrtonView, the MK14 running charset, NWDS at its normal value of 4K7. The default timing values have the 'rotating' character rolling slowly enough to see the individual characters but this meant that there were relatively few NWDS pulses vs. a lot of NENIN pulses making it hard to find a NWDS pulse to capture.

I therefore reduced the loop DLY value from FF (as original) to '01' and that sped up the rate of change of the 'rolling' character and therefore the write repetition rate.

As it was running I noticed that the character underneath the 'M' of 'Timbucus' was changing occasionally - not completely randomly, only through a small selection of characters including Underline, Space, and Forward-Slash.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 12:08 pm   #647
Slothie
Heptode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 574
Default Re: Mk14 vdu

I don't know how Karen has designed her code, but it seems strange that its reading a couple of characters at a time per NENIN. At first I thought that was it reading the config bits but of course that doesn't happen over the bus. I really must take a closer look at the code...
Slothie is online now   Reply With Quote
Old 27th Oct 2020, 12:16 pm   #648
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Originally she held NENIN high most of the time but that was why the original firmware caused such a massive system slowdown, so in the optimised version NENIN is allowed to return low whenever it reasonably can, with impressive results in terms of system speed up. The current version of firmware slows the system down slightly LESS than the original SOC VDU.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 2:14 pm   #649
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 677
Default Re: Mk14 vdu

Of course with a 4.7k capture you will likely not see the actual event where a corrupt write happens - I do not have the code with me in work but I wonder if the byte you see changing is the current character as I think that is written to a variable?

I think though that the captures are good evidence that the speed up gains are at the cost of the address bus changing before NWDS has gone fully high which the SOC VDU seems to have a guard delay on if not by design but it is there so supports the working theory
Timbucus is online now   Reply With Quote
Old 27th Oct 2020, 4:12 pm   #650
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Can't be the current character as that is changing at the rate of a zillion per second with the reduced timing delay, but the character below the 'M' in your name only changes maybe from one minute to the next. I think that's an unintentional change but I will have another look at it.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 6:27 pm   #651
Mark1960
Pentode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 127
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Can't be the current character as that is changing at the rate of a zillion per second with the reduced timing delay, but the character below the 'M' in your name only changes maybe from one minute to the next. I think that's an unintentional change but I will have another look at it.
Is there a relationship between the address of the rolling character and the address that is randomly changing?

Is the random changing character random or related to the rolling character?

Maybe repeatedly writing the same character or changing the address of the rolling character could find some clue.

Is it possible to capture NWDS with trigger from falling edge to see if and how much it can be shortened? Also wondering if it goes straight to floating when shortened, but pulled high at the end of a completed cycle.

I find the level of A0 in the scope traces a bit disturbing as it seems to float somewhere at neither high or low when the SC/MP is not driving it, but occasionally is pulled low for very short periods that look too short to be a bus cycle. Could be nothing to do with this problem though.
Mark1960 is online now   Reply With Quote
Old 27th Oct 2020, 7:12 pm   #652
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 677
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Can't be the current character as that is changing at the rate of a zillion per second with the reduced timing delay, but the character below the 'M' in your name only changes maybe from one minute to the next. I think that's an unintentional change but I will have another look at it.
Indeed just checked there is only one store instruction - I have done the same test and nothing else is changing for me onscreen even with no DLY so it seems that is your marginal effect.

That effect gets worse when you use a 10K resistor (and appears to be the same area of the screen as me so I was pleased you get almost or the same effect) - that even shows the double write of both RAM's accepting the data as CS must be changing as well so they both act on the corrupted address (in the range of the real one it seems) to action the low NWDS and get mostly the correct data from the data bus - as of course the VDU does not affect that as it is expecting to only read the bus once the memory chips drive it.

This is consistent with the correct data being written to the wrong location. I.e. your pattern of Valid characters is the pulse pattern where the write goes wrong and occurs on the same characters as of course the timing for their appearance is very precise.

MINEFIELD stores its variable near the start of its code so is highly likely to corrupt itself - for me that happened a lot after level 2 which is where the code is self modified to increase the speed.
Timbucus is online now   Reply With Quote
Old 27th Oct 2020, 7:25 pm   #653
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Picking up on something that Mark said about the ropey appearance of the A0 line, I agree, so I'm wondering if the PIC inputs in 'Tristate' (input) mode are actually loading the address bus to some significant degree.

You'll remember that Karen intentionally swapped over the 'B' and 'D' ports to make sure that the TTL-compatible PORTB would be handling the data bus, but the PIC port pins being used to output the address (in output mode) and to 'disappear' off the address bus (in input mode) may actually be having some unwanted effect on the levels on the address bus when they are switched to input mode.

I'll scope A0 (1) With OrVw attached but inactive and and (2) with OrVw not connected at all to see if that makes any significant difference to the appearance / levels of the A0 line.

You could try that as well Tim, your scope would easily handle that I think.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 7:42 pm   #654
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

By the way Tim, you seemed to be saying that you were going to try a range of values for the NWDS pullup - you appear quite sure that increasing that value is likely to make things worse, so did you try the logical opposite and try reducing the value of the pullup, since, up to a point, that should make NWDS rise / recover faster when released by whatever had it pulled low.

Obviously there's a limit to how low that resistance can go, too low and NWDS on the SC/MP will struggle to pull the line low when it needs to.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 8:10 pm   #655
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 677
Default Re: Mk14 vdu

Yes my first test was downwards to 2.3K or so with 2x4.7K in parallel - the machine was no different so I assume the rise time was not improved by much. I did not try any lower but, I suppose I could try as low as 1K easily and see if it helps Minefield which is the only thing that crashes now for me.

The Address line is quite noisy - I can see the higher 5v pulses of the PIC (which are regular enough I can use as a trigger lock - there does seem to be the same 1v rise effect you get - it is harder to make out with the OrtonView off as the trigger is less precise but I would say it was still there and even if disconnected.
Timbucus is online now   Reply With Quote
Old 27th Oct 2020, 8:19 pm   #656
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 677
Default Re: Mk14 vdu

For those who are interested in Retro devices here is my late 1980's Hameg shots of what A0 looks like sat in SCIOS, the first is with OrtonView on and the 2nd with it off or disconnected which were the same image so I did not photograph it as I was holding the pin probe on Pin 26 of the 8154 to look - I must invest in some IC lead clips for this sort of thing.

Click image for larger version

Name:	IMG_4151.jpg
Views:	15
Size:	49.7 KB
ID:	219052Click image for larger version

Name:	IMG_4152.jpg
Views:	16
Size:	44.0 KB
ID:	219053
Timbucus is online now   Reply With Quote
Old 27th Oct 2020, 8:28 pm   #657
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

Here's my take on the same thing.

Several captures from A0. All at 1V per division, with 0V lined up on the first thin horizontal graticule line.

1) A0 with no VDU attached
2) A0 with OrtonView attached but not active
3) A0 with OrtonView attached and active.

I don't see a great deal of difference between the first and second cases. In the third case the A0 pulses being generated by the OrtonView are self-evident as they are full-amplitude. While it would be nice if the address drive coming out of the SC/MP was equally confident, the fact that it isn't means it is quite easy for us to distinguish signals generated by OrtonView from those generated on the same lines by the SC/MP.
Attached Thumbnails
Click image for larger version

Name:	A0_with_No_VDU.jpg
Views:	12
Size:	96.2 KB
ID:	219054   Click image for larger version

Name:	A0_With_OrVw_Inactive.jpg
Views:	10
Size:	95.1 KB
ID:	219055   Click image for larger version

Name:	A0_With_OrVw_Active.jpg
Views:	13
Size:	87.9 KB
ID:	219056  
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 9:55 pm   #658
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

I'm also running charset again, but I have stripped out everything 'cosmetic' and it now just floods 0F12-0FFE and 0B00-0BFF with 3F, the character code for '?' before looping round continually changing just one character on the screen. Specifically, it writes each successive character code to one location over and over again.

So the character which the program is intentionally modifying many times per second, too fast to see individual characters, is the one held in lower screen address 0B27.

The character which is being occasionally, unintentionally, modified in the upper screen area resides at 0F27. So yes, there is a direct relationship between the address which is intentionally being modified and the address which is unintentionally, and only occasionally being modified.

The range of characters / values which the contents of 0B27 get modified to is relatively small, so far I have seen

Letter 'O' (code=0F)
Underscore (code=1F)
Forward Slash (code=2F)
Much less often, '?' (code = 3F).

So obviously, there is also a relationship between the 'Spurious' characters which are being written to 0F27.

Sometimes it can be a matter of seconds between changes, sometimes minutes.

Next experiment: Move the rolling character to another randomly chosen screen location, 0B31

As you might expect, the location which now changes randomly in the upper screen area is 0F31. The range of 'random' characters has the same small range as before - characters whose codes end in 'F'.
SiriusHardware is offline   Reply With Quote
Old 27th Oct 2020, 10:15 pm   #659
Slothie
Heptode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 574
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
As you might expect, the location which now changes randomly in the upper screen area is 0F31. The range of 'random' characters has the same small range as before - characters whose codes end in 'F'.
Which tells me that when the spurious writes are happening, the data bus is not being driven, as D0-D3 are pulled up to +5v with 1.2k resistors and D4-D7 are just floating. I suppose you could pull up D4-D7 with some resistors to verify this....
Slothie is online now   Reply With Quote
Old 27th Oct 2020, 10:41 pm   #660
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 5,004
Default Re: Mk14 vdu

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?)

Last edited by SiriusHardware; 27th Oct 2020 at 10:49 pm.
SiriusHardware is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 9:00 pm.


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 - 2020, vBulletin Solutions, Inc.
Copyright ©2002 - 2020, Paul Stenning.