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.

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!

The CMD SuperCPU, separating fact from fiction, Part I

The SuperCPU (SCPU) device is a hardware expansion which plugs into the back of a Commodore C64 or C128 (or will plug into the top of a C64 GS if you can find cartridge games to work with it). It has a WDC 65c816s CPU (similar to the CPU found in Nintendo's Super Nintendo Entertainment System) which is clocked at the breakneck speed (for the C64/128 platform) of 20Mhz. It has 128K as standard (I think on both the C64 and C128 models, and both the V1 and V2 units) and allows you to add up to 16MB of RAM that can be seen by the CPU in the cartridge expansion. It was first launched by Creative Micro Designs Inc. (CMD), and there are two different sources for a release date. One states Sunday, 4th May 1997, and the other states Saturday, 4th May 1996. I suspect the 1997 date is correct (when I was exactly 20 years old), but either way, new C64 machines had not been manufactured since 1993 and in many regions it was a dead platform.

Consider that the "World Wide Web" was in its infancy, and networked computers and devices where not as common in the home or workplace, so whilst there was an Internet with web pages that one could browse (and at the time, I did my best to do this with my 1200 baud C64 modem), there wasn't a significant Internet community keeping the C64 alive. Most information back then was still spread by magazines and fanzines, and hearsay. In the UK, dial up Internet connectivity was still a luxury, and the cost of dial up Internet was still something that many households would not justify. Either way, launching such a piece of hardware in the mid to late 1990s was a bold move by CMD. And it could do so because CMD hardware was awesome, and kept the C64 or C128 a very usable platform, hence the end user had no immediate reason to "upgrade" to "better" computers, especially I would say those users who had heavily invested their time and efforts into the fabulous GEOS operating system (which CMD supported avidly, and held the rights to distribute). And even now, the RAMLink is one of the best mass storage drives for the C64 or C128, and that was launched in 1990. Maybe I'll tell you more about the RAMLink in another post, as this is another piece of CMD hardware that isn't well understood.

My take on all of this is that CMD had a very loyal customer base because it kept the best computer platform of the 20th century very much alive. Most of the protagonists against CMD seemed to create a myth that it was not okay to upgrade the C64, and that all software must be compliant with the 1982 specification of the machine. Whilst this view is still prevalent today, there are always caveats to it, like "yeah but Sonic is allowed because [insert arbitrary reason]" or "Sam's Journey uses the REU for NTSC and that's okay because [some other arbitrary reason]". The point is that most personal or home computers worth owning (and even those not worth owning) had upgrades available. I mean, we don't religiously stick to the 1981 specification of the IBM PC, or the 1977 specification of the Apple ][, so why is the C64 different? Upgrades and addons tended to give a better user experience, that's why cartridges like the Action Replay from Datel Electronics, or the Super SnapShot by LMS Technologies were popular and remain popular today, especially given the slow drive access of the 1541 and the clunky way you performed disk drive commands in C64 BASIC. In my view, CMD made the very best and most compatible addons, expansions and upgrades for the C64 and C128. It was a sad day when it left the C64 market for pastures new.

You will note here that I've mentioned the C128. That's because CMD's hardware wasn't just C64 compatible, but worked with the C128 as well, not just in C64 mode either, but in its native modes (except for maybe the Z80 and CP/M, but I know nothing about this dark side of the C128 anyway, and it is perhaps the least used feature of the platform). So, if you think that the SCPU is only a C64 upgrade, you'll be wrong. There are two versions of it for the two machines, although the SCPU 128 does require an MMU Adapter which you carefully remove the MMU chip and place it into a new piece of electronics which allows the SCPU 128 to use the 40 and 80 columns mode natively. So if nothing else, any BASIC 7 programs will run faster, and your 80 columns screen will update more quickly. Although it's likely that your primary use would be GEOS or something like NovaTerm V2, or programming, as we know that the number of entertainment software titles available for the C128 is rather sparse though not completely unheard of.

As the SCPU supports both the C64 and C128 platform, the VICE emulation is only about half of the device, and I'm sure that the real hardware can do more tricks than the emulator does. So whilst the emulator is very cool, I don't think we'll see a full SCPU emulator anytime soon, and perhaps never. Firstly, the C64 scene doesn't really care about the SCPU. Secondly, it's a C64 scene, and the C128 is kind of like a forgotten relative that you don't see very often. And thirdly, I'm pretty sure that VICE is only emulating the SCPU V2 and not the V1. Okay, that latter point may be minor, but overall if you want to see everything that a SCPU can do, you'll need a C128 with MMU adapter and a SCPU 128. Then you'll have potentially at least everything that you'll need. But even with this, SCPU software is so sparse that I don't think we will see every trick that may be achieved with this hardware.

In any case, a short time ago, because of misinformation (or a common myth) that there are only three programs written for the SCPU, or only three programs worth loading, I started to create a list of all SuperCPU software that I could find. I began with CSDb.dk which currently shows 80 releases; many of these releases use the SuperRAM in place of the slower disk access (even with a fast loader, using the SuperRAM will be much quicker than the best 1541 speeds), so these releases may be enjoyed on an unexpanded system, just not these versions. I then started to look for the old sites I would pour over back in the late 1990s and early 2000s (those that I can still find at least). So far, I have 81 releases marked as "Games" (some of which actually for the C128 and even for 80 columns VDC display), 14 marked as "Demos" (no C128 stuff here), four GEOS releases (though I've not yet even scratched the surface), six under "Programming" and 44 other releases or software (including four "In Progress" and seven under the category "Cancelled or unknown"). In any case, there are definitely more than three programs for the SCPU. And of course, there are many different programs that benefit at 20Mhz. This latter category will take much longer to research and document, but I've at least made a start. You may view my research so far on on my Google Drive.

Aside from all of this software that is available, and that list is not just Metal Dust, Wolf 3D, and Doom, there is the question of how many SCPU devices were made by CMD. The total number by Maurice Randall would be easier to count, as this I suspect will be fewer than a couple of dozen. The highest serial number I've seen on CMD SCPUs for the 64 model is somewhere above 5k, and for the 128 model its around the 2700 mark. Now this may seem high, but it makes sense. CMD supported the Commodore platform until 2001. It could not have survived without selling its hardware in particular, as its software sales would not have sustained the company for so long. Its only a shame that more C64 users around that time who knew about CMD didn't support the company more, but then the hardware wasn't cheap. Cheaper than a new PC which be now would be completely obsolete and useless (unlike a C64 or C128 with a SCPU and RAMLink I might add, as although obsolete the very least new software is still being developed for the C64 and occasionally the C128).

Whilst you are reading this, I assume that you're also interested in the SCPU. If you are on Facebook, there is a group that was set up to discuss SCPU coding but is now widened its remit to include software as well. You may ask to join it here.