Page 1 of 1

65816 with misaligned accesses

Posted: Tue Jan 30, 2018 4:31 am
by calima
How did the 816 behave with misaligned 16-bit accesses?

I can't find a single doc/authoritative source in google, nor in the 816 book. Only google hit for any variation was about SNES game hacks, saying they only work in emulators due to misaligned accesses crashing on hw. But if that's true, why is there no warning in any official source, and zero google hits?

Re: 65816 with misaligned accesses

Posted: Tue Jan 30, 2018 6:56 am
by dougeff
The 65816 doesn't care about the alignment of data.

The SNES hardware registers might. Or some expansion chip, maybe?

VRAM is word aligned.

Re: 65816 with misaligned accesses

Posted: Tue Jan 30, 2018 7:41 am
by tepples
The 65816 has no penalty for crossing a 2-byte boundary within a 16-bit access. It's not like the x86, which has to break it up into narrower, slower reads, because the 65816 is already using a narrow (8-bit) data bus. Nor is it like the 68000, which raises an exception and expects software to emulate the unaligned access. A coprocessor that shares a 16-bit memory between itself and the S-CPU, such as the SA1, may slow down its own processing if it has to read the memory on the 65816's behalf for both the low and high bytes rather than reading it once for the low byte, caching it, and returning the cached value for the high byte.

But the tables on this page show a 1-cycle penalty for direct page accesses when D is not 256-byte aligned (+w) and a 1-cycle penalty for indexed accesses that don't use a 24-bit address and either are writes, have x=0 (16-bit X or Y), or cross a 256-byte boundary (-x+x*p). Taken branches crossing a 256-byte boundary in emulation mode also incur a 1-cycle penalty (+t*e*p). And the program counter always wraps within a 65536-byte page.

Re: 65816 with misaligned accesses

Posted: Tue Jan 30, 2018 10:19 am
by calima
Thanks folks.

Re: 65816 with misaligned accesses

Posted: Tue Jan 30, 2018 11:34 am
by tepples
In my opinion, the bigger takeaway here is that if you're indexing while writing, RMWing, or using 16-bit XY, there is no penalty for using a long base address: al,X over aaaa,X or [dd],Y over (dd),Y. Hence on the Super NES, there isn't a time penalty for keeping large arrays in a different bank from where D is pointed, such as RAM arrays in $7E2000-$7FFFFF or ROM arrays in HiROM areas ($C00000-$FFFFFF).