4 ms·

One of the enablers is zero page is really a register page under 6502. That helps a lot I think. Not to mention his thinking out of the box and tool around th

One of the enablers is zero page is really a register page under 6502. That helps a lot I think. Not to mention his thinking out of the box and tool around the issue, trading space vs speed in some scenario. Conceptually it is closed to dock as it provide an api call for some usage without a full blown vm.

throwaway81523 3y ago
I thought the zero page lived in ordinary ram. It was more efficient to access than the rest of ram, just because the instruction encodings were designed such that you could refer to 0 page addresses directly. To reach arbitrary 16-bit addresses, I believe you had to use the HL registers or similar. This style of design was common on memory starved machines of the era, including the PDP-8 which predated most of the 8-bitters.
- kragen 3y ago
  that is all correct except for the hl registers, which were an 8080 thing, not a 6502 thing
- HarHarVeryFunny 3y ago
  Zero page is just the first "page" (256 bytes) of the address space, which would map to normal RAM. The only thing that is special about zero page is that since the address "page" (high 8 bits of 16bit address) is implied (=0), you only need to use an 8bit (one byte) address to specify any zero page address. The 6502 instruction set takes advantage of this by having additional instructions to load/store values to zero page as well as ones to load/store to generic 16 bit addresses. An instruction accessing zero page memory will be two bytes (op-code + one byte address), while an instruction accessing a generic address will be three bytes (op-code + two-byte address). The zero page access therefore takes less code space, and will run faster (even though the memory access speed is the same) since there are only 2 vs 3 instruction bytes to fetch. Given the 10x speed overhead of the SWEET16 interpreter, it'd really not make much difference if it chose to use non-zero page locations for its 16 registers. It makes more difference in hand written code where you are optimizing for every byte of code space and cycle of instruction timing.
  - ngcc_hk 3y ago
    Should have said “in practice may used like a register page” as I saw a lot of work are based on this practice. For the “not much difference” would it be intended because it is using space to trade of low speed. Given this page use less space and less speed, would it still be important.
    - HarHarVeryFunny 3y ago
      For SWEET16 the choice to place it's registers in zero page, or not, would only affect speed of access, not code size. The SWEET16 code would still be using one byte register instructions in either case. As far as speed, given that the interpreter overhead of SWEET16 means it's about 10x slower than 6502 code, adding an extra clock cycle for non-ZP access would at worst make that 11x vs 10x. Would that really make a difference to the cases where it was useful? The trade off is that NOT using ZP for SWEET16 would give those 32 bytes of ZP (16 registered x 2 bytes) back to the developer. However, It seems that SWEET16 was not much used, and I doubt that any change like this - where to place it's registers - would have made any difference to that. It's maybe interesting to consider would a different interpreted code (with different feature set from SWEET16) have been any more widely used? Yes, you can consider ZP as a page of registers, but it's not like there was any choice - seeing as the 6502 basically had no registers (just A, X, Y) you had to have your program variables in memory, and ZP was faster/smaller that the alternative!
      - ngcc_hk 3y ago
        Thanks for the clarification.
renewedrebecca 3y ago
It's really not a register page though. There are all sorts of operations that you can do on the real registers that you can't do with a zero page address, at least not directly. It's just a shortcut addressing mode.

throwaway81523 3y ago

I thought the zero page lived in ordinary ram. It was more efficient to access than the rest of ram, just because the instruction encodings were designed such that you could refer to 0 page addresses directly. To reach arbitrary 16-bit addresses, I believe you had to use the HL registers or similar. This style of design was common on memory starved machines of the era, including the PDP-8 which predated most of the 8-bitters.

kragen 3y ago
that is all correct except for the hl registers, which were an 8080 thing, not a 6502 thing
HarHarVeryFunny 3y ago
Zero page is just the first "page" (256 bytes) of the address space, which would map to normal RAM. The only thing that is special about zero page is that since the address "page" (high 8 bits of 16bit address) is implied (=0), you only need to use an 8bit (one byte) address to specify any zero page address. The 6502 instruction set takes advantage of this by having additional instructions to load/store values to zero page as well as ones to load/store to generic 16 bit addresses. An instruction accessing zero page memory will be two bytes (op-code + one byte address), while an instruction accessing a generic address will be three bytes (op-code + two-byte address). The zero page access therefore takes less code space, and will run faster (even though the memory access speed is the same) since there are only 2 vs 3 instruction bytes to fetch. Given the 10x speed overhead of the SWEET16 interpreter, it'd really not make much difference if it chose to use non-zero page locations for its 16 registers. It makes more difference in hand written code where you are optimizing for every byte of code space and cycle of instruction timing.
- ngcc_hk 3y ago
  Should have said “in practice may used like a register page” as I saw a lot of work are based on this practice. For the “not much difference” would it be intended because it is using space to trade of low speed. Given this page use less space and less speed, would it still be important.
  - HarHarVeryFunny 3y ago
    For SWEET16 the choice to place it's registers in zero page, or not, would only affect speed of access, not code size. The SWEET16 code would still be using one byte register instructions in either case. As far as speed, given that the interpreter overhead of SWEET16 means it's about 10x slower than 6502 code, adding an extra clock cycle for non-ZP access would at worst make that 11x vs 10x. Would that really make a difference to the cases where it was useful? The trade off is that NOT using ZP for SWEET16 would give those 32 bytes of ZP (16 registered x 2 bytes) back to the developer. However, It seems that SWEET16 was not much used, and I doubt that any change like this - where to place it's registers - would have made any difference to that. It's maybe interesting to consider would a different interpreted code (with different feature set from SWEET16) have been any more widely used? Yes, you can consider ZP as a page of registers, but it's not like there was any choice - seeing as the 6502 basically had no registers (just A, X, Y) you had to have your program variables in memory, and ZP was faster/smaller that the alternative!
    - ngcc_hk 3y ago
      Thanks for the clarification.

renewedrebecca 3y ago

It's really not a register page though. There are all sorts of operations that you can do on the real registers that you can't do with a zero page address, at least not directly. It's just a shortcut addressing mode.