As mentioned earlier, I’m not porting AGI but writing Larry again from scratch to cater to the specific strengths and weaknesses of the C64 as a platform. I’m doing this in 6502 Assembler as that’s the only way for me to gain the required speed and control over the hardware that is needed to pull all the tricks I need. In this post I’ll provide more detail on how the screen actually gets drawn.
The Commodore 64 contains a VIC-II chip to drive the display. This is one of the most famous and well understood video controller chips in the history of personal computing. As users of modern systems we should recall that the C64 was originally always paired with a cathode ray tube (CRT) based monitor or a similarly configured TV set. In order to understand how the VIC-II works, and what tricks we’re pulling, you need to know a bit about CRT’s.
A CRT continuously generates a very strong but very thin beam at the back of the tube. This beam gets strobed at dizzying speed across the screen, starting at the top left corner and moving to the right very fast, then down a line and repeat until the lower right corner is reached and the process starts again. Along the way, the beam strikes a phosphorous screen at the front of the display. The particles light up for a short while under the influence of the beam. They dim again very quickly, though, so the beam needs to race across the screen dozens of times per second to keep up the illusion of a stable image in our sluggish human eyeball/brain combo.
Video modes of the VIC-II
What does this have to do with Larry? Well, the Commodore’s VIC-II can only do so many things at the same time. It can either show a raster of 40x25 characters of text. Very useful when writing code or playing ancient text adventure games. Clever programmers use this mode to draw pictures using what are, effectively, characters of text.
Sometimes they use the characters Commodore provides, called PETSCII, but more often they adjust the VIC-II so that it gets its information from RAM where the programmer can adjust what every individual character looks like. By doing this and cleverly combining characters, which are just blocks of 8x8 pixels, you can draw very elaborate graphics very quickly: most of the heavy lifting is done by the VIC-II, which is pretty good at reading character definitions from memory and drawing them onto the screen very quickly. Most shoot-em-up scrolling games have background graphics that are drawn in this way.
Since I’m porting an existing game that had graphics that were drawn onto a 16-colour bitmapped area with no regard for the 8x8 blocks of pixels that Commodore characters are composed of, the original Larry graphics don’t carry over very well to this mode at all.
Instead, I’m using the VIC-II’s mulicolour bitmap mode. The C64 can also display 16 colours in a resolution identical to the one EGA Larry was originally coded in: 160x200 pixels. The colours of the C64 are a bit different from EGA’s pallette, but that can be lived with. More interesting is the way the VIC-II draws bitmaps compared to EGA, but that’s a topic for a future post.
For now, it’s important to know that the VIC-II in bitmapped mode can not display text of any kind whatsoever. Sure, you could “draw” text as part of your bitmap but doing that is extremely slow and cumbersome to deal with. The resolution would also be very coarse in the multicoloured mode we need for Larry. Regular text is drawn on a 320x200 pixel matrix, bt the bitmapped screen can only do 160x200 so we get characters that are stretched to double their size horizontally. We could only display 20 of those before filling an entire line.
We’re actually tricking the computer into switching display modes at very precise spots on the screen. This works because the VIC-II chip exposes to the CPU exactly which line of the screen the CRT’s scanning beam is drawing. If we connect these two, we can interrupt whatever the CPU is doing just in time to tell VIC-II to switch from text mode to bitmapped mode and back, and the resume whatever it was doing before that. This trick is called a raster interrupt and it provides a way for us to split the screen horizontally into multiple parts.
In the case of Larry we have a top bar that holds the game’s title and score against a white background. This is done in the C64’s standard text mode. Just before the VIC-II is about to finish drawing the last white pixel of this top bar, we need to interrupt the CPU and gear it up to tell VIC-II to change modes ASAP. If we time this just right, this switching of video modes happens while the CRT’s scanning beam is busy drawing the C64’s fat screen border somewhere on the left or right of the screen. The result will be a sharp transition between the top bar and the multicoloured bitmap below it, as if the screen didn’t change modes at all.
If we do not get this right, there will be visible shimmering artifacts between the top bar and the bitmap below it. Getting this just right is something of a dark art that demo coders have honed to perfection. Me? Not so much.
Below is the code that sets up the raster interrupt for Larry.
/* Setup the system for interrupts from VIC */
lda #$C0 // Pick some random line somewhere mid-screen
bne csri_wait // Wait for mid-screen to avoid weird crashes
sei // Disable interrupts
sta $DC0D // Disable interrupts from CIA-1
and $D011 // Clear bit on VIC's raster register
lda $DC0D // Ack pending interrupts from CIA-1
lda $DD0D // Ack pending interrupts from CIA-2
lda #$3A // Scanline just below the top bar
lda #<core_irq_topline // IRQ handler low byte
lda #>core_irq_topline // IRQ handler high byte
sta $D01A // Enable IRQ signals from VIC
cli // Restore interrupts
What this does, is something I learned through trial and error. Apparently it’s not a good idea to just kick this process off whenever you feel like it. The game would crash with a garbled screen. So what the first line does is pick some more-or-less random line somewhere mid-screen, $C0 specifically, to prevent these crashes from happening. The number is loaded into the accumulator and we compare location $D012 (the VIC-II’s scanline register) to hit this number before proceeding. This is the only time in the game that we hold code execution while waiting for a specific scanline to be hit.
Once line $C0 is hit, we disable all other interrupts with
sei and perform the needed actions
that disable the timing interrupts that the CPU receives from the CIA-1 chip by default. We acknowledge
any pending interrupts from the CIA chips so they’ll be gone when we exit this routine.
Scanline $3A is the scanline that gave me the most stable result for triggering the switch to bitmapped
mode. The actual switching code is not in this fragment. We’re loading the address of
into the vector at $0314 and $0315, essentially constructing what languages like C call a pointer.
Our last step is to set $D01A to 1 to have VIC-II send interrupts to the CPU. The
re-enables interrupts system-wide and our newly installed handler will run from now on out. The code
that actually does handle the interrupt lives in a different routine:
/* This is where the scene's background starts */
lda #$00 // Screen background is black
lda $0B // Load current game mode
cmp #$00 // Game mode is default
bne cit_dialog // Jump to test for dialogue mode if not in default
lda #$F1 // Next interrupt just above the screen editor
cmp #$01 // Game mode $01 is dialogue mode
bne cit_system // Jump to system mode if this isn't it
lda #$D2 // Next interrupt just above the dialogue window
nop // System mode isn't present yet.
lda #$FF // Ack the interrupt
pla // Recover the stack
rti // Back to Kansas
core_irq_topline which is where the CPU gets sent when VIC-II fires just below the game’s
title bar. The routine immediately sets the screen’s background to black (value $00 in $D021) before
doing anything else. The next step is to figure out what game-mode we’re in and jump to the appropriate
label to act as needed. The difference mainly being the installation of the next interrupt handler at
another scanline further down the screen to either display the screen editor, a dialogue window or the
as-yet unimplemented system-mode. The
cit_wrapup part acknowledges that the interrupt took place and
recovers the stack so that we can return the CPU to what it was doing as quickly as possible.