Vic20 5k memory

[johncl]

Hi, pretty new here to the forum. I am a Commodore collector an enthusiast who recently developed Rocket Smash, a Jetpac clone for the C64 (a game that did get a Vic20 release). I have been taking a look at the Vic20 was intrigued by the machines limitations as it also kind of sets a limit to what you can achieve. - I have started a simple RPG game project using text-mode petscii, coding in assembly (using KickAssembler for compiling and running in Vice). Its all going well so far.

My aim is really to see what I can do on an unexpanded Vic20, and from what I have learned it has 5kb of RAM. I know that I can use these areas of the memory:

Code: Select all

0100-01FF    256-511      Processor stack area
033C-03FB    828-1019     Cassette buffer
1000-1DFF   4096-7679     User Basic area (3584 bytes)
1E00-1FFF   7680-8191     Screen memory (512 bytes)

I also wonder if I can basically use most of zero page as well as more of the memory between 0200-0400 or if I need to turn off some features of the Vic20 somehow? I guess the Kernal does use some of this memory for storing e.g. keyboard input and other things? For the C64 you can easily turn off Kernal and basically free up almost all memory for your own programs. If you can turn off the Kernal on the Vic20, I guess I need some alternative way of reading the keyboard then? I see there are lots of memory used by basic which is not needed, but it would be cool if someone has a list of safe memory spots to use. Zero page is of great interest ofc as it also reduces the size of the code if I store most of vars there.

I guess I can use the majority of the stack as it depends on how many subroutine calls I use (including whatever the Kernal does if its active). Atm I see it only affects some 16 bytes at the end (but I think I will reserve at least 32 bytes for actual stack usage).

Screen memory will be used for the screen ofc, I know I can store data there too though as long as they are same colour as the background. - There is only some 6 bytes left at the end.

I have thought about detecting a 3kb expansion (at 0400-0FFF) though (as that is so easy to accommodate due to screen and stuff not being relocated) and load an extra 3kb of data off the tape, perhaps some music + an attract screen with better graphics or something (perhaps using 1kb as charset to make a nice bitmap part). But when I checked the Reference Manual there doesnt seem to be any way of making the Vic see a custom charset at zeroth page? Will be a bit of a hazzle then to get that "optional load" working although I can just flipflop memory contents back and forth between the zeroth page and first.

Also I guess I would need to learn raster interrupts if I want to swap charsets mid-screen. Any pointers to this info that is good? Or do you just add loops that test for raster position?

[Mike]

My aim is really to see what I can do on an unexpanded Vic20, and from what I have learned it has 5kb of RAM. I know that I can use these areas of the memory: [...][/code]

You can use the entire (internal) RAM as long as you would want to program on the bare metal.

The KERNAL and BASIC need most of the zeropage though to operate properly. As the zeropage is necessary for indirect-Y address modes, you'd need at least some addresses in the ZP which aren't used (that often). $FB..$FE and $03..$06 are unused by the OS. Furthermore, there are some addresses shared between tape and RS232 operations. As long as neither of these two operate, you can use those for own programs. They're initialised by the OS to working values as soon as tape or RS232 operations are started, so you don't necessarily have to store the old values away, either.

I also wonder if I can basically use most of zero page as well as more of the memory between 0200-0400 or if I need to turn off some features of the Vic20 somehow?

You can't literally turn off features, rather just not use them.

For the C64 you can easily turn off Kernal and basically free up almost all memory for your own programs. If you can turn off the Kernal on the Vic20, [...]

Simply put, you can't. KERNAL and BASIC are always mapped to $C000..$FFFF on the VIC-20.

Screen memory will be used for the screen ofc, I know I can store data there too though as long as they are same colour as the background. - There is only some 6 bytes left at the end.

Unlike the C64, the VIC in the VIC-20 can change the screen dimensions. So the 506 bytes of the 22x23 screen layout isn't really fixed. And the remaining 6 bytes of the standard setup come handy to display the TI$ clock.

I have thought about detecting a 3kb expansion (at 0400-0FFF) though (as that is so easy to accommodate due to screen and stuff not being relocated) and load an extra 3kb of data off the tape, perhaps some music + an attract screen with better graphics or something (perhaps using 1kb as charset to make a nice bitmap part). [...]

The VIC chip cannot access anything at the expansion port. Especially an external +3K RAM expansion is *not* visible for the VIC. This has been discussed at various places here in the forum.

Also I guess I would need to learn raster interrupts if I want to swap charsets mid-screen. Any pointers to this info that is good? Or do you just add loops that test for raster position?

If you want to do bitmapped graphics, 160x192 is the maximum resolution feasible. This mode uses double-height characters, 'text' screen and character base both mapped to $1000. 240 bytes are used by the text screen, the first usable 'character' is 'P' and the bitmap then starts at $1100. This is the graphics mode implemented by MINIGRAFIK.

