Oziphantom wrote:Personally I think getting SEI and CLI backwards was their biggest misstep on the 6502. Also Non-Maskable ..
sigh...
Think of it this way and it'll click.
I bit is the minimum level of IRQs that get through.
NMI and RESET are level 1, and IRQ is level 0.
SEI sets the minimum level to 1, and NMI and RESET have level at least 1.
CLI sets the minimum level to 0, and IRQ, NMI, and RESET have level at least 0.
tokumaru wrote:What do you mean backwards? Do you think the mnemonics would better match their function if they were switched?
I think Oziphantom is referring to the fact that it's an IRQ
inhibit bit in the first place. On some other architectures, the sense of the I bit are such that 1 means allow IRQ and 0 means suppress IRQ, such as 8086 and the otherwise very 65C02-like SPC700. Blargg's SPC700 macro pack for ca65 switches the mnemonics back around to the 6502 way, but the underlying 8086 way is still visible if you PHA PLP or PHP PLA.
tokumaru wrote:Even in the NMI handler, where I need to backup all 3 registers, I use 3 ZP locations I have reserved exclusively for this purpose, instead of using the stack.
And then you
formally prove that NMI-in-NMI can never happen, right?
tokumaru wrote:LDA (ZP, X) can be useful for accessing collections of streams, such as the different channels of a song.
As seen in, for example, the Pently music engine. It stores pointers to note attack data, sound effect data, and note pattern data for each of the four APU channels, plus one more pointer to note pattern data for the attack track. But it might not appear so useful if your only 6502 experience is on 6502-based home computers such as Apple IIe and Commodore 64, where BASIC uses up most of zero page.
tokumaru wrote:Specially on the Atari 2600, which doesn't have any interrupts, so S can safely be used to load data faster in display kernels.
Or in my
Popslide VRAM update kernel for NES, because there's enough space in page $01 to leave room for the interrupt handler before the update data.
za909 wrote:As far as instruction sets go, sometimes I look at the Z80 set with quite some envy.
I sure don't, particularly when it comes to
random access to the properties of an entity. IX/IY stuff is slow on Z80 and nonexistent on
LR35902, which lacks a couple of the Z80 prefixes. On LR35902, or on Z80 without (slow) IX/IY stuff, you need to make successively accessed properties either adjacent (so you can INC L to get to the next and/or use the (HL+) and (HL-) modes) or one bit apart in address (so you can SET/RES bits in L).
Oziphantom wrote:If X is your entity number, and Y is the field you want in the entity then ZP can hold an entity pointer table of which you can easily index into.
The typical way to do this on 6502 is X is your entity number, and a separate array of properties for each entity. This is the "structure of arrays" approach:
Code: Select all
.bss
actor_xhi: .res NUM_ACTORS
actor_x: .res NUM_ACTORS
actor_xlo: .res NUM_ACTORS
actor_dx: .res NUM_ACTORS
actor_dxlo: .res NUM_ACTORS
actor_y: .res NUM_ACTORS
actor_ylo: .res NUM_ACTORS
actor_dy: .res NUM_ACTORS
actor_dylo: .res NUM_ACTORS
actor_class: .res NUM_ACTORS ; index into move vtable and sprite sheet pointers
actor_frame: .res NUM_ACTORS
actor_frame_sub: .res NUM_ACTORS
actor_health: .res NUM_ACTORS
actor_hurt_ht: .res NUM_ACTORS