What advice would I give newer and junior developers?

Over 10 years ago, I began a career transfer from an adult support worker (or whatever that role is called now, a care assistant in old money) to one in Computer Science. I knew on beginning my Degree in Enterprise Computing, a programme that I attended thanks to Manchester Metropolitan University (MMU), that what I wanted to do with the rest of my life was software development. Through the course, I discovered that my two best classes were Programming, and Business Studies and management. My least favourite and consistently poor results fell into the Database and Structured Query Language (SQL) side of things.

Whilst I kept writing through University and beyond (exclusively through the pages of Micro Mart at that point), it became very obvious that in order to progress as a developer, [software development] had to be the main focus in my life, so writing became much less important to me. I had a good technical grounding in programming languages thanks to MMU but especially due to an unexpected almost full year at the University of Derby Games Programming course (this was due to Government funding cuts thanks to a certain coalition of chaos that I won't mention further).

At Derby I had covered a lot of C and Visual C++, some MIPs, Java for Android and some other languages. Being focused on entertainment rather than application software meant a whole lot more programming but no database theory, management or SQL. I did make the point that SQL will become more important even in the games programming world, something that at least one of my lecturers acknowledged. How else are you going to store all of that data for all of those online games?

Anyway, I started as an web application developer thanks to an Internship. After about one year, I had my first job proper at a company in Wolverhampton. I was taken on as a Junior Developer and as a content writer. Our primary technology was a LAMP sort of stack; that being Linux, Apache, MySql (or MariaDB) and PHP. We were running a version of Magento version 1.7.1, and had some front-end CSS compilers that apparently made front-end development more easier, though I've always thought that the benefits of something like SASS has very marginal benefits over straight CSS. That aside, in each new role I undertook from there, I learnt a lot. So what sort of advice would I give now to junior developers? Or someone inspiring to change career to become a developer?

The first thing I'd say is that there is never a bad time to learn something new. Although not everyone is suited for a role as a software developer, like not everyone can be a Nurse, nor a Doctor, if you have a logical mind and you are able to break down problems to small manageable chunks, and you don't mind learning how to debug then this could be for you.

But as a developer, what issues might you come across? I've found that being a developer is often quite different than programming alone. As a developer, you usually need to work collaboratively, and conform to certain standards and expectations. And whilst you should be given some slack as a junior, your work will still need to be maintainable and scale as necessary.

In my first job proper, the so-called senior developer made two critical mistakes that were even apparent to me after just over one year in the industry; firstly, the version of Magento that we were using was core hacked, meaning that we couldn't easily upgrade it.

My senior colleague developed a service that would produce JSON for pricing data; this data could move up and down every second based on current market prices. Whilst his service was perfectly good, and served the website well, I had developed an iPhone and Android application that was dependent on it.

Shortly after this application was released, he decided to change the API to deliver a different JSON structure. That would have been fine in other circumstances, but he made these changes without consulting anyone else, and whilst he was able to fix the website JavaScript charts that consumed it, he didn't inform me of the changes and therefore my application had been rendered useless. This happened during the last few weeks of my time there, and I had no way to update the application quickly or easily, and he didn't understand the application to fix it as some of it was Objective C and he refused to work outside of his conform zone which rapidly became the PHP framework Laravel.

As a developer, no matter how senior you think you are, or you become, do not make unilateral changes by yourself. Consult others first, especially those people in your team. And if you make a mistake, admit it. The sooner you do, the sooner it can be fixed. Other developers making unilateral changes has caught me out on other occasions too. One server change cost me well over 1 week of debugging because this change wasn't announced to anyone. This change was unnecessary and on a development server, although making such a change without agreement on a production server might have caused even more headaches!

My final piece of advice is to never assume that you know everything, and do not assume that just because you know something that everyone else in your team has that same knowledge. I've done presentations that I never expected to; one was why computers do not divide by zero, and another was about the difference between scalar values and objects. I have a small advantage over many of my younger colleagues in that I grew up programming, and many of the computer magazines that I'd buy growing up would be aimed at teaching children like myself computer programming too. So concepts like Integers and Boolean values, loops, branches and conditionals are kind of second nature to me even if the terminology may have changed. But even good people with good degrees may not have such a good grounding in programming principles even if they're perfectly good developers otherwise.

I've learnt a lot from my colleagues over the years too. As one of my lecturers once said to me, if you're not learning as a developer, you'll soon be obsolete.

BMC64 is free, so how much does it cost?

This sounds like a bit of a stupid question. How can something free cost any money? The reason that I ask this is because I was speaking on a Discord chat group recently and a common statement that people make is that the Bare Metal Commodore 64 (BMC64) emulator is a better thing than THEC64 and THEC64 Mini. Of course, such a solution that one could build oneself would be better in many ways. One could presumably customise all of the settings to enhance the user experience, including I assume choosing which SID chip to emulate, or even have two SID chips emulated, and so on. On THEC64 platform, one doesn't have nearly as much control, not without hacking anyway.

Another reason for BMC64 being better [than THEC64 platform] is that it is free. I was specifically thinking of BMC64 kits that one may purchase when I made the point that THEC64 has likely sold a lot more units than these kits. The counter argument was that BMC64 is just software that one could install on a Raspberry Pi, so it's free like a Linux operating system is free. But how much would one need to spend to use BMC64?

If you're reading this and you've already made an investment in a Raspberry Pi then you may stop reading here; BMC64 isn't going to cost you any more money than you've already spent. But what if you don't already own a Raspberry Pi, and want a dedicated piece of kit just for Commodore C64 software? Is THEC64 or Mini a good solution compared to something for free?

Well let's look at costings for a BMC64 solution first. Assuming that BMC64 will run on any Raspberry Pi currently available, you're probably looking at spending around £30 - £40 GBP for the cheapest Pi, which I assume has the lowest specification. So we'll say £30 with postage. And then of course you'll want a keyboard, so there's another £10 - £15. And if you don't mind playing games with a keyboard rather than a controller or joystick, that's it. It's then just the time it takes to set up. So, you're looking at spending between £40 and £55 for this option, and that's if you don't already have a spare USB keyboard lying around. That's good value, but it's certainly not costing £0.

Like for like, THEC64 Mini is currently for sale here in the UK via Game outlets for around £40, at least in my local store in the West Midlands. Okay, so you don't have a keyboard included with the Mini, but do have a controller. I know THEC64 Mini joystick isn't the best version, but it's still a fair comparison for the cheapest BMC64 option. Set up time for THEC64 Mini is usually no more than a few minutes, whereas BMC64 may vary depending on how much one wants to configure. THEC64 Mini does include 64 games to get started with, and all of these are licensed games. THEC64 Mini has a custom housing, fewer USB ports and no included PSU. It requires a 5V 1amp USB charger, which will be another £5 - £10. Both solutions allow you to add your own software, but THEC64 platform is limited to USB 2 flash drives formatted to FAT32, though this is more than adequate for C64 games.

THEC64 Mini is nicely packaged. I genuinely had a warm fuzzy feeling when I initially opened my first THEC64 Mini. The guys at Retro Games Ltd did a really good job with the industrial design and packaging. I won't have that same feeling opening the packaging for a Raspberry Pi, but this may be different for you.

The suggestion in the chat wasn't for this cheap option, but to consider a Raspberry Pi 4000, as that includes a keyboard and a mouse. This is currently around £100 in the UK. How does that compare to THEC64 Classic?

THEC64 is currently retailing in the UK for around £120, it is housed in a stylist casing which matches the size of the most common C64 casing in the UK, and includes a fully functioning and properly mapped keyboard with a joystick controller. Again, everything on THEC64 is fully licensed, and the bundled joystick is much better than the THEC64 Mini joystick. At £120, this isn't costing significantly more than a Pi 4000 solution.

So whilst one may save some money with a Raspberry Pi, is BMC64 a better solution? Well that depends on what you mean by better. THEC64 and Mini work out of the box, and THEC64 has a fully mapped keyboard with a pretty accurate casing, and both run at 50 or 60FPS like the original hardware (depending on your region or what you're used to), and with no sound drift nor frame skipping like on some emulators especially running on lower specification hardware. There is an issue on some modern displays if you specifically want a 50Hz refresh rate, but I assume that this will be the case for a Pi anyway.

Whilst THEC64 emulation is more limited than with a BMC64, those things that are missing [from THEC64] are very marginal use cases. For most people who just want to play games, THEC64 is pretty good. If you are a more serious user and more invested in the C64 platform then BMC64 is very likely a more suitable option. It isn't for everyone though, like Linux isn't for everyone either.

This reminds me of the arguments that people used to have (maybe still do) between Microsoft Windows and Linux.

Linux is free, and yet you still need to spend about the same money as a Windows-installed PC to run it. Also, I've never known anyone to actually pay for a copy of Windows by itself as this cost is usually included with the computer, and that cost isn't necessarily significantly cheaper without a Windows installation. And more serious computer users probably want to build their own system anyway, and make their own choices of operating systems and other software installations.

So I don't own a BMC64 (or any bare metal emulator) solution, and at this point spending some money to get one isn't for me. I have got to an age now were I want things to work out of the box, rather than using my time with various customisations and setting, and wasting my time with any trouble shooting for when things go wrong. I already did that in the 1990s and early to mid 2000s with my Commodore C64 and C128 and all of the Creative Micro Designs hardware that I was using.

THEC64, regardless of what faults that it may or may not have, works. It's actually well supported and has seen regular updates for it, though I suspect that v1.6.1 will be the last firmware update for THEC64 as the remaining missing features, such as using a custom Kernal or emulating more than one drive, are very marginal use cases that most people who want to play classic games won't care that much about. Again, your experiences may differ here. Maybe it's essential that you have a custom Kernal installed, or have two SID chips emulated, for instance.

On that note, I'm off to play a few games of the absolute classic Wizball, and ponder the meaning of life, the universe, and everything.

Noel's Retro Lab bench mark test - we have a new leader

Noel's Retro Lab is a popular YouTube Channel that discusses many computers and related hardware. One thing I like about this channel is the detail Noel goes in to especially when repairing 8 and 16-bit personal computers. He gives a good overview of the hardware, and usually runs a BASIC bench mark as a way to compare one machine to another. This bench mark program is as follows:

10 FOR i=1 TO 10
20 s=0
30 FOR j=1 TO 1000
40 s=s+j
50 NEXT j
60 PRINT ".";
70 NEXT i
80 PRINT s

Noel has been adding the results (in seconds) for each machine that he has run this program on, and many of his friends and followers have contributed to this. You may see system-by-system comparisons in a Google Sheet here.

Until today, the fastest system has been the ZX Specrum Next, though it needs to be running at 28Mhz, and use Integers rather than floating point variables. It completes in 5 seconds, and for a BASIC interpreter on a Z80 computer that is pretty quick.

As I'd set up my Commodore C128D-Cr again yesterday, which has a CMD SuperCPU, RAMLink, FD2000, a Commodore 1581 and an Ultimate 1541 II attached to it (or the U1541 II alternates with the RAMLink due to compatibility issues with the two devices) I decided to try the aforementioned bench mark symbolic listing to see the results on my power system. I first tried it in C128 80 columns mode, and found that it was faster than 5 seconds (at least with BASIC or FULL optimisation enabled) - so I'd need a reliable way to time it accurately.

All variants of Commodore 8-bit BASIC have a TI$ system variable. This will tell you the number of seconds since you switched your computer on (by default) and may be set to the current time in HHMMSS format. Related to this is the TI system variable, which counts the 60ths of a second since the computer was switched on (by default), and is reset if the TI$ system variable is set to midnight. So I did a typical thing for Commodore BASIC bench marking by adding the following BASIC lines:

0 TI$="000000"
80 PRINT S:PRINT"SECONDS"TI/60,"JIFFIES"TI

At its fastest, and in C128 BASIC 7 and 80 columns mode, the bench mark completed in about 3.2 seconds with either BASIC or FULL optimisation mode set. I therefore knew that C64 BASIC 2 would be faster than this.

You may see the results on my official Twitter feed, but a heads up: in C64 mode the fastest result is under 2 seconds.

I'm now going to try this same bench marking on my Ultimate 64 at 48Mhz. I expect that the results to be under 1 second. I may optimise the U64 further to see if I can get this bench mark to run in under half a second without optimising the BASIC listing.

One thing to note about bench marking is that you may get misleading results that may or may not fit your personal agenda. I saw a YouTube video on how the Turbo Chameleon [TC] is faster than the SuperCPU. And yet, at the time of writing at least, the TC doesn't have a Doom port. Not in its C64 emulation anyway.

Do younger video game enthusiasts get the Commodore C64?

One thing that has become apparent to me over the years is that Commodore C64 games, and entertainment software on other 8-bit home computer systems like the Sinclair ZX Spectrum, are often abstract and usually quite difficult. At least the ones worth playing fall into this category.

I first realised this some time when I started my University Degree in Enterprise Computing. I was in my early 30s and it was around 2009 or 2010. At the time, I was still writing my weekly column for Micro Mart magazine (published here in the UK by Dennis Publishing Ltd I think, and previously under the Trinity Mirror group). I was one of the oldest people on the course, though not the oldest, and my friend Peter, who is interested in media and a part-time radio host on a local station, had something of a curiosity in 1980s technologies. Though he was probably interested because of Nintendo's enduring name, and was also an avid Apple user then (probably still is), with the latter monolith tech company rumoured to have "invented the personal computer", which we all know is false. The first real personal computer, at least at a consumer level, was the Commodore PET, being by far the most usuable, stable and complete machine of 1977. Right?

Anyway, it was around this time that a truly great ZX Spectrum programmer Jonathan Smith aka Joffa Smiff, passed away. I had met Joffa and even somehow got an interview out of him for Micro Mart. He was an extreme introvert, and I found him to be a complete genius, and thoroughly nice chap. Unfortunately, he had suffered with his mental health and this, along with other factors, lead to his passing at just 43 years old (RIP Joffa). I spoke with his sister shortly after his passing to offer my condolences whilst writing his obituary.

I already knew of some of Joffa's work as he was developing a Spectrum game before his passing, and I had played some of his games in the 1980s and early 1990s. But I'd never played all of his games until then. I can honestly say that I've never seen such consistent quality from a single 1980s games developer. I don't think there was one game that I didn't like, and I still play Hyper Active to this day. But it was his first game, Pud Pud that got me thinking about this question: "how would I explain this game to my daughter?"

For those who don't know Pud Pud, you take control of a flying Christmas Pudding-alike creature which must eat other creatures (which ones you have to figure out yourself) and find 10 other puddings whilst avoid being kissed by the evil Mrs Pud. It's fair to say that this game is a little out there and pretty abstract though not to the level of some Jeff Minter games. I got the feeling that younger game players wouldn't get it; those who have been born into a digitally saturated world, with if not instant but pretty quick on demand digital assets at your fingertips. Many of today's games, especially for younger players, have tutorial modes and on-screen prompts. And waiting to load for more than a few seconds in this world is unusual and may often lead to younger people to grow quickly impatient. In fact a recent television advert has people destroying their wifi routers because everything has to be now, and that's okay in the 2020s. It also shows the throw-away society that we have become in my view.

Those of us who grew up with machines like the C64, we generally didn't have games in an instant. Games consoles would load in seconds, but most people in the 1980s - at least most people in the UK - opted for a home computer for their main entertainment system even if we conned our parents into the myth that "it'll help with School homework" - well in the long run it helped anyway.

Home computers might have been as expensive as an equivalent video games console, but games were usually much cheaper for computers. Doing a quick search the Internet tells me that Atari VCS-2600 games would cost around $30 USD or more, so if we assume that those same games wouldn't have been cheaper than £20 GPB, you could have purchased 10 individual C64 games on cassette for that, thanks to budget publishers like Mastertronics. Also, cassette games were much easier to copy, you only needed a blank cassette tape and a tape-to-tape hifi system.

Anyway, C64 games were limited by the times and technology. Very few games had the luxury of having explainers, so if you didn't read the manual first (and very few of us did) nor the game reviews in various popular publications of the day, you wouldn't necessarily know what you were supposed to do on your first few plays. Magazines would have hints and tips to games, but those were generally published monthly. So if you were stuck on a new game and none of your friends had worked it out either, you'd have to hope that the next issue of your favourite printed periodical would have some hints for you, in the form of hand-drawn maps, or even cheats such as POKEs that would modify the game code to provide for infinite lives, time or other cheats.

Why do I mention all of this? Well, after my recent overview THEC64 Collection 1 for the Evercade I found a video from an upcoming YouTube channel which had some pretty pejorative and I think unfair veiws on the collection. The reviewer starts out by stating that he never had a Commodore C64 and all of the games on the collection were new to him. Fair enough, but in this particular review, he ranked the game "Lee", which is actually "Bruce Lee" as 13th out of the 14 games, in other words one of the worst on the collection. More on this later.

To be fair, this guy is of a younger generation. For various reasons, even games that I wasn't good at back in the 1980s (which was most of them), I'd still replay again several times after my first try. Maybe there was something that I'd missed as I hardly ever read the manual for any software. Each binary game world was an exploration and sometimes I'd actually progress a little further. Even if that didn't happen, I could listen to the music, or wonder how the programmer made that happen inside a television screen. As I was a programmer first (albeit BASIC), seeing different game ideas was as fun to me as playing them. Also, I didn't have games on tap, I might only get one new game a month. Something less frequently. And loading times would be at least three minutes, or ages as I thought back then. So if I was going to wait for something to load, I wouldn't want to switch it off after my first go, would I?

All of this nuance, this exploration, having patience and so on, something that is in my gaming DNA if you like, tends to be lost on younger game players. This lack of patience likely started in the 1990s, when machines like the Amiga started to become more common, with its pretty fast disk loading and relatively good amount of storage per disk, and powerful processor with pre-emptive multi-tasking capabilities. But more so with consoles. Cartridges could not only allow for more instant loading, but meant the game could be as big as the developer or publisher wanted it to be. Activision was one of the first to make a game seemingly exceed the capabilities of the host hardware with Pitfall II for the Atari VCS-2600, and this certainly happened with many Nintendo titles on both the Famicom/NES and Super Famicom/SNES.

So back to Lee, how could this be the second worst game on this Evercade collection? Well, the reviewer in question made some assumptions because it isn't instantly obvious that this isn't just a beat-em up with some platforms to navigate, and some lanterns to collect. A lack of patience, lack of exploration, and no background reading, meant that he abandoned this game before even opening the trapdoor on the second screen in. He didn't see the expanding gameplay elements, increasing difficulty and puzzle elements to the plaforms and so on. The review doesn't get much better from there, and again I see the same issue repeated in each subsequent overview of each of the titles included. Things aren't always instantly obvious especially to someone with nearly no experience with the C64 or its entertainment software. Although it's not all bad, some extra play time and a bit of background research would have helped ranking the games more accurately, especially if you're not going to persist with exploration.

As the YouTube reviewer in question has a negative feeling towards THEC64 Collection 1 for the Evercade, it turned into a bit of a pile-on by either people who don't like the C64 platform, or (I suspect) those who don't have anything good to say about Retro Games Ltd, because in some parts, you are one of the Kool Kids if you hate RGL. Because reasons.

One of the commenters in the YouTube comments section even went as far to suggest that the 1988 release of Impossible Mission for the Sega Master System was better because it was made by a "professional software development house" that "streamlined" the gameplay. I don't have a problem with the suggestion that a Master System game is better than the C64 version that it is based upon. It's the implication that Epyx in 1984 wasn't a professional software development house. Epyx probably had some of the very best video games designers and developers in the whole world in 1984. By the end of 1984, Epyx had published around 20 games including Impossible Mission, Gateway to Apshai, Pitstop and Pitstop II. I can vouch for how good these games are, and I'm sure many people will agree with me on those four titles. Its not just that these are great titles, but in 1984, each game would have been amazing. Add in that the video games industry wasn't yet 10 years old if you count from the launch of the VCS-2600, and that the C64 was only just 2 years old with many of its secrets yet to be discovered. This guy may be a Sega fanboy, but possibly also one of the RGL haters.

Anyway, that's my rant over. But it's worth noting that if the C64 platform, or for that matter any other 8-bit platform, is unfamiliar to you then often the games worth playing are difficult, sometimes abstract and many times unforgiving. Some games are limited by the way that the tile mapping works, for instance, or the limitations of sprite multiplexing, and there are other quirks that you'll get used to. But if you have a bit of patience, and maybe do some exploration, or some background reading, it'll all be worth it. Probably.

THEC64 Collection 1 for the Evercade

C64 gaming on the Evercade, finally...

I purchased an Evercade Handheld shortly after release, and whilst this console is pretty good, there hasn't been much for me personally. I do like the Atari 2600 and Lynx collections, though many of the 2600 games have been repackaged in various iterations over the years, and all of the good games still worth playing are available on several devices I own already. The only other enticing cartridge was the Oliver Twins collection, however the games featured seem to be from the Nintendo Entertainment System, a console that I never really owned nor have much time for. I would have preferred original ZX Spectrum games especially for those Dizzy titles, but I guess the graphics wouldn't have looked as good as those from Nintendo versions. An issue with games from 8-bit computers being played on consoles is that some of those will require reworking to accommodate the lack of a keyboard on the host hardware, which is why THEC64 Mini has a way of mapping keyboard inputs to a multi-button joystick, and an on-screen keyboard. These features have persisted though to later THEC64 classic models even though the classic edition has a properly mapped keyboard.

It perked my interest when I heard about THEC64 collection 1 pending release for the Evercade Handheld. This was announced just after the 40th anniversary of the original Commodore C64's launch to retail (it was launched in January 1982 in the same sense that the ZX Spectrum was launched in April 1982, though no one could buy either 8-bit computer at that time). At least it's retail launch in North America; most European consumers had to wait until 1983 to get their hands on Commodore's mainstay 8-bit machine.

Included in the 14 titles of this release are some well remembered classics, although when you have a back catalogue of at least 5,000 commercial titles, and many thousands of public domain releases, you'll never please everybody. And of course, with the C64 lasting so long commercially - 10 years in the UK if you count it's [UK] launch date - there are, to my mind, several eras for the technology during the 1980s and 1990s and people will remember those games by the releases around the time they first owned the C64. No one would forget their first game on such a machine, even if it wasn't very good.

Briefly, the games included on THEC64 Collection 1 for the Evercade are as follows:

1. Alleykey, by Hewson, published in 1986;
2. Battle Valley, by Rack It/Hewson in 1988;
3. "Lee", by Datasoft, 1984 (more on this later);
4. Gateway to Apshai, by Epyx, 1983;
5. Impossible Mission, by Expy, 1984;
6. Iridis Alpha, by Llamasoft, 1986;
7. Jumpman, by Expy, 1983;
8. Marauder, by Hewson, 1988;
9. The Monster Movie Game, by Epyx, 1986;
10. Street Sports Baseball, by Epyx, 1987;
11. Stormlord, by Hewson, 1989;
12. Subterranea, by Hewson, 1988;
13. Summer Games, by Epyx, 1984, and
14. Winter Games, by Epyx, 1985.

It's fair to say then that there's a good mix of early and mid-era C64 games from its first commercial era, before 16-bit platforms like the Commodore Amiga became established (at least in the UK and Germany anyway, North American users may have a different experience), and way before everyone wanted a games console for their main home entertainment system (again, this may differ for North American readers) rather than a personal or home computer. Early adopters of the C64 may well be drawn to Jumpman, or Lee (Bruce Lee), and even those who first got their Commodore later in the 1980s will recognise either Winter or Summer games. Hewson made its name with Paradroid, Uridium and Nebulus though sadly none of these classics are included. And Lee is interesting. Whilst this is version 2 of Bruce Lee, the rights to use the Bruce Lee name would have been either not possible, or prohibitively expensive, and may have made this sub-£20 cartridge well over £25, so it's credited to Psytronik Software and Code Digital, at least on the game art on the Evercade's carousel. It's definitely version 2 of Bruce Lee by Datasoft, something that you can discover by using the onscreen keyboard during play. I suspect Code Digital own the game code, and Psytronik Software did the cover art, and maybe made some code changes to the title screen so it reads "Lee" rather than "Bruce Lee™" - this, along with Impossible Mission and Gateway to Apshai are my favourites of the collection.

I mentioned the onscreen keyboard, this is available in any of the included games by pressing the Select button in game. And although the keyboard covers the game screen, it's not too distracting as it is either semi-opaque or completely opaque at your control. But it does mean that any future releases in this range will need to be carefully chosen, or require work to map any in-game key presses to the various buttons on the Evercade. But that does make me wonder what's happening in terms of the emulation. Is it using the same bespoke version of Vice that THEC64 range uses? If so, mapping the controller buttons is as easy as a simple text file - or a "Commodore Joystick Map" (CJM) in THEC64 speak.

The games in breif

Alleykat is a pacey vertically scrolling racer and shoot-em up which oozes Andrew Braybrook's class and pedigree, although I do find this game quite difficult and can never get very far into it. I'm sure with practise it can be beaten, and it's not a bad addition. My score: 7/10. Lemon 64 rating: 7.3/10

Alleykat Trivia: when run on the Commodore C128 in C64 mode, the game utilises some of the additional processing power available during the screen blanking, making for a faster game (it's difficult enough already though).

Battle Valley is a horizontally scrolling shoot-em up in which you take control of either an all-terrain tank or helicopter to destroy all enemy military installations and stop the launch of intermediate range nuclear missiles. It has some very nice graphics and excellent parallax scrolling effects. My score: 6.5/10. Lemon 64 rating: 7.1/10

"Lee" (Bruce Lee) is a game in which you must guide our hero through multiple locations in a screen-by-screen platformer with elements of a beat-em up, as you face two protagonists, the Green Yamo and a nifty Ninja. Collecting lanterns unlocks other areas of the game, which leads to a secret fortress protected by a powerful wizard. Once complete, the game loops and becomes more difficult, but it never becomes tiresome. A true classic in every sense. My score: 9/10. Lemon 64 rating: 8.7/10

Gateway to Aphsai is a multi-directional dungeon exploration game in which you must guide our hero to riches, find armaments and eliminate any roaming nasties found in those dank and eerie caverns, and if you get stuck, you may simply move onto the next level though sometimes at a cost, although the exploration of this game really is engrossing and skipping to the next level should generally be a last resort (for instance, when you have run out of keys to unlock other parts of the map). My score: 9.5/10. Lemon 64 rating: 8.2/10

If the C64 ever had a killer app then Impossible Mission would be a strong candidate. The infamous speech "Another visitor... stay a while. STAY FOREVER!" greets you, and from there, you must stop the Professor Elvin Atombender from obtaining US military secrets by infiltrating Atombender's underground silo in a screen-by-screen platform and puzzle game. There are multiple rooms to access and search, all connected by various elevators. Crack the puzzle and stop Atombenders malevolent plot for world annihilation! My score: 9.5/10. Lemon 64 rating: 8.7/10

Impossible Mission Trivia: In a review from a popular Commodore magazine, issue May 1987, it is stated that this game was originally released in 1983, whilst most sources state 1984. Side note: I always wondered why an evil genius would have candy machines in a secret underground bunker populated by robots.

Iridis Alpha is a well presented and somewhat psychedelic horizontally scrolling shoot-em up with two playing areas as each level has a mirror world. This game takes a while to learn and appreciate, so it's one where I recommend reading the game instructions, something that I never did as a child C64 owner. It may be off-putting to a new player, at least initially. But don't dismiss this too quickly, as some patients and a bit of background reading will help. My score: 7/10. Lemon 64 rating: 7.3/10

Another early C64 favourite is Jumpman which is a multi-level platform game with each level contained in a single screen. Simply traverse the ladders, platforms and ropes to collect tokens which affect certain aspects of the level as you go. To make things interesting, there are projectiles and other in-game objects such as robots to avoid. A note that this game requires the onscreen keyboard to start and to enter your name into the high score table. My score: 7/10. Lemon 64 rating: 8.4/10

Marauder is a well presented scrolling arcade shoot-em up in which you may fire lethal projectiles from your mobile battle car in one of eight directions. Your task is to infiltrate enemy territories, each well protected by various armaments and other leethal defences. My score: 7/10. Lemon 64 rating: 7.3/10

The Monster Movie Game does exactly what it says on the tin: you play an on-screen Monster in one of six Cities and various scenarios to enact for the viewing pleasure of the cinema audience. My score: 6.5/10. Lemon 64 rating: 7.3/10

Street Sport Baseball is a binary version of one of the most popular sports in North America, although it's simple enough for a non-Baseball fan to understand the rules of play, the computer player doesn't necessarily always provide the strongest of opponents. My score: 7/10. Lemon 64 rating: 7.3/10

Another polished and fun platform game in this collection is Stormlord, although I find this game very difficult. Explore the levels, find the keys, use the teleports and save the fairies. My score: 7.5/10. Lemon 64 rating: 7.3/10

Subterranea is a horizontally scrolling blaster with detailed graphics and silky smooth scrolling, though this is probably the weakest game of the collection. My rating: 5.5/10. Lemon 64 rating: 6.1/10

Summer Games is a mutliplayer sports simulator with a total of up to eight events to compete in, or each event may be practised until perfected. Although these events by themselves aren't at all bad, I find that the D-Pad controller on the Evercade does not allow for fluid play, especially on the joystick-busting events like the 100m Dash, although there's a mix of events where a D-Pad is just as well suited as a joystick. All events not being playable does reflect on my rating. My score: 6.5/10. Lemon 64 rating: 7.7/10

Unlike Summer Games, some of the events in Winter Games requires more precise and rhythmical joystick waggling, and the D-Pad is perfectly good for that. There are seven events to compete in, or to practise, my favourite being the Biathlon which has some beautiful Nordic-esque backdrops. My score: 7/10. Lemon 64 rating: 7.3/10

Overall, I think this first THEC64 cartridge is a very good value package with three real gems in the collection. Hopefully, this won't be the only release with C64 games for the Evercade, and with it being branded THEC64, and as I mentioned to earlier, I do wonder if this is running the bespoke Vice version found in THEC64 and Mini. I also hope that there will be a "THEVIC20" collection too? If there is to be a second release (no doubt Retro Games Ltd and those people paid royalties for their wares being included in this package will be keeping a keen eye on sales) then I hope it will include at least one or more recent C64 game such as anything from the Metal Warrior series. Now that would be awesome!

A tribute to Milo Mundt - RIP :'(

Milo Mundt, also known as MacGyver to people who are in and familiar with the Commodore C64 scene has recently passed away. The sad news was relayed to me on 14th October 2022. He was just 43 years old, just two years my junior.

He was a long-time and passionate advocate of the famous aforementioned Commodore 8-bit, and I first made contact with him over 20 years ago now, and what different times they were. Back then, I was trying to establish a retro-based fanzine. I didn't want my fanzine to be purely about looking back on this game or that computer, as I knew that the C64 especially, and likely other 8-bit home computers, still had new hardware and software being manufactured, albeit no longer mass produced, but enough was happening to take note of.

After doing some research on my dial-up modem, or maybe an early ADSL line, I produced a small PDF called Retro Computing Today which was picked up by the editor of Micro Mart magazine in the UK (when it was still published by the Trinity Mirror group and was based in Birmingham). The then editor, Simon Brew, phoned me and offered me a weekly column about all of these new 8-bit developments.

One of my first few columns that was printed in Micro Mart, in fact I think my second, covered a game called Bomb Mania, published by the German-based Protovision, of which Milo was an active member. At the time, the weekly circulation figures for Micro Mart was around 25,000. And for the first time since the mid-1990s, new C64 software was being reported in a main-stream IT-based publication, before Retro Gamer from Live Publishing was a thing (of course, there was a Retrogamer fanzine, which I recall being written and published from a guy from Liverpool), and even before the Retro section in gamesTM. It was at this point that I sent a photocopy over to my column to Protovision, which appeared on the fledging official website for the 8-bit software company.

During that time, and through my 9 months or so of being a staffer at Live Publishing's Retro Gamer, I worked closely with Milo and other English speakers at Protovision to try and promote what the group were doing. Milo was always very kind to me, allowing me to know about Protovision's developments for my news columns, and sending me software to review and sometimes even preview. It was thanks to my friendship with Milo (and the fact that I owned a CMD SuperCPU) that I got to review Metal Dust in Retro Gamer, something that I'm still very proud of, and a game that is now something of a C64 legend which people either love or hate, usually for all of the wrong reasons on that latter point.

In I think 2005, I met Milo, Jakob Chen-Voos and Malte Mundt (one of the founders of Protovision and Milo's older brother). The group travelled over from Germany for the CGE UK in Croydon. In person, the guys were very kind to me and I got a free t-shirt in the process. I remember that Milo took a picture of me wearing it.

Unfortunately, my tenure didn't last at Retro Gamer, and not long after I found myself in some personal difficulties. Retraining, becoming a father, and other life events overtook my retro computing hobby, and I faded in and out of the "retro scene". But early in 2022, Milo contacted me to see if I could help with English translations of Protovision news items. Whilst I was happy to commit some time as and when, again real life events got in the way. Sadly I could not contribute as much as I would have liked, but this is something that I am trying to rectify.

Aside from the Commodore C64, Milo was a Social Worker, which is something else that I had in common with him as I had worked for Social Services before becoming a full-time writer. I knew him to be a passionate and compassionate person, and would like to extend my deepest condolences to his family and friends. May he rest in peace.

Are you only allowed to say nice things about the ZX Spectrum Next?

A few years back, after ordering on Omni 128 HD, I had the opportunity to procure a Sinclair-branded ZX Spectrum Next. The Omni is made-to-order by one guy as far as I can tell, whilst the ZX Next was a KickStarter campaign. I had to wait for both machines to turn up. And it was the Omni that turned up first, although the screen arrived before the main unit. I'm not complaining about the delays here; I'd rather get something than nothing, and I was very happy to receive my Omni and ZX Next.

The Omni itself looks like a truly authentic ZX Spectrum if viewed from the front. The video output is different, and it has an SD card slot on the side with some dip switches to configure the device. It allows the addition of rechargeable batteries, so that it can be truly portable, and once configured and running, loading games via the cassette and/or from SD card is pretty painless. It is able to load TR-DOS images too, and as we know, any Spectrum clone already has plenty of software. I was very impressed. Forget your Apple something or other; not only have I never been a fan of Apple products, I think its historical devices are considered in higher esteem than cheaper machines (such as Sinclair and Commodore computers) for no good reason. I mean, who could afford an Apple ][, with Apple itself doing not much more that pioneering the high price point. I would say that though, wouldn't I?

Anyway, everything about the Omni felt right; the keyboard, the faceplate and the flat screen is good. The only issue really is that the hand-made plastic legs to fit the screen to the computer are a little brittle, and it could do with a bit more weight in the computer itself to counter the weight of the screen. Other than this, the Omni is a great device. You switch it on. It works. It's easy to use. And it can be used anywhere with some good battery life. It feels like a proper end-user product in the Sinclair tradition. Overall, I was and am very happy with it.

Getting my ZX Next some months later was slightly disappointing. The excitement when the box arrived, and seeing it for the first time, soon led to an anti-climax. Plugging in the device and testing it was good. Then I read online that I needed to update the firmware, which I did. I tested some games, and then unplugged the unit. The power cable was removed but I still saw what looked like a crashed Spectrum screen. I panicked as I thought I'd broken it somehow, but it turns out that using the HMDI port has its issues and you must remember to unplug the HDMI cable before unplugging the power cable. Well, at least I hadn't broken anything.

Next, I noticed that there was a CP/M mode, so I thought I'd try it. I had to get online to get CP/M working in the form of downloading some binaries. Once it was up and running, I was able to load some compatible software. Now, never using CP/M before put me at a disadvantage, but something happened where I couldn't get CP/M working at all anymore. I couldn't work out what I'd done, so I didn't know how to undo it. It wasn't until some months later before I could get it working again, but I don't know how I have, so any fix is purely accidental.

Some time after buying the Omni, I found some games that use the Nirvana engine; this allows ZX Spectrum games to be much more colourful, meaning that software sprites are not limited to two colours per 8x8 character cell as usual. One of the best examples of this is Pietro Bros by Cristian M. Gonzalez, Alvin Albrecht, and Einar Saukas. This works beautifully on the Omni, so I decided to give it a try on my Next. For some reason, it wasn't working, in that the Nirvana engine didn't seem to be working. It might have played the same, but it looked woeful and there was blatant colour clash everywhere. I know the ZX Next has more precise timings than the Omni, and clearly a better specification. So, what was going wrong here?

It turned out that the RGB output wasn't supported via HDMI, only by VGA. So, in order to play this and other Nirvana engine games on the ZX Next, I had to obtain a VGA monitor. As I didn't have one spare, this meant purchasing one. My monitor arrived, and I eagerly plugged in my ZX Next to my VGA VDU. And... Nothing. No video. Had I broken it again? Okay, so I tried the HDMI and got a picture. More searching the Internet and I found out that I needed to configure the machine to the screen it was using, especially if I changed screens for some reason. Well, luckily it wasn't too difficult, and the Next would run through its screen modes with a test card until you get one that fits. All good then, right?

Now my final gripe. I know that the ZX Spectrum never had a good keyboard, but a cheap one. The Speccy+ and 128+ also had cheap keyboards. I have aging models of these that still work today. Most importantly, the keys are still in place. On my ZX Next, however, I've had two keys somehow become detached from the keyboard, and I have to be very wary about using it and travelling with it. This is hardly convenient as I now take this and other machines to show to people, and to let others play on it.

With exception to the cheap keyboard, I think the issue with the ZX Next really is this: feature creep. I was happy when I heard about the original plans for the ZX Next. I think had the original specification and scope been adhered to more strictly, it would have been a cracking machine. But it seems like, maybe due to delays, and maybe trying to please too many people at once, the machine was released in an unfinished state. The HDMI is one pointer to this. The manual is another.

I know that this feature creep has meant a more powerful machine, but why did it need to be more powerful? Why wasn't the original specification enough? For most users I suspect, they will be playing original Spectrum games on reliable, modern hardware. So all of the nice extras, and some of which I haven't even used, are for limited use-cases where no more than 10 - 15% of the userbase will ever benefit. That's fine if you're planning to make a million machines, but this is a machine which exists in the thousands, so these limited use-cases should have been ignored in my view, and any of the extra goodies that were proposed along the journey should have been dropped, like the "SID chip" support, which isn't worth the PI Zero installation really, as it doesn't handle SID files very well. I guess this is what happens when enthusiasts are leading the development of a product, rather than a singular and more realistic and hard-nosed visionary. The ZX Spectrum Next is the Snakes on a plane of "new retro".

Here is the question? If I had to choose only one, which would it be? The Next or the Omni? Well, the Omni has been much less problematic, and once set up, it works perfectly well. I would choose that over the ZX Next. Of course, the Omni doesn't have the same exact timings of the ZX Next. And the ZX Next has a far superior specification, but that doesn't mean it plays my favourite Spectrum games any better. And those games that don't load on the Omni aren't significant in number enough for me to be worried about it.

The Omni plays enough of my favourites, and I don't have to mess about just because I use a different screen as there is only one video output to worry about, and the keyboard feels really authentic. It also works with the original Mic and Ear cables, whilst the ZX Next opted - for no good reason - for the Spectrum +3 tape leads.

Don't get me wrong. I do like my ZX Next. It's just not the finished product that I was hoping for. And in conclusion, I do hope that the next ZX Next irons out these issues with the next Next Kickstarter, especially to do with the keyboard, and as I am one of the backers of it. Anyway, I'm going to give Target Renegade a quick blast. Who wouldn't, eh?

Why use THEC64 or THEVIC20? What's the point, when you have real hardware?

So, here's a question. I own an Ultimate 64 Elite with two 6581 SID chips installed, and an Ultimate 1541 II which I use in conjunction with my Commodore C128D-Cr, CMD RAMLink, SuperCPU and FD4000. I also own a C64GS, two SX-64s, some other C128Ds, and several variants of the C64 and C64c. Surely I wouldn't have a use for THEC64, would I? Not that thing with the broken joystick according to some people on the Internets.

Well, if you're talking about THEC64 Mini, no, not really. The most use I get out of my Mini units is for some testing occasionally for Retro Games Ltd. Although it's smallness is useful sometimes in the communal living room (say if I want to give Soulless published by Psytronik Software a few hours of my time, or any of the other carousel games for that matter). It's great that it works on modern-days TVs too. If I wanted to, I could take this anywhere pretty easily, and for extra software I just need a USB drive. In that way, the Mini is pretty convenient.

My main interest is actually THEVIC20 model. I think it's an aesphetically pleasing machine; I love the keyboard, and its slate-white casing, and joystick. It's a really nice tribute to Commodore's first colour computer. But why would I choose to use it? Surely I have no use for it... it's just running VICE, right? On a Raspberry Pi, right? (Definitely not, it uses Allwinner Technology boards). Why don't I just buy a Raspberry Pi anyway and spend time learning how to set up BCM (I think it's called) and get with the kool kids?

Firstly, I'm not and will never be one of the kool kids. Aside from that, I don't have time to mess about setting up emulators (even if it's relatively simple). Building my U64 Elite was about as far as I wanted to go, finding the required ROM images and getting a spare casing, keyboard and some SID chips. And I know from trying to set up a version of UAE on a Raspberry Pi that I'm not cut out for it. I mostly want things that I plug in, switch on and that's all the set up that I need these days.

Moreover, the reason that I have a use for THEC64 (or in my case, THEVIC20 - well I actually have two THEC64 units as well, and another THEVIC20) is because I actually like the VIC-20. Using the VIC-20 mode on THEC64/THEVIC20 is a really good user experience. Most importantly, the keyboard is properly mapped to the original. And secondly, THEVIC20 joystick bundled with the machine is really nice to use. Some people don't believe me, but if you've read my VIC-20 articles one published in gamesTM, and another more recently in Popular Retro magazine, you will know that I really do have a soft spot for this friendly computer. Yes, the graphics aren't the best, and the screen area is small. BASIC 2 has always had its shortcomings, and it's a very limited platform even for its original launch in October of 1980 (as the VIC-1001 in Japan). But it's a charming machine that has a warm and fuzzy feeling for me, and all of this reflected very well in THEVIC20.

More than this, my actual Commodore VIC-20s, well one of them isn't working and the other is a VC-20, they don't work well with modern days televisions, and there's a lot of messing about with various hardware to use all software available (yes, I know there are cartridge upgrades available that allow for multiple memory schemas, but I seem to have lost mine). Albeit, there aren't many releases that require more than an extra 16KB of RAM, but there is Doom for the 35K machine by Steve McCrea and all considered, it's a pretty good version too. It's also not trivial on the VIC-20 (or VC-20, or VIC-1001) to play games written for PAL if you have an NTSC machine, or NTSC if you have a PAL VIC. THEVIC20 and THEC64 handles the various VIC memory maps and NTSC/PAL pretty well, and it's fairly easy to do.

Of course, some people still don't buy this. One guy on BookFace actually said to me that there was no way I could own a U64 Elite and still use THEC64 or THEVIC20 - even though I pointed out that the U64 DOES NOT mimic or emulate the VIC-20 hardware in any way (less the shared Kernal, BASIC and CBM DOS, of course). I suspect that this guy just doesn't like the VIC-20 platform so probably doesn't see the point of loading any VIC-20 software on anything ever.

A broader point is that THEC64 platform is made for an audience that just wants something that works out of the box; no messing about with installing this or that on some Raspberry Pi and then setting up configurations, finding various ROM images (not game disk or tape images, you know, the BASIC, Kernal and character ROMs from the original hardware) and then a suitable housing and probably not properly mapped keyboard (this point is the most frustrating on modern-days PC emulation and the like, especially if you do BASIC programming like I do).

If you're happy with using a Raspberry Pi for your retro gaming needs then good for you. If you think that everything else is worthless because you own a U64, then that's pretty narrow minded and stupid. Stuff that works out of the box is good. The newer micro-switched joysticks [for THEC64 range] are good, and now there's even mouse support, and that even extends to third-party USB mouses too. In fact, I use a trackball on THEVIC20.

Yes, there are still some shortcomings of THEC64 platform, one of them is that you only have one drive locked to device 8 (although that could be a 1541, 1571 or 1581), and I'd like it to support multiple drives to try GEOS on. Most users won't be using GEOS on THEC64. Another thing that I'd like is the ability to add a second SID chip, but then again I have a U64 with two real SID chips, so this is another outlier case, and you have to manually configure the second SID to be used by the (small amount) of software that supports it anyway, and that changes from one program to another. But for most users most of the time, THEC64 set up perfectly for them.

Anyway, I'm off to play one of my favourite VIC games Rockman, on my beautiful THEVIC20.

If you have an Ultimate 64 Elite, why are you still using your CMD SuperCPU?

I'm sure some of you are pondering why as a long-time Commodore C64 and C128 user (and one that owns an excellent Ultimate 64 Elite) I have a mild interest in the CMD SuperCPU and other CMD hardware? Doesn't the U64 Elite do everything that my CMD devices do? And if not, why not? In order to understand this further, I'll take you back to the 1990s, three years after I'd returned to the C64 platform following some time with the Amiga A500.

I have to say, I didn't then (and don't now) dislike the A500. It's a perfectly good machine and produced some pretty outstanding graphics, especially when compared to its contemporaries of the 1980s, when CGA was the most common standard on the IBM PC and compatibles, and for most users 640KB of RAM really was enough.

Even in 1991 and 1992, the C64 was still a supported platform in the UK by the main software houses such as Ocean and US Gold (as was the Sinclair ZX Spectrum and Amstrad's abominations, including its acquired Sinclair variants).

Clearly, the A500 is a more powerful machine than the C64, so why return to it? Well, I wasn't actually much of a gamer. I mostly played games to see what they could do, and I actually in many ways preferred C64 games because games were simpler (though not easier), and therefore I had a better understanding of them. I could imagine myself making a game for the C64, but the A500 seemed a step too far. Just doing simple things seemed much more difficult or involved on the Amiga platform, and I tried. Looking at for instance Amos BASIC, I couldn't easily understand it. It felt like I could understand most program listings on most 8-bits (albeit BASIC of course), even if those listings delved into some machine code.

For me, returning to the C64 was like becoming reacquainted with an old friend again. This time, though, I got to see more of what this machine could do, how it could be expanded beyond the tape drive and printer that I had as a younger child (I was 16 in 1993). I'd have more use for this computer than just games and BASIC programming. And it all started with the 1541 single-sided floppy disk drive, and fortunately, a certain High Street Micros in Crewe was still trading, and still had much of its stock of hardware and software from the 1980s.

My time then was spent between learning guitar and bass, practising with the band, drinking alcohol with or without the band, and of course Commodore computing. In September 1993, I started a college course at South Cheshire College, at that time the Bedford Street Annex (now private housing). We had there stand alone 286 machines with WordStar (I forget the version) as well as shared dot-matrix printers (Panasonic KX-P range I think). It was after this that I realised that my humble C64 could do what I did at college on a PC, I just needed a printer, a printer cable and a word processor. It wasn't until around 1994 when I finally got set up, thanks to Electric Boys Entertainment Software Importing Service that had the rights to distribute GEOS 2.0 in the UK, as well as importing all of that lovely CMD hardware, and making Centronics compatible printer cables so I could use the same printers as any PC used.

GEOS 2.0 is perfectly good, especially as I had obtained a higher capacity 1571 drive (approximately 340KB per disk, rather than ~170KB), but it wasn't until I got the CMD RAMLink until I saw a real performance improvement. GEOS was bundled with a rather handy (though American) spell checking application, the dictionary for which was around 96KB as I recall. This was okay, though it took time as GEOS would access the disk drive a lot, especially for programs or data that exceeded the C64's internal RAM such as geoSpell. So, whilst the RAMLink didn't directly add 16MB to my system, it did add a 16MB RAM disk partition (or multiple partitions of any size up to a single 16MB partition, but generally 800KB per partition which mimicked the 1581 3.5" disk drive) that GEOS could read from and write to. This was FAST, and if you were (as I was) used to the speeds of geoSpell from a 1571 disk, you really noticed the performance increase. In my view, just having a fast, mass storage device like the RAMLink really opens up the possibilities of what a C64 can achieve. That was obvious to me, but clearly many of the remaining C64 users then did not see, nor were interested, being perfectly happy with a 1541 and/or Datasette, and whatever new or Public Domain software was out there (at that time, the PD and demo scene was probably producing more software than anything that could be classed as commercial, at least from a UK/European viewpoint).

With the RAMLink and GEOS, I had the bug again. I got CMD JiffyDOS chips for my drives and machines, and got a CMD FD2000 3.5" disk drive which could write up to 1.6MB per disk - a good amount of storage for a C64. Sometime in 1995, my Dad got a P120 PC for the house with 16MB of RAM. So, a few things I noticed. The PC was okay. Windows 95 was okay. But it wasn't stable, not when compared to GEOS. And it wasn't significantly faster to do things like work processing than my 1Mhz C64 with a RAMLink and FD2000. It wasn't better to print out my documents for college, especially when you had to reinstall Windows 95 again just to use MS Word or something similar. But hey, that's progress for you, and it took [in my view] a long time for that progress to finally pay off.

Of course, if you were a gamer, the IBM PC was progress if only for the fact that new, shiny titles were being developed for it. Forget that you may have had to re-install Windows 95 two or three times. Not that new software wasn't being developed for the C64, of course, but some of it didn't feel 'new'. Some of the releases from Electric Boys and Psytronik were perfectly good (though there were too many games authored with the Shoot-em Up Construction Kit for my liking, and loads of Tetris clones flooding in from Eastern Europe as I recall). And with Mayhem in Monsterland being released around December 1993, and Lemmings in February 1994, the big names like System 3, Ocean, US Gold, Gremlin Graphics and others weren't supporting the C64 anymore, so gamers flocked to other platforms pretty rapidly in the UK.

Eventually, the SuperCPU arrived, and I got one in the late 1990s, I think 1998 but I can't be certain. Again, using the geoSpell as a benchmark, things weren't just a bit faster, it really was like going from a IBM PC Junior to a 486-DX 33 or something equally as lavish. And of course, GEOS wasn't less useful but more so, as the SCPU improved the access times to the RAMLink, which was already the fastest drive available for the C64 or C128.

At some point in the late 1990s or early 2000s I found out about Allan Bairstow's Commodore Scene magazine and importing service. I had wanted to start my own fanzine (and in fact, at some point in the late 1990s I wrote an article for a magazine called PC Mart which took months after submission to appear in the magazine due to some technical reasons that I don't remember, by which time it was very out of date). These years are a little hazy as a certain alcoholic drink called Southern Comfort would take my free time and money. But in the early 2000s, after temporarily sobering up long enough to attempt at my own fanzine and trying to organise a 8-bit computer show in Crewe, a guy called Simon Brew noticed my PDF [fanzine] and actually quite liked it. So, in early 2002, he offered me a weekly column in a magazine called Micro Mart to write about all things 8-bit (and some things 16-bit, where it did not encroach on the weekly Amiga Mart column). After about a year of writing, an upstart called gamesTM appeared with it's own unimpressive "Retro" section, and then of course Retro Gamer happened.

I first met Martyn Carroll at the first Micro Mart show in November of 2003 (I think). It was held at the Birmingham NEC, and I had organised a group of like-minded 8-bit enthusiasts to bring along their rare hardware and software to show off and talk about. As Martyn is from Stoke, it wasn't far for him to travel down to the NEC. I overheard him speaking to Allan Bairstow about the possibility of a new magazine in WHSmiths and everything. I promptly (rudely?) introduced myself to Martyn, and it seemed that he had read my column from time to time, so that was good.

In early 2004, I got a call from Martyn asking me to write a Commodore article for issue two of Retro Gamer. At that point, RG was intended to be a quarterly magazine, so I had loads of time to do my research. I anticipated that Martyn would want ~3,000 words, but he wanted more like ~10,000. So I was glad that the deadline was a long way away.

I started my research in haste; much of it was already done in fact, I just needed to put it into a Notepad text file. But then something happened. Martyn phoned me to say that the deadline was brought forward slightly, and could I have the article written in two weeks as RG was going monthly. Two weeks. Ten thousand words. I'd never written more about one subject at any point in my life, not really. I wasn't a graduate, and only had some College education, and no GSCEs to speak of. Ten thousand words. That was a big ask for me. So every spare minute was poured into this article. But I'd made a fatal mistake: Windows Notepad had a character limit, and I exceeded it, and in the process losing several paragraphs. I needed something that would better handle this, so I reluctantly turned to WordPad - note that I didn't yet have a good file sharing solution between GEOS and my PC. The various options that I had tried had been unsuccessful for me, but more on this later.

So, I got everything ready, ~10,000 words of Commodore 8-bit computers, with suitable JPEG images and such, all submitted on time. This was the lead feature in issue two of Retro Gamer. And shortly after I left my job at Social Services and started as a staff writer at Retro Gamer. The date is easy to remember, it was Tuesday, 4th May 2004. Issue three had been published, and I started work proper on issue four. Or was that issue four had been published? I don't recall. Anyway, I finally found out about geoDOS. By this time I had a Commodore C128, and I could use GEOS 128 (with the 80 columns screen) with my SCPU, RAMLink and FD2000. I could therefore write my articles for RG on my C128 and transfer them over to my PC. Of course, I wasn't then a good writer. This was my first office job, and I didn't know about such things as office politics. I didn't have a degree and had never been an undergraduate, unlike all of my colleagues. So, I was very much in the deep end, and not surprisingly I was sacked from RG some nine months later.

So, back to my original questions: Doesn't the U64 Elite do everything that my CMD devices do? And if not, why not? The U64 Elite is great. I really love it. The HDMI is very useful, and it sits on my desk at work for use during my lunch break. I've even wrote a couple of programs that are useful as a modern-days Scrum Master that'll work on the U64 and C64.

At home, I have a C128D-Cr, RAMLink, SuperCPU, FD4000 and some other hardware. The thing about the U64 is that whilst it's really lovely, it doesn't do C128 stuff, and unfortunately much of my CMD hardware (less the disk drives) won't work with it. I had hoped that I could use my SCPU with my U64 getting the best of both worlds, but this doesn't work. So, there's still definitely a place for all of my CMD hardware to use. And the U64 does not (yet) do everything that I want it to. Of course, for C64 gamers and developers, it will fit them perfectly. But anyone who has enjoyed and enjoys computing on the C128, using C128 specifics, the U64 will never completely fill that gap. I'm just wondering when we'll see an Ultimate 128? Probably never.

Will Doom or Wolf 3D run on the Ultimate 64 or Turbo Chameleon

As you may already know, Mathias "AmiDog" Roslund has ported two classics from iD Software, being Doom and Wolf 3D, and both require a CMD SuperCPU to run, as well as a higher capacity Commodore C64 disk drive, such as a CBM 1581 or [CMD] FD2000/4000. If you have a Ultimate1541 II, which emulates a Commodore Ram Expansion Unit schema up to 16MB, you may pre-load either the Doom or Wolf 3D "REU" image into that memory, and use a simple 1 block boot program to very quickly load either game into the SCPU. This may also be done with the VICE emulator, and I suspect this is the main way that people load each game on the XSCPU64 emulator on the PC.

Let's have a quick recap of what the SCPU does for a moment. This is a turbo cartridge that plugs into the C64 or C128 and runs approximately 20 times faster than a stock C64, and around 20 or 10 times faster on a C128 (depending on which mode you are in, as the C128 itself runs at 1 or 2Mhz). This is possible due to the (overclocked) and 6502 compatible processor in the SCPU, which is a WDC65c816S, running at 20Mhz. Aside from the extra speed, and built-in JiffyDOS (which in itself makes using all Commodore compatible drives much easier), you may add up to 16MB of RAM by using certain types of 72-pin SIMM RAM (fairly popular in PCs around the late 1990s), which can be 1MB, 4MB, 8MB or, of course 16MB. To add the extra memory, you will require a SuperRAM card on your SCPU - it does not do this as standard. Of course, some people would be perfectly happy just with the performance increase, especially GEOS users, or owners of other CMD hardware such as the RAMLink (still an excellent mass storage drive today).

So, here's a question that some people ponder. On the face of it, requiring 16MB and a faster processor, wouldn't either Doom or Wolf 3D work on the Turbo Chameleon or Ultimate 64? Well the short answer is "no" - but why?

Firstly, neither the TC, nor the U64 (or U64 Elite) have the right sort of memory. The builds of Doom and Wolf 3D we're discussing here runs in memory above 64K, the 6502 processor (no matter how fast it's running) can only address (or see) 64K at any one time, and the REU can only send memory to, or copy memory from, the C64's internal memory. This is unlike the SuperRAM described above, which allows the SCPU to see up to 16MB of RAM and therefore directly read from it, write to it, or execute code within it.

Secondly, both Doom and Wolf 3D are recompiled to native 65816 machine code on the SCPU. When you switch on the SCPU, you're running in emulation mode, which is actually a 65c02. Whilst this is largely compatible with the 6502 and 6510 processor, the 65816 does not do undocumented features that some C64 games and demos use, just like the 6510 does not understand the extended instruction set of the 65c02 or 65816.

I've spoken to Gideon Zweijtzer who designed and built the superb U64 and Elite (as well as the very excellent U1541 range) and he has ruled out the U64 ever having a 65816 option. This was also ruled out from the start by the guy who designed and created the TC, because as far as he was concerned, being able to perform the undocumented instructions of the 6510 was much better than having the extended instruction set of either the 65c02 or the 65816. I know that there are plenty of 65816 protagonists out there, for rather dry technical reasons.

The question is, would either game be possible in 6510 with REU support (like Sonic was possible with the REU)? I'm guessing that Wolf 3D would be, but I think a true port of Doom would be a step too far. Maybe. As the U64 Elite (an excellent machine which I own) can run up to 48Mhz, and you can even switch off the bad-line timing (where the VIC-II steals cycles from the 6510), someone might find a way, but as with everything on old 8-bit computers, you're largely dependent on other people's good will, time, effort and expertise. And this last point is why I really do appreciate new 8-bit software, because most developers making 8-bit games do it for the love of it.

THEC64 and SuperCPU emulation

This is a question that I see in various places: "can the SuperCPU be emulated on THEC64/THEC64 Mini?", and I usually respond even though some people insist that I don't know what I'm talking about. I mean, how could I know more than they do anyway? The Raspberry Pi is likely able to emulate a system more powerful than a C64 with a SuperCPU, so THEC64 Classic and Mini (which many people wrongly assume is just a Raspberry Pi) must be able to do it. Right?

To establish the long answer, the short answer to which is "no", I'll firstly adumbrate my credentials so you, dear reader, will have some confidence that I do know - in a small way at least - what I'm talking about. Let's start at the beginning for me, my rekindling of my Commodore C64 hobby (some may say obsession).

I left School in 1993, and was working at the local Bacon Factory in the freezers before I'd officially left. It was around this time that I saw a magazine on the shelves called Commodore Force (CF), and shortly afterwards, I noticed that Your Sinclair (YS) was still just about going. I started buying CF and managed to get the last two issues of YS along the way. The first issue of CF that I picked up was no. 8, and was an avid reader until the end. I then had to switch to the other CF (Commodore Format). This was the year that I got back into the C64 platform, and not too long after this, I learnt about GEOS and the excellent hardware from Creative Micro Designs, Inc.

Despite my love of computing, I studied Health and Social Care, and around 1996 or so, I started working for Social Services. It wasn't until 2002 until I got my first computering job, that being the weekly Retro Computer Mart column for Micro Mart (MM) magazine.

On 4th May 2004, I started as a staff writer for Retro Gamer (RG) magazine, then published by Live Publishing on a business park just outside of Macclesfield, in Cheshire (UK). This wasn't "real" computering. I wasn't then a Computer Scientist. But I did know enough about the Commodore C64 platform specifically, and Commodore's 8-bits more generally, as well as some Sinclair machines, to pass myself off as a sometimes good enough writer for printed matter magazines, back when printed mattered.

The gig at RG didn't last too long (I wasn't then much of a writer, and still now am not significantly better). Anyway, around mid-2005 I started working with a guy called Paul Andrews, and shortly after that I was interviewed for an open freelance job by Darren Melbourne. The interview was somewhere in Manchester City Centre. His company was Ironstone Partners, and he spoke to me about an agreement whereby I'd work to track down any holders of intellectual properties, copyrights and trademarks to mainly Commodore but also other 8-bit software. I knew that this was something that Paul was doing, so I declined, but pointed Darren in Paul's direction. Eventually, they both worked together to bring THEC64 Mini, THEC64 Classic, THEVIC20 and now THEA500 Mini to the world. These machines probably wouldn't have happened had I took on Darren's offer in the first instance. So, you're welcome.

Between 2005 and around 2007, I did some other freelance writing for gamesTM (gTM) magazine and a few articles for RG. Returning to RG was quite stifling. Whereas I had a pretty free hand under Martyn Carroll's editorship (too free, in fact), it was quite the opposite with Darran Jones at the helm. I'd worked with Darran briefly for gTM, and I don't dislike him personally. But what he wanted from me wasn't what I wanted to do, so my second time at RG ended pretty quickly and there's no reason for me to write for this magazine again. Just a brief example here, for one of the issues I had to write one page guide (~600 words) about an Atari VCS-2600 PC emulator. I think it was called Stellar. I could have written it in about 60, and I think I managed to write six or eight steps for this guide. It was nearly all a work of fiction. None of the steps I described worked - at least not on my PC, although were mentioned briefly in the documentation. I'm guessing that Darran didn't check my guide step-by-step to ensure that it was factually correct, or didn't care. Either way, there was no point continuing, and that's before I tell you about the remakes that I "reviewed".

It was 2009 when I finally started my journey through the realm of Computer Science, thanks largely to Manchester Metropolitan University, but also briefly the University of Derby and Birmingham City University. All through this time, and up until I think 2014, I continued my freelance work for MM. But in 2012, I started as a PHP developer, and along the way I've done some C, ObjectiveC, C#, and of course JavaScript.

After 2014, there wasn't much for me in "retro" computers. I was no longer writing for MM (way too busy with developing web applications and websites), and had (and have) no reason to write for gTM (now defunct anyway) or RG. I did make some enquiries to try and rekindle my writing, but nothing happened, and some of the newer publications that had appeared between 2005 and 2014 were run by, edited by, or owned by people who I knew that I couldn't trust. The one thing I wanted to do, and still want to do, is to make some software for the SCPU platform, but am just a novice at 65x based machine language, and there is currently no good C compiler that can build 65816 binaries and executables.

Anyway, around 2016, I first learnt about THE64 Computer, and this project changed course somewhat due to the Kickstarter (or Indigogo) funding goals not being met, but THEC64 Mini did happen. Honestly, I wasn't keen on the original designs of THE64 Computer, so it was for the better in my opinion. I picked a THEC64 Mini up in 2017 I think, and shortly after Paul Andrews was in touch. He wanted me to help with testing of THEC64 Mini US Launch and sent me a test machine that I could test various versions of the firmware developed by Chris Smith. I spent a lot of time testing and noticed some anomalies that had not been discovered. One issue that I found was whilst testing with Turrican. It was a good game to test because it's quite easy to complete, but also technically very good, and enough to show any shortcomings of the emulation. After a certain amount of time into playing Turrican, I noticed sound drift that was quite obvious. Chris could not recreate the bug, so I recorded it for him so that he developed a suitable fix.

When the Covid-19 lockdown hit, I was put on the furlough scheme through my employer at the time. This wasn't great for me. I got very bored, and very quickly. So, around April 2020 I started looking for a new job. I eventually found employment at a company called Low6. I would not ever recommend working for this company as a developer or in any technical role, for reasons that I will not divulge here. It is the only job - not just developer job, but any full-time job - where I've only lasted three months. I think that says enough.

Shortly after leaving Low6, Paul Andrews found out that I was unemployed. I think it was through Facebook. He asked me for my CV and I was soon interviewed by Chris, and although the work was on a rolling monthly basis, I was offered a job at Retro Games Ltd (RGL). Of course, working on THEC64, a recreation of the best personal computer of the 20th century (and perhaps ever), who would turn that down?

I was lead tester and worked to introduce Scrum and Agile methodologies and QA processes. I worked on the firmware upgrades for all models of THEC64 to the January 2021 update, and shortly afterwards there was no more work for me at RGL. My work there was done. I also did some work on THEA500 Mini but found that the hardware was much more difficult for someone who hadn't used an Amiga of any description since the 1990s (remember that I upgraded to a C64 in 1993, leaving the Amiga platform behind).

You could say therefore that I know the Commodore C64 and C128 pretty well, not an expert, but good enough to do real testing and give accurate feedback and advice to help improve the user experience of THEC64 Classic and Mini. And, owning two CMD SCPUs, two RAMLinks, two CMD HDs, and three or four FD drives, I know the SCPU pretty well too. So here's why THEC64 Classic and Mini will not emulate the SCPU.

Firstly, RGL is meticulously in licencing all software (which SCPU emulation would be part of the firmware, so it would require licencing). Now, we know who owns the rights to the SCPU and other CMD hardware, but licencing will either be difficult to obtain, or expensive. So even if this was possible, this won't be in a firmware upgrade for THEC64 as all firmware updates have been released at no cost to the user, so far at least.

And secondly, THEC64 isn't just running an off-the-shelf version of VICE. It is a proprietary version of it. Some of it is of course open source. But not all. It has to be this way so that the user experience is good on the host hardware (which again isn't just a Raspberry Pi).

