I guess it is was a bit unexpected, because there are other projects I could be working on. For example, the long running –and often neglected– “Outpost” for the ZX Spectrum 48K, a few ideas for DOS –including some sweet code to support CGA and EGA–. But that’s how creativity works: when inspiration comes, it is hard to not listen.

The working title of this new project for the Amstrad CPC is “The Heart of Salamanderland”.

The name is the work of my younger son, that is helping me with the script and the framing story, which is great and also hard!

I’m targeting the Amstrad CPC, 64K in a single load, loading from cassette or disk –there will be a CPR version for the GX4000 as well–, and graphics in mode 0.

I’m building on top of one of my two main engines for this type of game. I’m not sure if it is the right one, because it is performant but uses quite a lot of memory. At least I’m sure it will allow me to pack plenty of action on each screen.

I have been investing on a new map renderer based on meta-tiles of variable size and I think we may end with a good-sized game thanks to that –I wrote about encoding schemes for map data some time ago–. I’m not too stressed about it: if the game is not too big, I can make a sequel if people like it.

This project came about because I the last couple of months I read two series of fantasy books by Brandon Mull: Fablehaven and Dragonwatch, and I loved the adventure mood. So the game is a bit inspired by those books –the main character specially, I’m tempted to call him “Patton Burgess”–.

Another big inspiration is the classic Castlevania, that is a series that I love. So I gave Patton –let’s call him that for now– a whip, and in a way it works fine with Mull’s ideas. It is just that we don’t fight Dracula and friends. The quest is different, we are trying to find an old relic: the Heart of Salamanderland. And there will be undead, wizards and demons. I may be mixing realms, but that’s OK.

It is currently a work in progress and there are still things that aren’t clear. The usual memory constraints apply, so I have to decide what gets in and what doesn’t. But at least I would expect an action platformer, with a good number of interesting enemies, a few screens to navigate, and some puzzles so solve. All in my style, that is something that can’t be changed I’m afraid.

I usually post development updates on my Mastodon account and there’s a thread on CPC Wiki.

I have never used a game engine before and, when working with 8-bit, I have this thing of starting from scratch to learn the machine, even if sometimes there are good libraries available.

I’m not sure what I was expecting when I tried Godot. Works perfectly on Linux and my machine, and it is open source, so two of the important boxes for me are ticked.

It all has come about because my 6yo son has been programming in Scratch –it works on the browser, but not that great on Linux; there’s Scratux but has its problems–, and we have now when is “TV time” that he wants to watch videos about programming. So we ended watching a bit about Godot, so here we are now learning how to make a 3D platformer. That escalated quickly!

My first impressions by looking at how the 2D part works is that there are forms, a lot of forms, which I see it can be an advantage –like it was a good thing for some people in Visual Basic or Delphi–, but I always found it a bit of a problem as things grow beyond some size. But then, you can control a lot –if not everything– from GDScript that looks very much like Python. So you may not need to deal with all those forms, and that can be a good thing.

In any case, when I was watching to some tutorial about the 2D part of it –because 2D and 3D are almost like two different engines–, I was thinking most of the time that I could make it simpler. But can I, really? I guess if I look at all the work I put into one of my small engines, is not that much. However, I make an engine focused and specialised in the needs of the game at hand, while Godot has to support lots of different takes of a 2D game.

And then is when we looked at the 3D part, that doing it from scratch is something I have given up since my awkward attempts some years ago; and I see the potential. Which to be fair is probably what people that can’t (or won’t) make their own engines from scratch may feel when they look at the 2D part of Godot.

At the end I suspect it is going to be down to the models, the textures, the assets; because looks like Godot has what is needed and it is very accessible.

A different topic is finding how to do it. The books don’t look like a good option because Godot is changing quickly –version 4 is quite new–, and there is also a lot of content with questionable quality abusing the idea of people that don’t know better and want to make a game. I haven’t been lucky finding written tutorials, because we live in an age that people will make a 30 minute video on YT for 5 minutes of actual content –all monetised, like, subscribe, and hit the bell; and there’s my Patreon–. So there is mostly videos, and those aren’t great for reference.

Anyway, we are having fun, even if we haven’t made anything significant. I guess at some point I’ll start looking at Blender again and, with a bit of lucky, it won’t be the end of this. But Godot is nice and has potential, I like it.

