It doesn’t feel that long ago, but it has been 2 years since I moved some projects to GitLab. After that I started self-hosting my git repos, so there always was the question of GitLab in the back of my mind.

I never liked the user interface too much, it feels slow and bloated, but in general the feature-set is nice, and it definitely works for me. But then GitLab has been making changes that I didn’t like too much –even if they didn’t affect me directly–:

• Open source projects need to apply to special programme, or they will be moved to the free tier.
• They have changed the limits on the free tiers, and some aren’t great –but it is free, so fair enough–.
• They are copying the bad things I didn’t like in GitHub (achievements? why?), including a push for AI –because all has to have AI now!–.
• Their paid tiers are too expensive, meaning that you are in the free tier or you are a business that can justify the cost.

Considering that I’m privileged because I have my own servers and I can self-host, it doesn’t make sense for me to keep using their service if I’m not happy with them. I don’t want to endorse them either, which is something that you indirectly do when use a free service.

The projects I have left in GitHub (50 repos) are all forks, archived and/or I’m not actively working on them –and if at some point I resume some of them, I’ll move them to my servers–. The projects in GitLab, however, are active. So I have to make changes.

I have moved SpaceBeans already, and ubox MSX lib should come next.

I know the move will affect contributions and will make some things harder –although mostly because they will be different–. And that would be true even if I was moving to another hosting service, because that would likely be SourceHut, and it relies on email workflows.

So it is happening: I’m moving out of GitLab. I’m planning changes on the MSX libraries, and that is probably the perfect time to move things around. Now you know why.

I don’t think it is a surprise that a big part of the community around Hacker News is against the idea of copyleft (e.g. licenses like the GPL, AGPL and LGPL to some extent). They are a clear example of what is the result of the corporations getting involved in open source: the more permissive is the licensing, the better. So they can take, and don’t be forced to give back.

Is not an easy topic. When I was at University there was a whole course to learn about laws around software, and that included licenses. It is very easy to get confused, and people often argue about free software vs open source, perhaps because the Free Software Foundation has often been divisive in their way of promoting the philosophical side of open source.

What is copyleft? From Write Free Software (licensed CC-BY 4.0):

Copyleft is a licensing tool unique to free software. It is designed to encourage the proliferation of free software and protect free software from being incorporated into non-free works. This works by giving you not only the right to share your improvements, but the obligation to share your improvements under some conditions. It is very important to understand these obligations when re-using copyleft software in your own work.

And that obligation is what is referred as virical, and what the corporations don’t like. Specially in today’s take of computing, with cloud computing and software as a service making them all that money.

I used to be an open source / free software advocate 20 years ago, but I stopped because, at some point, it looked to me like we had accomplished some of our objectives (and I guess I got tired). But the truth is that things aren’t as good as they could be.

What was always front and centre was user freedom, something that open source ideas don’t really care about. Not because the licenses are different –because most open source is free software–, but because what it was always important was the copyleft.

So we need more free software, and Write Free Software is a very good resource that explains all you need to know –not really, you don’t need to know all that; but if you make software, it should help you–. It isn’t as confrontational as the Free Software Foundation resources, and definitely easier to read!

I guess is a sign or getting old when we stop tinkering with Linux distros, desktop environments, and windows managers. After Gnome changed to their new idea of desktop in Gnome 3 –back in 2011–, I tried hard –and for an embarrassing amount of time, considering I wasn’t happy–, and finally landed on XFCE. It was a weird time in the Linux desktop space.

XFCE was a bit different to the Gnome 2 experience I liked, but when I tried XFCE 4 on Debian Jessie it felt like home.

And don’t get me wrong: it has never been perfect. There are some issues that have been bugging me for years, like the screen lock getting stuck after suspending –and because it is rare, plus not being clear who owns the bug, it seems unlikely it will be fixed–, but as a desktop environment it is out of the way. What else can you ask?

Then I know a lot of people using tiling window managers, to the point that I may have been the only one not using one already. I had a few key bindings in XFCE to give me some limited features of that type of window management, but I was wondering if there was something I was missing out.

