User Tools

Site Tools

        __  __             ______
       |  ||__|  ______   /  __  \   ______   __  __   ______    ____   __  __
   ____|  | __  /  __  \ |  |  |__|_/  __  \ |  ||  | /  __  \  /    \ |  ||  |
  /  __ / ||  ||  |__|__||  | |____/  |  |  ||  ||  ||  |__|  ||  ||__||  ||  |
 |  |  |  ||  |`\____  \ |  | |____\  |  |  ||  ||  ||   _____||  |  W |  ||  |
 |  |__|  ||  ||  |__|  ||  |__|  ||  |__|  ||  ||  ||  |__|  ||  |  a |  ||  |
 `\_______||__|`\______/'`\______/'`\______/'`\____/'`\______/'| /'  D `\    /'
          _     _  _ __ ___ ____ ______________________________|/________|  |
           _     _  _ __ ___ ____ _________________________________________/'

             The   Journal   of   the   Commodore   Enthusiast

                      I s s u e  3  :  March 26, 1997

                             P R E A M B L E

Welcome to the third issue of disC=overy, the Journal of the Commodore
Enthusiast.  We greet you proudly, the ones who still hold the beloved
Commodore 8-bit machines in high regard and respect.  We thank you from
the bottom of our hearts and look forward to forging a solid productive
relationship with the C= 8-bit community.

  - Mike Gordillo, Steven Judd, Ernest Stokes, George Taylor, and the
    authors of disC=overy.

::::::::::::::::::::::T A B L E  O F  C O N T E N T S:::::::::::::::::::::::::

-Software Section-

/S01 - "Rommaging around : $A480-$A856"
$a480   by Stephen L. Judd

/S02 - "A Closer Look at the VIC II's Output"
$d000   by Adrian Gonzalez and George Taylor

/S03 - "Innovation in the 90s : Revisiting The Super Hi-Res Flexible Line
$d000    Interpretation Technique"
        by Roland Toegel, 'Count Zero', and George Taylor

/S04 - "Defeating Digital Corrosion (AKA "Cracking") - A beginner's guide
$dd00    to software archiving"
        by Jan Lund Thomsen

/S05 - "A possibility to be explored : Real Time Video with the Ram Expansion
$df00    Unit"
        by Nate Dannenberg

/S06 - "A look into 'The Fridge'"
$f00d   by Stephen L. Judd

/S07 - "C128 CP/M, trailblazer in a jungle of formats"
0100h   by Mike Gordillo

-Hardware Section-

/H01 - "The X-10 Powerhouse, What is it?"
        by Dan Barber

/H02 - "The Metal Shop"
        with 'XmikeX', David Wood, Marc-Jano Knopp and Daniel Krug

-Legal Section-

/L01 - Articles of Operation, Distribution, et al.

/S01::$A480:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::

Rommaging around : $A480-$A856
----------------              by
                                Stephen L. Judd  (
"Disassemble? ...Disassemble!!!" -- No. 5, 'Short Circuit'

        This series has a simple goal: to completely disassemble and document
the Commodore 64 ROMs.  There is a nice ROM disassembly available on the
internet, with the actual hex code displayed and HTML hypertexted.  This
version, on the other hand, is written in a more 'human readable' form,
heavily commented and labeled, and is intended to complement the other.
To that end, it does not duplicate very much information which is easily
obtainable elsewhere (, or Marko Makela's homepage, for instance).

        BLARG is a program which adds several hires graphics commands to BASIC,
and was the main motivation to finally get started on this project.  This
article will thus focus on the BASIC routines from $A480 (Main Loop) to 
$A856 (END), with a goal of understanding how to add new commands to BASIC.

        The first part of the article gives an overview of BASIC and its
internal workings, and sets up some of the things used later on.  The
second part discusses the parts of BASIC which relate specifically to
the disassembled ROM, with a focus on the vectored routines.  The third
part gives a brief overview of BLARG.  The ROM source, BLARG source,
and BLARG binaires are all included.  These files are all available at


        About the ROM listings: I did them up in Merlinesque format of
course.  Probably the only unfamiliar thing is the concept of global
and local lables.  Local labels are prefixed with a colon, and their
definition is only valid between two global lables.  Otherwise they
may be redefined.  Thus a piece of code like

        INC TEMP1


contains two global labels (PROC1 and PROC2).  PROC1 will branch to the RTS
instruction and PROC2 will branch to the DEC TEMP1 instruction, since the
:CONT label is redefined once the global label PROC2 appears.  The bottom line
is that if you see a branch to a local label, that label is nearby and
after the last global label.

BASIC overview

        Before starting, there are some important things to know about
BASIC.  When you type in a line of text, and hit [RETURN], that text
is entered into a text buffer located at $0200.  The text from this buffer
is then tokenized by the BASIC interpreter.  If it is an immediate mode
command (doesn't start with a line number) that command is then executed,
otherwise it is stored in memory as a BASIC program line.
        BASIC lines are stored in memory as follows:

      ______________________________   _______________________  ...__
     /                              \ /                       \      \
0 [link] [line #] [Basic line] [0] [link] [line #] [Basic] [0]  ...  [0] [0]
|    |       |          |       |     | 
|    |       |          |       |    Link to next line
|    |       |          |       | 
|    |       |          |      End of line marker
|    |       |          |
|    |       |     Tokenized line of basic program
|    |       |
|    |     Two byte (lo,hi) line number
|    |
|  Two byte (lo,hi) pointer to next line in program
Beginning of program

        A zero marks the beginning of the program, which normally begins
at $0800 (2048).  The next two bytes are the address in (lo,hi) form of
the next line in the program.  The following two bytes are the line
number for the current line.  Then the tokenized line of BASIC follows;
a null byte marks the end of the line.  The next line follows immediately.
A line link of value 0 (actually only the high byte needs to be 0) marks
the end of the program.
        Thus a program like

        10 PRINT "HELLO"

will in memory look like

2048    0               ;Zero byte at beginning
2049    15              ;Next link = $080F = 15+8*256 = 2063
2050    8
2051    10              ;Line number = 10 + 0*256 = 10
2052    0
2053    153             ;PRINT token
2054    32              ;space
2055    34      "       ;quote
2056    72      H       ;PETSCII string
2057    69      E
2058    76      L
2059    76      L
2060    79      O
2061    34      "
2062    0               ;end of line
2063    0               ;end of program
2064    0

        Variables begin immediately following the end of the program.
Strings are stored beginning at the top of memory ($9FFF) and work
their way downwards towards the variables.

        Another very important feature of BASIC is that the important
routines are vectored.  These are indeed filled vectors -- filled with
the address of the routines in question.  The BASIC indirect vector
table is located at $0300-$030B:

IERROR  $0300-$0301  Vector to print BASIC error message routine
IMAIN   $0302-$0303  Vector to main BASIC program loop
ICRNCH  $0304-$0305  Vector to CRUNCH routine (tokenize ASCII text)
IQPLOP  $0306-$0307  Vector to QPLOP routine (tokens -> ASCII)
IGONE   $0308-$0309  Vector to GONE, executes BASIC tokens
IEVAL   $030A-$030B  Vector to routine which evaluates single-term math

Calls to these routines are vectored through these addresses via an
indirect JMP -- they are called using JMP (IMAIN) for instance.  These
vectors may then be redirected to new routines, and so they provide
a smooth way of adding new keywords to BASIC.  CRUNCH is used to
tokenize lines of text when they are entered.  QPLOP is used by
LIST to print tokens to ASCII text.  GONE is used to execute tokens.
        Before modifying these vectors, keep in mind that many programs,
such as JiffyDOS, have already modified them!

        Finally, the routines CHRGET and CHRGOT are very important
in BASIC.  They are copied into zero page when the system first starts
up, and are located at $0073:

$73     CHRGET  INC TXTPTR      ;Increment low byte
$75             BNE CHRGOT
$77             INC TXTPTR+1    ;High byte if necessary
$79     CHRGOT  LDA             ;Entry here doesn't increment TXTPTR
$7A     TXTPTR  $0207           ;low byte, high byte -- the LDA operand.
                                ;Generally points at BASIC or points
                                ;at input buffer at $0200 when in
                                ;immediate mode.
$7C     POINTB  CMP #$3A        ;Set carry if > ASCII 9
$7E             BCS EXIT        ;Exit if not a numeral
$80             CMP #$20        ;Check for ASCII space
$82             BEQ CHRGET      ;...skip space and move to next char
$84             SEC
$85             SBC #$30        ;Digits 0-9 are ASCII $30-$39
$87             SEC
$88             SBC #$D0        ;Carry set if < ASCII 0 ($30)
$8A     EXIT    RTS

On exit, the accumulator contains the character that was read; Carry clear
means character is ASCII digit 0-9, Carry set otherwise; Zero set if
character is a statement terminator 0 or an ASCII colon ($3A), otherwise
zero clear.
        Wedge programs make this their entry point -- by redirecting
CHRGET and CHRGOT a program can look at the input and act accordingly.
Scanning text can get awfully slow, which is why most wedge programs you
see use a single character to prefix wedge commands.
        Finally, a list of BASIC tokens is a handy thing to have, along
with the address of the routine which executes the statement:

$80     END     43057 $A831
$81     FOR     42818 $A742
$82     NEXT    44318 $AD1E
$83     DATA    43256 $A8F8
$84     INPUT#  43941 $ABA5
$85     INPUT   43967 $ABBF
$86     DIM     45185 $B081
$87     READ    44038 $AC06
$88     LET     43429 $A9A5
$89     GOTO    43168 $A8A0
$8A     RUN     43121 $A871
$8B     IF      43304 $A928
$8C     RESTORE 43037 $A81D
$8D     GOSUB   43139 $A883
$8E     RETURN  43218 $A8D2
$8F     REM     43323 $A93B
$90     STOP    43055 $A82F
$91     ON      43339 $A94B
$92     WAIT    47149 $B82D
$93     LOAD    57704 $E168
$94     SAVE    57686 $E156
$95     VERIFY  57701 $E165
$96     DEF     46002 $B3B3
$97     POKE    47140 $B824
$98     PRINT#  43648 $AA80
$99     PRINT   43680 $AAA0
$9A     CONT    43095 $A857
$9B     LIST    42652 $A69C
$9C     CLR     42590 $A65E
$9D     CMD     43654 $AA86
$9E     SYS     57642 $E12A
$9F     OPEN    57790 $E1BE
$A0     CLOSE   57799 $E1C7
$A1     GET     43899 $AB7B
$A2     NEW     42562 $A642

$A3     TAB(                    ;Keywords which never begin a statement
$A4     TO
$A5     FN
$A6     SPC(
$A7     THEN
$A8     NOT
$A9     STEP

$AA     +       47210 $B86A     ;Math operators
$AB     -       47187 $B853
$AC     *       47659 $BA2B
$AD     /       47890 $BB12
$AE     ^       49019 $BF7B
$AF     AND     45033 $AFE9
$B0     OR      45030 $AFE6
$B1     >       49076 $BFB4
$B2     =       44756 $AED4
$B3     <       45078 $B016

$B4     SGN     48185 $BC39     ;Functions
$B5     INT     48332 $BCCC
$B6     ABS     48216 $BC58
$B7     USR     784   $0310
$B8     FRE     45949 $B37D
$B9     POS     45982 $B39E
$BA     SQR     49009 $BF71
$BB     RND     57495 $E097
$BC     LOG     47594 $B9EA
$BD     EXP     49133 $BFED
$BE     COS     57956 $E264
$BF     SIN     57963 $E26B
$C0     TAN     58036 $E2B4
$C1     ATN     58126 $E30E
$C2     PEEK    47117 $B80D
$C3     LEN     46972 $B77C
$C4     STR$    46181 $B465
$C5     VAL     47021 $B7AD
$C6     ASC     46987 $B78B
$C7     CHR$    46828 $B6EC
$C8     LEFT$   46848 $B700
$C9     RIGHT$  46892 $B72C
$CA     MID$    46903 $B737

$CB     GO                      ;Makes GO TO legal.

        The BASIC ROM begins at $A000:

$A000-$A001     Cold start vector
$A002-$A003     Warm start vector
$A004-$A00B     ASCII text "CBMBASIC"

$A00C-$A051     Statement dispatch table

        This is the first of several important tables used by BASIC.
When a new BASIC statement is to be executed the interpreter looks
here to find the address of the statement routine.  Each entry is
a two-byte vector containting the routine address minus one.  The
address is pushed onto the stack, so that the next RTS will jump
to the correct location.  The addresses are in token order, beginning
with token $80 (END) and ending with token $A2 (NEW):

$A052-$A07F     Function dispatch vector table

        This is another table of two-byte vectors for BASIC functions --
that is, commands which are followed by an argument inside of parenthesis,
for example INT(3.14159).  The entries are again in token order beginning
with token $B4 (SGN) and ending with token $CA (MID$).

$A080-$A09D     Operator dispatch vector table

        This table is for math operators, beginning with token $AA (+)
and ending with token $B3 (<).

$A09E-$A19D     List of keywords

        This is a table of all the reserved BASIC keywords.  The
high bit of the last character set, so it is easy to detect the end
of a keyword.  The keywords are listed in token order, so to find
the token corresponding to a given keyword the BASIC interpreter
simply moves down this list, counting as it goes.  If a match
occurs, then the token value is simply the counter value.
        The table is searched using SBC instead of CMP.  If the
result of the subtraction is $80 -- keywords end with the high bit set --
then a valid keyword has been found.  When input is placed into the
input buffer at $0200, character codes 192-223 are used for shifted
characters.  From this it should be clear why the keyboard shortcuts work,
for instance typing pO instead of poke.  It should also be clear why poK will
also work, but pokE will not work.

$A19E-$A327     ASCII text of BASIC error messages (dextral character inverted)
$A328-$A364     Error message vector table
$A365-$A389     Miscellaneous messages (null-terminated)

$A38A-$A47F     Some BASIC routines, to be be disassembled at a later date

$A480           Main loop

        Since the goal is to get a good enough understanding of BASIC to
add new keywords, the main program loop is a good place to start.  This
routine is vectored through IMAIN at $0302.  It gets a line of input
from the keyboard, checks for a line number, and processes the line
        When I started programming BLARG, I had no idea what routines like
CRUNCH were expected to return -- is the Y register expected to have
a certain value upon exit?  Or maybe a certain variable needs to be
set up so that another routine may reference it?  Thus it is a good
idea to begin at the main loop and see how a line is normally
processed.  The disassembly listing begins at this point.

        Other important vectored routines are:

$A579           CRUNCH

        This routine goes through the BASIC text buffer at $0200 and
tokenizes any keywords which aren't in quotes.  As the routine begins
to scan the input buffer it discards any characters which have their
high bit set, such as shifted characters.  (This is only in the
initial search for keywords -- shifted characters within quotes or
as part of a keyword are taken care of by another routine).  As
a practical matter, this means that any routine which adds extra
tokens must call this routine _first_, since it will just skip over
custom tokens otherwise!
        When it is finished processing the input buffer, the
input buffer contains the tokenized line, terminated by a null
byte, _and_ with another null byte at the end of the line +2 (much
like the terminating byte which marks the end of a program).  See
the disassembly and blarg source for other things which are set up.

$A717   QPLOP

        This is the part of the LIST routine (which begins at $A69C)
which converts tokens into ASCII characters and prints them to the

$A7E4   GONE

        This is the routine which gets the next token (every statement
begins with a token or an implied LET) and executes the appropriate command.
Invalid tokens generate a SYNTAX ERROR.  Character values less than 128 cause
LET to be executed.
        The IF/THEN routine actually bypasses the IGONE vector and jumps
directly into this routine, which means that lines like
will generate a syntax error.  BLARG currently has no mechanism for
getting around this (because I did not discover this until recently,
and the article deadline was several days ago :), except to place a
colon after the THEN, i.e. IF A=0 THEN:MYCOMMAND.  Apparently some
programs get around this by defining their own IF statement; probably
the best way to get around it is to redirect the IERROR vector.
When an error is generated, check to see if it is a custom token,
then check to see if it was preceded by a THEN token.

        By now, we have all the necessary information to add new keywords
to BASIC.  To that end I present BLARG, which adds several hires bitmap
commands to BASIC.  As a bonus, BLARG can take advantage of a SuperCPU
if you have one.  These commands are much faster than the 128's BASIC7.0
commands and in my quite biased opinion much more intuitive.  The CIRCLE
and LINE commands are adaptations of my routines from C=Hacking; look there
for more info on the actual routines.
        Some things in BLARG are done a little differently than their
corresponding BASIC routines, in large part because I wrote some of the
routines before disassembling the BASIC ones.
        BLARG documentation is below.

        I have found Mapping the 64 to be an invaluable reference, along
with "Programming the Commodore 64", by Raeto West. has
some good documentation, and I use Marko Makela's web page quite
often at -- there are many useful documents
there, including a complete html cross-referenced ROM listing.

* A480-A856  (MAIN-END)
*   Basic ROM disassembly starting with main loop
* Stephen L. Judd 1997

* Labels are at the end of the listing, along with a list
* of major routines and their addresses.
* MAIN -- Main loop, receives input and executes
* immediately or stores as a program line.

* $A480                          
JMPMAIN  JMP (IMAIN)      ;Main loop, below
                          ;Vectored through IMAIN, so it
                          ;may be redirected.
MAIN     JSR INLIN        ;Input a line from keyboard
         STX TXTPTR       
         STY TXTPTR+1     
         JSR CHRGET       ;Get 1st char out of buffer
         BEQ JMPMAIN      ;Empty line
         LDX #$FF         ;Signal that BASIC is in immediate
         STX CURLIN+1     ;mode.
         BCC MAIN1        ;CHRGET clears C when digit is read
         JSR CRUNCH       ;Tokenize line
         JMP JMPGONE      ;Execute line

* MAIN1 -- Add or replace a line of program text.
* TEMP2 points to the current line to be deleted
* TEMP1 will point to the start of memory to be copied
* INDEX1 will point to the destination for the copy

* $A49C
MAIN1    JSR LINGET       ;Convert ASCII to binary line number
         JSR CRUNCH       ;Tokenize buffer
         STY COUNT        ;Y=length of line
         JSR FINDLINE     ;Find the address of the line number
         BCC :NEWLINE
         LDY #$01         ;Replace line of text
         LDA (TEMP2),Y    ;$5F = pointer to line
         STA TEMP1+1      ;(TEMP1) = xx, Hi byte of next line
         LDA VARTAB       ;End of BASIC program
         STA TEMP1        ;(TEMP1) = basic end, high next
         LDA TEMP2+1    
         STA INDEX1+1     ;(INDEX1) = xx, Hi byte current line
         LDA TEMP2        ;Compute -length of current line
         SBC (TEMP2),Y    ;Current address - next address
         ADC VARTAB       ;end - (length of line to be deleted)
         STA VARTAB
         STA INDEX1       ;(INDEX1) = bytes to delete, high current
         LDA VARTAB+1     ;Back up end of program if necessary
         ADC #$FF         
         STA VARTAB+1     
         SBC TEMP2+1      ;Number of pages of memory to move
         LDA TEMP2        ;Pretty confusing, eh?
         SBC VARTAB
         TAY              ;256 - number of bytes to move
         BCS :CONT1       
         DEC INDEX1+1
:CONT1   CLC              
         ADC TEMP1        ;old basic end - number of bytes to move
         BCC :CONT2       
         DEC TEMP1+1
:CONT2   LDA (TEMP1),Y    ;Delete old line, fall through to create
         STA (INDEX1),Y   ;new line.
         BNE :CONT2      
         INC TEMP1+1      
         INC INDEX1+1          
         BNE :CONT2       

:NEWLINE JSR RESCLR       ;Reset variables and TXTPTR
         JSR LINKPRG      ;Relink program lines
         LDA BUF          
         BEQ JMPMAIN      ;Empty statement -- nothing to do
         LDA VARTAB       ;Start of variables
         STA $5A          
         ADC COUNT
         STA $58          ;Start of vars after line is added
         LDY VARTAB+1     
         STY $5B          
         BCC :CONT3       
:CONT3   STY $59          
         JSR MALLOC       ;Open up some space in memory
         LDA LINNUM       ;Number of line to be added
         LDY LINNUM+1     
         STA H01FE        ;Rock bottom on the stack.
         STY H01FF        
         LDA STREND       ;Bottom of strings to top of variables
         LDY STREND+1     
         STA VARTAB       
         STY VARTAB+1     
         LDY COUNT        ;Number of chars in BUF
:LOOP    LDA BUF-4,Y      ;Copy buffer contents into program
         STA (TEMP2),Y    
         BPL :LOOP        
         JSR RESCLR        
         JSR LINKPRG      
         JMP JMPMAIN      ;Wheeeeeeee...

* LINKPRG -- Relink lines of program text
* $A533                          
LINKPRG  LDA TXTTAB       ;Start of BASIC text
         LDY TXTTAB+1     
         STA TEMP1        
         STY TEMP1+1      
:LOOP1   LDY #$01         
         LDA (TEMP1),Y    
         BEQ :RTS         ;0 means end of program
         LDY #$04         ;Skip link, line number, and 1st char
:LOOP2   INY              
         LDA (TEMP1),Y    
         BNE :LOOP2       ;Find end of line
         ADC TEMP1        ;Add offset to pointer to get address
         TAX              ;of next line
         LDY #$00         
         STA (TEMP1),Y    ;And store in link
         LDA TEMP1+1      
         ADC #$00         
         STA (TEMP1),Y    
         STX TEMP1        ;Move to next line
         STA TEMP1+1      
         BCC :LOOP1       ;Keep on truckin'!
:RTS     RTS              

* INLIN -- Input a line from keyboard to buffer
* $A560
INLIN    LDX #$00         
:LOOP    JSR HE112        ;BASIC's way of calling Kernal routines
         CMP #$0D         
         BEQ :DONE        
         STA BUF,X        
         CPX #$59         ;Maximum buffer size = 88 chars
         BCC :LOOP        
         LDX #$17         ;STRING TOO LONG error
         JMP ERROR        
:DONE    JMP HAACA        ;Part of the PRINT routine

* CRUNCH -- Tokenize a line of text contained in the input buffer
* $A579
* On exit:
*   Y = last character of crunched text + 4
*   X = last char of input buffer read in.
*   TEXTPTR = $01FF
*   GARBFL = 00 if colon was read, $49 if DATA statement,
*            04 otherwise.
*   ENDCHR = $22 (if quote was found) or 0 (if REM)
*   COUNT = Last token read - 128 (contrary to what
*                                  Mapping the 64 says)
*   TEMP1 = More or less random
*   BUF = Tokenized text, followed by a 00, random byte, and 00

CRUNCH                    ;$A579
         JMP (ICRNCH)     
         LDX TXTPTR       ;Low byte
         LDY #$04         
         STY GARBFL       
MAINLOOP LDA BUF,X        ;Search input buffer for text
         BPL :GOTCHAR     ;characters or #$FF
         CMP #$FF         
         BEQ STALOOP      
         BNE MAINLOOP         
:GOTCHAR CMP #$20         ;Is it a space?
         BEQ STALOOP      
         STA ENDCHR       
         CMP #$22         ;Is it a quote?
         BEQ QUOTE2       
         BIT GARBFL       ;This either equals 00 if a
                          ;colon was hit, $49 if a DATA
                          ;statement was found, and #04
                          ;initially.  Thus, it prints the
                          ;text within DATA statements.
         BVS STALOOP      
         CMP #'?'         ;Short print
         BNE :CONT1       
         LDA #$99         ;Print token
         BNE STALOOP      
:CONT1   CMP #'0'         ;Check for a number,
         BCC :NOTNUM       
         CMP #'<'         ;colon, or semi-colon
         BCC STALOOP      
:NOTNUM  STY TEMP1        ;So, search for a keyword
         LDY #$00         
         STY COUNT        
         STX TXTPTR       
FINDWORD INY              ;Find keyword
CMPWORD  LDA BUF,X        ;Match against keyword table
         SBC RESLST,Y     
         BEQ FINDWORD     
         CMP #$80         ;High bit of last char is set
                          ;Also means p shift-O gives short
                          ;version of POKE (for instance),
                          ;as should po shift-K.
         BNE NEXTWORD     
         ORA COUNT        ;A now contains token value
STABUF   LDY TEMP1        ;Crunched text index
STALOOP  INX              ;Store text in crunched buffer
         STA BUF-5,Y      
         LDA BUF-5,Y      ;Goofy -- use AND #$FF or CMP #0
         BEQ ALLDONE      ;Zero byte terminates string
         SBC #$3A         ;Is it a colon?
         BEQ :COLON       
         CMP #$49         ;Was it $83, a DATA statement?
         BNE :SKIP        
:SKIP    SEC              
         SBC #$55         ;Was it $8F, a REM statement?
         BNE MAINLOOP         
         STA ENDCHR       ;If REM, then read rest of line
QUOTE    LDA BUF,X        ;Look for matching quote char
         BEQ STALOOP      ;or end of statement, and embed
         CMP ENDCHR       ;text directly.
         BEQ STALOOP      
QUOTE2   INY              
         STA BUF-5,Y      
         BNE QUOTE        
NEXTWORD LDX TXTPTR       ;Skip to next keyword
         INC COUNT        ;Next token
:LOOP    INY              
         LDA RESLST-1,Y   ;Find last char
         BPL :LOOP        
         LDA RESLST,Y     
         BNE CMPWORD      
         LDA BUF,X        
         BPL STABUF       
         DEC TXTPTR+1     
         LDA #$FF         
         STA TXTPTR       

*   Search for the line number contained in $14.  If found, set $5F
*   to link address and set carry.  Carry clear means line number
*   not found.

* $A613                          
FINDLINE LDA TXTTAB       ;Start of program text
         LDX TXTTAB+1     
:LOOP    LDY #$01         
         STA TEMP2        
         STX TEMP2+1      
         LDA (TEMP2),Y    
         BEQ :EXIT        ;Exit if at end of program
         LDA LINNUM+1     ;High byte
         CMP (TEMP2),Y    
         BCC :RTS         ;Less than -> line doesn't exist
         BEQ :CONT1        
         BNE :CONT2       ;...always taken
:CONT1   LDA LINNUM       ;Compare low byte
         CMP (TEMP2),Y    
         BCC :RTS         ;Punt when past line number
         BEQ :RTS         ;Success!
:CONT2   DEY              ;Get next line link
         LDA (TEMP2),Y
         LDA (TEMP2),Y    
         BCS :LOOP
:EXIT    CLC              
:RTS     RTS
* Perform NEW
* $A642
NEW      BNE *-2          ;RTS above
         LDA #$00
         STA (TXTTAB),Y   ;Zero out first two bytes of program
         STA (TXTTAB),Y   
         LDA TXTTAB       
         ADC #$02         
         STA VARTAB       ;Move end of BASIC to begin+2
         LDA TXTTAB+1     
         ADC #$00         
         STA VARTAB+1     
         LDA #$00         

* Perform CLR (Calcium Lime and Rust remover!)
* $A65E
         JSR CLALL        ;Close files
         LDA MEMSIZ       ;Highest address used by BASIC
         LDY MEMSIZ+1
         STA FRETOP       ;Bottom of string text storage
         STY FRETOP+1
         LDA VARTAB       ;End of BASIC program/variable start
         LDY VARTAB+1     
         STA ARYTAB       ;Start of array storage
         STY ARYTAB+1
         STA STREND       ;End of array storage/start of free RAM
         STY STREND+1     
         JSR RESTORE      
         LDX #$19         
         STX TEMPPT       ;Temporary string stack
         LDX #$FA         ;Reset stack
         PHA              ;Restore correct return address
         LDA #$00         
         STA OLDTXT+1     ;Address of current basic statement
         STA SUBFLG       ;
CLEAREND RTS              

* RUNC -- reset current text character pointer to the
* beginning of program text.
* $A68E
RUNC     CLC              
         LDA TXTTAB       
         ADC #$FF         
         STA TXTPTR       
         LDA TXTTAB+1     
         ADC #$FF         
         STA TXTPTR+1     
* LIST -- perform LIST
* entered via return from CHRGET
* $A69C
LIST     BCC :SKIP        ;Is next char an ASCII digit
         BEQ :SKIP        ;Is next char ':' or 00
         CMP #$AB         ;Is next char '-' (token)
         BNE CLEAREND     ;RTS, above
:SKIP    JSR LINGET       ;Read decimal, convert to number
         JSR FINDLINE     ;Find line number
         JSR CHRGOT       ;Get char again
         BEQ :CONT        ;statement terminator
         CMP #$AB         
         BNE NEW-1        ;RTS
         JSR CHRGET       ;Advance and get end of
         JSR LINGET       ;range to list xx-xx
         BNE NEW-1        ;RTS
:CONT    PLA              
         LDA LINNUM       
         ORA LINNUM+1     
         BNE LISTLOOP     
         LDA #$FF         ;Signal to list program to end
         STA LINNUM       
         STA LINNUM+1     
LISTLOOP LDY #$01         
         STY GARBFL       
         LDA (TEMP2),Y    
         BEQ ENDLIST      
         JSR TESTSTOP     ;Test for STOP key
         JSR HAAD7        ;part of PRINT routine
         LDA (TEMP2),Y    
         LDA (TEMP2),Y    
         CMP LINNUM+1     ;Check to see if at last line
         BNE :CONT1       
         CPX LINNUM       
         BEQ :CONT2       
:CONT2   STY FORPNT       ;temporary storage
         JSR LINPRT       ;Print line number
         LDA #$20         ;space
         AND #$7F         ;strip high bit
LISTENT2 JSR HAB47        ;Prints char, AND #$FF
         CMP #$22         ;Look for a quote
         BNE :CONT        
         LDA GARBFL       
         EOR #$FF         
         STA GARBFL       
:CONT    INY              ;$A700
         BEQ ENDLIST      ;256 character lines perhaps?
         LDA (TEMP2),Y    
         BNE JMPPLOP      ;Print the token
         TAY              ;Get line link
         LDA (TEMP2),Y    
         LDA (TEMP2),Y    
         STX TEMP2        
         STA TEMP2+1      
         BNE LISTLOOP     
ENDLIST  JMP HE386        ;Exit through warm start

* QPLOP -- print BASIC tokens as ASCII characters.
* $A717
QPLOP    BPL LISTENT2     ;Exit if not a token
         CMP #$FF         
         BEQ LISTENT2     
         BIT GARBFL       
         BMI LISTENT2     ;Exit if inside a quote
         SBC #$7F         ;Table offset+1
         STY FORPNT       ;Temp storage
         LDY #$FF         
:LOOP1   DEX              ;Traverse the keyword table
         BEQ :PLOOP       
:LOOP2   INY              ;read a keyword
         LDA RESLST,Y   
         BPL :LOOP2       
         BMI :LOOP1       
:PLOOP   INY              ;Print out the keyword
         LDA RESLST,Y   
         BMI LISTENT1     ;Exit if on last char
         JSR HAB47        ;Print char, AND #$FF
         BNE :PLOOP       

* Perform FOR
* $A742
FOR      LDA #$80         
         STA SUBFLG       
         JSR LET
         JSR FINDFOR
         BNE :CONT
         ADC #$0F         
         LDA #$09         
         JSR CHKSTACK     
         JSR ENDSTAT      
         ADC TXTPTR       
         LDA TXTPTR+1     
         ADC #$00         
         LDA CURLIN+1     
         LDA CURLIN       
         LDA #$A4         
         JSR CHKCOM       
         JSR HAD8D        
         JSR FRMNUM       
         LDA FACSGN       
         ORA #$7F         
         AND $62          
         STA $62          
         LDA #$8B         
         LDY #$A7         
         STA TEMP1        
         STY TEMP1+1      
         JMP HAE43        
         LDA #$BC         
         LDY #$B9         
         JSR MTOFAC       
         JSR CHRGOT       
         CMP #$A9         
         BNE HA79F        
         JSR CHRGET       
         JSR FRMNUM       
HA79F    JSR SIGN         
         JSR HAE38        
         LDA $4A          
         LDA FORPNT       
         LDA #$81         
* NEWSTT -- Set up next statement for execution.
* $A7AE
         LDA TXTPTR       
         LDY TXTPTR+1     
         CPY #$02         ;Text buffer?
         BEQ :CONT        
         STA OLDTXT       
         STY OLDTXT+1     
:CONT    LDY #$00         ;End of last statement.
         LDA (TXTPTR),Y   
         BNE HA807        ;branch into GONE
         LDY #$02         
         LDA (TXTPTR),Y   ;End of program?
         BNE :CONT2       
         JMP HA84B        ;exit through END

:CONT2   INY              
         LDA (TXTPTR),Y   ;Line number
         STA CURLIN       
         LDA (TXTPTR),Y   
         STA CURLIN+1     
         ADC TXTPTR       ;Advance pointer
         STA TXTPTR       
         BCC JMPGONE      
         INC TXTPTR+1     
* GONE -- Read and execute next statment
* $A7E1
         JSR CHRGET       
         JSR GONE         
         JMP NEWSTT       
* $A7ED
GONE     BEQ :RTS         ;Exit if statement terminator
         SBC #$80         
         BCC :JMPLET      ;If not a token then a variable
         CMP #$23         ;Tokens above $A3 never begin
         BCS CHKGOTO      ;a statement (except GO TO)
         ASL              ;Otherwise, get entry point
         TAY              ;of the statement...
         LDA STATVEC+1,Y  
         LDA STATVEC,Y    
         JMP CHRGET       ;... so CHRGET can RTS to it.
:JMPLET  JMP LET          
HA807    CMP #':'
         BEQ JMPGONE
CHKGOTO  CMP #$4B         ;Is it "GO TO"?
         BNE JMPSYN       
         JSR CHRGET       
         LDA #$A4         ;Make sure next char is "TO"
         JSR CHKCOM       ;token, and skip it.
         JMP GOTO

* Perform RESTORE
* $A81D
RESTORE  SEC              
         LDA TXTTAB       ;Set DATA pointer to start of program
         SBC #$01         
         LDY TXTTAB+1     
         BCS :CONT
:CONT    STA DATPTR       ;Address of current DATA item
         STY DATPTR+1
:RTS     RTS              
         BCS END+1        

* END -- perform END
* $A831
END      CLC
         BNE $A870        ;RTS
         LDA TXTPTR
         LDY TXTPTR+1
         LDX CURLIN+1     ;Current line number
         BEQ :CONT1       ;Branch if in immediate mode
         STA OLDTXT       ;Save statement address for CONT
         STY OLDTXT+1
         LDA CURLIN
         LDY CURLIN+1
         STA OLDLIN       ;Restored by CONT
         STY OLDLIN+1
:CONT1   PLA              ;Discard return address
* $A84B
HA84B    LDA #$81         ;Message at $A381
         LDY #$A3
         BCC :CONT2
         JMP $A469        ;BREAK
:CONT2   JMP $E386        ;BASIC warm start


ENDCHR   = $0008          ;See CRUNCH
COUNT    = $0B            
GARBFL   = $000F          ;Work byte
SUBFLG   = $0010          
LINNUM   = $14            
TEMPPT   = $0016          ;Next available space in temp string stack
TEMP1    = $22            ;Temporary pointer/variable
INDEX1   = $0024          
TXTTAB   = $002B          ;Pointer to start of BASIC text
ARYTAB   = $002F          ;Pointer to start of arrays
STREND   = $0031          ;End array storage/start free RAM
FRETOP   = $0033          ;End of string text/top free RAM
MEMSIZ   = $0037          ;Highest address used by BASIC
CURLIN   = $39            ;Current BASIC line number
OLDTXT   = $003D          ;Pointer to current BASIC statement
DATPTR   = $0041          ;Pointer to current DATA item
FORPNT   = $0049          ;Temp pointer to FOR index variable
TEMP2    = $5F            
FAC1     = $61
FACSGN   = $0066          
TEMP1    = $71            
FBUFPT   = $0071          
CHRGET   = $0073          ;Get next BASIC text char
CHRGOT   = $0079          ;Get current BASIC text char
TXTPTR   = $7A            ;Text pointer
H01FE    = $01FE          
H01FF    = $01FF          
BUF      = $0200          ;Text input buffer
IMAIN    = $0302          ;System vectors
ICRNCH   = $0304          
IQPLOP   = $0306          
IGONE    = $0308          
STATVEC  = $A00C          ;Statement dispatch vector table
RESLST   = $A09E          ;Reserved keywords list
FINDFOR  = $A38A          ;Find FOR on stack
MALLOC   = $A3B8          ;Make space for new line or var
CHKSTACK = $A3FB          ;Check for space on stack
ERROR    = $A437          ;General error handler
END      = $A831          ;Perform END
GOTO     = $A8A0          ;Perform GOTO
ENDSTAT  = $A906          ;Search for end of statement
                          ;(00 or colon)
LINGET   = $A96B          ;Convert ASCII decimal to 2-byte line number
LET      = $A9A5          ;Perform LET
HAACA    = $AACA          
HAAD7    = $AAD7          
HAB47    = $AB47          
FRMNUM   = $AD8A          ;Eval expression/check data type
HAD8D    = $AD8D          
HAE38    = $AE38          
HAE43    = $AE43          
CHKCOM   = $AEFF          ;Check for and skip comma
SYNERR   = $AF08          ;Print Syntax Error message
MTOFAC   = $BBA2          ;Move FP number from mem to FAC1
SIGN     = $BC2B          ;Sign of FAC1 in A
LINPRT   = $BDCD          ;Print num X,A=lo,hi in ASCII
HE112    = $E112          
HE386    = $E386          
STOP     = $FFE1          ;Kernal
CLALL    = $FFE7          

* Major routine entry points
* $A480 JMPMAIN  JMP (IMAIN)      ;Main loop, below
* $A483 MAIN     JSR INLIN        ;Input a line from keyboard
* $A49C MAIN1    JSR LINGET       ;Convert ASCII to binary line number
* $A533 LINKPRG  LDA TXTTAB       ;Start of BASIC text
* $A560 INLIN    LDX #$00         
* $A613 FINDLINE LDA TXTTAB       ;Start of program text
* $A642 NEW      BNE *-2          ;RTS above
* $A68E RUNC     CLC              
* $A69C LIST     BCC :SKIP        ;Is next char an ASCII digit
* $A717 JMPPLOP  JMP (IQPLOP)     
* $A71A QPLOP    BPL LISTENT2     ;Exit if not a token
* $A7E1 JMPGONE  JMP (IGONE)      
* $A7ED GONE     BEQ :RTS         ;Exit if statement terminator
* $A81D RESTORE  SEC              
* $A831 END      CLC

BLARG -- Basic Language Graphics extension
version 1.0 2/10/97

BLARG is a little BASIC extension which adds some graphics commands to
the normal C-64 BASIC.  In addition it supports the SuperCPU optimization
modes, as well as double buffering.  Finally, it is free for use in
your own programs, so feel free to do so!

My goal was to write a BASIC extension which was compact, fast,
and actually available for downloading :).  Also, something that wasn't
BASIC7.0.  It doesn't have tons of features but I deem it to be Nifty.

Anyways, these are adaptations of my algorithms from C=Hacking and such.
They are not the most efficient implementations, but they are fairly zippy,
and fairly well beat the snot out of BASIC7.0 commands!  For instance,
the times from moire3 (a line drawing test):

        Stock 64        1200 jiffies    (1X)
        SCPU Mode 17    137 jiffies     (9.1X)
        SCPU Mode 16    59 jiffies      (20.2X)
        BASIC7.0 (1MHz) 4559 jiffies    (1/3.5 X)

So lines are nearly 4x faster on a stock 64 than a 128 running BASIC7.0.
Running in mode16 on a SuperCPU is 77 times faster than BASIC7.0!!!

Let's not even talk about BASIC7.0 circles.  Well, what the heck, let's
talk about them :)
        Stock 64        360 jiffies     (1x)
        SCPU Mode 17    50 jiffies      (7x)
        SCPU Mode 16    22 jiffies      (15.4x)
        BASIC7.0        17394 j :)      1/49x

Bottom line: mode 16 circles are, if you can believe it, 790x faster
than BASIC7.0 circles (and much better looking, especially at large
radii -- BASIC7.0 circles are actually 128-sided polygons :-/  ).

The total size of the program right now is a bit over 2k, and sits at
$C000.  To install the program, just load and run.  To re-initialize
the system (after a warm reset for instance) just type SYS49152.  The
command list is located near $C000, immediately followed by the
routine addresses, in case you want to take a peek.

A second program, BLARG$8000, is included in the archive.  To use it,
load ,8,1 and type SYS32768 to initialize.  This program is included
so that it may be loaded from a BASIC program.

Several demo programs are included, and offer a good way of learning
the commands (for instance, try typing ORIGIN 10,10 before running

Words to the wise:

        1 - If you use a DOS extension like JiffyDOS then be sure to
            enclose filenames etc. in quotes (unless you want them to
            be tokenized, in which case feel free to omit quotes).

        2 - If it looks like your machine has completely frozen try
            typing RUN-STOP, shift-clear, MODE 17 (Sometimes you can
            break the program before it can tell VIC where the screen
            is located).  MODE16 and MODE17 will always fix stuff up,
            whereas run/stop-restore doesn't always do the trick.

        3 - Always keep in mind that MODE 16,17, and 18 may hose
            string variables.

        4 - IF/THEN bypasses the IGONE vector, so a statement like
            IF A=0 THEN GRON will fail.  The statement IF A=0 THEN:GRON
            will work fine.

Without further ado:

GRON [COLOR] -- Turns graphics on.  If the optional parameter COLOR is
        specified the bitmap is cleared and the colormap is initialized to
        that value, specifically,
        COLOR = 16*foreground color + background color

                GRON  -- Turn on bitmap without clearing it.
                GRON20 -- Turn on bitmap, clear, purple bg, white fg

GROFF -- Turns graphics off (sticks you back into text mode, or
        whatever mode you were in when you last called GRON)

CLEAR [color] -- Clear current graphics buffer.  CLEAR is part of
        the GRON routine, but will not set VIC or CIA#2.

COLOR n -- COLOR 1 sets the drawing color to the foreground color;
        COLOR 0 sets it to background.

ORIGIN CX, CY -- Sets the upper-left corner of the screen to have
        coordinates CX,CY.  More precisely, commands will subtract
        CX,CY from coordinates passed into it.  Among other things,
        this provides a mechanism for negative numbers to be
        handled -- LINE -10,0,40,99 will not work, but ORIGIN 10,0:
        LINE 0,0,50,99 will.  This value is initialized to (0,0) whenever
        SYS49152 is called.

PLOT X,Y -- Sticks a point at coordinates X,Y.  (Actually at
        coordinates X-XC, Y-YC).  X may be in the range 0..319
        and Y may be 0..199; points outside this range will not be

LINE X1,Y1,X2,Y2 -- Draws a line from X1,Y1 to X2,Y2 (subtracting
        XC,YC as necessary).  X1 may be any 16-bit value and Y2
        may be any 8-bit value.  Coordinates off of the screen will
        simply not be plotted!

CIRCLE XC,YC,R -- Draws a circle of radius R centered at XC,YC
        (translating as necessary).  The algorithm is smart and can
        handle R=0..255 correctly (as far as I know!).  I used a
        modified version of my algorithm, which makes very nice
        circles in my quite biased opinion, except for a few radii
        which come out a little ovalish.  Oh well.

MODE n -- New graphics MODE.
        MODE 16 -- SuperCPU mode.  This moves the bitmap screen to
                $A000, the colormap to $8C00, the text screen to $8800,
                and sets the SuperCPU bank 2 optimization mode.
                $9000-$9FFF is totally unused :(.
        MODE 17 -- Normal mode.  Bitmap->$E000, Colormap ->$CC00,
                text screen -> $0400.
        MODE 18 -- Double buffer mode.  MODE16 memory configuration,
                no SCPU optimization.
        MODE16, MODE17, and MODE18 reset the BASIC memtop and stringtop
        pointers, so any defined strings may get hosed.
        (They also execute GROFF, and hence turn on the text screen).
        Any other MODE parameter will be set to the BITMASK parameter.
        What is BITMASK?  Anything drawn to the screen is first ANDed
        with BITMASK.  (Try MODE 85 sometime).
        (Although these numbers are reserved for future expansion).

BUFFER n -- Set drawing buffer.
        When double-buffer mode is activated (MODE 18), both buffers
        are available for drawing and displaying.  It is then
        possible to draw in one buffer while displaying the other.
        BUFFER n selects which buffer the PLOT,LINE,CIRCLE, and CLEAR
        commands will affect.  If n=0 then it swaps the target
        buffer.  Otherwise, n=odd references the buffer at $A000
        and n=even selects the buffer at $E000.

SWAP -- Swap displayed buffer.
        Assuming MODE18 is selected, SWAP simply selects which buffer
        is displayed on the screen; specifically, it flips between
        the two.  SWAP only affects what is displayed on the
        screen; BUFFER only affects the target of the drawing commands.

I think that's it :).


* A graphics extension for C-64 BASIC
* SLJ 12/29/96 (Completed 2/10/97)
* v1.0
         ORG $0801        
* Constants
TXTPTR   = $7A            ;BASIC text pointer
IERROR   = $0300          
ICRUNCH  = $0304          ;Crunch ASCII into token
IQPLOP   = $0306          ;List
IGONE    = $0308          ;Execute next BASIC token
CHRGET   = $73            
CHRGOT   = $79            
CHROUT   = $FFD2          
GETBYT   = $B79E          ;BASIC routine
GETPAR   = $B7EB          ;Get a 16,8 pair of numbers
CHKCOM   = $AEFD          
NEW      = $A642          
CLR      = $A65E          
LINNUM   = $14            ;Number returned by GETPAR
TEMP     = $FF            
TEMP2    = $FB            
POINT    = $FD            
Y1       = $05            
X1       = LINNUM         
X2       = $02            
Y2       = $04            
DY       = $26            
DX       = $27            
BUF      = $0200          ;Input buffer
CHUNK1   = $69            ;Circle routine stuff
OLDCH1   = $6A            
CHUNK2   = $6B            
OLDCH2   = $6C            
CX       = $A3            
CY       = $A5            
X        = $6D            
Y        = $6E            
RADIUS   = $6F            
LCOL     = $A6            ;Left column
RCOL     = $A7            
TROW     = $A8            ;Top row
BROW     = $A9            ;Bottom row
         DA :LINK         ;link
         DA 1997          
         DFB $9E          ;SYS
         TXT '2063:'      
         DFB $A2          ;NEW
         DFB 00           ;End of line
:LINK    DA 0             ;end of program
         STA POINT        
         LDA #>PBEGIN     
         STA POINT+1      
         LDA #<PEND       ;Number of bytes to copy
         SBC #<PBEGIN     
         STA TEMP2        
         LDA #>PEND       
         SBC #>PBEGIN     
         STA TEMP2+1      
         LDA #$C0         ;Copy to $C000
         STA X2+1         
         LDY #00          
         STY X2           
:LOOP    LDA (POINT),Y    
         STA (X2),Y       
         BNE :LOOP        
         INC POINT+1      
         INC X2+1         
         DEC TEMP2+1      
         BNE :LOOP        
         LDY TEMP2        
:LOOP2   LDA (POINT),Y    
         STA (X2),Y       
         CPY #$FF         
         BNE :LOOP2       
         LDX #5           ;Copy CURRENT vectors
         STA OLDCRNCH,X   
         BPL :LOOP3       
         JMP INIT         
         TXT 'so, you want a secret message, eh? '
         TXT 'narnia, narnia, narnia, awake.'
         TXT ' love. think. speak. be walking trees.'
         TXT ' be talking beasts. be divine waters.'
         TXT 'stephen l. judd wuz here 1/20/97'
         ORG $C000        
* Init routine -- modify vectors
* and set up values.
         LDX #5           ;Copy vectors
:LOOP    LDA :TABLE,X     
         STA ICRUNCH,X    
         BPL :LOOP        
         STX ORGX         
         STX ORGY         

         JMP MODE17       ;Mode 17
:TEMP    DFB 05           
:TABLE   DA CRUNCH        
         DA LIST          
         DA EXECUTE       
JMPCRUN  DFB $4C          ;JMP
OLDCRNCH DS 2             ;Old CRUNCH vector
OLDLIST  DS 2             
OLDEXEC  DS 2             
* Keyword list
* Keywords are stored as normal text,
* followed by the token number.
* All tokens are >128,
* so they easily mark the end of the keyword
         TXT 'plot',E0    
         TXT 'line',E1    
         TXT 'circle',E2  
         TXT 'gr',91,E3   ;grON
         TXT 'groff',E4   ;Graphics off
         TXT 'mode',E5    
         DFB $B0          ;OR
         TXT 'igin',E6    
         TXT 'clear',E7   ;Clear bitmap
         TXT 'buffer',E8  ;Set draw buffer
         TXT 'swap',E9    ;Swap foreground and background
         TXT 'col',B0,EA  ;Set color
         DFB 00           ;End of list
* Table of token locations-1
* Subtract $E0 first
* Then check to make sure number isn't greater than NUMWORDS
:E0      DA PLOT-1        
:E1      DA LINE-1        
:E2      DA CIRCLE-1      
:E3      DA GRON-1        
:E4      DA GROFF-1       
:E5      DA MODE-1        
:E6      DA ORIGIN-1      
:E7      DA CLEAR-1       
:E8      DA BUFFER-1      
:E9      DA SWAP-1        
:EA      DA COLOR-1       
HITOKEN  EQU $EB          
* CRUNCH -- If this is one of our keywords, then tokenize it
         JSR JMPCRUN      ;First crunch line normally
         LDY #05          ;Offset for KERNAL
                          ;Y will contain line length+5
:LOOP    STY TEMP         
         JSR ISWORD       ;Are we at a keyword?
         BCS :GOTCHA      
         JSR NEXTCHAR     
         BNE :LOOP        ;Null byte marks end
         STA BUF-3,Y      ;00 line number
         LDA #$FF         ;'tis what A should be
         RTS              ;Buh-bye
* Insert token and crunch line
         LDX TEMP         ;If so, A contains opcode
         STA BUF-5,X      
:MOVE    INX              
         LDA BUF-5,Y      
         STA BUF-5,X      ;Move text backwards
         BEQ :NEXT        
         BPL :MOVE        
* ISWORD -- Checks to see if word is
* in table.  If a word is found, then
* C is set, Y is one past the last char
* and A contains opcode.  Otherwise,
* carry is clear.
* On entry, TEMP must contain current
* character position.
         LDX #00          
:LOOP    LDY TEMP         
         BEQ :NOTMINE     
         CMP #$E0         
         BCS :RTS         ;Tokens are >=$E0
         CMP BUF-5,Y      
         BNE :NEXT        
         INY              ;Success!  Go to next char
         BNE :LOOP2       
         LDA KEYWORDS,X   ;Find next keyword
         CMP #$E0         
         BCC :NEXT        
         BNE :LOOP        ;And check again
:NOTMINE CLC              
:RTS     RTS              
* NEXTCHAR finds the next char
* in the buffer, skipping
* spaces and quotes.  On
* entry, TEMP contains the
* position of the last spot
* read.  On exit, Y contains
* the index to the next char,
* A contains that char, and Z is set if at end of line.
         LDY TEMP         
:LOOP    INY              
         LDA BUF-5,Y      
         BEQ :DONE        
         CMP #$8F         ;REM
         BNE :CONT        
         LDA #00          
:SKIP    STA TEMP2        ;Find matching character
:LOOP2   INY              
         LDA BUF-5,Y      
         BEQ :DONE        
         CMP TEMP2        
         BNE :LOOP2       ;Skip to end of line
         BEQ :LOOP        
         CMP #$20         ;Space
         BEQ :LOOP        
         CMP #$22         ;Quote
         BEQ :SKIP        
:DONE    RTS              
* LIST -- patches the LIST routine
* to list my tokens correctly.
         CMP #$E0         
         BCC :NOTMINE     ;Not my token
         CMP #HITOKEN     
         BCS :NOTMINE     
         BIT $0F          ;Check for quote mode
         BMI :NOTMINE     
         SBC #$DF         ;Find the corresponding text
         STY $49          
         LDY #00          
:LOOP    DEX              
         BEQ :DONE        
:LOOP2   INY              
         LDA KEYWORDS,Y   
         CMP #$E0         
         BCC :LOOP2       
         BNE :LOOP        
         BMI :OUT         
         JSR $FFD2        
         BNE :DONE        
:OUT     CMP #$B0         ;OR
         BEQ :OR          
         CMP #$E0         ;It might be BASIC token
         BCS :CONT        ;e.g. GRON
         LDY $49          
:NOTMINE AND #$FF         
         JMP (OLDLIST)    ;QPLOP
:CONT    LDY $49          
         JMP $A700        ;Normal exit
:OR      LDA #'o'         ;For ORIGIN
         JSR CHROUT       
         LDA #'r'         
         JSR CHROUT       
         BNE :DONE        
* EXECUTE -- if this is one of my
* tokens, then execute it.
         JSR CHRGET       
         CMP #$E0         
         BCC :NOTMINE     
         CMP #HITOKEN     
         BCS :NOTMINE     
         JSR :DISP        
         JMP $A7AE        ;Exit through NEWSTT
         EOR #$E0         
         ASL              ;Mult by two
         LDA TOKENLOC+1,X 
         LDA TOKENLOC,X   
         JMP CHRGET       ;Exit to routine
:NOTMINE PLP              
         JMP $A7E7        ;Normal routine
* PLOT -- plot a point!
ORGX     DFB 00           ;Upper-left corner of the screen
ORGY     DFB 00           
DONTPLOT DFB 01           ;0=Don't plot point, just compute
                          ;coordinates (used by e.g. circles)
         JSR GETPAR       ;Get coordinate pair
         LDA LINNUM       ;Add in origin offset
         SBC ORGX         
         STA LINNUM       
         BCS :CONT1       
         DEC LINNUM+1     
         BMI :ERROR       ;Underflow
:CONT1   TXA              
         SBC ORGY         
         BCC :ERROR       
         CPX #200         ;Check range
         BCS :ERROR       
         LDA LINNUM       
         CMP #<320        
         LDA LINNUM+1     
         SBC #>320        
         BCC SETPOINT     
:ERROR   RTS              ;Just don't plot point
SETPOINT                  ;Alternative entry point
                          ;X=y-coord, LINNUM=x-coord
* ;X is preserved
                          ;On exit, X,Y are AND #$07
                          ;i.e. are set up correctly.
         AND #248         
         STA POINT        
         ADC BASE         ;Base of bitmap
         STA POINT+1      
         LDA #00          
         ASL POINT        
         ASL POINT        
         ASL POINT        
         ADC LINNUM+1     
         ADC POINT+1      
         STA POINT+1      
         AND #7           
         LDA LINNUM       
         AND #248         
         CLC              ;Overflow is possible!
         ADC POINT        
         STA POINT        
         BCC SETPIXEL     
         INC POINT+1      
         LDA LINNUM       
         AND #$07         
         LDA DONTPLOT     
         BEQ :RTS         
         LDA POINT+1      
         SBC BASE         ;Overflow check
         CMP #$20         
         BCS :RTS         
         SEI              ;Get underneath ROM
         LDA #$34         
         STA $01          
         LDA (POINT),Y    
         EOR BITMASK      
         AND BITTAB,X     
         EOR (POINT),Y    
         STA (POINT),Y    
         LDA #$37         
         STA $01          
                          ;On exit, X,Y are AND #$07
                          ;i.e. are set up correctly.
                          ;for more plotting
:RTS     RTS              
BITMASK  DFB #$FF         ;Set point
BITTAB   DFB $80,$40,$20,$10,$08,$04,$02,$01
* Drawin' a line.  A fahn lahn.
* To deal with off-screen coordinates, the current row
* and column (40x25) is kept track of.  These are set
* negative when the point is off the screen, and made
* positive when the point is within the visible screen.
* Little bit position table
CHUNK    EQU X2           
OLDCHUNK EQU X2+1         
* DOTTED -- Set to $01 if doing dotted draws (diligently)
* X1,X2 etc. are set up above (x2=LINNUM in particular)
* Format is LINE x2,y2,x1,y1
         JSR GETPAR       
         STX Y2           
         LDA LINNUM       
         STA X2           
         LDA LINNUM+1     
         STA X2+1         
         JSR CHKCOM       
         JSR GETPAR       
         STX Y1           
:CHECK   LDA X2           ;Make sure x1<x2
         SBC X1           
         LDA X2+1         
         SBC X1+1         
         BCS :CONT        
         LDA Y2           ;If not, swap P1 and P2
         LDY Y1           
         STA Y1           
         STY Y2           
         LDA X1           
         LDY X2           
         STY X1           
         STA X2           
         LDA X2+1         
         LDY X1+1         
         STA X1+1         
         STY X2+1         
         BCC :CHECK       
:CONT    STA DX+1         
         STX DX           
         LDX #$C8         ;INY
         LDA Y2           ;Calculate dy
         SBC Y1           
         BCS :DYPOS       ;Is y2>=y1?
         EOR #$FF         ;Otherwise dy=y1-y2
         ADC #$01         
         LDX #$88         ;DEY
:DYPOS   STA DY           
         STX YINCDEC      
         STX XINCDEC      
         LDA X1           ;Sub origin from 1st point
         SBC ORGX         
         STA X1           
         LDA X1+1         
         SBC #00          
         STA X1+1         
         PHP              ;Save carry flag
         STA TEMP         ;Next compute column
         LDA X1           
         LSR TEMP         
         LSR TEMP         
         LSR TEMP         
         STA CX           ;X-column
         BCC :NEGX        ;If negative, then fix up
         CMP #40          ;If past column 40, then punt!
         BCC :CONT1       
:NEGX    LDA X1           ;coordinate start and count
         AND #$07         
         STA X1           
         LDA #00          
         STA X1+1         
         LDA CX           
:CONT1   LDA Y1           ;Now do the same for Y
         SBC ORGY         
         STA Y1           
         TAX              ;X=y-coord
         PHP              ;Save carry bit
         STA CY           ;Y-column (well, OK, row then)
         BCC :NEGY        ;If negative, then fix stuff up!
         SBC #25          ;Check if we are past bottom of
         BCC :CONT2       ;screen
         ORA #$80         ;Otherwise, 128+rows past 24
         STA CY           ;(for plot range checking)
         AND #$07         
         ORA #8*24        ;Start in last row
         BMI :CONT2       
:NEGY    ORA #$E0         ;Set high bits of column
         STA CY           
         AND #$07         
         TAX              ;Start in 1st row
         LDA #00          
         STA DONTPLOT     
         JSR SETPOINT     ;Set up X,Y and POINT
         INC DONTPLOT     
         LDA BITCHUNK,X   
         STA OLDCHUNK     
         STA CHUNK        
         SEI              ;Get underneath ROM
         LDA #$34         
         STA $01          
         LDX DY           
         CPX DX           ;Who's bigger: dy or dx?
         BCC STEPINX      ;If dx, then...
         LDA DX+1         
         BNE STEPINX      
* Big steps in Y
*   To simplify my life, just use PLOT to plot points.
*   No more!
*   Added special plotting routine -- cool!
*   X is now counter, Y is y-coordinate
* On entry, X=DY=number of loop iterations, and Y=
*   Y1 AND #$07
         LDA #00          
         STA OLDCHUNK     ;So plotting routine will work right
         LDA CHUNK        
         LSR              ;Strip the bit
         EOR CHUNK        
         STA CHUNK        
         BNE :CONT        ;If dy=0 it's just a point
:CONT    LSR              ;Init counter to dy/2
* Main loop
YLOOP    STA TEMP         
         LDA CX           ;Range check
         ORA CY           
         BMI :SKIP        
         LDA (POINT),Y    ;Otherwise plot
         EOR BITMASK      
         AND CHUNK        
         EOR (POINT),Y    
         STA (POINT),Y    
YINCDEC  INY              ;Advance Y coordinate
         CPY #8           
         BCC :CONT        ;No prob if Y=0..7
         JSR FIXY         
:CONT    LDA TEMP         ;Restore A
         SBC DX           
         BCC YFIXX        
YCONT    DEX              ;X is counter
         BNE YLOOP        
YCONT2   LDA (POINT),Y    ;Plot endpoint
         EOR BITMASK      
         AND CHUNK        
         EOR (POINT),Y    
         STA (POINT),Y    
         LDA #$37         
         STA $01          
YFIXX                     ;x=x+1
         ADC DY           
         LSR CHUNK        
         BNE YCONT        ;If we pass a column boundary...
         ROR CHUNK        ;then reset CHUNK to $80
         STA TEMP2        
         LDA CX           
         BMI :CONT        ;Skip if column is negative
         CMP #39          ;End if move past end of screen
         BCS YDONE        
         LDA POINT        ;And add 8 to POINT
         ADC #8           
         STA POINT        
         BCC :CONT        
         INC POINT+1      
:CONT    INC CX           ;Increment column
         LDA TEMP2        
         BNE YLOOP        
         BEQ YCONT2       
* Big steps in X direction
* On entry, X=DY=number of loop iterations, and Y=
*   Y1 AND #$07
COUNTHI  DFB 00           ;Temporary counter
                          ;only used once
         LDX DX           
         LDA DX+1         
         STA COUNTHI      
         LSR              ;Need bit for initialization
         STA Y1           ;High byte of counter
         BNE :CONT        ;Could be $100
         DEC COUNTHI      
:CONT    ROR              
* Main loop
         LSR CHUNK        
         BEQ XFIXC        ;If we pass a column boundary...
XCONT1   SBC DY           
         BCC XFIXY        ;Time to step in Y?
XCONT2   DEX              
         BNE XLOOP        
         DEC COUNTHI      ;High bits set?
         BPL XLOOP        
         LSR CHUNK        ;Advance to last point
         JSR LINEPLOT     ;Plot the last chunk
EXIT     LDA #$37         
         STA $01          
* CHUNK has passed a column, so plot and increment pointer
* and fix up CHUNK, OLDCHUNK.
         STA TEMP         
         JSR LINEPLOT     
         LDA #$FF         
         STA CHUNK        
         STA OLDCHUNK     
         LDA CX           
         BMI :CONT        ;Skip if column is negative
         CMP #39          ;End if move past end of screen
         BCS EXIT         
         LDA POINT        
         ADC #8           
         STA POINT        
         BCC :CONT        
         INC POINT+1      
:CONT    INC CX           
         LDA TEMP         
         JMP XCONT1       
* Check to make sure there isn't a high bit, plot chunk,
* and update Y-coordinate.
         DEC Y1           ;Maybe high bit set
         BPL XCONT2       
         ADC DX           
         STA TEMP         
         LDA DX+1         
         ADC #$FF         ;Hi byte
         STA Y1           
         JSR LINEPLOT     ;Plot chunk
         LDA CHUNK        
         STA OLDCHUNK     
         LDA TEMP         
XINCDEC  INY              ;Y-coord
         CPY #8           ;0..7 is ok
         BCC XCONT2       
         STA TEMP         
         JSR FIXY         
         LDA TEMP         
         JMP XCONT2       
* Subroutine to plot chunks/points (to save a little
* room, gray hair, etc.)
LINEPLOT                  ;Plot the line chunk
         LDA CX           
         ORA CY           
         BMI :SKIP        
         LDA (POINT),Y    ;Otherwise plot
         EOR BITMASK      
         ORA CHUNK        
         AND OLDCHUNK     
         EOR CHUNK        
         EOR (POINT),Y    
         STA (POINT),Y    
* Subroutine to fix up pointer when Y decreases through
* zero or increases through 7.
FIXY     CPY #255         ;Y=255 or Y=8
         BEQ :DECPTR      
:INCPTR                   ;Add 320 to pointer
         LDY #0           ;Y increased through 7
         LDA CY           
         BMI :CONT1       ;If negative, then don't update
         CMP #24          
         BCS :TOAST       ;If at bottom of screen then quit
         LDA POINT        
         ADC #<320        
         STA POINT        
         LDA POINT+1      
         ADC #>320        
         STA POINT+1      
:CONT1   INC CY           
:DECPTR                   ;Okay, subtract 320 then
         LDY #7           ;Y decreased through 0
         LDA CY           
         BEQ :TOAST       
         BMI :CONT2       
         CMP #$7F         ;It is possible we just decreased
         BNE :C1          ;through row 25
         LDA #24          
         STA CY           ;In which case, set correct row
:C1      LDA POINT        
         SBC #<320        
         STA POINT        
         LDA POINT+1      
         SBC #>320        
         STA POINT+1      
:CONT2   DEC CY           
:TOAST   PLA              ;Remove old return address
         JMP EXIT         ;Restore interrupts, etc.
* CIRCLE draws a circle of course, using my
* super-sneaky algorithm.
*   CIRCLE cx,cy,radius (16,8,8)
         JSR GETPAR       
         STX CY           ;CX,CY = center
         LDA X1           
         SBC ORGX         
         STA CX           
         STA X1           
         LDA X1+1         
         SBC #00          
         STA CX+1         
         STA X1+1         
         PHP              ;Save carry
         LSR              ;Compute which column we start
         LDA CX           ;in
         BCS :CONT        ;Underflow means negative column
         LDA X1           ;Set X to first column
         AND #$07         
         STA X1           
         LDA #00          
         STA X1+1         
         ORA #$E0         ;so set high bits
:CONT    STA RCOL         
         STA LCOL         
         BMI :SKIP        
         CMP #40          ;Check for benefit of SETPOINT
         BCC :SKIP        
         LDA X1           ;Set X in last column
         AND #$07         
         ORA #64-8        ;312+X AND 7
         STA X1           
         LDA #1           
         STA X1+1         
         JSR CHKCOM       
         JSR GETBYT       
CIRCENT                   ;Alternative entry point
         STX Y            
         STX RADIUS       
         BNE :C           ;Skip R=0
         LDX CY           
         JMP SETPOINT     ;Plot it as a point.
:C       CLC              
         ADC CY           
         BCS :BLAH        
         SBC ORGY         
         BCS :C4          ;cy+y<orgy implies circle off screen
:RTS     RTS              
:BLAH    SBC ORGY         ;Always positive
         BCS :C3          ;Handle overflow sneaky
:C4      TAX              
         CMP #200         ;If Y>200 then set pointer to
         BCC :C2          ;last row, but set TROW
         CLC              ;correctly
:C3      TAY              
         AND #$07         
         ORA #$C0         ;Last row, set Y1 correctly
:C2      ROR              
         STA TROW         ;Top row
         LDA #00          
         STA DONTPLOT     ;Don't plot points
         JSR SETPOINT     ;Plot XC,YC+Y
         STY Y2           ;Y AND 07
         LDA BITCHUNK,X   
         STA CHUNK1       ;Forwards chunk
         STA OLDCH1       
         EOR #$FF         
         STA CHUNK2       ;Backwards chunk
         STA OLDCH2       
         LDA POINT        
         STA TEMP2        ;TEMP2 = forwards high pointer
         STA X2           ;X2 = backwards high pointer
         LDA POINT+1      
         STA TEMP2+1      
         STA X2+1         
         LDA CY           ;Now compute upper points
         SBC ORGY         
         BCS :CSET        
         SEC              ;We are so very negative
         SBC Y            
         BCC :BNEG        
:CSET    SBC Y            ;Compute CY-Y-ORGY
:BNEG    PHP              
         LSR              ;Compute row
         STA BROW         
         BCS :CONT        
         ORA #$E0         ;Make row negative
         STA BROW         
         AND #07          ;Handle underflow special!
:CONT    JSR SETPOINT     ;Compute new coords
         STY Y1           
         LDA POINT        
         STA X1           ;X1 will be the backwards
         LDA POINT+1      ;low-pointer
         STA X1+1         ;POINT will be forwards
         SEI              ;Get underneath ROM
         LDA #$34         
         STA $01          
         LDA Y            
         LSR              ;A=r/2
         LDX #00          
         STX X            ;y=0
* Main loop
         INC X            ;x=x+1
         LSR CHUNK1       ;Right chunk
         BNE :CONT1       
         JSR UPCHUNK1     ;Update if we move past a column
:CONT1   ASL CHUNK2       
         BNE :CONT2       
         JSR UPCHUNK2     
:CONT2                    ;LDA TEMP
         SBC X            ;a=a-x
         BCS :LOOP        
         ADC Y            ;if a<0 then a=a+y; y=y-1
         JSR PCHUNK1      
         JSR PCHUNK2      
         LDA CHUNK1       
         STA OLDCH1       
         LDA CHUNK2       
         STA OLDCH2       
         DEC Y            ;(y=y-1)
         DEC Y2           ;Decrement y-offest for upper
         BPL :CONT3       ;points
         JSR DECYOFF      
:CONT3   LDY Y1           
         STY Y1           
         CPY #8           
         BCC :CONT4       
         JSR INCYOFF      
         LDY X            
         CPY Y            ;if y<=x then punt
         BCC :LOOP        ;Now draw the other half
* Draw the other half of the circle by exactly reversing
* the above!
         LSR OLDCH1       ;Only plot a bit at a time
         ASL OLDCH2       
         LDA RADIUS       ;A=-R/2-1
         EOR #$FF         
         JSR PCHUNK1      ;Plot points
         JSR PCHUNK2      
         DEC Y2           ;Y2=bottom
         BPL :CONT1       
         JSR DECYOFF      
:CONT1   INC Y1           
         LDY Y1           
         CPY #8           
         BCC :CONT2       
         JSR INCYOFF      
         LDX Y            
         BEQ :DONE        
         ADC Y            ;a=a+y
         DEC Y            ;y=y-1
         BCC :LOOP        
         INC X            
         SBC X            ;if a<0 then x=x+1; a=a+x
         LSR CHUNK1       
         BNE :CONT3       
         JSR UPCH1        ;Upchunk, but no plot
:CONT3   LSR OLDCH1       ;Only the bits...
         ASL CHUNK2       ;Fix chunks
         BNE :CONT4       
         JSR UPCH2        
:CONT4   ASL OLDCH2       
         BCS :LOOP        
CIRCEXIT                  ;Restore interrupts
         LDA #$37         
         STA $01          
         LDA #1           ;Re-enable plotting
         STA DONTPLOT     
* Decrement upper pointers
         LDA #7           
         STA Y2           
         LDA TROW         ;First check to see if Y is in
         BEQ EXIT2        
         CMP #25          ;range (rows 0-24)
         BCS :SKIP        
         LDA X2           ;If we pass through zero, then
         SBC #<320        ;subtract 320
         STA X2           
         LDA X2+1         
         SBC #>320        
         STA X2+1         
         LDA TEMP2        
         SBC #<320        
         STA TEMP2        
         LDA TEMP2+1      
         SBC #>320        
         STA TEMP2+1      
:SKIP    TYA              
         DEC TROW         
EXIT2    PLA              ;Grab return address
         JMP CIRCEXIT     ;Restore interrupts, etc.
* Increment lower pointers
         LDA #00          
         STA Y1           
         LDA BROW         
         BMI :ISKIP       ;If <0 then don't update pointer.
         CMP #24          ;If we hit bottom of screen then
         BEQ EXIT2        ;just quit
         LDA X1           
         ADC #<320        
         STA X1           
         LDA X1+1         
         ADC #>320        
         STA X1+1         
         LDA POINT        
         ADC #<320        
         STA POINT        
         LDA POINT+1      
         ADC #>320        
         STA POINT+1      
:ISKIP   TYA              
         INC BROW         
* UPCHUNK1 -- Update right-moving chunk pointers
*             Due to passing through a column
         JSR PCHUNK1      
UPCH1    LDA #$FF         ;Alternative entry point
         STA CHUNK1       
         STA OLDCH1       
         LDA RCOL         
         BMI :DONE        ;Can start negative
         LDA TEMP2        
         ADC #8           
         STA TEMP2        
         BCC :CONT        
         INC TEMP2+1      
:CONT    LDA POINT        
         ADC #8           
         STA POINT        
         BCC :DONE        
         INC POINT+1      
:DONE    TXA              
         INC RCOL         
* UPCHUNK2 -- Update left-moving chunk pointers
         JSR PCHUNK2      
UPCH2    LDA #$FF         
         STA CHUNK2       
         STA OLDCH2       
         LDA LCOL         
         CMP #40          
         BCS :DONE        
         LDA X2           
         SBC #8           
         STA X2           
         BCS :CONT        
         DEC X2+1         
:CONT    LDA X1           
         SBC #8           
         STA X1           
         BCS :DONE        
         DEC X1+1         
:DONE    TXA              
         DEC LCOL         
* Plot right-moving chunk pairs for circle routine
         LDA RCOL         ;Make sure we're in range
         CMP #40          
         BCS :SKIP2       
         LDA CHUNK1       ;Otherwise plot
         EOR OLDCH1       
         STA TEMP         
         LDA BROW         ;Check for underflow
         BMI :SKIP        
         LDY Y1           
         LDA (POINT),Y    
         EOR BITMASK      
         AND TEMP         
         EOR (POINT),Y    
         STA (POINT),Y    
:SKIP    LDA TROW         ;If CY+Y >= 200...
         CMP #25          
         BCS :SKIP2       
         LDY Y2           
         LDA (TEMP2),Y    
         EOR BITMASK      
         AND TEMP         
         EOR (TEMP2),Y    
         STA (TEMP2),Y    
* Plot left-moving chunk pairs for circle routine
         LDA LCOL         ;Range check in X
         CMP #40          
         BCS :SKIP2       
         LDA CHUNK2       ;Otherwise plot
         EOR OLDCH2       
         STA TEMP         
         LDA BROW         ;Check for underflow
         BMI :SKIP        
         LDY Y1           
         LDA (X1),Y       
         EOR BITMASK      
         AND TEMP         
         EOR (X1),Y       
         STA (X1),Y       
:SKIP    LDA TROW         ;If CY+Y >= 200...
         CMP #25          
         BCS :SKIP2       
         LDY Y2           
         LDA (X2),Y       
         EOR BITMASK      
         AND TEMP         
         EOR (X2),Y       
         STA (X2),Y       
* GRON -- turn graphics on.  If a number appears
* afterwards, then initialize the colormap to that
* number and clear the bitmap.
BASE     DFB $E0          ;Address of bitmap, hi byte
BANK     DFB 0            ;Bank 3=default
OLDBANK  DFB $FF          ;VIC old bank
OLDD018  DFB 00           
         LDA $D011        ;Skip if bitmap is already on.
         AND #$20         
         BNE CLEAR        
         LDA $DD02        ;Set the data direction regs
         ORA #3           
         STA $DD02        
         LDA $DD00        
         AND #$03         
         STA OLDBANK      
         AND #252         
         ORA BANK         
         STA $DD00        
         LDA $D018        
         STA OLDD018      
         LDA #$38         ;Set color map to base+$1C00
         STA $D018        ;bitmap to 2nd 8k
         LDA $D011        ;And turn on bitmap
         ORA #$20         
         STA $D011        
CLEAR    JSR CHRGOT       ;See if there's a color
         BEQ GRONDONE     
         JSR GETBYT       ;Get the char
CLEARCOL LDA #00          ;Low byte of base address
         STA POINT        
         LDA BASE         ;Colormap is at base-$14
         SBC #$14         
         STA POINT+1      
         LDY #00          
         LDX #4           
:LOOP    STA (POINT),Y    
         BNE :LOOP        
         INC POINT+1      
         BNE :LOOP        
         LDA BASE         ;Now clear bitmap
         STA POINT+1      
         LDX #32          
:LOOP2   STA (POINT),Y    
         BNE :LOOP2       
         INC POINT+1      
         BNE :LOOP2       
GRONDONE RTS              
* GROFF -- Restore old values if graphics are on.
         LDA $D011        
         AND #$20         
         BEQ GDONE        
GSET     LDA $DD02        ;Set the data direction regs
         ORA #3           
         STA $DD02        
         LDA $DD00        
         AND #$7C         
         ORA OLDBANK      
         STA $DD00        
         LDA OLDD018      
         STA $D018        
         LDA $D011        
         AND #$FF-$20     
         STA $D011        
GDONE    RTS              
* COLOR -- Set drawing color
         JSR GETBYT       
COLENT   CPX #00          ;MODE enters here
         BEQ :C2          
:C1      CPX #01          
         BNE :RTS         
         LDX #$FF         
:C2      STX BITMASK      
:RTS     RTS              
* MODE -- catch-all command.  Currently implemented:
*   00  Erase (background color)
*   01  Foreground color
*   16  SuperCPU mode -- screen -> A000, etc.
*   17  Normal mode
*   18  Double buffer mode
*  Anything else -> BITMASK
MODENUM  DFB 17           ;Current mode
         JSR GETBYT       
         CPX #2           
         BCC COLENT       
:C16     CPX #16          
         BNE :C18         
         STX MODENUM      
:SET16   LDA #$A0         ;Bitmap -> $A000
         STA BASE         
         LDA #01          
         STA BANK         ;Bank 2
         STA OLDBANK      
         LDA #$FF         ;End of BASIC memory
         STA $37          
         STA $33          
         LDA #$87         
         STA $38          
         STA $34          
         LDA #$24         ;Screen mem -> $8800
         STA OLDD018      
         JSR GSET         ;Part of GROFF
         LDA #$88         
         STA 648          ;Tell BASIC where the screen is
         STA $D07E        ;Enable SuperCPU regs
         STA $D074        ;Bank 2 optimization
         STA $D07F        ;Disable regs
:C18     CPX #18          ;Double-buffer mode!
         BNE :C17         
         STX MODENUM      
         JSR :SET16       ;Set up mode 16
         STA $D07E        
         STA $D077        ;Turn off optimization
         STA $D07F        
:C17     CPX #17          
         BNE MODEDONE     
         LDA #$E0         
         STA BASE         
         LDA #00          ;Bank 3
         STA BANK         
         LDA #3           ;Bank 0 == normal bank
         STA OLDBANK      
         LDA #$FF         
         STA $37          
         STA $33          
         LDA #$9F         
         STA $38          
         STA $34          
         LDA #$14         ;Screen mem -> $0400
         STA OLDD018      
         JSR GSET         ;Part of GROFF
         LDA #$04         
         STA 648          ;Tell BASIC where the screen is
         STA $D07E        
         STA $D077        ;No optimization
         STA $D07F        
* BUFFER -- Sets the current drawing buffer to 1 or 2,
*   depending on arg being even or odd.  If double-
*   buffer mode is not enabled then punt.
*   Now, buffer=0 swaps draw buffers, even/odd otherwise.
         JSR GETBYT       
         LDA MODENUM      
         CMP #18          
         BNE :PUNT        
         LDY #$A0         
         BNE :CONT        
         CPY BASE         
         BNE :CONT        
         LDA #1           
:CONT    LSR              
         BCC :LOW         ;even = low buffer
         LDY #$E0         ;odd = high buffer
:LOW     STY BASE         
:PUNT    RTS              
* SWAP -- Swap displayed buffers.  MODE 18 must
*   be enabled first.
         LDA MODENUM      
         CMP #18          
         BNE :PUNT        
         LDA $DD00        ;Ooooooohhh, real tough!
         EOR #$01         
         STA $DD00        
:PUNT    RTS              
* ORIGIN -- Set upper-left corner of the screen to
*   new coordinate offset.
         JSR GETBYT       
         STX ORGX         
         JSR CHKCOM       
         JSR GETBYT       
         STX ORGY         
         ORG              ;re-org
PEND                      ;To get that label right :)

The BLARG distribution binary is available from 'The Fridge', Mr. Judd's
archival web page on the internet at

/S02::$d000:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::

by Adrian Gonzalez (DW/Style) & George Taylor (Repose/Style)
         1         2         3         4         5         6         7


0.  Preface

1.  Introduction
     1.1  Target audience
     1.2  The legal stuff

2.  The NTSC Y/C video signal
     2.1  A little history
     2.2  A closer look at black and white TV
     2.3  Let's talk about color
     2.4  The chroma signal

3.  Wrapup


0.  Preface

This text was originally formatted to 78 columns for ease of use.  This
ensures compatibility with MSDOS "edit" with scrollbars, as well as 80 column
readers that cause double spacing if the 81st character is a carriage return.
The text is written in conversation style to ease the problem of dual
authorship.  Subsections not marked may be considered generic text and may
have been written by either of us.  You will not be able to view the ASCII
diagrams in 40 columns. Major headings are marked with ---'s.

1.  Introduction


While working on an image conversion project, I stumbled upon the need to
find RGB values for the c64's colors.  My first idea was using two monitors
and matching the colors "by eye", however, this turned out to be more
difficult than I expected.  After trying other methods I decided the next
logical step was to analyze the c64's output and determine the RGB values
from there.  Simple enough, eh?  The only problem was that I had no clue as
to what the VIC-II's output looked like.  After digging up some books on TV
theory, I decided to embark on a quest to find RGB values for the c64's
colors, and I found many interesting things along the way. 

This article is the result of many hours of research, programming, and taking
measurements.  I hope you find it interesting and perhaps even learn
something new from it (!).


Coincidently, I was working on exactly the same kind of image conversion
project.  So I got together with DW to discuss our common problem of finding
the RGB colors of the 64.  I also put out a request to comp.sys.cbm and was
sent measurements from several people, including an excellent effort from
Marko Makela.

1.1  Target audience

This article should be very interesting for people doing emulators, image
converters, and other similar projects.  Due to the rather technical nature
of its content, it is not meant for beginners, however, the end result could
be very useful for anybody interested in using other platforms to do
graphics work for the c64.  If you're not sure whether this article is for
you or not, here are some terms you should be familiar with:  scanline,
frame, refresh rate, CRT, RGB, vertical and horizontal blanking.  These terms
are used all throughout the article, and it is assumed you already have a
basic knowledge of how a TV works.

1.2  The legal stuff

Part of this article deals with taking measurements from your c64.  If you
decide to tinker with your c64 and something goes wrong, it's your fault, not
ours.  The authors will not be held responsible for damaged equipment, data
loss, loss of sleep, loss of sanity, etc.  Now, on with the show.

2.  The NTSC Y/C video signal

There's basically three ways you can connect your c64 to a TV or monitor and
get a color picture.  The first and perhaps the most common is to use the RF
modulated output with a TV tuned to channel 3 or 4.  The second and third
use the Video/Audio connector and require either a monitor or a TV/VCR with
A/V inputs.  We will get to each of these later on, but first, a little bit
of history.

2.1  A little history.


In 1953, the National Television Systems Committee (NTSC) developed a
standard that allowed the transmission of color images while remaining
compatible with the large amount of black and white TV sets in widespread use
at the time.   In the US, public broadcasting (using the color NTSC system)
began in 1954.  The same system was adopted in Japan, where it came into
service in 1960. Other countries favored modifications of the NTSC system,
such as PAL (Phase Alternating Line) and SECAM (Systeme Electronique Couleur
Avec Memoire).


PAL is used in many western european countries, and has technical advantages
to NTSC.  SECAM is used in eastern and middle eastern europe.  It is only a
semi standard in a way because video production is always done in PAL format,
and only converted to SECAM for final transmission.  The main point of this
was information control, as it offers no advantages over PAL.  As far as I
know, VIC IIs were only made to conform to PAL or NTSC standards.

2.2  A closer look at black and white TV.

In designing a TV system, the engineers had to make several considerations.
One had to do with bandwidth, which is the space that a TV channel takes in
the radio frequency spectrum.  To allow for many channels, and also to be
easy for the ancient technology of that time, it was decided to split up the
picture into two parts, and send each half sequentially.

The display on your TV is made up of a several hundred scanlines, composed
of two fields which are interlaced to form a complete display, called a
frame.  This interlacing doesn't happen on the c64, but we will get to that
later.  First let's look at the fields:

Odd field                                Even field

                                     Scanline     1 +++++++++++++++++++++++
Scanline   2 ----------------------
                                     Scanline     3 +++++++++++++++++++++++
Scanline   4 ----------------------
                                     Scanline     5 +++++++++++++++++++++++
Scanline   6 ----------------------      .
.                                        .
                                     Scanline 2*n-1 +++++++++++++++++++++++
Scanline 2*n ----------------------
                                     Scanline 2*n+1 +++++++++++++++++++++++

Each of the fields is 262 1/2 lines long (NTSC), (312 1/2 PAL) which means
each frame is 525 (625 PAL) lines long.  Your TV displays odd fields and
even fields one after another, and thanks to what is called "persistence of
vision" we see something like:

Scanline     1 +++++++++++++++++++++++
Scanline     2 -----------------------
Scanline     3 +++++++++++++++++++++++
Scanline     4 -----------------------
Scanline     6 +++++++++++++++++++++++

The second consideration the engineers had was how to represent a 2d image as
a 1d voltage.  To do this, they needed markers to separate a horizontal line
and also odd and even fields.

So, let's take a closer look at what the voltage waveform for black and
white scanlines looks like:

^  Voltage
|             Scanline n                                  Scanline n+2
|          ___________________________________         _________________..
|         |   White level                    |         |
|         |                                  |         |
|         |                                  |         |
|         |                                  |         |
|         |                                  |         |
|___  ____|   Black level                    |___  ____|
|  |  |                                         |  |
|  |__| <- Horizontal sync pulses ------------> |__|

The scanline in this example is a simple white line.  If you were to feed
enough of  these  to  your  TV  plus  some vertical sync signals, you would
get a white screen.  The horizontal sync pulses tell the TV receiver when a
scanline starts.  They  make  up  25% of  the  total  height  of  the signal.

The brightness at a particular point of the scanline is defined by the
voltage of  the  waveform  at that instant.  With this in mind, if we wanted
to create a display with a simple white vertical line at the middle of the
screen, the waveform would look like this:

^  Voltage
|                   Scanline n                              Scanline n+2
|                        __                                           __
|           White level |  |                                         |  |
|                       |  |                                         |  |
|                       |  |                                         |  |
|                       |  |                                         |  |
|           Black level |  |                                         |  |
|___  __________________|  |_____________________  __________________|  |
|  |  |                                         |  |
|  |__| <- Horizontal sync pulses ------------> |__|

Let us now turn our attention to the visible display area on your TV:

___                                                          ___
 |        XXXXXXXX                                               ^
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 | Field  XXXXXXXX                                               |
 | period XXXXXXXX                                               |
 | (60hz) XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
 |        XXXXXXXX                                               |
_v_       XXXXXXXX                                              _v_
           17% of                  83% of line
           line                    is visible
                      Line period: 63.5 microseconds

The X's in the graph represent areas in which the in which your screen is
not visible.  At the top we have the vertical blanking interval, and at the
left we have the horizontal blanking interval.  Please note that whether
these intervals occur at the top or bottom, left or right or both, is not
relevant. It is shown this way in the diagram for the sake of clarity. So,
with that out of the way, let's see what happens in the vertical blank
interval (vblank from now on):

^ Voltage
|    last                                                        time   ---->
|    scanline
|  __ _______ ___ ___ ___ ___ ___ __                            _ ___ ___ _..
|    |       |   |   |   |   |   |  |    |   |   |   |   |   | | |   |   |
|    |       |   |   |   |   |   |  |____|___|___|___|___|___|_| |   |   |
     ^       ^                                      ^            ^
Horizontal   End of even field         Serrated vertical sync    6 equalizing
sync pulse   6 equalizing pulses       pulse                     pulses

Please note that the time scale has been compressed to be able to cover most
of the vblank interval.  Basically the vblank interval is composed of 6
equalizing pulses, one serrated vertical sync pulse, and 6 more equalizing
pulses.  The equalizing pulses and the serrations in the vertical sync pulse
are spaced half a scanline apart.  An interesting thing happens if we take
away the equalizing pulses and serrations:

^ Voltage
|    last                                                        time   ---->
|    scanline
|  _________________________________                            ___________..
|                                   |                          |
|                                   |__________________________|

                                       Vertical sync pulse

We end up with a vertical sync pulse that looks very much like the
horizontal sync pulses, except it runs at a much lower frequency.  In NTSC,
the field frequency is 60 Hz, and the frame frequency is 30hz (PAL has a 50Hz
field rate and 25Hz frame rate).   In other words, we get one of these
vertical pulses on every field, to let the TV know when the field starts
(just like the horizontal sync pulses tell it when a line starts).  According
to an old book on TV theory, "serrations are placed in the vertical sync
pulse to stabilize the operation of the horizontal scanning generator during
vertical retrace time".

One last thing remains before we move on to color television: interlacing.
Interlacing is achieved by making the field size 262 1/2 lines long, which
also changes the spacing between the equalizing pulses and the vertical sync
pulse. It will not be discussed any further, though, because the c-64's
output is not interlaced.  Instead, it is composed of always fields, thus
there are visible spaces between the scanlines.  The field rate may be
considered also the frame rate, since one field is a complete image in

Note:  it is not known to us if the c64 produces even or odd fields.

2.3  Let's talk about color.

Up until now, we've only talked about black and white TV signals, but if you
remember the little bit of history in section 2.1, you know that color has
to be introduced in a way that doesn't interfere with the BW signal.  The
VIC-II really outputs two signals (NTSC version only):  the Luminance (Y)
signal and the Chrominance (C) signal.  The Y signal contains the brightness
information of the output, while the C signal contains color information.
The Y signal is just like the one described in the previous section, except
it is not interlaced.  The c64 has circuitry to mix the Y and C signals into
a composite video signal which has both BW and color info.  It then goes to
an RF modulator which allows these signals (plus audio) to be viewed on a TV
tuned to channel 3 or 4 (in the North American TV frequency).

Before we move on to describe the color signal, we will talk briefly about
RGB.  RGB stands for Red Green Blue, or in other words, a set of three
primary colors, which are mixed in different amounts in order to obtain a
broad gammut (range) of colors.  An interesting thing to note is that it is
impossible to reproduce the entire spectrum of visible light with a set of
three (or any finite number) of real primary colors, however, RGB and other 
color systems do a fair job of being able to represent typical images.
RGB color is probably quite familiar to you, as it is the basis of the video
circuitry in most computers and their monitors.  However, NTSC/PAL signals
use an encoding called YUV.  Y is the brightness information, while UV are
the C or color information.  U and V are components of a vector.  You can 
picture this vector as originating from the centre of a circle.  It's angle
is the tint of the color, and it's radius is the saturation of the color.
The angle represents a full sprectrum, from red, to orange, yellow, green,
blue, purple, back to red again.  A highly satured color will be pure, while
no saturation would give a grey.  There are usually controls related to these
properties on a TV, called tint and color, or hue and saturation.

2.4  The color signal

Color was added to B/W NTSC in a very clever way.  It was added as a carrier
on top of the normal signal.  It is basically a sinewave of 3.574545Mhz
(NTSC) (4.43Mhz PAL) with a varying phase and amplitude.  To a B/W TV, this
will be seen as a fine wavey detail in the luminance.  But, a color TV uses a
filter to separate the high frequencies as the color signal, and pass on the
lower frequencies as the normal B/W signal.  This separation is not perfect,
and can cause several strange effects on the picture, known as "crawling
dots", "hanging dots", and "color moire patterns" (NTSC, similar effects may
appear in PAL).  That is why, coincidently, the S-VHS format was invented, to
physically separate the color signal from the luma signal.  One question,
that may have occurred to you, is how do you measure phase without a
reference point?  Fortunately, at the start of every rasterline there is a
calibration color signal known as the color burst, and from this sinewave,
the phase of the color signal is measured.

The sinewave then continues, at the same time as the luminence portion of 
rasterline is sent, both signals varying to specify a color and luminance.

  *   *           *
 *     *         * 
 *     *         *
*-------*-------*----> Time
         *     *
         *     * 
          *   *
ColorBurst Reference Signal

    *   *
   *     * 
   *     *
--*-------*-------*--> Time
 *         *     *
 *         *     * 
*           *   *
An Orange color 30 degrees
out of phase with ColorBurst

3.  Wrapup

For now, we will end here.  Look forward to a second part, which will 
describe the signals as measured on the 64 in more detail, and finally 
provide the most accurate measurements of the 64's 16 colors known.  One 
important point which will be explained is how gamma affects RGB color 
measurements, and why any measurement must be given with gamma information,
and why putting the same RGB values into two different monitors will not 
cause the same colors to be seen.

Also provided will be a program which can display the 64s colors on a PC and
let you play with hue and saturation controls.  When our measurements are
finalized, we would expect all emulator writers to add our calibrated 
colors to their programs, so that the original feeling of the 64 can be

Please see
for up to date information.


Introduction to Digital Video, Charles Poynton. FAQ.
Television Theory and Servicing, second edition.  Clyde N. Herrick

/S03::$d000:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::
                        : Innovation in the 90s :
Revisiting The Super Hi-Res Interlace Flexible Line Interpretation Technique

         by  Roland Toegel (Crossbow/Crest), Count Zero/TRC*SCS, and
             George Taylor (

Prelude from George Taylor, technical editor
Once you have FLI, why not just overlay some sprites on it to make better
graphics?  A simple idea you may have thought of, but as you will see,
implementing the concept was very difficult.  There are two key concepts
to making it work.  The following article is a brilliant piece of work on
the subject.  It was presented in disC=overy (issue 2) and subsequently
raised a great deal of discussion.  There are some confusing concepts
involved so I have added extra interpretation to the original text as
as editorial notes, which I hope will help bridge the gap from foreign
language translated text and difficult explanations.
Prelude from Count Zero

First seen earlier this year, the new SHIFLI video technique that is described
in this article is -the- paramount example of programming brilliance.  The
inventor of the technique, Roland Toegel (Crossbow of Crest), was helpful
in providing the original SHIFLI documentation, which I translated from 
German into the English text that follows for the exclusive use of the
disC=overy journal.

So without further ado, let us now learn from Mr. Toegel how to achieve
the award winning :
   'Super Hires InterLace Flexible Line Interpretation' Graphics mode !
Please note that the technique is described primarily for Commodore computers
based on the European/Australian PAL TV standard. NTSC-based Commodore machines
require an extra 2 cycles per line to be added to the raster routine.  
This may require the programmer to time out the routines by hand, but this
should not be a major obstacle to overcome.
Count Zero
i.      Foreword
As the inventor of the SHI-FLI mode, I am pleased to have the services of
Count Zero and the disC=overy journal for the dissemination of my technique
into the English language.  I must add that the text below does require the
reader to be already familiar to a high degree with VIC-II programming on the
C64.  I would suggest books such as 'Mapping the 64' and the programming texts
found at, for a solid base of instruction.  Also,
some terms used in this document (e.g., mix-color) are meant to be uniquely
descriptive and hence, will not be found in any 'standard' programming text.
The terminology is a result of the strain that occurs when new methodology
meets old semantics.  However, the experienced programmer should find the
words to be self-evident in the context which they are used.

[Mix-color: a new color derived from the original 16 by the process
of alternating normal colors at such a high rate of speed that they
blend to the eye.  Also know as flashcolors. -GT]
1.      Introduction to Super Hires

[Hires FLI: a graphics mode which uses rasters to enable the use of a separate
color memory on each line, thus giving 2 colors chosen freely in each
8x1 hires pixel area. Interlace: alternating any two graphics modes to allow
the use of mix colors. FLI without the 'hires' modifier usually means
the use of the FLI technique with a multicolor mode as the basis.  Super
Hires FLI might be more aptly named as Sprite Hires FLI, but the super means
that sprites are overlayed on top of another graphics mode. -GT] 

Super-Hires Interlace FLI : The absolute successor of the Super-Hires-Modes.
Just like normal Super-Hires, the width is 96 Hires Pixels, which is equal to
12 Characters or 4 Sprites next to each other.  For visual enjoyment this
area is centered though using Char-Position 15 to 26 inclusive on the
screen.  The Y-Axis is 167 pixels high having nearly 21 Character lines or
8 Sprites and to have as much flexibility as possible on choosing colors or
pixels, 2 layers of sprites in a row of 4 beside each other are used
(8 sprites on the rasterline) over the bitmap graphics.  Due to the fact that
all 8 sprites are used for a 96 * 21 pixel-wide area, a small multiplexer is
needed to repeat the 8 layered sprites for 8 times, at 21 pixel intervals as
you go dowards on the screen, with each row using their own bitmaps.  
We thereby win 2 colors plus the 2 normal colors of the Hires-Bitmap Mode 
in an 8*8 pixel block.  Please note that the 2 additional colors
are the same throughout the whole picture.
2.      Super Hires with FLI !?!
FLI is, for most coders, still quite hard. Sprites over FLI, for most, quite
impossible. Maybe one or two sprites, but 8 !?! next to each other and
still FLI in each rasterline!  Hard to believe, eh?
First of all you need to know how to do FLI and what it does and also
what effect sprites have on it.
2.1     Normal FLI
On each eighth rasterline (the Badlines, the first rasterline of each charline)
the VIC stops the processor for 40-43 cycles to read the new Characters and
colors of the video and color-ram.  This is the case when the bits 0-2 of the
registers $D011 and $D012 are the same.  Now if you change on each rasterline
the bits 4-7 of $D018, which holds the length of the video-ram (handling the
colors on bitmap graphics) and set the bits 0-2 of $D011 to get a badline on
each rasterline, you will get new colors on each rasterline in the bitmap
graphics.  The only condition to be followed is that on each rasterline 23
cycles are used but for the *used cycles - 22* char of the textline the
next 3 chars have the byte $FF (light grey) read from the video ram and the
FLI effect starts after that (the FLI bug).  In the multicolor mode, for the
color-ram the next byte in the program after writing to $D011 is chosen as
the color.  As we are using the Hires Mode here, this is irrelevant.
> NOTE: The last 3 sentences were pretty hard to translate and I advise you
>       to read other articles about FLI aswell, if you want to know more
>       about Multicolor FLI. (CZ)
2.2     Sprites over FLI
So what does a sprite do over FLI?  Pretty simple, as it just eats up some
cycles.  All 8 sprites use 19 cycles per rasterline, meaning in the case where 
we code our FLI routine without loops, we just need 2 x (LDA, STA) commands 
(for $D018 and $D011), using 12 cycles per rasterline.  All together with the
8 used sprites that makes 31 cycles.  Thus, the 'light grey' FLI-Bug occurs on
char-positions 9,10 and 11 and from char 12+, the FLI effect comes up.  This
doesn't matter much to us, as the Super Hires Picture starts at Char-Pos 15.
We therefore get 3 cycles per rasterline for other commands.

[The explanation of when the FLI effect starts in 2.1 was unclear.  Here
we can understand that the effect starts 3 cycles after the write to $d011.
The only catch is that this code is delayed by the extra DMA time used by
the sprites.  Thus the formula (12+19)-22=9 gives the start of the grey
pattern, and 9+3=12 is the start of the FLI effect.  The constant 22 comes
from a measurement of when the CPU continues after DMA is released, relative
to the position on the raster line. -GT]

3.      Mulitplexing over FLI
Now we have to increase the Y-Coordinates of the sprites by 21 pixels
each 21 rasterlines and give them new patterns.  As we use 8 different
video-rams on FLI for the colors and the sprite-pointers are always at the
end of the video-ram, we are supposed to write 8 * 8 values for the patterns
plus 8 values for the Y-Coordinates, resulting in 72 different addresses.
Thats far too much for a single rasterline and adding the FLI routine will
bust the limits.  Therefore we have to do a little trick.
3.1     Changing the sprite-pointers

The trick is not to change anything at all!  On the other hand we don't want
the patterns to look the same everywhere.  Luckily, the height of a sprite
(21 pixels) is not capable of being divided by the height of a textline
(8) and the smallest mutual multiple is 168 (meaning 21 * 8).  As we are
writing (due to the FLI) a new value to $D018 on each rasterline and we use
8 video rams, we can abuse this and have different sprite-pointers on every
video-ram.  The handling of where the graphics for the sprite-patterns are
located becomes a little bit confusing, but it doesn't eat up any rastertime
as we don't have to change the pointers.

[Put another way, we take advantage of the fact that the video
matrix location is changing every raster line (and therefore also the
sprite pointers at the end of the video matrix), and slice up the sprites
so that the bitmap definition is located in a different place in memory
for each line of the sprite.  This is very confusing, and the graphics
are spread throughout memory in essentially random locations to make
them fit around the other graphics areas.  But at least it is possible
to give every part of every sprite a separate bitmap without changing
sprite pointers at all, and is the first key concept to making this
technique work, and a brilliant invention by Mr. Togel. -GT]

3.1.1   Table to illustrate the sprite pattern-handling
Spriteline      Video-Ram     Screenline (NOT equal to rasterline!)
1               1             1
2               2             2
3               3             3
4               4             4
5               5             5
6               6             6
7               7             7
8               8             8
9               1             9
10              2             10
11              3             11
12              4             12
13              5             13
14              6             14
15              7             15
16              8             16
17              1             17
18              2             18
19              3             19
20              4             20
21              5             21
1               6             22
2               7             23
3               8             24
4               1             25
.               .             .
.               .             .
.               .             .
20              1             41
21              2             42
1               3             43
2               4             44
3               5             45
.               .             .
.               .             .
.               .             .
3.1.2   Example
Small example for Sprite 0 under the following conditions:
Used 8 Video-Rams            : $4000 - $5FFF
content of the sprite-pointer: $43F8  80 00 00 00 00 00 00 00
                               $47F8  81 00 00 00 00 00 00 00
                               $4BF8  82 00 00 00 00 00 00 00
                               $4FF8  83 00 00 00 00 00 00 00
                               $53F8  84 00 00 00 00 00 00 00
                               $57F8  85 00 00 00 00 00 00 00
                               $5BF8  86 00 00 00 00 00 00 00
                               $5FF8  87 00 00 00 00 00 00 00
Thus the Sprite-Patterns are in memory from $6000-$61FF.
Therefore the pattern-handling looks like this:
Screenline      Memorylocation
1               $6000-$6002
2               $6043-$6045
3               $6086-$6088
4               $60C9-$60CB
5               $610C-$610E
6               $614F-$6151
7               $6192-$6194
8               $61D5-$61D7
9               $6018-$601A
10              $605B-$605D
11              $609E-$60A0
12              $60E1-$60E3
13              $6124-$6126
14              $6167-$6169
15              $61AA-$61AC
16              $61ED-$61EF
17              $6030-$6032
18              $6073-$6075
19              $60B6-$60B8
20              $60F9-$60FB
21              $613C-$613E
22              $6180-$6182
23              $61C3-$61C5
.               .
.               .
.               .
3.1.3   Remark to the display-routine of the editor
As the changing of the video-ram on the editor-routine happens inside of the
textscreen (but the spritepointers are read inside the sideborder), the change
takes effect one rasterline later.  

[To state this again, the changes in the raster routine are made at a time
when the sprite pointers have already been read by the VIC, therefore,
even though the changes are made on the same raster line, they don't
take effect until the next raster line. -GT]

This means that whenever the colors for the bitmap of color ram 2 are read,
the sprite pointers or video ram 1 are still active.  This is the reason why
the editor uses only 167 screenlines (instead of 168) and why the first
textline of the first video-ram and the first rasterline of the bitmap
stays empty.

[I would consider this a minor bug which potentially could be fixed in
a future version, by starting the raster routine one line earlier. -GT]

3.2     Changing the Sprite Y-Values
As the changing of the sprite pointers more or less happens by itself, we just
have to make sure the correct Y-Value comes into the game.  These are still
8 values, but they don't have to be set in one rasterline and we got 21
rasterlines to set them.  As we have just 3 cycles left on each rasterline on
the FLI routine described and that wouldn't be enough for a simple LDA : STA,
we have to change the FLI routine a little bit.
3.2.1   Load new sprite Y-Value
As the height of all sprites is the same, we just have to do a single
LDX #$VALUE.  Therefore, 2 of the 3 free cycles are used and we cannot do
anything else with the last free cycle.
LDA #$08
STA $D018
LDA #$38
STA $D011
3.2.2   Preload the Upcoming $D011 Value
As a STA $SPRITE0Y needs 4 cycles, we cannot include it in the next rasterline,
but we can already load the next $D011 value into the Y-Register.  The free
cycle stays unused.

LDY #$3A
LDA #$18
STA $D018
LDA #$39
STA $D011
3.2.3   Write new Sprite Y-Value
As we already did the loading of the $D011 value for the next line, we now
have 5 cycles left and therefore enough time for a STA $SPRITE0Y.
LDA #$28
STA $D018
STY $D011
Now plot 3.2.2 and 3.2.3 have to be repeated for the remaining 7 sprites with
changed values for $D011 and $D018.  So there is now 1 rasterline for loading
the new sprite Y-value and 8 * 2 rasterlines to write the new sprite Y-Value.
We now have 17 rasterlines and the 4 remaining ones just need an additional
NOP so that all rasterlines use the same amount of cycles.

[This tricky piece of raster code is the second brilliant concept to
making the technique work.  Note also that there will be some staggering
in the timing of FLI effect, due to the unused cycles, but still
within the parameters required.  Also it seems that parts of the
row of 4 sprites in 2 layers would gradually be moved downward after
parts of them have already been drawn, therefore causing a repetition
of graphics, except for the fact that the sprite pointers are different
in the new position, and that the sprites are really sliced apart in
lines, so it doesn't matter.  I find this a very difficult concept. -GT] 

3.2.4   Remark to the Display-routine of the editor
For simplification of the routine, which generates the FLI routine, in the
remaining 4 rasterlines an LDX #$VALUE was used instead of an NOP.
4.      Memory-allocation

Now video-rams, the bitmap, and the sprites have to be placed reasonably in
a VIC-Bank.  As the banks from $0000 - $3FFF and $8000 - $BFFF are useless
for graphics due to the overlay of the Char-rom we choose the back from
$4000 - $7FFF for now.
4.1     Video-rams
The 8 video-rams need $2000 Bytes.  They are located from $4000 - $5FFF.

4.2     Bitmap
The bitmap needs $1F40 Bytes.  It's located at $6000 - $7F3F.
4.3     Sprites
As we need 2 sprites overlayed {two layers of 4 sprites next to each other}
(four times next to each other and 8 times below each other), we need
2 * 4 * 8 sprites, meaning 64 overall.  We need $1000 bytes for the
sprites.  We check what the video-rams and the bitmaps already allocate
and recognize that only $7F40 - $7FFF, enough memory for 3 sprites, is
left open.  How do we rectify this situation?
As the video-rams and the bitmap just need a small part for displaying the
picture, the sprites can be put into the spare parts of the video-rams and
the bitmap.  They have to be masked by choosing the right color in the video-
A textline of a bitmap covers $140 bytes.  Our Super Hires cutout just needs
$60 bytes though and is centered.  Thus the first and the last $70 bytes of
a textline of the bitmap is free.  As a sprite needs $40 bytes, we can put 2 
sprites in each textline of the bitmap (one to the left and one to the right).
Due to the height of the picture (21 textlines), this results in space for
42 sprites.  From textline 22 on (in memory from $7A40) we can use the whole
textline for sprites, resulting in 5 sprites per line.  Continuing this until
textline 24 inclusive, we have space for 15 additional sprites.  So overall
we already have 57 sprites and just 7 are missing now.  These we could place
in the remaining free area of the bitmap ($7E00-$7FFF), but that's not very
efficient as we have some space left in the video-rams.
The Textline of a video-ram contains $28 bytes.  The Super Hires cutout just
needs the middle $0C bytes.  As the sprites we put to the left and to the right
of the picture are supposed to be invisible, we need to set a background-color
in the video-ram (in our case, the color light-grey $FF).  So we don't have
enough spare room for the sprites to the left and the right of the picture
in the video-ram.

If we finish the FLI Routine from textline 22 on and keep the video-ram on
until the end of the screen (filling the this area ($4370-$43E8) with the
backgroundcolor $FF to hide the sprites) we can use the remaining 7 video-rams
from textline 22 (from $4770, $4B70, $4F70, $5370, $5770, $5B70, $5F70) for
one sprite each.  Now we have placed all 64 sprites and the allocation of the
sprite pointers looks like this:
$43F8  80 84 85 89 8A 8E 8F 93
$47F8  94 98 99 9D 9E A2 A3 A7
$4BF8  A8 AC AD B1 B2 B6 B7 BB
$4FF8  BC C0 C1 C5 C6 CA CB CF
$53F8  D0 D4 D5 D9 DA DE DF E3
$57F8  E4 E8 E9 EA EB EC ED EE
$5BF8  EF F0 F1 F2 F3 F4 F5 F6
$5FF8  F7 1E 2E 3E 4E 5E 6E 7E
The pointers from $80 to $E4 are the 2 sprites which are left and right
next to the picture in the bitmap.
The pointers from $E8 to $F7 are the sprites from textline 22 to 24 below
the picture in the bitmap.
The pointers from $1E to $7E are the sprites from textline 22 to 24 below
the picture in the video-rams.
5.      Interlace
Until now we had the normal Super Hires FLI mode, supplying the basics for
interlace.  For the interlace mode we need 2 pictures of this kind switching,
displayed 25 times per second (PAL).  [30 times/sec in NTSC -GT]  As such
a picture fits into the VIC-Bank from $4000 - $7FFF and we have another
VIC-Bank ($C000-$FFFF) with the same assumptions we can easily place the
2nd picture there.
We had in the Super Hires FLI mode (on a 8 * 1 pixel-area) the choice between
4 colors (2 sprite-colors, being the same for the whole picture + 2 FLI
colors).  Now, in the interlace mode, we have the choice between 16 mix-colors,
meaning the combined 4 colors from picture one and two.  When using interlace,
mix-colors are created except for the case when the same colors are used for
both pictures on the same 8 * 1 pixel-area (Check the following example) :
      Pic2 ->        Sprite1:$E [ Sprite2:$0 [ FLI1:$6 [ FLI2:$9
Pic1    Sprite1:$1  [   $1E     [    $10     [   $16   [   $19
  [     Sprite2:$3  [   $3E     [    $30     [   $36   [   $39
  V     FLI1   :$E  [   $EE     [    $E0     [   $E6   [   $E9
        FLI2   :$6  [   $6E     [    $60     [   $66   [   $69
This results in the following 16 mixcolors:
 1. White-Lightblue
 2. Cyan-Lightblue
 3. Lightblue-Lightblue (pure Lightblue)
 4. Blue-Lightblue
 5. White-Black
 6. Cyan-Black
 7. Lightblue-Black
 8. Blue-Black
 9. White-Blue
10. Cyan-Blue
11. Lightblue-Blue
12. Blue-Blue (pure Blue)
13. White-Brown
14. Cyan-Brown
15. Lightblue-Brown
16. Blue-Brown
When choosing the colors you should take care that the brightness-values of
the 2 mix-colors are about the same and that they do not differ by more than
2 brightness steps, as things otherwise start to flicker too much.
(e.g. Black-White flickers a lot).
Here is a table with brightness-values from light to dark.
(Colors on the same line have the same brightness)
$1     : White
$7, $D : Yellow, Lightgreen
$3, $F : Cyan,   Lightgrey
$5, $A : Green,  Lightred
$C, $E : Grey,   Lightblue
$4, $8 : Lilac (Purple), Orange
$2, $B : Red ,   Darkgrey
$6, $9 : Blue,   Brown
$0     : Black

[On very old 64's (64 cycle raster line NTSC VICs), there are only 5 luminance
values in the 16 colors, making them less distinct.  Yellow and cyan are
the same brightness, then green, grey, and purple, then red and blue.  White
and black form the last 2 values of brightness.  The pairing of colors above
are included. -GT] 

6.      Additional Graphics (Not handled by the editor)
We found out that on the left or right of the picture in the bitmap, $70 bytes
was left for spritedata.  We used just $40 bytes of that space, meaning we
still have $30 bytes (6 Chars or 48 Pixels) left to both sides of the picture.
6.1     Left to the picture
Our Super Hires Picture starts at position 15.  The spare $30 bytes are from
position 9 to 14.  As we use 14 cycles in our FLI routine and the 8 sprites use
19 cycles per rasterline, the light-grey FLI Bug now uses the chars 11, 12, 14.
Thus meaning we could use char 14 for Hires FLI.  On chars 9 and 10 we could
just use 2 different colors (respectively 4 mix-colors for interlace) on the
height of 21 textlines in the bitmap, as the FLI effect starts from Char 14 and
before that no new data (colors in this case) are read from the video-ram.
The colors are in the first video-ram in memory from $4008+$4009 respectively

[The shifli pic could probably be expanded by rearranging the raster
code very carefully, and even areas outside the shifli effect could still
use normal graphics modes, but I expect only a small improvement. -GT] 

6.2     Right to the picture
Our Super Hires Picture lasts until char-position 26.  The spare $30 bytes in
the bitmap are from position 27 - 32.  Here we could use all 6 chars for Hires
FLI (or Interlace Hires FLI).
7.      Memory-allocation of a picture startable with RUN
The included SHIFLI picture, once unpacked, can be easily modified for your own
use, as follows :
$0801-$080C Basic Startline
$080D-$0860 Routine for copying the Graphic-data to the correct memory area
$0861-$095B Routine which is setting the I/O registers and creates the
            display-routine (from $085F-$10FB)
$095C-$475B Data of the 1. Picture (to be copied to $4000)
$475C-$855B Data of the 2. Picture (to be copied to $C000)

8.      Conclusion
For questions or comments concerning this article :
Roland Toegel is available at      :
Count Zero/TRC*SCS is available at :

/S04::$dd00:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::

                   Defeating Digital Corrosion (aka "cracking")

                    - a beginners guide to software archiving

                      By Jan Lund Thomsen (aka QED/Triangle)

   Pontus Berg briefly touched the subject of tape cracking in his disC=overy
1 article (/S08: Software analysis and reconstructive therapy, a historical
view on "cracking"). But then again, "great minds think alike". :)
   The purpose of this article is to provide a broader, more detailed view at
the general components - as well as some insight on the way a cracker did his
"thing" back in the old days. Although some degree of technical knowledge is
required to make the most of this article the casual C64 enthusiast should also
be able benefit from it.

   Despite the issues discussed in this article it is in no way written to
encourage software piracy. You are not allowed to use the knowledge found here
to make copies for other people. If you go ahead and do this despite what I
have just said it is not my problem and I can't be held responsible in any way.

[Ed. note : As always, disC=overy and the editors and staff of disC=overy can
 not be held responsible for the use or misuse of any information presented
 in this article.]

   In a world of digital corrosion the need to create backups is something
most of us deal with sooner or later. You might never have had any problems
yourself - but tapes or disks have been known to "go bad". And what if your
tape deck suddenly blows up, rendering you unable to play your favourite games?
Wouldn't it be nice to have a backup? Some people (myself included) prefer
using the backup copy and storing the original in a safe place. Copies can be
stored on floppy disks or hard drives for easier/faster loading. Creating an
exact copy of a backup is not only very easy; it eliminates the risk of
losing data due to corroded tapes.

   Yes, the techniques described here are exactly the same as software pirates
have been using since the dawn of time; defeating a protection scheme in order
to create something that can easily be backed up. This article is *not* about
Software Piracy (and I will not answer any comments on that issue). I strongly
believe that owners of original software have every right to create backups. 

   During the course of this article I will be looking into the specifics of
transferring original tape software to disk. I have several reasons for
choosing the subject of tape rather than disk software:

 - I have far more tape originals than disk originals. (I.e. more research

 - From a beginners point of view, Tape software is far easier to crack.

 - Disk originals are easier to reproduce, and therefore not as vulnerable to
   digital corrosion as tapes.

   Apart from a tape deck and one or more original tape programs it goes
without saying that a good deal of 6510 Assembly skills are required to be
able to be a successful cracker. A good cartridge is really a must as well.
I prefer the Action Replay Mk V or the Expert V4.2 due to their awesome
debugging features.

Why don't I just use the backup option in my cartridge?
   To be able to answer this question we need to go back in time and take a
look at the C64 crackers of yesteryear. As different people all over the world
were pirating software, cracking soon became a quest for quality rather than
quantity. Of course some people cared less about quality and more about
releasing a steady stream of software.
   A real cracker didn't care about speed. Any cracker could produce a working
copy in a couple of hours - but the real cracker wasn't satisfied with just
producing a "working copy". Why would anyone capable of doing a *great* crack
settle for less? For some crackers "good" simply wasn't good enough. Bugs were
fixed, cheat modes installed, and excess data was surgically removed to
produce shorter, cleaner cracks.
   Real cracking is about technical achievement, pride, dignity, and a
dedication to quality. Needless to say, no cracker worth his salt will want
to freeze/backup anything. I, for one, have never used this feature of my
Action Replay - not even for the purpose of producing copies for my eyes only.

   Although a backup created with the "backup" option of the Action Replay,
Expert, or any other freezer cartridge might run just fine, it can *never* be
as good as the result produced by a dedicated cracker who knows what he is

   In short: *Anyone* can press a button.

Getting started
   As this article is aimed at the beginner level we will only deal with
"single-loaders" - i.e. programs loaded into memory in a single pass. Programs
using additional I/O (highscore savers, intermission screens, levels, etc.)
are known as "multi-loaders" and will be briefly mentioned in chapter 5: What's

   Cracking (let's not beat about the bush and call it something else just to
be politically correct) a tape game boils down to the following four steps:

       1) Transferring the loader to disk.
       2) Analysing the loader.
       3) Modifying the loader and pulling the files off tape.
       4) Wrapping up.

Chapter 1: Transferring the loader to disk  (or "One small step...")
   By definition, copy protection prevents the user from duplicating a piece
of software. In the case of tape software programs are stored in a non-standard
format, incorporating a fast loader of some sort. The "loader" - a short
assembly program at the start of the tape contains the program code necessary
to load the rest of the data. As the loader is stored in the standard tape
format it is fitted with an autostart feature to prevent tampering.

   Therefore, the first step to transferring a tape original to a copyable
form is to load the "Loader" program *without* starting it. Luckily Commodore
themselves come to our rescue with the following ROM routines:

        Decimal  Hex.    Description
        #63278   $F72C   Read program header off tape
        #62828   $F56C   Read rest of program off tape

By inserting a tape and issuing the 'SYS 63278' command the program header
will be read into the tape buffer at $033C-03FC. The first bytes of a typical
program header will look something like this:

   .:033C 03 A7 02 04 03 4C 4F 41 .....LOA
   .:0344 44 45 52 00 00 00 00 00 DER.....

As you might have noticed, the filename is stored from $0341 onwards. However,
the five bytes from $033C-0340 are of much more interest to us. The first
byte describes the type of header: in this case "03" - a machine language
program. The next four bytes contain the start and end address (Low/High byte)
of the program. This header above denotes "LOADER", a machine language
program loaded from $02A7-0304. As the $0300-0304 area contains a number of
system vectors that can be modified to to point at the loader program and
this explains the autostart.

If we modify the start/end address before reading the rest of the program
(using the routine at $F56C) the file will be relocated, thereby circumventing
the autostart. I recommend adding #$10 to each of the high bytes (thus
shifting the entire loader $1000 bytes upwards in memory) as this makes
further studies a lot easier. The file in question would be relocated to

Having read the "loader" program to another memory location we are now able
to save it to disk. But that's not all! Program code can also be stored in the
tape buffer so be sure to examine the contents of $033C-03FC before moving on
to step 2. If the buffer contains any other data than the five control bytes
and the filename discussed earlier, save it to disk as well.

Congratulations! You have now taken the first step... there's much more to

Chapter 2: Analysing the loader.
   Brace yourselves! This is the tough part.

   There are a *lot* of different protections out there. It would be rather
impossible to discuss even a fraction of them here. Some tape protections are
quite easy to crack once you've gotten past the initial autostart loader.
Others might require you to decrypt data in one way or another. Some particular
nasty systems even load a new copy of the loader on top of the old one to
prevent tampering (the Firebird Gold loader being a good example of this).
Cyberload, the mother of all tape protection schemes, not only uses this
technique - it also features encryption as well as two different load
systems. If you can force a Cyberloader to it's knees, you have every
reason to be proud of yourself.

   It really goes without saying that a good deal of assembly language skills
are required in order to understand what goes on. However, as long as you are
able to grasp the overall function of the various parts of the program under
scrutiny - you do not need to know every detail about the inner workings of it.
Having said that it should be obvious that the odds increase the more you are
able to understand. In other words: Practice! Practice! Practice!

Consider the following example:

        l1     JSR $XXXX        ; get byte from tape
               STA ($F9),Y      ; store in memory
               INC $F9          ; increase pointers
               BNE l2
               INC $FA
               [...]            ; check for end-of-file/last file/etc.
               BNE l1
               LDA #$35
               STA $01
               JMP $1000        ; start the program.
        XXXX   [...]
        l3     LDA $DC0D
               AND #$10
               BEQ l3
               LDA $DD0D
               STX $DD07
               LDA #$19
               STA $DD0F

   The subroutine at XXXX seems to be doing something with certain I/O
registers. Understanding exactly what goes on isn't all that important because
by looking at the code following the JSR (at l1) we can clearly see that
something is stored in memory after calling the routine - i.e. the routine at
XXXX must be some kind of loader. As Sir Arthur Conan Doyle's famous detective
would put it, "Elementary, my dear Watson."

   Sometimes you will have to overcome various obstacles to get to the heart
of a loader. Some protections schemes rely on encryption, others on obfuscated
coding. The creators of the most sophisticated protection schemes knew that
understanding what goes on is the key issue regarding cracking, and went to
great lengths to discourage the "professional" as well as the casual cracker.

Chapter 3: Modifying the loader and pulling the files off tape.
   Now that you have penetrated the outer layers, you will want to pull the
individual files off the tape and store them on disk. One approach would be
to locate the piece of code that launches the main program and replace it with
something that halts the computer using a infinite loop, allowing you to enter
your cartridges in-built monitor, and save a memory dump to disk. In some cases
it is advisable to halt the computer after each file has loaded and save the
data to disk before carrying on to the next file.
   Whatever approach you choose the key issue is to halt the C64 and save the
relevant data. 

If space permits, I prefer to insert the following piece of code:

        LDA #$37
        STA $01
     l1 INC $D020
        BCC l1

If there is no room in loader for big modifications like the above make a note
of the original code before modifying the loader.

     l1 CLC
        BCC l1

also works quite well, not to mention only taking up three bytes. However,
this requires you not to enter the monitor until you are completely sure the
program has entered the infinite loop. I have used this approach so much that
I know the assembly opcodes ($18,$90,$FD) by heart, even though I haven't used
them in years.

   Now that the C64 is halted and we are ready to save the data to disk we
need to obtain the relevant addresses. I mean, why take up too much diskspace?
:)  Using the example from the previous chapter the data was stored at the
memory location held in $F9/$FA <STA ($F9),Y>. Thus, looking at the content of
$F9/$FA will give us the end address of the file. For the start-address we can
either make an educated guess using the 'M'emorydump or 'I'nterrogate to scroll
backwards until we encounter something that does not look like it belongs to
the file (after lots of practice real crackers can be quite good at this.)
A more precise (not to mention subtle) approach is to patch the loader to store
the content of the pointer elsewhere and modify the loader back to normal to
prevent the start-address from being increased due to the pointer being

Chapter 4: Wrapping up.
   Having transfered the files to disk it is time to wrap everything up. This
is by far the easiest step. Link the relevant files, then use a Char/RLE
packing program (EBC, Link & Crunch, X-Terminator, etc.) followed by a
"cruncher" program (DarkSqueezer, Byteboiler, Cruelcrunch, etc.)

   For shorter, cleaner cracks be sure to removing any excess data. Try
having a look at the game code - be sure to examine any memory-ranges that
are cleared by the startup code. Often quite a bit of data can be surgically
removed without causing any damage to the "patient".

   Loading pictures are most often turned into stand-alone files. Just add a
short piece of code to get the graphics on screen and pack everything.

   *Test* the finished product. In the old days a lot of bad quality could
have been avoided if crackers had taken the time to make sure everything worked
before releasing it onto the public. Again, this boils down to real cracking
being more than just churning out a heap of "warez" every day. I suppose the
modern day term is "quality assurance". :)

Chapter 5: What's next?

    Just because you suddenly find yourself able to breach one protection
scheme doesn't mean that you have suddenly become an expert cracker. Lots of
practice and further studies are needed to become successful. If you have more
than one original tape using the same copy protection, don't be afraid of
experimenting. Maybe you'll want to try out some new approaches. A lot can be
learned from writing a program to automatically transfer files saved by a
specific system. Gradually progress to other systems. If a system seems
impossible to breach, try sharpening your skills on easier systems and coming
back to it later.

As mentioned earlier, there are a *lot* of different loaders on the market.
Although the schemes used vary from one program to another, chapters 2 and 3
should give you a rough idea about the basic idea and the steps needed to
circumvent various systems.

    Multi-loaders (Programs using additional I/O such as intermission screens,
levels, etc.) will require you to replace the original loader with a custom
disk-loader. If you poke around the original loader you will most likely
discover some sort of internal level-counter that can be used to refer to the
name of the file you want to load next. Be sure to compress data files with
a Levelpacker for a result consuming a lot less disk space. Levelpackers
include a short loader/depacker program that will decompress the files on
the fly.

 Disk originals
    Feeling confident about tape cracking? Why not move on to disks? Be
prepared to encounter everything from minor obstacles to the meanest mothers
in the business. Disk cracking is, as they say, "A whole different ballgame!"

The author has been a C64 enthusiast for the past 11 years - and a general
8-bit addict for even longer. In his earlier years he was part of the European
C64 cracking scene. He is an active participant both on the #c-64 IRC channel,
and in the comp.emulators.cbm and comp.sys.cbm newsgroups. Recently he took his
group "Triangle 3532" to the World Wide Web. When he isn't busy playing Lode
Runner on his C64 he is available for questions and/or general comments at the
following Internet address:

/S05::$df00:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::

 A possibility to be explored : Real Time Video with the Ram Expansion Unit

                    by Nate Dannenberg (

A few weeks ago, there was a discussion on the comp.sys.cbm usenet newsgroup
concerning the viability of using the Ram Expansion Unit as a medium for
displaying real-time video animation on the C64 or C128.  I thought about
the possibility and came to a few conclusions.  The following text is how
I would undertake such a project.  Along the way, I shall illustrate some
previous "reu-animation" efforts and how the peculiar qualities of the REU
allowed such efforts to be accomplished.

While I've never actually done video, Commodore did it at least twice.

On the 1750 and 1764 Test/Demo disks there is a "Pound" demo and a "Globe" 
demo.  These two are full motion displays using your REU.  The "Pound" 
demo is a 3-dimensional # sign transforming in and out, the "Globe" is a
full rotating Earth/globe. 

The controlling program for these is written in BASIC, with a small ML
program to decompress the graphic data that's stored on the disk, as it's
loaded into the REU.

The REU has a transfer rate of about 1,022,000 bytes per second.  Since a
single video frame is 1/60 of a second, that gives you 16,666 clock cycles
per video frame (including video sync time).

Chances are good you will probably want to only display about 15 frames a
second, which is the MPC-1 specification for PC full motion video playing
from a CD-ROM disc.

With simple code, you can get about a 7.7Khz sample rate for the audio, by
playing one sample byte every other raster line, and maintain a smooth 60
FPS video transfer rate, should you want to go this high. 

All you have to worry about is making sure you start an animation frame
transfer at the top of the intended video refresh, raster line 0.  You do
this with a simple wait loop:

loop BIT $D012
     BMI loop

As soon as bit 7 of $D012 goes low, the BMI will fail, signalling raster
line 0 on a new frame.

The VIC chip steals 43 cycles from the CPU (and any REU transfer in
progress) on the first of every 8 raster lines.  The line where this
occurs now only has about 21 cycles free instead of the usual 64, this is
called a "bad" line in demospeak.

You want your audio routines to use the odd lines, to stay out of the way
of the bad lines that occur every 8 lines.  The video routines and any
additional overhead can be used after the audio routine has done it's job
on it's line. 

An algorithm like this might do the job:

0 bad line, start audio REU xfer from last video refresh (see below)
1 Play 1 sample of audio data and run animation copier routine
2 ::::
3 Play 1 sample and run animation copier
4 ::::
5 Play 1 sample and run animation copier
6 ::::
7 Play 1 sample, set REU to grab 2 more audio bytes
8 bad line, start the audio REU xfer (should take 8-10 cycles)
9 Play 1 sample and run animation copier
10 ::::
11 Play 1 sample and run animation copier
12 ::::
13 Play 1 sample and run animation copier
14 ::::
15 Play 1 sample, set REU to grab two more audio bytes
16 bad line, start the audio REU xfer (8-10 cycles)
17 Play 1 sample of audio data

You use a 2-byte transfer buffer for the digi audio data, to cut REU
overhead to a minimum, and to maximize the usage of those bad lines.
Remember that packed RAW data, as stored in a file, takes 1 byte for 2
samples.  So we're really transferring 4 samples here..

Basically on every badline you simply tell the REU to start the 2 byte
transfer that was set up on the previous line.  In the case of line 0 of
the very first frame when starting the code, simply set up everything
needed, including the first 2 byte audio pointer, which will be used by
the REU at the end of line 0 to copy those 2 bytes..

This only takes 6 cycles to activate, plus 2 cycles for the dma copy. You
have 11 cycles left, which may or may not be useful.  Just use four NOPs
and a BIT, to waste this time out to the next line.

Play 1 sample of audio data on every odd line, this takes only 6 cycles if
the data from the REU was copied to Zero Page. 

You have the remainder of the this rasterline and all of the next to run
your animation copier, a total of about 120 cycles.  You should be able to
squeeze in about 80 or so bytes into this space (80 bytes plus about 40
cycles of REU overhead is about 120 cycles).

The REU can be programmed to remember where it left off after a transfer,
making subsequent contiguous transfers painless. It takes about 40 cycles
to set up and execute the first transfer (plus the actual copy time), and
then only 6 cycles to repeat the transfer (plus transfer time of course),
by using LDA #imm:STA $DF01 , where #imm is the value that tells the REU
to start, I forget offhand, something like #$95 I think... 

This means that you might only be able to copy 80 or so bytes the first
time after an audio data copy (the first line following a bad line), but
you can transfer another 80-byte block just by using only 6 cycles to
re-execute the copy.

Use another 6 cycles to adjust the size of the transfer if you want more
to be transferred this time, LDA #imm : STA $xfer_size_reg where #imm is
your new size and xfer_size_reg is the REU register for the low byte of
the transfer length..

In this way you use 12 cycles to start a new size of transfer, and are
able to copy around 108 bytes, instead of just 80.

On every raster line that'S just before a badline, you play the last
sample in the buffer, and use the rest of the line to set up the REU to
transfer another 2 bytes of audio data into your audio buffer.  This
should only take about 40 cycles or so, plus whatever time is needed to
update your audio data pointers. 

To keep your timing easy, you should definitely keep this line down to
less than 64 cycles.  You can push it into the next (bad) line, but then
you gotta make sure the REU has completed the 2 byte transfer before the
VIC starts the line following the bad line, and you only have 21 cycles on
that bad line in which to do it. 

Use as much raster time as you can for the REU copier code, since the
audio code is so simple and requires comparatively little CPU time.

The REU is predictable; you will always know precisely how many cycles a
transfer will take.  However, you may not always know how much time your
own code will take, so you may need a simple wait loop like this at the
ends of certain raster lines, to wait for the next raster line: 

     LDA $D011
loop CMP $D011
     BEQ loop

This takes 11 cycles, plus 7 each time it loops.

Needless to say, you need to know a little about synchronizing all of this
to the video display and the raster lines. 

Location $D011 in the VIC is the low byte of the raster counter.  Reading
this register will tell you what raster line the VIC is on at any given

Remember that an NTSC TV has 525 lines, which consist of two 262 line
fields, often called "even" and "odd" fields.  In a TV displaying a normal
broadcast signal, One set of fields is normally positioned half a raster
line below the other, resulting in true 525 line interlaced display at a
30Hz refresh rate.

The VIC chip gets around this by displaying the exact same data in both
fields, and by placing both fields on  the exact same position on screen,
instead of moving one down half a line.  The result is the "normal" 262
line screen with a 60Hz refresh rate.

Synchronizing to a particular raster line is a simple matter of: 

     LDA #your_raster_line
loop CMP $D011
     BNE loop

This type of wait loop takes 9 cycles for the first run, plus 5 cycles
each time it loops.  

When you start a new frame update/copy, you need to synchronize your
routine to start on raster line 0.  You can do this by watching the high
bit of the raster counter:

loop  BIT $D012
      BMI loop

This only takes 5 cycles per loop.  As soon as bit 7 of $D012 goes low
(0), the BMI will fail, signalling that the VIC has started an even video
field.  This  way you know you are at the start of the TV's video frame as
well as the VIC's idea of a frame.  I don7t knwo if this would really
matter, however. :)

Remember that line 0 is NOT a bad line, nor are any other lines outside
the range 48 to 199, because there is no visible display here, only

On these lines outside the visible display, you have 43 cycles more on
every 8th line, which are normally the bad lines on the visible display.
They are all a full 64 cycles long like any other non-bad line elsewhere
on the display.

Let's take a general routine that copies 80 bytes on every two raster
lines (minus the bad line and the line before that), not using the REU's
ability to remember where it left off.  80 bytes * 3 transfers per row is
240 bytes.  25 visible rows * 240 bytes yields exactly 6000 bytes.

Well we still have those 56 rasters off screen.  That'S about 7 rows
tall, and we can use the same routine as we do for the on-screen rows
(except we have no bad lines to deal with).. 

So 7 * 240 = 1680 bytes + 6000 from the on-screen rows = 7680 bytes.

That'S not quiet fast enough to do 60 FPS, but you can certainly get 15
out of it. :)  In fact that looks to be good enough for 50 FPS.  Well we
can improve this! 

Since the REU can remember where it left off, why not get it to transfer
80 bytes the first time on each row, and 108 bytes each of the next two
times (as described way up there someplace)? 

Well, let's add it up...  80 + 108 + 108 = 296 bytes per row.  25 rows
times 296 bytes yields 7400 bytes on the visible screen.  We only need
another 600 bytes to finish our 8000 byte bitmap... 

LeT's just use the next three rows and waste a few rasters..  296 * 3 =
888, add the 7400 bytes we've done on the visible screen and we get 8288
bytes.  Just slightly more than enough for the full screen. 

After all this we still have another 32 rasters left, on which the audio
routine is still running (on every other line).  That audio routine is
probably only using maybe 1/20 of the total raster time. 

Even then we could still speed this up by using some of that leftover
raster time, and with a little fiddling you can get 15Khz instead of
7.7Khz, but that'S kinda tricky and involves a lot more cycle counting. 

Now remember, all of this audio and video data takes a LOT of ram....

You can only get 8 animation frames into a 64K bank in the REU if you go
with full-size 320x200 bitmaps.  A 1750 REU only has 8 banks, that'S a
total of 64 animation frames.

At 15 FPS, that'S only about 4 seconds of video..

A 2MB REU on the other hand has 32 banks, which yields 256 frames.  At 15
FPS, that'S only about 17 seconds of video.

One way to increase the video time is to use custom characters to simulate
an 80x100 bitmap using a text screen.  This would still be monochrome and
would be much lower resolution, but you would now have about 8 times
longer video.  That 2MB REU would now be able to handle about 140 seconds,
or just over two minutes.

The advantage of that method is you would only have to copy 1K of data
instead of 8K, which could be done in about 5 rasterlines using the above
copy-and-remember method.

And then you still have your audio track with that..  a 7.7Khz sample uses
7700 bytes for 2 seconds (packed 4 bit data) of sound, so a 4 second long
sample, will take just over 15K.   A 17 second sample would take about
65K.  And to match up that 140 seconds of video with 140 seconds of audio
would take about 537K, or about 1/4 of the 2MB REU.

Obviously you would have to find a break-even point here, where you have
as much audio time as video time.  From the looks of it, video takes about
4 times as much data as audio, when using 1K charctermapped frames, or
about 32 times as much when using full 8K bitmaps.

If you were playing the Audio data from the C64's memory, or if you had
one ram device to hold audio data and one to hold video, then the overhead
would be virtually nil.  You could probably get away with a 44 KHz sample
rate and 60 FPS video, depending on the code and the speed of the ram
device(s) in question.  Two REU's mapped at different addresses in memory
should in theory be enough to do it. 

/S06::$f00d:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::

                          A look into 'The Fridge'

                     by Stephen L. Judd  (

[Ed. note : The following text is from The Fridge, an archive on the World
 Wide Web dedicated to the preservation of useful routines and algorithms.
 The Fridge ( is authored and
 maintained by our technical editor, Mr. Stephen L. Judd.  All contributions
 to The Fridge should be sent to him at]

Sample descriptions

     * ascii2bin.doc - A description of an ASCII to binary number converter.

     * ascii32.s     - A routine to convert a 32 bit number to ASCII and print
                       it to the screen.
     * rand1.s       - A simple pseudo-random number generator from dim4.
                       Not that great of a random sequence, but fine for
                       simple sequences.

     * bitchin.doc   - "A totally bitchin' circle algorithm"

The idea here is pretty simple.  Numbers are read in left to right, and
each time a number is read in, the total is multiplied by ten and the
digit is added in:

:loop   total= total*10
        total= total + digit
        read digit (and convert from ASCII to integer)
        if not EOF then goto :loop

There are two ways to multiply by ten.  The first way is to use a general
multiplication method.  The second is to realize that 10 = 8+2, thus
x*10 = x*8 + x*2 = x*2*(1+4), so with a few shifts, a temporary location, and
an addition, multiplying by ten can be done very quickly.

Example: read in the number 1653


1st read: digit=1
        total= total*10 => total=0
        total= total+digit => total=1

2nd read: digit=6
        total= total*10 => total=10
        total= total+digit => total=16

3rd read: digit=5
        total= total*10 => total=160
        total= total+digit => total=165

4th read: digit=3
        total= total*10 => total=1650
        total= total+digit => total=1653


SLJ 10/96

* 32 bit -> ASCII conversion
* Take 2 -- Divide by 10 manually; remainder is coefficient
* of successive powers of 10
* Number to convert -> faq2..faq2+3 (lo..hi)
* SLJ 8/28/96

          ORG $1300

FAQ2      EQU $6A


          LDA #$FF
          STA FAQ2
          STA FAQ2+1
          STA FAQ2+2
          STA FAQ2+3

          LDA #10
          STA FAQ2+4

          LDY #10
          JSR DIV32
          LDY TEMP
          ADC #48
          STA $0400,Y     ;Stick it on the screen
          BNE :LOOP

* Routine to divide a 32-bit number (in faq2..faq2+3) by
* the 8-bit number in faq2+4.  Result -> faq2..faq2+3, remainder
* in A.  Numbers all go lo..hi

DIV32     LDA #00
          LDY #$20
          ROL FAQ2+1
          ROL FAQ2+2
          ROL FAQ2+3
          CMP FAQ2+4
          BCC :DIV2
          SBC FAQ2+4
          INC FAQ2
:DIV2     DEY
          BNE :LOOP

* Generate a somewhat random repeating sequence.  I use
* a typical linear congruential algorithm
*      I(n+1) = (I(n)*a + c) mod m
* with m=65536, a=5, and c=13841 ($3611).  c was chosen
* to be a prime number near (1/2 - 1/6 sqrt(3))*m.
* Note that in general the higher bits are "more random"
* than the lower bits, so for instance in this program
* since only small integers (0..15, 0..39, etc.) are desired,
* they should be taken from the high byte RANDOM+1, which
* is returned in A.
         LDA RANDOM+1
         STA TEMP1
         LDA RANDOM
         ROL TEMP1
         ROL TEMP1
         ADC RANDOM
         LDA TEMP1
         ADC RANDOM+1
         STA RANDOM+1
         ADC #$11
         STA RANDOM
         LDA RANDOM+1
         ADC #$36
         STA RANDOM+1


                    A totally bitchin' circle algorithm

Last revised: 2/20/97 SLJ

With a revision!  The old algorithm ignored one small detail -- the plot8
8-fold plotter, which can be a real pain!  One thing to do is to make the
algorithm draw a quarter of a circle instead of an eighth, and the
way to do that is to attempt to reverse the procedure that drew the
first eighth of the circle.

BLARG does exactly this; in the process, I also experimented with how the
order of statements below makes a difference in the way the circles
look.  So the algorithm below is now the best version I know of, i.e.
makes the most beautiful circles at all radii.

This is the entire algorithm:

        Y = Radius
        X = 0
        A = Radius/2
        Plot4(x,y)      ;Could just use Plot8
        X = X + 1
        A = A - X
        if A<0 then A=A+Y : Y=Y-1
        if X < Y then :loop

; Now more or less reverse the above to get the other eighth

        A = -R/2 - 1
        A = A + Y
        Y = Y - 1
        if A<0 then X=X+1:A=A-X
        if Y>=0 then :loop2


The other possibility is to use the first half of this algorithm with
an 8-fold symmetric plot, and be sure to plot the last point X=Y.

See C=Hacking Issue #9 for more details, but note that A=R/2 above, which
will make the circle correct for small R (it just rounds numbers).

These and other useful bits of information can be obtained through Mr. Judd's
web page, - The Fridge -, at

/S07::0100h:::::::::::::::::::S O F T W A R E:::::::::::::::::::::::::::::::::

               C-128 CP/M, trailblazer in a jungle of formats.
                               Mike Gordillo
The microcomputer world was once awash in an estimated 100 different major
operating systems with over 2000 proprietary disk format-types.  The numbers
are much less intimidating today, but with the resurgence of older systems
amongst the public (IMHO), the need to extract information from an obscure
disk format may become very real to the hobbyist.  Your C-128 and its
drive peripherals are extremely flexible when coupled to the right software.
When running CP/M, your C-128 is at its best in its role as an inter-platform
intermediary.  This article will attempt to deliniate what your C-128, under
CP/M, can do for you in this regard.
The original C-128 CP/M BIOS directly supports six 5.25" CP/M MFM (Modified
Frequency Modulation) and two 5.25" CBM GCR (Group Coded Recording)
format-types.  They are as follows:
      Epson QX10   (MFM) - CP/M Z80 DS/DD
      Epson Euro   (MFM) - CP/M Z80 DS/DD
      IBM-86       (MFM) - CP/M 8086 DS/DD
      Kaypro II    (MFM) - CP/M Z80 SS/DD
      Kaypro IV    (MFM) - CP/M Z80 DS/DD
      Osborne      (MFM) - CP/M Z80 SS/DD
      C-128 DS/DD  (GCR) - The "Default" C-128 CP/M format-type.
      C-64  SS/DD  (GCR) - C-64 CP/M (Z80 Cartridge) SS/DD
   Note: The 1581 is "officially" supported in the 28 MAY 87 version of
         C-128 CP/M 3.0+.  The official 1581 format-type is MFM DS/DD.
         (SS = Single Sided, DS = Double Sided, DD = Double Density)
MFM disks usually have the same number of sectors on each track while GCR
disks have a variable number of sectors for different ranges of tracks.
Commodore-DOS-style GCR is the "default" format-type for C-128 CP/M
because this allows "Joe User" to easily boot up CP/M from a 1571 or even
a 1541 (slow!) drive.  (Fortunately, when Commodore finalized the 28 May 87
version of C-128 CP/M, they not only provided a format-type for use with the
1581 but added a FORMAT.COM that could create a 1581 3.5" C-128 CP/M bootable
system disk.)
What can you do with these format-types?
Taking advantage of what CP/M provides is as simple as inserting a diskette.
For example, let's say I have some files on my Kaypro which I need to use on
C-128 CP/M.  All I have to do is put the Kaypro disk in my trusty 1571 and
voila, I can use it and the files within as I please with no hassles.  This
is no small point of trivia.  The message here is that you can use data on
these "alien" format-types as if the data were sitting on the "default"
C-128 CP/M disk.
What about copying them over to C-128 CP/M disks?
No problem!  The transfer process is as easy as using an off-the-shelf file
copier because as far as CP/M is concerned, the "alien" and "default" (native)
format-types are one in the same.  This degree of transparency is due largely
to the internal disk format table which exists within the computer's memory
as part of the CP/M BIOS (Basic Input/Output System).  This arrangement
constitutes better support and flexibility over the rigid Commodore DOS system
when it comes to juggling different format-types.
What happens if I run across a format-type that is not directly supported by
C-128 CP/M?
Flexibility to the rescue!  The "built-in" drive table is modifiable (both in
memory or on the system disk).  If you need to access other CP/M format-types,
the solution may be as easy as installing the parameters that match the disks
in question.  A good example of a utility that does this is the UNIDRIVE
utility by Frank Prindle.  It reconfigures the drive table, allowing up
to ten different 5.25 MFM format-types at any one time from an overall
selection of twenty-four.  Because of the drive table, UNIDRIVE is a simple
elegant program that can make these changes without sacrificing any TPA
(Transient Program Area) memory.  The undisputed king of format "jugglers" and
nowhere near as simple is the JUGGLER utility by Miklos Garamszeghy.  This
program can read and write and format over ONE HUNDRED THIRTY different
format-types, mostly 5.25" MFM (with 1571) but also 3.5" MFM (with 1581) based
disks.  This includes the popular space extending, speedy alternative formats
for C-128 CP/M, namely Maxi 1571/1581 and MG 1581.  A demo version of the
JUGGLER utility is publically available.  It does not have as many features
as the full version, you can only access twenty-two format-types and modifying
the "built-in" drive table is out of the question.  This would be inconvenient
if the full version were hard to find as it once was.  This has changed as
its author as put up the full version of Juggler on the World Wide Web at
What about MSDOS MFM disks, can I use them as well?
Yes you can!  I know of at least three separate utilities that will allow
communication between C-128 CP/M and MSDOS diskettes.  First on the list
is the RDMS 2.33 utility.  This is an old program designed to read MSDOS
diskettes, and that's all it does.  It will read from MSDOS into CP/M but
will not write back to MSDOS.  Frank Prindle ported over this program
(for the 1571 drive) and he would have probably added a "write MSDOS" option
if someone else hadn't beaten him to the punchline.  The TRANSFER 128 v1.2c
utility (ported over by Gilly Cabral from David Koski's original TRANSFER
util.) came soon after Prindle's rendition of RDMS 2.33.  In fact, the routines
used to communicate with the 1571 are based on Prindle's work.  TRANSFER 128,
however, goes way beyond RDMS 2.33.  Not only does it read and write to MSDOS
disks but it also provides a suprisingly high level of sophisticated access to
the internal workings of MSDOS disks.  For example, it can display the MSDOS
FAT (File Allocation Table) and reconstruct it, if needed, using a backup FAT
as a template.  TRANSFER 128 supports single and double sided 5.25" format
types with eight or nine sectors per track.  It places no limits on the size
of the data it can transfer.  The only limitation is the free space left
on the destination diskette.  This is a huge advantage over the first "native"
mode MSDOS to CBM DOS programs which use internal memory buffering.  For many
years, TRANSFER 128 was my only standby for large files.  When better utilities
came out for the "native" modes, I still found TRANSFER 128 to be my choice.
Why?  Because of the excellent Ram Expansion support under the CP/M BIOS.  CP/M
thinks the Ram Expansion Unit is truly a real drive.  TRANSFER 128 (and other
CP/M programs) does not have to worry about steering clear of "interface pages"
and silly stuff like that when dealing with the additional Ram.  Eventually,
people wrote transfer utilities that did work with CBM RAMDOS, for example.
Too late, my heart was set on TRANSFER 128.  It's been a good companion and
since it comes bundled with its Turbo Pascal source, I can always modify it
in case of trouble.  In fact, I had to do just that when I set up several
BIOS/BDOS/CCP enhancements on my system.  (But that's another story :)))
The one tiny snag with TRANSFER 128, however, is that it will format the
various MSDOS format-types perfectly as far as MSDOS itself is concerned,
but "native" mode transfer programs do not recognize the disks which TRANSFER
128 has formatted.  I am at a loss to explain this, so I won't ;), but its safe
to say i'll give TRANSFER 128 the benefit of the doubt anytime!
What about 3.5" MSDOS format-types using my 1581?
Ah, yes, I've neglected to mention what may be the best "transfer" utility
available for the C-128.  It may be too sophisticated for young viewers so
this section of this article will be rated PG-13 :).
Well Well Well !??!?  Don't keep us in suspense!
Not to worry!  The utility i'm harping about is called MSDOSEM (by Nichita
Sandru).  It doesn't just give you a temporary transfer "window of
opportunity", it makes CP/M think of MSDOS disks as native CP/M disks and
it provides (get this) *full* subdirectory support!!!
This is similar to the transparent "juggling" of CP/M format-types, yes?
Yes, except that CP/M disks carry the same directory structure no matter how
their format-type is arranged.  In order to support the MSDOS directory
structure, MSDOSEM creates a separate buffer area for internal conversions
between CP/M and MSDOS logical constructs.  The actual physical nature of the
MSDOS format-types, however, is handled (once again) with a modified CP/M drive
table.  MSDOSEM has no problem with 5.25" (1571) or 3.5" (1581) double density
MSDOS format-types.  Again, as described earlier in this article, transparency
means that you can play with the "alien" disk as if it were a "default" one.
Any copy utility you have sitting around can now access MSDOS diskettes with
MSDOSEM as the go-between.  This is the ultimate in MSDOS to C-128 transferring
because you (essentially) do not have to transfer anything anymore! The "stuff"
on your MSDOS disks is no longer anathema to CP/M, even though it may be to
you :).
What about support for regular Commodore DOS (GCR) disks?
In reality, the original "default" C-128 CP/M format-type is as Commodore
DOSian GCRish as anything Commodore has done for the "native" modes.  I take
advantage of this when backing up my CP/M disks, either with FastHack'em
(or any GCR copier) in C-128 mode or IMAGE.COM under CP/M itself.  These 
programs allow us to manipulate Commodore GCR on a gross level.  For a more
refined manipulation of files "stuck" in regular CBM GCR disks, I generally
use the RDCBM 2.1 utility by Rob Tillotson and Turbo Penguin Software.  This
program can read files from 1541 or 1571 "native" Commodore GCR disks and spit
them out as straight binaries (eg., no translation) or it can convert files from
PETSCII to ASCII.  Like RDMS 2.33, RDCBM 2.1 does not write back to the disks
it so aptly read and it does not read anything on the 1581.  These quirks are
*highly irritating* considering its a pretty good program otherwise.  Good
enough to provide limited support for files under the GEOS file structure.
Fortunately, I surmise that I have not run into a more recent version of
RDCBM to evaluate.  I say this because the source listing of this program
contains "Hooks and Crannies" pointing to the author's efforts to implement
a "write-back" option and 1581 support.
You mean I cannot transfer material from my CP/M disks to my regular 15xx
No I don't.  There exist several "native" C-64 and C-128 utilities which will
do this.  The C-128 "native" mode version of the Big Blue Reader program has
this ability.  Utilities like Supersweep and Crosslink can also port your
files to CBM DOS 15xx disks, albeit these two programs set limitations on
the size of the files in question.
That's nice, but i'm a C-128 CP/M'er through and through!
Ok, you beat it out of me.  There *is* a way to "save" files to a regular
CBM DOS diskette from within C-128 CP/M.  You first use the C128LOAD utility
by David Bratton to load a file into Bank 1 of the CP/M memory map.  Next, you
hit CTRL-ENTER (on the numeric keypad, do not press RETURN) and this will put
you in C-128 "native" mode.  Finally, you use the built in C-128 ML monitor
to save to disk the memory block (Bank 1) where the program was loaded.
Please note the following example;
     A> C128LOAD DIEHARD.C64
        Program loaded - from 2000 to 8192  <-- Last byte-address
     --When the A> prompt reappears, press the CONTROL and ENTER keys
       simultaneously.  (The ENTER key is on the NUMERIC KEYPAD.)
       <The C-128 will now boot Basic 7.0 -- C-128 "Native" mode>             
     MONITOR (activate the C-128 ML monitor & insert CBM DOS disk into drive 8)
     S "DIEHARD.C64",8,2000,8193  <-- Always add +1 to the last byte-address.
In effect, we have just moved the file DIEHARD.C64 from C-128 CP/M to a CBM
DOS disk (remember to use the bank address of 1 when saving).  While this
method places an absolute restriction on the file size of what you can "save",
it means that files can be "saved" to any drive supported by the C-128.  It
is possible to save only one file per iteration of this cycle.  In order to
save many files, you will have to reboot CP/M and go through these steps
for each file involved.  This is a roundabout way to "write-back" to CBM DOS
and it certainly isn't as contained within CP/M as most of us would like.
How do the exciting CMD FD-2000 and FD-4000 drives factor into all this?
They are "covered" insofar the programs that support the 1581 also support
them, namely the JUGGLER, MSDOSEM, and C128LOAD utilities, and also the 28 MAY
87 Version of CP/M 3.0+ on the C-128.  The FD series drives do a pretty good
job at emulating the 1581 and should present no problems under C-128 CP/M.  The
1581 is limited to around 800 kilobytes and this may not be adequate for you.
As far as accessing the high capacity disks within the scope of the FD-drives,
the key issue is software (again).  For example, there is nothing in terms of
hardware that says we cannot use these drives to play with MSDOS 2.88 megabyte
formats (ala FD-4000) or create 2.88+ megabyte CP/M formats of our own design.
I do not know if FD-based software exists to allow this under C-128 CP/M.
How do I use the strengths of some programs to get around the limitations
of other programs?
I take it you are asking this because of the software gap in linking CP/M
to CBM DOS (at least from the CP/M side of the equation)?  Well, we have
a trump card in our sleeves in the form of the MSDOS format-types.  These
tend to be the lowest common denominator for information inter-change in
the entire microcomputer world.  For example, if the JUGGLER utility lacks
the ability to communicate with a particular brand of CP/M format-type (a
rare event indeed), chances are the system (with the funny format-type) has
some means to get information from its disks onto MSDOS disks.  Obviously,
I can simply use the MSDOS format-types as a bridge "over troubled sectors" :)
and not worry anymore.  The same holds true for CP/M to CBM DOS.  If it becomes
too inconvenient to save with C128LOAD and the built in C-128 mode monitor,
I simply pop up TRANSFER 128 or MSDOSEM and let them put things into MSDOS
disks for later retrieval by CBM DOS-able "native" mode programs such as Big
Blue Reader or Little Red Reader/Writer 128.  Mind you, this has its own
share of inconveniences, but it does present an attractive alternative to
some people.
What if I don't have a C-128 but I need to put files on a C-128 CP/M disk
or some other type of CP/M disk?
Hmmm...that's a tad outside the scope of this article but I can see a situation
arising from this where a C-128 CP/M user might miss out on some software.  If
you have a machine that runs MSDOS, you can avoid that situation.  There is a
MSDOS to CP/M utility called 22DISK140 which supports 140 different CP/M MFM
formats in its demo version and over 400 (!) in the full version.  The key
thing here is that it supports the Commodore 1581 CP/M MFM format.  Any files
you put in there are going to be useful to a C-128 CP/M user as long as he/she
has a 1581 and the 28 MAY 87 Version of CP/M 3.0+ on the C-128 (or a suitable
patch which supports the Commodore 1581 CP/M MFM format).
You've shown me the software, but where do I get it?
All the C-128 CP/M utilities I mentioned are available on Internet FTP sites
such as  in directory  /pub/cbm/os/cpm.  I have also seen
some of them in the GEnie and Delphi information networks.  The 22DISK140
utility is available on the Internet FTP site  in directory
Final thoughts...
Software Software Software... This article is by no means the final word
on what you can or can't "port" out of C-128 CP/M.  For example, Apple CP/M
GCR disks are completely isolated from C-128 CP/M, 22DISK140 or anything out
there besides an Apple drive!  However, some clever magician among you may
set to master the Apple GCR format using a Commodore GCR drive.  If you do it,
drop me a line, good CP/M software is usually a thing of beauty.  As I hinted
the last time we met, CP/M's strength lies in its software, (: and in its users
does its software lie. :)
Mike Gordillo is an expert in CP/M and Z80 programming as well as
a devout Commodore fanatic.  He may be reached on the Internet as for general comments or questions.


                     The X10 PowerHouse, What is it?

                     by Dan Barber (

Well to put simply, it is a system that allows you to control up to 256 lights
and or appliances in your house automatically, or from a distance.

The most basic part of the system is the modules.  They are small boxes that
plug into a plain 2 or 3 pin electrical outlet (depending on the module you
have purchased) and the device you wish to control is plugged into the module.
Then you can get numerous remote controls that send signals to a receiver
that then sends the signals over your wiring to the individual modules,
which then turn on, off, or dim (if you are using a lamp module).

As I have said, you can get remote controls to control the appliances,
but why not just control them with the normal switch and save yourself some
money?  Because a computer interface can also be purchased for the system,
and this interface can be programmed with a Commodore 64/128!  Or if you are
one of the unfortunate that don't own a Commodore, then you can use a MS-DOS,
Apple Macintosh, or Apple IIe/IIc.

The CP290 Home Control Interface is 5 inches wide by 7 long, and 1 1/2 deep.
The top face is covered by rocker keys which allow you to control 8 modules
from one HOUSECODE which is adjustable.  The modules have two dials on them,
the first is the letters A-O.  This is called the the HOUSECODE.  The second
dial on the modules is the number 1-15, this is the UNITCODE.  So, your
first module would probably be name d A1 and the second A2 and so on, for
a total of 256 modules.  

The interface can handle control of all 256 modules but if you are using
the Commodore 64/128, you can only program 95 using the included point-and
-click GUI (Graphic User Interface) program.   If you have more than 95
modules you will have to use the included BASIC extension program that is
included on the disk.  Then you can create your own simple program to control
all of the modules if need be.  But I can't personally imagine anyone using
over 95 modules, unless you have a mansion.  :)

The program that sets up the interface is very simple to use.  With the
power off you connect the cable to the userport and the interface turn it
on and load the program.  You set the time and the HOUSECODE you want the
rocker keys to respond to and then the screen shows the different rooms
you can "install" modules in.  There are 9 "virtual" rooms you can place and
program modules, though it does not make any difference what room you have
the module in as long as the dials on it are set properly.  Programs for use
with other computer systems have differences, some you type in the name of
the room instead of using the "virtual" rooms.  And some can control all 256
modules with the supplied software, where as other systems must write there
own software if they need to control all 256 modules.

Once you pick a room (by using the cursor keys or the joystick to move a
pointer and clicking) you are presented with 11 "tabs" where you can "place"
modules.  When you select one you are presented with choices of icons
(graphics) that look like appliances and lamps.  When you chose one it is
stored in the interface as well as the HOUSECODE and UNITCODE.  Note, it does
not make any difference what icon you select to go along with a module, it
is just to remind you of what the device is.  So you could have a toaster
icon (graphic) actually controlling a coffee pot, the only thing that really 
matters is the dials on the modules and the interface codes are the same.

Once you have the rooms set up with icons you like, you go to the operate
mode.  This is where you program the interface to come on or off at specific
times of days.  You can set it to go on NOW, which turns it on immediately.
And this is the beauty of the system, you can have your house have a "lived-in"
look even though it isn't.  With SPECIFIC DAYS and EVERYDAY modes, you can set
a security mode.  This means that if you set something to come on at 5:00pm,
it would come on between 5:00pm and 5:30pm.  It just picks a random time and
ON (or OFF) it goes.  The interface is very versatile and you can enter
numerous ON and OFF times, so for instance, if you have kids that forget to
turn off the lights you can have them go off-only at designated times, the
same goes for ON.  Now this is why this system shines over others, when you
aredone programming you unplug the interface from the computer!  It does
not tie the computer up.  You only use the computer to program the interface.
Afterwards it runs completely on its own.

The interface will handle up to 128 timed events, which means if you were
controlling a Christmas light setup, and you were changing the lights every
minute (the closest span that you can program a timed event) you could have
over 2 hours of automatic control.  I should mention that it does not make
any difference how many modules have been setup to go on or off for one
particular time (up to 16 modules).  It would still be considered one time
event (ex. modules A1, A4, A7, and A15 programmed to go on at 70% brightness
on Mondays, Wednesdays, and Fridays at 7:30 p.m. is just one event).  Also, 
you can only set brightness for a lamp module with the interface hooked up
to the computer to send the commands manually, or as a pre-programmed event.
So, if you just hit one of the rocker keys or turn the lamp on, off, and
back on (the module will sense this and turn on), the lamp will just come
on full.

And after you get the interface all programmed just the way you want it-the
power fails and you loose your entire program.  Well, if you have a 9 volt
battery installed the program would have been safe.  The battery can hold the
memory of the interface for 10 hours (or so).  And it is a good precaution,
the only problem might be to forget it is in there and after a few years,
the battery leaks.  But that applies to any battery-powered device.  There
is also the option to save the entire contents of the interface to disk.  
This is available as a separate program on the disk, and it saves the interface
data as a file to the disk.  Three saves can be on the disk at one time, and if
you need more just copy the disk, it is not protected.  One of the greatest
benefits of this feature is the ability to swap setups in and out so you can
have one for different times of the year.  For instance you could save your
Christmas light setup to disk and next year get out the same setup and save 
yourself a lot of time in programming.

If you have a elaborate house setup that takes 20 minutes or more to program.
It is great to be able to load the settings back in a minute or so!  Another
good reason for having a backup is because the interface can "lock-up" and
you must remove the battery and unplug it to reset it.  This of course causes
the program to be lost so having a backup is necessary in this case, otherwise
you have to reprogram it.  I have had it happen once, but I was moving the
interface.  I think that the battery lost contact momentarily while I was
moving it to another room and caused a "lock-up" to occur.  But I had just
done a backup so nothing was lost.

Power failures have different effects on the modules as well.  The appliance
module will stay in the same position (they have a latching mechanical relay
type switches) as it was before the outage.  Where as, the lamp modules will
be off after a power failure (they have a triac for dimming), no matter what
state the module was in before the failure.

There are a lot of clones on the market, and they all appear to be compatible.  
X-10 was the first, but other places such as Radio Shack has both the interface,
modules, and other addons for the system.  But in the case of Radio Shack's
interface, it is missing a very important feature (at least in my opinion):
no manual rocker keys!  Other than that, I don't know of any differences
between the systems.

** Just as this issue of disC=overy was going to press, I found out that
   X-10 manufactures all the clones themselves!  The differences are minor
   and limited to cosmetic changes as the example listed above.

The equipment is long lasting (people have had the system in place for over
20 years).  But of course if you have a lightning strike I would not expect
them to survive, and don't try to put a surge suppressor on them either.  Most
filter the lines and will block any signals going out or coming in to the
attached equipment.  And a plug-in intercom system or baby monitor will
interfere with the signals if they happen to be sent at the same time as
the intercom is on.

In short this system is MUCH easier than running cabling all over your house,
and much cheaper.  You can get the interface and 4 modules for around $100.
And if you want to control a chandler or other such lighting fixture, just
replace the switch with an X-10 controllable switch, and the same applies
for outlets.  And replacing them is very easy, and can be done in an afternoon
(unless you are doing an entire mansion).  Just make sure to turn off the
power at the breaker!!!!  Other addons for X-10 include entire alarm systems,
motion sensing flood lights, emergency dialer (dial for assistance when you
push the remote control), telephone responder (remote control your home
while you are away), and many other interesting products.

There have been some interesting uses I have heard of for the X-10 system.
Like, magicians using it in there act, remote control lighting for underground
cavetours, and lighting control for chicken farms to fool the chickens into
laying more eggs.  And many others, this proves that is no limit to what the
system can do if you put your mind to it.

The processor is in the interface is a 80C48.  And I mentioned before a maximum 
of 256 modules with a maximum of 128 timed events.

The transmissions are complex and are sent twice for verification and basically
the signals involve short RF burst which represent digital information.  The
transmissions are synchronized to the zero crossing point of the AC power line.
The goal is to transmit as close to zero crossing point as possible, but
certainly within 200 microseconds of the crossing point.  A Binary 1 is
represented by a 1 millisecond burst of 120 kHz at the zero crossing point,
and Binary 0 by the absence of 120 khz.  And the instructions to the module is
sent with those two signals (as is all computer information).
The complete code transmission involves eleven cycles of the power line.  The
different cycles represent different commands to the module.  Such as the first
two cycles represent start, next four represent the House Code and the last
five represent either a Number Code (1 thru 16) or a Function code (ON, OFF,
etc).  The programming manual is reproduced below with permission and for the
edification of the reader.

[Ed. Note : Portions of the technical information below require some basic
 understanding of signal theory and electronics.]

Software is required to use your computer to program the X-10 Home control
Interface.  The interface is packaged with software and connecting cable for
either IBM PC, Apple Macintosh, Apple IIe/IIc or Commodore 64/128.

A utility program of Basic statements is included with the Home Control
Software for IBM, Apple IIe/IIc and Commodore Computers.  These Utility
programs let you write your own programs in Basic.

For more advanced programming you may also need to refer to this programing

This programing Guide is for advanced programmers who wish to write their
own software using Machine code and need information than is supplied in the
owner's manual which comes with the X-10 Home Control Software.

If you do NOT intend to write your own software, don't be intimidated by
this programming guide- you don't need it.

The Interface must be connected to your computer for programming but once
programmed it can be disconnected and will continue to send commands to the
X-10 Modules under time control.

The Main functions of the Interface are summarized as follows.

*Maintains a real time clock
*Stores the timed events relating to control of lights and appliances in the
*Stores the graphics data required by the computer to display the details of
lamps and appliances installed into the house by the user.
*Transmits X-10 Control Signals onto existing house wiring to control lights
and appliances connected to the X-10 Modules.

A 9volt Alkaline battery will provide approximately 100 hours back up for the
Interface clock and stored data.  When the Interface is running on battery
power, the L.E.D. pulses approximately once every 5 seconds.

Up to 128 timed events + 256 ICONS (Graphical pictures of lights and
appliances) can be stored in the Interface.  A timer event is any number of
unit codes on the same Housecode programmed to go on or off at a particular
time at a specified brightness level on any day or days of the week.
(E.G. Modules A1, A4, A7 and A15 programmed to go on at 70% brightness on
 Mondays,Wednesdays and Fridays at 7:30 P.M. is just one event and 128
 events can be stored.)

The Interface has 8 rocker keys to give manual control of unit codes 1 thru 8
onthe Base Housecode.  Base Housecode is set to "A" on power up but can be
changed by the software.


The Interface is programmed to recognize 8 different types of instruction
for the computer and each instruction has an ID number between 0 and 7.  Each
instruction from the computer has a leading SYNC pattern of 16 x FF bytes. The
ID number tells the Interface what type of data to expect and a check sum is
maintained which is compared with the last byte of data in the instruction.
If the check sums agree, the Interface will acknowledge back to the computer
and obey the instruction.  It is suggested that if no response to an
instruction is received within 10 seconds, the computer should advise the
user of potential problem with the connections to the Interface. 
(E. G. the program could display a message such as "Error check Interface
 connections.  Press Enter to continue".)

The Interface is programmed via the 5 pin DIN socket on the back of the
Interface.  The pin connections are shown below.

                      Looking at Back of Interface
     5         1
       4     2
Pin  Description
1    -
2    Receive (Input)
3    Ground
4    Transmit (Output)

The input signals from the computer (receive data input) are connected between
pins 3 and 2.

The output signals to the computer (transmit data output) are connected
between pins 3 and 4.

A data cable is available for IBM, Macintosh, Apple IIe, and Commodore 64/128
and is included with the Interface and software for these computers.
<Note-The Commodore cable and software must be purchased separately, it is no
longer sold with the interface.  To get the cable-software package you must
order one from X-10..>

Voltage levels meet RS-232 specifications and the data format is RS-232 with
the following characteristics.

Baud rate:  600.
Data bits:   8.
Parity:      None.
Stop bits:   1.

           Start                                Stop
            Bit  D0  D1  D2  D3  D4  D5  D6  D7   Bit
     V+    ---     ---            ---     ---
           ! 0 ! 1  ! 0   1   1   1 ! 0 ! 1 ! 0 !  1
     V- ---     ---    -----------     ---    ---

1011   D   D0 to D3
1010   5   D4 to D7

Dec = 93
Hex = 5D
0 = Mark
1 = Space

A gap of 1 Millisecond should be left between each byte of data sent.

A start bit signifies that a string of 8 data bits will follow.  A start
bit is always a SPACE bit, i.e. "0".  A stop bit signifies that the data is
finished and separates one byte from another.  A stop bit is always a MARK
bit, "1".


When the Interface is first powered up, the Base Housecode is set to "A".
To change this you must first send a leading SYNC pattern of 16 x FF bytes
to the interface, followed by the identifier "0" for "download base Housecode"
and then of data, the upper nibble of which contains the Housecode information.
See below.

BYTE    D7    D6    D5    D4    D3    D2    D1    D0
1-16    1      1     1     1     1     1     1     1  Sync, 16 X FF
 17     0      0     0     0     0     0     0     0  ID 0, download Base 
 18    ---HOUSECODE------------- 0     0     0     0  See table 1.


House   Byte 18     House   Byte 18     House   Byte 18
  A       60         B       E0          C       20
  D       A0         E       10          F       90
  G       50         H       D0          I       70
  J       F0         K       30          L       B0
  M       00         N       80          O       40
  P       C0 

Base Housecode is used by the rocker keys on the Interface.  Changing the
Base Housecode will reset all timer events and graphics data stored in the
Interface, therefore before downloading a new Base Housecode to the Interface,
the program should warn the user of this.  (E.G. the program could display
"Warning changing Base Housecode will erase all program information.  Continue
with change yes/no".)

After a successful download, the Interface will acknowledge by sending the
"ACK" message to the computer.


Byte    D7    D6    D5    D3   D2   D1   D0
1-6      1     1     1     1    1    1    1  FF X 6
 7       0     0     0     0    0    0    S  Status

The STATUS bit is reset to "0" during power up of the Interface and is set
to "1" by a download of data from the computer (any data with byte 17 equal
to ID 0, 1, 2, or 3).  The STATUS bit is used to warn the computer that the
Interface has been powered down.  E.G. a STATUS bit equal to "0" could tell
the program to display a message such as "The Interface has been powered
down and contains no data.  Press Enter to continue".


To turn something ON or OFF or adjust the brightness level of a light
instantly,m it is first necessary to send a leading SYNC pattern of 16 x FF
bytes of data to the interface.  This is then followed by the identifier "1"
for "direct command" and then 4 bytes of data followed by a check sum.  The
check sum is the sum of bytes 18 through 21.  See below.

BYTE     D7  D6  D5  D4  D3  D2  D1  D0
1-16      1   1   1   1   1   1   1   1   SYNC FF x 16.
 17       0   0   0   0   0   0   0   0   ID1, Direct command.
 18           LEVEL          FUNCTION       See notes 1 and 2.
 19         HOUSECODE     0   0   0   0     See table 1.
 20       9  10  11  12  13  14  15  16   Bit mapped unit codes.
 21       1   2   3   4   5   6   7   8   X-10 Modules.
 22                   CHECK SUM           Sum of bytes 18-21.

"LEVEL" is dimmer settings for lamps.  This applies only to X-10 Lamp Modules
and Wall Switch Modules.  Level F Hex is full DIM and level 0 Hex if full
BRIGHT.  The lamps specified by bytes 20 and 21 will switch on, adjust to full
brightness and then DIM to level specified by the upper nibble of byte 18.
All codes between 0 Hex and F Hex are acceptable thus providing 16 discrete
light levels.

D3  D2  D1  D0  Function    Explanation
0    0   1   0    ON        Modules with house codes as specified   
                            by upper nibble byte 19 and unit codes as 
                            specified by bytes 20 and 21 will turn on.

0    0   1   1    OFF      As above, except turn OFF.

0    1   0   1    DIM      Lamp Modules and Wall Switch Modules addressed as 
                           above will turn on, adjust to full intensity and 
                           then DIM to the level specified by upper nibble of 
                           byte 18.  Appliance Modules do not respond to 
                           bright and dim codes.

If the check sum is accepted, the Interface will send the ACK response to the
computer and will then transmit the X-10 codes onto the house wiring.  When
the power line transmission is complete the command is uploaded to the computer
(see command upload).  Also, if X-10 codes are transmitted by pressing the keys
on the Interface, at the end of each transmission the codes are uploaded to
the computer.  This allows the computer to keep track of the ON/OFF status
of the Modules while it is connected to the Interface.

Example 1:  Turn ON modules A1 and A4
Bytes:   1-16  17  18  19  20  21  22
Data:     FF   01  02  60  00  90  F2

Example 2:  Turn OFF modules A1 and A4
Data      FF  01  03   60  00  90  F3

Example 3:  Turn on lamp module B9 and DIM to 50%
Data      FF  01  75   E0  80  00  D5

Example 4:  Turn OFF all modules with housecode A
Data      FF  01  03   60  FF  FF  61

COMMAND UPLOAD (Interface to Computer)
This follows every transmission of X-10 onto the power line either from
pressing the rocker keys, or from direct commands, or from timed events.
This enables the computer to keep track of the ON/OFF status of lights and

Byte   D7  D6  D5  D4  D3  D2  D1  D0
1-6     1   1   1   1   1   1   1   1   FF X 6.
7       0   0   0   0   0   0   0   0   Status.
8          HOUSECODE       FUNCTION     See note 4 below.
9       9  10  11  12  13  14  15  16   Bit mapped unit codes of
10      1   2   3   4   5   6   7   8   X-10 Modules.
11      BASE HOUSECODE  0   0   0   0   Same as table 1.
12                 CHECK SUM            Sum of bytes 8-11.

NOTE 4 -House code same as table 1.  Function same as note 2, except that
the code for DIM is UPLOADED to the computer as 0100 (4hex).

SET CLOCK (Computer To Interface)
To set the clock in the Interface it is first necessary to send a leading
SYNC pattern of 16 X FF bytes of data.  This is followed by the identifier "2"
for set clock and then 3 bytes of data followed by a check sum.  This check
sum is the sum of bytes 18 thru 20.  See below.

Byte   D7   D6   D5   D4   D3   D2   D1   D0
1-16    1    1    1    1    1   1    1    1     SYNC 16 X FF.
17      0    0    0    0    0   0    1    0     ID2, set for clock.
18      0    0             MINUTES              HEX 00 to 3B (0 TO 59).
19      0    0    0         HOURS               HEX 00 to 17 (0 TO 23).
20      0   Sun  Sat  Fri  Thu Wed  Tue  Mon    Bit mapped Days.
21                    CHECK SUM                 Sum of bytes 18 to 20.


EXAMPLE 1  To set clock to 9:30 a.m. on Monday.
BYTE  1-16   17   18   19   20   21
DATA   FF    02   1E   09   01   28

EXAMPLE 2  To set clock to 7:45 p.m. on Friday.
BYTE  1-16   17   18   19   20   21
DATA   FF    02   2D   13   10   50

(Computer to Interface)

To download either a timed event or graphics data you must frist send a
leading sync pattern of 16 X FF bytes.  The ID. (Byte 17) is 3 HEX for both
timer events and graphics data but D2 in Byte 19 is a "0" for timer events
and a "1" for graphics data.

Timer events are stored in bytes 0 to 1023 of the 2k X 8 RAM in the interface.
Only bytes 20 to 27 of the downloadable message are stored.  Each event (group
of 8 bytes) is assigned a Start Address in the RAM in the Interface.  This
Star Address is specified by A0-A4 in Byte 18 and A5-A6 in Byte 19.  D0, D1,
and D2 in byte 18 must ALWAYS be 0, so that the Start Addresses increase in
multiples of 8 (0, 8, 16, .... 1016).  The computer should keep track of the
event Start Addresses and load new events into vacant address locations in RAM.
Byte 20 designates the type of timer event as shown in table 4.  Bytes 21
through 23 set the time and day of the event.  Bytes 24 and 25 specify which
Modules will be controlled and byte 26 specifies the Housecode of these
Modules.  Byte 27 specifies whether the Module(s) will turn ON, OFF, or
DIM and to what brightness level.  Byte 28 is the sum of bytes 20 to 27.

BYTE   D7   D6   D5   D4   D3   D2   D1   D0
1-16    1    1    1    1    1    1    1    1    SYNC 16 X FF
17      0    0    0    0    0    0    1    1    ID3, event/graphics download.
18     A4   A3   A2   A1   A0    0    0    0    A0 to A6 binary coding of
19      x    x    x    x    x    0   A6   A5    event number.
20      0    0    0    0         MODE           See table 4.
21      0   Sun  Sat  Fri  Thu  Wed  Tue  Mon   Bit map of days.
22      0    0              HOUR                HEX 00 to 17 (0 to 23).
23      0    0    0        MINUTE               HEX 00 to 3B (0 to 59).
24      1    2    3    4    5    6    7    8    Bit map of unit codes.
25      9   10   11   12   13   14   15   16    Bit map of unit codes.
26         HOUSECODE        0    0    0    0    Same as table 1.
27          LEVEL               FUNCTION        Same as Notes 1 and 2.
28                   CHECKSUM                   Sum of bytes 20 to 27.



BYTE 20 lower nibble
D3    D2    D1    D0    MODE      EXPLANATION
 1     0     0     0    NORMAL       Occurs on a weekly cycle at 
                                     the same time each day, on 
                                     day or days specified by byte 
                                     21 and at the time specified 
                                     by bytes 22 and 23.  The 
                                     function and codes for event 
                                     are specified by bytes 24 to 27.

 1      0     0     1    SECURITY    Same as NORMAL mode 
                                     except that the event time 
                                     will be different each day 
                                     and will be within one hour 
                                     after the time specified by 
                                     byte 22.  (varies in a 
                                     pseudo random pattern). 
                                     SECURITY is only available in 
                                     EVERYDAY and SPECIFIC DAYS  
                                     modes, see note 5.

BYTE 20 lower nibble
D3    D2    D1    D0    MODE      DESCRIPTION
 0     1     0     0    TODAY     EVENT occurs only TODAY at 
                                  the time specified by bytes 22 
                                  and 23. and will be cleared from 
                                  memory at midnight TODAY.

 0     0     1     0    TOMORROW   EVENT occurs only TOMORROW 
                                   at the time specified by bytes
                                   22 and 23. and will be cleared 
                                   from memory at midnight 

 0     0     0     0     CLEAR      Clears from memory, the 
                                    event specified by the event 
                                    number stored in bytes 18 
                                    and 19.

In addition to TODAY and TOMORROW, it is suggested that the program offer the
user the choice of EVERYDAY and SPECIFIC DAYS.  If EVERYDAY is chosen, byte
21 should be sent as 7F HEX (all days selected).  If SPECIFIC DAYS is chosen,
byte 21 should indicate which days were chosen.

Graphics data is stored in bytes 1024 to 1535 of the 2K  x 8 RAM in the
interface.  Only bytes 20 and 21 of the downloaded message are stored.  Each
pair of bytes is assigned a number between 0 and 511 as specified by A0 to A6
in byte 18 and A7 in byte 19.  D0 in byte 18 is ALWAYS '0' so these address
numbers increase in steps of 2 (for graphics type and X-10 code of 256
objects).  Note also that byte 19 D1 is ALWAYS "0" and D2 is ALWAYS "1".
The computer should keep track of the message numbers and load new messages
into vacant address locations.  The contents of bytes 20 and 21 depends on
the graphics approach used by the programmer (see note 6), the interface
merely stores this data and will upload it to the computer upon request (see
graphics upload).  Byte 22 is the sum of bytes 20 and 21.

BYTE   D7   D6   D5   D4   D3   D2   D1   D0
1-16    1    1    1    1    1    1    1    1   Sync 16 X FF
17      0    0    0    0    0    0    1    1   ID3, event/graphics download.
18     A6   A5   A4   A3   A2   A1   A0    0   A0 to A7, binary number for
19      X    X    X    X    X    1    0   A7   graphics object- 256 objects.
20                 GRAPHICS DATA               User RAM to define type and
21                 GRAPHICS DATA               X-10 code of graphics object.
22                   CHECK SUM                 Sum of bytes 20 and 21.


Note 6
A suggested allocation for byte 20 is shown below.
BYTE 20   D7   D6   D5   D4   D3   D2   D1   D0
          1=ON          ICON TYPE

ICON of a lamp shown in the ON state.
           1    0    0    0    0    0    0    1
ICON of a T.V. shown in the ON state.
           1    0    0    0    0    0    1    0
ICON of a coffee pot shown in the ON state.
           1    0    0    0    0    0    1    1
ICON of a fan shown in the OFF state.
           0    0    0    0    0    1    0    0

Byte 20 = 0 indicates a vacant ICON storage location.  To clear an ICON from
the Interface you need to send a graphics download with byte 20 = 0.  Note,
after doing this, you should also send a DOWNLOAD TIMER EVENT message with
byte 20 = 0 (to clear any timed events for the removed ICON).

A suggested allocation for byte 21 is shown below.

BYTE 21    D7   D6   D5   D4  !  D3   D2   D1   D0
              HOUSECODE OF    !  UNIT CODE OF 
              STORED ICON     !  STORED ICON

(Interface to Computer)

To upload the time and Base Housecode from the Interface it is first necessary
to send a leading SYNC pattern of 16 X FF bytes, followed by an ID4 for the
request clock and Base Housecode.  See below.

BYTE    D7   D6   D5   D4   D3   D2   D1   D0
1-16     1    1    1    1    1    1    1    1    SYNC FF X 16
17       0    0    0    0    0    1    0    0    BASE Housecode.

If the Interface receives the request correctly it will respond by uploading
the clock and Base Housecode to the computer, as shown.  If the request is
not received correctly, no response is given.

Byte   D7   D6   D5   D4   D3   D2   D1   D0
1-6     1    1    1    1    1    1    1    1   SYNC 6 X FF
7       0    0    0    0    0    0    0    S   status bit. *
8       0    0             MINUTES             HEX 00 to 3B (0 to 59)
9       0    0    0         HOURS              HEX 00 to 17 (0 to 23).
10      0   Sun  Sat  Fri  Thu  Wed  Tue  Mon  Bit mapped days.
11      BASE HOUSECODE      0    0    0    0   Same as table 1.
12                  CHECK SUM                 Sum of bytes 8 to 11.

* The STATUS bit is reset to "0" during power up of the Interface and is set
to "1" by a DOWNLOAD of data from the computer (any data with byte 17 equal to
ID 0
, 1, 2, or 3).  The STATUS bit is used to warn the computer that the Interface
has been powered down.  E.G. a STATUS bit equal to "0" could tell the program
to display a message such as "The Interface has been powered down and contains
no data.  Press Enter to continue".

REQUEST TIMER EVENTS (Interface to Computer)
To upload the timer events from the Interface it is first necessary to send a
leading SYNC pattern of 16 X FF bytes, followed by an ID5, for request timer
events.  See below.

BYTE   D7   D6   D5   D4   D3   D2   D1   D0
1-16    1    1    1    1    1    1    1    1    SYNC FF X 16
17      0    0    0    0    0    1    0    1    ID5, request timer events.

The Interface will respond by uploading to the computer, all of the 128 events
starting with number 1 as shown below.  A vacant event is represented by a
single FF byte, this shortens the time for the upload.  The check sum does
not include these FF bytes.


BYTE   D7   D6   D5   D4   D3   D2   D1   D0
16      1    1    1    1    1    1    1    1     SYNC FF X 6.
7       0    0    0    0    0    0    0    0     Status.
24-149  1    1    1    1    1    1    1    1     FF X 126 to indicate 126 
                                                 vacant event spaces.  
150                   CHECK SUM                  Sum of bytes 8 to 23 (FF 
                                                 bytes ignored).

REQUEST GRAPHICS DATA (Interface to Computer)

To upload graphics data from the Interface it is first necessary to send a
leading SYNC pattern of 16 X FF bytes followed by and ID6, for request
graphics data.  See below.

BYTE    D7   D6   D5   D3   D2   D1   D0
1-16     1    1    1    1    1    1    1    SYNC FF X 16
17       0    0    0    0    1    1    0    ID6, request graphics data.

The Interface will respond by uploading to the computer, all of the 256
ICONS starting with number 1, as shown on page 33.  A vacant ICON space is
represented by a single FF byte, this shortens the time for the upload.  The
check sum does not include these FF bytes.


BYTE    D7   D6   D5   D4   D3   D2   D1   D0
1-6      1    1    1    1    1    1    1    1    SYNC FF X 6.
7        0    0    0    0    0    0    0    0    Status.
8-9                   ICON NUMBER 1              2 bytes.
10-11                 ICON NUMBER 2              2 bytes.
12-13                 ICON NUMBER 3              2 bytes.
14-15                 ICON NUMBER 4              2 bytes.
16-17                 ICON NUMBER 5              2 bytes.
18-268   1    1    1    1    1    1    1    1    FF X 251 to indicate 251 
                                                 vacant ICON spaces.
269                    CHECK SUM                 Sum of bytes 8 to 17 (FF 
                                                 bytes ignored).


The Interface has a self test diagnostic routine which is initiated by sending
a leading SYNC pattern of 16 X FF bytes followed by a ID7.  Upon receiving
this instruction, the Interface will run a self check on it's own hardware and
software (firmware).  The output of the Interface (pins 3 and 4) will go low
for 10 seconds as part of this test.  If the check is o.k. the Interface
will respond by sending the ACK with status "0".  If a fault is diagnosed,
the interface will Send ACK with status "1" or will not respond.

BYTE    D7   D6   D5   D4   D2   D1   D0
1-16     1    1    1    1    1    1    1    SYNC FF X 16
17       0    0    0    0    1    1    1    ID7, initiate self test.

The above programming guide is included when you purchase the interface.  I
checked and it is freely distributable.  And remember, if you don't want to
control more than 95 modules, you don't need to create your own program (as
stated previously.

If you want to read further on the X-10 system, then go to there web page at  They have information on all the products they carry,
as well as ones still in the works.  Also on the web page is a FAQ (Frequently
Asked Questions) file that has a wealth of information on the X-10 system
and compatible products.  Unfortunately, the interface is no longer sold
packaged with the Commodore cable and software.  So, you must purchase the
interface packaged with some other software and call X-10 and order the
Commodore connection package separately for $25.  Of course you can create
a cable and copy the software (it is also freely distributable) if you
wanted to.  To get the interface and any modules or compatible products,
Home Controls has a great selection, and there catalogue is filled with
home automation equipment.  X-10's and Home Controls addresses and phone
numbers are as follows:

X-10 (USA) INC.
91 Ruckman Rd.
Closter, NJ  07624
Phone: 201-784-9700

Home Controls INC.
7626 Miramar Road, Suite 3300
San Diego, CA  92126-4446
Phone: 800-266-8765  or  619-693-8887


 !......The Metal Shop......!
                                                     // - The Metal Shop - //

                      ^...!..The Metal Shop..!...^

  Contributors : XmikeX  (
                 Co-Sysop of DiamondBack BBS (305)258-5039

                 David Wood (

                 Marc-Jano Knopp and Daniel Krug

Dear Metal Shop,

    I recently found a 16 KB Commodore expander for my trusty VIC-20.  My
glee turned to disgust after realizing that I needed the proper DIP scheme
required to bank the memory into the VIC.  I barely know the old '20, much
less this expander.  Please tell me this will be easy.... :)



You are in luck RE because as the Good Lord would have it, I have also run
into a VIC-20 expander!  Ok...I didn't just "run" into it...  I actively
sought one out to view the new Veni Vedi Vic (Vedi Veni Vic?) demo by Marko
Makela (with umlauts over the a's).  :)  And oh Yes, this will be easy!

Without much further ado, I decoded the DIP scheme for my 16 KB VIC-20
expansion cartridge, as follows :

CBM VIC-1111 16 KiloByte RAM expansion cartridge with eight DIP scheme
Expansion RAM bank 1                            Expansion RAM bank 2
(8 KB)                                          (8 KB)
                          8 KB Mapped to :
1     2     3     4                             5     6     7     8
on    off   off   off   -> $A000-RAM/ROM4 <-    on    off   off  off
off   on    off   off   -> $6000-RAM/ROM3 <-    off   on    off  off
off   off   on    off   -> $4000-RAM/ROM2 <-    off   off   on   off
off   off   off   on    -> $2000-RAM/ROM1 <-    off   off   off  on

As is evident above, the DIP settings for each bank yield identical results 
so I suspect that the settings for the 8 KB CBM ram expander follow the same
scheme.  8 KB chunks do keep things simple, and we can either give the VIC-20
just 8 KB of expansion memory at $2000, $4000, etc., or we can activate both
banks and map them to these RAM/ROM expansion blocks within the VIC's memory
map for 16 KB total.  For example, whereas 8 KB ROM images are usually quite
happy with 8 KB of memory at RAM/ROM4, most 16 KB rom images tend to require
that RAM/ROM blocks 3 and 4 be active.  We can accomplish this by mapping
expansion bank 1 into $6000 and bank 2 into $a000 (or vice versa!).  In this
case, our DIP settings could be :
        1     2     3     4     5     6     7     8
        off   on    off   off   on    off   off   off
        on    off   off   off   off   on    off   off
Please note that with the CBM 16k expander, we cannot map any of its memory
to the 3 KB expansion area sitting at $0400-0fff (1024-4095).  - XmikeX

[Ed. Note : The following is a response to the 1541 <-> Apple disk ][
 discussion that appeared in this column, issue 2.  It has been reprinted
 in its entirety with permission from the author.]

From    :
Date    :  19-JAN-1997 08:58:43.19
Subject :  info on 1541/disk ][ transfers

First: Thank you disC=overy magazine.  I've read a few zines, and only yours
and C= Hacking make the bet for me.

Keep up the _good_ work!

Dear Metal Shop,

I was reading the article in the disC=overy magazine, issue two.  In there
was a section from a user who has an Apple ][ computer who wished to
transfer files from the computer's disk drive to the Commodore 1541 (or was
it vice-versa?).

I am commenting on the hardware aspect of the disk ][ drives on the Apple
computer.  When I was in college, my 1541 failed completely due to
lightning.  The main board was fine, but the read/write head was blown
"open" as I discovered in the school's electronics lab.  Remembering my
days on the ol' ][ in high school, I thought of hooking a disk ][ assembly
to the 1541 board.

I acquired a junk drive assembly from a friend, unhooked all the
electronics, and re-wired the assembly to the 1541 drive's CPU board. 
Voila!  The system ran fine, until I could come up with a low-density
single-sided assembly from a PC to fit "inside" the 1541's case.  It even
ran fastloaders and GEOS.

Point at hand?  The disk ]['s mechanical assembly is functionally identical
to the 1541's drive assembly.  In fact, the Alps assembly was used in some
Apple compatible drives (am I right?).  Reading Apple disks on the 1541 will
be one hell of a challenge, because of the drive's limited RAM.  

However, reading Commodore's GCR format should be fairly easy if you have a
little advanced knowledge of the disk ][ interface.  All you have to do is
get a modified CBM DOS binary into the Apple ][, and have it read the
Commodore disk.  Not a trivial task mind you.  When the DOS is in the Apple,
the rest is easy.  simply change the locations the program uses to
read/write the disk, and you have it.

Hope I was helpful!

-David Wood

ps:  All the disk ][ is (with the interface included), is a 1541 with no
brains. :)

[Ed. Note : The text below to the end of the article is a sample of the C=
 hardware repair and enhancement projects put out by Marc-Jano Knopp & Daniel
 Krug on the WWW
 Reprinted with permission.]

                                   SAFER SID!

Project: Protection circuit for SID
Target : C64 (all models)
Time   : 20 min
Cost   : ~1 US$
Use    : Protect the SID from overvoltage.

 The SID cannot stand more than 3Vss or 1Veff, respectively.
 Therefore, if you use the SID audio input, the input voltage
 should be limited. The circuit below limits the input signal
 to about 1.4Vss. This is done by two antiparallel silicon diodes
 which cut off the signal at +/- 0.7V. The resistor limits the
 current coming out of the audio source.


  - 1 resistor 470 ohm
  - 2 diodes 1N4148 (or 1N914)


  1. Build the following circuit:

  SID protection circuit

  (5)  O---------o----------o-------XXXXX-----O  Audio in
                 |          |
                 |          |                    __
              +-----+     -----                 /  \
 <-- to SID    \   /       / \          <--   -+----+----+-
                \ /       /   \                      \__/
               -----     +-----+
                 |          |
  (2)  O---------o----------o-----------------O  GND

  XXXXX  = resistor 470ohm
  diodes = 1N4148 or 1N914

 2. ... and stuff it in a DIN plug for the AV jack.

                         SPONTANEOUSLY RESETTING C-64?

Symptom: C-64 resets at random.
Target : C64 (all models) and VC20
Time   : 10 min.
Cost   : <1 US$


  Voltage level floats near to forbidden zone (unstable voltage
  below ~4 volts).


  Pull-up resistor between pin 3 (/RESET) and pin 2 (+5V) of
  user port. Value should be in the range of 4.7k to 10k,
  starting with 10k.


  C-64s which are used industrially, should be equipped with an
  additional 100nF capacitor connected between pin 3 (/RESET) and
  GND (pin 1), which provides excellent noise immunity.
  The same applies to users encountering reset problems due to
  a long reset switch cable.


  - resistor of 10k (or less)


  1. Open case, disconnect power plug!

  2. Solder one end of resistor to pin 2 the other end to pin 3
     of the user port connector. DO NOT solder the leads directly
     onto the contact area, instead try soldering them to the
     nearest visible bare point connected to the above pins.

  3. Connect power plug and keep your C-64 running for several
     hours. See if it resets spontaneously as before; if not,
     close the case again.

Possible failures

  - Resistor's value is too high, try 5.6k or 4.7k otherwise.

                               'FIX' RESTORE KEY!

Project: Make RESTORE key behave like all the other keys
Target : C64 (old)
Time   : 15 min.
Cost   : <1 US$
Use    : Never hear the RESTORE key singing
         'Killing me softly ...' again.


   Replace 'NMI-capacitor' C38 by a 4.7nF one.

   The value of the built in capacitor responsible for triggering
   the NMI via the timer 556 is too small in old C-64's (big PCB).
   On account of the pressure dependant resistance of the keys,
   pressing the RESTORE key just as softly as the other keys is not
   sufficient for producing a trigger signal at the timer's TRIG
   input. Therefore, we will replace it with a 4.7nF capacitor.
   The problem described above was fixed in the new (small) PCB's
   and in the SX-64.

  - 1 capacitor 4.7nF


  1. Open case, disconnect power plug!

  2. Search for capacitor C38 (51pF) below the leftmost CIA. In
     most boards it is built into a resistor case with green base
     color! Its color code is: green-brown-black

  3. Unsolder it and replace it with the 4.7nF one.

  4. Connect power plug.

  5. Switch your C-64 on. After the startup screen appeared press
     [STOP]-[RESTORE] just as softly as you would usually hit the
     other keys. Repeat that procedure a few times and if the
     RESTORE key seems to behave like the other keys, close the
     case again.

Possible failures

 - Replaced the wrong capacitor. Often the capacitor is built into
   a resistor case.

                                 BLACK SCREEN

Symptom: Screen remains black.
Target : C-64

  Possible sources of failure
    - Power supply's fuse is blown -> no power :)
    - continuous reset -> no startup
    - Fuse -> no 12V for VIC (old C-64)
    - Voltage regulator -> no 12V, no fun (old C-64)
    - CPU -> blocks phi2 or bus
    - VIC -> blocks bus
    - SID -> blocks bus
    - PLA -> well.... :)
    - 8701 -> no clock cycles
Analysis - Power supply ok?

  If the power LED is not lit, check the power supply's fuse and
  replace it, if necessary. Next, measure the voltage directly on
  the power plug. If you cannot find 5VDC and 9VAC anywhere, kick
  the power supply and get a new one.

  If you have an old C-64, check its internal fuse now.

  Then check the 5V at the power jack (before the switch!) with
  the power supply plugged in and the C-64 switched on. It should
  be between 4.9 and 5.1V. If not, a defective IC might demand a
  current so high that the 5V level gets pulled below 4.8V. You
  should be able to locate the very IC by simply touching all the
  chips and checking for especially hot ones. Replace it.

  Next, measure the 5V supply voltage between pin 7 (GND) and pin
  14 (Vcc) of a 74xx chip. If the 5V show to be ok, then continue
  with 'Voltage regulator ok?'.
  Otherwise, it is very likely that the cause for the low vol-
  tage level is - believe it or not, it DID happen to a lot of
  people - the power switch(!), so that it could be a good idea to
  either rock the switch several dozen times, open and clean it or
  to replace it completely.

Reset line HIGH?

  Since it is possible that the black screen is caused by a con-
  tinuous reset, you should check the voltage between pin 1 (GND)
  and pin 3 (/RESET) of the user port. If it is below 1V, then
  check the reset switch, if you got one. Otherwise, check wether
  the output levels of the 7406 and 74LS14 (new board) match their
  input levels. Next, you should check the timer 556 (old board)
  when I managed to offer you a description for that chip :) Until
  then, simply replace it, it is not socketed, but cheap.

  If that does not help, some other chips load the reset line so
  that the level is below 2.4V which causes the CPU to reset. Try
  a pull-up resistor (4.7k) between pin 2 (+5V) and pin 3 (/RESET)
  of the user port. If that does not make the blank screen vanish,
  check for other defective chips (which probably become very hot,
  see later in this document).

Voltage regulator ok?

  In case you have an old C-64, check the 12V voltage regulator
  VR1 (7812). At the output (right pin, 2) you should measure
  around 12V (11.8 to 12.3V). If not, measure the input voltage
  (left pin, 1), the voltmeter should show about 15 to 20V. If the
  latter is the case, replace the VR. If the input voltage is out
  of range, check the 9VAC on the power plug (with the C-64 still
  switched on). If they prove to be ok, then the two diodes before
  the voltage regulator could be damaged; replace them. If you cannot
  find the 9VAC, make sure you have checked for the C-64's internal
  fuse and otherwise get another power supply.

CPU running?

  Try accessing the floppy drive by typing blindly (you do not
  need to close your eyes)

    LOAD"$",8   (assuming your device id is '8')

  If the floppy drive's motor starts spinning, you are lucky. The
  processor, the CIA's and the address manager seem to work.
  If the floppy does not react in any way, you probably have a
  serious problem and should continue reading...

Other chips alive?

  Test VIC, SID, PLA and, where applicable, the clock circuit 8701
  near the VIC (not in very old PCB revisions), whether they get
  extraordinaryly hot. If any of the chips gets hot, it is very
  likely that they are defective and, e.g. block the bus. These
  should be replaced. In C-64s with the new board, you will find
  a 64-pin multifunction chip, the MMU. If the other chips are ok,
  it is probably the MMU which is damaged. Alas, this MMU is prac-
  tically impossible to replace, there are neither suitable
  sockets nor spare chips.

  Of course, every chip connected to the bus in any way could be
  damaged and blocking the bus, therefore you should also check
  if the CIAs, the ROMs, the RAMs, the RIMs or the RUMs (oops) are
  getting extremly hot.  Especially in the old C-64 board, the
  various 74xx/74LSxx might be responsible for the failure.

If all else fails...

  ... you should consider the very low price of a used C-64 on
  the free market or, if you live in a strange country with prices
  over US$ 30 for a C-64 (including power supply), check for
  hair cracks and dry joints.


                A R T I C L E S    O F    O P E R A T I O N

Article 1 : Mission Statement
Our intent is to present useful information in order to enhance and preserve
the knowledge base of the Commodore 8-bit domain, including, but not limited
to, the Commodore 64 and Commodore 128 home computers.  To this end, we shall
require that every article contain what in our discretion should be a viable
Commodore 8-bit hardware and/or software point of relevance.  Likewise, each 
issue should include material that can both potentially enlighten the most
saavy of users as well as the layman.  We intend to complement and assist all
others engaged in similar endeavours.  We believe it is of paramount concern
to stave off entropy as long as possible.
Article 2 : disC=overy Staff
The current staff of disC=overy, the Journal of the Commodore Enthusiast,
is as follows:
      Editor-in-Chief       : Mike Gordillo  (
      Associate/Tech Editor : Steven Judd    (
      Associate/Tech Editor : George Taylor  (
      Webmaster             : Ernest Stokes  (

      disC=overy, issue 3 logo by 'WaD'
We invite any and all interested parties to join us as authors, panelists,
and staff members.
Article 3 : General Procedures

- Submission Outline -

a. Articles may range in size from 1 kilobyte and up.  Approximately 15
   kilobytes of text is the preferred length, including any software present.

b. Sufficient technical content about Commodore 8-bit home computers,
   concerning software and/or hardware relevant to these systems, is a 
   requirement.  What constitutes a sufficient amount of 'technical
   content' is left to the discretion of the Editor-in-Chief and/or the
   review panel (see below).

- Staff Priorities -

The Editor-in-Chief shall supervise the organization of each issue in regards
to grammatical and syntactical errors, flow of content, and overall layout of
presentation.  The Editor-in-Chief and Associate Editor shall form a review
panel whose function it shall be to referee literary work which the Editor
in-Chief has deemed to be of advanced technical merit.  The Editor-in-Chief
iand disC=overy, the Journal of the Commodore Enthusiast, shall retain
copyright solely on the unique and particular presentation of its included body
of literary work in its entirety.  Authors shall retain all copyrights and
responsibilities with regards to the content of their particular literary
work.  Authors shall be required to submit their works to the Editor-in-Chief
approximately two weeks prior to publication.

Article 4 : Peer Review
To the best of our knowledge, disC=overy shall be the first Commodore 8-bit
journal with a review panel dedicated to uphold the technical integrity and
legitimacy of its content.  The Editor-in-Chief and the Associate Editor
shall be responsible for the formation of the panel.  The appointed
panelists shall have the option of anonymity if desired.  The panel shall
review works primarily for technical merit if the Editor-in-Chief and
the Associate Editor deem it necessary.  Authors may be asked to modify
their works in accordance with the panel's recommendations.  The Editor-in-
Chief shall have final discretion regarding all such "refereed" articles.

Article 5 : Distribution

Although we welcome open distribution by non-commercial organizations, there
are currently four "official" distribution channels available to interested
parties.  This journal may be obtained by directly mailing the Editor-in-Chief
or via the World Wide Web at and
at FTP site : - directory /u/t/tpinfo/C64/Magazines/discovery
A "snail" mail disk copy of any issue of this journal may also be obtained
from Arkanix Labs at the following physical address :

   disC=overy, c/o Jon Mines
   Arkanix Labs
   17730 15th Ave NE  Suite #229
   Shoreline, WA  98155

This source should follow the distribution guidelines as listed in Article 6
below.  However, specific questions concerning billing, etc., should be
directed at them.

Several versions of this journal may be available for your convenience, please
check with the aforementioned sources.

Article 6 : Disclaimers
The Editor-in-Chief and disC=overy, the Journal of the Commodore Enthusiast,
retain all copyrights regarding the presentation of its articles.  Authors
retain all copyrights on their specific articles in and of themselves,
regarding the full legal responsibility concerning the originality of their
works and its contents.

The Editor-in-Chief and disC=overy, the Journal of the Commodore Enthusiast,
grants the reader an exclusive license to redistribute each issue in its
entirety without modification or omission under the following additional
      - If distribution involves physical media and is part of a commercial,
        not-for-profit, or PD distribution, the maximum allowable monetary
        charge shall not exceed $4 1996 United States Dollars per issue
        unless more than one issue is distributed on a single media item
        (i.e., two or more issues on one disk), in which case maximum
        allowable charge shall not exceed $4 1996 United States Dollars per
        media item.  All dollar values given assume shipping costs are
        -included- as part of the maximum allowable charge.
      - If distribution involves non-physical media and is part of a
        commercial, not-for-profit, or PD distribution, the maximum
        allowable charge shall be limited to the actual cost of the
        distribution, whether said cost be in the form of telephony or
        other electronic means.

      - Software included within articles (as text) may be subject to separate
        distribution requirements as binary executables.  Please check directly
        with authors regarding distribution of software in binary form.

      - disC=overy should be distributed on per-issue basis, and any potential
        subscription arrangements are strictly between distributor and reader.
        We do not guarantee subscriptions nor do we take responsibility for
        distribution outside of the disC=overy home page on the World Wide
        Web (

It is understood that distribution denotes acceptance of the terms listed and
that under no condition shall any particular party claim copyright or public
domain status to disC=overy, the Journal of the Commodore Enthusiast, in its
The Editor-in-Chief and disC=overy, the Journal of the Commodore Enthusiast,
reserve the right to modify any and all portions of the Preamble and the
Articles of Operation.

\END:::::::::::::::::::::::::::March 26, 1997:::::::::::::::::::::::::::::::::
magazines/discovery3.txt · Last modified: 2015-04-17 04:35 by