Multiple screen memory areas ?

Basic and Machine Language

Moderator: Moderators

Post Reply
User avatar
majikeyric
Vic 20 Afficionado
Posts: 349
Joined: Fri Oct 24, 2014 2:08 pm
Website: http://majikeyric.free.fr
Location: France

Multiple screen memory areas ?

Post by majikeyric »

Hi,

I have started diving into the technical specs of the VIC20,

is there a way to have more than one screen memory area ?

we can have several charsets but what about screen matrix ?

that would be to have a double buffer for screen manipulations.

Thanks.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Multiple screen memory areas ?

Post by Mike »

The screen base address is controlled by the upper four bits of register 36869 and the top bit of register 36866 in the VIC, in steps of 512 bytes.

The colour RAM always shares the bottom 10 address bits and anyway has a capacity of 1K nibbles only (at $9400..$97FF). So, for double buffering you are restricted to a maximum screen size of 512 bytes if you want independent colour RAM for the two pages; furthermore the screen RAM base address must leave 0 as remainder for one page and 512 as remainder for the other page when divided by 1024.

One possible scenario is:

POKE36869,239 -> screen RAM at either $1800 or $1A00, character set at $1C00

and then:

POKE36866,22+0 -> screen RAM at $1800, colour RAM at $9400, or
POKE36866,22+128 -> screen RAM at $1A00, colour RAM at $9600.

The "22" in the lower 7 bits of 36866 are the displayed character columns.

Once again: only internal RAM and the character ROM are accessible by the VIC chip!
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Multiple screen memory areas ?

Post by beamrider »

Mike wrote:The screen base address is controlled by the upper four bits of register 36869 and the top bit of register 36866 in the VIC, in steps of 512 bytes.

The colour RAM always shares the bottom 10 address bits and anyway has a capacity of 1K nibbles only (at $9400..$97FF). So, for double buffering you are restricted to a maximum screen size of 512 bytes if you want independent colour RAM for the two pages; furthermore the screen RAM base address must leave 0 as remainder for one page and 512 as remainder for the other page when divided by 1024.
Excellent. I had [wrongly] assumed double buffering was out of the question for large screen geometry. However for games that may use quad colour multi-colour and static color ram as per this thread, double buffering would seem to be on the table.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Multiple screen memory areas ?

Post by Mike »

beamrider wrote:Excellent. I had [wrongly] assumed double buffering was out of the question for large screen geometry. However for games that may use quad colour multi-colour and static color ram as per this thread, double buffering would seem to be on the table.
Indeed. If you can live with a shared colour RAM, screen page 1 at $1000, screen page 2 at $1400 and a complete 8x8 character set from $1800 to $1FFF is a possible scenario, with:

POKE36869,206 -> screen RAM at $1000, (colour RAM at $9400), character set at $1800
POKE36869,222 -> screen RAM at $1400, (colour RAM at $9400), character set at $1800

and the top bit of 36866 cleared. The whole 1K of those two screen pages is fully accessible by VIC.
User avatar
majikeyric
Vic 20 Afficionado
Posts: 349
Joined: Fri Oct 24, 2014 2:08 pm
Website: http://majikeyric.free.fr
Location: France

Re: Multiple screen memory areas ?

Post by majikeyric »

Thanks Mike ! (again :lol: ),

When reading the VIC20 PRG, I was wrongly thinking that theses bits (composing the screen address) dispatched into $9002 and $9005 were read-only.
But with your explanation and by reading : "Mapping The VIC", now I have understood :D


I have seen some very nice VIC20 demos effects but which VIC20 games are technically very advanced ?
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Multiple screen memory areas ?

Post by Mike »

majikeyric wrote:I have seen some very nice VIC20 demos effects but which VIC20 games are technically very advanced ?
The so-called demo-scene hasn't contributed much to explore the capabilities of the VIC-20 after 'Robotic Liberation' was released by PwP in 2003. Maybe 'going lowres' from TRSI, released in 2010, deserves a honorable mention because of its clean design.