So I finally tried i3wm after some research, because it looked like the most user friendly –despite having a steep learning curve, like all of them, but that’s true for most power tools–. I installed it alongside my XFCE, gave it a quick go, and I put it on the back burner because it wasn’t the right time to disrupt my workflow –I was finishing Hyperdrive–.

Until last week, that I gave it another go, and I love it.

i3wm feels fast and responsive, and being used to the vim + tmux experience, it felt a very natural way of working. Sure, it needed some effort to configure, and I don’t think I’m finished with it, but I’m getting there.

Currently I still depend a bit on having XFCE installed, which is not a problem, because I still use Thunar for example to browse files. If at some point I install a system from scratch, then I will do a more focused selection of applications I really use and I may not need a full desktop environment that I won’t use.

My i3 configuration is available, and it will need some time to get close to that perfection I’m talking about. I have passed the test of streaming with OBS, which was the part that I initially thought it would be “harder”.

However, currently I have a couple of issues:

• I’m using xfce4-screenshooter to take screenshots, and works beautifully, but it doesn’t give me the option to put the screenshot in the clipboard; which is mildly annoying.
• I’m using kazam to record videos, and when I try to select the window to capture, it goes wrong and I can’t see the windows. If I click where the window should be, it does the capture just fine.

Other than that, I’m converted already. And if (when?) I have to move to Wayland, I can move to Sway without much work –other than not using XFCE apps unless it has Wayland support by then!–.

So I guess I’m not that old yet, because there’s some tinkering spirit still in me.

Update (2023-07-08): because I got a couple of emails mentioning it and I had solved “the issue” already, let me update on the screenshot “issue”.

Just run XFCE’s climpan! In X11 there is no shared clipboard, so you need an application that can keep that data when the screenshot tool is gone. My i3 config has now:

# Clipboard manager
exec --no-startup-id xfce4-clipman

Then you just need to configure it to your personal taste. Because XFCE didn’t show the icon of the application when it was running, I didn’t know it was there.

Thanks again for the emails and the i3 tips!

So it all started because a copule of people I follow on Mastodon are into DOS game development, and they are doing very neat stuff. I looked at some of the games and I saw that DJGPP is still around! It was my first ever contact with GCC, GNU and free software –although I didn’t notice that last part, or I didn’t understand it–. It surely changed me, like having a ZX Spectrum as a kid had a lasting effect on my career, before I started using Linux.

I made a few programs with it, with different levels of success. Some of them even got “published” on a magazine at the time –via one of the sections, you could send them your stuff and they would comment it and include it in the CD-ROM distributed with the magazine–. Unfortunately I never managed to finish a game.

Today I’m better equipped on the knowledge side of things, and I have a few finished (and released) games under my belt. I also think I have better tools and computing environment today, so I thought: would it be that hard to make a DOS game today?

That type of question has always worked for me. That is how I got started making ZX Spectrum games in 2014, and a few other systems after that. I always answer if I could and never wonder if I should, which I will leave to you dear reader to decide if is a good or a bad thing.

Besides, recently I have passed the 4 years mark doing streaming of my coding sessions –with 40+ videos uploaded to YouTube–, and I thought it would be a nice experience to try and make a simple DOS game on the stream. There is also a DOS game Jam happening, so it is all there!

Obviously, this is yet another project, that adds more distractions and things to my already long TODO list; but considering that it should be quick, there is nothing to worry about, isn’t it?

It won’t be a tutorial, but I tend to explain what I do on the stream, and the source code is available. It all depends on the skills of the person following the series, but it could work as a good introduction or, at least, as inspiration.

That doesn’t mean all the streams will be “making a DOS game”, but until the game is completed, there are chances they are the majority of the videos. Nothing is happening with my unnamed Haskell game for PC, the TR8 fantasy console, or Outpost for the ZX Spectrum. Those are still on and healthy.

I’m streaming the sessions on my Twitch channel and the videos will shortly appear on this playlist on YouTube, so there are two ways for following the project.

I got the inspiration from the fantastic rasm –a Z80 assembler–. rasm supports a number of formats for input and output, and the input goes way beyond the “include” we can find in some assemblers.

As part of my TR8 fantasy console I have implemented .incpng "file.png", that does the following –from the docs–:

