User avatar
Seattle, WA, USA

Posted Tue Dec 05, 2023 10:19 am

So, yeah. I need to start off saying what everyone usually says: I never thought I would ever have one of these. And there are lots of caveats, but as a result I feel like I now know the hardware - at least on paper - so much better than I used to.

Introducing, the SuperCPU 64 v1 (SCPU):
SuperCPU 64 v1, with original user's manual and JiffyDOS manual, and copy of the Utilities Disk. The original disk came in the package, too, but had been damaged beyond use years ago. The previous owner didn't have the heart to throw it away. So, he scanned the label, made his own, and slapped it on a new disk copy he made from a d64 off the internet.

The SuperCPU takes a 1Mhz Commodore computer and accelerates it by 20x. Some literature claims 22x (or 22Mhz) depending on the process. It won't work with most games, but that's not what these were made for. These were to turn our already awesome Commodore computers into serious productivity machines.

You've probably noticed how I keep appending "v1" to my new device's name. As I understand it, the release-history goes something like this.

First, there were some very early white-cased prototypes we often see in early CMD promotional articles and pre-order advertisements. I'm not sure if it even had a v# at that point (v0?) but there was at least one of those, maybe a handful. I also don't know the DOS version these early models used.

They looked like this:
Pre-retail versions of the SCPU existed at some stage. CMD accepted $50 deposits to lock-in projected prices of $199 for the 64 version, and $299 for the 128 version.

There were also some strange units in the earliest days with wooden cases - presumably before there was an official metal case ready for production but the internals were solid.

At the beginning, my understanding is CMD offered two units:
  • SuperCPU 64 (v1) for $199
  • SuperCPU 128 (v1) for $299

Both of these units came equipped with SuperCPU DOS 1.32 from 1996.

I've read reports that some of the earliest models had some bugs. What those were, and when they showed up, I don't know. I've not yet used my device to the fullest as I've only just received it.

The 128 version, in order to work in 128 mode, required the addition of a small daughter-card that was installed in the U7 socket on the C128's motherboard. The chip that is normally in that socket is removed and placed back into the daughtercard. Then 5 clip wires lead to various points on the 8502 (U6) chip.

If a C128 lacked the MMU upgrade, the SCPU128 would still work as a complete SCPU64 model. In this scenario, when plugged in and enabled it would automatically boot a C128 into 64 mode - at 22Mhz.

Later, the DOS for the SCPU was upgraded to version 2.04 (suspiciously the same version number as the stable v2 for Amiga OS, but that was probably pure coincidence).

This DOS chip update is important, because this change allowed SCPUs to then use an internal RAM card that could be populated with 16 MB of "SuperRAM". Some programs could take advantage of this RAM and launch Commodore computer performance to even greater heights.

Thus, in a relatively short amount of time CMD was shipping v2 models with the new DOS chips.

My understanding is a lot of the chips in CMD hardware were encrypted, and as a result no one has ever been able to reverse engineer them. That holds true for most CMD hardware in general. There's a very interesting post by Jim Brain from 2020 where he lists out the history of the CMD IP, and the state of the hardware ownership.

The code and plans of CMD hardware resides on some old period-correct PCs, and those PCs - if they still exist - are very likely never to be retrieved. Their secrets are essentially locked into a permanent tomb.

