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.

Return to “Conquests”