more work on documenting residual similarities with C64 KERNAL

c64/kernal/chrin.s

@@ -27,8 +27,8 @@ chrin_repeat:
 	sta keyboard_input_ready
 	pla
 	tax
-	lda #$0d
 	clc
+	lda #$0d
 	rts
 
 not_end_of_input:
@@ -100,8 +100,8 @@ empty_line:
 	;; the cursor advances and screen scrolls as required)
 	pla
 	tax
-	lda #$0d
 	clc
+	lda #$0d
 	rts
 	
 not_enter:	

c64/kernal/scan_keyboard.s

@@ -220,7 +220,7 @@ Main:
 	;; //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 	;; // Check for Port Activity
 
-	sty $dc00       ;// Connect all Keyboard Rows
+	stx $dc00       ;// Connect all Keyboard Rows
 	cpx $dc01
 	bne skip0
 	jmp NoActivityDetected

src/similarity.c

@@ -132,11 +132,13 @@ int main(int argc,char **argv)
 	  if (f1[i]==0x85) break;
 	  if (f1[i]==0xa2) break; // LDX #$xx
 	  if (f1[i]==0xa9) break; // LDA #$xx
+	  if (f1[i]==0xa0) break; // LDY #$xx
 	  if (f1[i]==0x69) break;
 	  if (f1[i]==0xc9) break;
 	  // Similarly for random byte before such instructions
 	  if (f1[i+1]==0x85) break;
 	  if (f1[i+1]==0xa9) break; // LDA #$xx
+	  if (f1[i+1]==0xa0) break; // LDY #$xx
 	  if (f1[i+1]==0x69) break; // ADC #$xx
 	  if (f1[i+1]==0xc9) break; // CMP #$xx
 	  

strings/028E8302

@@ -0,0 +1,3 @@
+something followed by STX $0283
+
+One and a half instructions are not copyrightable.

strings/029900

@@ -0,0 +1,4 @@
+part of two instructions $02 STA $xx00,Y
+
+This sequence isn't even a whole instruction.  It is 
+not copyrightable, containing no creativity or distinguishing content.

strings/03DC8E

@@ -0,0 +1,3 @@
+Fragment dealing with $DC03, followed by  STX $nnnn
+
+Not even a whole instruction here. Not copyrightable.

strings/04A90085

@@ -0,0 +1,5 @@
+Fragment followed by LDA #$00 / STA $xx
+
+This is a very common sequence of actions (putting $00 into ZP location),
+and fully 1/256 of such instances would be expected by random chance to 
+have a $04 byte preceding it.  Not creativity. Not copyrightable.

strings/186020

@@ -0,0 +1,11 @@
+CLC / RTS / JSR $xxxx
+
+CLC / RTS the obvious and simplest way to clear the carry flag
+when returing from a routine.  Many of the routines in the C64 KERNAL
+public API indicate that they use the carry flag to indicate success
+or failure, hence how often it shows up in the C64 KERNAL itself.
+That a JSR instruction happens to be the first instruction in whatever
+follows actually highly likely through chance, since several percent
+of all instructions in a typical 6502 program are JSR instructions.
+
+Not copyrightable.

strings/20D2FF68

@@ -0,0 +1,7 @@
+Probably JSR $FFD2 followed by PLA
+
+$FFD2 is a publicly listed API of the C64 KERNAL that prints a character.
+It corrupts the contents of the A register. Thus is it totally expected to restore the A register
+from the stack after calling $FFD2.  That this happens several times in the C64 KERNAL itself
+is evidence of this being boilerplate and not copyrightable on that basis, as well as it simply
+being too short and lacking any creativity etc.

strings/489848

@@ -0,0 +1,3 @@
+PHA / TYA / PHA 
+
+Push A and Y onto the stack.  Nothing creative or copyrightable here.

strings/586C00A0A2