A couple of years ago I released the Return of Traxtor source, because I thought it could help people willing to start making games for the CPC writing things from scratch, and also for some historical value: it was my first good enough Amstrad CPC game.

Since then I have been busy and I must confess I totally forgot about open sourcing more games –although Gold Mine Run! was open source from the start–. I have different engines for making CPC games that I consider current, and unfortunately not that many ideas –or time– to make games, so it is kind of sad that the code is not being used in new projects.

From my Amstrad CPC production, Kitsune’s Curse is probably my favourite, and it uses a very special engine that is intended to make mid-size games on 64K by using as little memory as possible. It implements what I called mini-buffers, as opposed to a large buffer covering all the drawable area.

It tracks dirty tiles and minimises the amount of drawing on the screen, which is nothing new, but by using small buffers that are dynamically allocated so background and masked sprites can be drawn to it, the memory use is reduced drastically. In “Kitsune’s Curse” only 2560 bytes are used for mini-buffers, compared to the 16384 bytes of a hardware back-buffer.

Yes, that makes things complicated and it affects performance, but “Kitsune’s Curse” had 60 screens, 8 different enemies, 64 tiles, and all in 64K with one single load; and can handle up to 10 sprites of 8x24 pixels. So I think it was a success!

I used the same engine in The Dawn of Kernel as well, but then I wrote two more engines: one focusing on performance (used in Brick Rick) and another one for vertical scrolling games (used in Hyperdrive). I should make more games and less engines, isn’t it?

In any case, the source code of “Kitsune’s Curse” is available on this git repo. Like in my previous releases, this is how the code was when I released the game in 2020 –although I made some effort to update the tools, so things compile in a current operating system and no Python 2 is required–. It is not a framework or a library. Yet I think it may be an interesting read or a good base to start new projects, who knows?

I have documented most of the generalities of the code in the README.md, specially the interesting bits regarding the engine. There is a lot of Z80 assembly but, when possible, there is also the equivalent C code in a comment. Hopefully that will make understanding the code easier!

Over the last few years we have enjoyed some great games that included the source code, and I have learned a lot from them. I’m glad that “Kitsune’s Curse” is joining that club.

What do I mean by final software? I haven’t put much thought on a definition but, if I had, it would be around the idea of software that it is finished, that its utility and usability doesn’t changed over time, you can go back to it an build it at any time, and it is as good or bad as it was when it reached its final state.

I have been thinking about how non-final SpaceBeans is, even if I have decided that is feature complete and that I won’t add more functionality, I can’t stop updating it because its dependencies are non-final and there will be bug fixes and security updates.

SpaceBeans is a Gemini server built using Scala –and a small number of dependencies–, the Java way of building software means that the end product is a ‘JAR’ file that includes all dependencies; so it is my responsibility as project maintainer to have those updated. If I stop updating the project –updating dependencies eventually leads to API changes that require changes in my code–, it is possible the software can’t be used because security.

This wouldn’t happen if the end product was a package for example for Debian –ideally included in the distribution itself–, so it would be the maintainers of this fantastic operating system who would do the work of keeping the dependencies –and my software, by porting fixes– free of security issues. I think this is a much better model.

I would say this is something I kind of get on my games for 8-bit systems. The machines I target are final –their spec won’t change–, and thanks to open source, you can always get the compilers and tools I used to build the software when I worked on it, and build it as it was build at that time. And the resulting binary is final.

In the case of SpaceBeans, it is mainly down to the dependencies. If your project is small and focused enough, I believe you can get to that final state where no more features are needed and there aren’t any more known bugs –and it could be even bug free, I guess–, as long as your dependencies don’t change. Because a third party like Debian makes it happen, or because you have little or no dependencies, or your software has a limited attack surface so security doesn’t really matter.

Recently I read in Mastodon about slow software, which sounds similar to some of the ideas behind permacomputing. I’m not sure if any of them deserve a movement, but some of their proposals are very interesting and worth learning about.

According to git, it has been 12 days –not really, because this is when I have free time–, and 15972 bytes in total. The Return of Traxtor for DOS is now available to download!