I suppose you already know, that most effects in demos do not transfer well into a game environment. Externally, games are much more dependent on good gameplay, and internally it is necessary that several dozen routines play nice with each other. That doesn't exclude well executed graphics engines and sound effects.

In the Announcement section you should be able to find quite some pearls in the threads about Software releases.

Welcome to the shark pool! :mrgreen:
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: Multiple screen memory areas ?

Post by darkatx »

Man, this is why I love this place...I was porting over my unexpanded routine into 8K+ expansion and totally got lost. Took this place to make me remember the basics!
Thanks guys!
Learning all the time... :)
4matdemoscene
Vic 20 Newbie
Posts: 8
Joined: Sat May 16, 2015 4:14 pm
Website: http://www.atebit.org/
Location: UK
Occupation: Coder/Musician

Re: Multiple screen memory areas ?

Post by 4matdemoscene »

Mike wrote:The so-called demo-scene hasn't contributed much to explore the capabilities of the VIC-20 after 'Robotic Liberation' was released by PwP in 2003.
No, of course it hasn't(!) ;)

Actually there's also a bunch of stuff you can do with $9002 to repeat lines of the screen, even have different ink/multicolour/single colour in the same character if you don't mind scanlines. I used that myself in the end part of this, the screen is one character high and you have different ink colours every visible charline.
User avatar
pixel
Vic 20 Scientist
Posts: 1328
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: Multiple screen memory areas ?

Post by pixel »

4matdemoscene wrote:
Mike wrote:The so-called demo-scene hasn't contributed much to explore the capabilities of the VIC-20 after 'Robotic Liberation' was released by PwP in 2003.
No, of course it hasn't(!) ;)

Actually there's also a bunch of stuff you can do with $9002 to repeat lines of the screen, even have different ink/multicolour/single colour in the same character if you don't mind scanlines. I used that myself in the end part of this, the screen is one character high and you have different ink colours every visible charline.
True. But still: the best stuff came out ages ago. :( I'm glad you made it here! Welcome!! :D

It's nice to be a piranha in a shark pool, btw. ;)
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: Multiple screen memory areas ?

Post by tokra »

4matdemoscene wrote:Actually there's also a bunch of stuff you can do with $9002 to repeat lines of the screen, even have different ink/multicolour/single colour in the same character if you don't mind scanlines. I used that myself in the end part of this, the screen is one character high and you have different ink colours every visible charline.
Very interesting! I did not think it was possible to have the screen only one character high, after reading the vic6561-emulation file in the VICE sourceforge. I see by looking at your code I must have been wrong.

Is the trick to set $9002 to 0 before the displayed rasterline ends? So that way the rasterline does not finish and as such the y-counter (and the row-counter) are not increased, and when you then re-set $9002 to 28 it means the same line is being re-displayed (while you changed the color-ram in between)?

I'm wondering if the opposite might be possible -> have the y-counter increase twice per rasterline by letting it finish display a screen area and then open another 1 character wide small area further to the right by setting $9002 to 1 and $9000 to a value where the raster-beam has not been yet. That way you could have the row-counter increase earlier leading to a character height of only 4.
User avatar
pixel
Vic 20 Scientist
Posts: 1328
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: Multiple screen memory areas ?

Post by pixel »

In matters of $9002 I'm also wondering how on earth the VIC would truncate the number of columns to 27 and why there are enough bits for 128 columns. 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? Just a funny gut feeling there…
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Multiple screen memory areas ?

Post by Mike »

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.
User avatar
pixel
Vic 20 Scientist
Posts: 1328
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: Multiple screen memory areas ?

Post by pixel »

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.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
pixel
Vic 20 Scientist
Posts: 1328
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: Multiple screen memory areas ?

Post by pixel »

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!? :wink: 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.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
Post Reply