Sure, you may be able to hack a unit to run the XSCPU64 emulator. This may work well on THEC64 Classic. But on the Mini, I think you'll have at least sound drift issues that I experienced with Turrican on the bundled 'stock C64' emulator, or have to run the SCPU emulation at 25 or 30 frames per second (rather than 50 or 60). I suspect both compromises will have to be made. RGL won't add features that don't work well on all models of THEC64 for the obvious reason that the Mini is by far the best selling model. I suggest using VICE on an old PC rather than getting an inferior experience from hacking THEC64 Mini to emulate some of the SCPU 64 v2. You may use the joystick from THEC64 with VICE these days on your PC, so you can just pretend it's THEC64. Some people assume that there's no practical difference between VICE on a PC (say WinVICE) and THEC64 anyway.

On a personal note, it's great that this question keeps popping up. It shows that, regardless of what the C64 scene thinks about the SCPU, general users are curious about it. Even if it is only to play Metal Dust, which as you will know from my other blog posts, isn't the only game to play on this nifty C64 upgrade.

The CMD SuperCPU, separating fact from fiction, Part IV

So, the third and final part of my random rambling about the CMD SuperCPU, and as promised, I'm going to quickly give an overview of the three best known Commodore C64 games that require this precious hardware upgrade. We'll start with the infamous Metal Dust, published by Protovision around 2005.

