From the moment the C64 came out people started to get busy enhancing this computer one or the other way, or in English: to upgrade it. One can find different sorts and forms among them. We will unveil a little for you.
The most widely known form was upgrading of the built in software (named kernal) to for example make loading and saving programs from/to disk faster. Well known names include: SpeedDos, DoplhinDos, Exos V3 and JiffyDos. The next step was increasing the memory. Two versions have made it to popularity: GeosRAM and Commodore's own RAM Expansion Unit. Both are expansion cards making changes to the C64 unnecessary. The following step was upgrading the processor. This sounds simpler than it is. The C64 contains the 6510, a brother of the well known 6502. The speed of the system bus, approx. 1MHz, is dictated by the video chip and can not be changed. To be able to use a faster processor one has to create a small system with its own RAM which only replaces the necessary parts of the C64.
The 65816 is the successor of the 6502 and a number of companies tried hard to put this processor into the C64. The most well known is probably CMD's SuperCPU. It still is produced but one problem is that the SCPU (plus memory module) isn't exactly cheap. So a number of people went looking for alternatives.
The big problem is that beside the 65816 there is no successor to the 6502. This leaves three possibilities open:
1) You use the 65816 anyway and you have some limits.
2) You use another fast processor plus a conversion program. It's relatively easy to create a PC card that emulates (imitates) the pins of the 6510. A program emulates a working 6510. You can only build up speed by letting the PC emulate as much C64 memory as possible. Problem: This can't be easily done.
3) You develop your own processor with the help of socalled FPGAs. People being familiar with EPROMs know that data can be programmed into these. You can program FPGAs too but instead of data you program circuits. Using special development tools this is possible for the average hobbyist too. Of course there are some "buts". Such a development kit currently costs more than the SCPU, hence no saving money here. The problem is not working with such a development kit, but to be able to develop such a processor, you have to have loads of knowledge. And when you have a working IC (Integrated Circuit) a printed circuit board has to be developed for the connection between the C64 and the IC.
Gideon Zweijtzer
Our Commodore user club member Gideon Zweijtzer has chosen the third way and his first step was the development of the socalled 'core' or the heart of the processor. For this, Gideon makes use of the language VHDL. Much information about VHDL can be found in the internet. And soon the first problem emerged. A processor receives its instructions in form of numbers (opcodes). Using eight bits you can define 256 different opcodes. The 6502 does not use all of the 256 opcodes. Unused opcodes form a problem. Some do nothing, others make sure that the 6502 stops completely and still others do something. There are programmers who made use of the 'illegal opcodes' for this reason. The question was whether Gideon had to support or not support the use of illegal opcodes. He has chosen to not support them for the following reason.
For compatibility reasons you have to leave the original opcodes the way they are. Hence, to develop a processor offering more possibilities you need more opcodes. This was also the case with the 65816. It utilizes all 256 possible opcodes and does not support the original illegal opcodes.
Reality shows that illegal opcodes have rarely been used. Most SCPU users say they have little problems with that. Now you can ask yourself if it wouldn't be wise to handle the useful illegal opcodes in a useful way. The problem is that there is a big logic in those opcodes. If you want to handle the new opcodes by the same logic then that will lead to the discovery that the new illegal opcodes sit in each other's way. Hence a mathematical model suggested that a processor with a wide range of illegal opcodes would be much slower than one without. The decoding mechanism would usually need more time to determine if it is a regular or illegal opcode.
The first prototype
The first prototype was done relatively fast and indicated that there still were a number of bugs in the core. A funny side effect was that this core supported a number of illegal opcodes. It was said that illegal opcodes are a by-product of the original opcodes and this incident proved it was true. A quick review showed that not all known original opcodes were present but this is not surprising if you look at how the 6502 and the 65GZ02 are developed.
The next step was to determine what the new processor would be required to do. Ideas had developed in a way that one could barely speak of a processor any longer. The first idea was to make it a 32 bit CPU: The 65GZ032. For your referrence: The Motorola 68040 and Intel 80486 are 32 bit CPUs too. But such a CPU only comes into its own if it has enough memory available. The C64 can not support this memory so a mechanism has to be integrated to support SDRAM modules. Considering today's standards the C64 is limited in its capabilities to support external devices like floppy drives, hard drives and CD-ROM drives. An improvement of the video output also should do no harm. After much thinking and considering and a number of discussions the decision was made to add PCI and 16 bit ISA bus to the processor. This enables the user to equip his 20 year old C64 in a very simple way with current technology stuff.
Jeri Ellsworth
The 65GZ032 was intended primarily for the C64 to assist the 6510 processor. Gideon is not the only person eager to enhance the C64, though. The American Jeri Ellsworth began development of a successor of the video chip of the C64 two years ago. This chip, among other things, should make it possible to get much better resolutions on a VGA monitor. But during time the project grew and after all resulted in the CommodoreOne (also C=1), some kind of C64 clone only much better. This project also has been put into reality as FPGA with one exception: The processor. Jeri did not have enough time and knowledge of the 6502 processor to develop a core for this too and used the 65816 core instead. In the Commodore world, almost everybody knows almost everybody else and it didn't take long and Gideon and Jeri were up to date with each other's development. From this it followed that the 65GZ032 developed by Gideon could be connected to the expansion port of the C=1. This way, Jeri solved her problem with her processor.
Commodore built different computers and unfortunately, they use different processors. Fortunately, they are all based on the 6502. The different pieces are so small that Gideon decided to make the print in a way that the 65GZ032 can also emulate the 8502 (C128), 8501 (C16, Plus4), a 6502 (VIC-20) and others. The latest developmet has another advantage: Making it more versatile allows for a bigger market (6502: Atari, Apple!!!). The advantage is that with the production of larger numbers of PCBs the costs are reduced and thus more people are attracted and also writing software becomes more attractive.
In summary, the first prototype of the 65GZ032 should run in the C=1. Also, there is a first idea for a 65GZ032 assembler which in turn enables other programmers to port existing 6502 code to 65GZ032 code. We will keep you updated on the latest developments.
(Translated by Paul Foerster)