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.
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.
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.
TL;DR
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.
Jim
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!
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.
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:
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.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.
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.
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.
- Photo by Thomas Christoph © Corei64
- SCPU64 v1
- RAMLink with 16MB brand new SIMMs
- 2MB CMD 1750XL
- CMD HD w/2GB
- CMD FD-2000
