Nice work. I love these sorts of compression techniques and it's one of the reasons that I like the VIC-20 so much because it's small memory encourages them so much.

I think i know why now. Maybe? It’s because the code beforehand is using the bytes from the memory in those spaces. Hence why each line of music code increases the address by 5. Am I half-educatedly guessing correctly?

@@throwitatthewall6289 Yes, you're right. When I enter the music using the 'M' command it enters 5 bytes per line and hence increases the memory address by 5 each time. When entering assembly language you will find that different instructions take up a varying number of bytes and hence the next address increment will vary based on this.

Different things work for different people. I always found that ensuring I had a copy of the code on paper worked for me. I kept it in sync with my working code and I don't see any reason that there would be more undetected bugs using this approach (assuming I kept the paper copy in sync accurately) than just inputting straight into the monitor as I would test each routine thoroughly before moving on. I certainly found it much easier to plan a routine and locate bugs though if I had a copy on paper using symbolic references. One odd feature of VICMON is that you have to use the '$' in assembly instructions even though all values are in hex, it is something that bugs me a little. I could have written the code differently but as I mentioned it was never supposed to be an example of a good music player as it was only there to demonstrate the monitor. On the last point I guess I just always did it that way and got accustomed to it - it probably helped having an accurate paper copy marked up with the forward addresses and other addresses of interest. I'll try this approach in future as see how I find it. Thanks :-)