Close Reading the VICE Source Code
Today I’m attempting to close read the code base of the VICE emulator. I already made some attempts at this through going into the source code 2023-05-24. Meanwhile, I also read the insightful text on the VICE project by André Fachat and got a more profound understanding of how an emulator tries to translate electronic processes into software. This first inquiry is guided by questions of visuality.
I have to admit that I’m neither fluent in C, the language VICE is written in, nor the Commodore 64 architecture. Starting in video.h, the place where declarations and macros for video are set, I forked into different other aspects. In this exploration, I found a few topics I needed to research and could be interesting for further investigation: VIC-II (Video Interface Chip), Graphic Modes and Bad Lines.
Context
The following articles helped me in creating context for the interesting topics I found while reading. I read some, skimmed others, and just saved some for later reference.
- Video Interface Chip and Graphic Modes
The Commodore 64 was designed to deliver a number of official graphics modes which provide for combinations of character graphics, bitmap graphics and sprites in single and multicolour. All of which can be mixed. The various modes were implemented using the VIC-II. As familiarity with the VIC-II grew, users developed non-official techniques which delivered graphical improvements.
- Bad Lines
A badline is a gridline in which the processor is switched off by the VIC so that the latter can make more memory accesses. The name comes from the fact that this shutdown messes up the timing of the processor. This is problematic with diskette accesses, for example. Badlines also interfere with many raster tricks. But there are also tricks where you have to create such a line on purpose.
Discussion
I can read the source code as text, but it is tedious and quickly grows in complexity. Without being practically involved, such as working on the code base, it is near impossible to grasp the source code in its entirety. Even though the files are exceptionally well commented with pointers to the code’s functionality, inner workings of processes, but also organizational matters (such as TODOs and FIXMEs) there is so much inherent knowledge of what is doing what.
That aside, I was fascinated by the concept of badlines, which are glitches that appear when the video interface controller chip turns off the main CPU to be able to read from memory. Theoretically, the emulation of the C64 system could have fixed that, since today’s system has enough resources and possibilities to enable both emulated chips to read at the same time.
An interesting problem arises now because badlines were an essential reality at the time of the physical C64, being part of the experience as a player and also being actively used in producing the graphics on screen. The following post goes into the details of this approach.
This post will cover three techniques that violate things the VIC-II thinks ought to be invariants. This puts the chip into unusual states and a few surprising things happen as a result. All of these techniques involve cases where a badline does not actually last the complete line it’s intended to cover. Whether something is a badline is checked continuously, so if the chip’s logic says “wait for a badline to happen, then do this thing” it can be made to happen earlier or later. - Partial Badlines: Glitching on Purpose
These specifics of the hardware of the C64 had to be reimplemented, unquestionably! I was wondering in the end, how such a source code is an epistemological object, also for machines. The code base of the VICE essentially describes how the C64 should work, but it is describing it in a language which is equally accessible for humans and machines (the compiler).
Basically, software emulators translate physical sign categories into semiotic ones [Holenstein 1992:17]: Their goal is to map the hardware structure of the original system into software that runs on the host system.
Finally, I was questioning how fluent I have to get in a programming language to be able to truly critically analyse it. Also, can one memorise a “Choose your own Adventure” book?