It was common practice for most advanced C64 software to avoid most kernal routines, replacing disk i/o with custom fast loaders, screen output with custom ren

It was common practice for most advanced C64 software to avoid most kernal routines, replacing disk i/o with custom fast loaders, screen output with custom rendering, and system interrupts with their own. This was almost always true for games, and sometimes true for applications, for example, the C64 didn't have a UART, and high modem baudrates sometimes lead to bit errors, so some fast terminal programs wrote their own. This article is amazing though, because it revealed stuff I never knew, even after years of C64 coding. For example, I didn't know about the VECTOR calls to save/restore the vector table. I almost always started out my code doing this myself, e.g. SEI/LDA $0314/STA SAVED_IRQ/.../CLI. I remember writing a BBS in assembly language for the C64 and using $FFD2, but I had to hook the kernel to implement multiple window support, so that when the SYSOP was doing stuff, he had an overlay window and output could be directed at different screens. The design of the kernal gave you just enough flexibility to do what was needed. 20 years later, and I still feel like I had more joy developing on the C64 than any modern system. The tools were primitive, the kernal was primitive, the constraints were great, but everything was much more predictable. You knew exactly how long something took, you knew what resources you had to work with, and it was possible for a single person to completely understand the whole system down to even the hardware layer. And man oh man, the Action Replay cartridge. Immediate feedback from changes, and global freezing of a system and inspection of all system state including WRITE ONLY registers.