Mk14 vdu

[Timbucus]

Well with them all unsoldered and just clipping Graphics/Text to Ground I.e. the default setup of the VDU except PS3 joined to TOPPAGE locally on the VDU I still get the effect.

When I first clipped the Ground lead on to the Graphics/Text pin to switch to Text mode from the default graphics the reverse C appeared on the display in the same place - I could not repeat it despite several tries but, even before when messing around in the monitor it only occasionally appeared but, it would seem to indicate it is the PIC disrupting the memory write function for the display in the monitor which was running at the time I clipped it on and before when poking around in memory as I was modifying the data in the 8154 registers when it appeared.

[Timbucus]

Well - still fiddling decided while they were unhooked to test the other uses of TOPPAGE so here it is connected to INVERT...



and as expected when hooked to the MODE it does split screen text and graphics...



while watching this I noticed that it was possible to observe the bits flipping in the affected byte more clearly than just watching the character and I think if you watch the video what this means is that the D7,D6 and D5 bits are flipping more often... WARNING - juddering as it is on the A model so graphics frames judder.

https://youtu.be/SvyeijODmYc

[Mark1960]

Is there a guard time between setting NENIN to boot the SC/MP off the bus and driving the address on the bus from the vdu?

If the SC/MP is performing a write to memory, I think there should be a hold time on the address to ram to allow the NWDS to return inactive and possibly also a slight hold time after NWDS is high.

[SiriusHardware]

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.

[SiriusHardware]

Forgot to add: Tim, can you give me a description of what is going wrong, where, when you are running MINEFIELD so I can try to reproduce that here now.

[Timbucus]

Wow cross post or what - that had worried me all day why we were different - I decided following Mark's post to take a look at the relative timing on NENIN and NWDS with at least my twin input ability - the machine went bonkers unusable - fiddled for ages but even at X10 and unclipping the probes it was nuts... I noticed the pullup on NWDS I had tapped onto the lead of was a bit bent... went to straighten it and this happened (I wonder if it was already intermittent or a bit higher than rated):



I have put a new 4.7K on there at the moment and the single character corruption in CHARSET is gone - however I am missing the data on the very bottom lines (which I was never sure what it was but, was present on the SOC VDU anyway).

In graphics mode though non of the animated programs run correctly - the static images load and look fine. So I still have an issue.

I had wondered about different ram - I will have a hunt. I will also try a 2.4K pullup to be like yours.

[Timbucus]

Originally Posted by SiriusHardware

Forgot to add: Tim, can you give me a description of what is going wrong, where, when you are running MINEFIELD so I can try to reproduce that here now.

It was crashing on me when playing once I got near the bottom. Running it now I do not have the TANK count display on the screen anymore. So I have different effects now - just trying to be a bit methodical testing - Mark's view that it is an effect of NWDS seems very astute which the stronger pullup may fix - going to try it now.

[SiriusHardware]

Erm, I said that I have extra pullup on NRDS, not on NWDS. Just saying.

[Timbucus]

Originally Posted by SiriusHardware

Erm, I said that I have extra pullup on NRDS, not on NWDS. Just saying.

Noted - thanks I missed that point. I will try anything at the moment but, the issue does seem to be with NWDS maybe.

As I had the scope and probes still laying about I clipped them on NENIN and NWDS and now the Interactive programs seem to run better (FALLMAN/HORSERACE in graphics mode) and the Tanks count is back in MINEFIELD but that goes a bit wrong especially as the tank gets lower down the B00 part of the screen.

Unfortunately I cannot get a good enough lock to see much useful at these frequencies on my scope.

[Karen O]

Mark1960 has a point in post #583.

Were the VDU to assert NENIN part way through a write cycle to screen memory, then that write cycle may be corrupted, resulting in temporary corrupted data in memory. Corrupted data may then show up in the screen display.

When the SC/MP is allowed to resume, the SC/MP will repeat the cycle, complete successfully and restore correct data to memory.

I've tried to think of every trick to get graphics mode working on the same pixel clock as text (as I think that this might stop the juddering).

It is interesting that the juddering is not perfectly random.

If it really does shift or not shift on a frame-by-frame basis then it seems to be aware of the 625 frame rate, which is kinda baffling.


So, the effect of corrupted display data may be an illusion.

[SiriusHardware]

Just to comment on Tim's video in #582, due to the strobing interaction between the TV frame rate and the phone camera refresh rate the video makes the shudder look much slower than it is, basically an electronic equivalent of 'wagon wheel spoke effect' - in reality it is 50 frames per second, with every alternate frame offset a little to the right.

- The video also makes it look as though some pixel lines are more offset than others within a single frame, but that isn't the case either. Taking two successive frames, if the first one has no offset, then in the following frame all the lines in the active screen area are offset a little bit to the right, starting at the right hand edge of the 'bright line'.

Also to reaffirm: This 'shudder' effect only occurs when the PIC is an 877A - the simplest 'cure' is to fit an 877, which makes the problem go away.

And finally, the 'shudder on graphics' effect was not present in the first two versions of firmware posted, even when the PIC was an 877A. In those versions graphics frames were all rendered with the same degree of offset as character screens - no offset.

[Timbucus]

As for Sirius idea for swapping RAM I have just fitted a set of 4 AM9111BPC which are 400ns parts (I previously had the DPC which are 250ns) and I am getting more corruption even on the static images (could be from the PI uploader though as using the older slower script seems less prone). I will tone down the speed a little in the upload script and keep testing - I will put back the non A part as the juddering is getting to me...

[SiriusHardware]

I'm trying to think of a way to prove that the shudder shift is regular and on a frame by frame basis rather than variable, on a line by line basis.