It has less colors than the Amstrad CPC version –and no music, even if the PC speaker sound effects are kind of cute–, but it plays really well. Probably the most playable of all the versions, in my humble opinion. And possibly, the less buggy as well.

The CGA is fun to program, and I’m very impressed by IA16 GCC. I wouldn’t mind making another game for the original IBM PC, but not sure if it is worth it. For whatever reason, this early age of PC gaming isn’t that appreciated. And I’m not sure is just the CGA palette.

I may try the middle ground: find out how to program the EGA and add some Ad-Lib music!

I was reading this post by Foone on Masto:

Hot take: DOS gaming is not one era. It’s two.

Before and after 32bit extenders.

And I totally agree. DOS games, and DOS software in general, had a first age that was 16-bit, and a later one that was 32-bit and lasted until around 1997.

My first DOS game –or shall I say my first released game for DOS– was Gold Mine Run!, that is a 32-bit game. It requires a 386 or later, VGA and Sound Blaster; which is very different to what we had in the first age of 16-bit DOS.

So when the DOS COM Game Jam was announced, I thought: wouldn’t it be fun to make a game for the early IBM PC?

The 64K limit is not a big deal if we consider that most of my 8-bit games require less than that –even if you target a machine with 64K of RAM, that includes the video memory as well–. I could potentially port any of my 8-bit games to PC and it should fit in a COM file, embedding data and all.

I decided that I would target:

• MS/DOS or compatible
• IBM PC (8086)
• CGA
• PC internal beeper
• All in a COM file (that means 64K or RAM on disk; I could use more memory if needed), so I can submit it to the Jam!

This is basically what I had available on my first PC, an Olivetti Prodest PC1.

But then, I didn’t want to stress myself again and potentially not submitting the game because I didn’t have enough time. I hadn’t programmed the CGA before, I didn’t know if I could comfortably cross-compile from Linux to DOS and 16-bit. So I went for a simple –yet fun!– game: The Return of Traxtor. I have implemented the game a few times –my favourite is The Return of Traxtor for the CPC–, so it should be fine.

At the end, it wasn’t that bad, even if the CGA is fiddly and closer to what you would do on a ZX Spectrum –encodes 4 pixels in one byte– than what you would do on a VGA.

My strategy is not that different to what I did in “Gold Mine Run!”:

• Using build-ia16 to have a version of GCC that targets Intel 16-bit (8086) and can generate DOS binaries (including COM) on Linux.
• Embedding the data in the binary using objects and the linker (see for example raw.py).
• The keyboard controller is the same –although I had to rewrite it to use real mode interrupts, fun!–.

The first part was getting to draw on the CGA, following the docs I could find –see: Colour Graphics Adapter: Notes–. It required writing some assembler because of the real mode memory addressing, but I got it working reasonably fast in an evening. Then the interrupt handler for the keyboard was tricky as well, but after that, all it was writing plain old C code.

So far the project is progressing nicely –see my Mastodon account–, and looks like I’m going to finish a good version of the game and on time.

The name is kind of misleading, because is not a port to DOS of my ubox MSX lib, but I call this sort of library “ubox” when I’m building them –even if it is for internal use; they exist for Amstrad CPC and ZX Spectrum–. I hope it doesn’t cause any confusion.

After I released Gold Mine Run! I knew that if I wanted to make another game for DOS, I had to extract what I had written for this game and make it a library.

It is true that I could have made part of the work when I wrote the game, but I decided early on during the development of the game that I wouldn’t waste time thinking about abstractions or reusing code when it wasn’t clear that I would be able to finish the game. Now that there is not uncertainty –the game is finished!–, it is time to do the boring stuff.

And it is done, so I have published a repo with ubox lib for DOS. It is pretty much what I used for the game, with some extras –like an asset manager– and, in some parts, cleaner code.

I don’t know if it can be useful to anybody else, but I guess that now that I have the library, I will have to make at least another game to justify the effort. What I’m sure that I’m not going to do is maintain the library as a project to facilitate people to make DOS games; because I did that with the MSX library, and I haven’t enjoyed the experience too much.

So there isn’t documentation, although the library is tiny, so anybody should be able to read the code and figure out how it works, and even adapt it if needed. I’m happy for people to send bug reports and fixes, but I don’t want it to grow in directions that I don’t like –or, specially, that I don’t use–. Feel free to do whatever you want with your version of it, respecting the license (that is).