And now you are entering the Metal Dust

Metal Dust (MD) is probably best known as the only SCPU specific game for the Commodore platform. Except of course, that's not true, thanks in a large part to Mathias "AmiDog" Roslund (see below). It has nice presentation, and supports lots of CMD and higher capacity drives, which it had to. There was no way this would comfortably fit onto 5.25" floppy disks without being a worse multiload than Street Fighter II on cassette. The whole game is spread over four 1581 3.5" disks, two FD2000 disks, or one FD4000 disk, although all CMD floppy disks drives are 100% compatible with the 1581.

MD was the first time I saw a full screen FLI image without the ~16 pixel FLI bug. Beautiful 16 colour [static FLI] screens are presented whilst loading the game, and then between each level. It won't surprise you to know that the pastel shades of the VIC-II chip are quite pleasing in these images - the artist here did a good job.

After selecting your difficulty level, as well one or two players, you are soon greeted with the most difficult part of the whole proceedings if you are new to MD (and sometimes even if you are not), and that is getting through the first few screens worth of attack waves. Hint: if you can't shoot through it, it's not background and you should manoeuvre to avoid it. Fortunately, MD has a built in auto fire, so holding down the fire button and observing which part of your projectiles hit whatever is in front of you is the best way to learn this game.

I have poured hours into this MD, and could be the first person outside of Protovision to complete it, so I know it pretty well. The trick for a new comer is to listen to the title music for several minutes. If you do, two new difficult settings appear before you begin your game. "Boring" gives each player 99 lives per continue, and "Insane" has zero lives per continue. I recommend anyone to try it on Boring (it's not boring) as it gives you the best chance of learning each section and eventually each level. Don't be fooled though. It's not easier on "lower" difficulty levels, you are simply given more chances to complete each level.

Regarding how brutal this blast fest is, well that's open to interpretation. Despite what people say, MD is not impossible to complete. I emboldened the font there just in case anyone misunderstood. It's definitely tough, but honestly not the most difficult of shooters out there. Take Loins of the Universe for example. By comparison to Lions, MD is like a children's game.

Like a Boss!

With all of this extra processing power available on a SCPU system, does that mean bigger and better mid and end level bosses? I suppose that's down to interpretation again, but the ED-209 inspired mechanical beast on level two is particularly pleasing, but all are pretty epic. As you would expect the bosses have some good animation, and the whole game has a very stable sprite multiplexor. If there is any flicker anywhere, you won't notice it unless you have exceptionally keen vision.

Regarding each level, I always thought that they were ordered wrong, and have believed until recently that level two would have made a better introduction to the game than level one. I recently swapped the order of play around and my version now is two, one, three and four. I know now that I was wrong in my assumptions. Whilst learning the first level took a while, it's much easier to complete than the second.

The levels themselves are really quite something to see, and although there were some technical criticisms from some other developers of how things should have been, the road of a thousand miles starts with the first stone. And I haven't seen many other people rush to do things the "right" way. We may have a "Sonic" moment in the future when something is developed for the SCPU that makes it okay to develop for the SCPU (like it's now okay to develop for the REU), but that isn't likely to happen soon, which is a shame as clearly MD gives us but a glimpse into what is possible.

