Denial

pixel wrote:In matters of $9002 I'm also wondering how on earth the VIC would truncate the number of columns to 27

It doesn't. On NTSC, values up to 31 and on PAL, up to 32 work.

and why there are enough bits for 128 columns.

<shrug>Maybe because they didn't find any other use for the single bit 6 (with value 64)?</shrug>

What would that look like in hardware? Mustn't there be latches loaded with the screen/color pointers to (re)set them for each character line to avoid adding or subtracting anything?

Nearly spot on.

- there is the screen base address, the bottom 10 address bits which are shared with the colour RAM base address,
- there is a 10 bit wide offset into the text screen, which is added to the screen base for each character fetch,
- at the beginning of a new text line, the current offset is latched,
- before characters are displayed, the number of columns to display is loaded into a counter ("remaining columns") from the bottom bits of $9002,
- the offset into the text screen is incremented after each character fetch, the remaining columns are decremented,
- when is number of remaining columns reaches 0, the right border activates,
- if the next line is not the beginning of a new text line, the text offset is reloaded from the latch.

All these actions happen in certain single cycles during the horizontal raster sweep, so it's quite possible to produce funny effects when $9000..$9003 are changed at defined positions.

tokra's 104x256 FLI mode, for example, changes the number of columns from 13 to 16 after the first 4 pixel rows of a text line, for reasons explained in a more detailed way in the corresponding thread. The text offset pointer then runs like this: 0..12 (4 times), 0..15 (4x), 16..28, 16..31, 32..44, 32..47 ...and so on.

Some old documentation said it would truncate at 27 – even wrote that into the Wiki, I'm afraid.

Mike wrote:Nearly spot on.

I'm a fan of brevity. A friend of mine bought me an FPGA development board, so I would design chips for him. Had nothing better to do than to start designing something 656x-compatible to get my head in. Don't tell him.

Mike wrote: All these actions happen in certain single cycles during the horizontal raster sweep, so it's quite possible to produce funny effects when $9000..$9003 are changed at defined positions.

tokra's 104x256 FLI mode, for example, changes the number of columns from 13 to 16 after the first 4 pixel rows of a text line, for reasons explained in a more detailed way in the corresponding thread. The text offset pointer then runs like this: 0..12 (4 times), 0..15 (4x), 16..28, 16..31, 32..44, 32..47 ...and so on.

You guys are amazing! Wish you'd update the Wiki more often. Some trick to blank the first or last couple of lines to clip hardware scrolls would be awesome.

Mike wrote: tokra's 104x256 FLI mode, for example, changes the number of columns from 13 to 16 after the first 4 pixel rows of a text line, for reasons explained in a more detailed way in the corresponding thread. The text offset pointer then runs like this: 0..12 (4 times), 0..15 (4x), 16..28, 16..31, 32..44, 32..47 ...and so on.

Dude! Are you having this kind of abstract/logic clarity all bloody day? Is there a name for it!? Gotta read this within the first five minutes after I woke up in the morning and I might be lucky understanding everything without spending hours on getting it all together. Already got water in my eyes reading this halfway through.