General update – March 2021

Belated Happy New Year. I hope that you, your family and friends are well and keeping safe during these difficult times.

It’s been a long time since I posted even though I have been up to various retro computing activities on and off since I last posted in November 2020. It’s almost 12 months that I’ve been working remotely now which brings with it challenges around space and separating home and personal life but I count myself as very lucky in that I am able to work remotely and still do my job. I know others have not been so lucky.

Since I last posted I began re-working my old Alternate Reality X (ARX) code on the Pi 400. I started to restructure the code to try and make it much tidier especially around the display routines and game loops. So instead of having lots of different display and game loops for different things I was moving code into a single over-arching loop with a number of different states depending on whether you were exploring, in an encounter or at the main menu. I made quite a bit of progress with this but it was hard going moving some very old code around which often broke many other parts of the game. I also added an option to scale the window size with a key press; X1, X2 and so on based on your preference.

I’m not really sure I had a clear endgame with this re-working of ARX such as a public release or whether I would use the reworked framework as the basis for an Alternate Reality inspired game. Part of this was me just wanting to make ARX a lot better organised from a coding perspective – more for personal satisfaction that anything else. I haven’t done any further work on this since the end of 2020 but I’d like to get back into some coding on this soon and try to bring this project to some sort of logical conclusion.

Alternate Realith: The City box art

I’ve done some retro gaming and emulation on the Raspberry Pi 400 and also tried out various alternative operating systems on the Pi 400 such as Twister OS – https://twisteros.com. One problem I have with the Pi is keeping track of what is on each of my MicroSD cards – bring back 3.5” floppy disks! At least you could put a label on them.

As many long time readers may know I’m a Commodore Amiga fan and after my Amiga emulation above I went ahead and bought an Amiga 600 from eBay which I’ve been spending some time working on and trying to get to the point where I can maximise my enjoyment on it gaming and possibly some light development. Not my favourite Amiga model by a long stretch but it does have the smallest physical footprint (important for me just now) and does have some features that make it very useable in 2021. Maybe I should have gone for an Amiga 1200 but they cost a lot more. I’ll post about this separately.

My “new” Amiga 600 running Workbench 2.1
Ultima VI – The False Prophet running on the Amiga 600

I plan to post more frequently in the coming weeks and months but feel free to drop me a note if there are any interesting retro gaming / computing things you’ve been up to or think I might be interested in. Take care.

More Pi?

I’ve recently bought a Raspberry Pi 400 which I am planning to use for most of my coding projects going forward. If you’re not familiar with this, it is a Pi single board computer but integrated into a keyboard with the relevant ports accessible at the rear very much like the classic computers that you know I love such as the Commodore 64, Amiga 500 and Atari 800.

I opted for the desktop bundle which includes the main Pi 400 computer / keyboard combo as well as a wired mouse, SD card, micro HDMI to full HDMI cable and a USB C power supply. It also comes with a nice beginners guide book which is in full colour. The keyboard isn’t bad and very compact. The Pi 400 has a faster ARM processor than it’s predecessors and 4Gb of memory as opposed to the 1Gb my Pi 3B+ had so some things which were a bit slow for me are that bit smoother on the Pi 400.

The only slight annoyance just now for me is that the composite/audio jack present on the earlier Pi’s is not included on the Pi 400 so I can’t connect up my recently purchased speakers without a HDMI to VGA splitter which isn’t producing a great picture on my monitor. I’ll maybe just pick up a monitor with an audio out jack for my speakers.

I’ve been very busy with work recently so not had a lot of time for my coding projects but I have a number in progress that I’m really excited about. I’ll not say anything else about these just now until I have a bit more to show.

The easy to use Raspberry Pi Linux environment is working quite nicely for my coding efforts but I’m very focused on ensuring that any coding I do is easily portable to other systems such as Microsoft Windows so I am continuing to use C/C++ with SFML, both of which are very easily set up on the Pi. I found Code::Blocks a little unstable on the Pi 3B+ but haven’t experienced any issues with it on the Pi 400 yet. I’ve also been using the Geany editor which comes pre-installed in Pi OS but requires a little bit more set up for me than Code::Blocks. SFML is extremely easy to set up on the Pi compared to Windows.

I’m looking forward to some enjoyable emulation on this version of the Pi such as some Commodore Amiga and classic DOS games and also in trying out some of the other operating system choices that are available such as desktop release of Ubuntu.

C64 CRPG: Adding a map

