• Commodore Free Magazine, Issue 82 - Part 9

    From Stephen Walsh@39:901/280 to All on Fri Aug 15 17:15:49 2014

    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)