and more...

strings/0260A9

@@ -0,0 +1,3 @@
+Something, RTS, LDA #$xx
+
+Here is only one whole instruction, and RTS.  Not copyrightable.

strings/028D91024C

@@ -0,0 +1,4 @@
+Fragment / STA $028D / JMP $xxxx
+
+Only one whole instruction. Not copyrightable.
+

strings/AD0DDCAD

@@ -0,0 +1,5 @@
+LDA $DC0D / LDA $xxxx
+
+LDA $DC0D clears pending interrupts on CIA1. 
+Only one whole instruction.
+Not copyrightable.

strings/B1AC91D1

@@ -0,0 +1,5 @@
+LDA ($AC),Y / STA ($D1),Y
+
+Copy a byte from one pointer to another.
+Nothing creative here.
+Not copyrightable.

strings/B1AE91F3

@@ -0,0 +1,3 @@
+LDA ($AE),Y / STA ($F3),Y
+
+Copy byte from one pointer to  another.  Nothing copyrightable here.

strings/C8B1D18891D1C8B1F38891F3C8C4D5D0EF

@@ -0,0 +1,41 @@
+Copy screen + colour RAM to the left one place
+
+This sequence of instructions:
+
+loop:
+         INY
+         LDA ($D1),Y
+         DEY
+         STA ($D1),Y
+         INY
+         LDA ($F3),Y
+         DEY
+         STA ($F3),Y
+         INY
+         CPY $D5
+         BNE loop
+
+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 left one byte
+is to read, decrement Y by one to get the destination address, store,
+then increment 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 $D5 (current length of line) is also
+necessary for working out when to terminate the loop.  
+
+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/D007A980

@@ -0,0 +1,4 @@
+Branch over LDA #$80 and some more 
+
+Branching is extremely common, as is loading the accumulator
+with any specific value.  Nothing creative or copyrightable here.

strings/DE3F815F

@@ -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.