Following a suggestion on one of my recent YouTube videos I’ve been trying out Turbo Rascal Syntax Error (TRSE) for my Commodore 64 game development and first impressions are very positive. TRSE uses a Pascal style language which I have used previously at University, though I missed out on the famous Borland Turbo Pascal for the PC.
TRSE is a full integrated development environment with many helpful features to make your classic 8bit/16bit coding easier. I understand it was originally developed for C64 coding but it now supports many computer and console systems including the ZX Spectrum, BBC Micro, Commodore Amiga and MS-DOS.
Features include inline assembly language support for when you need that extra speed, large numbers of example code, code profiler to show you which routines or data are taking up the most space and some built in editors for graphics and maps. For the C64 there is specialist support for playing music SID files, raster interrupts for split screen effects or sprite multiplexing and many other features which I’ve not had the opportunity to explore yet.
Moving from CC65 which uses the C programming language, I’ve found some of my earlier code doesn’t work as expected (even when rewritten in Pascal) but with the examples provided I’ve managed to replicate the main code fairly easily and that’s before I consider any optimisations or the use of assembly language.
You can see me using TRSE below with some rough test code for Demon’s Isle.
I’ve been working away on my Commodore CRPG as time allows and making some good progress with it. It’s provisionally called “The Citadel”. I’ve made a number of visual changes including moving the map display to a separate screen which I think works quite well, tweaked the wall graphics a bit and added a custom font. Raster interrupts are used to provide some flexibility with screen colours and character sets for different vertical slices of the screen. My build process also adds the executable and data files to a Commodore 64 disk image file allowing me to swap in maps or wall graphics as required. Currently I have lots of free space on a standard 170K disk.
There are some locations with flavour text and examples of special locations where you can find objects and add them to what is currently a simple inventory. Content wise, the next things I really want to add are some wandering encounters, an initial combat scheme and a shop where you can upgrade your weapons and armour.
Before that though I need to take a look at the way I’m currently using memory for the game. I started to experience some strange behaviour the other day and decided that the code segment of the game was overwriting some sensitive area of the C64 memory. My current executable file appears to be about 37K (36,929 bytes). This hasn’t been an issue so far as I’ve been very free with my use of memory so far. For example the wall set character data is larger than the final data will need to be to allow me to easily and quickly update graphics and see them working in the game immediately.
As mentioned before I’m using a mixture of C and 6502 assembly language using CC65 https://github.com/cc65/cc65. It’s a suite of tools including a C compiler and a full assembler and can be used with a variety of 8 bit systems such as the C64, Apple II and Atari 800. It uses a configuration file to determine the memory layout of your program. Here’s a portion of my current file:
One change I made from the original file was to move my CODE segment to come after my data files. This possibly isn’t the best approach so if anyone has experience of C64 coding or particularly using CC65 then I’d welcome your advice. Currently I have my character set (font) starting at $3000 (12288 in decimal) so this can be moved to a lower position in memory, providing I pick one of the valid character set locations. The screen memory sits at 1024 – 2024 by default but can be relocated if required. Even if I leave the screen where it is and move the character set and wall character sets to sit after the screen that will still open up another 10K or so for code.
There are lots of inefficiencies in some of my data files / data areas which I can reduce and I also have some old routines that I’m not using that I can take out to free up additional space.
My next job however is to review the C64 memory map again (https://sta.c64.org/cbm64mem.html) and see whether I can move my data to sit under some of the areas of the C64 memory that can be switched in and out to access the full 64K of memory that the C64 has. These would normally include the BASIC ROM and the KERNAL ROM areas. I also need to check where CC65 stores its stack of C data structures and variables. I believe the C stack grows downwards into memory but I need to check and maybe look for a good CC65 forum that can advise me.
Overall I’m still really enjoying putting this game together and finding the C / 6502 hybrid programming approach is working well for me.
I’ve been experimenting a little bit with the bitmap modes on the C64. As mentioned previously there are a choice of high resolution (320×200) or multi-color (160×200) bitmap modes on the C64. There are various pros and cons with these two bitmap modes as well as with using the other character based modes the C64 offers.
Bitmap mode – 2 colours per 8×8 pixel cell
Standard or high resolution bitmap mode shown above has the advantage of giving you the full 8×8 pixels per character cell on the screen but you are limited to only a single foreground and background colour in each 8×8 cell. A full screen uses 8K of memory plus 1K for the colour information.
Multi-color bitmap mode – 4 colours per 8×8 character cell
Multi-color bitmap mode has the advantage of allowing you to have up to 4 colours per 8×8 character cell (one of which is a shared background colour) but has the disadvantage of reducing the horizontal resolution in half, displaying double width pixels. It also uses 9K of memory in total but needs an extra 1K for the additional colour information.
Memory usage for both these modes could likely be reduced by 1-2K by using a split screen mode with a text display at the bottom – think Ultima 2 or any of the many graphic adventure games of the 1980s. Many C64 games used a split screen like this to mix modes on a single screen, saving memory and improving display speed.
My initial tests with these bitmap modes are proving quite slow to display compared to my earlier character based version. This is hardly surprising as drawing a single 16×16 pixel tile on the screen will now involve writing at least 40 bytes to the display (characters and colour information) as opposed to just 8 bytes. I’ll give it some further thought and do some more drawing in the various modes before deciding to see if I feel the additional flexibility is worth the increased memory usage and reduction in speed.
An example of mixing multi-color and high-res characters on a single screen
Since my last post I’ve been experimenting with using the Commodore 64’s multi-color character mode. This mode allows you to display 4 different colours in each 8×8 pixel character cell but with the loss of horizontal resolution. Each “pixel” in multi-color mode is effectively made up of 2 horizontal pixels – this sometimes leads to the slightly “chunky” look of some C64 graphics in games. 1 colour is the background, 2 colours are set universally for each character using registers and the other comes from the C64’s screen colour RAM (one colour per character cell on screen).
A C64 multi-color character – Note the 4×8 “pixels” rather than 8×8
It’s possible to use a mixture of multi-color mode characters with standard high-res characters on a single screen. This is done by setting bit 3 of each character cell’s color memory – the value of this bit determines whether a character on the screen is in standard high-res mode or multi-color mode. The downside of this is that you have a more limited selection of colours. Colour values of 0-7 in the colour RAM will display a high res character, 8-15 a multi-color mode character. This means you can’t use colours 8-15 in your display other than as one of the 3 universal colours – so no light red, shades of gray, light green etc (colours on the right hand side below).
The C64’s 16 colour palette (taken from Pixcen)
I’ve done a bit of experimentation with Pixcen and produced a few sample multi-color tiles but it took me a while to understand how the colour limitations work and I find the loss of horizontal resolution hard to work with, and I have little artistic skill to start with! I also need to work out what my graphics development process is. Pixcen seems to be a good enough utility but I think there may be other tools which might suit me better. Some form of C64 graphic, tile and map editor might be required.
So I have a real balancing act to consider, deciding on whether to use multi-color mode (losing resolution and colour choice) or just stick to using high-res characters but having the limitation of a single colour per cell. I’m aware that I could use one of the C64’s bitmap modes which provides the programmer with control of individual on-screen pixels with greater colour flexibility but from what I’ve read that will use a lot of memory (8K just for the bitmap data) and would potentially be slower than using characters. Let me know your thoughts.
Here’s the latest image from my Commodore 64 RPG. I’ve added some additional tiles (from Ultima IV) as placeholders and to give me something to work with whilst coding game functionality.
The Ultima IV tiles and C64 character set are temporary.
Additional placeholder tiles and a basic screen layout
I now need to add some additional maps to the game with working entrances and exits, initially just a town and a dungeon. I need to give some serious thought to map sizes and how I want to manage the wilderness map. Games such as Ultima IV and V would load sections of their wilderness map into memory as required but I’m not sure my map needs to be as large. I’d also like to add some basic combat with those red monsters on the wilderness map and some basic interaction with some example town NPCs.
I’m urgently feeling the need for some map editing tools. Whilst I could create some windows tools for these I’m considering making the tools run on the C64 as there will be a number of similar coding routines. There’s no shortage of things to keep me busy with this project and so far I’ve not run into any serious problems – memory and floppy disk space do concern me though…
Since my last post I’ve revisited the CC65 cross compiler which you can use to write C programs on 6502 based systems such as the Commodore 64, Apple II and Atari 8bit.
I had been using CC65 for a few months, sketching out the beginnings of a C64 CRPG but had run into problems managing the memory configuration required for custom graphics. I’d moved onto using CBM PRG Studio and programming in 6502 assembly code which meant my code ran very quick but I was finding was slowing down my development time compared to using C in the past.
Some simple C code for the Commodore 64
Now I’m not much of a programmer in any sense of the word but I probably have the most experience of using the C language overall so I was finding 6502 assembly language time consuming to use and my game development time is very limited and I’m not really trying to do anything fancy technically by the standards of C64 games.
There is a lot of documentation online for CC65 but I was lacking an example of how to do a simple custom character set and use code overlays for swapping code in and out of the C64’s 64K of memory from disk. Most of the famous CRPGs I grew up with such as Ultima and Alternate Reality use this method to make the most of the machine’s limited memory by modern standards. I just couldn’t get this to work and gave up frustrated.
I noticed this week that CC65 had been used to create some of the code in Ultima IV Remastered for the C64. After this I came across a CC65 example online that included both a custom character set and code overlays and worked out how to compile it with a custom linker file. This determines how the memory map for the program is set up and where any external data files or graphic data should go. Once I had this working it was relatively easy to load in my modified character set and recreate my map code in C, display it on the screen and have a player marker move around the example map. I also was able to automate my compilation process with a single key press from within Notepad++ and run the resulting program in the Vice emulator which felt pretty smooth.
A simple map with a (feeble) character graphic player to move around
The main reason I was originally attracted to CC65 was that I love the idea of using C and being able to then reuse the code on other 6502 based platforms as well as modern PCs and operating systems. CC65 also has special support for some systems including the C64 so that you reference the C64 hardware directly within your C code. As CC65 includes a full assembler in its tool chain, you still have the option of using assembly language within your C program where extra performance is needed and tweaking the generated code. I’ll post more about CC65 in a future post; where to get it and provide a brief example and possibly a video of how to do the things I was struggling with in the hope they help others get started.
I’m starting to put together my notes for a new project – part original game, part game programming video / blog tutorial. I’ve been planning this for the last couple of years and it will be an enjoyable change of pace from Alternate Reality X development.
As you may know I grew up playing CRPGs on the Commodore 64 so have many fond memories of those days spent exploring the lands of Britannia in Ultima IV, skulking round the streets of The Bards Tale and of course finding unique new treasures in the depths of Alternate Reality: The Dungeon.
I recently had a lot of fun doing a bit of BASIC programming using a Windows based program called CBM PRG Studio – this provides an IDE for rapid C64 development in both BASIC and assembly language as well as offering integrated tools for graphic and music creation. Used in conjunction with the Vice emulator it’s a pleasant way to program for this classic machine. I’m also planning to dip into other tools such as native assemblers and possibly even some cross assemblers and cross compilers.
Of course you won’t need a Commodore 64 to follow the series or play the various versions of the game. Depending on how the game comes along I’m not ruling out a version which will run on current operating systems as well. The intention is to start small explaining the basics of the machine and its display, use of the built in character set and PETSCII characters before moving onto user defined characters and multi character tiles more akin to Ultima and other classic CRPGs from the era.
In case you haven’t heard about it there was a recent successful Kickstarter called “Unknown Realm” which is for the C64 and PC and looks good. In case you’re wondering I was planning some C64 CRPG development when I bought my Programmers Reference Guide a couple of years back 🙂 You can read more “Unknown Realm” below:
Don’t worry about my new project slowing down ARX development. I’m planning small incremental changes as to how the series and game develop which I don’t anticipate will be particularly time consuming compared to a typical ARX release. I hope you’ll enjoy it.