@@ -0,0 +1,17 @@
+CLI + JMP ($A000) + LDX #$xx
+
+The C64 programmer's reference guide explains that the KERNAL 
+clears interrupts and jumps into the cold start vector of
+the BASIC ROM on boot. This is exactly what this snippet does,
+and it is the most obvious solution. Also, it is well established
+best practice to disable interrupt masking only at the last moment
+to minimise the risk of an interrupt being triggered before the 
+called program has a chance to setup what it wants.
+The presence of the LDX #$xx following this is the result of the
+mechanical processes of our linker, and is mere coincidence. As 
+this opcode constitutes >1% of opcodes in a typical 6502 program,
+no reasonable claim can be made based on its presence.
+In short, this fragment is the obvious and most simple implementation
+that implements the described functionality p269 of the C64 PRG, as
+well as being too short and lacking creativity to be eligible for
+copyright protection.

strings/68684C

@@ -0,0 +1,8 @@
+PLA / PLA / JMP
+
+Pulling two values off the stack is a common way to simulate returning
+from a routine, i.e., to remove the return address from the stack.
+That such a sequence is followed by a JMP is not at all surprising,
+given this.  But at the end of the day, pulling things off the stack
+and jumping somewhere without a matching destination cannot possibly
+be copyrightable

strings/68A868AAA5

@@ -0,0 +1,8 @@
+PLA / TAY / PLA / TAX sequence / followed by LDA $nn
+
+This is a common sequence for restoring registers from the stack.
+It is a fragment of the reverse of pushing the registers A X and Y
+in alphabetic order.
+The frequency of LDA $nn instructions also makes this complete sequence
+no more remarkable.
+ Not copyrightable.

strings/84028E8302

@@ -0,0 +1,7 @@
+Do something to $0284 followed by STX $0283
+
+The public API for the C64 KERNAL MEMTOP routine
+requires loading and saving these locations from X and Y
+registers.  Thus this is lacking in creativity and not
+copyrightable, even if it were long enough to somehow
+justify copyright, which we do not believe that it does.

strings/88B1D1C891D188B1F3C891F388C4D3D0EFA92091D1

@@ -0,0 +1,44 @@
+Copy screen + colour RAM to the right one place
+
+This sequence of instructions:
+
+loop:
+       DEY
+       LDA ($D1),Y
+       INY
+       STA ($D1),Y
+       DEY
+       LDA ($F3),Y
+       INY
+       STA ($F3),Y
+       DEY
+       CPY $D3
+       BNE loop
+       LDA #$20
+       STA ($D1),Y
+
+is the obvious any minimal way to copy the screen and colour RAM data.
+The constants $D1 and $F3 are fixed by the publicly documented interface
+of the KERNAL to point to the screen and colour RAM of the screen.
+
+The Y register is the only register that can be used to post-increment an
+indirect address on the 6502.
+
+Thus the only efficient manner to copy a string to the right one byte
+is to read, increment Y by one to get the destination address, store,
+then decrement Y again so that it points to the source offset, now read
+the colour RAM byte, add one to Y so that we point to the destination,
+and then write it.  
+
+Similarly the check against $D3 (current column of cursor on screen) is also
+necessary for working out when to terminate the loop.  The storing of $20
+into the screen RAM is also required to effect the insertion of a space.
+
+In fact, about the only variant possible would be to swap the $D1 and $F3
+constants so that the colour RAM is copied before the screen RAM in each
+loop, instead of after it.
+
+It is telling that this routine was the result of independent implementation
+of this routine, without looking at the KERNALs routine, in terms of supporting
+the argument that the routine is the obvious manner in which to do this.
+

strings/8A48A5

@@ -0,0 +1,4 @@
+TXA / PHA / LDA $nn
+
+TXA + PHA is the way to save the X register on the stack.
+ZP loads into A are also very common. Nothing creative or copyrightable here.

strings/8D9D8C898A8B91

@@ -0,0 +1,16 @@
+List of key codes generated when certain key combinations are pressed
+
+This sequence is a list of which ASCII/PETSCII code should be generated
+when certain key combinations are pressed, based on the keyboard matrix
+position.  That is, it is a sequence in keyboard matrix order, of the
+codes that should be generated. Thus it is a list of facts, which cannot
+be copyright, according to the long standing precedent under US copyright law:
+
+https://www.law.cornell.edu/copyright/cases/499_US_340.htm
+
+Similar decisions exist in other jurisidctions.
+
+Note also that the matrix order list of keys is a fact of the C64 hardware,
+and which has been repeated in many publications, such as Compute's Mapping the 64,
+without challenge from the C64 ROM copyright owners, which serves to reinforce the
+claim that this sequence of bytes is not copyrightable.