Since I last posted I’ve been doing most of my game development on a Raspberry Pi 3B+ under Raspberry Pi OS . There has been a little bit of a learning curve with getting this set up and some of the utilities I was using aren’t available under Linux but overall it’s working quite well. One of my biggest frustrations was getting a usable version of the Vice C64 emulator running. I failed to compile it successfully from source and ended up installing it using the PiKiss utility (https://github.com/jmcerrejon/PiKISS). Vice doesn’t seem to perform very well on my Raspberry Pi so I would appreciate any suggestions anyone can provide in how to improve its performance.

My Raspberry Pi 3B+

Most of my work on “The Citadel” has involved reorganising memory again. I’ve not successfully managed to move all my graphics into the top 16K of memory. The Commodore 64’s VIC-II chip can only see 16K of memory at a time and this top 16K of memory includes other things including the Kernel ROM. Usually these need to be “switched out” in order to access the RAM underneath but the VIC-II can apparently see the RAM underneath for character sets, the screen, bitmap graphics and sprites – very useful as I can continue to use the C64’s KERNEL routines such as print a character, screen the screen etc but also make use of the RAM underneath for graphics. This means that CC65 can use a contiguous block of RAM, around 50K just for program code and other data. This also means I was able to simplify my linker configuration file (as shown in my previous post) and remove all the segment references which have been a bit of a distraction when I’ve been using CC65.

The C64 Programmers Reference Guide

I’ve moved the other data files such as map and wallset data onto a C64 disk image and I’m loading these into memory when the game starts. This seems to be working well and my program file is now down to around 15K leaving plenty of space for extra game code.

I’ve also added the feature of switching between the 3D view and an overhead map. Currently this just shows the half the map (32×16 locations) regardless of where you have explored but I’m going to modify this so that the map only becomes visible as you explore. So you can now move around the map either in the 3D view or in an overhead view. I need to think this through a bit as both views need to have their purpose and be useful. I thought the game should switch into 3D view when you have an encounter or enter a shop (if you’re not already in this view).

Moving around the map in overhead view

I also plan to make the map more interesting in terms of better use of characters and colour rather than just using simple blocks. I think I can now focus on adding some gameplay and have a brief playable demo out soon with some initial encounters and combat included.

C64 CRPG Update: The Citadel

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.

More Commodore 64 CRPGs

Was it really September 2019 when I last posted here? Wherever you are I hope you, your family and friends are healthy and safe during the current COVID19 pandemic. I’m working remotely from home during this time which has its challenges but have done quite a bit of CRPG development since last year.

I’ve been focusing on creating a CRPG for the Commodore 64 computer. It’s my all time favourite despite its age and I find working within its limitations and restrictions a (mostly) enjoyable challenge. There are basically 2 C64 projects I have in development.

One game is currently called “Demon’s Isle” and is a classic Ultima style game with an overhead view and tile based maps. It’s a couple of months since I worked on it but I’ve lots of ideas on how to improve it technically to make it smoother and provide more graphic variety.

The other game doesn’t really have a title, although I have considered “The Citadel”. It’s a first person, single character game in the style of The Bard’s Tale, Legacy of the Ancients and Alternate Reality. Most of my time here has been working out how to make creating the map wall sets easy and quick to transfer into game builds. I have 2 brief videos on my YouTube channel illustrating the first person view but development has advanced quite a lot since the last video. I’m making steady progress with regular improvements and adding new features.

Both projects are written in a mixture of C code (using the CC65 compiler, assembler and linker) and 6502 assembly language. I am using assembly language for those parts of the game which need some additional speed such as the first person 3D view and overhead map view. These have both been significantly improved with 6502 code since my last video.

Exploring the streets

For “The Citadel” I’m currently using the C64’s multi-colour character mode which allows a mixture of multi-colour (4 characters per cell) and high resolution characters on a single screen but with a number of colour restrictions. I’ve successfully made use of raster interrupts to split the screen to use a mixture of display modes which gives me some further flexibility when it comes to display options such as more colours on screen and access to more than 256 character definitions on screen at the same time for drawing the 3D views as well as special location portraits.

My main concern just now is running out of memory before the game is well enough advanced. There are lots of areas I can recover memory from though and I haven’t implemented any sort of compression schemes as of yet.

Alternate Reality: A Return to Xebec’s Demise?

In early 2018 I came to the realisation that I probably wouldn’t be able to contribute much time to working on my port of Philip Price’s Alternate Reality (AR) series which I’d called Alternate Reality X (ARX). My last public release was on 21st May 2017 and personal issues had to take priority. Around the same time an enthusiastic AR fan made some changes to my ARX code and then started a brand new AR port written in Java. You can follow his progress at his webpage and on his YouTube channel where he posts update videos regularly. He’s put a lot of work into the project and I look forward to playing it when it’s available.

However, Looking back over my past blog posts and my journey developing ARX, I couldn’t help but feel a nagging desire to work on an AR related project of my own again. My time is still limited and I want to continue work on my own Commodore 64 game project though I have no hard deadline that I’m working towards on that project. Anyway I have a number of AR related ideas that I’m considering.

Enhance the original games

When I started ARX a number of AR fans expressed a desire for enhanced and expanded versions of the original 8bit games running on their original hardware. For me this would be the Commodore 64 and Atari 800. There are a number of positives about this approach and it would allow me to build on my recent experiences with 6502 assembly and coding for the Commodore 64. It has the major benefit that the games are already complete and I can just focus on enhancements without having to recreate code! It would also be an opportunity to hopefully unravel some of the mysteries of Alternate Reality that have eluded players for over 30 years by looking more deeply into the code and mechanics.

However, Not everyone wants to run games on old hardware. To address this I think it would be feasible to package up any enhanced versions with a suitable emulator to make for a smooth, single click experience on a modern operating system. There would of course be nothing to stop players from using their old hardware if they have access to it or emulator of choice on modern systems.

Writing for older systems does lead to some limitations that I think for me could actually be a positive. The hardware and storage restrictions mean I won’t go off on any tangents or wild goose chases, helping me to stay focussed on the core gameplay and playability. I have lots of ideas of features and improvements I would like to add.

This would be a challenging project with a high learning curve for me. Fortunately in 2019 we have a wealth of information, online communities and tools to help us understand the games and speed up modern development for these systems.

New scenarios

One option with a lot of crossover with the project above would be to build new scenarios using the core code from The City or The Dungeon as the basis for a new scenario. It should be feasible to replace the data for graphics, maps, locations, encounters etc with new content. Obviously some new game logic would be required as well for quests and special locations. Opening up and creating The Arena and The Palace within the existing areas within the game maps would also be a possibility.

Revive Alternate Reality X

If I were to consider this then I would be taking some time to review what I had done before and probably strip away lots of the code and partially coded features to make for a more solid foundation. This would take some time. I would probably remove the option for the enhanced graphics and focus solely on gameplay and new features. This doesn’t mean there wouldn’t be new graphics and sounds, just that they would be in keeping with the original 8bit style (or with minor improvements).

I would probably modify the code to make it straight C to give me the option of porting it back to the 8bit machines using CC65 as I wasn’t really doing any “proper” C++ coding anyway. The disadvantage of this approach is that I would have to recreate code from the original game’s 6502 assembly code or through observed behaviour through gameplay.

I’d welcome your thoughts or any other ideas you have that I haven’t mentioned.

My Commodore 64 CRPG – August 2019 Update

Though I haven’t posted here on the blog since April, I’ve been busy working away on my Commodore 64 CRPG. Since I last posted I became a little side-tracked learning how to code certain things on the C64 as well as considering some different game styles.

At one point I was interested in creating some sort of CRPG / Adventure / Choose Your Own Adventure hybrid. I still like this idea but I eventually came back to the idea of doing a more traditional tile based CRPG – I think this is still my favourite style of CRPG although I was also tempted to go for an Alternate Reality or Bards Tale first person view – maybe next time!

I spent quite a lot of time experimenting with the various graphic modes on the C64, coding up examples thinking about their pros and cons which I’ve discussed here previously. I also worked out how to locate and reserve space for graphics and screen displays using CC65. This is the C programming environment for 8bit systems I’m using. It also includes a full assembler so I can freely mix my C and assembly language code as required in a single project. I’m only using it for the C64 currently, but it also supports platforms such as the Atari 8bit and Apple II machines. It’s taken me a bit of effort to get to grips with it but I’m enjoying working with it now.

I also spent some time using the tools in the C64 VICE emulator ( http://vice-emu.sourceforge.net/ ) and the CharPad software ( https://www.subchristsoftware.com/charpad.htm ) to analyse how some of the C64 games I liked worked and used the C64 to build their displays. Some like Alternate Reality use a mixture of modes with raster interrupts to split the screen, Ultima IV a single high-resolution bitmap screen and Legacy of the Ancients the C64’s character mode. As mentioned these can all make the game look different as well as provide different levels of flexibility, use of colour and use different amounts of memory.

In the end I’ve settled for using the C64’s character mode, initially with just high-resolution characters rather than multi-color mode. This mode allows you to display up to 256 unique characters on the screen at a time across the 1000 cells which make up the display (40 x 25 characters). Using CharPad these characters can be made up into tiles ( 2 x 2 in my case) and then used to build up a map. I can use all the C64’s 16 colours on the screen but I’m limited to a single colour on a common background for each screen location. I plan to get around the limited number of characters by loading in additional character sets for different regions.

CharPad – Showing characters, tiles and a map in progress

Using CharPad I can now export my characters, tiles and map into binary files which I’m loading into my C64 program. Currently the tiles are heavily Ultima influenced but I’ll try and make them more unique as time and my limited artistic skill allows! I also hope to make use of the C64’s sprites for characters and possibly encounters. On the C64 you are limited to 8 of these without more complicated sprite-multiplexing coding which I suspect may be a bit of a challenge for me. Next time I’ll tell you a bit more about the game as it currently stands and pose a few questions I’d like to get your thoughts on.

Moving around the map in my C64 CRPG

C64 Bitmap mode…or not?

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.