GET YOURSELF A VICE
This is a pretty nice emulator – open source and cross-platform. Unfortunately, it’s a little fiddly to set up. First do the usual sudo apt update to bring your PC up to date. Next, install Vice with:
$ sudo apt install vice
However, we need to get the
CBM-64 Basic, Chargen and
Kernal ROMs, and some others. Those are included in the
Vice emulator source, so first download that from:
http://bit.ly/lxf313Vice.
This has a lot of files but the one we want is vice-3.6.tar.gz. This is well down the page. If there is a later version, use that and change the Tar statement.
We need to create two folders – C64 and DRIVES – under /usr/ lib/vice:
$ cd /usr/lib/vice
$ sudo mkdir C64
$ sudo mkdir DRIVES
Now extract the Vice files from the downloaded file using Tar:
$ cd ~/Downloads
$ tar -zxvf vice-3.6.tar.gz
$ cd vice-3.6.0/data
There’s a load of folders but we’re just interested in the C64 and DRIVES folders. Use:
$ cd C64
$ sudo cp chargen kernal basic /
usr/lib/vice/C64
Then:
$ cd ../DRIVES
$ sudo cp d1541II d1571cr dos* /
usr/lib/vice/DRIVES/
We’re almost there. Now go to the C64 folder in /usr/lib/ vice/C64:
$ cd /usr/lib/vice/C64
$ sudo x64sc
Or:
$ sudo x64
And Robert’s your uncle. The
x64sc version is newer, slightly slower but more accurate.
Make sure that it’s working as expected by doing a print message, as the screenshot
(below) shows.
run xa to generate a PRG file, do the following. On the Vice File menu, click Activate Monitor. This opens another window and gives a cryptic display (see screenshot, bottom, previous page).
There are many commands available. To see them, simply press ? and hit Enter.
We’ll load the first.prg file in a moment. First type in
pwd to see the current working folder, to check you are loading the file from the correct folder. Now type the code below to block load the first.prg file into RAM:
bl “first.prg” 0 2000
The 0 is device 0, which is the disk. Note 2000 and $2000 are the same. This should load the file and tell you what address it loaded into and the number of bytes that were loaded:
Loading first.png from 2000 to 801E (001F bytes)
We can look at this in memory with the d command to disassemble the RAM at the specified address. Type in d 2000 and press Enter. Now let’s run it with the g address command specifying the address:
g 2000
We got the DEX and ADC #$01 instructions in the wrong order, so instead of showing 16 characters, it did the whole 256, because the BNE kept branching back until the accumulator overflowed and returned to 0.
The JSR $FFE4 is a call to a system routine which returns non-zero if a key is pressed. So, the BNE $2004 keeps looping round until a key is pressed. It then exits and returns to the Basic interpreter. That’s what the three JSRs do.
You’ll find that the Vice monitor doesn’t return after the g command. First hit a key on the CBM-64 screen so that it drops through the WAIT1 loop, then kill the monitor window and reopen it. It doesn’t lose anything when you do that.
Development cycle
There’s been a lot there, so let’s sum it all up:
1. Edit your source files.
2. Use xa to assemble the source into machine code in a PRG file.
3. Use the Vice monitor to load the machine code into RAM.
4. Run it.
There’s a lot more to the Vice monitor. It will let you do line-by-line debugging and set breakpoints. That’s something that wasn’t available back in the day and would have made life a lot simpler.
Games development
The Commodore 64 is best known for being a games machine. As well as a three-channel sound chip, it has eight hardware sprites that can be multiplexed in software to allow more on screen. Also, there is a graphics mode; in fact, programmers in the demo scene have learnt to do remarkable colour graphics. For some examples take a look here: https://bit.ly/ lxf313demo.
There isn’t enough room or time to create a game, so instead here is an open source arcade game, a simple Tetris by programmer Christian Jauvin – https:// github.com/cjauvin. The rest of this article is about the edits you need to do to get it to compile with the xa65 assembler. The original was assembled using a Java assembler called KickAssembler, and lines 9-14, which detailed that, were removed. All other comments, including the original author, have been left in.
CBM-64 try to assemble!
There are a number of 6502 assemblers and they vary in things like the opcodes for assigning data, constants, load address, even whether labels have a terminating colon. Getting a game to assemble with a particular assembler can be a tedious task if the code you are trying to use was not written using that assembler. Another issue is whether all the code is in one file or
multiple ones. We looked at another Tetris but it had several source (https://github.com/wiebow/tetris.c64)
files, so a lot more editing was needed.
Download the Tetris ZIP file from https://github. com/cjauvin and unzip it. The file has two source files, math.asm and tetris.asm, and a Readme.md.
Assemble it with this command – it takes the source file and outputs tetris.prg:
$ xa testris.asm -o tetris.prg >asm.txt
Xa65 is fast – even with a 1,000-line source file, it’s almost instantaneous.
The >asm.txt puts all output into the text file asm. txt, so you can view the errors in a text editor; it beats having to scroll upwards.
Go for xa65
Here are the instructions to get it assembling under xa65 without any errors. Comment or remove line 32 and change line 34 to * = $2000 .
Add a jmp main just before line 35, which has the label frozen:. The label main is where the program starts and jmp main lets you start it at $2000 and jump straight to the main code.
Merge the file math.asm into tetris.asm; anywhere will do – in this case, just after the piece_j bytes around line 105. Remove the .import statement.
The rest of the changes take 10-15 minutes. The main change is to edit labels that start with a ! and remove the !. These are local labels that xa65 doesn’t support, so number them by adding a digit or character – so, when you see !loop, change it to loop1, the next !loop label is loop2, and so on. These labels often have a + or – depending on whether the branch is forward to a local label or backwards. From this you can figure out if the branch is backwards or forwards. For instance, line 289 is a !loop and on line 311 there’s a bne !loop-. Line 319 is another !loop and on line 325 there’s another bne !loop-. Line 407 has a jmp !continue+ which jumps to the !continue at line 410. Another change is the .fill on line 35, which became .dsb. This allocates an array of 1,000 bytes, each set to 0 initially.
It’s a useful exercise to take someone else’s code and get it assembling, but if you get fed up, just fetch the working tetris.asm file on GitHub: https://github. com/David-H-Bolton/Projects/.
If you want to see all the differences between the original and the xa65 version, rename the original tetris.asm to, say, original.asm and copy it into the same folder as the xa65 tretris.asm. Then run the diff
command to see all the differences:
$ diff original.asm tetris.asm
This outputs a listing showing the old and new lines.
Running Tetris on Vice
Open the Vice monitor then do: bl “tetris” 0 2000 d 2000 g 2000
The disassembly shows the initial JMP followed by a thousand BRK statements.
4C 2C 2B – JMP $2B2C
00 - BRK 00 - BRK
…
The disassembly interprets the 00 value as the BRK instruction. It should be possible to have PRG files autostart, so that all you need to do is drag a file in Files on to the Vice window. However, it hasn’t worked so far! It’s possible that the PRG format isn’t quite correct.
The screenshot (below) shows the working game running in the Vice emulator. You can use the WASD keys as described in lines 10-14 of tetris.asm to play. Have fun!