Jim Brain:
* Yes, I have (and continue to) tried to buy out [Maurice Randall]’s remaining product stock (even just buy the unmade stock, PCs used to create the units, etc.). I inquired on getting some help with some equations in December 2019 (Ray Carlsen asked me to help, since he gets units to repair, but no PLD files to assist), but I have not been able to convince MR to chat on the topic.
* MR does not “own” the licensing/IP. He was supposed to pay licensing to Mark Fellows, which he did for a while, but then got behind and stopped.
* He *DOES* own the PCs used to write the CPLDs, raw materials, stuff like that.
* He also owns copies of the schematics and such. Again, he does not own the IP, but he has the copies in his possession.
* Mark has truly moved on. I’m sure you could find him, but I keep trying to get the files from him as well. The masters are in his parent’s attic, and he’s just not motivated enough to go dig through them to get me the details. Don’t be too harsh on him. Try to remember something you did (or some code you wrote) 30+ years ago and see what you’d think if someone called and asked for copies of the source (or help)
* Doug Cotton is not associated with this anymore. Last I remember, he works at a library. Don’t call him for sure
* I think there was a Christianson Sr. and Jr. who were part of CMD (I forget their first names). Again, they’d be no help. When CMD got out of the CBM business, all copyrights and IP was re-assigned (or reverted) to Mark.
* If the situation presented itself, my business has made enough money to fund the purchase, no crowdfunding required. And, given how the last financial transaction ended, I would HIGHLY discourage such a thing. When MR bought the rights to produce, he borrowed from lots of CBM enthusiasts, none of whom ever saw that money again. If *I* was involved in buying the rights, my plan would be to self fund, make up enough units of the original designs (or as close as possible) as ’legacy” or “continuation” units, like they do today for cars, sell those to helpfully pay the tab on the funding (or get close), and then try to upload as much of the material as I can get, so at least it will be available for research (you’d still need to license parts of it, like the DOS and some of the Verilog/ABEL) if you wanted to reproduce, but having the designs online would make repairs easier and smart folks can always work around some of the more egregious concerns (the PCB artwork is copyrighted, but the schematic cannot be, and not all ABEL/Verilog/VHDL is novel enough to get copyright protection)
Ever so slowly, I make progress reverse engineering these things (reverse engineering itself is a learned art), and I always welcome help, but I really doubt the original plans will materialize. I *do* have tentative permission to reproduce the units from Mark if I can get such a thing to fruition, so the legal issues are not my main stumbling block.
Hope that helps clear things up.

God speed, Jim.

So I have a SuperCPU64. It took me a while to even understand how to plug it in while also using a RAMLink. This was problematic for me because I wanted to use the SCPU - at first - with my C128D even though it would force 64-mode, when enabled. If you disable the SCPU with the flick of a switch, the D boots up normally as you'd expect.

The problem was the SCPU collided with the D's case when I put the device in the RAMLink's expansion port. Then someone suggested I put the SCPU first in the chain.

Like this:
You need a REALLY deep desk for all of this to fit! My keyboard rides right on the edge of the table now. But it fits!

Before I got this, when I booted my machine the JiffyDOS in my RAMLink would be front and center. Now, the SCPU's DOS and JiffyDOS take over. I can still access the RAMLink normally, but its JD chip is now redundant when the SCPU is enabled. Of course, I can disable the JD chips on both devices very easily should the need ever arise.

When the machine boots up, I am first presented with a black screen and a rocket ship that animates under a SuperCPU logo - very cute. Then the screen flashes to the blue BASIC screen where DOS 1.32 is across the top rather than the normal Commodore message.
What does all of this mean?
It means a lot of what the SCPU was created to do will work just fine on my machine. The lack of RAM/MMU is really the only difference, and most software that can use the SCPU was never tasked to take advantage of the RAM option.

To that end, the RAM situation on Commodore computers is really kind of ridiculous. It has at least 4 different and totally incompatible types of RAM: 17xx-REU, GEORAM, RAMLink DACC partition, and SuperRAM.

I contacted Gregorio Naçu of C64OS fame and asked if my hardware would work well with his OS. I've seen it booted on a C64 equipped with a SCPU128 in 64 mode before and was shocked at how fast it was.

Naçu replied:
You’ve got lots of great hardware. The best combination would be SCPU for CPU speed, plus RAMLink as the main system drive for storage speed, plus an REU in the pass through port of the RL for use as RAM under C64 OS, and then stick a parallel cable between the RL and the CMD HD for mass storage, though slower than the RL itself still much faster than the IEC bus alone, and much more capacity for media and stuff than the RL.
He made a very good point about the IEC. While the CPU is greatly accelerated, the data transfers across the Commodore serial IEC lines can only ever go 1Mhz fast. This is why the RAMlink part of the puzzle is so important, because it doesn't depend on the IEC bus.

My plan is to make a new mega-C64OS battle station in early 2024 to push it to the max. (GEOS battle station; previous CMD battle station)
But Naçu made another good point about the REU. While his OS can take advantage of the SCPU's speeds, he never bothered supporting SuperRAM. But he does support 17xx REUs. And while I had a .5MB Commodore REU, I knew there was one step further I could go...

So I took it.
2MB of 1996 RAM provided by, once again, CMD.