Changing the character set mid-screen is only necessary if you want to go beyond that resolution. That has been extensively been featured in the series 'New Frontiers in VIC-Hires-Graphics'.

'Raster' interrupts can be used for other things, though, like changing the background colour register, etc. They are usually set up with VIA timers, and synchronising once to the raster register in the VIC chip. In the thread 'QUIKMAN 2008 for the unexpanded VIC 20' you'll find an example being constructed (and before that, a remark how *not* to synchronise game action with screen refresh, and why).

Finally, there's not anything gained (of fame, etc.) by restricting oneselves to unexpanded RAM on the VIC-20. You can safely assume, that all people still concerned with the VIC-20 do have a memory expansion available. And some things are, if not downright impossible, but at least rather infeasible to implement: like the aforementioned bitmapped graphics. When the display fills up the entire internal memory (save for the OS workspace in $0000 to $03FF) then you have nothing else to put a program - unless you use a RAM expansion.

[johncl]

Thank you for the reply!

About zero page and 0200-0400 RAM, since I never return to Basic, and neither use any IO features I can basically write whatever I want there? I am not familiar with the Kernal really, but I guess it works like you actively need to call those ROM functions in order for the zero page and other areas to mean anything. I guess there are some exceptions though, as I mentioned the keyboard scan routines seems to update zero page $c5 without me actively calling anything in Kernal - so what I need to figure out really is which zero page addresses and others are considered safe.

I know that the Vic20 has some interesting screen resolutions, but I will stick with the plain 22x23 mode now as that works fine for the game.

As for swapping the charset midscreen it would be used for e.g. an attract screen where I use for example 12x10 chars from a 120 custom charset to show some bitmap on the top and then swap to rom chars on the bottom part for credits and stuff. I know I can achieve this by polling the raster ($9004) but from the C64 I am used to setting up raster interrupts to make life easier.

The memory challenge is really there to limit the size of the project as I perfectly know I can expand memory and make insane multiload stuff as well. I find it more challenging to see what I can fit into an unexpanded vic20 than figuring out what to fill memory with in an expanded one, if you get my idea.

[Mike]

As for swapping the charset midscreen it would be used for e.g. an attract screen where I use for example 12x10 chars from a 120 custom charset to show some bitmap on the top and then swap to rom chars on the bottom part for credits and stuff. I know I can achieve this by polling the raster ($9004) but from the C64 I am used to setting up raster interrupts to make life easier.

There's one interesting feature of the VIC architecture, that allows you to mix user defined characters with the non-inverted ROM character set *without* raster interrupts. If you set the character base to $1C00, the non-inverted ROM characters are accessible with the screen codes 128..255 (that's because of an address wrap-around in how the VIC chip 'sees' the built-in memory).

Lots of games for the unexpanded VIC-20 utilise that technique to obtain a set of 64 user defined characters (0..63), though 64..127 overlap with the screen at $1E00. You can relocate the text screen to $1A00, though, and so have the full set of chars 0..127 available.

There are lots of examples of unexpanded programs in the Software Releases threads in the Announcement section. But you might quite as well start off with my Unexpanded Type-In Collection for the VIC-20 for examples.

The memory challenge is really there to limit the size of the project as I perfectly know I can expand memory and make insane multiload stuff as well. I find it more challenging to see what I can fit into an unexpanded vic20 than figuring out what to fill memory with in an expanded one, if you get my idea.

Within that collection, if you enable +24K RAM, you are able to start-up the READ ME, which should give you some hints about my background and reasonings about unexpanded RAM.

[johncl]

Ah, thank you for that tip about the wrap-around feature. Very nice! I might try to squeeze in a small attract screen using 64 custom chars for some more detailed graphics. The game itself have a number of random elements which is nice for generating game map in cassette buffer area and using whatever memory I can below 0400 for dynamic lists and such.

[Kweepa]

To get an idea of what you can do, check out Whack by Aleksi Eeben. It's a Hack clone in 1k. The source code is available.

[johncl]

Yeah, Whack is cool and very well implemented. My ambitions are a bit higher, we'll see how far I get on 5kb.

[orion70]

Higher than Eeben's? Congrats in advance

[johncl]

Hehe, well this has many similarities to classic Rogue but presented differently. Its a one-man party RPG with random (or seeded) regions you travel through, fighting encounters, looting and gearing up your toon to improve stats as well as XP and Leveling. It has a 3D view as well but no map (each level/region is rather small anyway). Still learning as I go although its coded 100% in assembly and I am generally just trying to figure out how much I can squeeze into the unexpanded machine (love this challenge). At first I am focusing on a petscii version, but I have already prototyped large portions of a 64 custom charset that would lift the games appearance considerably so I might make an effort getting that into the unexpanded one as well.

