begin implementing preprocessor to generate ROM files

README.md

@@ -48,3 +48,17 @@ We can capture this information using x64 -remotemonitor, and then making a prog
 and uses reset 0 to reset the CPU, and then types step and sends carriage returns repeatedly, and logs the
 instruction stream.  If a program is loaded and run, then this will capture the instruction stream, and allow us
 to generate this call graph.
+
+# Specific Method
+
+1. Begin with the immutable starting point of the 6502 reset entries, IRQ entry and NMI entries, and the rest of the ROM being empty.  This starting point can have no copyright problems.
+2. Based on the public calling interface of the C64 KERNAL, make stub routines for the jump table.
+3. All routines begin at the lowest address in the kernal, sorted by routine name.  Thus the order of the routines is deterministic, and not the result of any creative process.
+3. Run a test program with the C64 KERNAL, and collect entry points.
+4. Implement the routines in the order that the entry points are discovered.
+5. Where an entry point does not correspond to a public API of the KERNAL, research the function by searching for it in Google. Implement it according to the first matching reference.
+6. Where an entry point means that previously implemented routines have to be moved to make space at a specific address, move only those routines required to do so, to the next available address.
+
+To organise this as we develop, we will assemble the ROM from many separate source files, each with a single routine in it, and with the name of the file matching the routine.  Where code must be placed at a specific address, the file should be called xxxx.routine.s, where xxxx is the address.  We will write a special preprocessor that will take the routines and put them in the correct deterministic order, and make
+sure that no address placement violations occur.  To make this easier to do, we are using the Ophis assembler, as it makes it quite easy to check such things.
+