To reiterate, this game is not impossible to complete. It's just very tough. But is it worth playing, even for me who has completed it many times? I would say yes. Ultimately, it's fun to play and still presents a challenge for my aging reactions and fading memory.

Entering Castle Wolfenstein

Castle Wolfenstein first appeared on the C64 in 1983 thanks to Muse Software, although this was a 2D affair. After years of some people debating and deliberating on whether a Doom port would be possible for the C64 + SCPU (on places like comp.sys.cbm and others), AmiDog went ahead and ported Wolf 3D by id Software. It's really good too, especially if you use the "Apple II" colour palette option. Of course, the graphics still look like a C64, but the gameplay is fast and responsive (at around 10fps for 16 colours, and faster still with four colour display).

For those who don't know, the premise of the game is set during World War II. You assume the role of William "B.J." Blazkowicz for the Allies, and must escape from the dreaded Nazi prison Castle Wolfenstein, along the way picking up various weapons and rearmaments, and shooting Nazis and their trained four-legged familiars. I always feel sorry for the dogs and try to avoid them though, as daft as that sounds.

Whilst this game is pretty epic, and very playable, the same cannot be said for AmiDog's MIPs recompiled conversion of Doom. Although it's a great achievement, the playability and replay factor is quite low for some technical reasons.

At the very least, we can say that the SCPU passes the "does it play Doom?" test that applies to many devices these days. For all I know, there's a version of Doom that'll run on your washing machine. But this was really meant as a proof of concept more than anything to set the C64 gaming world alight. Yes, you can play it, but it's slower than many of the Freescape games are on an unexpanded C64, and there is no music nor sound effects. I'm sure that more gameplay could be achieved from this project, as there are likely to be further optimisations that can be applied to the source code, but I'm not in any way technical enough to comment further. There's nothing really more to say here.

