Interleaving screen and attribute memory on the VDC

[nikoniko]

[Warning: I'm just thinking out loud. I haven't tested this idea and am not 100% certain it would work. However, given that the VDC works pretty predictably, I don't see why it wouldn't, so I am 99.4% certain. ]

Normally when we work with screen and attribute memory, we access them as two separate regions. For simplicity's sake, let's consider an 80x25 color text display, where we have a contiguous 2000 bytes for the screen data and another contiguous 2000 bytes for attributes. We can have them start wherever we'd like within VDC, but we keep them separate and they don't overlap. Overlapping probably wouldn't make any sense unless we were going for some really bizarre effect.

But consider a very nifty feature of the VDC: register 27, which controls the address increment per row of characters. It allows us to effectively create a virtual screen area that is wider than the display, so that if we want to scroll left or right all we have to do is increment or decrement the start of screen memory by the number of columns we want to move. Wham, bam, instantaneous panning. (Of course, this won't be smooth unless we also manipulate the smooth scrolling control.) For instance, if we were coding a text editor and wanted to support lines longer than 80 columns, say up to 160 columns, we could set register 27 to 80, then pan across whenever we need to display more of a long line. Definitely easier than the VIC-II where we'd have to write a routine to move memory around.

Well, suppose that instead of considering those extra 80 columns to be screen memory, we did something else with them. Let's say that we set the VDC's attribute area to begin on the first byte of that offscreen memory. Now what have we got? If my musings are correct, we'd end up with screen memory and attribute memory interleaved. We'd have 80 bytes screen, followed by 80 attribute, 80 screen, 80 attribute, and so on. Or if we set register 27 to 240, we'd have 80+240=320 bytes per row, 160 screen followed by 160 attribute, which would allow us to do the same horizontal scrolling described above.

Kinda weird, eh? And maybe very slightly cool. But definitely useless, right? Probably. Can someone here think of an advantage to this organization?

[hydrophilic]

From the CPU side, it doesn't matter too much where you place attributes, in a seperate block or 'interleaved' like you suggest.  It would make a little extra work for the CPU to calculate the address (not much).

On the VDC side, this would be great for vertical scrolling using the block copy feature -- it would (mostly) avoid the ugly artifacts of scrolling the text seperate from the attributes.  Actually for vertical scrolling, the CPU code would be simpler  than issuing a 'copy text', 'copy attribute' pair for all 25 lines (since you can do both at once).

Good idea!

[nikoniko]

Thanks for that insight. Minimizing the time when display elements are mismatched would definitely be a good use for this.

[nikoniko]

EDIT: Umm... this was in reply to Airship's post, which seems to have disappeared.

You could certainly use the space to store a second screen. In order to display the new screen, you'd just increment the screen start address by 80 (or whatever you have the displayed # of columns set to). Most of the time that could be done just by adjusting the low byte, unless your new address crosses a page boundary and requires the high byte to be incremented by one.

[airship]

I realized that what I had said was ignorant, because I'd forgotten that you shove all the VDC commands through a single register. So there's no real advantage to doing this over simply setting a new start-of-memory pointer. D'oh!