In my "quest for bytes" on an unexpanded vic - I figured there are 512 nibbles in color memory that can be used as I realized there were in fact two "pages" of nibbles ($9400 and $9600). Those can be e.g. used for a 4x8 font like the one Mike shown somewhere else on this forum and indeed use in many of his creations (although using color ram would require shifting - which would be a bit slower ofc than the double ones). I might use that to present some kind of story or even instructions, although ingame I will use standard ROM font. But perhaps I find better use for these nibbles.

Sorry if my posts seem rather noobish, its a new architecture for me and on the C64 I sort of never worried that much about memory as I do on the Vic20 for natural reasons.

I tested moving the screen page to $0200 which also could work for some screens, like an attract screen, as long as I stay out of the keyboard memory stuff at least - messing with those locked up the emulator at least (can make these not show by setting them to bg color in color memory). The basic buffer at the start is definitely memory I could use and naturally most of the bottom of the screen which is the cassette buffer. How about the RS232 bytes ($0293-$029e), I guess I can mess with those as they aren't really used unless one call Kernal functions? I guess I will just tinker with each one of these to see if they break anything and lock up the emulator.

I also realized that I could read data straight into the default screen memory at $1e00 contiguously (as part of main load), and just move data to other places when I run it (like into the nibbles in color memory and down into the stack or $0200-$03ff area). Ofc if I use a custom 64 charset it will loaded directly into place there too.

I sort of hoped there was a list compiled of what memory you could safely use in the first page when doing 100% asm, but I have not found anything like that yet. If anyone have compiled a list like that I would be very happy to see it as it saves me for a lot of experimentation. I have noted Mike's comment above about tape and RS232 stuff though so those are likely safe then. I guess pointing screen to $0000 and just watching whats changing will at least give me a hint too.

[beamrider]

According to "Compute's - mapping the Vic" (which I suggest you download), you can use most of zero page (and the first four pages apart from the CPU stack obviously) if never returning to basic, not performing any IO and making limited use of the kernal (apart from perhaps the keyboard IRQ). Although I haven't tried this personally.

[johncl]

Yes but "most of" is relative. - Figuring out exactly what to avoid is the trick here. Anything that requires a Kernal call for the machine to read/write can be safely used, although from the memory map its somewhat hard to know - including some addresses that work as vectors and stuff that might redirect the CPU or Kernal features if I write values in them.

As for the stack, I believe you can use most of that too as only the end of the stack is really used depending how deep your jsr tree is (+ any the Kernal does in interrupts). From what I can see running my code so far it only goes some 32 bytes deep, so I will definitely use a lot in the CPU stack area too.

[johncl]

Ok, did a quick and dirty test where I wrote zeroes in the first two pages ($0000-$01ff) and then run a continuous test to check if the contents have changed after (also after I press some keys).
This is the result I got:



This is an image of the first two pages using a 22x24 char screen. The black @ are unmodified, the red ones are modified and the blue ones are the last bytes at $200 which are not part of this test.

I am not so sure about adress 0 actually being modified (as the image indicates) but rather colored by some Kernal thing that moved the cursor up to the top left corner (it blinks there when I run the program - and I dont exit out of basic, so obviously this is something the Kernal still reads and displays as part of the screen editor stuff). Obviously the red stuff there at the end of the screen is the stack busily being used by the Kernal (it changes a lot). All the keyboard input stuff is in the middle of the screen and easy to spot by typing on the keyboard.

Will try to compile a list of what seems safe eventually.

[beamrider]

great idea, empirical evidence is always best...

Just noticed you ran it in BASIC. Might be worth repeating in assebly language?

[buzbard]

If you look at the screenshot, about 9 lines down you see a "J", which corresponds to address 198 which is the number of characters waiting in the keyboard buffer.
Then counting to the right 6 places you see "@K" these two correspond to addresses 204 and 205 which are "CURSOR Enable" and "CURSOR Timing Countdown".
When your program pokes a zero into 204, you've enabled the hardware cursor and since you obviously cleared the screen the CURSOR is naturally in the top left corner of the screen.
That's why it's blinking.

[johncl]

Well the program is written in assembly, I just drag it over to vice to boot it up so there is a short basic sys line there, nothing more. I guess that loading line that pops up in Vice when you drag over a file is what you see in the basic input buffer thing in blue there which starts at $0200 (which btw is also memory one can safely use, the buffer alone is 88 bytes which is a nice contiguous block).

Thanks buzbard for the tips about those memory spots, I was going to check them in the Memory Map later today to check exactly whats going on when I set all those bytes to zero. - Although half of them I have no idea what they are doing.

Btw, anyone know whats in $03fc-$03ff? Those last bytes after the cassette buffer. Looks like room for 2 pointers or something?