Quote:
Writing a program to modify other programs so that they write to a SID in a different location would be the easy part about doing that.
+1. The assembly-language code should have no addresses in it. You refer to registers by name, for example, the 6522 VIA has 16 register addresses, and you call them by PB (port B), PA (port A), DDRB (data direction register for port B) DDRA, SR (shift register), T1CL (timer 1 counter low byte), etc.. Before the code starts, you'll have equates (usually using the EQU assembler directive) telling what the address is of each named register. Then when you run the assembler on your source code, the names will get assigned the right number for the machine-language output. For example, if the VIA's PB is at address $6000, then every time the assembler sees "PB," it will replace it with $6000. If you change the address decoding so it gets moved to $8000, you just change the one line that says
Code:
PB: EQU $6000
to
Code:
PB: EQU $8000
and now the countless references to PB get changed in the machine-language output the next time you run the assembler. You don't have to change them all manually. Again, your assembly-language source code should have very few numbers in it, and maybe no actual addresses at all except in the EQUate lines.
A working monitor program will save you time getting going, but is not necessary. I got started without such a thing. This was 1985, when most households had no computer yet. Mine was no exception. I wrote, by hand, what was more or less what I later would find out was essentially a monitor program, assembled it by hand, and made a manually operated EPROM programmer to put my creation in EPROM. Yes, it was a very slow and error-prone process. A friend had made himself an EPROM programmer he could use with his Hewlett-Packard hand-held computer, and offered to help, so I took my hand-assembled machine-language program, maybe 600 or 800 bytes' worth, to his house, and dictated while he punched it in, then he read it back and edited where there was an error, then he programmed a ROM for me. It all worked on first try, but was not really useful. Learning what
would be useful was a process.
I had no assembler to start. Today, it's easy to get one. You'll want to get a good one you can grow with (meaning it ought to have macro capability) and learn it. My
links page has a section of assemblers at
http://wilsonminesco.com/links.html#assem . Most of them are free. I have never used a simulator for 6502, and never really missed it. It seemed like the best place for one would be for understanding
the I/O ICs, not so much
the processor. I tried Microchip's MPSIM when I was first learning the PIC16 microcontrollers, and it was so cumbersome to use that I basically threw it out and went without. I've never been sorry.
Some of the relevant chapters of the
6502 primer are:
Do go through the
entire 6502 primer though. It is arranged logically, for new 6502 computer builders.