Regarding what I’m going to do next for DOS, I’m still undecided!

Last night I released my first game ever for MS/DOS: Gold Mine Run!

I mentioned here when I started that I had used some of the tools back in the 90s, and that I had the crazy idea to stream the process of making the game (the videos are in this playlist).

Although the engine and the stream were completed about two weeks ago, that wasn’t really a game: it needed level design and music, both things that I didn’t want to do on the stream.

At the end, I decided to add 30 stages, which is about right considering the amount of content –there are limited enemy types–. I didn’t feel like I was repeating myself too much when designing the stages, because there were enough components to keep it somewhat fresh. Yet, it is a small jam game anyway.

I did some gamedev in DOS back in the day, and I feel a bit like I am 25 years late to this, but still had a lot of fun making this game. Without my experience in the last 10 years I wouldn’t have been able to produce Gold Mine Run!, that’s sure. But then I have the feeling I could have made the same game using C and SDL2 –or even Haskell!–, and target current platforms (Linux, Windows and Mac at least). Would it have been the same game? Probably!

Now that this project is out of the way, I can pay more attention to my TODO list. Exciting!

Someone what asking what do you put in a personal website, and it is a shame I can’t remember / find where it was.

My answer was in the lines of just put together stuff about the things that you are interested in. And lately I have been thinking that this has been my personal website since 2002, but perhaps it doesn’t feel like it now.

In my last re-design –that’s something you do to your personal website every now and then–, moving from a dynamic site managed with Django, I put my games front and centre. Perhaps that is why it doesn’t look that much like a personal website.

In reality, my notes section –that I added as result of my thoughts on digital gardens– is what feels more like a personal website. It is mostly work in progress content about things that are interesting to me right now, like for example my experiments with Sinclair BASIC.

This is all subjective, really. May be what for me is a personal website is not what a personal website is for you, but in any case, I think it is important that there are people discussing these topics, and hopefully doing something about it. That is how we escape the big tech companies of 2.0 and their enshittification –my local dictionary didn’t recognise the neologism, so I added it because it is here to stay–.

It is refreshing to click on the surprise link of Wiby and get a different 1.0 website every time, and is not just because of nostalgia, but because all that information should have never been a Facebook page, for example.

And the excuse is not that things cost money and you have to give your freedom away –or become the product–, because you can always find free hosting –and also learn something–.

These are a couple of options that I recommend:

• ctrl-c.club: part of the tildeverse it is a very welcoming community where is very easy to create an account and host your website.
• Neocities: is it a social network? I guess the original Geocities was a bit like that too. I prefer the club; but this is probably easier to get started.

The game still needs some work, though.

I mentioned here that I was making a game for the DOS operating system, and that I was going to stream the process. And I did it!

All the videos are available on this playlist on YouTube, a total of 20 videos where I build most of the game from scratch. I didn’t do pixel art, for the most part, and there were a couple of bits that I wrote off camera because it was about solving problems that I didn’t even know if there was a solution, and that type of troubleshooting on stream is very boring.

The series had some interest, considering that I don’t have that many followers and not many people watch the sessions live –there seems to be more views when I upload the videos to YouTube–. I enjoyed the few occasions when there were people on the chat and we commented on the stuff I was coding, which is one of the big reasons to stream my sessions –the other one is basically sharing, so people can learn or perhaps get inspired–.

I have been consistent as well, streaming Tuesdays and Thursdays from 20:30 GMT for 1 to 2 hours. But I had to add some sessions in between, and that was the main problem with this project: the time was too short.

I have made games with similar scope before, and it took me from 3 to 4 months, so trying to squeeze the same in month and a half… it was probably too much. Besides, this is a new platform and I didn’t have an existing working codebase. That was specially problematic with the sound and the engine design –that at the end works perfectly on a 386DX 33MHz, but it was hard to get there–. In the 8-bit systems I make games for, I don’t start from scratch any more!

As consequence, I won’t be submitting the game to the Jam. Which was one of the possible outcomes.

The game is not finished, and over the next 2 to 4 weeks I will be working on the music and level design, and after that, Gold Mine Run! will be released. Watch this space.