Motivations and goals for the project

The previous posts have mostly consisted of screen shots of progress on the C65GS, but until now I have not gotten around to actually describing what I intend to achieve, and what bought me to this point.

I owned a Commodore 65 prototype from 1994 until 2010, when I sold it to a collector because, among various reasons, I didn't feel that I had the resources to care for what was rapidly becoming a valuable museum piece.  During the time that I owned the C65, I did make regular use of it, wrote a few simple demos and utilities, and modified some existing C64 software to take advantage of the faster CPU.

I have also owned a C128D through that time, which I also enjoyed using.  However, I always found the C128 architecture to be rather strange and unappealing.  It really does, to me at least, feel like a hacked on C64, rather than the feeling of a new and enhanced machine that the C65 provides.

During the 1990s and 2000s I had also repeatedly thought about making a C64 accelerator using a trick I devised and tested that avoids the synchronisation with VIC-II RAM problem faced by accelerators like the SuperCPU, which either limited compatibility or the speed of acceleration possible.

During my PhD studies I learned to program in VHDL, and started thinking about implementing an accelerator in an FPGA.  However, FPGAs at the time were too slow to provide the degree of acceleration that I considered necessary to make the project worth pursuing.

My goals were to make the most powerful 8-bit computer to date by various measures:

• Better graphics than the Apple IIgs, Atari 800 or Plus/4: 1920x1200 @ 60Hz, 256 colour palette from 4,096 colours (later from 24-bit colour palette once I create an HDMI output) via my VIC-IV video controller.
• Better sprites than the C64.  Plan is for the 8 compatibility sprites, plus perhaps 32 256-colour Enhanced Sprites with hardware scaling and practically unlimited size.  Maximum number of displayable sprites will depend on the resolution of the display and the sprites on a given raster line.
• Faster CPU than the SuperCPU or any available 65C816 CPU (20MHz), and ideally with enough headroom to beat a 20MHz 65C816 running in 16-bit mode.  Currently the 65GS10 runs at 96MHz, but with an effective speed more like 48MHz until I work on some planned IPC improvements, like a 16-bit cache of zero-page to make zero-page indirect instructions take as little as 3 cycles.
• More RAM than a fully expanded Apple IIgs or C65 (~8.125MB).  It will initially have 128KB of chipram like the C65, plus 16MB of slowram, plus "some" ROM.
• Comparable or better sound capability than the Apple IIgs.  Multiple SIDs plus digital audio channels.  Design to be finalised.

I also wanted to make the machine more backward compatible than the C65 or any 65C816 based machine.  The main issue here is actually quite easy to fix, consisting of restoring the 6502 read-write-modify behaviour of instructions like INC and ASL.  I would also like to make the machine sufficiently C65 compatible to be able to run a stock C65 ROM.

However, perfect C65 compatibility is not high on my list, given the relative lack of software available for it anyway.  In particular, I have no real intention at this stage of implementing the bit-planar graphics modes, as they were never really a good idea for an 8-bit computer, requiring way to many cycles to edit even a single pixel.  

Instead, all new graphics modes (and Enhanced Sprites) are planned to really be character mode, but allowing 16-bit character sets and making characters 8x8 fully addressible pixels, i.e., requiring 64 bytes per character.  This also saves lots of RAM and CPU cycles when most of the screen is blank or repetitive.  Enhanced Sprites will be mapped in the same way, allowing reuse of graphic characters to help save chipram.

This graphics architecture helps to keep fun in programming the system by making it non-trivial to have a full 1920x1200 image, as there is only about 10% of the chipram required to support such an image, and the slowram is too slow to supply the data, even if using the DMAagic DMA controller I intend to implement.

In short, I hope to preserve most of the fun elements of an 8-bit computer, while providing some 21st century improvements that will make the machine fun to program and use, and who knows, maybe help foster new life in the demo scene.

From a hardware perspective, I am purposely implementing it using an off-the-shelf FPGA development board designed for university students, as the boards are relatively cheap for their performance and have many built-in peripherals, like ethernet, VGA output, USB keyboard input.  This also has the significant benefit that availability will not be based on small production runs by myself or anyone else.  

The design is intended to be able to be installed in a real C64 case with keyboard using either a Keyrah v2, or a custom interface PCB that I have worked on.  The custom interface PCB will likely offer datasette and IEC serial ports, and later may also provide a userport and/or expansion port, depending on some unresolved factors.