Commodore Free Magazine
Issue Number 6

March 2007 

Musician Richard Joseph
Passed away 4th March 2007

Editor	
=====
Really got into some research this issue, I decided to 
do some reviews of Commodore vic 20 games, BUT 
guess what, I dug out  

Bomber and Blue meanies played them for 3 hours, 
and realised I hadn?t done any actual reviewing!

So err no vic games reviews then in this issue, sorry 
about that, I did though find around 50 games I had 
in a box locked in the  

attic of my house, and fondly looked through the 
covers remembering the fun I had playing the games 
many years ago before  

the Commodore 64 came out. After the 64 the old vic 
games just moved to the attic never to see light of 
day again, well until  

now. 

I have some concerns 
I have been asked how I can justify the cost of the 
disk image, and copies of the magazine, turns out 
some members are  

copying the disk images and printing the pdf then 
charging for the copies this is disgusting, I can 
appreciate a small charge for  

cost of the disk and even ink but no more. If you are 
being charged more than a duplication cost please let 
me know. 

The whole goal of the magazine is that its all FREE! 
So the disk image text and pdf are all free to 
download or read online, I  

suggest a local library or Commodore club should 
have some form of web browser if you don?t have 
internet access.

Thanks this issue and last go to Al Jackson who has 
been mugged with the job of Disk creation, Al sort of 
volunteered but  

didn?t realise it and now checks e text on the disk 
imaged D64 

Remember the magazine is all by volunteers, ok 2 
people myself and Al doing the disk text, it may not 
be professional but it?s the  

best I can do, as I have said I am no writer, I also 
found I am not good at interviewing, if you feel you 
can do better then please  

do and send in some text or a review you have 
written 

I just read the sad news about Richard joseph  
Commodore musician 

If you have an article you would like to share please 
feel free to send it to me

I have tracked 350 individual downloads of 
Commodore Free issue number 4
More surprising is no one has actually criticised the 
magazine and ripped it to shreds am I doing 
everything right, I expect many  

will now correct this oversight. 


NEWS
=====
Bomb Chase
Richard bayliss releases and updated Bomb chase
http://www.redesign.sk/tnd64/games/Bomb_Chase_
Revival.zip With updated Graphics and music 
The idea of the game is to dash around collecting 
bombs before they explode. A simple game but the 
simple ones are usually  

the most addictive.

PRESS PLAY ON TAPE is proud to announce two 
upcoming concerts in the near future:
On Saturday april 7th we'll be playing in Frankfurt, 
Germany, at the Breakpoint'07 demo event. We have 
been wanting to play in  Germany for a long time so 
we are really looking forward to this. If you live in 
Germany don't mis it! See the Breakpoint website  

for more info: http://breakpoint.untergrund.net/


Press Play on Tape
On Saturday May 5th we'll be playing another concert 
in Copenhagen at "The Rock". The last concert in 
December went really  

well so The Rock wanted us to come and play again 
:) Hope to see YOU there! Tickets are available at  

http://www.billetlugen.dk (search for "PRESS PLAY 
ON TAPE") at 85 DKK + fee. At the previous concert 
the doors closed  

during the evening because the place was crammed, 
so be prepared and buy your ticket in advance :) 
Keep an eye on our  

event page for up-to-date info about support band 
and more: 
http://www.pressplayontape.com/?pid=concerts_ther
ock2007

ROC=K ON!

PRESS PLAY ON TAPE




Cottonwood BBS
I've been hard at work on adding "goodies" to my 
BBS, which is now running on Color 64 software. I 
have added multi-upload  

capability, 40/80 column selection for message entry, 
a "one-liner" feature, and best of all, some online 
games! I've added  

Horserace (a "classic" Color 64 game), Master's 
Empire (a very good upgrade to the classic Empire 
game), and Stock Market  

(another great game).

Master's Empire and Stock Market are both multi-
player games. Everyone gets to take turns while 
they're signed onto the BBS,  

and over a period 
of weeks, the game progresses until one person 
reaches the pre-set goal and is proclaimed the 
winner.

I'll be on the lookout for more Color 64 mods to 
improve my setup... I'm always looking to improve... 
:-)

Check out what's new on Cottonwood BBS today by 
calling (951) 242-3593.

Take care...
-Andrew




COMMODORE FREE
Programming section 

I am pleased to announce that if all goes to plan! We 
should have a programming section in the magazine, 
I have asked the  

writer to produce an Introduction to programming. 

So what?s new with that there are loads of these, Yes 
dear reader and if you are a programming virgin you 
will realise they all  

start slow then seem to gather pace till it?s a rush to 
the end and somewhere mid section you seem lost! 

The Commodore Free programming guide will walk 
the user through the basics of Coding a game in 
BASIC using Commodore  

graphics then move to using sprites, and sounds, the 
adding music then finally to producing the whole 
game in machine code. 

I will announce more after I have the full ok from the 
writer taking up the challenge.  

Many readers have requested that there be a 
programming section and I hope this fills the gap, If 
you have any programming  

experience or advice please share it with other 
readers. 

Again I would like anyone whatever background to 
submit an article on something Commodore related, 
Thanks to all readers  

who contributed to this issue.




Pre-orders are now open for "The Commodore 64 
Games Book 1982 - 199x". 
 
