ts -- because it was the dummy write that
cleared the interrupt. This is probably the single greatest source of incompatibility between the C64 and C65 for common software. Technically simple games like Impossible Mission just wouldn't work. I do recall
patching a few games to clear interrupts on the C65 and getting them to
work, or nearly work.

The VIC-III video controller is the other really interesting advance in the C65. It keeps all VIC-II modes, although to "make life easier for the programmer", raster splits that change the video mode only take effect at
the start of each character row. This means that clean raster splits are
easy to write, but it probably means that some advanced tricks, like FLI
and DMA-delay based effects may not work on the VIC-III. It also has a 256-colour palette with 12-bit colour (4,096 possible colours like the
Amiga 500).

32 colours can be used in text and normal bitmap modes, through the use of
an extra "bold" flag bit in the colour RAM (which is not 8-bit wide, and is really just 2KB of the 128KB internal RAM, unlike on the C64 where it is a separate 1KB x 4 bit RAM). The palette can be changed at anytime, so it is possible to have many more than 32 colours visible in a single frame. To
have more than 32 colours, it is necessary to use new bit planar modes,
like on the Amiga. Unfortunately, with only 128KB of RAM, this is really memory inefficient, and with an 8-bit CPU at 3.5MHz, really slow. The
focus on planar graphics, even though allowing 8 bit planes and hence 256 colour graphics, is in my view a serious design mistake. Having a super-character mode with 256-colour characters and allowing more than 256 characters is more memory efficient for games where there is a lot of
repeated graphics, and also much faster to manipulate the display. More on that when I talk about my C65GS design.

- - - - - - - - - -

Q. I often felt that Commodore missed out by not manufacturing (apart from
a few prototypes) the Commodore 65 I know I would have bought one.

If Commodore had done a really good job on the C65, and got it out quickly,
it might have had a chance. But by 1992 it really wasn't competitive, and
the shockingly slow DOS and crippled bit-planar graphics and really ensured that it was never going to be a commercial success. Of course, for us enthusiasts, this doesn't matter so much, and just the thought of using
what was possibly the most powerful 8-bit computer ever built has an
intrinsic appeal.

- - - - - - - - - -

Q. You mention the Commodore 128 feels more hacked together, and looking
at the history of the machine it would seem the designer wasn't told by the marketing department that it would support larger memory upgrades and also
be backwards compatible with the c64, (another of Commodore's failing letting-marketing run the company). Do you think this is why the C128 felt like a hotchpotch of design implementations?

My reading of the history suggests that, while I don't personally like the result, the C128 was pulled together insanely quickly, and managed to
achieve some seemingly contradictory and almost impossible goals. The
machine could run CPM on its Z80 processor. It was so amazingly close to
100% C64 compatible that the designers deserve some kind of medal. And it
was developed from scratch in only about five months.

- - - - - - - - - -

Q. Can you explain to reader what FPGA is?

The easiest way to think of an FPGA is as a programmable chip. In an FPGA
you can create a real CPU and other digital circuits, and you can change
them as often as you like. Basically it means that someone with a bit of skill, the right software and a few hundred dollars can design an
interesting new computer, without needing a chip fab or millions of
dollars.

- - - - - - - - - -

Q. Many will ask why implement the c64/65 in FPGA. Also, hasn't the c64 already been implemented in FPGA?

For me, there are several reasons.

One of the biggest reasons is that the existing C64 implementations in FPGA
are not free. That is, they are not released under open-source licences
that let someone take and improve them. For me, this is really important philosophically, and also for the longer-term survival of the C64
ecosystem. This is also why I have designed it to be able to work on an off-the-shelf FPGA board, so that as a community we don't need to rely on custom PCB runs and other barriers.

A second is that the existing C64 FPGA implementations are not really 100% compatible. I want to create a basis for making a 100% compatible reimplementation. The visual-6502 project is a key part in this, because
they will soon have a gate level reverse-engineered design for the VIC-II
and SID chips, which will make it much easier to make 100% compatible implementations in FPGA. People hoping to see such should consider
donating to that project.

- - - - - - - - - -

Q. Is this just a collage project or do you plan a physical machine at the
end of the design?

I have a few end points in mind.

One, I intend to make a computer that lives in a C64 case that is a fast, modern 8-bit computer, and that is as compatible with the C64 as possible.

Two, I would like to have a laptop form-factor 8-bit computer that I can
take with me when I travel for work, and generally enjoy using in a
productive manner. Writing notes and simple word processing is quite
feasible on a 32MHz 8-bit computer with SD-card storage and ethernet/Wi-Fi. While other laptops have to worry about suspend and hibernate, and long
boot times, with an 8-bit laptop it will be possible to cold boot in <3 seconds, and potentially <0.3 seconds if I can make the SD-card reset
happen faster.

Three, for teaching computer science, a modern 8-bit computer is I think a
good way to quickly and interestingly teach the fundamentals of computers.

Four, the experience of refreshing my FPGA programming skills will be
helpful in designing a completely open-source mobile phone that uses just
an FPGA and radio front-end, and has no closed-source binary blobs. This
will be of great use in my humanitarian telecommunications work, because it will allow me to make mobile phones that work like digital CB-radios, communicating with each other directly, as well as with phone towers.

- - - - - - - - - -

Q. Many will question "where do you start" and what tools / software and hardware would you need to program such a project.

All I needed was a $200 FPGA development board and the free license for the proprietary VHDL programming and synthesis software. The rest is knowledge
and a lot of patience, as VHDL is not a nice language, and the tools have
many bugs and short-comings.

- - - - - - - - - -

Q. You plan to implement new features for the machine. Do you think this
will alienate your creation from the purists of the machines (although to
be fair if they were that bothered they would just use physical machines)?

Purists will, as you note, not see what I am making as being "proper", and
less so because I am extending and changing the specification in some ways.
Of course, for the C65 there is no solid uniform specification, and the
various prototypes differ in various ways. But for me, this isn't my
concern. I have a real C64 for when I want to use it, but when I want
updated 8-bit fun, I will be very happy using what is undeniably an 8-bit computer (there is no other CPU in there anywhere). They are different and complementary. I have already had fun writing 4,096 colour raster bars and playing with stretching pixels using the hardware scaler in the C65GS's
VIC-IV. For me, the important thing is that it is still purely 8-bit, and feels like an 8-bit computer. So all IO is direct mapped, POKE is a
skeleton key that lets you do anything, and "booting" is mostly a euphemism
for letting the ROM clear the screen and say "READY."

- - - - - - - - - -

Q. At some point the old 8-bit hardware will fail and become impossible to repair. Could you see this happening in your lifetime, and do

--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair ---:- bbs.vk3heg.net -:--- (39:901/280)