If I draw a test image which just consists of a number of one pixel wide vertical lines, then, if the whole frame is shifting back and forth I would expect that to the naked eye each vertical line would become two equally evenly lit transparent vertical lines lined up against each other.

If, on the other hand, the shudder is occurring semi randomly on a line by line basis then I would expect that both of the vertical side-by-side lines would shimmer like faulty striplights because for any given pixel line, the line might or might not be offset.

I'll prepare or generate such a test image - could be as simple as writing 0x01 to every screen RAM location - and see which effect I get.

[Timbucus]

Originally Posted by Karen O

Mark1960 has a point in post #583.

Were the VDU to assert NENIN part way through a write cycle to screen memory, then that write cycle may be corrupted, resulting in temporary corrupted data in memory. Corrupted data may then show up in the screen display.

When the SC/MP is allowed to resume, the SC/MP will repeat the cycle, complete successfully and restore correct data to memory.

....

So, the effect of corrupted display data may be an illusion.

I do not think it is an illusion as a physical exam of the memory location after a RESET showed the data in the RAM location. Now I have a new pullup on NWDS I have a different effect that does not show up as easily but, it is still a random corruption of memory on write I am sure - the more animation and interactive the program the faster the effect will show up.

I think I will write a character program that just constantly writes the whole visible character set to the top or the bottom with the other side left blank. That should make the corruption visible to the naked eye.

MINEFIELD is the worst (and also the most complex) as using the fire key seems to get it to die quicker than just letting it play itself and burn out tanks.

I think the fact that both Sirius and I see the reverse C in the same place on the 7 segment display is a good sign as we are both getting the same effect in that area of the memory map.



Photo just to make sure it is the same effect Sirius sees.

[SiriusHardware]

I've tried to think of every trick to get graphics mode working on the same pixel clock as text (as I think that this might stop the juddering).

I have no idea how much code memory you have left, but

2 * 256-byte lookup tables

First lookup table contains the high nibble pattern for each possible bit pattern 00000000 through to 11111111
Second lookup table contains the low nibble pattern for each possible bit pattern 00000000 through to 11111111

So the entries at offset A5 (10100101) into the two tables would contain:

Upper nibble table: 11001100
Lower nibble table 00110011

So for a pixel bit pattern of 10100101 the UART would send two bytes

11001100 00110011

at the same higher baud rate as character mode. No idea whether you have the 512 byes of spare code memory or the uP cycles available to do this.

Edit: Of course due to the LSB first nature of UART transmission the tables would need to hold the nibble patterns reversed, just as you already do with the lookup table which holds single byte patterns reversed, and I've just realised you would repurpose that reverse-byte lookup table as one of the reverse-nibble lookup tables, so you'd only need an additional 256-byte reverse-nibble lookup table.

[SiriusHardware]

I'm going to hold off for now until Tim comes up with a definitive list of things which he has tried and wants me to try to replicate because at the moment his symptoms seem to be a bit of a moving target while he experiments.

But, I can confirm that I sometimes see that reverse 'C' shown in the image in #594. Not usually straight away, I tend to notice that it has appeared after a while.

[Timbucus]

Originally Posted by SiriusHardware

I'm going to hold off for now until Tim comes up with a definitive list of things which he has tried and wants me to try to replicate because at the moment his symptoms seem to be a bit of a moving target while he experiments.

But, I can confirm that I sometimes see that reverse 'C' shown in the image in #594. Not usually straight away, I tend to notice that it has appeared after a while.

Sensible move - glad it is the same and I am sure it is caused by the same problem I have a corrupt write. It will appear just sat in SCIOS for me (after a long time) as of course there is an NWDS assertion happening a lot around a fixed group of addresses - I am going to guess that the state of the bits on the address bus that are affected will be consistent due to that sequence which is why it is repeatable.

I was just getting it a lot more often with that dodgy resistor I think - I will put back in the 250ns memory soon to prove they only affect the PI upload rate (as the VDU is off for most of that anyway) and report back. I have slowed down the send14 script for the moment and that has stopped the static corruption on load which seems to evidence that theory.

I also took the opportunity to solder back down all the hanging around bits of wire to the 8154 and get rid of the long black clip jumper I was using to select Graphics and Text. I wondered if they were introducing noise or spurious capacitive effects.

Short runs of all the software seem fine now without spurious data but, I can get MINEFIELD to crash by the second level about 6 mines in - my next step is to put the SOC VDU back on and prove it does not do it there - which I don't think so but, best to double check.

Fixing the resistor is making finding the fault harder as it is becoming more exotic... I will obviously play with values for the NWDS pullup to see if I can get the effect to change - where is my big 10K POT ...

[SiriusHardware]

This is the problem, as the firmware gets closer to perfect, any outstanding issues become correspondingly harder to catch in the act and it is unfortunately then down to us to try to narrow the 'when it happens' to an absolutely specific set of circumstances to give Karen any chance of working it out, since she isn't able to observe the problems at first hand or immediately observe the effect of any changes.

With regard to the Pi uploader, removing that if... statement from 'PressMK14Key()' may have shortened the interval between each key press by a very small amount of time compared to the previous version of the script, which in turn may have increased the keying speed slightly. I think I noticed the same thing and had to raise the delay constants a little bit on the current version of the script, over and above those which had always worked for me on older versions.

[Phil__G]

Originally Posted by Timbucus

... I will obviously play with values for the NWDS pullup to see if I can get the effect to change - where is my big 10K POT ...

...remembering of course that pots go down to zero...
(We've all done it... )

[SiriusHardware]

Indeed, maybe have a 470R in series with the pot just to be on the safe side.

For information, the reverse 'C' character is formed by segment a (=1) + segment b (=2) +segment c (=4 ) + segment d (=8) , in other words a byte value of b0001111 or 0x0F is somehow eventually getting written to that display cell.