you think an
FPGA should we say "clone" or implementations is the best way to preserve
the machine historically?

Spare parts, especially SID chips, are already getting very hard to source. FPGA replacement of ICs is a good backup plan. However, I have been doing
a bit of digging around, and if we can raise the necessary funds, there is
a chip fab in a Canadian University that uses the right kind of process
that would allow us to recreate real SID chips, real VIC-II chips and all
the other custom chips. As a University fab, the costs are surprisingly
low, especially if it is connected in and becomes part of their VLSI
teaching. If this can succeed, then it will be the golden standard for preserving old computers, but as I say, FPGAs are a good backup plan, and
have the advantage that we have them now.

- - - - - - - - - -

Q. Talking of cloning, is that how you see the designs in FPGA? Is it
cloning of the machine?

Well, I hope to provide as close to 100% compatibility for C64 mode as I
can. This might mean having a 4510 and 6510 CPU and a VIC-IV and a VIC-II
in the design to achieve this. However, I don't intend to exactly clone
the C65. It was never finished, and so I am re-imagining what it could
have been, and giving it some capability and performance boosts along the
way, so that the end result, while very C65-like, will be a unique machine,
and I think a very fun machine. That's really the goal, that this be a
machine that is similar enough to be nostalgic, and give an authentic experience of a real C65, but with some niceties (like SD storage instead
of actual floppy disks) and extras that can be accessed (like extra RAM,
faster CPU, ethernet, more colours, higher resolutions and so on) if
desired. But when it turns on, you will be thinking, "wow, I get to play
with a C65".

- - - - - - - - - -

Q. Someone once said to me the holy grail of cloning (or implementations) would be to create a SCPU in FPGA. I see one of your goals is to provide a machine faster than the SCPU, so will SCPU "compatibility" be programmed
into the design?

Well, that is the holy grail for some at the moment, and I am sure will continue to be for a number of people. However, the C65GS is already
faster than the SCPU, especially for video-intensive tasks. The only real advantage of the SCPU right now, is that GEOS works on it. It won't be
hard to add C65GS support to GEOS, and once that is done, there will be
only a very few SCPU specific programmes that people will miss out on. So
my personal view is that SCPU compatibility will not be high on most
people's agenda if they had a C65GS.

Talking about GEOS, I am actually very looking forward to seeing it ported
to the C65GS. Pretty much all the functionality required is already there
for it to work, give or take sprites which are one of the next things I
wish to implement. The VIC-IV video modes are very like the VIC-II bitmap modes, but with resolutions up to 1920x1200 and separate 256 colour
palettes for bitmap and sprites. If someone would like to take a shot at porting GEOS to the C65GS, I'd be happy to provide the necessary technical information and assistance.

- - - - - - - - - -

Q. Some feel all this tinkering isn't the Commodore way, and the machine
isn't in fact a Commodore 64 /or 65 because its doing things that were not implemented in the machines original design, or that were impossible to implement. Would you like to comment to those readers?

I have probably mostly answered this in my response to one of the questions above. But I would say that this project isn't about recreating the
machine in a pure sense -- for that we need chip fabs. It is really about making a new C64-like and C65-like (and hopefully compatible) 8-bit machine that is fun to use in the 20th century. For me there is also a sense of
the less-is-more philosophy, in that modern computers are so complex that
they have lost a lot of the charm that we enjoyed in the 1980s. Even my
phone takes more than a minute to boot these days. Rather than just yearn
for the simple old days, I am trying to recreate some of the the nice parts
of them, but re-imagined through the hardware that is available today.

Of course my secret long-term plan is to implement a complete 8-bit
computer using a GaAs chip fab. Modern GaAs digital circuit processes are currently at about 1 micron, the same size as was used for most of the
custom chips in the C64. The big difference is that for the same power consumption as the original chips it is possible to clock a design at
somewhere around 10GHz. Now that would be a fast 8-bit computer :)

- - - - - - - - - -

Q. Personally I think this sort of implementation or "machine cloning"
leads to a better understanding of the machine and sees demos and programs
that would not have been realised if the coder hadn't been, should we say, "tinkering with the dark side" of FPGA implementations.

I think you are right in that; the more we understand the hardware, the
more we can stretch it to its limits. This is part of why I am really
looking forward to a complete and 100% accurate reverse engineering of the VIC-II.

- - - - - - - - - -

Q. On the Commodore 64 and 65 what component or software on each machine
would you change and why (assuming you could do this when the machine was created)?

I think the C64 is best left as it is, because it is so iconic. It would
be like me trying to say what should have been different in the original VW beetle.

But with the C65, I think it is easier to make some comments.

On the hardware side, planar graphics modes should have been ignored, in
favour of better bitmap and character modes so that interesting graphics
and animation could be done in 128KB RAM, and with a 3.5MHz CPU. Also, the 4510 should have included a 6502 compatibility mode that kept in the dummy writes. This would have been fairly easy to implement. One could also
argue that it should have come with more than 128KB RAM, but that was a practical limitation of the time. Otherwise, I think some more advanced sprites would have been a nice touch.

On the software side, Commodore should have put some extra effort in making
the DOS more efficient. The internal drive loads at only around
1KB/second, because it switches memory maps for every byte read. They
could have at least made LOAD and SAVE copy a sector at a time, and so run
10x to 30x faster. They may well have planned to do so, but the ROM was
never finished. This is an optional change to the ROM that I may well implement at some point. There is space in the modified C64 kernel to do
such a thing, but it isn't too high on my list because when the C65GS is running at 32MHz it loads at around 8KB/second which is pretty comfortable.
Any programme wanting to load faster can just make a fast loader that prods
the emulated floppy controller or even the SD card controller directly.
Already the kickstart ROM that loads the main 128KB C65 ROM is able to load
at several hundred kilobytes per second on a decent SD card.

- - - - - - - - - -

Q. On the 128, if you were designing the original machine without any constraints what would you have done differently given the limitations of
the day?

Ok, so If we assume we had to work with the technology of 1985, but had
plenty of time and money, then I would have used the fastest 6502
compatible CPU of the time, probably 8MHz or 16MHz, and made a new VIC-II
that did 40 and 80 column output to either a composite or RGBI video
output. Also I would have made C128 mode re-accessible via secret knock register like on the C65. The memory management would also be a lot
different!

- - - - - - - - - -

Q. Finally I would like to thank you for your time and do you have a
comment you would like to add?

You're welcome. The only comment I have is to emphasise that this is an open-source project, and so other people are more than welcome to
contribute with VHDL programming, testing, documentation or any other
activity that interests them. My h

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