Raster split and $9002

[pixel]

We need a "VIC raster explorer"…

Sounds like your next project

Well, would be exciting but the next thing, I guess, is a finished Ultimem filemenu. Wanna get really busy with the retro tape manufacture.

[Mike]

(are you listening, Mike?)

Yes.

...



(... > off to continue with the new raster paper ... )

[beamrider]

Ok some progress...

Thanks to the discovery by Tokra that position 68 gives identical behaviour on the real h/w and VICE - I have modified my code to achieve a stable result on both using this value. I've also eliminated the artefacts present above the lettering in ex4 (real h/w) by setting that line of the color RAM to the same colour as the background within the 1st raster split and then restoring it to the colour needed for the scrolling region in the VBI

I now just need to work out how to get more lines of text without flickering, although two would provide a bare minimum of information for some games if this proves impossible.

See attached ex6..(btw there's no screen jitter during scrolling on real h/w for those that only have VICE, just a small hiccup on direction change due to a bug/defficiency in my code)

btw, you can also increase[6]/decrease[4]/reset[2] the black bar raster timing delay on this version using the keyboard.

[groepaz]

i have slightly edited tokras test program and added it to the VICE testrepo here

[beamrider]

Perhaps this analysis of the hardware can add some light to this riddle?

[lance.ewing]

Perhaps this analysis of the hardware can add some light to this riddle?

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.

[tokra]

Thanks so much for the new test-program! Simpler tests are always better to get to the bottom of the effects. I can confirm that my VIC shows the same strange display with the values you mentioned at the end of your post. I've tried the program with a smaller screen (POKE 36866,11+128). The effect starts later then (of course). So it has something to do with the end of the raster-line for sure. Whether some useful effect can be accomplished with this behaviour remains to be seen.

[tokra]

I've investigated this a little today, looking for the position the corruption starts in regards to the $9002-value. These are my measured values:

Code: Select all

$9002	Corruption $9000	
	PAL	NTSC
 1	66	60
 2	64	58
 3	62	56
 4	60	54
 5	58	52
 6	56	50
 7	54	48
 8	52	46
 9	50	44
10	48	42
11	46	40
12	44	38
13	42	36
14	40	34
15	38	32
16	36	30
17	34	28
18	32	26
19	30	24
20	28	22
21	26	20
22	24	18
23	22	16
24	20	14
25	18	12
26	16	10
27	14	 8
28	12	 6
29	10	 4
30	 8	 2
31	 6	 0

This gives a general formula of:

(32*$9002-value)*2+4 for PAL
(32*$9002-value)*2-2 for NTSC

Interestingly there is a difference on what kind of corruption appears. Most times it is really bad with the values above, but higher values for $9000 often produce a more sensible picture. The most interesting effect is that the y-counter seems to jump to the next char-line at some values, meaning it should be possible to have other char-heights than 8 or 16 with this method, which could possible allow for wider-FLI-graphic-modes than 13 chars. If this proves true I feel a new part of the the "New Frontiers in VIC-Hires-Graphics Series" coming up

[tokra]

According to https://sourceforge.net/p/vice-emu/code ... lation.txt
"A rasterline starts (the horizontal flipflop opens) in cycle n if it hasn't already started and n is stored to $9000 in cycle n or earlier [...]".
Also displaying each char takes 2 cycles.

By this we can calculate the raster-position that leads to the corruption. E.g for PAL if $9000 is 24 and $9002 is 22 this means raster-position 24+22*2 = 68. In fact it is ALWAYS raster-position 68 when the corruption first shows for PAL and always raster-position 62 for NTSC. As NTSC has 6 cycles less than PAL (65 instead of 71) this makes perfect sense. So, something happens with the VIC when it can not finish the rasterline by cycle 68 for PAL or 62 for NTSC.

[beamrider]

Interesting. Yes 68 is the value I settled on for my split screen pixel scroller (WIP).

Would be nice to get a full explanation of this someday.

[beamrider]

I guess we never got to the bottom of this?

[tokra]

Once again here is the charflow-testprogram by Lance since the link above is dead.

In fact since the program is so small and simple here's the source as well:

Code: Select all

10 c=11
20 for a=0 to 255
30 poke 38400+a,0
40 poke 38656+a,0
50 poke 7680+a,a
60 poke 7936+a,a
70 next a
80 c=c+1
90 poke 36864,c
100 poke 7680,c
110 get b$
120 if b$=" " goto 80
130 if b$="x" goto150
140 goto 110
150 poke 36864,12
160 print chr$(147)
170 end

[mathop]

Noticed this thread just now. I'll try the charflow.prg bit later.
Also this might be related:
https://youtu.be/ct8Ulc80qk8

[tokra]

Yes, this is most definitely the same effect.

I just found that back in 2018, Mike and I discussed this and I adapted/improved the test-program by Lance to better analyze the problem. Try the attached D64. Should work with or without expansion.

It basically fills the screen with chars 0-255 and each char itself has been redefined so that each line is its own value. So the first char only has the rightmost column set and char 255 has all columns set. Also I used four different colours to better distinguish the chars from each other.

You can use the cursors-keys left/right for $9000 and up/down for $9002 - you can flip the charset with "C" and leave the program with "X" after which it will show the final values of $9000/$9002.

Hope this helps solve the mystery

[mathop]

I believe this has to do with the way the VM counter is implemented on the chip, where there are additional carry circuits for each group of 4 bits.
When the display is still active at the start of the line (or end of the line, depending on how you look at it) the carry line(s) may be triggered by mistake.

The VIC has a 12-bit VM counter, which I will also refer to by just VM.
At the start of each line VM is loaded with a base value from a register, say, VB.
Then, depending on the horizontal offset, sx, ($9000), VM will increase steadily, starting at some X position, for 2*m cycles, where m is the 'horizontal size' register ($9002), or until the start of the next line, whichever occurs earlier.
Also during the last line of each character row (normally this would be the 8th line) VM is saved into VB, so VB will essentially increase by 2*m at each row of characters.

The problem occurs when the display is still active at the start of the next line.
For PAL VICs this would be for example when sx=24 and m=22.

If, at the start of the next line, any of the lower 4 bits of VM are not zero, everything is as normal. That means that the next value of VM will just be VB. Note that VB will also have increased if the previous line was the last line of the character.
If the lower 4 bits of the VM counter are all zero at the start of the next line, but any of the middle 4 bits are not zero, then VM will be reset to VB+$10
If the lower 8 bits of the VM counter are all zero, then VM will become VB+$100.

As an example: take sx=24, m=22.
Then VM will run through these values

Code: Select all

$000..$02C (8 lines)

$02C..$058 (8 lines)

$058..$084 (8 lines)

$084..$0B0 (1 line)
$094..$0C0 (7 lines)

$0D0..$0FC (1 line)
$0C0..$0EC (7 lines)

$0EC..$118 (8 lines)

$118..$144 (8 lines)

$144..$170 (1 line)
$154..$180 (7 lines)

$190..$1BC (1 line)
$180..$1AC (7 lines)

$1AC..$1D8 (8 lines)

$1D8..$204 (8 lines)

$204..$230 (1 line)
$214..$240 (7 lines)

$250..$27C (1 line)
$240..$26C (7 lines)

$26C..$298 (8 lines)

$298..$2C4 (8 lines)

$2C4..$2F0 (1 line)
$2D4..$300 (1 line)
$3D4..$400 (6 lines)

$500..$52C (1 line)
$400..$42C (7 lines)

$42C..$458 (8 lines)

etc.