For me, if you want a "Doom-alike" game, the best so far is Wolf 3D, and that's not likely to change soon.

Before I go, please consider the following resources:

Metal Dust available on itch.io.

Wolf 3D from csdb.dk.

Doom from csdb.dk.

I think I've covered everything that I wanted to about the CMD SuperCPU, but if you have any questions then please don't forget to add your comments. Many thanks for reading, and apologies for any spelling mistakes, typos, or general lack of any good grammar throughout these blog posts.

The CMD SuperCPU, separating fact from fiction, Part III

I think there'll be two more parts to this trilogy of blog posts regarding the SuperCPU for the Commodore C64 and C128, and this is one of them. If you have read my other posts, you will know that I hold this piece of kit in high esteem, but more on that at another time. Firstly, let's consider some other fictitious accounts that have seeped into the wider consciousness and have became broadly known as factually accurate. And we'll start with the Maurice Randall debacle.

Before I begin here, I am going to point out that I have no vested interests in defending Maurice. I am however interested in the truth. I found him to be very personable when I spoke to him on the telephone, and he was obviously very knowledgeable. He took the time to help out where he could when I had questions or other issues with not just my CMD hardware, but my C64 too. Yes, he did kind of just disappear with who knows how many thousands of dollars worth of orders, some people already waiting many months or years before he vanished like an old Oak table. A few may have sadly passed away whilst waiting for an order, and will certainly have done so by now, and without compensation. But it is not true that he delivered nothing. I have a CMD JAZ HD drive, and had a copy of Wheels 128, and some spare SCPU parts from him, and I wasn't the only person to receive at least partial or full order from Maurice. Therefore, it's a matter of plain English that any quantity of orders that Maurice shipped, even if it was just the items to me, is still greater than zero. So whilst I gave up a long (long) time ago of ever seeing the item of mine that he had, it seems to me that the people who get most vexed about the whole Maurice situation are those who didn't actually order anything from him in the first place, and therefore didn't personally lose out.

