beamrider wrote:Perhaps
this analysis of the hardware can add some light to this riddle?
tokra wrote:
Now for the real VIC the result are very different! At value 24 the line below the split looks a little garbled. At value 25 suddenly the same char-line starts with a lower char (Y instead of Z). At value 26 it even skips to start with W! At least the blank line appears at the some position as in VICE at value 26. Position 27 starts with V, and then at position 28 it suddenly jumps to the pound-sign just to go back to S at position 29. It continues to skip a character or two back which each next step, until suddenly at position 36 all bets are off, as it seems to jump FORWARD about 140 chars, just to go back at position 37. The next jump like that is at position 52 (36+16), until finally with position 68 (36+16+16) finally the real machine catches up with VICE and from then on they look the same.
I've read the posts in this topic a number of times over recent months and thought quite a bit about it. There appear to be a number of different peculiarities mentioned. I can confirm that having run tokra's test program on my real PAL VIC 20, I see exactly the same thing on my screen for each position as the images that tokra posted on his site.
I thought I'd pick up on one of the phenomena today, because it appears that something like it can easily be reproduced using a simple BASIC program that moves the text window to the right until the right edge starts moving off the end of the raster line:
https://sites.google.com/site/mos6561vi ... arflow.d64
The program is very similar to tokra's asm program, except that it is BASIC and it doesn't have the raster split. If you hit the space bar, it moves one position (half character) to the right. If you hit X it will exit the program. Now if you try running this in VICE versus a real PAL machine, you'll notice that it behaves differently when the right edge of the text window moves beyond the end of the raster line. In VICE the characters displayed in the text window remain static in their screen positions, but on a real machine the characters start moving around. Most of the time they appear to wrap down on to the next text line.
The same effect can be achieved by simply listing a program listing on screen and then POKEing 36864 with a value that puts the text window right edge beyond the end of the raster line.
I think it has got something to do with the WITHIN MATRIX' signal that controls the increment enable of both the Video Matrix Counter and the Horizontal Cell Counter. That WITHIN MATRIX' signal is only active (i.e. LOW, which is the value of this signal line that enables those two counters to increment) when the current X/Y position is within the text window. The logic for determining the right edge of the text window is not only checking for when the Horizontal Cell down counter reaches 0, but also if it has reached the end of the line (i.e. start of the next line). When this happens on the first seven lines of a character, the Video Matrix Counter reloads the value it had at the start of the text line from it's latch. But after the 8th line of a character (or the 16th if it is double height), it stores the current Video Matrix Counter value in the latch rather than reloading the previous value. Now since some half columns have started moving beyond the end of the raster line, the Video Matrix Counter never incremented for those half columns, and so the value stored in the latch is not equal to the previous value plus the full width of the text window. Instead it is the previous value plus the number of half columns that it counted at the point that it reached the end of the line. So rather than getting 22 columns of text on a text line, you might start getting only 21 and the 22nd character then moves down to the next line because the text window has actually become narrower than what the number of columns register says it should be. Keep in mind that it moves in half characters, so as it moves more and more beyond the end of the raster line, the text window width is shrinking in half characters, i.e. 22, 21.5, 21, 20.5, etc. A character on the first line of text seems to wrap down to the next line only every two half character movements to the right. But this has an accumulative effect as you move down each text line. The character at the start of the second text line changes every second tap of the space bar, but the character at the start of the third text line changes on every tap of the space bar.
Similar to what tokra observed, for certain values of $9000 it behaves rather strangely and seems not to follow the character wrapping behaviour mentioned above. That is the second of the phenomena that tokra discovered and quite frankly I'm at a loss at the moment to explain that one.
I'd be very keen to see how the CHARFLOW BASIC program behaves on people's real machines. On my machine I seem to be getting some strange interaction between the key press and the value that gets stored in $9000, i.e. the value that ends up being put into $9000 is sometimes not what I POKEd but instead some random value. So I've got a tweaked version of this program that has a small delay between the keypress and the POKE. That seems to fix my issue. I suspect it is only my machine and that others won't see this. It is a bit of a worry actually, i.e. that keypresses on my machine can affect what gets put into memory locations.
Now, to really mess your screen up, try directly in BASIC simply POKEing some values 24 and above into 36864:
POKE 36864,24
POKE 36864,28
POKE 36864,38
POKE 36864,40
POKE 36864,44
POKE 36864,52
Pretty harmless in VICE, but causes havoc in the real machine.