This is a bit of a holy grail item in and of itself - like all CMD products. Even though I have a 2MB DACC set up on my RAMLink, C64OS won't see it. But it'll see this 2MB of REU RAM! So now the machine will be 22Mhz, with 2MB REU and 10 of the 16MB for OS storage on the RAMLink. And for "mass storage" options I'll either add the HD, which has a ridiculous 2GB of space, or my FD-2000 (or both). It's INSANE!

So, I figured I was done with all of this. Time to play.

But then... I'm frolicking along a small C128 closed group and someone nonchalantly mentions on one of my posts that years ago they acquired a C128D that had an MMU left inside the case. Apparently it's SCPU was either sold off or thrown away at some point and its MMU was left behind.

In the hopes that some day before I leave this earth I might have a SCPU 128 opportunity in front of me - and that it might lack the impossible to produce or find MMU - I made a fair offer on it. And he immediately accepted.

So now I've got one of these, too, even though I can't use it with my device. I look at it as an insurance policy for a future that might never present itself, but I'm OK with that.
What a crazy design! Photos by Charles Hawn.

Incidentally, Thomas over at Corei64 makes a replacement PCB for the C128 MMU Link for these precious chips that eliminates the janky as F clip lead wires. What a massive improvement! I've not invested in that because I've no real immediate need. But maybe later if I ever catch wind of a SCPU128 I'll go for it.
Photo by Thomas Christoph © Corei64

In any case, now I'm looking at this CMD collection:
  • SCPU64 v1
  • RAMLink with 16MB brand new SIMMs
  • 2MB CMD 1750XL
  • CMD HD w/2GB
  • CMD FD-2000
I'm done. Unless, of course, I ever find a 128 model. :commodore:

User avatar
Seattle, WA, USA

Posted Tue Dec 05, 2023 11:57 pm

Since posting, I've discovered Bo Zimmerman put this on his site back in 2015:
Screenshot 2023-12-05 at 10.57.50 PM.jpg
Could upgrading a v1 to a V2 be as simple as updating the SCPU DOS chip??

User avatar
Seattle, WA, USA

Posted Wed Dec 06, 2023 12:03 am

I have an early SCPU64, version 1C. It required a drop-in replacement of the CPLD to enable it to use the RAMCard.
Oof, well that seems to kill that idea.

So what all of this means is I think I could upgrade my SuperCPU DOS chip, but the CPLD - since it has never been Reverse Engineered - is what it is. Might be worth updating the DOS, though, if it eliminates some early-days bugs.

User avatar

Posted Thu Dec 07, 2023 7:37 pm

A while ago, someone was selling CMD clone floppy and hard drives on eBay (commander kang was his eBay username). He claimed to have reverse engineered both of those from scratch. I can’t remember his real name, but had read elsewhere he’s a sketchy character. I had asked him on eBay a long time ago if he had thought on doing a superCPU or Ramlink clone, and he said yea, but it would cost him over $20K in development costs so he had no plans to incur that expense and go forward.

Nevertheless, I wonder how he got the PLDs, etc for the drives he produced if CMD encrypted all of them.

User avatar
Seattle, WA, USA

Posted Thu Dec 07, 2023 7:47 pm

I've done a little hunting. Commander Kang (aka Admiral Decker) was supposedly a guy named Jeffrey Jarian.

Over on Lemon, back in 2017:
I hung around with Jeffery Jarian back in the mid to late 1980's. Always thought it was kind strange that every once in awhile when I'd stop over his parents place he'd be dressed in a Star Trek uniform and wanted to be called Admiral Decker.

Only reason I came on here was to try and find out some info on this Thunderdrive sold on ebay. Sure enough up pops Jeffery Jarian, Admiral Decker and now Commander Kang.

Any who, back in the day he worked at a rather high end TV sales and service shop that I went to a few times to help him trouble shoot and repair some TV's.

From what I remember about him I doubt this Thunderdrive is reverse engineered but most likely a hack of someone else's work.

Not to say I wouldn't mind looking at one up close and personal, but I'm not going to give him $360.00 to find out..
Hey there C64 folks. I recently, as in this month, and most recently this week have had a heck of a time with Jeffery Jarian aka AdmiralDecker. He sent me this huge email about some ebay items I sold, with threats to me, etc. And threats to my buyers personal emails (he somehow tricked ebay to give that info out - another issue all together) He claimed I sold stolen goods and I was demanded by him to get them back, say sorry to him, and send them to an undisclosed location by Today - - or else. I bought the items straight out from a C64 users son, the user passed away.

