Friday 31 January 2014

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.

6 comments:

  1. Amazing! When do you think a working beta version will be released to the public? I will buy one. :)

    ReplyDelete
    Replies
    1. Hello,
      Because I am purposely using an off-the-shelf FPGA board it is possible to buy the hardware now and start having fun. You just need a Nexys4 FPGA board and an SD card, ideally no bigger than 2GB for now, as SD HC support has not been well tested yet.

      Delete
  2. Awesome. Only 350 bucks for the best 8 bit computer ever?! I'm down. Any alpha releases yet?

    ReplyDelete
    Replies
    1. Hello,
      If you buy yourself a Nexys4 board and find a 2GB micro-SD card, that's all you need to get started. While I haven't publicly released any of the FPGA program files, I am happy to provide the latest functional one on request. In other words, you can get your own hardware now, and start playing with the latest builds as I create them. If you are interested in helping write firmware or software for it, you are even more welcome :)

      Paul.

      Delete
    2. Would a ZYBO Zynq-7000 Development Board also work since it uses an Artix-7, or are there other factors? I'm assuming it won't, but thought I'd ask because of my zero knowledge of FPGAs. Looking at the specs, it seems it has "more" in some areas, but less in others (e.g., A9 processor, 28k logic cells vs. 15.8k logic slices) Thanks.

      Delete
    3. Hello,

      I thought about the ZYBO when I started this project and decided against it for two reasons:
      1. It has a non-8-bit CPU, and I wanted a pure 8-bit system at the end.
      2. It has much less BRAM, so the C64/C65 RAM could not all be internal with zero wait-states which would result in lower performance.

      The ZYBO has the Zynq Z-7010 part, which has the smaller Artix 7 device inside (28K logic cells versus 85K in the Artix 7 100T -- each logic slice contains several logic cells). To fit the design, you would need the Zynq Z-7020 part that has the same FPGA inside it. The Z-7010 has only 240KB of block ram which is only about 1/2 of the needed amount. It might just be possible to make it fit, but the CPU would be halved in speed at least, as I would have to remove the shadow RAM from the chipram, and I might also have to reduce the size of the colour RAM from 64KB to 16KB or less. Finally, I am using 37% of the FPGA already, so it would likely completely fill the Zynq's FPGA as the design currently stands.

      See the following URLs for the comparison of the devices:

      http://www.xilinx.com/publications/prod_mktg/zynq7000/Zynq-7000-combined-product-table.pdf
      http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1198&Prod=ZYBO

      Paul.

      Delete