Re: Mk14 vdu
I only asked about programmers (Tim) because it seemed possible that your preferred programmer does not always work perfectly which is a bit dangerous - we could end up making Karen waste time looking for a non-existent problem (which is why it's great that there are two of us independently testing, otherwise we might be none the wiser).
On the matter of the horizontal shifting in graphics mode only, brilliant observation thanks Tim - so ultimately if I want to fix that the workaround is just to use a non-A part, but then that offers another mystery - why does the 'A' part not do this when programmed with the original code? Why only in more recent versions?
I went looking for empirical proof of the graphics shifting problem, and here it is:
Image #1 a capture of a single line of the 'inside' image video. The first bright spike after the sync pulse and a bit of black-level is the unavoidable 'white bit' generated when the UART switches on. As this is a frozen image it only shows the line at one of two possible degrees of shift.
Image #2: This is is a close up on the sync pulse and the 'bright line' only, but this time I left the scope running 'live' while I took the shot, and you can now see that the 'bright line' is alternating between two different durations, so we can say for sure that this is the point at which the timing of unshifted graphics frames and shifted graphics diverges, the timing on all frames is identical up to the rising edge of the 'bright line' but on every other frame, for some reason, there is an extra white bit being added on to the right hand side of the bright line. When this happens, the whole line following is shifted to the right by one UART bit duration / half a graphics pixel width.
|