Commodore Trivia
Home  Weblog  Research Kitchen  Contact 
All You Ever Wanted To Know About Commodore Main Menu
Home > Trivia #15A

C64 Chronology
  A comprehensive chronology of the Commodore 64
Zzap! 64
  Fan site for the classic C64 mag
Lemon 64
  Awesome 64 games site
  A C64 on your desktop
RKO C64 Remixes
  Amazing site of C64 SID remixes

Who wrote this stuff?
This trivia was originally written by Jim Brain as part of the now long defunct C= Hacking Magazine, but happily Jim has kindly agreed to let me reproduce it in HTML-ized format for retro computing fans everywhere.

If you are interested in seeing the Commodore Trivia digests in their original form, take a look at this website.

For those who are interested, these pages were generated from the original text files using Perl and Velocity (and a nice template originally found here)


	What is the difference(s) between the Newtronics 1541 and the 1541C?
        (only one difference is needed)

	(George Page, a noted authority on CBM Drives, indicated that Commodore
        made this a tough question to answer.)  By the time the 1541C was 
        introduced, Commodore threw a number of drives together and called
        them 1541Cs.  The theoretical 1541C exhibited the following
        No head banging, and other problems fixed by modified ROMs.
        Case color matches C64C and C128 computers.

	What happens when you type 35072121 in direct mode on the C64 and
        hit return?

	Simple answer:  Most likely, the screen clears and the word READY.
        is printed at screen top.  This is the behavior seen when pressing 
        RUN-STOP/RESTORE.  Alternately, nothing could happen, or the computer
        could lock up.
        Involved answer:  There is a bug in BASIC 2.0.  Easily fixed, but 
        destined to live life immortal.  (long)
        The bug is in the PETSCII number to binary conversion routine at
        $a69b (LINGET).  The routine basically reads in a character from the
        line, multiplies a partial result by 10 and adds the new character
        to the partial result.  Here is a code snippet:
        a96a     rts
        a96b     ldx #$00  ; zero out partial result
        a96d     stx $14
        a96f     stx $15
        a971     bcs $a96a ; not a number, return
        a973     sbc #$2f  ; PETSCII to binary
        a975     sta $07   
        a977     lda $15   ; get hi byte or partial result
        a979     sta $22
        a97b     cmp #$19  ; partial > 6399
        a97d     bcs $a953 ; yes, goto error
        a97f     lda $14   ; load lo byte of result
        a981     asl       ; lo*2
        a982     rol $22   ; hi*2 + c
        a984     asl       ; lo*2
        a985     rol $22   ; hi*2 + c
        a987     adc $14   ; complete lo*5
        a989     sta $14
        a98b     lda $22  
        a98d     adc $15   ; complete hi*5
        a98f     sta $15
        a991     asl $14   ; lo*2 complete lo*10
        a993     rol $15   ; hi*2 complete hi*10
        a995     lda $14
        a997     adc $07   ; add new char
        a999     sta $14
        a99b     bcc $a99f ; did lo overflow?
        a99d     inc $15   ; yes, inc hi
        a99f     jsr $0073 ; get next char
        a9a2     jmp $a971 ; go through it again.
        The problem is at $a97d.  when the partial result is greater than 6399,
        (if partial > 6399, then new partial result will be over 63999)
        the routine needs to get to $af08 to print an error, but can't due to
        branch restrictions.  However, a branch that will get there is in the
        preceding function, which handles the ON GOTO/GOSUB keywords ($a94b,
        So, the BASIC writers just branched to the code in ONGOTO; specifically
        a94b     jsr $b79e
        a94e     pha
        a94f     cmp #$8d  ; is the keyword GOSUB ($8d)
        a951     beq $a957 ; yes
        a953     cmp #$89  ; is the keyword GOTO ($89)
        a955     bne $a8e8 ; no, print SYNTAX ERROR.
        a957     ...       ; handle ON GOTO/GOSUB
        This code is checking to make sure the ON (var) is followed with a
        GOTO or GOSUB keyword.
        The LINGET error handler branches to $a953, which compares
        .A (which holds hi byte of partial result) to $89.  Normally, this
        fails, and the normal SYNTAX ERROR code is reached through the branch
        to $a8e8.  However, for partial results of the form $89XX, the check
        succeeds, and BASIC tries to execute an ON GOTO/GOSUB call.
        By the way, it is no coincidence that this error occurs on 35072121,
        since one of the partial results is $8900 (hi byte is $89). In fact,
        350721 will achieve the same result.
        If the check succeeds, the code limps along until $a96a:
        a969     pla       ; complement to $a94e
        a96a     rts       ; return
        But we never executed $a94e, the push, so the stack is now
        messed up.  Since the stack held $9e, $79, $a5 before the PLA,
        (The stack could hold other values, but I always saw these)
        the RTS gets address $a579 to return to, which usually holds a BRK
        opcode.  The break handler is invoked, and the screen clears with the
        READY. at the top.
        Now, the BASIC 2.0 authors were justified in reusing the error
        handler code in ONGOTO for LINGET, but they calculated the branch
        offset wrong, according to my tests.  If you have the LINGET error
        handler branch to $a955, all these troubles disappear.  You can
        verify this procedure with the following BASIC program on a 64:
        10 for t=57344 to 65535:poke t,peek(t):next
        20 for t=40960 to 49151:poke t,peek(t):next
        30 poke 43390, 214
        40 poke 1, peek(1) and 254
        Just to be complete, this error occurs when a 6 digit or greater line
        number is entered and the first 6 digits indicate a number in the
        range 35072-35327 ($8900-$89ff).  Also, it appears the error occurs
        on the VIC-20, but I didn't completely verify it.  It would be
        interesting to note if the error is found on all version of CBM BASIC.
        Whew, what a mouthful.

	If a SID chip is producing a "sawtooth waveform", does the waveform look
        a) "/|/|/|/|"  or
        b) "|\|\|\|\"  ?

	a is the correct answer.

	On BASIC 2.0, what special precaution(s) must one take when working with
        relative files? (only one is needed)

	Because BASIC 2.0 doesn't handle positioning in relative files quite
        right, one must position the relative file pointer before AND AFTER
        a read or write to a relative file.

	What incompatibility existed between C128 Rev. 0 ROMS and the REU?

	OK, I admit it.  I placed this answer and its discussion somewhere
        in my store of information, and it must have fallen behind the 
        cabinet, because I cannot find it.  I will post an answer to this
        as soon as I can find it, but the answers really must go out, as
        they have been held up long enough.

	What can trigger an NMI interrupt? (count all sources on one chip as

	The following sources can trigger an NMI interrupt:
        1) The expansion port.
        2) CIA #2.
        3) The RESTORE key.

	What can trigger an IRQ interrupt? (count all sources on one chip as

	The following sources can trigger an IRQ interrupt:
        1) The VIC-II chip.
        2) CIA #1.
        3) The expansion port.

	Where is the ROM in a 1541 located in the 64K memory map?

	The ROM is located from $C000 to $FFFF, yet the ROM code does not
        begin until $C100.

	Which VIA on the 1541 is hooked to the read/write head?

	VIA #2, located in memory from $1C00 to $1C0E.

	In the Commodore DOS, what bit in the file type byte denotes a "locked"

	bit 6.

	If files are "locked" under Commodore DOS, under what condition(s) may
        the file be changed?

	Depending on the file, the following operations can be done on a 
        locked file:
        1) Rename will change file name, although not contents of file.
        2) Random access can be used to alter file.
        3) Formatting the disk will alter the file. (duh!)
        4) Save-with-replace (@0:) will replace file and unlock it.
        5) Opening file in append mode will allow it to be changed, and
           unlock it.
        6) Opening a relative file and adding or changing a record will
           succeed and unlock file.

	How big can a program file be on a 1541 or similar?

	The file can be as large as a sequential file, since both are stored
        in the same way: 168656 bytes.  However, since a program contains its
        load address as bytes 0 and 1, the largest program size is 168654

	Under BASIC 2.0, how does one open a random access file on a disk

	Random access (or direct access) files are a misnomer.  What you
        really doing is opening the disk for reading and writing.  You need
        two open command to access a random file: (assume drive 8)
        open 15,8,15     and
        open 1,8,4,"#1" will open a random access file using buffer 1.
        open 1,8,4,"#" will open a random access file using the first
        available buffer
        Now, by using B-R, B-W, B-A or their replacements, you can write
        data to sectors on the disk.
        Note that Random access files are different from relative files.

	A file that has a '*' immediately before the filetype is called
        a _________ file.

	a splat file.  This is its correct term, believe it or not.

	We know the 1541 and similar drives have 5 internal buffer areas, but
        how many does an 8050 drive have?

	Since the 8050 has twice the on-board RAM (4kB), it has 16 buffers, but
        only 13 are available.  (All CBM drives use one buffer for zero-page
        memory, one for stack memory, and one for temporary variables.) 

	On a "save-with-replace", where is the location of the first track and
        sector of the new copy of the program saved in the directory entry for
        the old copy?

	The new first track is stored at location 26, and the new first sector
        is stored at location 27.  These values are copied to their
        correct locations after the save is completed.

Jim Brain
10710 Bruhn Avenue
Bennington, NE  68007
(402) 431-7754


This site 2005 The Research Kitchen and Jim Brain.
Page generated: Sat Oct 14 14:06:37 BST 2006