What I suspect happened is that whilst the orders weren't enough to sustain Creative Micro Designs, inc. in 2001 when it moved to the PC market, it was too much for one man to handle by himself. As well as the GEOS software that he was developing and supporting, and the CMD HD firmware upgrade that he was working on, he had his own business to run. He very likely became overwhelmed (and quite quickly), and at some point around 2004 or 2005 he reported that his workshop that housed his CMD stock was flooded. This is pure conjecture from me here, but if he didn't have suitable insurance, or the insurance company didn't pay out, this would have been pretty cataclysmic. Now I'm not saying that I believe that his Commodore workshop was flooded, but something definitely happened that put him in a situation that he just couldn't do it anymore. He stopped answering the phone, and responding to people's mails. This was indeed a sad event for all involved. Again, I am not here to defend Maurice, but I don't believe that he was a villain, or that he deliberately set out to defraud people by selling C64 and C128 hardware. Anyway, time has passed, and time also heals, so we move on.

There's something else that's factually incorrect about the SCPU that I want to adumbrate, but let's talk about what it's like being a SCPU user first. As I've owned both the SCPU 64 and 128, and owned a SCPU from the late 1990s, I know that the best version to use is definitely the SCPU 128 even if you own a C64. This is because the chips are beefier and better handle timing differences between PAL and NTSC machines, as well as discrepancies between the various models themselves. And by the time CMD launched the 128 model, it had worked out all of the bugs and issues prevalent in the earlier versions of the SCPU. But there are two issues that won't easily go away. One is power, and the other is heat.

