Who Debugs the Debuggers
Writing code is like playing an RPG. Your main quest is “make the game”, but on your way you’ll be handed side quests. Some are epic and fun, others are time sinks dropped in your way just to pad the experience out. Sometimes the side quests have side quests.
I’m trying to make a game, I don’t know what kind yet. What I do know is the game needs sprites, and for that to happen it needs some way of managing sprites. So I’m off down a side quest of writing a very simple sprite manager.
Except it doesn’t work, so I need to debug the sprite manager. This is on a Spectrum Next, my debugging options are limited to
- Thinking really hard and guesswork
- Changing the border colour, and guesswork
I’m writing this in C, so while I can attach a debugger to an emulator, it steps through assembly code, not C code. And I’m not off on an epic quest to learn how to translate one to the other in a debugging session.
No, instead I went down the minor side quest of trying to create some sort of debugging system. All I need is an approximation of the good old printf style debugging. Let me put text on the screen so I know things are working or not. Except you can’t print on the screen because there’s game on the screen (or not, that’s what we’re trying to debug). So what to do?
Well we can work with files, so let’s make a good old logfile. That seems easy, write text in a file, read it later. Only when I tried this, the emulator didn’t write any files anywhere, why? Aha, yes… it’s side quest time - “Files are not being written in the emulator, you must go and find out”.
Turns out it’s because I’m not using the emulator properly and it has no SD card image to write into. So let’s find one of those. What’s that? “The emulator isn’t reading the SD image properly and you have to find out why?”. Well, alright then, I guess. I’d better get some good XP for all this.
The SD image wasn’t being read because I’d downloaded the wrong one from an old copy of a website, linked from an old link. OK, back up the recursive tree we go one step. What were we doing? Oh yeah writing files… Well, I have an SD image, I need to get my game code into the SD image, how do I do that? … here we go again.
There’s a tool called hdfmonkey, that does it. The compiled version didn’t run on my Windows 11 PC for no obvious reason, but I could compile it in Linux. It also makes brand new SD card images if you tell it, so after some Makefile buggering about I managed to craft a build system that’ll compile all my code, stuff the binary and data files into an SD card image and I can load that into the emulator, run the code and see what happens.
So we can hand in a quest? Well not quite… the files were being written, but were empty. I was sent back to find out why. Found out they need closing when you’re done. But this is a game, there is no “done”, there is just resetting the machine at the end. After reading my favourite documentation - header files I found through Google - I discovered there’s a “sync” function which seems to flush the disk buffers.
And now we can hand in all the quests and I have a debugging system that’ll put text in a file so I can trace my code and find out what’s going on.
So tomorrow I can work out why the sprites aren’t working.
And then we can get on with the game. No, no we can’t, we can get on with the next chain of nested side quests.