I have a lot of respect for him...and his ability to survive giant deadly meteor impacts.

http://www.sciencemag.org/news/2016/03/ ... -dinosaurs

Mike B.

Anyway, regardless of who came first it's clear they share a common heritage.

In general, it looks like the origins of many of the early 6502 monitors were pretty incestuous and nobody really bothered much with attribution.

AIUI, it was very unclear as to whether software was even subject to copyright - was it a creative work? That's since been put into a legal framework. (The same is true of physical chip designs, aka layouts - in this case, a new category of copyright was created for the purpose, with a ten year span.)

; Jim Butterfield described the post-processing of Supermon 64 binaries
; in a posting to comp.sys.cbm on Dec 20, 2003:

; I should note that, since Supermon+64 is relocatable code, the source
; does not assemble into the final binary file. It may seem crude, but
; I follow this procedure: (1) The source is carefully structured so
; that there are no "dispersed addresses" such as might be created with
; something like LDA #>VECTOR .. LDY #<VECTOR - every relocatable
; address is two adjacent bytes; (2) I assemble the source TWICE, to
; two different page addresses; the only difference in the binaries will
; be the high-order bytes of the relocatable addresses; (3) a small
; post-processing program blends the two binaries into a relocatable
; package, adding a Basic driver to complete the bundle.

; Source: https://groups.google.com/forum/#!searc ... _UQlwVnPcJ

; This code was disassembled from the original Supermon+64 V1.2 binary.

; The relocation stub starts at the Start of Variables pointer (VARTAB) and
; works backwards through the Supermon64 machine code, copying it to the top
; of basic memory pointer (MEMSIZ), and decrementing the pointer as it goes.
; Relative addresses that need to be adjusted are marked with a $36 byte
; immediately following them. Since we're working backwards, the marker is
; encountered first, then the high byte, then the low byte of the address
; needing to be adjusted. The relative addresses are calculated such that
; adding the top of memory to them will yield the absolute address of the
; jump target in the relocated code.

; The next step will be to build a Python script that will take Supermon64
; binaries assembled to two different addresses and output relocatable code
; with the relative addresses and $36 address markers.

; ... (1) The source is carefully structured so
; that there are no "dispersed addresses" such as might be created with
; something like LDA #>VECTOR .. LDY #<VECTOR - every relocatable
; address is two adjacent bytes; ...