Protecting screen memory

[Stormcrow]

I understand how to manipulate the number and position of rows and columns by POKEing around with specific bits in the VIC chip, and how to find the beginning of screen memory.

What I'd like to do is protect two rows on the top and bottom of the screen, leaving the usual 23 rows between then, and POKE titles and status messages into them. I haven't yet figured out how to tell the VIC which screen memory addresses are available. I know you can tell it which page to use with 648, but I don't see how to deal with the available size of screen memory, or how to fine-tune the start address if you've got more than the usual 506 characters showing.

For instance, the title of my program is POKEd into the top. As the text scrolls, it disappears before hitting the title, which never moves. And new text appears on the third-to-last row, leaving room for status messages that also do not scroll.

Any guidance is appreciated. I hope I've made myself clear.

[Mike]

Hi, Stromcrow,

even if you tell the VIC chip to use another number of rows or columns, the screen editor in the BASIC interpreter still refers to the 22x23 layout, it is hardcoded therein all over the place.

The VIC chip can locate the start of screen memory only at multiples of 512 bytes, it takes the relevant information from bits 4..7 of register 36869 and the top bit of 36866. During initialisation, address 648 is merely set in concordance to the VIC register settings.

I'm afraid to tell you, that you'll have to take care by yourself of the screen layout by directly accessing it, preferably in machine language.

You find further information in these two threads: 'Kernel Routines and Arbitary Screen Size' and 'Printing to screen without kernal'.

Greetings,

Michael

[wimoos]

The only thing that you can do is change the number of rows to 24 and use the first 6 positions of that bottom row. They are addressable at positions 506-511 from start of screen.

I ever used those 6 positions to display a clock (hooked some ML into the IRQ routine).

Regards,

Wim,

[Mike]

The only thing that you can do is change the number of rows to 24 and use the first 6 positions of that bottom row. They are addressable at positions 506-511 from start of screen.

That only applies, when the screen is located at 7680, as it is for an unexpanded VIC-20 or with +3K RAM expansion. In that case, the VIC 'jumps' to address 32768 after the first 6 characters in line 24 and accesses the character ROM. For bigger RAM expansions, the screen is relocated to 4096, the screen editor uses the range 4096 to 4601, but of course the RAM beyond that is fully usable for the VIC, and you can add more than one line.

I suppose though Stormcrow was already aware of these things.

I ever used those 6 positions to display a clock (hooked some ML into the IRQ routine).

Like this one?

[wimoos]

I remember sitting in the attic sometime in 1983 writing a similar thing.

[Stormcrow]

For bigger RAM expansions, the screen is relocated to 4096, the screen editor uses the range 4096 to 4601, but of course the RAM beyond that is fully usable for the VIC, and you can add more than one line.

Right. But does that mean that the rows that you can only reach by POKEing must always be on the bottom, when you use addresses beyond 4601? You can't, for instance, shift the 506 (well, 512) addressable locations down a row? Does screen memory always begin at the start of a page? If not, how do you set the low byte of screen memory?

[Mike]

Does screen memory always begin at the start of a page?

As I already wrote above, the base address of screen memory can only be located at multiples of 512 bytes. The screen editor always places the first editable line at this base address.

Any deviation from the standard screen layout, which should also be usable for BASIC programs (especially the PRINT command) requires someone to re-implement the screen editor. A windowing technique like it is available with the C16, C116, Plus/4 or C128 could be used to protect screen contents outside the window from being overwritten, cleared or scrolled, but that requires even more code.

A more practical solution for most programs just does direct access to screen memory without any aspiration to redo the whole screen editor code.

[Stormcrow]

Got it. Use the screen editor, or use machine language; don't try to use the screen editor at all if you're going beyond its two-byte range.

Thanks!