| geocities main | times square | Index |
| Vic-20 | DOS | X11/Unix | RiscPC | Ideas | e-mail me |
| PCVIC | Arcvic | archive | programming | transfer | screen grabs | links |

The (small) Vic-20 programming page

Last page update: 21 Mar 1997

Vic-20 development tools

THE RANDOM ALIEN GENERATOR (rndalien.hqx) - Probably the most unusual development tool you've ever seen! Generates random 'space-invader' like sprites. The data values of any chosen sprite can be displayed.

Cross-development tools for the PC.

By default, AS65 generates Raw files, but with a little trick, you can make it generate PRG files that can be easily loaded into an emulator, or a D64 disk image. An example.

TOK64 (tk6414.zip) by Cris Berneburg. This utility converts ASCII files to CBM tokenized BASIC files, and vice versa. This is very useful if you want to write CBM Basic programs using a regular DOS text editor. The special CBM control characters are denoted by words within curly braces { and }.

However, there are some problems with TOK64. The most important one is that it was made for use with the CBM64, which results in a start address problem. An overview of problems and workarounds.

RLCCBM (rlccbm1.zip). A PRG relocator/BASIC rechain utility (C source only but it should compile with most compilers). This can be used to relocate Vic-20 programs for use with TOK64.

PEPORES (pepores.zip) by Graeme Scott. A TSR pop-up debugger. The newest PCVIC version (1.13) displays the DOS segment where the Vic-20's memory can be found. With PEPORES, you can look up this segment and easily view/edit the Vic-20's memory.

Libraries and example code

What you have to do to make a your ROM program bootable is put a specific sequence of bytes at address $A004. When this sequence is found at reset, the kernel transfers control to the address found at $A000.

Besides that however, you will have to set up your own initialization and handling routines for any hardware you want to use, because the Kernel will not do this for you unless you tell it explicitly. Of course, exploiting the Kernel is a good idea if you want to get the most out of the limited program space you have, but it is tricky business, because a lot of its routines are complex and have side effects (for example, they expect or use variables in the zero page). You will need good documentation, or better, disassemble the Kernel routines you want to use to be sure.

Here (rom_template.txt) is an example of setting up a ROM program. It initializes the screen and a couple of timers, and scans the keyboard. This program does not use any Kernel routine, but its handling routines do not take up a lot of space.

How to display bitmapped graphics.

Bitmapping is a flexible technique that makes sprite animation look really smooth. A lot of ROM games (Examples: Jetpac, Turmoil, Fast Eddie, Gorf, Shamus, Predator, Black Hole, Ms. Pacman, Demon Attack) use bitmapping, though it does cost a lot of memory. Of the unexpanded 5K RAM that is normally available, less than 1K is left for variables or code. I have written a little program (Source, PRG image) that explains the use of bitmapped graphics.

Smooth scrolling.

Smooth scrolling is a bit of a problem on the Vic, because the panning registers have a limited resolution (especially horizontally) and show glitches at the sides when used for scrolling. Scrolling a bitmapped screen, on the other hand, eats up too much processor power. I have an alternative (which I think is also used by Mountain King, although I haven't looked at their routines. I haven't found any other game that uses it though) that allows full-screen one-way or two-way scrolling horizontally or vertically. I have written an example program (Source, PRG image) that demonstrates the algorithm.

More example routines

MAKEFONT (makefont.txt), a program that generates an alternate font from the character ROM's own font, which is less expensive on memory than defining the font from scratch.

RANDOM GENERATORS (Source, PRG image). Reading the low byte of a timer is a quick and easy method to get a random value, but it will work only if you don't use it several times in quick succession and if your program itself is not tightly timer-controlled (remember that all timers in the Vic are fed by a central clock). Instead, you can use a deterministic random generator, like the ones given here. These random generators have the property that when you start off with the same initial random-seed, the sequence of values they generate is always the same. This may be a disadvantage, but can also be used to your advantage. For example, consider a video game where you generate rooms using a random routine, and you want your players to be able to walk back into rooms they've been before. When you use a deterministic random generator, you don't have to have your program memorize each room after it's generated, but it can re-generate each room as needed by loading the same seed before generation starts. All you have to memorize now is the random-seed.

Send suggestions/comments to: