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.
Using raster interrupts seems pretty advanced and not an easy thing to pick up. But I’ve determined today by looking at color and resolution details of my favorite C64 RPGs that this must have been employed in most of them. They seem to have the 4 color limitation in any given character cell, but when I plot the locations of cells I see that more than 1 color changes between cells in each part of the screen (and since BG and MC1, MC2 are global, only the FG from color RAM can be the difference without advanced tricks — “racing the beam”). They also switch between wide pixels and normal pixels in different parts of the screen.
I’m excited to see how far you’ve come. I’d like to see more on the design side: data structures, algorithms, decisions you had to make or change for hardware convenience or limitations. I see you mention on your previous update “since your last video”. I don’t see videos linked. Can you point me to these? I’m also curious about your 3D view. It seems to now mix wide pixels and normal pixels on single scan lines. Are you racing the beam that aggressively or is the scaled image just deceiving me? Also your view looks stretched wide. It appears almost twice as wide as views in Bard’s Tale, Goldbox, and other CRPGs. Is that the blog doing that or did you go with a stretched aspect by choice?
Hi,
I’ll try and post more frequently. I’ve split the screen into 4 slices. The top one is text as is the bottom one. These point to one character set. The 2 middle multi-colour mode splits point to another character set so that I can use the a full 256 characters just for walls. There are 2 splits as I’m setting different background colours for the sky and ground just to get a bit more colour into the 3D view. I think a lot of C64 CRPGS use a full screen bitmap mode which I’m not doing. I really want a high res font rather than a multi-colour one. I could raster split the screen for this but I also thought drawing would become slower (even in assembly) as I would need to draw 8 bytes per 8×8 character rather than 1 byte as I’m doing with screen characters just now. All the later Ultima’s, original disk version of The Bard’s Tale and Dragon War’s use bitmap graphics. Some games like Alternate Reality: The Dungeon use raster interrupts – character modes for text areas and I think multi-colour bitmap mode for the 3D view. Pool of Radiance uses character graphics like me but without any raster splits to mix modes. I went with the stretched look so that I would get smoother lines in multi-colour graphics mode.
My videos can be found on YouTube as “CRPG Dev”. My latest video is at:
https://www.youtube.com/watch?v=q31s7bu51Gw