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.