strings/8D9D8C898A8B9196B3B097ADAEB1

@@ -0,0 +1,16 @@
+List of key codes generated when certain key combinations are pressed
+
+This sequence is a list of which ASCII/PETSCII code should be generated
+when certain key combinations are pressed, based on the keyboard matrix
+position.  That is, it is a sequence in keyboard matrix order, of the
+codes that should be generated. Thus it is a list of facts, which cannot
+be copyright, according to the long standing precedent under US copyright law:
+
+https://www.law.cornell.edu/copyright/cases/499_US_340.htm
+
+Similar decisions exist in other jurisidctions.
+
+Note also that the matrix order list of keys is a fact of the C64 hardware,
+and which has been repeated in many publications, such as Compute's Mapping the 64,
+without challenge from the C64 ROM copyright owners, which serves to reinforce the
+claim that this sequence of bytes is not copyrightable.

strings/A868AA

@@ -0,0 +1,5 @@
+PLA / TAY / PLA / TAX sequence
+
+This is a common sequence for restoring registers from the stack.
+It is a fragment of the reverse of pushing the registers A X and Y
+in alphabetic order. Not copyrightable.

strings/A9003860

@@ -0,0 +1,9 @@
+LDA #$00 / SEC / RTS - Return failure and 0 from a KERNAL routine
+
+The C64 KERNAL public API indicates that the carry flag should be set
+to report failure of many routines, and those routines can also return
+A=$00 as part of that.  
+Also, returning such values from a routine is not uncommon generally,
+and lacks all creativity. Not copyrightable.
+
+

strings/C3C2CD3830

@@ -0,0 +1,15 @@
+CBM80 cartridge signature
+
+This is the string used to compare with the signature block of
+a cartridge. It is required for interoperability with C64 cartridges,
+and the requirement for this string is explicit, and is well documented,
+including the string itself, in many places, such as:
+
+http://mirror.thelifeofkenneth.com/sites/remotecpu.com/Commodore/Reference%20Material/Manuals/Hardware%20Manuals/Datel%20Eprommer64%20Instruction%20Manual.pdf
+
+Indeed, the C64 Programmer's Reference Guide describes it on p263.
+
+Since Commodore instructed cartridge developers to include the string
+in cartridges, it cannot be held to be a violation of copyrights,
+even if it were able to be copyrighted, which we do not accept on grounds
+including that it is a list of facts (published by Commodore themselves)

strings/D004A900

@@ -0,0 +1,15 @@
+Branch over two instructions, first being LDA #$xx
+
+This corresponds to the following sequence:
+
+Bxx +
+LDA #$xx
+(two more bytes not matched
+*
+
+This is the obvious way to conditionally execute two instructions,
+the first of which is LDA #$xx, which is very common.
+
+That the argument of LDA #$xx doesn't match, nor does the following
+two bytes, adds strength to the argument that this is a non-copyrightable
+sequence of bytes.

strings/DCAD0DDC

@@ -0,0 +1,6 @@
+Fragment followed by LDA $DC0D
+
+$DC0D is a register of the 6526 CIA1 in a C64, so reading it 
+is to be expected.  The presence of a byte before the instruction
+in no way constitutes a creative act, and the whole fragment is too
+small to be worthy of copyright protection in any case.

strings/DCEC01DCD0

@@ -0,0 +1,4 @@
+Fragment, CPX $DC01, BRANCH
+
+There is only one whole instruction here.
+Not copyrightable.

strings/EC01DCD0

@@ -0,0 +1,4 @@
+Fragment, CPX $DC01, BRANCH
+
+There is only one whole instruction here.
+Not copyrightable.

strings/FFA0FF

@@ -0,0 +1,3 @@
+Fragment, followed by LDX #$FF
+
+One and a half instructions are not copyrightable.