originally the story from the son was, there is this guy in MN who said wanted to BUY items, so he gave him my number. Then the story changed, and Jeff called me, said thats mine, you need to put in a box and send. I blew em off. Well, I guess he cyberstalked me, the last couple weeks, and threatened me, mentioned my wife, my daughter, my work etc. Also mentioned all these companies that he is with/associated with - and their legal teams are gonna get me. Needless to say - - I did nothing wrong, and I opened a Sheriff Case against him out here in California where I live. I feel he wanted items, came up with an outlandish story, made threats to unknowing ebay C64 collector/buyers and is trying to shake me down, and my other buyers (completly wrong on many levels) If he was to truly file something, he MUST APPEAR - therefore for all you folks out there with Jefferey JArian, AdmiralDecker etc issues
Anyway, it's unbelievable how much drama surrounds some of this stuff.

User avatar
Seattle, WA, USA

Posted Fri Feb 09, 2024 4:40 pm

I picked up a few more CMD pieces this month. Notning heavy duty, just some cool little things to test out this year with GEOS and other CMD hardware.

First up is the CMD GeoCable II, which is a userport parallel printer cable adapter and passthrough. This doohickey allows you to attach standard printers equipped with a Centronics parallel port directly to a Commodore 64 or 128 User Port.

Screenshot 2024-02-09 at 3.02.04 PM.jpg
Features in graphical form, for the lazy typist. ;)

Software packages that support this device include all versions of GEOS (by replacing the built-in drivers), Superbase, Superscript and Paperclip. Apparently the Action-Replay MK VI cartridge has the ability to "make many C-64 programs output through geoCable II."

Next up is the 6-disk set of Perfect Print LQ (which also works with the geoCable II).

This set of disks includes the print system, printer drivers, HQ/LQ fonts and font editor (!), and 4 double-sided disks of LQ (letter quality) fonts. This package brought high-quality fonts to GEOS back in 1991.

Screenshot 2024-02-09 at 3.17.41 PM.jpg
The word that was cut off at the end was "Gasp!"

Perfect Print theoretically solves this problem. It consists of the GEOS LQ Print System for geoWrite, and a collection of HQ interpolation drivers for other applications. The interpolation routines deliver substantially improved print quality. The entire package was originally developed in Germany and in German, and the author then translated everything to English as well. Pretty cool!

Lastly (for now, I think?) Wheels 64.


This should be fun to "take for a spin" with my SuperCPU and RAMLink. This is the enhancement package by Maurice Randall that goes on top of GEOS (like Gateway does) and turns things up another notch - especially if you have CMD hardware. It brings full support to the SCPU and, unlike previous versions and incarnations of GEOS, Wheels actually requires extra RAM in order to be run.

User avatar

Posted Tue Feb 13, 2024 10:10 am

Great find and great article!!

Always wanted to get the Wheels going but never had a SuperCPU or RamLINK!! Be sure to keep us in the loop on the update.

User avatar

Posted Fri Jun 14, 2024 10:06 pm

Great article! Just found it and read it. I was a self-styled C64c / C128D "power user" from 1988 thru 1999 at which point a career change followed by a physical relocation forced me to abandon all that and switch to using Linux as my primary desktop OS for the past 25 years. Finally, this year, I'm trying to get my old Commdores back in action... Some of it has deteriorated in various ways while sitting in climate-controlled storage all this time. Other parts still work well.

I was a CMD fanatic in the 1990s. I bought a SuperCPU v1 when it was new. I bought a RAMLink and fitted it with the full 16MB of RAM. I connected them both to the back of my C128D and managed to find a "deep desk" that accommodated them well - although it was always a pain having to reach that far back behind the machine to flip the switches, press the buttons, and see the lights... not to mention the difficulties of changing out cartridges. Other than that it was an amazing setup. As you said, it's for productivity, not for gaming. I remember with the SuperCPU switched on, all 3 of your lives in Pac-Man were lost before you even had time to move the joystick! Where's the fun in that? :lol:

