24th December 2023
Despite an epic last minute effort I have been completely unable to get a suitable demo of Arkanoid 2 ready for release today. I was hoping to have a bit more time available for it leading up to Christmas but also, unsurprisingly, some aspects of the collision routine took a bit longer to work out than I was expecting.
Another problem has been finding an efficient way of dealing with the brick shadows, an issue that I hadn't even considered until I actually had the collision working. It's all under control but it does mean the demo is delayed for the time being.
The good news is that I've finally come up with a nice way of moving the ball around that should let me very closely copy the ST version. I've been struggling to get my head around this problem since I worked on Samtona; you want the sprite to be able to move in any direction, but with a constant velocity. I always understood that it was basic trigonometry (we did SOH CAH TOA when I was at school), but as soon as the word 'maths' rears its ugly head my brain panics and hides under the bed.
I thought this would make a good subject for a video about programming so I'll be having a go at making one sometime soon.
Until then, thanks for stopping by and Happy New Year! :)
3rd December 2023
I've taken a couple of steps forward with Arkanoid 2 and I'm about to start the main part of the game code, the collision routines. I had to come up with a routine to get the level editor working and I'm hoping I can develop it to give me some really fast collision. If I can achieve this then a lot of the cool things, like the big multi-ball powerup, will be a cakewalk. I don't want to have to leave bits out of the game to keep it at 50fps like I usually do..
Before I do all that, I decided to tackle the sound FX. In the past I've been using a complete solution, that was given to me by another coder, that works really well and is very fast and efficient. Having something like this done for you is an awesome advantage when it comes to getting games together quickly but, thanks to my inherent laziness, it's allowed me to avoid ever learning how to do it for myself. When I started looking at how to handle the music and sfx for Arkanoid2 I realised that I would have more options if I understood what was going on under the hood, particularly as I would potentially be working with sound data from the Atari ST version for which I have no handy sound code kicking about to save me the effort!
I had already put together a basic program to edit sound fx data so I went back to the drawing board with it and created a new version, entirely in machine code that would get things working with my own sound code. The downside of this is that my own code is somewhat crude and clumsy, but it has allowed me to learn how things work. The technical data sheets for the SA1099 make it clear that the chip is a genuine synthesiser and I'm interested in finding out how to use it like one. I've had to learn how synthesis works to create sounds for my Novation virtual synth and I am very keen to apply some of this knowledge on the Sam if possible.
The Novation has oscillators to create the really exciting sounds and I'm interested in seeing if something like this can be achieved with the Sam. I assume that with the correct knowledge it can be done fairly easily but as that knowledge is heavily maths based I'm guessing it will be tough going with only my 90's GCSE maths skills to help me!
On the subject of maths, there have been several times that I've needed maths functions for my Sam projects and I've found some excellent solutions online to help people like me, who don't find maths particularly intuitive at the best of times let alone on an 8-bit computer. I've added a couple of links on the Sam Links page but I wanted to mention the amazing z80 Heaven. I've been using their C_div_D, an 8-bit divide routine, for a while and it's extremely good and far faster than anything I could ever come up with.
This is the current version of the app, hopefully functional enough to make the sound fx for Arkanoid. The app takes advantage of the mouse and lets me generate data automatically and then edit it by hand where necessary. The screen on the left is the main page where each channel of the chip has it's own tab. I'm only going to work with two channels to begin with and in the current version only channel 1 is hooked up. The middle screen shows the current, very messy, interface for generating data.
I can generate linear fades, sine waves, and random values so far and will soon add square, sawtooth and triangle waves. There will also be an extra menu, when you click on the wave type icon, with options for how to create the data with that wave. There are a lot of possibilities and if I can add them all it should prevent the need for too much fiddly editing by hand.
The final screenshot shows the data editor. The main display shows the frequency above the center line, the volume below and the octave is represented by the colour, low (darker) to high (lighter). There's a little flashing pixel for a cursor and the current value is edited with a left or right click on the icons at the bottom of the screen.
I've put this together in a bit of a hurry so I'm taking advantage of SimCoupe, namely the export data function, to save the data for a sound into a binary file that can be added to a project. My goal for 2024 is to learn how to load/save to disk so hopefully I can add this to the program for creating sounds on the real Sam hardware.
Hopefully my next update will be on December 24th and will be a playable demo of Arkanoid2..
11th November 2023
It's been a while since my last diary update and that's just down to having made very little progress on any of my projects this year.
I started the year working on my Sam Coupé gfx tools, adding Comet file output which, along with ascii text output, would be very useful features to have. I had good results initially in that I can convert a single image to a comet source file successfully, but when converting a lot of images at once it was a bit flakey for some reason. I'm going to get the bugs squished over the Christmas holidays and hopefully, finally get it working as a webasm app for people to try out. The important thing is that Edwin Blink's instructions on how to create the comet file data worked perfectly! My eternal thanks and gratitude go to him for helping out with this.
Despite having a busy year I was able to get up to RetCon in the early summer, just before the weather literally went south, where I got to meet Gordon Wallis and Howard Price who were manning several Sam Coupés at the show. This was the first computer show of any kind that I have attended in at least 20 years and it will not be the last I hope. I was kicking myself for not bringing my glasses as it seems that the RetCon tradition is to use lots of incredibly small TV screens, many as old as the home micros and consoles connected to them! I assume this is a practical necessity to make efficient use of the available space and to get as many machines hooked up as possible.
Thankfully the Sams were hooked up to larger lcd displays and I was able to try out the new Manic Miner by David Ledbury, which kicked my arse, before I regained some credibility with a better effort on Howards Flappy Bird port. Thankfully Gordon was able to demonstrate how to play Manic Miner properly, getting way further into the game than I could manage, so I could see that the new Lower Caverns update has been a huge success. I'm really looking forward to getting stuck into it when it's released.
Another highlight was Howards "demo" code examples featuring many of the classic megademo style coding tropes that we all know and love. The smooth rotating image he demonstrated particularly stuck in my mind, but there were plenty of genuine "wow" moments throughout. The whole experience reinforced the sinking feeling I've had for the past couple of years that I need to put a bit more effort in to learning the more technical aspects of what I'm trying to do. I have a very lazy mentality that infects my thinking and approach to things and I settle on code that basically gets the job done, instead of looking at how to do things well.
There was so much to talk about with Gordon and Howard that I quickly found myself out of time and having to make the trek back from London without checking out much of the nearby Atari ST setup. I had intended to pick someones brains about working with those crazy bitplanes but alas it was not to be this year. I'm so behind with my Sam stuff right now that it was probably for the best anyway!
Overall I had a great time! The organisers were friendly and helpful and, considering the extremely low cost of the ticket, I couldn't recommend a better value day out. So I will be going back next year, better prepared and maybe arriving a little earlier to give me more time to see everything!
Since RetCon, and later on this summer after the rain had stopped, I was able to have my first proper go at using RetroBright to de-yellow my newly refurbished Atari STe. This was a test run to get ready for having a go at doing the same with my Sam. It took me a few goes before I found the best way of going about the procedure but the results weren't too bad in the end, despite an early misstep.. my advice is don't use cling film as the RetroBright instructions advise on the bottle. Instead I found that a really large, clear bag with improvised "struts" inside, to make it like a vaguely squarish tent, gave the most even results. This way the Atari case could sit inside the bag without being in contact with any part of it. Some Youtube videos suggest big expensive looking boxes for this but a big bag and a carefully harvested supply of used kitchen roll tubes does the trick very nicely if you're on a budget!
It feels slightly odd using an Atari ST that looks like it just rolled off the production line yesterday, but it's also *VERY* cool! I have tried to make the most of it in my spare time, a task made infinitely easier thanks to the Gotek drive I installed last year. I have a USB stick made up with a very complete set of all the coverdisks from the main ST magazines as well as all the games you could ever want. It has been very satisfying retracing the steps of my teenage years and the whole experience has done a lot to recharge my enthusiasm for finishing my Sam projects and porting whatever turns out best to the ST.
I don't have enough time to do justice to the Space Adventure Simulator 2 at the moment but I have put together a little project using a piece of Atari related hardware that I bought when I was about 14 years old. I am referring to the Ultimate Ripper cartridge by Power Computing which makes it very easy to rip music and graphics from atari software and save them to disk. I have used it to get the raw sprite sheets for a game that seems ideal for the Sam in every way and you can read about it here.
One last thing. I've always assumed that, as a latecomer to the Sam scene in relative terms, anything that I am doing code-wise is old hat to everyone else. If that's not the case, and anyone out there wants to see actual code examples of anything I'm doing then let me know at the email address above and I'd be happy to add something in the next diary update.
As always, thanks for reading!
15th December 2022
A few hours after I made my last post I fell ill and tested positive for SARS-CoV-2. Awesome! I'm now feeling a lot better but not well enough to do anything practical so I thought I'd make a quick post about Sam and Atari graphics.
I was hoping to quickly port Bubble Ghost to the ST before the end of December to get some experience for making the Atari version of the Space Adventure Simulator 2 but, as always, things are way more complicated. In fact, the way the Atari ST handles pixels is so stupid that I can't really believe it. The way the Sam does things, packing two pixels into one byte, makes things tricky for single pixel movement of sprites. I was told the easiest way to deal with this is to make two versions of a sprite, with one shifted by a single pixel so you can check the x coordinate before you draw to select the correct version. It works well but makes the drawing code a bit clunky.
A single Atari ST pixel is also 4-bit but unlike the Sam, each individual bit of that 4-bit number is stored in a separate 'bitplane' and has to be re-assembled before it can be used. To make things worse, 16 pixels worth of bits are stored in a word so, in order to work like the Sam, I'd need to make 16 different versions of a sprite to create single pixel movement.
This just isn't a practical use of memory so I will have to store the graphics as a single sprite sheet and then build the sprites needed on the fly. This is such a shame as it means that a huge amount of processing time will be spent just putting a sprite on the screen in the right place.
I've channeled my frustrations into this handy diagram showing the difference between the Sam and Atari way of doing things:
I think this makes things a lot clearer and I hope it helps anyone else who has struggled to understand this complete nonsense.
8th December 2022
It's been ages since I've had any time to spend fixing up the website. I'm sure I don't need to tell anyone what a strange and unsettling year it's been and I hope that everyone is making the best of it all, wherever you are in the world.
As it's been a while since I posted here this entry may end up being longer than usual. I'll keep updates about individual projects on their own pages from now on so I can keep this page more about what's going on with me in general.
I'm still working on The Space Adventure Simulator 2 and by the time you read this I should have made a page for it with some screenshots and some detailed information about my plans for the finished game. I'm also making a Patreon for wubsoft, which I was hoping to activate alongside the release of TSAS2. This may not happen quite as seamlessly as I had intended as I've had to slow myself down a bit recently. I was rushing things along too much and making the project worse as a result. The urge to get on with the "next big thing" is so great sometimes that it can be extremely counter productive!
My Sam is also in need of some repairs, particularly the power supply, which I'm about to replace the capacitors in to see if it sorts things out. I've been very wary of getting a soldering iron anywhere near the Sam as the second hand prices have really gone nuts these last few years. My sound chip has needed replacing for ages (I already have a replacement from Quazar) but I've been putting it off, just in case the worst was to happen..
This rise in the price of a second hand Sam has also made me wonder if the Sam has become more of a speculative investment than an affordable 8-bit gaming platform, which really would be a shame. Despite its technical shortcomings, it's still a really fun machine to make games for. If anything, I've found that the limitiations of the machine have made it more interesting to work on. And the limitations are only really with the power of the machine, the memory has always seemed to be really generous if you don't have loads of graphics to work with, and the sound chip is better than that of any other 8-bit machine, or even the Atari ST.
Anyway, these issues have been on my mind as I've thought about how to present myself on Patreon.
My goal has always been to become a "one man Mastertronic", and release lots of small, fun games for the Sam and other similar home micros. It's taken longer than I expected to get comfortable with game programming and the world has moved on far faster than I would have ever expected but, with the rise in popularity of retro-gaming, I still feel that it's a worthwhile endeavour.
I've begun the painfully slow process of getting started with the Atari ST (bitplanes, omg!) and I'm going to have another crack at getting my sprite tool working on the website for everyone to make use of. Edwin Blink has been very kind in providing the cheat codes for his Comet file format and I've successfully converted a sprite from my app directly into a source.s file. My sprite tool has made converting graphics to the Sam really quick and saved me a lot of time, but now it will be possible to go in and hand-optimise the converted sprites for some extra speed.
Assuming that I can get my Sam games ported to the ST with no problems, I'm also looking at the Commodore Archimedes as a potential future platform. I had a chance to play E-type when it was still fresh and exciting so the Archimedes has always been something I'd like to have a go at programming. I also like that it offers the chance to learn ARM assembly and that it's still possible to get a working machine for a reasonable price! The modern retro machines like the Spectrum Next are also an option but I haven't had the time to properly look at what would be required, or what they are capable of.
As for the Sam, there are several Gameboy games I was crazy about back in the day that would probably work really well for it, and I recently got an old 166Mhz Pentium working which made me realise that Dune II would be a far better choice than Command and Conquer if I was going to have a go at something like that again. It wouldn't be necessary to remake the whole game in one hit, each campaign could be a separate game or it could even just be a simplified remake in the style of Dune II. As long as it was fun in the same way I wouldn't mind particularly. I've also been re-visiting the Dungeon Master/CSB source code now that I understand a bit of 68k assembly. The way the source code is written, using pseudo-68k registers makes a bit more sense to me now, although the way the copy protection is completely embedded within the game code makes me wonder if it's still a fools errand..
Other than coding I've done a lot of electronic repairs this year. I've had several pieces of music equipment break down and I've also started looking at a few of my broken consoles to see what can be done. I have an original Sega Treamcast that I bought and almost immediately broke about 15 years ago and, apart from not working, it's in amazing condition for its age due to it barely being used. I'll post more about that either here or on the Exxos forum when I get around to it. I'm not sure what I'd do if I got it working as it was about 140 quid when I bought it and the last one I saw being sold went for almost 1500! Maybe I could swap it for another Sam..
3rd July 2022
Hi to anyone who's reading this, thanks for keeping an eye on what I'm up to!
I've been a bit bogged down working on 'The Space Adventure Simulator 2' recently so I've taken a break to absorb the stunning new issue 26 of Sam Revival and to set up His Majesty to play the cover disk (which I've heard has one particularly good game on it!). I also thought that writing a quick update would be helpful to get some perspective back now I'm reaching that 'almost finished' stage with the game.
The parts I'm working on now are the bits that handle when the player kills a monster or dies. I'm still not massively comfortable with drawing graphics and so I've tried to use that to my advantage by making something similar to the very early South Park cartoons. So kind of crappy in a way that's comical, but effective enough to convey what's going on. So far it's been a lot of trial and error, drawing small sprites and writing fiddly code to orchestrate several elements at the right time. If it works then the fiddlyness will have been worth it!
I've made a better small font for the game text that has most of the ascii set, with the lower case letters going below the line properly where necessary. It's more readable than my previous efforts but it's still not perfect. A bit of shading will probably help but if TSAS2 goes really well I might go on a hunt for a proper graphic artist to collaborate with for TSAS3.
One of the big changes I've made for TSAS2 is how many lives the player has, something I got completely wrong for the first game. A crew of one hundred was way too many and totally ruined the strategy element of the gameplay. There's no consequence to losing crew members while exploring the planets and moons and so you can just asset strip system after system way too easily.
TSAS2 does things completely differently. You now have 26 'Captains' who you play as, one at a time, until you die or get beaten in a battle. The captains are named, from A-Z, after characters from sci-fi films and TV shows and I've made two sets, for male and female characters. I cannot overstate what a monumental challenge this was! I thought it would be considerably more straightforward given how much sci-fi has been made over the years, but completing both lists without using any characters from Star Wars or Star Trek (which I thought would be cheating given how many characters they've churned out over the years!) turned out to be impossible. It seems that script writers like to pick names from a very small area of the alphabet and a lot of really good names had to be left out simply because there were too many choices.
The game itself is about halfway to being a proper RPG. I have a nice storyline worked out to base a game on but I'd rather save it for TSAS3 and use TSAS2 as the testing ground for creating a coherent universe and functional resource management system first. So I've made a fairly traditional arcade adventure, think Atic Atac or Con-Quest, with some of the main elements of an RPG mixed in.
My 'Big Idea' for the resource management system, which I had to simplify way too much for the first game, is to use real-world chemistry where you can slowly amass elements from the full periodic table. I had planned to put together some kind of system based on Lewis structures (which I learned about by watching an excellent chemistry course from MIT), but this is all way too much for a Sam game, even if I could work out how to do it and actually code it, which is highly unlikely!
I liked the materia system in Final Fantasy 7 and want to create something along those lines. The first TSAS sets out the basic idea, metals for ship strengh, gasses for weapon power and less common elements having more value. It may end up being some sort of fudge but we'll see!
Finally, I have cleaned up my 4MB STe and had a go at sun bleaching it, ready for working on and testing the ST version of TSAS2. I'm hoping it will be a pleasant way to have a crack at 68k assembly but I'm not going to make too many promises until I've put some proper time into it. If the ST is anything like the Sam then a few teething problems are to be expected..
And yes, I know I spelt laser wrong, with a z, on that demo video. And yes, I know it's an acronym and not a word. Seriously, stop yelling at me! :)
21st April 2022
As always, it takes a bank holiday weekend to see any real progress from me!
If you got to this page then you must have seen the new website, unless you have an older browser that doesn't support HTML5. I have no idea how well it will work for people, I get surprising and uneven results from my tests on various, mostly older, machines. It's set to run at 60fps and it's a bit too fast running natively, which seems to work about right for me online.
If it works particularly badly on your system then please consider dropping me an email to let me know! I will point out the obvious flaw, while I've left space for them, I haven't added touchscreen controls yet. I don't have a modern enough device with a touchscreen to develop on right now, but it's next on the list so will get sorted at some point! SDL supports touchscreen controls perfectly and I have used them for my openGLes projects in the past, so I'm not expecting problems..
In other news, I have added a video to my youtube channel of some of the graphics and gameplay for the new version of "The Space Adventure Simulator", which is ticking along nicely despite a considerable drop in the amount of free time available since life started to return to normal.
4th September 2021
You can get the new game here.
The music for this was created by Howard Price, and he's done a remarkable job of recreating the original gameboy music and sound fx for the Sam. According to his blog he's going to write about the process of putting the tracks together, which should be very interesting. I can't thank him enough for his efforts on this, it's really made the whole thing worthwhile.
Overall I think it has turned out pretty well, but there's a few differences from the gameboy version that deserve an explanation.
The collision detection on the gameboy version is very forgiving, which for a small screen is probably a good idea. But on the Sam it made things a bit too easy so I've made it exactly half as lenient; the collision detection ignores the outermost pixel of the bubble whereas on the gameboy it was two pixels.
The bubble behaviour is also not perfectly copied, although it's pretty close, and the maximum distance you can move the bubble with one blow seems to be identical. I am very tempted to keep tinkering with it endlessly, but the way it's working here is very playable so I probably won't :)
There's one object missing on a couple of the levels, and while most of the animations are about right, I didn't kill myself trying to copy everything perfectly.
Finally, as the gameboy version is so easy to complete, I've also made a whole set of ludicrously difficult levels that should drive you mad. Don't say I didn't warn you! :)
6th June 2021
As for the tools themselves, I have all the pieces working nicely on the Sam and I'll make a video showing what the web version will do asap. In short, it will be possible to choose a bmp, select areas of it to convert into compiled sprites, and then save the output as either a 32k page for using directly on the Sam or as a Comet source code file.
I've also made a good start on a tile map system that uses graphics converted with these tools, and that will support animated tiles. I'm making a video to show the new versions of The Space Adventure Simulator and Dungeon Game that will make use of all this.
To cap off a busy year of coding projects I have finally made a start with Atari ST programming. I've set up an emulated system using Steem SSE and have Devpac3 working nicely from a vitual hard disk. I do have a real ST but I'm going the emulated route to start with. I've managed to get some graphics from The Space Adventure Simulator converted to degas .pi1 format and have used a good 68k/ST tutorial to learn how to draw them on the screen. The Atari ST uses the same method of storing pixels in nibbles as the Sam, but also makes things slightly more complicated by storing them in dwords rather than bytes. Despite the extra complexity, supporting the ST with my online graphics tools will be simple. Famous last words..
At some point I'm also going to remake this whole web site so it's less rubbish.
9th May 2021
This version doesn't handle textures, only material colours, and only a single object and material file. If you don't happen to have an object handy you can download one of my test objects here. I downloaded a lot of ready-made objects like this about ten years ago when I was working on my object parser, but I can't remember exactly where it came from now.
8th May 2021
When these tools are working for the Sam I'll start on the Atari ST versions. I've been meaning to get started with an ST version of wubtris for a while but there's never enough time.
It has also become apparent that my HTML knowledge is a bit out of date and even after fixing all the really big mistakes on this site I still have dozens of errors. Some of the HTML attributes I use have been deprecated since 1998, which is about the last time I made a web page to be fair!