.incpng “filename”
Read the PNG image and add the content to the output at current position. The image colors will be matched with the TR8 palette and any non-matching color will be considered transparent and the index 128 will be used.

So it is like a “include binary”, but it understand and reads a PNG file, including the pixel data in the assembled output.

It converts the image to red, green and blue triplets –RGB values– and maps them to the EGA default palette –which is the palette I’m currently using–. If a RGB value doesn’t match the EGA palette, the tool uses 128. That value is used with the blitter if transparent is enabled to treat it as transparent –otherwise it will be black–.

It is so convenient to use! But obviously, this is only because I’m writing the assembler myself –and it has many limitations, currently–. Using other compilers, very often the options are very limited, and that is when my conversion tools written in Python save the day.

Over the years I have been playing with the idea of writing interpreters and compilers, and I say idea on purpose, because I haven’t been very successful at it. Something similar happens with operating systems and virtual machines, although I have been a bit better with the latter, I had many projects started over the years without results.

Considering that I have been doing game development consistently for almost 10 years now, the idea of a fantasy console is so perfect if you want to write those, that I would say it was almost inevitable I made one.

And that’s why the TR-8 fantasy console came about.

It is all very work in progress and, instead of spending a lot of time planing and designing without getting to make anything, I decided to start implementing and put together things as I go. And you can tell when you look at the design of the 8-bit CPU.

Without getting in too much detail, an example program:

.org 0

; address of the frame interrupt vector
.equ INT_VECT 0xff00

    ; setup an int handler so we
    ; can use the frame int to sync
    ld a, >INT_VECT
    ld x, <INT_VECT
    ld b, <int_handler
    ld [a : x], b
    inc x
    ld b, >int_handler
    ld [a : x], b

    ; enable interrupts
    cif

    ; loop filling the screen with one
    ; colour cycling the whole palette
    ld b, 0
loop:
    call fill
    inc b
    and b, 15

    ; wait 1 second
    ld x, 60
wait_loop:
    halt
    dec x
    bnz
    jmp wait_loop

    jmp loop

    ; fill frame-buffer with a color in reg b
fill:
    ld a, 0xbf
    ld x, 0
    ld y, 0x40
fill_loop:
    ld [a : x], b
    inc x
    bno
    jmp fill_loop
    inc a
    dec y
    bnz
    jmp fill_loop
    ret

int_handler:
    iret

That may give a bit of a taste of what is TR-8.

At the moment I’m working on three essential components:

• a virtual machine for the CPU
• an assembler
• a “player” that uses the virtual machine and provides the other bits of that make it “a console”

All written in C –hopefully portable–, with SDL2 for the player.

As I say, it is a work in progress, but this is what I have decided so far:

• Display: 128 x 128 pixels 16 colors (using the default EGA palette for now)
• Memory: 64K
• CPU: TR-8, 8-bit, 8M instr/sec (for now, likely make it slower when I add the hardware blitter)
• Sound: TBD, likely to be either a PSG or perhaps FM (OPL3?)
• Programming: ASM

The TR-8 CPU is inspired by the 8-bit CPUs I have programmed: the Z80 and the 6502; but also the MIPS (specially on how I’m encoding the instructions). This is not about a good design but about having some fun.

The main features of the CPU are:

• 16-bit registers: stack pointer (SP) and program counter (PC)
• 8-bit registers: 4 general purpose registers (a, b, x, y), flags register (F)
• frame interrupt (60Hz)
• port based IO (very Z80)
• a frame buffer (16K of RAM as video RAM; I thought about implementing a VDP but then I realised I was copying the MSX!)

I don’t know how far I’m going to get. I guess I will implement enough to feel satisfied, perhaps making a game for it, and that’s probably it. I don’t expect anybody using this, when you can make games for actual 8-bit machines –or more user-friendly fantasy consoles like the Pico-8 or the Tic-80–.

I think this is my first ever recently type of post, let’s see how it goes!

Trip to Spain

We spent a bit over a week in “Arenales del Sol”, in Alicante (Spain). Visiting family, enjoying the good weather, the beach, and resting. It was pretty good.

The less good part was that I couldn’t met old friends that I haven’t met in in years, because Arenales is kind of isolated and we had limited access to a car. Next time!

