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.