Page 1 of 2

The CMD SuperCPU

Posted: Fri Sep 16, 2016 6:27 am
by KC9UDX
Does anyone know where can be found complete information on the design, operation, and usage of the SuperCPU?

Re: The CMD SuperCPU

Posted: Fri Sep 16, 2016 7:06 am
by BigEd
I don't, but I'll put up some general links anyway.
Quote:
The SuperCPU is an accelerator module that plugs into the C64/128 Cartridge port. At its heart is the W65C816S microprocessor running at 20 MHz, along with 128K Bytes of high-speed Static RAM
- from SuperCPU General Information

From the programmer perspective, it's a fast '816 with lots of memory. As such, it can also work like a fast 65C02. It runs at 20MHz as much as possible, but accesses to the host C64 have to be at 1MHz. But it's not as bad as it might be:
Quote:
In addition, buffered write-thru circuitry (similar to PC cache-controllers) helps the SuperCPU avoid slow downs when writing data back into the C-64's RAM.
I see we had a thread previously, with a photo:
viewtopic.php?f=4&t=2437

In fact, I see a number of links are already over there! (Perhaps we could kill this thread and continue over there?)

Re: The CMD SuperCPU

Posted: Fri Sep 16, 2016 5:45 pm
by cbmeeks
Anyone create one of these in FPGA format (that's easy to install) will be instantly famous and rich beyond belief. Well, famous. OK, famous in the C64 community.

:-)

The folks at Lemon64 know everything there is to know about this I bet.

Re: The CMD SuperCPU

Posted: Fri Sep 16, 2016 5:59 pm
by BigEd
There was a very long thread about it over there - see the thread I linked over here - mostly commentary from people who wanted something, or who didn't want something! Just a few commenters did seem to have technical knowledge. The best bet we have right now is probably the C65GS project, which is, in some ways, more ambitious. But it too will not make everyone happy - a lot of people who have fixated on a computer from the 80s are remarkably inflexible!

Our own Beeb816 project is a small step in the direction of a SuperCPU, but it has no write buffer, and doesn't run at 20MHz. Nor is it made for the C64's expansion port - it's made for a 6502 socket.

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 2:06 pm
by ArnoldLayne
cbmeeks wrote:
Anyone create one of these in FPGA format (that's easy to install) will be instantly famous and rich beyond belief. Well, famous. OK, famous in the C64 community.
Not exactly an FPGA-SuperCPU, but this thing here is FPGA based and sports a turbo that runs circles around a SuperCPU, while emulating a 6510 instead of using a 65816, thus being 100% compatible:
https://icomp.de/shop-icomp/en/produkt- ... on_64.html

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 4:50 pm
by GARTHWILSON
ArnoldLayne wrote:
cbmeeks wrote:
Anyone create one of these in FPGA format (that's easy to install) will be instantly famous and rich beyond belief. Well, famous. OK, famous in the C64 community.
Not exactly an FPGA-SuperCPU, but this thing here is FPGA based and sports a turbo that runs circles around a SuperCPU, while emulating a 6510 instead of using a 65816, thus being 100% compatible:
https://icomp.de/shop-icomp/en/produkt- ... on_64.html
I don't see anything on the page telling how fast it is. Do you know?

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 4:53 pm
by BigEd
Seems to be 10x, 20x or 40x the original machine, depending on benchmark:
http://wiki.icomp.de/wiki/C64_Benchmarks

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 5:01 pm
by GARTHWILSON
Hmmm... so not exactly "running circles around a SuperCPU," in fact not as fast as a SuperCPU if the latter running software written to take advantage of its 16-bit registers and added capabilities.

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 5:19 pm
by BigEd
Well, the answer to "how fast is it" is bound to depend somewhat on whether you're running legacy code or newly minted code which won't run on older slower machines. There are a few different viewpoints on what a faster computer would be for - and that's one reason why no speedup offering is likely to sell very many units.

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 5:47 pm
by KC9UDX
The only way I would ever take advantage of the 65816 in a C64 or C128 would be if I had some portable code that I only ever planned to use for my purposes. The latter is almost always true in my case, but the former almost never at this point.

I have the same problem with the REU. I've got the only one which I've ever actually seen, and I've only got one. It sure is tempting to use it, but usually that means software that won't work well without it.

What bothers me about the FPGA solution is that now we're getting into the realm of emulators, in which case a Pi is 1000% faster at maybe 10% the cost.

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 5:58 pm
by BigEd
The wonderful thing about computers is abstraction layers. For most purposes, you don't care how something is done, if it is done correctly. Whether your 6502 code is running on 70s silicon, 2000s reconfigurable logic, or being emulated on some other architecture should be no concern, because as a programmer or a user you can't tell. What you might care about is physical things like what peripherals there are, what the case and keyboard look like, what the power consumption is.
It's true that a Pi is faster - we saw a little over 200MHz in our bare metal emulation.

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 8:42 pm
by ArnoldLayne
GARTHWILSON wrote:
Hmmm... so not exactly "running circles around a SuperCPU," in fact not as fast as a SuperCPU if the latter running software written to take advantage of its 16-bit registers and added capabilities.
Which is pretty rare on a C64. I only know of one game specifically written for C64 + SuperCPU.

Also, present C64-software which is using illegal opcodes will not run at all on a SuperCPU.

Re: The CMD SuperCPU

Posted: Mon Sep 19, 2016 9:03 pm
by KC9UDX
Well technically, it will probably do something. But that's moot. I wonder how much software there is that uses illegal opcodes. Someday, I'd like to build a "65c10" and I'll find out the hard way.

I did put a 65c02 in my Apple ][+, but that's different, because at some point everyone stopped using undocumented 6502 instructions for that platform. I have not run into any problems, but I hardly use it. Even when I do, I'm using the same old disks I always use, so I'm not likely to find a problem.

Re: The CMD SuperCPU

Posted: Tue Sep 20, 2016 6:19 am
by ArnoldLayne
KC9UDX wrote:
I wonder how much software there is that uses illegal opcodes. Someday, I'd like to build a "65c10" and I'll find out the hard way.
Since every C64 and C128 uses an NMOS 6510 or derivative, it is guaranteed that software using illegal opcodes will run on every C64/C128. Some games use them, afaik Arkanoid. Of course, demos use them a lot. I also believe that GEOS uses them, but I am not 100% certain on this.
KC9UDX wrote:
I did put a 65c02 in my Apple ][+, but that's different, because at some point everyone stopped using undocumented 6502 instructions for that platform. I have not run into any problems, but I hardly use it. Even when I do, I'm using the same old disks I always use, so I'm not likely to find a problem.
Yep, that's different because Apple started to use the 65c02 with the Apple IIc in 1984.

Re: The CMD SuperCPU

Posted: Tue Sep 20, 2016 6:38 am
by BigEd
I think we're told though that WDC had to back out some of the improvements in their 65C02 to improve compatibility which was demanded by Apple. So, there was software which made use of unexpectedly fine detail in the behaviour of the NMOS part. That was probably normal for the 70s but becomes a drag on progress in the 80s.

The same sort of thing happens with ROMs - some software will read or jump into unpublished addresses, and when the ROM is revised, the manufacturer has the choice of sticking to the spec and breaking such software, or constraining the update to retain the content of those few undocumented addresses. Some manufacturers intentionally break everything undocumented to prove the point about what the spec is, and others make great efforts to retain compatibility even when they shouldn't have had to.