I didn’t write a single line of code on that period, at least on a computer. I wrote some ideas for a fantasy console, but all with pen and paper, so it doesn’t count!

IRC is the new IRC

I have been using IRC since February. I’m surprised because it doesn’t feel like was that long, but weechat logs don’t lie.

I started using it by the time I stopped using Telegram. We decided some time ago to only use Signal for the family communications –and a couple of old friends that happen to have my phone number–, or I should say my sister decided because she moved my parents from Google’s Hang out (or Meet or whatever is called this week!).

Closing my Telegram account wasn’t easy, because I had a few friends there that I don’t think I will talk by other means –people don’t do email any more–; but I don’t trust Telegram. Too big and freemium, not fully open source, and an unclear business model are a few of the reasons. Signal is not perfect, but is better.

IRC has been OK, I’m on a few channels and most are basically idle, with the exception of #haskell-game and #gamedev. The latter not being too different to some Telegram group chats I used some time ago, focused on a topic related to development, with the good and bad things –specially a lot of people that don’t do any actual development, so they add noise to the channel–.

Looks like everything is on Discord now. I guess if I really wanted the interactions, I would join one of those servers. Or I would still be using Telegram. It is complicated.

Persona 4 has gone cold

I started playing Persona 4 on the PS2 back in January, and I loved it. Well, I still love it, but it has slowed down too much and I find it hard to keep playing.

The downtime between events on the main story, where you are supposed to do the school routine, increase your stats by doing different small quests and interact with different characters, and grind; all got a bit shallow at a times. Like the school camping trip, with some conversations that help building the characters, but it was around 30 minutes of just press X to continue. I don’t want all combat, but it has become a bit dull at this point with not much feeling of progress.

There has been another event now that is part of the main story, so things are going back to be more interesting, but I’m not looking forward to keep playing.

So after 25 hours I’m about a third of the game. It is still an amazing game, and just checking a saved game to write this post and listening to the music it almost makes me want to play it, but it is a long one!

Revived Outpost and Haskell is fun

I mentioned here that I’m working on a game using Haskell and SDL2, and I used the “Outcast” sprites as a reference. So Víctor was wondering what happened to my ZX Spectrum project, and we reviewed what I had and together we completed the design of the remaining puzzles.

There are so many cool things on that game! It would be a total shame if that never gets released, so I have restarted the work on the project and things are progressing nicely.

It won’t be the same game I originally envisioned, but that’s probably for the best to be honest. The project is more focused now and I know exactly what is left to be done, although some of the ideas Víctor suggested are going to be tough to implement. But that’s OK, it is going to feel fresh. Do game design like you are 6 years old!

So there will be a ZX Spectrum 48K release from me in 2023, and the Haskell project keeps going. I have been streaming on my Twitch channel and some of the videos are in my YT channel, and it is a lot of fun –programming Haskell, the videos not that much–. It won’t be a big game. I don’t even know it if will be fun to play, but it will be finished this year –my first PC release in ages!–.

And that’s all that has happened recently.

I wrote here about gamedev in Haskell, but I didn’t have much to show. I was still exploring some ideas and I wasn’t sure it was going anywhere.

Now I think the engine is taking shape and there’s a public git repo, but I forgot to mention it here. For some reason, when I talk about these things in a channel, I forgot to do the same in the others.

Currently we have:

• My Mastodon account, where I tend to update often if I don’t stream, but I always forget to announce when I’m streaming.
• My Twitch channel, where I stream when I’m in the right mood –and I’m not too tired–. Sometimes I just want to code, and making it publicly requires considerably more energy.
• My coding sessions on my YouTube channel, where I upload a copy of some of the Twitch stream –Twitch removes the past stream videos after a while–. I don’t like Twitch too much, but I don’t like YT either; I seem to get more views and comments on YT though.

And, of course, there is this blog. So I guess a good way of following this project could be following me in one of those, and probably not this blog, because I’m not consistent enough!

The engine is nothing too special, other than it is written in a functional style, and in Haskell. I haven’t had to do anything hacky to make it work, so for now I’m pleased with the code. However, I’m still learning and I wouldn’t recommend the code specially to anyone willing to learn gamedev in a functional way. Some people with more experience than me have told me that the code is OK, so there is that too.