Regarding the power issue, a flat C128 or any version of the C128-D usually has a sufficient power supply to run the SCPU and even SCPU with an REU if your PSU is good. But the C64, well aside from the original PSUs being known as "Bricks of death" now, even good ones don't work well over a few hours (sometimes less). So the power issue is the most pressing; you will need a heavy duty power supply to use this upgrade, and especially so on the C64.

It is sometimes pointed out that CMD did not make a heavy duty PSU for the C64. This is not actually true. CMD did not ship a heavy duty PSU with the SCPU as standard, that bit it true enough, unless you purchased one with your order of course. But the CMD Heavy Duty power supplies (which had both C64 and C128 versions) only worked with 120V outlets, and this wasn't much use to users in Europe as the common voltage here is 230v. Now today that might seem a little strange, but back in the late 1990s and early 2000s, having multi-region power supplies that could accept 120v or 230v wasn't really that common. Although it didn't feel like it at the time, they were simpler times back then.

So the heavy duty power supply problem was a European one (unless you have a C128, but of course most people did not have), and whilst Commodore Scene and Protovision offered their own PSU solutions, these were made to order and prohibitively expensive. The Commodore Scene PSU could power all of your computers and drives though, as well as IDE drives if you happened to own an IDE64 cartridge. Who knows, maybe if more people in Europe had been purchasing CMD hardware, CMD may have made a 230v PSU. But that clearly wasn't the case.