This is the follow-up to the ZX Spectrum book 
released in December 2006 by Andrew Rollings. ( 
http://zxgoldenyears.com )
Author Andrew Fisher will review and describe over 
200 classic (and not so great) Commodore 64 fans, 
revealing trivia about  

the machine, the programmers and the games. 
There will be a limited print run, and pre-ordering will 
help guarantee the book goes to print.
http://c64goldenyears.com 
More information later in this issue of Commodore 
Free magazine 




"New version of JSIDPlay available" 
A new version of the 100% Java sid player is 
available at www.jac64.com. It plays much more sid 
tunes than previous  

versions since it is based on the latest JaC64 version 
and use Dag Lemms sidplay assembly routine. The 
full HVSC library is  

available to listen to!

http://www.jac64.com/sid-music.html

==========
 
Readers Comments 

Pablo

Hi!,
My name is Pablo and I'm a collector from Argentina. 
I'm really surprised about Commodore Free having 
copyright problems, I  

really cannot believe there are companies having 
problems with your magazine,

 I guess Commodore users are still a "respectable 
force", so they still bothered about copyrights, but 
why don't they take your  

comments as free advertising?, I simply cannot 
understand they can have complains.

Ok, just keep going on and forget about them. Great 
Magazine and
excellent work.

Pablo

COMMODRE FREE

I agree with you that other users are braking 
copyright and never get ?caught? I can sympathise 
with companies who still own  

copyright to images, text etc. the only thing I can say 
is that I have to be more careful 

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

Yann

Hi,
Where can i get the 3 first magazines?
best regards,

Yann

COMMODORE FREE

Yann Due to copyright problems I can no longer 
distribut the issues, maybe you could find a user that 
has downloaded one of  

the first 3 issues and read his/her copy Thaks

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

Damiano
hi,
i'm italian guy 1971 old ...
 
i lost the 1,2,3 number of fantastic!!! 
commodore_free_issue_ pdf fromat is possible to 
received in my email
 
than'k for your good work!
 
bye Damiano

COMMODORE FREE

Damiano
I am glad you like the magazine, like many of the 
other questions here I am unable to distribute them 
due to copyright problems, 







Jocelyn

Hi,
 I just discovered your magazine and i want to thank 
you very much for this great piece of art.  I'm a huge 
fan of the commodore  

64 (i programmed a lot in the 80's!) and I?m glad that i 
found your magazine.  I was searching for a 
Commodore 64 dedicated  

magazines and this is the only one i found. 
Thanks again!
 
Regards,
 
Jocelyn

COMMODORE FREE

Jocelyn
Glad you like the magazine, why not contribute an 
article about some of the items you wrote for the 
Commodore, no one knows  

everything about the machine and its good to look at 
others experiences

As for other magazines there are a number of PDF 
downloadable but most are not in English, also there 
are a number of disk  

based magazines to run on real machines 

Maybe I should feature an article on all commodore 
magazines Disk or paper based

Help would be very much welcome for this feature, if 
you know of a magazine disk, or pdf or paper based 
let me know, and  

how its ordered or downloaded.
  
============================
For the record then on copyright 
I was contacted by a number of company?s claming 
an infringement of copyright, or a misrepresentation 
of the company, the  

letters looked real and genuine and a number 
threatened court action if no further action was taken. 

I decided to pull all copies and text from the website, 
the letters stopped, so I now ensure I try to clear all 
text and pictures and  

logos with the relevant copyright holders. 

I am not going to list the companies involved as they 
may claim I am trying to start a vendetta against 
them, or a hate mail list, all I  

want to do is create a FREE magazine filled with 
relevant Commodore related items. 

I make no money from the magazine, and in fact its 
costing me money to keep the magazine running, as 
well as the time it takes  

to compile the issue. 

I can t blame companies for protecting themselves 
that?s how they make money, unfortunately I am not 
motivated by money, I  

enjoy having fun and living rather than thinking all 
day about money 

Regards
Commodore Free magazine 

==========
 
The 6502-RAMROM as drive expander
 
 Wolfgang Moser and Nicolas Welte 

A short overview of the 6502 microprocessor based 
hardware extension, that was designed by Nicolas 
Welte . It contains a  

dedicated test report with my personal experiences 
and some application examples. 
Originally the 6502-RAMROM 
[6502-RamRom inserted into 1541 drive, side view, 

was conceived by Nicolas Welte and Paul Frster for 
the Commodore PET series computers as a RAM 
and ROM expansion and  

diagnostic board, leading to it's first name: PETRAM. 
Based upon many discussions with Nicolas in the 
design phase, he (we ?)  

decided to make use of a Flash-ROM chip instead of 
just EPROMs. And other 6502 microprocessor based 
Commodore  

computers like the VIC20 or the 1541 disk drive 
should be taken into account. 

The processor adaptor board can be configured for 
different systems by simply replacing one little GAL 
16V8 programmable  

logic chip. To keep the hardware simple, the C64 
computer or other non pure 6502 micro's are not 
supported. 

6502-RAMROM prototype test report from Womo, 
2003-02-07 HardwareSome weeks after Nicolas 
received his professionally  

manufactured printed circuit boards (PCBs) of the 
6502-RAMROM  I ordered two of them  
[Delivered 6502-RamRom and Flash-Adaptor PCBs, 

along with some of the needed components. Since I 
don't own a PET computer nor a VIC20, I ordered 
only two GALs for the  

Commodore 15x1 drive replacement configuration. 
Since I can call myself an experienced electronic 
craftsman, soldering the 




board was no big problem. Although I have to state 
that, for a beginner, it may be too hard. Please look 

onto Nicolas' construction page and carefully decide, 
if you feel able to solder the board. If not, you should 
order the ready-built  

extension board 
 
[6502-RamRom top view,
 
[6502-RamRom bottom view
 
[Soldered optional SMD-RAM, 

At this time, the Flash update software wasn't 
available for disk drive in-circuit updates, so I had to 
use my IBM-PC based  

c't-Flasher for burning some contents into the ROMs. 
I tested several speeder ROMs, flashed different 
versions into the four  

ROM banks and switched them forth and back. 
Everything worked fine, cool.  
Dolphin-DOS 2.0
Before I could test the RAM options I needed to solve 
some problems. I wanted to test out the Dolphin-DOS 
2.0 floppy speeder  

ROM  which makes use of additional RAM . But for 
this and other speeder systems I needed to install a 
parallel cable from the  

floppy's 6522 VIA chip to my C64's user port. And I 
needed a simple solution to quickly test out different 
C64 Kernal  

replacements.The second was no problem, because 
I also ordered some Flash-ROM
 
[C64 Flash-Adapter Kernal ROMswitch, top view,  
[Inserted C64 Flash-Adapter Kernal ROM switch,] 

adaptor PCBs  and could easily build a Flash-ROM to 
C64 Kernal adaptor. Inserting a parallel cable into my 
1541 drive was a  

little bit problematic, because the 6502-RAMROM 
board overlays the 6522 VIA chip location. First I 
used some additional 40 pin  

sockets to lift the 6502-RAMROM a bit higher, but I 
didn't feel happy with it; the case couldn't be closed 
now. So I built a very  

special lowest-profile parallel cable adaptor. 
 
[1541 low profile parallel cable adaptor, bottom view,
 
[1541 low profile parallel cable adaptor, top view, 

This all done, I first tested my beloved SpeedDOS 
(35 and 40 tracks) and made sure, that it worked fine. 
I also tested some of  

the most important copy programs to make sure, that 
the parallel cable and the ROM replacements don't 
fail. Preparations for the  

test of Dolphin-DOS 2.0 ] were done, flashing the 
1541 drive ROM and C64 Kernal. I configured the 
RAM option switches to  

DD2 and made the first steps. Anything looked fine. 
And wow, DD2 isn't as slow as I thought all the time. 
Although beaten by  

Professional-DOS  working with it brings fun. I 
couldn't see any problems like load or CRC errors, all 
games loaded fine and  

were playable. So the RAM seemed to work fine 
also.
 
 
[Space between parallel cable adaptorand 6502-
RamRom (view 1), 

 
[Space between parallel cable adaptor and 6502-
RamRom (view 2),

 
[Space between parallel cable adaptor
and 6502-RamRom (lifted), 

In-circuit flashing
The next test phase came, when Nicolas was 
finished with the in-circuit drive flashing software . 
This piece of software was  

designed a very, very special way. The ROM, that is 
going to burned is not loaded into the computer's 
memory and transferred  

back into the drive's Flash-ROM memory. That would 
be much too long winded. No, the ROM contents are 
transferred directly,  

block by block, from the disk's surface into the drive's 
buffer memory and further into the Flash-ROM. 

This is possible, because Flash-ROMs from Atmel ] 
were used, that can be flashed page by page. 
Unfortunately the Flash  

software does only support chips from Atmel until 
now, but you can use differently sized ROMs, if you 
want (AT29C256,  

AT29C512, AT29C010) and if you don't need that 
much ROM banks.For the first times flashing new 
drive ROMs went  

flawlessly, but whenever a SpeedDOS-ROM was 
configured via the main ROM switches I ran into 
problems with flashing other  

ROM banks.

 Some tests revealed, that whenever a SpeedDOS-
ROM was selected with the 6502-RAMROM and the 
Flash enable switch  

was set, the drive hung up, when a file was loaded or 
the error channel was retrieved with the '@' 
command. I discussed it  

with Nicolas and he told me, that he found similar 
problems with the original CBM VIC20-ROM. We 
found out that some  

misdesigned ROM code fragments were responsible 
for this (Note: the VICE emulator's built-in monitor 
was exceedingly helpful  

with this: <ALT>-m, device 8:, watch store 8000 
FFFF, exit).

 Whenever the Flash enable switch is set and parts 
of code executed by the desired 6502 processor 
store values to the ROM  

(to the Flash-ROM), the internal logic of the Flash 
blocks the whole chip so that even reading the ROM 
fails for some time. After  

discussing this point in the cbm-hackers mailing list ], 
Nicolas managed to fix this ROM bug and so did I 
with the  

SpeedDOS-ROMs . 

Now, with the patched ROMs, I was able to Flash 
other ROM banks without the need to switch back to 
the original CBM DOS  

2.6 ROM (which worked flawlessly with all previous 
tests).  Problems with the prototype another problem 
manifested when  

analyzing the store-to-ROM problem with the drive 
expansion 6502-RAMROM prototype What happens, 
when someone  

wants to flash the whole ROM, but the DD2 RAM 
configuration is selected?

 Because the DD2 RAM overlays the drive's address 
space from 0x8000 to 0x9FFF  the Flash-ROM 
cannot be addressed  

there. Furthermore, DD2 went crazy, whenever the 
Flash enable switch was set. Nicolas detected the 
problem by carefully  

reviewing the 1541 GAL equations. 

The Flash option switch disables the overlaying RAM 
for write operations. Not a big task, because only the 
GAL needs to be  

replaced, I thought.  First we decided to patch the 
floppy DOS ROM part of Dolphin-DOS 2.0. The ROM 
code should not access  

the 8kB RAM at the memory address location 
0x8000...0x9FFF anymore, but at the addresses 
0x6000...0x7FFF. That way no  

changes to the 6502-RAMROM would needed, 
because the RAMboard configuration could be used 
instead. And flashing the  

full 32kB ROM bank should become possible, too.  
But Nicolas reported, that the patched DD2-6 ROM  
didn't work, although  

other tests with the VICE emulator showed no 
problems. He found out, that there was a real 
hardware problem, that depends  

on the special address decoding behaviour of the 
CBM drive series (RAM and especially VIA locations 
mirrored at different  

addresses; IRQ flag handling). Since the PET and 
VIC20 computers don't contain such mirrored device 
address spaces, this  

problem couldn't be detected with the PET/VIC20 
6502-RAMROM prototypes. 

The Solution
Nicolas worked out a solution, that needed the least 
possible changes to the PCB in combination with 
changed GAL equations.  

Without the GAL, this fix would have been a huge 
patch orgy. Unfortunately you have to redo the patch  
if you want to use the  

6502-RAMROM in a VIC20 or PET again. Although 
not needed I installed some jumpers to easily 
configure the PCB for both  

options. 

 In the meantime I tested flashing other Flash-ROMs 
with different sizes. I had an AT29C020 as spare and 
tested the bigger  

flashing page size. Reading out the ROM contents 
with the c't-Flasher  at my PC again showed no 
differences. Note: you can't  

access/flash half of the banks of this ROM type 
without further hardware modifications. Then I tested 
an AT29C256 as a small  

replacement for my C64 Kernal switch board. 


[AT29C256 to 32 pin Flash-Adaptor, bottom view,

 [AT29C256 to 32 pin Flash-Adaptor, top view, 

Before I had to build a small Flash adaptor, because 
the 29C256 has got a different pinout (28 pins) than 
the standard 32 pin  

Flash ROM chips. I hacked Nicolas' Flash-ROM 
board  a little bit by cutting some traces. Although the 
Flash-ROM PCB was not  

designed for this purpose it fitted my needs best 
(instead of building a cable wired adaptor). 

Flashing the 29C256 with the least possible page 
size brought me a very small kernal switch board in a 
few minutes; thanks to  

the well designed Flasher software , that is able to 
burn different parts of the ROM chip in several steps 
(by selecting a start  

address of 0x8000, 0xA000, 0xC000 or 0xE000). 

6502-RAMROM final release test report from Womo, 
2003-02-16 Retesting different flashing scenarios to 
check, that the  

problems with Dolphin-DOS were gone After I got the 
new changed GALs I repeated all the earlier tests: 
Flashing the original  

CBM DOS V2.6 into bank 0 Selecting bank 0 and 
flashing the patched SpeedDOS 40 tracks ROM into 
bank 1 
Selecting bank 1 and flashing the original Dolphin-
DOS 2.0 ROM into bank 2. Because of the applied 
SpeedDOS ROM patch, the  

Flash procedure went flawlessly. 

 Selecting bank 2, configuring the DD2 RAM 
configuration and flashing the patched Dolphin-DOS-
2.0-6 ROM (RAM a location  

0x6000 to 0x7FFF) into bank 3. No problems with 
that and it shows, that you can now Flash the ROM 
locations from 0xA000 to  

0xFFFF, when the original Dolphin-DOS 2.0 is 
enabled. But don't try to Flash the ROM location at 
0x8000. Because it is used by  

DD2's RAM, the drive may become stubborn. 

Selecting bank 3, configuring the RAM-Board 
configuration and flashing the Dolphin-DOS 3.0 ROM 
into bank 0. With the patched  

DD2-6 ROM the full ROM bank (0x8000 to 0xFFFF) 
could be flashed without any problem, thanks to the 
hardware modification  

and the new GAL. 
After preparing some matching C64 Kernal ROMs
 [AT29C256 to C64 Kernaladaptor, top view,


[AT29C256 to C64 Kernaladaptor, bottom view,]

I started testing the burned SpeedDOS and Dolphin-
DOS versions. As mentioned earlier the patched 
SpeedDOS and also the  

original Dolphin-DOS ROM worked without problems. 
I also tested some special Dolphin-DOS copy 
programs (Dolphin-Copy)  

without problems. The patched Dolphin-DOS-2.0-6 
(RAM at 0x6000) is another task, with this ROM, the 
Dolphin-Copy program  

doesn't work, because the RAM location seems to be 
hardcoded into the copy tool. I also tested Dolphin-
DOS 3.0, which  

worked fine with the exception that it was nearly as 
slow as the original CBM DOS. 

No wonder, because DD3 makes use of an extra 
parallel port chip (6821 PIA) within the drive. It 
cannot communicate over the  

standard parallel port cable connected to the VIA 
6522, therefore it has to use the slow serial bus 
transfer routines.  

The future and some ideas Until now, mainly the 
ROM part of the 6502-RAMROM was tested, in the 
future I'll have to look at the  

RAM configurations, especially in some applications 
for the maxRam-Mode. Perhaps Markus Brenner 
wants to jump in here and  

extends his Burstnibbler based transfer tool mnib , 
so that much more sophisticated copy protections 
can be dumped to G64  

disk images. I already started analyzing the Dolphin-
DOS 3.0 DOS ROM looking for all the parallel port 
accesses to the 6821 PIA.  

Maybe I'm able to patch it, so that it makes use of the 
VIA 6522 parallel port. 

This way people may use Dolphin-DOS 3.0 without 
hardware hacking; that means adding an additional 
6821 PIA into the floppy.  

 I should take my 1571 floppy drive sometime and 
test it with the 6502-RAMROM, too. 

There are other floppy speeders, especially designed 
for this drive. Not only to mention Dolphin-DOS 3.0 
for the 1571, but  

especially Prospeed-1571. With this drive, the 
maxRam mode of the 6502-RAMROM cannot be 
used, it would overlay the 1571's  

CIA and the registers of the WD177x controller.

 It may be interesting what could happen, if the 
maxRam mode is used nevertheless.
Not enough, there are more problems with the 
Commodore 1571 disk drive. 

Since there is incredibly little space between the 
mainboard and the transformer assembled over it, I 
currently don't know, how  

to insert the 6502-RAMROM into the 1571 drive best. 
One solution may be to connect the board with some 
flat cable to the  

processor socket. As for the parallel cable connector 
(1571 Burstnibbler cable compatible) I already built 
another lowest profile  

adaptor. 

[Inserted 1571 low profileparallel cable adaptor, 

[Space upon 1571 low profile parallel cable adaptor, 

[1571 low profile parallel cable adaptor, top view,

[1571 low profile parallel cable adaptor, bottom view,

Conclusion and application scenarios
Speeder system emulatorEmulating different 
DOS ROMs and simple speeder systems like Jiffy-
DOS, SpeedDOS or  

Dolphin-DOS is the playfield of the 6502-RAMROM, 
when inserted into Commdore's disk drives. You only 
need to add a simple  

parallel cable for some of these systems. 

Atmel Flash device programmer

In combination with a patched Dolphin-DOS (DD2-6) 
, this hardware extends your floppy disk drive to a full 
blown high speed  

Atmel Flash device programmer. You will never need 
to handle with EPROMs and EPROM burners again. 
There is no need  

anymore for transfering the ROM files slowly to the 
computer memory before they can be written to the 
EPROM. The well  

designed flasher software makes your life even 
simpler. 

Maybe you want to replace your system ROMs with 
DD2-6, which requires some little hardware 
modification (using address  

line A14 for switching the upper and lower part of the 
DD2 ROM at 0xA000/0xE000); this way you can 
flash the whole chip.  

Nicolas is also working on more functions, like 
programmable bank switching about unused VIA/CIA 
port lines.  

Maybe not only Dolphin-DOS-2.0-6 can speed up the 
Flash process a little bit, but other drive speeders like 
Jiffy-DOS, too.  

Because of the special designed In-System-Flash 
software, the whole process is not really slow on a 
1541 drive equipped  

with a standard CBM DOS (35 seconds for 32kB). 

So you don't need to install a speeder system or 
ROM in any case, instead it is an option. And Nicolas 
said, the Flash software  

contains some potential for speedups with the 1541 
drive. Let's wait, test and see... 

RAM (only) expander (1541/1571 RAMBoard) and 
RAM diagnostic moduleMore applications of this 
board may rely on the RAM  

option only, you could save some money by not 
making use of the Flash-ROM chip. Copy software 
like the well known tool  

series Maverick already know how to use a 
RAMBoard equipped drive  which the 6502-
RAMROM can easily be configured to  

emulate. 

Perhaps Michael Klein (cbm4linux  or other people 
may want to develop special software, that makes 
use of a maxRAM  

equipped disk drive (nearly 32kB of RAM usable). 
Not to mention the RAM diagnostic functionality that 
replaces the drive's builtin  

RAM by the one from the 6502-RAMROM. 

Things, the 6502-RAMROM can't do easily
Because the hardware was mainly designed for 
universality and simplicity, it is not a general speeder 
system hardware  

emulator. Systems like Dolphin-DOS 3.0, 
Professional-DOS or Prologic-DOS cannot be used 
without further extensions or ROM  

patches. This purpose may be the job of another 
hardware extension board, one of the projects I am 
currently working on.

Taken from the website
http://d81.de/6502RamRom/

 Wolfgang Moser and Nicolas Welte
Re printed with owners consent


Notes From Wolfgang Moser on the project

Email: -Wolfgang Moser

in general I agree about reprinting parts of my online 
article, if authorship is made clear and the origin of 
this article is named.  

Spelling corrections may be done. Then the article 
sometimes contains outdated informations, like e.g.:

"Nicolas is also working on more functions, like 
programmable bank switching about unused VIA/CIA 
port lines."

Nicolas is currently not working on extensions to the
6502-RamRom, it perfectly does its job as it is.

Since Nicolas also may want to agree to reprint my 
article or because he wants to point out other things, 
he got a Bcc copy of  

this mail.

Commodore Free I received no email from Nicolas 
but decided to print the article 

==========

THE REST OF THE BIBLE
By Dave Moorman  

OPEN lf,dv,ch(com)
  
  Here is how you access the disk drive. LF is the 
Logical File number, which you pick. You can open 
more than one file, but  

each must have its own Logical File number.

DV is the device number (8 or higher for disk drive). 
CH is the Channel, again a unique number for each 
open file (we often just  

use the LF number, unless the OPEN is for a DISK 
COMMAND).

DISK COMMANDS

 We can send commands to the disk to Scratch a file, 
Format (New) a disk, Rename a file, or Copy a file. 
Each is sent over the  

Command  Channel -- 15. Here are some examples.

OPEN 1,8,15,"S0:FILE":CLOSE1
This will Scratch the file named FILE from the disk.

 OPEN 1,8,15,"N0:DISK NAME,ID":CLOSE1
This will format a new disk, preparing it to accept 
data.
 
OPEN 1,8,15,"N0:NEW NAME":CLOSE1
NOTE: no ID characters. This will wipe a formatted 
disk clean and give it a new name.

OPEN 1,8,15,"C0:NEW FILENAME=OLD 
FILENAME":CLOSE1
This copies the file OLD FILENAME to another file 
called NEW FILENAME.

OPEN 1,8,15,"R0:NEWNAME=OLDNAME":CLOSE1
This changes the name of the file OLDNAME to 
NEWNAME.

Channel 15 also lets the disk communicate with the 
computer. Here is a trick we use all the time to find 
out whether a certain  

filename is 
on the disk.
    
    10 F$ = "FILENAME"
    20 OPEN 1,8,15,"R0:"+F$+"="+F$
    30 INPUT#1,EN
    40 CLOSE1
    
When this is done, EN will contain either 62 or 63. If 
EN=62 then the filename is not on the disk. If EN=63, 
the file name IS on the  

disk.

Once the command channel is open, we can use 
PRINT#lf to send further commands to the drive. We 
do this in our Scratch and  

Save routine:

    60000 D=PEEK(186):IFD<8THEND=8
    60001 OPEN1,D,15,"I0":N$="PROGNAME"
    60002 PRINT#1,"S0:"+N$:CLOSE1
    60003 SAVEN$,D:VERIFYN$,D:END
   
OPEN1,D,15,"IO" (should be "I" zero) makes sure 
the disk drive is awake and aware. Then the program 
name is put into N$. Line  

60002 scratches the program name, and CLOSEs 
the logical file. Finally, we SAVE N$,D, then VERIFY 
N$,D to make sure we  

got a good save.





We also use OPEN to open a file for reading or 
writing. Here is code that will save three variables to 
a file, followed by the  

routine to get those three variables.

    10 DV=PEEK(186):IFDV<8THENDV=8
    :
    1000 OPEN 1,DV,15,"S0:DATAFILE":CLOSE1
    1005 OPEN4,DV,4,"DATAFILE,W,S"
    1010 PRINT#4,A$
    1011 PRINT#4,B$
    1012 PRINT#4,C$
    1013 CLOSE4
    1014 RETURN
    :
    2000 OPEN4,DV,4,"DATAFILE,R,S"
    2001 INPUT#4,A$
    2002 INPUT#4,B$
    2003 INPUT#4,C$
    2004 CLOSE4
    2005 RETURN

When we OPEN a file, we need to tell it the filename, 
whether we will be Writing it or Reading it (W or R), 
and what kind of file it  

is. We have two normal kinds of files: Program and 
Sequential. For short data information, use a 
Sequential file. 

So, after scratching the file, we open it to Write, 
Sequential (,W,S). Then we use PRINT#lf to print the 
data to the file. The best  

way is shown above, with each variable printed 
separately. We CLOSElf and RETURN when 
finished.

To get the data back into the variables, we open the 
file to Read, Sequential. (You can leave off the ",R,S" 
when opening a file  

to Read.) Then we INPUT#lf each variable exactly 
the same order as we did the 
PRINT#lf, CLOSElf, and RETURN to the main 
program.

    OPEN is also our way to get data to the printer.

    100 OPEN4,4,7
    110 FOR X = 0 TO 50
    120 PRINT#4,A$(X)
    130 NEXT
    140 CLOSE4
 
Here we assume that each element of the A$ array 
has one line of text for the printer. You will have to 
experiment with your  

printer on this -- and read the manual for special 
characters and effects. At 
LOADSTAR, we assume a 66 line page with 80 
characters to a line -- and don't do much that is 
fancy.

[NICKEL GAMES has a built in function to turn a C-
64 print-out into a PC TXT file. After doing a print-out 
in VICE, press <Alt-Tab>,  

and click on File>Print. In a moment, your print-out 
will be displayed. You can copy and past it to a word 
processor, save it as a  

TXT file, or send it to your printer.]

NOTE: Always CLOSE the logical file after use. 
Getting proficient with OPEN takes a lot of practice!
See SECRETS for other stuff about disk access.


PEEK(loc) (fun)
Returns the contents of the memory byte at LOC. We 
use PEEK(186) to discover which disk drive device 
was last used. You will use it a lot for advanced 
tricks.

    10 DV = PEEK(186)

POKE loc,byte
Puts BYTE value into memory location LOC. 
Especially important for controlling C-64 features not 
included in BASIC 2.0.

10 POKE 53280, 0:POKE 53281, 0
(Turns screen border and background black)

POS(0) (fun)
Returns the current position of the cursor on the 
screen row (0 - 39). I have no idea what this would 
be good for!

PRINT (com)
Probably the most important and versatile command 
in BASIC 2.0. It puts characters, strings, and values 
on the screen.

End the PRINT with a semicolon to keep the cursor 
from automatically dropping down to the first column 
of the next row (called  

a carriage return). Use a comma to move the cursor 
to the next pre-set tab 
location on the line.

Semicolons and commas can separate data in a 
PRINT command. This is a command you will have 
to play with!

READ (com)
Reads values or strings in DATA statements into 
variables.

 Make sure the number of data items in the DATA 
statements match up with what you are expecting! 
For string data, enclose  

each string in double-quote 
marks.

    100 FOR X=1TO4
    110 READ A$(X)
    120 ? A$(X)
    130 NEXT
    140 END
    20000 DATA"DADDY","MOMMY"
    20001 DATA"JUNIOR","SIS"

REM (com)
Short for REMark. Everything on the program line 
after REM is ignored by the computer. Good for 
commenting on what the  

program is doing at 
a particular point.

    10 REM BEGINNING OF PROGRAM
    :
    199 REM MAIN LOOP AT 200
    :
    60100 REM (C)2005 DAVE MOORMAN
    60110 REM COPYING THIS PROGRAM BY 
    60111 REM ANY MEANS WILL GET YOU
    60112 REM A SLAP ON THE HAND!

RESTORE (com)
Resets data point so that the next READ receives the 
first data element from the first DATA statement. Not 
very useful, really,  

since we usually READ data into arrays, which are a 
lot easier to handle.

RETURN (com)
Ends a subroutine and sends the program back to 
the GOSUB that jumped to this place. 

RND(n) (fun)
Returns a random number between (but not 
including) 0 and 1. If N is a negative value, the value 
is used to seed the random  

number generator. The result will always be the 
same for each negative number. If N is 0 or positive, 
a new random number is  

generated. Most say using 1 is best.

Actually, computers cannot do truly random numbers. 
Everything inside a computer is far too logical. 
However, with a bit of  

math, it can generate a list of unknown numbers. 
When you use a negative argument, you reset the 
generator. 

I have heard some arguments about how an 
argument of 0 is not as random as a positive 
argument. Who knows?

To get a useable number, you might use this custom 
function:

    10 DEF FNR(X)=INT(RND(1)*X)+1

If you want values from 0 to X-1, leave off the last +1. 
Now any time you need a random number, just use 
the function. Here is  

a routine to shuffle 52 "cards".

    10 DIM CD(52)
    15 DEF FNR(X)=INT(RND(1)*X)+1
    20 FOR X = 1 TO 52: CD(X)=X:NEXT
    30 FOR X = 1 TO 52: R=FNR(52)
    40 C=CD(R): CD(R)=CD(X): CD(X)=C
    50 NEXT

    Please do NOT do this:

    10 DIMCD(52)
    :
    200 DEF FNR(X)=INT(RND(1)*X)+1
    210 CD=FNR(X):IFCD(CD)<>0THEN210
    220 CD(CD)=1
    230 RETURN
 
You will be able to quickly "pick a card" at first, but as 
the cards are taken, each pick will take longer. To 
find the last card, you  

are likely to look at about 52 taken cards!

RUN [ln] (com)
Runs a program. You can begin a program at a given 
line number. You can also use RUN in a program to 
start all over from the  

beginning.

RIGHT$(s,n) (fun)
Return the rightmost N characters from string S.

    10 A$ = "THIS IS A TEST"
    20 ? RIGHT$(A$,4)
    (This will print "TEST".)

SAVE (com)
We have already covered the correct way to put a 
Scratch and Save routine in every program. In a 
pinch, you can simply

    SAVE"FILENAME",8

SGN(n) (fun)
Returns -1 if N is negative, 0 if N is 0, and 1 if N is 
positive.

SIN(n) (fun)
Returns the sine of N in radians.

    10 A = SIN(1)
    (A contains the value 0.841470985.

SQR(n) (fun)
    Returns the SQuare Root of N.

    10 A = SQR(9)
    (A contains 3)

STOP (com)
Causes a break in the program. Line number is 
reported. Useful for debugging.

STR$(n) (fun)
Returns a string of the value N.

    10 A$ = STR$(123)
    (A$ contains " 123")
    15 V = 4
    20 B$ = RIGHT$("0"+MID$(STR$(V),2),2)
    (B$ will contain "04")

SYS loc (com)
Executes an ML routine at memory LOCation. SYSie 
commands are often used with ML Modules just like 
BASIC commands,  

complete with parameters. Be sure to read the 
documentation that comes with modules.

TAB(n) (print com)
Moves cursor to N column when printing.

    10 PRINT TAB(17)"CENTER"
    (The word "CENTER" is printed in the center of the 
line.)

TAN(n) (fun)
Returns the tangent of N in radians

    10 A = TAN(1)
    (A contains 1.55740772.)

USR(n) (fun)
Executes ML routine in memory pointed to by 
locations 784/785. N is placed in the Floating Point 
Accumulator. Returns the value  

in the Floating Point Accumulator. This is a function, 
not a command, so you must either PRINT USR(N), 
or put the result into a  

variable -- A = USR(N).

VAL(s) (fun)
Returns the value of string S. Non-numeric 
characters return 0.

    10 ? VAL("12A7")
    20 ? VAL("NAME")
    (Prints 12 and 0.)

VERIFY (com)
Like LOAD, except VERIFY compares the program in 
memory with that on disk without changing either. If 
the memory matches  

the disk file, OK 
is printed.

WAIT loc,v [,eor] (com)
Causes the program to pause while waiting for the 
byte at memory LOCation ANDed with V and EORed 
with C is not zero. C is  

optional. This is a great command for waiting for a 
keystroke.

    10 POKE 198,0
    20 WAIT 198,1
    30 GETZ$
The program pauses while WAIT watches location 
198 (which holds the number of keystrokes currently 
in the keyboard  

buffer). When a key is pressed, the program 
continues, GETting Z$.


SECRETS

Here are some "secret" routines that do useful things.

BLOAD
To load a binary file or block of data to any place in 
memory (except between 53248 and 57343).

    1 DV=PEEK(186):IF DV<8 THEN DV=8
    5 DEF FNH(X) = INT(X/256)
    6 DEF FNL(X) = X - FNH(X)*256
    9 ADDR = 49152: REM ADDRESS WHERE FILE         
WILL BE LOADED
    10 SYS57812"FILENAME",DV,0:POKE780,0
    20 POKE781,FNL(ADDR)
    25 POKE782,FNH(ADDR)
    30 SYS65493

BSAVE
To save memory to a file. Cannot save from 40960-
49151, or above 53248.

    35 B = 49152:REM  BEGIN ADDRESS
    36 E = 53248: REM END ADDRESS + 1
    40 SYS57812"FILENAME",DV
    50 POKE 193,FNL(B):POKE 194,FNH(B)
    60 POKE 174,FNL(E):POKE 175,FNH(E)
    70 SYS62954

POSITION CURSOR ON SCREEN
his handy routine will put the cursor anywhere on the 
screen, where X = 0 through 39 and Y = 0 through 
24.

    1000 IF Y=0 THEN ?"<Shift-HOME>";:GOTO1020
    1010 POKE214, Y-1:?
    1020 ? TAB(X)"WHATEVER!"

Note: If the printing wraps around, an extra screen 
line may be inserted. Avoid printing to column 39 if 
possible!

Read through these commands and functions again! 
Try the code. Try experiments. Programming 
requires a broad knowledge  

of possible commands 
and functions and ways they can go together.


Dave Moorman
Editor, LOADSTAR
September 12, 2005
 
==========
 
Interview with HOXS-project
David Horrocks
 

Q Hello David, and thanks for taking the time to 
answer our few questions. Perhaps you want to 
introduce yourself first?

A I am David Horrocks and I live and work in 
England, Cheshire as a Software Engineer. I 
currently design and maintain data  

management 
applications which makes Hoxs64 a very different 
type of project to what I do at the office 

Q When did you start the HOXS-Project (we may 
assume that the name of the Emulator comes from 
the surname of the  

author?) and what has been 
your aim?

A Yes. The name Hoxs comes from my surname. I 
sometimes wonder if I should have come up with 
something more snazzy  

but at least the originality presented no problems 
getting a .com domain name. The Hoxs64 project 
starting during a period of  

annual leave early in January 2001. 

The initial aim was for me to understand what made 
a computer like the C64 tick. I was inspired by seeing 
other emulators and I  

mistakenly thought it would be a quick job to throw 
together a CPU and graphics emulation based on the 
programmers  

reference guide.

But things were more complex as I delved deep into 
the inner working and then the project just grew and 
grew. The CPU emulation being the first part to be 
designed was quiet tedious. There was no visual 
result for me see how  

things were progressing. The disassemble window 
was a necessary item to help view the progress of 
the CPU.

 I remember getting the CPU to execute the initial 
C64 ROM boot code but would get stuck looking for a 
non existent VIC  

graphics chip. That was my cue to begin coding the 
VIC emulation. It was major milestone just to get to 
the point where Hoxs64  

could display the words 

**** COMMODORE 64 BASIC V2 ***** as every C64 

emulator author will surely testify. A large amount of 
work takes place before there is even just one pixel 
dot to show for.  

There is no half way house to show. C64 software 
simply will not run with until you have all of a RAM, 
ROM, CPU, VIC and CIA  

emulation all put together in the right way

 
Q Why do you think there is a need for yet another 
C64 Emulator for Windows? What can HOXS do that 
WinVice or CCS64  

can't?

A With good emulators like Vice and CCS it is tough 
to argue the need for a new emulator. These 
emulators have features that  

are currently 
missing in Hoxs64 such as ROM cartridge support, 
mouse and tape seek interface just to mention some.  
But there are a couple  

of unique things  about Hoxs64. Vincent Joguin's 
http://www.oldskool.org/disk2fdi/ FDI 
support has recently been added. FDI support gives 
Hoxs64 better  accessibility to copy protected disks. 

As far as I know, Hoxs64 is the only C64  emulator in 
the world to emulate cycle based sprite collision and 
the  only one that  

can run Emu-Fuxx0r protected 

software 
http://www.btinternet.com/~hoxs64/Plush_Emu-
Fuxx0r_V2.zip 

Q Is HOXS rather adressed to the "skilled-
programmer" than to the "quick-gamer"? Because 
there are several games that do not  

run on the 
emulator - how compatible do you think is HOXS in 
its present version?

A Hoxs64 is aimed at all C64 users both 
programmers and gamers. I will  admit that until I 
revamp the debugger then  

programmers are not as well  catered for as 
compared to the fully featured debugger in WinVice.

 I am  not aware of any games that do not run in 
Hoxs64. If anyone finds a  game not working then I 
would be happy receive  

the file image for the 
purpose of improving the emulation. Occasionally a 
user will mail a game  that does not work. One such 
example was  

MicroLeague Baseball which  recently got fixed. This 
game required D64 custom track format support 
which  was  

subsequently added to the disk drive emulation.

In my humble  opinion the C64 side of the emulation 
has reached such a high level that no  legacy 
software should fail. It is still  

possible that there is an  inaccuracy in the C64 
emulation or 1541 disk emulation that will cause 
some  software to fail and I  

would be happy to inspect such software.
 
Q What fixes/Updates for HOXS are waiting for us in 
the immanent future?

A Updates for the future hope to include a better 
debugger, speed optimisation, tape seek and save. 
But these features are not  

immanent at present. The only thing that controls 
progress is how much time I have to spend.
 
QIs it planned to establish a HOXS-port on Linux or 
even MacOS Computers?
 
A No Linux or Mac port is planned largely due the 
fact I don't have Linux or Mac. My priorities are to 
improve the emulation  

accuracy and user accessibility to both gamers and 
programmers. 

Have a big "Thank You" for the interview!

Regards
David

Hoxs64 is a Commodore 64 direct X emulator written 
by David Horrocks with the help of documents written 
by the following  

people.

Many thanks to:
Christian Bauer for the VIC-II 6569 info.
Marko Makela for the CPU 6510 info.
Wolfgang Lorenz for the CIA 6526 info.
Ruud Baltissen for the floppy disk controller info.
 
==========

THE HEX FILES - PART 1
Written by Jason Kelk
 
A few people out there have expressed an interest in 
learning machine code. And after all, if you want to 
write successful  

games, demos or utilities it is the best language to 
learn, albeit a bit unfriendly. The main problem with 
machine code is its  

simplicity. There, I bet that confused you a bit eh? 
What I mean is that almost anything can be done in a 
single BASIC command  

can take a bit more work in machine language but at 
a greatly increased speed.

Right, that's the intro over with so lets start looking at 
some commands. The first one I've decided to 
explain is RTS. RTS is short  

for ReTurn from Subroutine and its job in life is just 
like the BASIC return command. 

So why am I explaining it first? Well, if you just use it 
without subroutines it also acts like the end command 
and for the  

purposes of this course we will be using RTS to finish 
our code. So why does it have such a short name? 
That's due to the  

fact that all assembly language commands are only 
three letters long!
Now, if you were to just put the command RTS into 
an assembler and try to run it all that would happen is 
the "READY."  

message would come up. Dull, huh? 

For the next bit I need to explain a bit about the 
workings of the C64; imagine in your mind for a 
moment a long line of little boxes  

and that each box has a number on it from 0 to 
65,535. A good example is box number 1,024 which 
controls the character at  

the top left of the screen.

If you type POKE1024,1 and press return the letter A 
appears at the top left of the C64's display over 
whatever happened to be  

there. All of these boxes can hold a number from 0 to 
255 (a byte). In the same way, box 53,280 controls 
the border colour of  

the screen so for example POKE53280,4 will put 
colour four into the border making it go purple.

But to do this in machine code is a little more 
complex. First off, all numbers are stored in hex, 
which is base 16. We all count in  

base 10 (mainly due to that being the number of 
fingers most of us have to count with) but base 16 is 
a little more tricky. You  

count to 9 as normal, but instead of saying 10 you 
use the letter A.

Similarly you would use B to represent 11, C for 12 
and so on until F (which is 15) when you would finally 
use 10 (pronounced  

"one zero" or "one oh"). But in hex 10 is 16 which 
would be incredibly confusing so from here on any 
hex number will have a  

dollar sign in front of it to say which base its in, for 
example $64.

So why do we have to use hex? The benefits will 
become apparent later on but as it's a good habit to 
think in hex we will start  

now to get everybody used to the idea and move on 
to our next two commands, which are Load Decimal 
Accumulator, or LDA  

for short, and STore Accumulator, STA to its friends. 
LDA is machine code's equivalent of a cross between 
the LET and PEEK  

commands, so LDA #$04 is the same as LET A=4. 
But LDA can also be used for reading the contents of 
those little memory  

boxes we discussed earlier, so if we were to use LDA 
$C000 

we would be putting whatever was in location $C000 
(box 49,152) into A. The use of the # tells our C64 
that we are giving it a  

direct number to put into A and without the # the C64 
will read what is in box 4 in the memory instead.STA 
is the reverse, it can  

put whatever is in A back into a memory box. So STA 
will put whatever A contains into box $0400 (or 
1,024, which is the top 
left of the screen remember?). A good example 
would be:

		

lda #$04		
sta $d020
		rts

Basically this is the same as the "POKE53280,4" 
command we saw earlier and shows you what I 
meant by the simplicity. One  

simple BASIC command takes two in machine code 
for this particular job and each step has to be 
followed. Now an example of  

the second version of LDA:

		lda $d021
		sta $d020
		rts

Now this is slightly different. The first command reads 
from 53,281 (the screen colour, which is normally 
dark blue) and then  

the second puts that colour into 53,280 (the border 
colour again) so basically this will turn the border the 
same colour as the  

screen! So this is the same as 
POKE53280,PEEK(53281).

BASIC programmers will be wondering why we are 
always using A and not another letter for the variable. 
The reason is that A  

is not just a variable in this context, its the 
Accumulator. But we do have two other letters 
available and they are X and Y,  

known technically as the X and Y registers. Both can 
be used in a similar way to A in that:

		ldx #$04
		stx $d020
		rts
 
Will do the same thing as the first example and 
replacing LDX with LDY and STX with STY will also 
work. The X and Y do have  

a couple of different features which will be covered in 
detail later, but one incredibly useful thing they can 
do is add or subtract  

1 from their contents in a flash! This trick is done with 
the INX and DEX commands for the X register and 
INY and DEY for the Y.  

So how do we use them? Time for another example 
methinks:

		ldx #$04
		dex
		stx $d020
		rts
 
This looks similar to the previous example, but the 
result of running it would be to make the border turn 
cyan! What actually  

happens is that first X is given the number 4 to look 
after. Then we tell it to go down by 1 with the DEX 
command leaving it with  

3. Finally X is told to put it's number into the border 
colour but because it only holds a 3 now the colour is 
different. I bet you  

can't guess which colour 3 makes!

INX will have the reverse effect to DEX so replacing 
one with the other in the above example will cause X 
to end up holding a 5  

so this time the border would be dark green. The Y 
register is exactly the same, so replacing all of the 
references to X with Y in  

the example will still work and produce the exact 
same result.That's all for this first instalment, but if 
you want to head on to the  

next part I'll show you what to do with an 
accumulator, two registers and an old washing up 
liquid bottle. If you have any  

questions about this article or machine code, email 
me and I'll do the business with the shooters. Erm, try 
to help

Continues Next Issue

Written by Jason Kelk   (Published with Permission)
http://www.oldschool-gaming.com/

========== 

Commodore Free Article entitled
"Bits and Pieces"
Written over a 2 month period
 

     Hi everyone, here is Luke Lynde again with 
another article. In keeping with tradition, I am typing 
this article on a Real C64  

using Mini Office 2 - saving it directly to D64 disk 
image, and then converting it to PC text (.txt) using 
the Printer Emulation in  

WinVice! That way, I make it easy on Nigel ;) So 
while the text is authentic and real,  the rest of the 
process involves the PC!  

Yes, PC is very handy for all the fake stuff... 

     Anyway, I like to do my typing this way more 
preferably! This article is about anything C64 that 
comes to mind, because so  

often when writing about C64, I say to myself "I 
should have talked about that in article." So, this text 
here, is about things I  

forget to talk about -which will be included here, as I 
give a bit of time (a month and more) for updated 
ideas and brainstorming  

to come through, before you see the finished product 
- as you will be reading it (now) upon
completion.

     First thing I would consider a great idea would be 
like a portable MP3  player that plays SID files. That 
would be the ultimate  

music hardware for me. Imagine walking around the 
streets with a miniature device that contains over 
33000 SID tunes. It  

would be great. It's funny, because I read somewhere 
(forget where) about someone playing SID music, 
and everyone around  

them thinking their mobile phone is ringing.

     Before my latest phone, it would happen to me all 
the time, because I guess the SID chip has that basic 
kind of sound like a  

telephone ring now and again! SID music as a 
ringtone, that sounds a good idea, and  it is even 
being done now. Even some  

CD's I have, sometimes make me  think the phone is 
ringing. It was funny reading that comment, because
it is so true. I think the composer Smalltown Boy 
made that remark somewhere. Oh, Randall!

     Next, I really wonder about EBay. If you don't 
know, it is an Internet  auction site. In Australia, you 
usually pick up a C64  

keyboard and Power Supply for around $25AU. 
That's pretty good, sometimes you get it for less than 
that - postage ends up  

being around $15AU. Whenever a C64 system is 
advertised with a disk drive, it goes above $100AU. I
can't understand this crap, because disk drives are 
so unreliable. I don't know how to service them, so I 
am more than happy  

with my 1541 emulation PC system. 

     There are also rare odd C64 hardware that goes 
for over $100AU, once again - ridiculous as far as I 
am concerned. I think  

there is a level people reach when they become 
"fanatical" about it all, whether it be C64 or even 
something like religion. Let's  

face it, C64 hardware is not going to last forever - 
and due to it's age, it should get cheaper and 
cheaper every year. It is not a  

collectable like antiques - computers have never 
been classified as a collectable in the strict antique 
sense of the word.

  


   I think C64 is a hobby for most of us. Enough about 
all that, I love C64. I am not saying C64 is crap, I just 
say that from antique  

collector theories - electronics are not really included. 
Excluding antique references, it is still up to debate 
how collectable  

electronics are - if at all. I tell people I collect C64 
stuff, but I think it would be erroneous to say they are 
collectors items
themselves. I mean, a piece of furniture from the 
1800's is a different thing entirely!

     The C64 is a great computer, that I will always 
love. Not because of people in the scene, as alot of 
them are rude and  

abusive towards others. Because of the games and 
magazine publications? Certainly. The nostalgia 
plays a big part in it all too,  

when you grow up with something - sometimes you 
never want to let that something go. The scene? Well 
I hate the arrogance  

of recent disk magazines, for sure, and people who 
think they are in control of everything C64 and 
pretend to be God. The  

scene is something that evolved over the decades, 
bring a mixture of joy and irritation to all involved.

     Joystix? Yes, I did a PDF mag also, it is available 
for download from  CSDB. There are 2 issues, the 
first issue was a really  

bad rush job -  but the text was okay. In Issue 2 I 
made sure everything looked nice and aligned, and 
that the screenshots were  

with better palette, etc. I  like black text on a grey 
background. Issue 2 was simple in design, but more 
polished than Issue 1.  

Issue 3? I don't know about that, I think I will do it, 
but... I need Inspiration, and until then, I will leave it 
for a while. If more people  

download Issue 2, I will do another one - if not, what 
is the point? Ho, hum.

     C64 emulation on the PC is pretty good at the 
moment, I guess. But you can never compare it to 
real C64. I wrote an article  

on Emulation in Commodore Free #4. Obviously an 
Emulator is not using the real hardware of a C64, so 
it is only going to reach  

a certain level - and it can go no further. I still use PC 
Emulators, as most do, even  though I have some 
real C64's. Comparing an  

Emulator to the Real thing, might be like comparing a 
cheap copy of the Mona Lisa painting  to the original. 
In some ways it may  

look the same, but the final product and outcome is 
different.

     Commodore Free on a .d64 file? Yes, and even 
compatible with 64hdd - because of no fast load 
routines. So read this mag  

also on a Real C64!  Good work, Nigel! I hope the 
readers of this Commodore Free Publication find it as 
a breath of fresh air, in  

the wilderness  comprised of many different aromas. 
My first and major thoughts about
Commodore Free PDF is: this is informative and well 
presented, I hope it continues on and on! As you may 
know, there aren't  

many modern English PDFs dedicated to 
Commodore?Anyway, this is the end for now, I will 
catch you around in another article  

some time. CUL8R SK8R H8R! zzz

Thanks Luke Regard Commodore Free

==========
 
DiskImagery64
A drag & drop Disk Image Editor for Commodore 64 
D64 Images
  
Written by Christian Vogelgsang
under the GNU Public License V2
Official Page is: http://www.lallafa.de/blog 
(DiskImagery64 Page)
 

Introduction
If you are a C64-addict then you usually like to setup 
own disk images with new software or with new 
arrangements of  

existing collections. I often use the
great "c1541" command line tool of VICE, 
(www.viceteam.org) to create and modify disk 
images on my Mac. Working this way  

gets cumbersome if you arrange new images from a 
large collection of other images or if you want to 
hand-craft an image with  

many files from different sources. For this task I
wrote DiskImagery64...

DiskImagery64 is a GUI application that allows to 
quickly view and edit alarge set of disk images and 
allows to copy or move  

files by simple dragging
them from one image to the other. Furthermore, a file 
browser allows access to your local file system and 
from there you can  

also drag files to an image and
vice versa.

Installation
DiskImagery64 is written with the portable Qt-library 
(www.trolltech.com) and is open source under the 
GNU Public License  

V2. You can either download the
source code or a compiled binary. The source 
compiles on all Qt-platforms:Mac, Linux/Unix with 
X11, and Windows. Simply call  

"qmake" and "make" in the source tree to build it. 
Make sure to use at least Version 4.2.x of Qt.

For the low-level disk image I/O DiskImagery64 uses 
the "diskimage" library written by Per Olofsson. For 
your convenience the  

source code is included in
this source distribution, but you can also find the 
source with documentation on Per's official 
"diskimage"-Page:  

http://www.paradroid.net/diskimage/
diskimage - D64/D71/D81 library Copyright (c) 2003-
2006, Per Olofsson  All rights reserved.

Fonts
For authentic reproduction of file names in disk 
images, DiskImagery64 uses two fonts: CBM and 
CBMShift for the unshifted and  

shifted commodore char set.In this distribution you 
find both of them as scalable TrueType fonts. 
Installthem on your system  

before running DiskImagery64.

Mac users simply double-click on the CBM.dfont and 
CBMShift.dfont files andselect "Install" in the Font 
Manager to install them  

on their systems. Windows
and Linux users can use the provided CBM.ttf and 
CBMShift.ttf files.

The fonts were not created totally by myself. I had a 
scalable commodoreTrueType font lying around on 
on my hard disk and I  

used it as a starting
point. The existing font told me its origins in the 
header: based on a font byDevin D. Cook with fixes 
from Chris McBride.

I loaded this font in the great free font editor 
FontForge(http://fontforge.sf.net/) and started fixing it 
again: I wanted a one-to-one
petscii mapping and that was not present. 
Furthermore, this requires to have



two fonts: one for unshifted and one for the shifted 
commodore char set. I created the two new fonts 
CBM and CBMShift with  

a "Unicode" TrueType mapping but with each petscii 
character at the correct hex position. The characters 
were copied from  

the other TrueType font and missing characters were 
drawn bymyself.  I hope the mapping of all petscii 
characters is correct  

now. For reference Ihave provided the editable Font 
Forge font (*.sfd) files in the "fonts" directory. If you 
find any errors then  

please send me your fixes!

The fonts are NOT suitable to use them as a 
replacement for any other unicodefont as the 
embedded mapping is called unicode  

but petscii actually. Nevertheless, they are perfectly 
suited to directly print petscii strings.

Usage
1. Startup
There are several ways to launch DiskImagery64:
 
 - Double-click on the application icon
 - Double-click on a *.d64 image file (on Macs)
 - Drag a *.d64 image file onto the application icon

If DiskImagery64 is launched with a disk image then 
an Image Browser windowopens and shows the 
directory of the image. If  

no image is given then the
File Browser window opens.

2. Image Browser
An Image Browser windows shows the contents of a 
disk images. You can open as many image browsers 
as you like. You  

can create a new disk image with the "File/New 
Image" menu command. A new and empty image 
browser is opened. The new  

disk image is empty and has a default disk name and 
id. 

"File/Open Image" opens a new image browser with 
an already existing image.

You can change the disk name and id by formatting 
the image with the"Tools/Format Disk" command. 
Enter a new disk name  

and id in the dialog.
This will also erase all files on the disk.

A disk image is altered by copying files from and to 
the directory shown inthe corresponding image 
browser. Simply select one  

or more files in one disk
image and drag-and-drop them to another image. It is 
also possible to drag files from the File Browser to 
the image. Then a local  

file is copied onto the image.

Files on a disk image can be altered with the 
common "Cut", "Copy", "Paste"and "Delete" 
commands found in the "Edit" menu.  

First select one or more ofthem and issue a 
command.

If a disk image is modified the changes are at first 
only performed in memory.You need to save your 
image to disk to make the  

changes permanently. Eitherselect "File/Save" to 
save the image with the already given name or 
use"File/Save as..." to save a  

copy or a currently unsaved image.

"File/Close" closes the current image browser. The 
image is not automatically saved onto disk in this 
case. The applications  

warns you if you want to close
an unsaved image. If the last browser in 
DiskImagery64 is closed then the application quits.

3. File Browser
The File Browser shows you a directory of your 
machine's file system. Thebrowser is used as a drag 
source or a drop target  

if you want to move local
files to or from a disk image.

You can browse your file system by opening and 
closing the tree hierarchy shown in the browser. 
Furthermore, the root of the  

shown file tree can be
entered in the top line edit field. Simply enter a valid 
path there and press enter. Additionally, a click on 
the directory icon lets  

you select the root directory in a file dialog.

Select a single or multiple files in the file browser and 
drag them onto adisk image to copy them there. The 
file names are  

automatically converted from
Unicode to Petscii. Additionally, known extensions 
like ".prg", ".del", ...are automatically stripped for the 
Petscii name and  

converted into the corresponding CBM file type.

The transfer of files from a disk image to the local file 
system works similar: Simply select one or more files 
in the image  

browser and drag them onto a directory in the file 
browser. Again, the file names are converted 
automatically and the CBM file  

type is added as a file extension. Invalid characters 
(":","/","\") are automatically stripped from the name.

4. Tools
The Tools Menu offers some tools while working with 
a disk image. "Format Image" allows to completely 
format the virtual disk.  

Enter the new name and
disk id.

"Add Separator" is used to add a separator special 
file to the current disk image. A separator file is 
usually empty and only  

used in the directory listing to separate entries or to 
group application files. The Add Separatorcommand 
has already some  

predefined separator styles available, but you can
design your own separator (see Preferences).

5. Emulator
DiskImagery64 allows to call your favorite C64 
Emulator to mount an opened image. Use the 
preferences to setup your  

emulator. The "Mount Image" command 
mounts/attaches the disk image to a virtual drive in 
your emulator and launches the  

program.

"Run Program" allows to run the selected disk entry 
inside your emulator. Make sure to have a single 
program selected. The  

emulator is run and the disk image name and file 
name on the disk image is passed as arguments.

6. Networking
DiskImagery64 can directly work with a real 
Commodore 64 if its connected via ethernet. For the 
C64 a popular network  

adapter is the RR-Net, a 10 MBit NIC mounted on the 
Retro-Replay cartidge (available from Individual 
Computers
http://ami.ga) which is an Action Replay clone.

To set up your network, I suggest to use a cross-
cable to directly connect the C=64 to your Mac. This 
avoids traffic from other  

sources that can disturb the
good old 8-bitter. Furthermore, The Final Replay 
ROM (short: TFR) image is
required to use CodeNet or NetDrive features 
described below. The ROM is suitable for the Retro-
Replay and available at  

http://www.oxyron.de/html/freplay.html. Setup the 
correct IP addresses for the C64 and your Mac in the 
ROM with the deliverd  

tool and flash the image on your cartidge. Finally 
store both IP addresses in DiskImagery64's 
preferences and you are ready to  

go! The following network services are available in 
DiskImagery64:

* CodeNet: Press F6 on the C64 with TFR running to 
enter CodeNet mode. In this  mode the C64 waits for 
instructions from the  

network. You can fill memory, download data directly 
to C64 memory, jump to memory or run a program. 
This is all implemented  

in DiskImagery64 but currently only used to 
download a PRG and run it.

  In DiskImager64 simply select a program file in a 
disk image or a local file and select "Network/Run 
Program". The file is  

downloaded in a second and run on the real 
machine. This works only for one-filers as loading 
other files is not supported in  

this mode.

* NetDrive: TFR allows to access a "virtual" IEC 
network drive on device id 6. So a "LOAD "$",6" on 
your C64 will load the  

directory from the network
drive. In DiskImagery64 you can create a network 
drive from every disk image or selection of files (also 
local ones) by selecting  

"Network/Share Files in
NetDrive".

  The NetDrive allows to use multi-file-programs as a 
program can load data files from the virtual device 
later on. The program  

must only use the kernal load routines (no fastloader, 
custom load routines...) as the NetDrive works on 
kernal level and is  

bypassed by custom routines. Kernal loading is often  
required nowadays (e.g. on IDE64, Dreamload on 
MMC64,...), so many  

multi-file progs are already available in patched 
versions.

* WarpCopy64 support 
(http://www.oxyron.de/html/wc64.html). WC64 is a 
server  program running on the C64 and a client on  

a host (PC/Mac). Now you can  control your C64-
attached real disk drives (e.g. 1541) directly via 
network  from your Mac. You  

can format a disk, verify a disk, send direct DOS 
commands to the drive and of course copy disk 
images in both directions. You  

can then directly transfer a real disk into a disk image 
in DiskImagery64 or a disk image back onto a real 
disk. A slow (most IEC  

compatible) mode taking
several minutes per side and a warp mode only 
taking tens of seconds is available.

  First of all enter CodeNet by pressing F6 in TFR. 
"Network/WarpCopy64/Start  WarpCopy" now 
transfers the WC64 server  

program to your C64 and launches it.  Make sure to 
have the correct IP adresses selected in preferences! 
You can  pick  

"Network/WarpCopy64/Read Disk" to transfer a real 
disk into a disk  image of DiskImagery64. If you have 
a disk image opened  

then the "Network/WarpCopy64/Write Disk" 
command is available and transfers the image  
directly onto a real disk.

==========
 
"New Games on C64"
 
     Hi here is Luke Lynde with a look at some fairly 
recent game releases for the C64. Some suprising 
titles here, I mean - who  

can ever say the C64 is dead and buried? Here we 
go...

Bomberman C64
Coder+Gfx: Skull, Music: CRD.

     Well, when I noticed this PRG on a disk image I 
downloaded from the net - I really did not expect it to 
be this good at all. I  

have in the past played Bomberman on the NES, and 
it is a game I find quite addictive - but also equally 
frustrating. This new  

Commodore 64 version from Samar Productions is 
absolutely brilliant. The graphics are some of the best 
you will ever see in a  

C64 game. The title screen  is professional and 
polished, with nice music+graphix - and a scrolltext 
from Jammer.

     While playing the game, even though I am no big 
fan of the Bomberman series - this is perfectly 
playable in all aspects, I  

have yet to find any flaws with anything about this 
game. I still struggle to get past the second level, 
though. Now I realise why  

I dislike Bomberman on the NES! However, I will 
continue playing it - because it is on the computer 
that I adore, and it looks and  

plays like something that maybe nobody thought the 
Commodore 64 could do, as well as this.

     Playability: 93%
     Graphics: 94%
     Sound: 91%
     Addictiveness: 92%
     Lastability: 90%
     Overall: 96% [Gold Medal!]

Beam
Code: Skate, Gfx+Msx: Hydrogen.

     Well this is a simple type of idea, I have not really 
seen implemented in a game before. You must 
balance a ball on a type of  

beam, while hitting another ball with your bat which is 
situated a top of the beam. Sound simple? Well it 
requires some major  

type of reflexes and patience to be become proficient 
at it. The idea is simple, and it works well.

     So, there is not much to this game. It gets very 
frustrating, when a game can be over in a matter of 
seconds, but  

perseverance pays off.
  
   You have 3 balls to start, and there is a continuous 
high score feature - which will change the better you 
get. The initial  

design reminds me of a pinball screen layout, but 
different. I use the joystick in port 2, but apparently 
you can use a mouse with  

this game, nice.

     Playability: 65%
     Graphics: 78%
     Sound: 88%
     Addictiveness: 81%
     Lastability: 82%
     Overall: 80%


Deep Sea Salvage 2
Code etc: Richard Bayliss/TND

     I really can't see the point of releasing games like 
this, ad infinitum, like Richard does. The only thing 
you could compare it to,  

would be like: Frogger underwater - but without even 
the slightest rudimentary game concept to make it 
even slightly  

interesting.  Basically, collect treasure from the 
bottom of the ocean while avoiding the fish. Advance 
a level after collecting a  

certain amount of treasure.

     This game is so bad it would not even be good for 
a young child to learn computer and other skills, by 
playing it. The music is  

okay, but   like all Richard's games appear the same, 
so does the sound of his tunes.

     Playability: 50%
     Graphics: 60%
     Sound: 45%
     Addictiveness: 5%
     Lastability: 1%
     Overall: 10%


Greenrunner
Code etc: Aleksi Eeben

     A molested centipede game with minter-esque 
effects. This game is for the Game Over(view) 
freestyle jam competition, and  

features 100 levels
of frenetic and bizarre blasting mayhem - 
unparalleled in any game I have played before. On 
initial inspection, I expected this  

game to be downright terrible. After playing it, I was 
filled with an excitement that I rarely experience 
playing a video game.

     The sounds are very atmospheric, extremely 
suited to the game ? and the voice samples are 
awesome. The gameplay is  

fast and addictive, and
there is enough variety to add that extra polish. The 
variety of colors are okay, but on some C64's they 
may not look so good -  

on mine they are fine. This is the type of game you 
can play, and will play again, and again. It is a 
brilliant little game, and comes  

highly recommended.

     Playability: 92%
     Graphics: 82%
     Sound: 94%
     Addictiveness: 91%
     Lastability: 90%
     Overall: 90% [Sizzler!]

     Well that's it for now, I hope you enjoyed reading 
about some new releases on C64. As suprised as I 
was with  

Greenrunner, you could have  knocked me over with 
a feather when I loaded up Bomberman. It's 
moments like these, that  

keeps my motivation to report to the world my C64 
findings - and contribute to the C64 world at large. By 
the way, my reviews  

don't contain implicit reference about the game 
details, it's up to you to discover them. I provide an 
introuction, the middle and  

ending is up to you. Enjoy!
 
==========
 
Interview with commodore128.org Lance
By Commodore Free magazine

 
Q Lance could you introduce yourself formally to our  
readers

A Lance Lyon, most of your readers would be aware 
of me from comp.sys.cbm & within the wider C= 
community over the last  

20 odd years

Q where do you live

A Katoomba, in the Blue Mountains, 110km west of 
Sydney, NSW, Australia

Q Are you a Commodore Free reader :-)

A Yes 

Q How did you get into Commodore machines

A In 1978 my parents "decided" (read: I beat them 
into submission with my non-stop begging!) to buy 
me a computer & wanted  

to get me a TRS-80, we 
Were using Exidy Sorcerors in school & I wanted one 
of those, so they visited Sydney & couldn't get either 
the Radio Shack or  

Exidy machine & bought a PET 2001 instead. (I still 
want a Sorceror though......)

Q Do you still actively use Commodore machines

A Yes, my 128D & my original PET (still chugging 
along) & my Amiga 1200. I also have a Commodore 
PC-5 (XT compatible) that  

is used a little as  well (my original BBS machine).

Q what machines do you own

A part from those mentioned above, several C64's 
(not used, just stored) A couple of Plus4's, a several 
C16's, two VIC20's, 3  

Amiga 600's, 5 Amiga 1000's, several Commodore 
PC clones, various contemporary PC's & a whole 
plethora of other classic  

computers (mostly stored). No Spectrums 
though ;-)

Q are there any active commodore 128 hackers

A Nothing like exists for the C64 scene, but there are 
a few coming out of the woodwork on the forum, so 
the scene is starting  

to get a (somewhat belated) boost

Q Tell our reader about your website

A In simplest terms, a "one stop shop" for all things 
Commodore 128

Q When was the site created

A The forums went online in July 2006,  
www.commodore128.org went  online in October 
2006, however the site is an  

outgrowth of my BBs that has been online since 
1987, so it has a pretty long pedigree

Q Why Commodore 128 what is so special 

A There are a plethora of sites for the C64 & even 
though there are a few 128 related sites, there are no 
specific community  

(forum) sites, I felt it  was way past time that the 
machine had a "proper" community site. As for what's 
special about the  

machine, well, IMHO it's the best 8 bit machine from 
any company & 
is the penultimate 8 bit Commodore (I don't count the 
unreleased C65 as it was never finished). Add to that 
that the 128 has  

been underexposed & underutilised for so long, it's 
way beyond the time when it needed its own 
dedicated site
Q "what did Commodore do wrong"

A My opinion ? several things, getting rid of Jack 
Tramiel was the first big mistake, introducing the 264 
line was another mistake,  

next mistake was producing the 128 & crippling it by 
including 64 mode & then continuing  to produce the 
64; that should have  

been canned once the 128D was  released. And they 
dropped the ball big time with the Amiga - they had 
the most technically  

superior 16 bit computer of the time - even compared 
to the Mac - and they lost their lead, AGA was too 
little, too late. In   

markets like here in Australia they had a huge lead 
over every other company,  even their PC line was 
selling better than other  

"name' brands, they threw  away an enormous 
amount of goodwill

Q What Commercial games were released 

A Not many - Infocom had a few; Beyond Zork, A 
Mind Forever Voyaging, Bureaucracy & Trinity; then 
of course there were  

The Last V8, Thai  Boxing,
Kickstart II & The rocky horror picture Show - 
conversions all, but  with Kickstart II (as an example) 
you could see that had more  

games been released, they would have been 
superior to the C64 offerings. In that  game there 
were 27 courses compared to  

the 8 offered in the 64 version. Elite 128 was another 
that sticks out too

Q I suppose the 128`s main advantage was 
backward  compatibility with  the Commodore 64 I 
also think this  was its draw  

back as many programmers  just made Commodore 
64 versions never utilising the full 128`s  power do 
you  think
this was the case

A Absolutely, see my earlier comment about C64 
compatibility

Q What is the 128`s killer application

A That's a hard one, GEOS 128 springs to mind (80 
column mode), and practically any of the 80 column 
business software  

(Timeworks was always a favourite label of mine)

Q Although the retro scene seems fixated on the C64 
are there any new titles in development for the 128

A In development? Well, probably not, but one of the 
things that I've noticed since starting the site is that 
people are starting to  

program the 128 after having been in hiatus for many 
years, one of our members for example was spurred 
to re-write VICE's  

2MHz mode, plus with the coding comp we're 
currently running (small to start with), I'm hoping that 
people 
Will start developing for the machine. Remember that 
anything the the C64 can do the 128 can do twice as 
well & twice as fast  

too! <grin>

Q Thanks for your time is there anything you would  
like to add

A I'd like to thank the core group of my members who 
have put an enormous amount of their own time & 
effort into growing the  

site. Also, keep up 
The excellent work with the mag!


cheers, Lance


// http://www.commodore128.org
Commodore 128 forums & more! //
 

==========
 
 
introduction to the c128
The Commodore 128 (aka C128) was Commodore 
Business Machines final  8 bit computer (the C65 
doesn't count as it was  

never completed & never commercially released). 
Introduced at the January 1985 CES, it was the 
follow-up to the Commodore  

64 & was a vastly expanded & more poweful 
successor to that computer.

The C128 features :
CP/M mode via a secondary Zilog Z80 CPU in 40 & 
80 column modes
Enhanced & faster 6510 (the 8502) running at 2MHz 
Native 40 & 80 column modes in two speeds (1 & 
2Mhz) 
Near 100% compatible C64 mode 
Basic 7.0 - more poweful & flexible than the limited 
C64's Basic 2.0 
Numeric keypad 
Burst mode disk access 

128k of RAM with more available for programmers 
due to an MMU 

The 128 was released in three models - the first 
looked like the a larger 64C (& the design was 
repeated in the later Amiga 500,  

600 & 1200) - the "flat" 128. The second model was a 
rather nifty plastic box with a carry handle & slide in 
keyboard that  

allowed the machine to become a "luggable" (the 
128D) & the last model was the metal cased cost-
reduced variant (the  

128DCR). The 128DCR also came with a 64k VDC 
as opposed to the earlier models 16k chip (they could 
be retrofiited).

Although the computer sold in excess of two million 
units during its lifespan, native software was thin on 
the ground due to the  

included 64 mode - developers didn't bother creating 
software that took adantage of the native modes. 
However, there are  

several fine business packages produced for the 80 
column mode & due to the CP/M compatibility (& it's 
ability to handle multiple  

CP/M disk formats) a large library of software was 
available right from the start.

about our site AND Mission statement :
To provide an active & vibrant community devoted to 
keeping the Commodore 128 alive (hence the name 
of the site) into the  

future. 

To gather together in one place as much relevant 
material as possible & to provide a "one stop shop" 
for the C128 community. 

To foster a friendly & sharing Commodore 128 
community.

To provide accurate information & discussions about 
the Commodore 128.

To promote an active development scene for the 
Commodore 128.

To preserve & distribute Commodore 128 related 
software, manuals & code.

And above all - to have a good time while we're doing 
it!

Commodore 128 hardware information
The C128's hardware basically remained the same 
across all three models. It consisted of :

128kb of RAM (externally expandable via an REU) 
8563 VDC chip driving the 80 column RGB display 
with either 16k of RAM or 64k of RAm in later models 
(& easily retro-fitted) -  

in the 128DCR this was replaced with an 8568

VT-100 style keyboard with a numeric keypad 
8502 CPU - an expanded 6502 which could run in 
either 1MHz mode or 2MHz mode (the 40 column 
screen turned off at the  

higher speed) 
Secondary Zilog Z80 CPU that controlled the startup 
of the computer & allowed it to run CP/M in either 40 
or 80 column mode.  

Although this was a 4MHz chip, it was constrained to 
2MHz due to the requirements of interfacing with the 
8502

A reset button 

MMU bank switching chip 
In the two later models, the keyboard was detachable 
The 128D models also contained a built in 1571 disk 
drive 
2 KB 4-bit dedicated color RAM for the VIC-II E 
MOS 8580 SID chip for sound - this was the cost 
reduced version, earlier 128's had the 6581 SId as 
used in the C64

RGBI video output allowing the computer to connect 
to a standard CGA monitor but with an additional 
monochrome composite  

signal as well

There are three basic models of the Commodore 128 

The original "flat" version, broadly similar in looks to 
the 64C, Amiga 500, 600 & 1200. This model came 
equipped with the 16k  

VDC & had no internal disk drive.  

The Commodore 128D was an attempt to produce a 
more "business-like"  looking  PC and was in a low 
profile plastic box with  

an internal 1571, stowable keyboard & a retractable 
handle that made the computer a luggable. It still had 
the 16k VDC. This PC  

also had an internal fan.

The Commodore 128DCR was the final version 
released. The CR stood for "cost reduced". This 
release came in a sturdy metal  

case, dispensed with the fan, had a reduced number 
of chip components & had the 64k VDC.

Text Reprinted from the website
http://www.commodore128.org/index.html

==========
 
Commodore Preservation Project
http://rittwage.com/c64pp 

Welcome to the Commodore 64 (C64) Preservation 
Project The main goal of this project is to archive 
pristine versions of original  

Commodore 64 software, including copy protection. 
A secondary goal will benefit of this will be to catalog 
and document all the  

different copy protection methods used. This 
information will be used to improve emulation, as well 
as remastering software  

onto disks for you to enjoy on the real thing. These 
goals are much like that of C.A.P.S. project for the 
Amiga. Of course, to  

reach these goals, we need your help. This software 
exists only on magnetic media from the 1980's, and 
as such has been  

disappearing into attics, yard sales, and landfills for 
almost 20 years. Floppy disks were also never made 
to last a lifetime, as I  

have found in purchasing them in auctions. Even 
disks that were stored and cared for by their owners 
all these years have  

pretty high failure rate, some where the magnetic 
material actually wipes right off, making the drive 
heads filthy. You can help  

preserve them for our own and future generations in 
a number of ways. 

* If you have a 1541 or 1571 disk drive and a XEP, 
XAP, or XMP cable (serial/parallel combination), we 
can send you the latest  

mastering software. You can then send us the 
resulting image and statistical data for analysis and 
inclusion in the archive. 

* We will happily pay for postage to get any original 
disks you have to us! We will promptly image them 
and send them back to  

you. 

* If you don't have the cabling or don't wish to send 
us your originals, you can make us nibbled copies of 
the originals by  

whatever the best means you have and send us 
those. We will pay for postage, as well as return 
these disks to you, of  

course. We can sometimes reconstruct the protection 
onto the image by looking at what it checks for, plus 
they can be used to  

verify the original image if nothing else. 

Copy Protection Methods 
Many different protection methods were developed 
over the years in a cat-and-mouse game with those 
that wanted to make a  

copy of their own (or a friend's) disk. The methods 
steadily increased in complexity, but whether or not 
the protection was 
copyable or not, a way was always found to make a 
working backup. Descriptions of the drive hardware 
itself, as well as  

many of the methods that different companies 
employed to keep the disks from being copied are 
found here.
-----------------------------------------------------------------------
Background

The Commodore 1541 disk drive is a stand-alone 
computer that talks to the C64 through a somewhat 
slow serial port. It is  

based on similar technology to the C64 itself, 
employing a 6502 CPU, two 6522 VIA I/O chips, and 
only 2k of memory (the  

limitation of which will be discussed later). It came 
with either an 
Alps or a Newtronics 5.25" double-density floppy 
mechanism, both of which are functionally equivalent. 
This mechanism  

requires double-density 48 track-per-inch 5.25" 
magnetically-coated Mylar disks.

Tracks
Tracks on the disk are organized as concentric 
circles, and the drive's stepper motor can stop at 84 



different locations (tracks) on a disk. However, the 
read/write head on the drive is too wide to use each 
one separately, so  

every other track is skipped for a total of 42 
theoretical tracks. The common terminology for the 
step in between each track is a  

"half-track" and a specific track would be referred to 
as (for example) "35.5" instead of the actual track 
(which would be 71).  

Commodore limited use to only the first 35 tracks in 
their standard DOS, but commercial software isn't 
limited by this. Most  

floppy media is rated to use 40 tracks, and the drives 
usually have no trouble reading out to track 41, 
although some will bump  

and not get past 40. Most software does not use any 
track past 35 except for copy protection, but 
alternative DOS systems like  

Speed-DOS used all 40 tracks in it's own DOS 
implementation.

CBM drives have no way in hardware to detect which 
track it is on, or where it is on any particular track. 
The software must  

handle these functions which leads to many of the 
more creative styles of copy protection. 5.25" disks 
contain an "index hole"  

which is the little hole you see diagonal to the hub 
ring on your disks. If you spin the disk around in it's 
shell, you'll see that there  

is a hole in that, too. Other drive manufacturers used 
an optical sensor to detect when this hole passed by, 
which would signal  

the start of a track. Commodore didn't implement this, 
so we have to use marks that are written to the disk 
during formatting.  

Later copy protection implementations took 
advantage of this because the devices used to 
master original software are not  

typically a 1541. They could master the disk using 
the index hole so it was lined up perfectly. As far as 
knowing which track  

we are on, the only way to tell is again in software. 
Each sector on a track has a header that contains 
(among other things) it's  

track number. DOS will read this whenever it needs 
to access a track so it knows how many times to step 
the motor to get  

there. The famous "drive-knock" is the software hack 
that Commodore employed to reset the drive to track 
0 when we couldn't  

find any sectors. In this case, the motor is stepped 
out as far as it can go until it physically stops 
(causing the knocking noise)  

which guarantees it's at track 0. Unfortunately, this 
behavior is what is blamed for the terrible drive 
alignment problems of the  

early mechanisms.

Sectoring
Tracks are further divided into sectors, which are 
sections of each track divided by the forementioned 
software-generated  

sync marks. The drive motor spins at 300rpm and 
can store data at 4 different bit densities (essentially 
4 different clock speed  

rates of the read/write hardware). The different 
densities are needed because being round and the 
motor running at a constant  

speed, the disk surface travels over the head at 
different speeds depending on whether the drive is 
accessing the outermost  

or innermost tracks. Since the surface is moving 
faster on the outermost tracks, they can store more 
data, so they use the  

highest density setting. Consequently, the innermost 
tracks use the slowest density setting. Because it's 
recording at a higher  

density, of course more sectors are stored on the 
outer tracks, and fewer on the inner tracks. There is 
nothing stopping the  

hardware from reading/writing at the highest density 
across the entire disk surface, but it isn't generally 
done due to media  

reliabilty, and slight speed differences between 
drives. The media itself is only rated for a certain 
bitrate at a certain speed.

Drive Internals
The drive head, at it's lowest level, can only detect 
and create polarity changes in the magnetic flux on 
the surface of the disk,  

which is interpreted by the drive as a binary 0 (no 
change) or a 1 (flux polarity change). Because of the 
specifics of the  

hardware used to access this magnetic flux, the bits 
stored on the disk have a couple of limitations (or 
"features"). This flux  

detection circuit feeds dual 4-bit "shifters" which 
convert the bits (detected from the flux changes) into 
a whole byte (8 bits),  

much like a serial port does. If this circuit detects ten 
'1' bits in a row, it knows that it has read a "sync". 
This sync is what tells  

the software that it's about to get a series of bytes 
representing either a sector header or sector data 
right after the sync ends.  

An anomaly of this circuit is that it if it runs across 
three or more '0' bits in a row, it will clock in an extra 
'1' bit on each 4-bit  

shifter that doesn't really exist on the disk. When this 
happens, the track loses framing, meaning the data 
is bitshifted after this  

due to our new phantom bit. It will shift a new 
phantom '1' into the LSB once in a while (and wrap it 
around) according to drive  

speed and other environmental factors until the next 
real '1' bit is seen. This data is "random" in the sense 
that the data is never  

the same twice due to drive speed (and humidity, 
temperature) fluctuations. A good example is when 
you try to read a new,  

unformatted disk. If you try this, you'll get "random" 
data caused by this anomaly in the drive hardware 
because there are no  

flux changes on a blank disk. To the 1541 hardware, 
this is all '0' bits. Because of this weakness of the 
hardware, all data is  

stored on the disk in an encoding system called 
"GCR". This encoding assures that there will never 
be more than two '0' or '1'  

bits in a row in the data itself. This "feature" of the '0' 
bits is of course taken advantage of in some later 
copy protection  

schemes. (Rapidlok, Mindscape, and Datasoft, for 
example) ;)

Differences between a "fast copier" and a "nibbler"
Copy programs have been referred to by these two 
different types since the first nibblers came out on the 
Apple II. A little more  

background is required in how the disk is structured 
to explain the difference. A track is broken up into a 
number or sectors,  

which are further broken up into a header and data 
portion, and each of these has a filler "gap" at the 
end to give the drive  

software time to change modes. The actual GCR 
data is structured like this:  SYNC (at least 10 bits of 
'1' in a row)  header0 (8  

bytes in DOS)  header gap (usually 5 filler bytes, 
longer for nibbled copies)  SYNC  sector data 0 
(CBM DOS uses 260 bytes)   

tail gap (usually 5 filler bytes, longer for nibbled 
copies)  SYNC  header1... (and on until the end of 
the track) 

Fast copiers
A "fast copier" reads the source disk on a sector-by-
sector, normal CBM DOS level, and recreates them 
onto a new formatted  

disk. This method produces a "clean" copy of the 
disk, but does not copy any protection since it will 
ignore any sectors with  

errors, or any sectors that don't conform to the format 
explained above. It was really only used when we 
weren't going to try  

to copy the disk protection, but rather apply a 
"parameter" to the disk. A "parameter" is nothing 
more than a patch program that  

was run on the backup disk to remove the check for 
copy protection. Fast Hack'em, Kracker Jax, and later 
Maverick were all  

very popular copy programs that utilized parameters. 
Nibblers
A "nibbler" works at a lower level and will duplicate 
the actual headers and data, whether or not they are 
in CBM DOS format. It  

does have limitations, though. First, they don't 
duplicate the header or tail gaps or the original sync 
length, but rather creates it's  

own, so protections that hide in the gaps or count 
sync lengths won't be duplicated. Secondly, the drive 
only only has 2k of  

RAM, but a whole track is up to 8k, so it must be 
broken down and read in several passes, then 
stitched together on the  

destination disk. Protections that exploited this would 
use a sector or track larger than would fit in RAM at 
once, making it  

impossible to copy. Later, there were hardware 
solutions to this, such as extra drive RAM and 
parallel ports. 
-----------------------------------------------------------------------
Protection Methods

Intentional Disk Errors
This protection consists of a disk error purposefully 
placed on a sector or an entire track, then it's 
existence is checked for in  

the program. If the error isn't found, it's knows it's a 
copy. In the beginning, there were no copy programs 
except Jim  

Butterfield's "COPY/ALL" that came on the 1541 
test/demo disk. This program could not reproduce 
these errors (and even if it  

could, it took *FOREVER* to copy even regular 
disks). Like most protection, though, it only foiled 
casual copiers. Early, clever  

crackers figured out how to scan an original disk for 
these and the methods for recreating the errors were 
not difficult. Soon  

after, programs like "Copy II/64" came out that could 
effortlessly detect and reproduce these errors which 
marked the end of  

this era. Most publishers of disk software used this 
method before late 1984.

Fat Tracks
This protection involves placing a track on the disk 
that is actually 2 tracks (4 half-tracks) wide. This has 
two effects.

1) The second track is invalid because Commodore 
DOS stores the track number as part of the track 
header, which is now for  

the wrong (previous) track.

2) The tracks are perfectly aligned on the disk since 
they were written at the same time.

The protection is checked by the program by 
stepping the head up and down between these 2 
tracks and the halftrack  

between them while reading the whole time. 
Normally, a half-track will contain a garbled 
combination of it's neighboring tracks.  

However, since these two tracks are now identical, 
this track should contain the same data as both of it's 
neighbors. If it  

doesn't, it knows it's a copy. Electronic Arts used this 
protection from about 1984-1985 and Activision used 
a tougher variant of  

it called "XEMAG 2.0" for many years. These 
protections stand out from most of the early 
protections because they could *not*  

be copied 100% reliably even with *any* nibbler. As 
mentioned earlier, the 1541 has no way to know 
where it is on a track.  

Therefore, it has no way to know where it is in 
comparison to any other tracks on the disk. For this 
reason, it is impossible to  

reliably write these tracks out perfectly aligned with a 
1541 drive. This was an idea that was greatly 
expanded on in future  

protections, but it still stands the test of time and still 
can't be duplicated reliably with the best copiers that 
ever existed. It is of  

note that it *is* possible to "unreliably" copy these, as 
you can just try over and over again copying just 
these two tracks until  

you happen upon "close enough" alignment for it to 
work. The EA protection in particular relies less on 
the exact track  

alignment, so it is less difficult to copy this way. 
NOTE: Slowing your disk drive motor down to 
298.5rpm or less seems to allow  

you to load a copy of any fat-track protected disk 
remastered with MNIB.

Half Tracks
Along the same vein as fat-tracks, it was of course 
possible to read and write to the usually skipped 
"half-tracks" instead of  

the normal tracks, if you weren't worried about storing 
any data on the normal tracks. This foiled many 
copiers because they  

didn't search for and copy these half-tracks by 
default, so they instead got garbled, invalid mixes of 
the "real" data when trying  

to read the tracks as if they were normal. Copiers 
later came out that could scan for and detect these 
and copy them properly. I  

have not yet run into any disks which are known to 
use halftracks.

Extra Tracks
This protection simply relies on using disk tracks 
beyond 35. Normally, copy programs default to 
copying only tracks 1-35, so  

these are missed. I am not sure why the 
programmers didn't extend this by default, except 
maybe some would lock up reading  

unformatted tracks, which these tracks usually are. 
Sometimes these tracks contained actual DOS-
formatted data, but usually  

they were just "key" tracks, or the second part of a 
"fat" track from track 35. They could sometimes be 
nibbled, other times they  

could not, because they were combined with other 
protections.

Changed Bitrates
As mentioned above, the bitrate is normally higher on 
the outer tracks and lower on the inner tracks. Some 
disks were  

protected by using a non-standard bitrate on different 
tracks. Copiers later came out that would scan for the 
correct density  

and these disks could be copied that way. 

Header and Tail Gaps
As mentioned above, when a disk is copied with 
either a fast copier or a nibbler, the gap data is not 
copied directly. Copiers  

would commonly just fill this space with 0x55 bytes. 
Gaps are "inert" bytes, meaning they aren't normally 
used as data, but just  

a space filler that is ignored by DOS. There are some 
protections that check for specific bytes here, or even 
the length of the  

gaps, and know they're a copy if it's different. This 
protection can be copied with hardware solutions that 
either extend the  

RAM in the drive to 8k or add a parallel port so it can 
read and write the entire track in one pass.

Long Sectors
As mentioned above, the drive has only 2k and can't 
fit an entire track in RAM, so it must be broken down 
into 4 parts and  

stitched together on the destination disk. If you make 
a sector longer than will fit in RAM, it can't be copied 
with a normal 1541.  

This can be copied with hardware solutions that 
either extend the RAM in the drive to 8k or add a 
parallel port so it can read  

and write the entire track in one pass. 

Custom Formats
These usually depend on the long sectors trick above 
to be successful, but they also entail changing the 
way that GCR is  

interpreted in a custom DOS. If you write your own 
DOS, you can use your own disk format entirely, 
ignoring common sync,  

gap, header, and data conventions altogether and 
use whatever you want. You only have to adhere to 
the hardware limitations  

of sync and no more than two '0' bits in a row, but 
even that didn't stop later innovations. :)   
Long Tracks
Normal drives spin at ~300rpm and can "write" data 
at the highest density up to about 7700 bytes per disk 
track. However, the  

drive can "read" more than that, within some margin 
of error depending on motor speed. Some protection 
took advantage of this  

and put more data on the track than could be written 
back out at the normal speed, making it difficult to 
copy. Some copiers  

would "trim" the data in as non-destructive way as 
possble (reducing sync length and gaps) and it was 
also possible to slow  

down the disk drive to foil this, but usually these disk 
relied on a combination of other protections as well. 
A good example of  

this is Harald Seeley's "V-MAX!". 

Sync Counting
A sync mark must be at least ten'1' bits long to signal 
the drive hardware that it's about to see GCR data. 
However, sync marks  

are usally much longer than this (40 bits) and have 
no limit to their length. When copying a disk with a 
software nibbler, sync  

has to be reproduced rather than copied, since it is 
more like a "signal" than actual data stored on the 
disk exactly. For this  

reason, the length of a sync is also somewhat 
dependent on drive speed and will vary a little. Some 
protections count on this  

and measure the lengths of the sync, or the 
occurances of sync on a track, to see if they match, 
and know they're a copy if  

they don't. Microprose used this method on some 
disks, and in fact "trimming" the sync will fail the 
protection checks. 

Track Synchronization
We mentioned above that the drive doesn't use the 
index hole, so lining up the tracks on the disk is 
nearly impossible on the  

1541. Since disks weren't usually mastered with a 
1541, but rather with machines that could do track 
sync based on the index  

hole, protections took advantage of this in different 
ways. They would move to a halftrack or the next 
track in the middle of  

reading to see if the data that should be there exists. 
If it doesn't, it knows it's a copy. 

Weak Bits/Unformatted
We mentioned before that if the drive gets more than 
two '0' bits in a row, it clocks in a random '1' bit 
occasionally. Single  

occurances of this sequence won't always make it 
lose framing, it will return a "random" byte, but more 
than a couple in a row  

will result in the drive losing framing and reading 
these "random" bytes until it sees the next real '1' bit. 
Most nibblers can't  

duplicate this, so protections checked a byte 
purposefully on the disk somewhere and if it reads 
the same thing over and over,  

it knows it's a copy. Later copy programs did try to 
reproduce this-- Burst Nibbler detects and writes a 
0x01 byte in their place,  

which is enough to fool most software into working. It 
is also worth noting that this is the same thing as 
unformatted tracks, so  

you'll see this a lot when imaging in new disks. Since 
the disks aren't usually duplicated on a 1541, and the 
tracks aren't always  

as long as they could be, the machine leaves 
unformatted data on the end of all the tracks, causing 
a lot of software to appear  

to have these on every track, and making it difficult to 
verify the tracks from disk to disk, since the bytes will 
be different from  

sample to sample. I have several disks from Synapse 
that have unformatted parts on all the tracks, and 
none of the tracks  

above 25 are formatted at all! I've seen this used in 
Rapidlok (all titles), later Microprose disks, and 
Datasoft (Bruce Lee, The  

Goonies, Mr. Do!) 

Signature (key) Tracks
This protection is seen from time to time and revolves 
around a track being mastered in a non-standard 
way. It can be all sync  

'1' bits (which we call a 'sync-killer' track), 
unformatted (or all '0' bits), filled completely with 
some other byte, or filled a special  

byte sequence like EA's PirateSlayer, or a 
combination of all of them. These tracks generally foil 
most all copy programs  

because they either cannot handle all or long 
sequences of '1' or all '0' bits, or they are just read 
incorrectly/out of framing. We  

can remaster most all of these with our development 
version of 'mnib'. ;) 

No SYNC
The meanest protection that came about used tracks 
on the disk that had *no* sync marks. Most copiers 
cannot read these  

tracks and most times think they're empty. The later 
Vorpal uses this. We believe there is a way to find 
the track cycle in these  

and reproduce them, as Maverick had custom 
copiers for these titles. It needs disassembled and 
examined. 
-----------------------------------------------------------------------
Frequently Asked Questions
Q: Where do I download the games from?
A. You can get back images for games you have 
contributed, games for which can be proven you own 
the originals, or games  

that the publisher has said can be redistributed. We 
cannot legally redistribute the games, as we are not 
the copyright holder.  

Most of the games we have preserved already have 
existed on the internet in other forms for over a 
decade, but still we  

cannot open up any sort of legal implications. 

Q: How do I use the images I get back?
A. The images are in "NIB" format. This format 
contains a little more information about the media 
than a G64 file does that helps  

the remastering process. In most cases, the image 
can be converted to G64 and either VICE or CCS64 
will run them. There are  

some tougher protections that won't run due to the 
inexact way 1541 emulators work. There are also 
some images that work  

on the emulator that can't be put back on a real disk.

Q: What equipment and/or cables do I need to dump 
my disks?
A. You need a 1541, 1541-II, or 1571 disk drive and 
an XAP1541, XEP1541, or XMP1541 cable. This 
cable has both the  

standard IEC connector as well as the direct parallel 
connection to the VIA chip inside your disk drive. You 
can build them  

yourself using the guides on Joe Forster's Pages or 
purchase them from his shop. Note with the latter 
that you still have to  

solder in the parallel cables to the VIA chip inside 
your drive, but the cables are top quality and you'll 
save a lot of time.

Q: You already have all the games I own in your 
database. Should I bother to redump them? 
A. Yes! There are many different reasons.

* Not all disks even with the same publisher, region, 
and disk label have the same protection. The disk we 
have might be a  

different version, from a different region, from a 
different mastering run, or from an alternative 
publisher (like a budget release).  

The disk we have might even be bad and we don't 
know it yet.

* Commodore's checksum for DOS sectors is not 
strong (it's a simple rolling XOR) and prone to flag a 
sector as good when it is  

not, and heavily protected disks are even worse 
since they don't even have these checksums. This 
can happen on old disks  

that have deteriorated and caused some of the bits to 
go "weak". The only way we have to verify that an 
image is "good" is to  

compare it to other dumps of the same exact game. 
We are working on a tool to create CRC32 
checksums of just the actual  

data on the disk without regard to sync, gaps, and 
weak runs. This will help verify and compare images 
going forward.
-----------------------------------------------------------------------
MNIB Development
MNIB - Commodore 1541/1571 disk image nibbler
(C) 2004-07 Peter Rittwage, Markus Brenner, and 
friends (C) 2000-04 Markus Brenner.
-----------------------------------------------------------------------
1/7/2007 - Released version 0.45.1  Added halftrack 
support as the default behavior for NB2 images. 
-----------------------------------------------------------------------
1/7/2007 - Released version 0.45  Added support for 
new NB2 format, specified by extension. (i.e. 'mnib 
test.nb2') This format  

contains 16 samples of each track, 4 at each 
possible density. Processing tools are forthcoming.  
Noticed the new writing tool  

'pwrite' was missing from the web distribution. This 
has been added to the binary releases.  Density and 
'killer' track detection  

has been improved/changed. (again) Interactive 
mode should be working 100% now. Command line 
interface to this is clunky,  

but functional. Allows 9 second backups. :) 
-----------------------------------------------------------------------
The C64PP project originally started when I took 
Markus Brenner's GPL source for MNIB and figured 
out how to add a routine to  

make it write the disk images back out to real disks. 
This part turned out to be easy, but I opened up a 
can of worms that has  

taken lots of time to perfect. :) Since then, I have 
actively developed the program, adding in various 
routines to handle foreign  

disk formats and protections, as well as improving 
the read routines and conversion tools. At this point, 
we can read and  

reproduce pretty much any disk that was/is possible 
with 1541 drive hardware. Most converted 
protections will work in the  

emulators as well, with a few exceptions. I have been 
handing out the test versions over time to 
contributors (of time, advice,  

disks, and images) and at this point it is pretty stable. 
Markus as well as many other people from around 
the world have kindly  

contributed their time and expertise to expand this 
into a powerful tool. I would never have gotten out of 
DOS and into  

Windows/Linux without Tim Schurmann, Nate 
Lawson, and Spiro Trikaliotis.
-----------------------------------------------------------------------
The latest sources are always available via 
anonymous CVS and can be fetched with CYGWIN 
as follows: set  

CVSROOT=:pserver:anonymous@rittwage.com:/root
cvs login (password is 'mnib') mkdir mnib36 cvs 
checkout mnib36
-----------------------------------------------------------------------
Special thanks for code, bug reports, and 
suggestions: Tim Schurmann, Spiro Trikaliotis, Nate 
Lawson, Jerry Kurtz, Matt  

Larsen, Mat Allen (Mayhem/UK), Wolfgang Moser 
(Womo), Quader, Jani, Curt Coder, Roger Cousin, 
Christian Hedemann,  

Steppe, Victor Castro (and many more I'm sure I've 
forgotten...) 
-----------------------------------------------------------------------
The MNIB DOS version contains code originally 
based on CBM4Linux from these authors:
Michael Klein, Andreas Boose 

All content copyright (c) 1971-2061 by Peter 
Rittwage. All programs mentioned are copyrighted by 
their respective owners

Text reprinted with thanks from the website with the 
Permission of Peter Rittwage
 
==========

Interview with Pete Rittwage
C64 Preservation Project
 
Q -  Please Introduce yourself to our Reader, Where 
do you live, What do you do for a living

A - I am a Senior Network Engineer from Augusta, 
Georgia, USA that grew up in the 8-bit computing era 
during the reign of the  

Commodore 64. My original goal was probably that of 
a lot of retro users.

 I wanted to recollect all the games I had for the C64 
when I was a kid, which for most part were games 
that I either copied (or  

later cracked) from friends in the Northeastern Ohio 
(USA) area.  

It always bothered me when I got a copy of a game 
where the text was edited with silly "BROKEN BY" or 
"CRACKED BY"  

phrases, so I would always remove them and put 
back the original text. Later, we were inundated with 
the "intro demo" which  

usually saw the loss of the title screens and original 
loading graphics. I sought to remove those as well.

 From there it expanded into collecting original disks. 
After  discovering Markus Brenner's MNIB project, I 
decided it was better  

to just try to collect all the games as they were 
originally distributed. That way you avoid any errors 
or missed protection  

checks that the 'cracker' left behind. This opened up 
into the can of worms you see in the software  and on 
the site today.

Q - What introduced you to Commodore

A - I received a Vic-20 for my birthday in 1983 or so.  
After the C64 came out, then VIC was marked down 
to less than $100,  

so my parents were able to afford to get me one.  I 
had no tape drive for about 6 months until I got one 
for Christmas. During  

that time, I would type in programs from magazines 
and debug all my typos, which is how I learned 
programming.  

But of course when the computer was turned off, they 
were gone.  :( I purchased a C64, 1541, and 1525 in 
1985 or so (used)  

from a friend of  my parents who was "upgrading" to 
an IBM PC.  I moved to Georgia a couple  of years 
later, sold all my C64  

equipment, then bought an Amiga 500 in  about 
1988.  Later (1991) I went to work for a Commodore 
dealer and was surprised  

how many people still used the C64.  I had a almost 
a full time job repairing them for a year or two.

Q - What Commdore machines do you own

A - Pretty much anything they made that was in color.  
VIC-20, C16, a couple of +4's, an original badge 
breadbox (S/N 25000 or  

so), many rainbow badge
64's, a pristine SX-64, a couple 64C's, a couple 
128's, Amiga 600, Amiga1200, Amiga 1000, a couple 
of Amiga 500's, a dozen  

or so 1541's, 1571's, and 1541-II's.  I have plenty of 
parts to last my whole life.
And a couple thousand original disks at this point, 
about 1/3 with boxes. Nothing sealed, of course.  :)

Q - where did Commodore go wrong

A - Well, I worked for a CBM dealer when they went 
under, and the owner of the store owned CBM stock 
(and actually went  

to the last stockholder meeting in
the Bahamas).  It became clear that the leadership at 
CBM did not want to invest the money in becoming a 



mainstream computer company in the 90's. So they 
just drained what they could until it collapsed.  I could 
write a whole essay on their mistakes, but this was 
the ultimate downfall in the end.

Q - Commodore Preservation Society - please tell 
our reader the main aim of this website

A - To collect and document all floppy disks released 
for Commodore computers. 

Q - I have printed the FAQ file from the site but you
must receive some really dumb questions can you
Enlighten us

A - Actually, you'd be surprised.  Most people that still 
use C64's or play as a hobby are quite computer 
literate, so I don't get  

many dumb questions at all.

Q - would it ever be possible to recreate a duplicate 
disk from a Nib Copy

A - Most images, yes, you already can.  Some won't 
work due to the limitations of the drive hardware, but 
some of that can be  

worked around.  Probably 
97% of images can be remastered without problems.

Q - Please tell our reader about the process and the
NIB copy format

A - The NIB "format" is really nothing more than 
about a cycle and a half of raw GCR data as it's seen 
passing over the drive  

heads on each track. The parallel connection inside 
the drive sends this GCR data out in real time to the 
PC which stores it in  

this simple file format.  

This file is then analyzed, the track cycles are 
determined, and then converted to G64 (or D64 if 
appropriate) for use in  

emulation.  I usually briefly analyze the copy 
protection (manually) and make note of it.  I then use 
other tools I've written to  

compare the data to other known images of the same 
title to see if it's unique in some way.

Q - What will happen to the game copies if the 
website closes

A - There are many contributors to the project that 
have backup copies of everything, so if I disappear 
hopefully someone will  

carry the torch.

Q - How can our reader help your project

If you have any original disks and have access to the 
hardware to read  them (XAP, XMP, or XEP combo 
cable) then feel free to  

contact me to  contribute
images.  If you don't have the hardware, then you 
can send the disks to me or other project members 
that may be in a country  

nearer to you.  I can even pay for postage both ways, 
if you wish.

Q - Do you copy the documentation and disk covers?

No, but there is a site called "The SixtyFour Originals 
Database" that does this.  It's too much for me to 
handle all of that too, so  

it's good to have different projects.

Q - What about tape preservation or have you 
deliberately left this to others

A - There are a couple of other projects doing this as 
well.  Tapes aren't plentiful in the USA (most software 
was on disk here)  

so I leave that  to people with more expertise in tape 
preservation.

Q - What is the worst copy protection scheme you 
have come across and has any scheme had you 
unable to produce a disk  

copy

A -Big Five's "Bounty Bob Strikes Back" is written in a 
format like "Spiradisk" (from the Apple II).  1/2 of 
each track is written,  

and the head bumped 1/2 a track in the middle, then 
repeated again and again 
For about 12 tracks.  This is very difficult to copy or 
write back out because of timing issues.  No copy 
program ever  

succeeded in making an exact
duplicate (without cracking it).  

There is a special copy program for the SuperCard+ 
that is supposed to work, but we've tried it on two 
different originals with  

3 different drives and never gotten it to produce a 
working copy. The other very difficult ones are mostly 
due to track skew.   

On the 1541,there is no way to accurately align 
tracks to one another without adding an index hole 
sensor. 

 Some protections (like Rapidlok) check timing 
between certain patterns on neighboring tracks and 
fail if they are even a bit off  

For this reason, these games don't completely work 
in emulators, as they don't yet emulate track skew or 
exact stepper motor  

timings. Long tracks, such as those used in V-MAX 
or the newer Vorpal-protected disks (like California 
Games, etc) are no  

problem for emulators, but The disk drive motor must 
be slowed way down to fit all the data on the disk 
when remastering  

them.

Q - So where does it go from here, is this just to
Continue collecting disk images

A - That's pretty much it.  Nobody knows how many 
games were released on disk for the 64, so we'll 
never know when we're  

done.  We're about to reach
about 2,000 unique titles, and there are about 3500 
disk sides that make up those titles. 

 Also, there are many games which were released in 
different versions, different regions (PAL/NTSC and 
language  

differences) as well as re-releases on budget labels, 
etc.  It's a big job.  I probably spend a between 3-10 
hours a week on it  

just going through images and disks trying to keep up 
with our kind contributors.

Q - Can a user create an image and send it to you for
the Database if so how would they create the images

You need a 1541 (preferably an original model as 
they are more  reliable), a PC (running DOS, 
Windows, or Linux) and an XAP,  

XMP, or XEP combo cable. This cable has the extra 
parallel connection soldered into the drive like the 
'Datel Burstnibbler' or '21  

Second Backup' used back in the old days.

Q - Many of the Commodore games can be 
downloaded from various sites, these are normally 
cracked with intros and cheats,  

although this does allow in many cases the games to 
be played with newer or extra hardware for example 
run from Cmd  

products, like hard disk and Ram - its nice to run the 
real version of the software, the problem is how long 
will my disk drive last  

constantly bumping the heads about,

A - Only the earliest copy protections that check for 
an intentional disk error have this problem.  The old 
original drive  

mechanism with the pull-down 
(as opposed to the twist-down) are less reliable and 
should be avoided for these earlier disks. 

 I've got a 1541 drive with the twist-down door  that 
I've used to read probably 10,000 images with and it 
still works fine,  so  

the hardware is pretty reliable if you have a good 
drive.  If it  breaks, though, there are plenty left 'in the 
wild' for years to come.  

 :)

Pete Rittwage
C64 Preservation Project
http://c64preservation.com

==========

Interview with Andrew Fisher
Freelance Writer Musician and Commodore 
Programmer  

Q. Please tell our readers a little about yourself.

A. My name is Andrew Fisher, I'm 32 and a freelance 
writer. I live in Cambridge, England.

Q. Tell our readers about your computer memories.

A. My earliest computer experiences would be 
playing games at a friend's house on his birthday, on 
his VIC-20 and BBC (he  

was a lucky kid). As we were living near Great 
Yarmouth at the time, I also started to play arcade 
machines like Gorf and Pole  

Position.

Q. When did you first receive your Commodore 
machine?

A. It was October 1985, in a package with two games 
and a Datasette. Sadly the powerpack was faulty, 
meaning it was  

several weeks before we got it back working and had 
the chance to play the games - Arcadia 64 (with 
dreadful flickering  

sprites, and it
took 18 minutes to load!) and 3D Time Trek (without 
a joystick). 

Q. What machines do you own?

A. I still have that original C64, a couple of C64C's 
and a C128. Plus a Spectrum +3, NES, SNES, N64, 
Gamecube, PS1, PS2,  

Xbox and a JAMMA arcade
cabinet. And a Gameboy Advance, Gameboy 
Advance SP and Nintendo DS Lite. As you can see I 
own quite a few machines... 

Q. Tell our readers about your writing work on 
magazines.

A. Well, back in 1993 I started  writing a technical 
column for  Commodore Force as "Professor  Brian 
Strain", or The Mighty  

Brian. That was a caricature based on a real photo of 
me. When Commodore Force closed, I wrote for its 
rival  Commodore  

Format for a few issues, mostly on GEOS and user 
groups. Then I spent most of the 1990's writing for 
fanzines like  

Commodore Scene, before Retro Gamer appeared... 

Q. You recently worked on Retro Gamer, tell our 
readers a little about the articles you wrote.

A. Well, the first one was sent in on spec, and printed 
so I guess you could say I was lucky! That was THE 
RETRO RYDER  

CUP, looking at golf games through the years. On a 
Commodore theme I wrote about cartridges and the 
Commodore 128. I  

contributed to a couple of other articles, and had 
more underway.



Q. Retro Gamer closed, were you left unpaid for 
some of the articles?

A. Yes, I was owed money for one article. 

Q. Did you look to recover your money? 

A. Administration is a difficult process (which I've 
unfortunately been dragged into several times with 
my magazine work) and  

there was no chance of the 
freelancers being paid back with the banks and other 
companies owed so much. Instead, the freelancers
got together to create the Retro Survival CD, 
featuring some of the articles that would have been in 
the

issue 19 that was never printed.  The readers were 
so enthusiastic, they pre-ordered enough to cover the
cost of getting the CD produced, so we have been 
able to pay money back to all the writers. If you are
interested in Retro Gamer and want to see some 
interesting articles, the CD (which is compatible with 
PC or Mac) is available  

from: www.retrosurvival.co.uk

Q. Retro Gamer was purchased by another 
publisher, have you written for this publisher?

A. Yes, Imagine Publishing stepped in with new 
editor Darran Jones taking the helm (he had 
previously worked on gamesTM's  

retro section). I had work in the first few issues ? 
interviews with Shaun Southern and Andrew Morris, 
plus C64 artist Stephen  

Robertson (known as SIR). Then there was my 
biggest article ever, a look back at the history of 
Gremlin Graphics. Hopefully I  

will have more in the
magazine soon.

Q. You work freelance, has this always been the 
case?

A. Yes, the freedom is quite nice but at the same 
time there are downsides - like not being paid, tight 
deadlines and trying to find  

an outlet for the work.

Q. If our readers wanted to break into writing for a 
career, what would you suggest?

A. The first step would be to write as much as you 
can - if you want to get into games reviews, find a 
website that is looking  

for reviewers and volunteer.
(I'm currently writing reviews for a site called Console 
Obsession, for example.) Once you've built up a few
contacts like that and got some good feedback on 
what you write, try approaching editors with ideas.
Rejection is tough at first, but keep at it. The most 
important thing is to make sure you read a lot and 
write a lot; over time your  

work will get better.

 
Q. Do you have any favourite software?

A. In terms of games, my favourites on the C64 
include The Sentinel, Wizball, Paradroid, Impossible 
Mission and Pogo Joe. On  

other machines I tend
to play a lot of sports games, like the Tony Hawk 
series and American Football games. Just recently 
I've been hooked on the DS  

puzzle game Meteos, Nintendogs and the two Lego 
Star Wars games for Xbox. 

Q. Tell us about POL, how were you involved and 
what POL is?

A. People of Liberty is a group formed by Joerg 
Droege, a German C64 fan. He was looking for 
contacts to help him with his  

disk magazine and I
volunteered. It's amazing to think that is nearly seven 
years ago.

Q. Do you belong to other groups?

A. Yes, I've been a member of two other groups. I 
first joined the Irish group Ozone back in the
mid-90's and then released a lot of my own demos 
under that group. I was also invited to join ROLE
back in 2002/3, writing music and text for them. 

Q. You write music, is this all "SID" music?

A. Yes, the majority I have written has been on the 
C64. I used programmes like Dutch USA Team's 
Music Assembler,Cosine's  

Electronic Music System (EMS) and DMC v4 (Demo 
Music Creator).  I started out doing a lot of covers  
from sheet music, but  

then Warren Pilkington persuaded me to try writing 
my own. Over the last couple of years I've also done 
a bit of remixing on the  

PC, taking my SID tunes and turning them into music 
for Ovine by Design or releasing it on remix.kwed.org

Q. Can our readers listen to some of your music, and 
where would our reader need to look?

A. The vast majority of my SID tunes are in the High 
Voltage SID Collection at www.hvsc.c64.org. If you 
already have the latest  

update, it's at  /MUSICIANS/M/Merman  (in older 
editions it's at 
/VARIOUS/M-R/MERMAN). SIDPlay is one of the 
easiest ways to listen to it on PC or Mac. 
Alternatively, a lot of the tunes are at:  

http://www.geocities.com/andrewrfisher/
in my old website called "Merman's Kingdom"

Q. At http://c64goldenyears.com/ you have 
announced a book looking at gaming history, can you 
enlighten our readers?

A. This is actually a follow-up to a Spectrum book 
that was published in December 2006. I approached 
the author of that book,  

Andrew Rollings, the previous year about doing a 
Commodore 64 version and he agreed. But with 
2006 being a busy year for  

me, I didn't have the time to work on it. But a new 
year proved the perfect stimulus to get me to start it 
up again. The basic  

format of the book is that it is split into chapters each 
covering year (with smaller
chapters covering 1993-1994, and from 1995 
onwards). Each year has a short introduction and a 
famous loading screen from  

that year, before each
game gets a full page review with screenshots, trivia 
about the game or the programmer and a description 
of how it plays. With  

over 200 games chosen to be in it (and many 
favourites having to be left out to fit it all in) there is a 
lot of reading. 
Q. How would our reader order this book - when will 
it be available and what is the intended print run?

A. Pre-ordering can be done with PayPal or credit 
card via the website - http://c64goldenyears.com.
The current plan is to get the book finished and 
printed, ready for sale in summer 2007. Sorry I can't 
be more specific than that,  

because there are so many factors that will affect 
how long it takes. The final number to be printed has 
not been decided, but  

the nature of the book means it will be a limited 
amount. 

Q. Who is the publisher of this book and will it be 
available over the counter in our local book shop?

A. Publishing is being done by Hiive Books, set up by 
Andrew Rollings to print the Spectrum book. It won't 
be on general sale,  

but it will have an ISBN number allowing overseas 
readers to find it. (Printing is being done in the United 
States, and the books  

will be sent
from there).

Q. This is a follow-on book; would our readers need 
both books?

A. No, it will stand on its own as it is about 
Commodore games. The layout and look of the book 
will be broadly similar... but it  

will have better graphics and more shades of grey... 

Q. Do you have a sample page our readers could 
look at?

A. A couple of sample pages are currently available 
on the website, but those are very early previews and
Subject to change.

Q. Do you have any other projects in the pipeline? 

A. I'm doing more work on my website, 
www.seuckvault.co.uk I'm writing more stuff for Retro 
Gamer. And long term there  

could be more books, depending on how successful 
this one is.
 
Q. Any question you wished you had been asked? 

A. Hey, that's my question! Seriously, good luck with 
Commodore Free, and the only question I would like 
to have been asked is  

"Do you know someone who wants a million 
pounds?"

Commodore Free 
DOH guilty I pinched one of your questions ? I should 
be ashamed ? although Yes I could use the Million 
Pounds I think it would  

come in handy 

Q. Would you like to plug the book again to our 
readers - why should our readers purchase this 
book? 

A. If you are a Commodore 64 fan who wants to 
know more about the great games, discover games 
they may have missed, or  

find out some fascinating
trivia about the games and machines, then you need 
this book. Or even if you don't like games it's 
something you can pick up  

and flick through
When you're bored. 

Q. Thanks for your time. How does it feel to be on the 
opposite end of the interview? :-)

A. It makes a change to be answering the questions!
 
========== 
 
An Interview with Richard Joseph  
by Neil Carr
 

Defender Of the Crown, Antirad, Barbarian and more 
recently 11 tracks for a lego game. Although he 
follows a different lead  

with his company Audio Interactive he still writes 
music to this very day. Talking of music.. Keep an 
eye out for a remix of  

Barbarian which may feature in a future BIT Album 
by Richard himself. 

Real name: Richard Joseph 
Nationality: British 

Q What other c64 composers did you like?

A Martin Galway is still my favourite even now. 
Although Rob's was technically groundbreaking 
there's more emotion in Martin's  

stuff. Very musical.

Q What non Richard Joseph sids did you like?

A Knucklebusters - Rob H 
Martin Galway - Wizball (awesome music AND fx. 
The whole soundtrack is brilliant) 

Q What tune that you created were you most pleased 
with?

A It was an ending section for Antiriad that I decided 
to change to the piece you hear now. It was abstract 
and surreal and I felt  

that the reviewers and gamers alike would hate it. 
But I still love it. Also, there was a collection of great 
tunes written for a  

game called 'Monster Museum' which was never 
released. Annoying really, I was just starting to get 
good when the Amiga  

came along and we all had to change or lose our 
jobs.....

Q What were your likes/dislikes about the sid chip?

A I hated the fact that the filter was changed a 
number of times throughout various production runs 
of the hardware. This  

meant that we couldn't really use it at all. 

Q You created music for some of the best games on 
the c64, including Barbarian 1&2, Defender Of The 
Crown, Antiriad. How  

pleasing for you personally was it for you to be 
associated with these fine titles?

A I felt honoured. After the 64 I went on to work on 
very many top titles and I still feel honoured to work 
on them even now.

Q You worked mainly at the now no longer Palace 
software, could you explain that period to our 
readers?

A It was a very exciting time. We all knew we were 
doing something special and there was a real 
concentration of great talent.  

There were only a few games developers in those 
days and it was very cool to work for indie houses 
like Palace and System  

3. A lot of very high up names in the current games 
industry came from those studios originally. Palace 
was a part of the film  

company that made Evil Dead and Absolute 
Beginners so the emphasis was on cinematic games 
from the start. Palace liked  

getting publicity and one stunt was to feature Page 3 
girl Maria Whitaker as the Princess in Barbarian. I 



remember the uproar it all created in the tabloids. 
Brilliant. The Barbarian himself was of course a yet to 
be discovered Wolf out  

of Gladiators. 

Q Why did you start writing c64 music?



A It was the flagship format for the first game I did for 
Palace, Cauldron II. Out of the three we working on- 
Spectrum and  

Amstrad being the others- the C64 was by far the 
best to originate a soundtrack on. I never used it for 
anything but games  

work, but then the games stuff used to take up all of 
my time anyway.

Q How did you become involved in the games 
industry?

A I had spent many years working in the pop music 
industry and was writing for mainstream 
entertainment when I answered  

an advertisement in Melody Maker (sadly no longer 
with us) put in by Palace who were looking for a 
composer to work in  

games. Nothing unusual about that, but this was 
1986 of course and there weren't very many 
computer musicians around at  

that time. I'd just spent a year composing about 100 
tunes on a Yamaha CX5 music computer (including 
the 'famous' Robocod  

one), and had tinkered with a Spectrum so it wasn't 
that hard to convince Palace.

Q What are your thoughts on your music being re-
created using modern sounds?

A I?m always interested to hear other people?s 
interpretations but I don't believe that any of these, or 
remixes of other's stuff is  

neccessarily 'better' or 'improved' just because more 
modern sounds are used. I think ultimately it will be 
the original c64  

renditions that go down in history whatever remixes 
exist.

Q Have you heard any of these remixes/covers that 
has impressed you?

A Well they all have to some degree. I just like the 
fact that people are enjoying doing them, although I 
do wonder why- my own  

stuff doesn't exactly fit into the mainstream of 
remixable soundtracks being largely orchestral.

Q Is there a tune, you wished you could have worked 
more on?

A I only had a short time to do Cauldron II. There is a 
longer version but sadly it didn?t get finished quickly 
enough to make it to  

the game. I had just two weeks from booting up the 
c64 for the first time to delivering a finished tune and 
20 sound effects.

Q Probably your most remembered tunes were for 
Defender Of The Crown and Antiriad. Would you 
agree with this, and what  

can you tell our readers about these two sids?

A Antiriad was the second soundtrack after Cauldron 
II. I took the tune from something I'd written a year or 
so earlier on midi  

instruments and stuck a new bit on the end. As I said 
in another answer there was an alternative part B for 
Antiriad that never  

made it, and I still listen to it to this day and wonder 
what might have been.  Defender Of The Crown was 
more remote for me,  

as Cinemaware who developed it 
were based in the States. It was weird working that 
way but I really enjoyed it- the game itself is brilliant 
fun. 

Q What other formats have you worked on, and what 
was your preference/least preferred?

A
 Spectrum / Amstrad 464  / Amiga  / Atari ST  / Sega 
Megadrive / SNES / Gameboy  / GBC  / Playstation 
Playstation 2  / N64  /PC 

Favourite was Amiga. Bitmap Brothers, Sensible 
Software, those were cool times.  Least favourite was 
Megadrive. One of the  

most interesting moments was listening to Rob 
Hubbard's Megadrive conversion of my Robocod 
tunes! 

Q So I see you are still involved in the game music 
industry with Audio Interactive. Do you still write 
music for games, or do you  

follow a different lead now?

A I am more involved with the production of a game?s 
audio. There is so much material needed nowadays 
that I prefer to leave  

the specialized work, like writing Orchestral music for 
instance to experts in those particular fields. I did 
write 11 tunes for a  

Lego game last year but as a rule I don?t write as 
much. Probably more for myself in fact.  I've been 
working on an orchestral  

arrangement of Barbarian in the style of Ennio 
Morriconi, which is what I had aimed for in the c64 
version, and its turned out  

very well. If all goes well it could appear on a future 
Back In Time CD. 

Q What can you tell our readers about Audio 
Interactive?

A We do everything audio for games. We compose 
and record music, both linear and interactive. We 
design and implement  

sound effects. We do dialogue production, recording 
and processing. It sounds like a big industry but its 
not really. Its just the  

same as it was in c64 days but on a larger scale. If 
anything there was more pressure in those days, as 
every single sound  

was critical. These days we have the luxury of being 
able to use sampled sounds which makes the job an 
absolute doddle  

compared to the old times. 

Q If there was a tune that you wished you could as 
your own, what would it be and why?

A Probably Rob's Knucklebusters. The tune 
maintains the listeners interest for what, thirteen 
minutes? That's no mean  

achievement. 

Q What are your fondest memories of the c64?

A The day I booted it up for the first time, after 
bringing it back from Palace, and playing Beach 
Head and Impossible Mission  

with my girlfriend's kids (work it out.... yes I am very 
old!).

Q What has been your latest project?

A The latest project is Republic: The Revolution for 
Elixir Studios. The sound has lots to do including 
conveying the various  

atmospheres of a city at different times of day and 
night, with ever-changing orchestral /industrial film 
music to suit each action  

within the game. 

Q Your music on the c64 was generally more slanted 
towards the orchestral side rather than heavy drums 
and baselines. Was  

this due to the games you made music for or was this 
your style?

A This actually was quite a problem for me, with the 
SID only having very limited resources for recreating 
real instruments.  

Most of the early games I worked on needed the kind 
of ambitious soundtrack we are creating now.

Q What did you do after leaving Palace software?

A I went freelance and signed up to do games for 
The Bitmap Brothers, Sensible Software and 
Millennium. In 1995 I formed  

Audio Interactive and we picked up companies like 
Sony and EA. Last year we won a BAFTA Interactive 
award for best sound  

on Theme Park World. Another of our soundtracks, 
Codemasters' Cannon Fodder (GBC) was nominated 
for the same award.

Q How would you best prefer to be remembered?

A For the early stuff- not only the c64 but the Amiga 
soundtracks I did for Sensible and the Bitmaps. 
Nowadays I would say  

that Theme Park World is probably the best but I 
have higher hopes for Republic...

Q Have you ever considered Remixing or re-
arranging some of your old c64 sids into modern 
sounds?

A Yes, the Barbarian thing. Otherwise no, I like them 
the way they are.

Q How did you get your inspiration for the music for 
Defender Of the Crown?

A I don't think anything was an inspiration for DOTC. 
Palace just told me that another company wanted to 
use me and that there  

was some tie-in for them. In a lot of ways it was good 
to work on something, for a change, that wasn't 
'Palace' in feel.

Q What does the future hold for you and your music?

A I have no idea to be honest. There is a whole CD 
of music and mayhem from the ill-fated Sensible 
game Sex n Drugs n Rock n  

Roll that we are trying to place with a record 
company right now. It's quite wonderful really! I just 
don't want it put out as an  

mp3 yet- we must have spent nearly six years on it 
from start to finish and I want to get something out of 
it. As for the future,  

Jon Hare (ex Sensible) and I are creating a sequel to 
the SDRR CD but there is little pressure on us to 
complete it and neither of  

us have much time. If SDRR was a success then 
things would be different obviously.

Q Lastly, what would you like to say to the c64 
community?


A I would like to say that it's brilliant that there's a 
community at all. After the c64 disappeared into 
commercial history and the  

industry was pushing forward I just thought that 
everyone?s pioneering work would simply be 
forgotten. Not so! The  

appreciation of retro games and the people who 
made them is wonderful, as is the continued use of 
the machine and  

emulators, with remixes and CDs... wonderful. 

Richard always followed the orchestral side of 
music.. Which with 3 voices was as richard explained 
was very difficult.  

However he came out of it with flying colours, 
creating some of the most ambitous music on the 
c64. Palace software was a  

small player in the games market, but didn't they 
produce some fantastic games and who could forget 
the publicity campain for  

Barbarian where they pictured Maria Whittaker 
scantily clad. This caused a real stir amongst the 
press. This however must  

have been exactly what Palace had wanted. The 
Barbarian soundtrack was exceptionally fitting for the 
game too. Who could  

forget the move in Barbarian where the player could 
spin around and chop an enemies head right off in 
full gore. Wikid!!! 

- Neil
Interview date: 30.04.2001

Interview printed from 
http://www.remix64.com/interview_richard_joseph.ht
ml With Permission via email 

Subject: Re: Interview Reprint request 
    Hello Nigel,

yes, please go ahead.

Regards,
- Markus 



THE END
 


