So can you Please can you explain what KERNAL64 is   
      
   AA:  Kernal64 is a cycle-exact emulator:  this means that it reproduces all   
   the internal behaviors of the original machine.  It is able to run all the   
   old (and new!) software without any adaptations.  For example, you can load   
   inside the emulator an old game disk (e.g.  using the .d64 format) and play   
   with it.   
      
   The term "cycle-exact" means that the accuracy of the emulation is   
   cycle-based, that is at every emulated clock cycle the emulator must follow   
   the same mechanism that the original machine follows during its processing   
   activity.  This kind of emulation is the heaviest one in terms of resource   
   consumption.   
      
            - - - - - - - - - -   
      
   CF:  Although it's fairly obvious, why did you settle for the name KERNAL   
   64?   
      
   AA:  The name comes from the ROM-resident Operating System name.  Some   
   people says that KERNAL is the acronym of Keyboard Entry Read Network And   
   Link, others says that the original name was KERNEL but in the very early   
   documentation it was reported as KERNAL because the name was misspelled by   
   the author I preferred the latter, that's all.   
      
            - - - - - - - - - -   
      
   CF:  Can you list the top 5 features, as I will list them all at the end of   
   the interview for readers to browse through?   
      
   AA:  OK, top 5 features of the emulator are:   
      
   1. Internet capabilities (Internet modems, RS-232)   
      
   2. Remoting (experimental)   
      
   3. Wide range of emulated devices and formats   
      
   4. Printer preview panel   
      
   5. Good debug tools   
      
            - - - - - - - - - -   
      
   CF:  Apart from the nostalgia, what prompted you to create the project?   
      
   AA:  Building from scratch an old computer via software piece by piece was   
   so exciting that in few weeks I built a minimal run-able emulator, capable   
   of executing just .PRG files and the easiest form of cartridges.  I   
   remember that the first game I ran was "Bruce Lee", and the first cart was   
   "International soccer":  But there was a bug in the sprite coordinates   
   management, so the players were composed by two sprites, and appeared   
   "mutilated", the legs run to the right and the body to the left...   
      
            - - - - - - - - - -   
      
   CF:  Of course the other question to tie into this is, "Do we need another   
   emulator?"   
      
   AA:  Absolutely not!  My work is just a tribute to the Commodore 64 and to   
   those fantastic years.   
      
   I think that building an emulator such the Kernal64 is a big programming   
   exercise, because you have to face a lot of different problems you have   
   also to search and collect a lot of documents, piece them together, and in   
   some circumstances work with fantasy to figure out what is not clearly   
   reported in the documentation.   
      
            - - - - - - - - - -   
      
   CF:  I noted you listed light pen support.  How does this work, can you use   
   a real light pen with the software?   
      
   AA:  The lightpen is emulated like the mouse or the joysticks:  The   
   joysticks are emulated via keyboard or USB real joystick, the mouse is   
   emulated with a real mouse, and the lightpen is emulated with the real   
   mouse.  The mouse pointer emulates the lightpen beam.   
      
            - - - - - - - - - -   
      
   CF:  Some will feel that CPM support is a major feature of the software.   
   How is this implemented as the C64 version of CPM needed an external   
   cartridge and not much software ran on it due to the screen resolution, and   
   incompatibilities in the disk drives?   
      
   AA:  You're right!  The core of the CPM cartridge is basically a Z-80   
   processor, the rest is some circuitry to make the processor   
   signal-compatible with the C64.  So I wrote beside the 6510, a Z-80   
   emulated software core (even if it's not accurate like the C64's main   
   processor).  The emulated Z-80 takes control of the C64 using a DMA (Direct   
   Memory Access) signal:  In this way the two processors can use the computer   
   in an alternate way (for example, all the API exposed by the C64 kernal are   
   written for the 6510 processor and when a CP/M software needs them it must   
   switch to the 6510).   
      
   To run the CP/M you must download the .d64 archive of the original   
   Commodore implementation and activate the cart.  The CP/M cart was a total   
   failure back then mainly because the Commodore's drive was not able to read   
   the available CP/M software.  Today we don't have this problem anymore,   
   because the software is available in digital supports, like .d64.  Anyway,   
   useful or not, it's very interesting to run CP/M software today on an   
   emulated C64!   
      
            - - - - - - - - - -   
      
   CF:  Is there a downloadable EXE version of the software that readers can   
   download or do you have to compile the software?   
      
   AA:  You can download an executable version using   
      
   github.com/abbruzze/kernal64/tree/master/Kernal64/dist/kernal64_install.zip   
      
   Unzip the archive and under the bin directory you will find the two   
   scripts, kernal64.bat and kernal64.sh, the first one for Windows, the last   
   one for Unix/Linux (to run the emulator you must install a Java Runtime   
   Environment 1.7 or above).  Of course it's possible to download the entire   
   project and run the Ant script to build the emulator.   
      
            - - - - - - - - - -   
      
   CF:  The software can implement Jiffy dos, I believe this is still under   
   copyright with Jim Brain being the only person who can sell and burn the   
   chips.   
      
   AA:  Yes the user must now provide the Jiffy Dos ROMS in order to use the   
   fastload.  On the Wiki (github.com/abbruzze/kernal64/wiki) there are   
   details about this.   
      
            - - - - - - - - - -   
      
   CF:  It looks like the software is regularly updated.  I guess this is   
   like, "How long is a piece of string," but do you see a time when it will   
   be "finished" with nothing more to add, or tweak?   
      
   AA:  Well, in the last months I regularly updated the software because I   
   had some functionality in mind and time to implement it.  The last one,   
   Remoting, now in an experimental phase, gives you the opportunity to   
   "share" the emulator with another Person, for example to play with a   
   2-players games (audio is not transmitted yet).  It's a sort of X11   
   forwarding, for those who are familiar with Unix/Linux:  the C64's display   
   is exported via network to another machine, so the second player can play   
   the same game of the first player.  I don't know when I will be bored with   
   this project:  anyway, it would be nice if someone else would join it on   
   Github in order to improve the accuracy and add features.   
      
            - - - - - - - - - -   
      
   CF:  Using commercial software what, from your experience is the success   
   rate, (this would be a workable loadable game)?   
      
   AA:  Unfortunately I don't have a success rate I can let you have.  I can   
   say that most of the games work properly and most of the applications   
   (utilities, alternative OS, GEOS, etc.).Clearly the demos are the hardest   
   piece of software to emulate:  Also in this case most of them run properly,   
   some show strange effects because the VIC emulation accuracy is not 100%   
   compatible, some fail.  Another source of problems is the disk emulation,   
   especially when the software being emulated uses custom fastloader.   
      
            - - - - - - - - - -   
      
   CF:  What issues were there writing the software, what was the most   
   complicated part of the software?   
      
   AA:  The only way to develop a software like this in an ideal world would   
   be to write accurately every single module (in most cases a module is the   
   software counterpart of a real chip), do a massive test phase (imagine what   
   would be a test list for the 6510 CPU, or for the 1541 disk, or even the   
   CIA), wire all the module together and test the whole object again.  I did   
   a few basic tests for each module and then day by day I fixed the bugs, a   
   lot were microscopic bugs:  it was a frustrating job.   
      
   Most of the time the bugs shows themselves in a very strange way.  For   
   example, I couldn't properly run the game "Impossible Mission":  The Game   
   seemed to remain frozen as soon as the elevator appears.   
      
   Months later I found the problem -- I had inverted the edge-triggered   
   mechanism of the NMI (Non Maskerable Interrupt), the fix lasted 10 seconds!   
      
   Of course the hardest modules to emulate are the less documented one   
      
   --- MBSE BBS v1.0.4 (GNU/Linux-i386)   
    * Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- (3:633/280)