The heat issue may also cause some unpredictable behaviour, and over time residue will build up on the contacts of the edge connector to the computer. I've found that cleaning this with 70% alcohol solution every so often does help. And whilst you may take the lid off the SCPU whilst running it (so that the RAM does not run too hot), I now superstitiously always wear an anti-static wristband if I do. The best solution is of course to to heatsink the chips and have your whole computer system running in a well aired and cool environment. Anyway, hopefully any future compatible SCPU-like device will not suffer from this flaw, or the power issue mentioned above.

In my final blog post [about the SCPU], I'll briefly summarise three of the most likely best known software for the SCPU platform: Protovision's Metal Dust (which I once reviewed for a magazine called Retro Gamer), and AmiDog's MIPs recompiled versions of Wolf 3d and Doom. Until then.

The CMD SuperCPU, separating fact from fiction, Part II

Although my first post on this subject is not yet even a few days old at the time of writing, it seems like I kind of drifted from my original point a little and missed out a few things that I should mention in passing. Hopefully, this will fill in some blanks. And for that, I may as well start at the beginning, and here's what I know.

Around the mid to late 1990s, I was in regular contact with a Croydon-based guy named Russ Michaels, who was the sole proprietor of a new Commodore C64 start up called Electric Boys Entertainment Software. Russ was quite patient and put up with my C64 obsession quite well really. I stayed at his place a couple of times and that was the first time that I saw the mythical Flash8. Russ had set this hardware expansion up to quickly and reliably copy disks for his Public Domain library and his commercial software. And he had developed a Red Dwarf inspired demo for it too. With Future Publishing's Commodore Format magazine still plodding along through 1994 and I think until around 1997 (someone will correct me on that), he naturally assumed that there'd be enough interest in new C64 software to make a living from producing and publishing it, and maybe he'd also be able to develop his own games for his Electric Boys label.

Russ spoke of a Flashback port and a Defender clone (I think called Defensive). His Scene handle was Ironfist and he was interested in and very impressed by what the demo scene was pumping out. I'm not sure what his big plan was, but he was the official importer for Creative Micro Designs (CMD) Inc. to the UK (which if you don't know by now made the best C64 upgrades and hardware, unsurpassed until quite recently really). I imagine that in his head he thought that the fast CMD FD drives coupled with JiffyDOS would allow for bigger and better games with no disk swapping or waiting around for cassette multiload (even then the datasette was still the medium of choice in the UK). And because of the storage capacity even at the lowest end (~790K per disk), that would be enough to have some great demo-scene like cut scenes and then quickly into the action.

Anyway, Russ and I loved the potential of the Flash8, and around 1995 or early 1996, I think shortly after CMD launched its magazine Commodore World, he sent over (or arranged for CMD to receive) a Flash8 unit. For those of you who don't know, this device is an 8Mhz upgrade for the C64 that plugged into the expansion port on the C64 or C128 (in C64 mode), and it was powered by a WDC 65c816s CPU. It came with up to 1MB of RAM and I think there was a 256K RAM version too. If this is sounding familiar, then I think you may already know where this is going.

The problem with the Flash8 was compatibility and some general bugs that would cause unpredictable crashes. When it did work, it was great. And obviously copying from the 1MB RAM (essentially disk images) to real magnetic media was fast, efficient and reliable (as I saw for myself). The Flash8 worked with geoPaint - or at least there was a hacked/fixed version of geoPaint that you could use; with geoPaint being a GEOS package, and CMD being the official distributor of GEOS, this sparked some interest. From there, the guys at CMD had a base to work from, and to iron out the bugs and compatibility issues [of the Flash8], and maybe even to make an accelerator of their own, being fully GEOS compatible and integrating with all other CMD devices. Well, that's what happened. You'll note that early versions of the SuperCPU were to be 10 or 20Mhz, but the price difference is unlikely to have been enough of a draw for CMD's loyal customer base to the slower unit. And afterall, why would you want a 10Mhz upgrade when the same hardware was offered at twice that speed but not twice the price?

So how good is the compatibility of the SCPU then? Well in a sense, it's very close to 100% compatible, as even with the computer switched on you can switch out the whole unit as required. Simply and gently depress the reset button on the SCPU whilst holding down the CTRL key on the C64 or C128 keyboard, and switch off the unit on the top of the SCPU, let the reset button go and you're back to your stock C64 or C128 without having to turn off the computer and remove the hardware at all. I've never known this to cause any issues with any software, but also I haven't yet tried every single release on both the C64 and C128 to confirm this for sure (has anybody?) - but even with the unit enabled, the two other switches enable and disable JiffyDOS (again, I've never known a single program to fail or crash with JiffyDOS enabled), and to switch in real time between 1Mhz and 20Mhz (or 2Mhz and 20Mhz if you're in fast mode on the C128).

On the difference between SCPU 1Mhz and C64 1Mhz, there is not difference that I can tell for most of my Commodore uses. When at 1Mhz, the SCPU is synchronised with the C64. The one thing that it won't do is undocumented op codes of the 6510, and this is just how the 65816 CPU works. Whilst in "6502" mode (or more accurately, 65c02 mode), it accepts all documented instructions of the 6510. So there will be some games and demos that will hang or crash because the 65816 doesn't know what to do with the instructions that would otherwise work on a C64 or C128 when using undocumented features. But as you can just switch the unit out easily, it's not a big issue, at least after you know something doesn't work with the SCPU enabled.

Finally, those games and other programs that do work at 20Mhz. Some of them are really responsive and fast. Sometimes too fast. Sometimes about right. But just because you have a piece of entertainment software running at 20Mhz doesn't always mean that it will play any different than it does at 1Mhz. In this case, it is to do with how the game is coded and timed, which isn't a topic I'm currently too clear on. I'm sure that there'll be C64 coders out there who will know why this is.

For now, I'll leave it there. But just before I go, you may be interested to know that @dsp8bit has been mulling over a SCPU compatible accelerator, as you can see here. That's one of my old spare SCPUs that I kept for parts. Well I figured that it was no good to me if everything failed, and so at the same price I paid for this spare (not the crazy price that someone might pay for it), I sold it and sent it over to North America to hopefully help bring about a modern days SCPU alike device for the masses. Unfortunately, this labour of love has been slightly stalled, but I've heard that developments will be restarting in the (Northern Hemisphere) Spring. So whilst Russ played a small part in making the original SCPU a reality, I hope to play a small part in making a compatible (though not a 1:1 clone) and new SCPU like device a reality too, and soon. And I'm as excited to see what may be as I was when I first heard about this mythical Flash8 device!