26th Oct 2020, 10:39 pm | #641 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Possibly the first example of a 'cheat mode' in a game?
Quote:
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. |
|
26th Oct 2020, 10:45 pm | #642 | ||
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
|
||
26th Oct 2020, 10:48 pm | #643 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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. |
26th Oct 2020, 10:54 pm | #644 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Quote:
Last edited by SiriusHardware; 26th Oct 2020 at 11:01 pm. |
|
27th Oct 2020, 12:47 am | #645 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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. |
27th Oct 2020, 11:27 am | #646 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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. |
27th Oct 2020, 12:08 pm | #647 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
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...
|
27th Oct 2020, 12:16 pm | #648 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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.
|
27th Oct 2020, 2:14 pm | #649 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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 |
27th Oct 2020, 4:12 pm | #650 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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.
|
27th Oct 2020, 6:27 pm | #651 | |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
|
Re: Mk14 vdu
Quote:
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. |
|
27th Oct 2020, 7:12 pm | #652 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
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. |
|
27th Oct 2020, 7:25 pm | #653 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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. |
27th Oct 2020, 7:42 pm | #654 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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. |
27th Oct 2020, 8:10 pm | #655 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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. |
27th Oct 2020, 8:19 pm | #656 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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.
|
27th Oct 2020, 8:28 pm | #657 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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. |
27th Oct 2020, 9:55 pm | #658 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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'. |
27th Oct 2020, 10:15 pm | #659 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
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....
|
27th Oct 2020, 10:41 pm | #660 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
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. |