The 6502 (the processor in many of the computers mentioned) had a special addressing mode for the 'zero page' (see Wikipedia article by the same name). The zero page was faster to access and use. A three cycle LDA $0000 could instead be written as a two cycle LDA $00 accessing the same location in memory. Thus, the zero page was a location where significant amounts of convention was stored. One could possibly work with an assembler that had labels and go through and label each of those 256 memory locations, but it was safer to work with them as hard coded values to make sure you were using the LDA $00 form of the instruction which translated to A5 00 rather than AD 00 00.

The zero page map for the Apple ][+ can be seen at Jon Relay's Apple II Info Archives - Zero Page Addresses. If you wanted to get the horizontal location of the cursor, this was stored at $24. Thus, hard coded addresses were certainly used for accessing locations of things on the zero page.

Furthermore, page 1 on the 6502 was the stack. $0100 - $01FF was the stack - no way around that. The instructions TXS, TSX, PHA, PLA, PHP, and PLP were working on the stack. Along with JSR for a subroutine which would push the return address on to the stack.

Hard coded locations in rom were especially useful if there was a card necessary. The code on the card din't know what slot it was loaded into (each of the slots had a different memory range), just that it was invoked. So jumping to a known RTS memory instruction in ROM would push the return address onto the stack, and then pop it and return. Then an examination of the stack pointer register and accessing one byte (little endian) just past the top of the stack would tell you the high byte of the memory you came from - and that would tell you what slot your code ran in.

Memory management on the Apple ][+ within Applesoft, was largely handled by the zero page location $6F which had the top of free memory and the ROM routine at $E452 (GETSPACE) which would do essentially a malloc of the accumulator bytes and store the location of that memory in the X and Y registers. There was also a garbage collection routine at $E484 and a memory reorganization routine at $E5E2. And while there were symbolic names for these routines, and a sufficiently advanced assembler could use them (not the one at $F666), they were well known and unchanging addresses.

While a large download, the pdf Inside the Apple //e has a significant amount of information about the structure of the processor and programs that ran.

The 6502 (the processor in many of the computers mentioned) had a special addressing mode for the 'zero page' (see Wikipedia article by the same name). The zero page was faster to access and use. A three cycle LDA $0000 could instead be written as a two cycle LDA $00 accessing the same location in memory. Thus, the zero page was a location where significant amounts of convention was stored. One could possibly work with an assembler that had labels and go through and label each of those 256 memory locations, but it was safer to work with them as hard coded values to make sure you were using the LDA $00 form of the instruction which translated to A5 00 rather than AD 00 00.

The zero page map for the Apple ][+ can be seen at Jon Relay's Apple II Info Archives - Zero Page Addresses. If you wanted to get the horizontal location of the cursor, this was stored at $24. Thus, hard coded addresses were certainly used for accessing locations of things on the zero page.

Furthermore, page 1 on the 6502 was the stack. $0100 - $01FF was the stack - no way around that. The instructions TXS, TSX, PHA, PLA, PHP, and PLP were working on the stack. Along with JSR for a subroutine which would push the return address on to the stack.

Hard coded locations in ROM were especially useful if there was a card necessary. The code on the card didn't know what slot it was loaded into (each of the slots had a different memory range), just that it was invoked. So jumping to a known RTS memory instruction in ROM would push the return address onto the stack, and then pop it and return. Then an examination of the stack pointer register and accessing one byte (little endian) just past the top of the stack would tell you the high byte of the memory you came from - and that would tell you what slot your code ran in.

Memory management on the Apple ][+ within Applesoft, was largely handled by the zero page location $6F which had the top of free memory and the ROM routine at $E452 (GETSPACE) which would do essentially a malloc of the accumulator bytes and store the location of that memory in the X and Y registers. There was also a garbage collection routine at $E484 and a memory reorganization routine at $E5E2. And while there were symbolic names for these routines, and a sufficiently advanced assembler could use them (not the one at $F666), they were well known and unchanging addresses.

While a large download, the pdf Inside the Apple //e has a significant amount of information about the structure of the processor and programs that ran.