a problem on said format in hopes that my Commodore knowledge will be a possible solution for them. Even today, when some user runs into a
problem, I always think of what I can do with my Commodore that will
possibly be beneficial to them with an answer.

So, in conclusion, I will decide to continue to work on both careers,
Commodore and Christian, so that hopefully one or the other will profit me. Like it says in Ecclesiastes 11:2, "Divide your portions into seven, yes,
even into eight, for you do not know what disaster will fall upon the
earth." Who knows? Maybe both will prosper well and I will be up in the
money, or I'll stay struggling like so many other people around the world.

But before I go, let me once again say, "Thank you," Commodore reader, for making me a success in what I do.


=====================================

*************************************
INTERVIEW WITH PAUL GARDNER-STEPHEN
Making a C64/C65 Compatible
Computer in an FPGA
*************************************

c65gs.blogspot.co.uk/

Let's jump straight in as the interview will explain the title for those
still confused about the FPGA acronym, as they say, all will be revealed,
Well not everything but you know what I mean.........

Anyway I will leave you with the interview as I have a call coming in on my shoe!

- - - - - - - - - -

Q. Please introduce yourself to our Commodore Free readers.

My name is Paul Gardner-Stephen, and I work as a lecturer in computer
science and researcher in rural, remote & humanitarian telecommunications
at Flinders University in Australia (see servalproject.org and servalpaul.blogspot.com.au for more details). I have also achieved some notoriety for creating a working shoe phone (realshoephone.com).

- - - - - - - - - -

Q. Can you give our readers a little history about yourself and your
computing love?

I have been using Commodore 8-bit computers since the mid 1980s. I first
used Commodore 64s at school, but the VIC-20 was the first computer I was
able to buy for myself. In high school I wrote 64NET to allow my Commodore
64 to use the hard drive in a PC via a custom parallel cable. 64NET went
on to be sold around the world, but mostly in Germany. The creation of
64NET also resulted in an invitation to join the tools section of
FairLight64.

As time went on, I was able to upgrade, first to a SX64 and then a C128D, appreciating the internal drive and improved keyboard of both. I never
really used the advanced features of the C128, partly because I found the memory management system to be rather unappealing and overly complex, and
the performance of the VDC to be uninspiring.

However, I remember hearing the persistent rumours about the Commodore 65 during the 80s and 90s, and imagining what an improved 8-bit computer, that really was a genuinely enhanced Commodore 64 might be.

I also started thinking about how to make a really good C64 accelerator in
the late 1990s, that didn't suffer from slow memory write-back or glitching
of the display if memory writes were cached and delayed. Looking at the
bus arrangement of the C64 I realised that it was possible to avoid these problems by pulling the write line low during a VIC-II memory access,
because nothing drives the write line during VIC-II memory accesses. This would make the RAM "listen" to whatever was put on the data lines. The
VIC-II would of course still drive the address lines. With fast enough
logic and external memory, it would be possible to watch the address lines,
and present the appropriate byte of memory to the bus, and so create a just-in-time memory synchronisation system.

I did some early experiments on making such an accelerator, proving that
the system could work, but didn't have the equipment or other resources at
the time to make it a reality. Also, around the same time, the German distributor of 64NET sent me a Commodore 65 prototype. My immediate need
for increased speed and performance were met, and I used the C65 as my main development machine for much of the late 1990s. Turbo Assembler was a
dream at 3.5MHz, and the internal 3.5" floppy, while still rather slow
(more on this in a moment) was still a considerable improvement on a 1581.
This meant that I gained quite a good working knowledge of the C65, and
even wrote a few C65-only applications, including a simplistic micro-emacs
like 80-column text editor.

- - - - - - - - - -

Q. Can you explain some of the features of the Commodore 65 and what
happened to it for the readers who are unaware of the machine?

To me, the C65 has the sense of being what the creators of the C128 might
have liked to have done, given enough time. It also contains obvious
lessons learned from the C128, principally that all advanced features can
be accessed from C64-mode. In fact, the C65 boots in C64 mode first, and a modified C64-mode kernel decides whether to jump to C65 mode.

In terms of specification, the C65 is like a cross between the C64 and
Amiga 600. It has stereo SIDs (the newer 8581 type).

The units shipped with 128KB of RAM, and an Amiga-like trapdoor slot that theoretically take another 8MB of RAM, but not without some rather scary
memory banking tricks, involving two nested levels of memory banking. The trapdoor slot mapped 512KB at a time into the 1MB address space of the 4510 processor, and required the memory expansion to include a special register
to select which 512KB bank was required.

The byzantine logic to make use of this was built into the DMAgic DMA controller, or at least was supposed to be. I don't know if anyone knows whether it was actually all implemented in the experimental units. The DMA unit is however handy for memory fills and copies, and is heavily used in
C65 mode for screen clearing, screen scrolling, and accessing BASIC
variable and program storage.

The C65 has an internal 3.5" floppy drive which is compatible with disks
from the 1581, but the DOS runs in the C65 itself. The DOS itself was
rather buggy; erasing files or validating the disk is not recommended
unless you want to mess things up. This may have been improved in later versions of the ROM, of which there were many.

The CPU is a 3.5MHz 4510, which is an extended version of the 6502 (the
VIC-III provides the 6510-like CPU IO port in the C65), but also including
the 6526 CIA adapters. The 4510 has a number of interesting new addressing modes, as well as an extra index register (Z), and some special registers
for memory mapping. The B register sets where zero page lives, now renamed
to "base page". There are also unnamed memory offset registers that allow access to 1MB of memory. The 64KB of address space is divided into eight
8KB chunks, in two sets of four. Each chunk can point to its normal
address in the first 64KB, or have an offset applied that allows it to
point to any 256-byte address in the 1MB range. The offset is common for
each of the four chunks in one half of memory, which places some practical limits on the memory mapping. The bottom few pages of memory have no
special treatment, unlike on the C128.

A lot of the extra opcodes in the 4510 (all 256 are defined) are dedicated
to more efficient bit fiddling operations which make for more compact
and/or faster code in many cases. A number of the new opcodes cover 16-bit relative branches, a relative version of JSR, allowing for completely relocatable code. Finally, there are new address modes, like
stack-indirect, and a 16-bit stack mode that make it much, much easier to
write a C compiler for the 4510 than for the 6502. Many of these new instructions are common to other variants of the 6502, but not always with
the same opcode.

This means that 6502 illegal opcodes don't work on the C65. This isn't
much of a problem for most C64 software. However, the engineers also
shaved a cycle off INC, DEC, ASL and the other read-modify-write
instructions, removing the dummy write that happens on the 6502.
Unfortunately, this broke lots of software that expects ASL $D019 or DEC
$D019 to clear raster interrup

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