The original plan was to make a game jam type of game, so I don’t get in one of my “4 to 6 months” projects when I’m still not sure what I’m doing. Besides, it is a game for PC and not an 8-bit system, so there may not be much interest to play it when it is finished, so I didn’t want to invest too much time on it!

But then my boys are excited and suggesting ideas, so we shall see! For now it is a simple “collect them all to get to next stage” type of arcade platformer, and when I have a sufficient game I may just release and leave it there. You can watch a short video of the game –in Mastodon–.

Then all the lessons learned could be used to start an actual special project, with more of a plan and hopefully more chances of completing despite being a larger commitment.

Some time ago Juhang Park contacted me to say thanks for ubox MSX libs –which is always nice–, show me some work in progress games and ask for my permission to write a book about game development in C for the MSX using my libraries.

That was interesting. I don’t think anybody needs permission for that –even without considering the licence of the libraries–, so that is what I told Juhang. I wished them good luck and kind of forgot about it.

Well, the book has been published now in Korean: The retro game development bible. Which is very cool!

Apparently the book was rejected a few times because it was “only MSX”, so Juhang had to cover more ground by including MS/DOS and other “retro” targets –the site selling the book lists a lot of systems, but I can’t tell how deeply they are covered–. And there is something unexpected: Juhang wrote a translation layer so my API can be used with SDL1, SDL2 or Allegro as backends.

There is a reimplementation of King’s Valley 1 using ubox MSX libs –that I’m guessing it is used in the book–. It can be played on the browser thanks to WebMSX. There is also a repo with some info about the different chapters.

Juhang offered to send me a copy of the book, but I can’t read Korean, and told me that there are two MSX games that hopefully will be released soon: Galkave (a horizontal SHMUP) and Bomberman Special (a Bomberman clone).

It is complicated. May be my games aren’t that good or interesting, but if you can only play them if you compile them from source –and besides, written in Haskell–, that is perhaps too niche even for me.

This weekend I put some time into researching it, and there’s some documentation (for example: Cross Compiling GHC), but things don’t quite work. The most interesting issues I have found:

• Haskell is written in Haskell, so you need a Haskell compiler. Apparently 9.2.5 won’t compile 9.2.5, or I did something wrong. Using 8.10.7 seems to be OK.
• The cross-compiler is hosted in Linux and the target is Windows, yet the compilation of stage1 tried to include windows.h; which is not available in Linux. I must confess don’t quite understand what was going on, but I couldn’t get past that.

It is slow to try and repeat. Besides, once things fail, there isn’t much I can do.

So I shifted my focus to a different approach: can I run the Windows binaries in Linux using Wine?

It is possible, and I have put together some docs and scripts in cross-compile-hs-wine.

The first part was easy: getting GHC –the Haskell compiler– and Cabal –one of the Haskell’s tools to build Haskell projects– to run using Wine. I mean, is not trivial, but is not too hard. At least for pure Haskell projects, because if your dependencies need a C compiler, or even worse, are bindings to C libraries –like SDL2 and SDL2_Image–, things get very fiddly.

So at the end I had to get everything running in Wine, which includes:

• Cabal for Windows.
• GHC for Windows.
• MingGW-W64, a port of the GCC compiler suite to run in Windows.
• SDL2 and SDL2_Image development for MinGW.
• pkg-config-lite, a version of pkg-config for Windows.

Looking around, seems like installing Haskell on Windows (and SDL2) isn’t that easy.

For the second part, because Cabal is awesome, I only had to write a wrapper for it so it can find everything it needs when running from Wine, and after that it was just a couple of issues to get the sdl2 to compile. First I couldn’t get Cabal to find pkg-config, and second I think it might be a bug in sdl2-image –I will open a bug report–.

The compilation is slower than the native Linux versions, and the generated binary doesn’t quite work in the Wine version shipped by my Debian 11 (stable) –tried with unstable from a container, and Wine 8 runs it perfectly–, but this makes things OK: I can build and distribute binaries for Linux and Windows –even if the Windows part is a bit awkward–.

So now I can stop procrastinating and keep working on the game.