update README

This commit is contained in:
Paul Gardner-Stephen committed 2019-05-07 22:29:22 +09:30
1 parent 621d470fe3
commit 8a6fd814d7
1 file changed
+5 -5
+5 -5
View File
@@ -83,11 +83,11 @@ to generate this call graph.
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.
7. Where understanding of the inner workings of a routine are required to replicate it, secondary sources, such as the "Mapping the C128" or "C64 Programmer's Reference Guide" should be used. When those do not provide the answer, internet searches based on the name of the routine should be done, and failing that, based on the routine's address if it has no well known name or insufficient material is turned up. Reference to actual disassemblies of the ROMs is not to be made, to ensure that we have strong defences against any claim of copyright infringement.
4. Implement publicly documented routines in any order, using secondary sources, such as books about the C64, but without refering to the 64 ROM contents themselves.
5. Run test programs using the C64 KERNAL, and collect entry points into the ROMs.
6. 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 those references.
7. 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.
8. Where understanding of the inner workings of a routine are required to replicate it, secondary sources, such as the "Mapping the C64" or "C64 Programmer's Reference Guide" should be used. When those do not provide the answer, internet searches based on the name of the routine should be done, and failing that, based on the routine's address if it has no well known name or insufficient material is turned up. Reference to actual disassemblies of the ROMs is not to be made, to ensure that we have strong defences against any claim of copyright infringement.
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.