All of my computers and drives had JiffyDOS chips even if they were redundant. I actually disliked using Commodores without it - and I'm still that way. I bought a SID Symphony Stereo Cart. I bought a 1750XL REU. I bought an FD-2000 High-Density Floppy Drive. I bought an HD-100 hard drive. I bought the parallel cable for connecting the RAMLink with the hard drive. I wrote a custom menu program that was configured to autoboot from the RAMLink as soon as I flipped the power switch. With that menu, the RAMLink and the SuperCPU combined, I'd be up-and-running in not just GEOS - but Wheels - from a cold boot in under 5 seconds. GEOS and Wheels are *amazing* with that combo! "Insane" indeed! PC users today rave about booting from an SSD - like that's some kind of neat, new trick! :lol:

The neat thing is - I still have all of this hardware. It's my original Commodore hardware that's needing to be repaired or replaced before I can begin using them again like I used to. I started working towards that goal today when I found 3 hours remaining on an eBay auction for another 16MB-equipped RAMLink still in like new condition. Now, when it arrives, I'll have 2 for the first time in my life. Right now, there's also a SuperCPU64 v2 with 16MB RAM up for auction but it's already over $3,000. I love my "v1" but not so much I'm willing to pay that price for another.

Anyway, it was great to read about your journey of discovery with all of these devices. It's not often I find anyone else going down the same path I took 25-30 years ago. CMD truly did make Commodore computing an unbelievably incredible experience back in the day.

I also have every issue of their Commodore World magazine still in storage. I'm pretty sure it's a complete set anyway. I subscribed to that one from the very beginning. I even used some of their articles to learn my earliest basics with HTML using my Commodore to build my first web pages in 1996 - without even a graphical browser to view them! I've been a LAMP Stack web developer - professionally - since Spring/Summer 2000. All thanks to CMD and Commodore World for helping me start down that amazing road.

Nearly every photo in your article is of something I bought then and still own today... including the geoCable II and the set of 6 Perfect Print LQ disks. That's what fascinated me the most. Everything in this article - except for the SuperCPU128 information - looks exactly like what my daily life as a ComMoDore user was in the mid/late-1990s. All my Microsofty friends who'd stopped using Commodores in the '80s couldn't understand what was keeping me onboard. Those were good times and great days!

I look forward to one day returning to programming my Commodores. I was always a C64 programmer first and foremost. Only occasionally would I use them to play games. Writing software which used Direct Disk Access commands or ran only on JiffyDOS-equipped systems became my specialty which I wholeheartedly - and apparently uniquely - embraced.

User avatar
Seattle, WA, USA

Posted Sun Jun 23, 2024 10:47 am

Last week at my Commodore Club meet a local friend (dddaaannn) helped show me how to update my copy of C64OS by Gregory Nacu, which I believe I purchased 2 years ago, to the most recent version 1.06 which was released a few months ago. I was on the beta testing team prior to that. But I hadn't been keeping track of all of the updates since.

The fastest and easiest way to use C64OS is with a SD2IEC device, as the purchased OS comes on an SD card and is prepped and ready to go. It can also be installed to IDE64, CMD HD or RAMLink. I plan on duplicating my installation to a partition on my CMD HD later.

With the SD2IEC it's a surprisingly easy process for the most part. To add the updates you need to pop the card into your modern computer and download the various files dropping them right into the root of the card. Then you can move that card back over to the SD2IEC and run the installer files right from within C64OS after you've installed the OS from the first original file. When you're in the Files Manager, you can simply double-click the update files (in order) and they will launch an Installer window. VERY COOL.
Updates 2, 3, 5 and 6 are very easy and painless. Only update #4 requires looking at the instructions on Nacu's website and following along. In fact, this update caused an issue that required we look at the C64OS private Discord server, where we soon discovered others had the problem. The solution was in the same thread and we were soon back on track and finished all of the updates.

Incidentally, for the first update I ran it on a barebones stock C64 and it took a really. Long. Time.

For update two and all subsequent updates I popped on the 20Mhz SCPU and oh my god what a difference. Some of the updates were done in just a few seconds. Had I not had the SCPU on-hand we very realistically would not have had the time get through all 6 files.

With C64OS fully up to date I decided to perform a quick test to see how long it took to boot from the moment I pressed the Return key after typing "RUN".

On a stock C64 with a SD2IEC it takes 2 minutes and 1 second to boot.
With the SCPU64 and SD2IEC it takes 20 seconds. :bruce:

Music: Cover tune of Pink Floyd's "Money" by The Flaming Lips

Return to “Conquests”