Game Development Options on the Commodore 64

Introduction

There was a recent thread on Lemon64 concerning the antipathy many of us in the Commodore 64 scene show towards games developed using the Shoot 'Em Up Construction Kit (SEUCK) development platform, and I contributed with a comment of my own directed at Alf Yngwe, the planet’s number one SEUCK developer.

The gist of my reply was that aside from SEUCK, there are other options for creative types within the scene to develop games for the Commodore 64 instead of SEUCK.

Those non-SEUCK options largely consist of the following (but do let me know if there is something else you think should be added):

1. KickC
2. Turbo Rascal Syntax Error (TRSE)
3. Vision BASIC
4. XC=BASIC 3
5. MOSpeed
6. Other BASIC Compilers
7. Standard BASIC enhanced with some simple (beginner-level) 6502
8. Going all-in with 6502 Assembly Language

Let’s check them out in turn:

1. KickC

The official statement on this says:

KickC is a C-compiler that creates optimized 6502 assembler (sic). The language is classic C with a few modifications to allow it to optimize better for 6502 assembler.

The KickC Compiler produces assembler source code that can be assembled to binary by Kick Assembler.

Overlooking the pedantic point that it should say 6502 assembly (or assembly language, which is the proper name), not 6502 assembler (which is the compiler program for assembly language), this method comes with no greater recommendation than having been used to develop the delightful Robot Jet Action.

Admittedly Robot Jet Action is not a highly technical game, but it far exceeds the quality of anything possible with SEUCK and is certainly a better game than much of what passes for commercial releases.

But how easy is it to write code with KickC compared to assembly language?

Well, since it is essentially C, straight off the bat it is a high level programming language^* (as compared with the low level assembly language), so we know that it is substantially abstracted from the nuts and bolts of the 6502’s native instruction set (the 6502 in its 6510 variant being the CPU deployed on the C64).

Speaking plainly, KickC is much more beginner-friendly than assembly language, just as C64 BASIC is supposed to be, but unlike BASIC, KickC is not clunkily interpreted on-the-fly but rather is compiled first into machine code before it is executed.

This makes it a much faster, and therefore more game-suitable, option than trying to code games (or anything else) in BASIC.

The following excerpt from the KickC manual reveals that it not only compiles functional assembly language, but it takes measures to do so in an optimal fashion:

The compiler uses a number of modern optimization methods to create 6502 assembler code that executes as fast as possible and does not contain unnecessary boilerplate. The optimization techniques include:

• Detection of constant values and expressions
• Optimized allocation of registers to variables
• Optimized parameter and return value passing to/from functions
• Minimizing the number of zero-page addresses used for storing variables
• Choosing optimal assembler instructions to represent each statement
• Removing unused functions, variables and code
• Peephole optimization of the generated assembler code

And if you are wondering what the code you would be writing in actually looks like, then (a) you likely have no experience with a high level language :-( and, regardless, (b) it looks like this excerpt taken from the manual:

byte max(byte a, byte b) {
if(a>b) {
return a;
} else { return b;
}
}

So its syntax is similar to, say, JavaScript or PHP.

KickC therefore is ideally suited to someone with a grounding in any of the popular high-end languages in use today, not just those familiar with C or C++ (although it might be fanciful to imagine that anyone would know the latter two and be wholly ignorant of, say, Python, JS, PHP, etc!)

But is it suited to the absolute programming noob?

Probably not, but... it’s still likely to have a much softer learning curve than unadulterated 6502 assembly language.

That said, as with all the options in this article, you would still benefit greatly from some fundamental grounding in 6502 and the C64 memory map, SID and VIC-II registers to make the most out of KickC.

* = There is no universal consensus on the term "high level language" and some will no longer consider C to be such compared to newer languages, but since this is a C64 blog and its central theme is coding, I hold it to be perfectly reasonable to still describe C as high level; I mean, if we view everything from machine code to next.js on a spectrum, C is much closer to the next.js end than to the machine code end.

2. Turbo Rascal Syntax Error (TRSE)

I’ll introduce this option with the summary from its own website:

TRSE (or its full original name “Turbo Rascal Syntax error, “;” expected but “BEGIN”) is a complete suite (IDE, compiler, programming language, resource editor) intended for developing games/demos for 8 / 16-bit line of computers, with a focus on the MOS 6502, the Motorola 68000, the (GB)Z80 and the X86. TRSE currently supports application development for the C64, C128, VIC-20, PLUS4, NES, Gameboy, PET, ZX Spectrum, TIKI 100, Amstrad CPC 464, Atari 2600, 8086AT, Amiga 500, Atari 800, BBC Micro, Super Nintendo (SNES), Mega65, VZ200, MSX, Apple II and the Atari ST 520 (complete list here). With the benefits of a modern IDE (error messages, code completion, syntax highlighting, sample projects and tutorials) and a bunch of fast built-in tools, it has never been easier to program for your favorite obsolete system!

Presumably, if you are reading this, you don’t care about all the other legacy platforms mentioned there; you just want to develop something for your beloved C64.

With TRSE the baseline language is Pascal, which is another high level language along the lines of C, so the comments above regarding KickC largely also apply here.

TRSE, however, comes with some pretty impressive support features in the form of customisable tutorials covering many of the things you might wish you could do on the C64 but hitherto lacked the coding prowess to attempt.

It even has its own ray tracer to help making demo-level effects, which to me seems way above and beyond the call of duty for such a development platform, so well done the TRSE developer!

Like KickC, it facilitates optimisation of the code (trust me, this is always desirable on the C64!!!) and has various gfx editors as part of its all-in-one approach to development.

The full list of what it does is outlined on the project’s home page and for me, this looks even more impressive than KickC, but see for yourself.

For an example of a game written with TRSE, check out Night Knight.

More examples of very impressive results using TRSE can be found at the TRSE gallery page.

3. Vision BASIC

Unlike the previous two options (which are both 100% FREE and both cross-platform), this is a commercial product that runs on the C64 itself and is essentially a superfast (i.e. compiled) form of BASIC that allows native imbedding of assembly language and, as a BASIC-assembly mashup, features an in-built compiler.

Personally, I think it something of a strategic faux pas not to have made this cross-platform, as all that functionality on the native C64 comes at a cost: you need a 256K REU plus a SuperCPU / Turbo Chameleon / Ultimate 64 to use it on real hardware, even though the compiled code runs on a vanilla C64 without any of that.

The remedy is, of course, to use it with VICE emulating the REU + SuperCPU. But if you’re doing that, it may as well have been made for cross compiling.

The big plus with Vision BASIC, however, is that you don’t need to be familiar with modern high-level languages to get the most out of it. Rather, it presupposes that you have a grounding in old school BASIC and somewhat know your way round the C64’s registers.

So far, the only game I am aware of produced using Vision BASIC is Harold, which is not exactly showcasing anything spectacular so while that may not be anywhere near as impressive as KickC’s commercial quality Robot Jet Action, Vision BASIC nonetheless represents a quantum leap in what would be possible with BASIC or even SEUCK and probably has not yet been fully exploited in terms of game development.

4. XC=BASIC 3

XC=BASIC 3 is a cross-platform BASIC that produces executable machine code from source largely modelled on QuickBASIC and CBM Basic.

One of the really attractive features it has is the relative ease with which is allows you to set up interrupts, tantalisingly even including timer interrupts (wow!)

This is significant, as many experienced C64 coders have no idea how to use timer interrupts^* (as opposed to raster interrupts), much less the incredible power they bring to game development, as this article, The Wild Wood Deconstructed, reveals.

If the suite of options is as useful in real world deployment as the feature set would appear to promise, some seriously impressive C64 games should be possible using this tool.

In the meantime, an example of a simple game developed using it is Ad Astra, but I would be intrigued to see something much more ambitious attempted with XC=BASIC 3.

5. MOSpeed

If enhanced forms of BASIC are not your thing and you would prefer to dabble in compiling standard C64 BASIC (aka "BASIC V2"), MOSpeed stands as a modern cross compiler with handy full integration with Arthur Jordison's CBM prg Studio (which I happen to use for compiling all my assembly language projects).

Being a modern compiler, it produces efficient code as expected, allegedly giving discernible performance gains over the old BASIC compilers of yesteryear.

However, its rigid adherence to C64 BASIC, without any new features, means I personally would not imagine it to be suited to much more than introductory dabbling in cross-compiled BASIC.

6. Legacy Era BASIC Compilers

As mentioned above, compiling BASIC (or a form thereof) into fast executable machine code is nothing new. Others that did it before the modern newcomers include:

• Basic 64 Compiler (runs on the C64 natively)
• BASIC Boss Compiler (runs on the C64 natively + has cross-compiler functionality)
• Blitz (runs on the C64 natively)
• Exquisite C64 BASIC (this only has a manual in Swedish, AFAIK, but that’s okay as 50% of coders seem to hail from there!)
• Laser Basic (this consists of an enhanced BASIC with extra commands; it runs on the C64 natively)

But are any of the above worth working with in trying to develop a game?

I would say you would be better advised to use one of the more modern options and always use a cross compiler rather than working on native hardware for a much less stressful, less laborious workflow.

7. Standard BASIC enhanced with some simple (beginner-level) 6502

The final option I know of for those who don’t wish to roll solo with 6502 would be to just persevere with standard BASIC and enhance it with snippets of machine code.

This was actually “a thing” back in the day; I do recall a charming version of Scramble that was presented as a type-in listing in a C64 magazine in the UK and it used machine code, in the form of unintelligible DATA statements executed via an SYS call, to perform a sideways scroll of the screen’s gfx data.

It wasn’t smooth scrolling and so the effect was jerky, but it was still far superior to anything possible using BASIC alone.

I myself started to add snippets of very crude, dismally written machine code to my own truly awful BASIC games, typically to read the joystick, move sprites, clear the screen, change screen colours, set-up the VIC chip, clear the SID, write to the SID, etc.

All beginner stuff, all hand-coded by converting the instructions from their native hexadecimal into decimal and figuring out the branching, JSR and JMP addresses likewise and then manually entering it as DATA statements.

Sure, it was ultra “frontline” but it was no way to code and I was never going to produce anything special that way.

Nowadays, however, you can easily write assembly language on your PC and have it exported as DATA statements for enhancing your BASIC programs.

Nevertheless, this would probably still yield the least impressive results out of all of the options listed here due to BASIC still being interpreted line-by-line instead of compiled first.

8. Going all-in with 6502 Assembly Language

Assuming you have the time and focus that the teenage version of yourself had, I think that sooner or later you would probably want to tackle the seemingly daunting task of learning 6502 so that you can code entirely in the C64’s native language... After all, that will always remain the gold standard, especially for ambitious projects that require highly efficient “under the hood” interactions with the CPU and the rest of the hardware.

But before committing to learning assembly you might want to read this primer.

After that, you could dabble with Easy 6502 (snapshot from the website shown below) to get an early feel for it all.

What’s nice about that is you can run some little sample snippets of code in your browser to see it working in action!

Then you have to decide if you want to be self-taught from scratch through the arduous process of trial and error (and incidentally, no matter how adept a coder your become, you will always be a learner to some extent) or through a course.

Personally, I did it the first way when I was a teenager but I see some merit in the course approach too; the pros and cons below for the self-taught approach largely find diametrically opposite counterparts in the course approach.

Some pros of being self-taught:

• Painful experience impresses lessons on one’s memory and, in my opinion, provides a deeper understanding of the hardware and its instruction set than learning from a course might.
• You develop your own coding style that is instantly intelligible and readable to you, rather than becoming mentally confined within a facsimile of someone else’s idea of proper code layout.
• You are more likely to aim high and try the ambitious because nobody ever told you “this can only be done my way” or “that can’t be done”, etc.
• You are not taking a shortcut... there is no way to sugarcoat the fact that learning assembly language to any useful extent requires patience and perseverance, and attempting to speed-hack the process is just not going to yield great results.
• It’s FREE!

Some cons of being self-taught:

• You may develop bad habits / misunderstandings that might take a long time to weed out.
• You exclude insights and good practice that you might otherwise pick up from following a course.
• The scale of the task may appear unmanageable and compel you to just give up if you lack the confidence that seems to come when following a course.

I believe that a course is never going to really be a substitute for self-learning, but rather can only serve as a solid primer for what follows: lots of tinkering and learning from your own mistakes, reading Codebase (or trying to decipher some of the dismal “explanations” on it) and if you’re really into arduous processes, reverse-engineering other people’s code.

Old Books

Whether you are intending to go the self-taught route or take a course, I would recommend you familiarise yourself with the Programmer’s Reference Guide (cover image shown above) as a starting point and obtain the best books on the subject, most of which are available as free downloads on bombjack's website, notably:

• Machine Language for the Commodore 64, 128 and other Commodore Computers by Jim Butterfield
• Programming The Commodore 64: The Definitive Guide by Raeto Collin West
• Mapping The Commodore 64 by Sheldon Leeman

I would be selective in which books I refer to because some of them are genuinely atrocious, as Robin at 8-Bit Show & Tell revealed in his review of the laughably absurd Black Book of C128 by Robert H. & Dell Taylor (whose names will abide in infamy for having produced such a monumental screed of fake-it-till-you-make-it gibberish).

(On that note, I would recommend Robin's 8-Bit Book Club playlist for level-headed reviews of the golden age C64 coding books).

New Books

Meanwhile, as to be expected, there are a couple of newer books on Amazon:

• Retro Game Dev: C64 Edition (2017) by Derek Morris
• Retro Game Dev Part 2: C64 Edition (2021) by Derek Morris (Check out this review video)

Reportedly Derek Morris' books use macros and he provides a rationale for that, but personally I am not a fan of the practice (or the abomination that is pseudo code) and find it a distraction from learning 6502 assembly in its resplendent purity.

On the plus side, he also emphasises developing via cross-platform rather than on a C64, which is entirely proper in my view.

Courses

I only know of the following 6502 coding courses:

• Learn 6502 Assembly Programming... This is FREE, but I dislike that it is generically for 6502 rather than specifically for the C64.
• 64bites... This is a paid course and as a purist, I dislike that it uses pseudo code and macros, as these are superfluous abstractions that take you away from getting to grips with coding in the CPU’s native language... if we’re going down that route, you might as well just forget 6502 and jump into KickC or TRSE. However, if you don’t mind applying yourself to that and rolling with it for the sake of learning assembly, then I would assess that this course forms a solid introduction to coding on the C64. And while it is a paid course, the price is not exorbitant and therefore should not be a consideration.

A 6502 coder's profile:

Do you need to have genius level intellect to become adept at assembly coding?

Of course not, but obviously it would help!

All kidding aside, you would have to have a fair degree of aptitude for logical thought processes / lateral thinking, as well as patience and some measure of emotional investment in the learning process (i.e. passion for making games on tbe C64).

If you want to make the next Sam’s Journey, you will have to go all-in with assembly language, but if you only want a passable Space Invaders clone then you could achieve that with some of the frameworks outlined above.

Concluding Thoughts

Ranking the non-SEUCK options:

The following represents my own ranking, from best to worst, and others may disagree (apart from assembly being #1), but here goes anyway:

1. 6502 Assembly (obviously).
2. KickC (until anything else can produce something as impressive as Robot Jet Action, it takes #2 spot by default).
3. TRSE (or maybe it and XC=BASIC 3 should swap places... I can't quite make up my mind).
4. XC=BASIC 3.
5. Vision BASIC (until it can produce a passable game, it's not close to showing it is better than SEUCK... and the extra requirements for it plus the price are not attractive).
6. MOSpeed.
7. Other BASIC Compilers.
8. Standard BASIC enhanced with some simple (beginner-level) 6502... Fine for hobby projects, nowhere near good enough for commercial releases.

For 6502 coders, there may also be some mileage in using #2 - #4 to produce a functional outline of a game and then manually refine the code to strip out additional excess cycles here and there, or do things with interrupts that may not be possible with the generated code, etc.

In other words, we could investigate them to see if they have any potential for fast-tracking game development.

My opinion on using SEUCK for games:

However, when it comes to using SEUCK in creating commercial games, I am personally vehemently opposed to this, even though I do admire some SEUCK productions.

I don’t care how nicely packaged it is, I don’t care for the fancy bitmaps and other bells and whistles, or how well designed or thought-out the gameplay is.

It’s still obviously SEUCK with all the inferior quality and stigma that defines that system.

A commercial release that you are asking people to pay money for has to be, in my personal opinion, degrees of magnitude above and beyond what anyone can knock out using average coding skills or something that produces the inescapably lookalike results that SEUCK does.

I do not wish to hurt anyone’s feelings, but commercial releases should have compelling gameplay PLUS 21st Century standards in gfx, scrolling, multiplexing, etc., without a flickering artefact or generic explosion in sight.

Embellishing a SEUCK release is, by contrast, just putting lipstick on a pig.

Accordingly, I implore all you SEUCKists to acknowledge the limitations of SEUCK and accept that games produced with it should not be commercial releases.

And before anyone starts, this is not about “hating SEUCK”, as some of you will undoubtedly say.

Rather, it’s about hating inferior quality in releases that you are asking people to pay for.

All I am asking is that you produce quality and raise standards, as that would do more to keep the scene alive than any quantity of highly polished SEUCK releases ever could.

So don't be lazy!

Get your hands dirty with code or at least, try out some of the better options listed above!