It is currently Sun Nov 18, 2018 8:20 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Tue Jan 30, 2018 4:31 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 820
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?


Top
 Profile  
 
PostPosted: Tue Jan 30, 2018 6:56 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2334
Location: DIGDUG
The 65816 doesn't care about the alignment of data.

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

VRAM is word aligned.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Tue Jan 30, 2018 7:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20783
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Tue Jan 30, 2018 10:19 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 820
Thanks folks.


Top
 Profile  
 
PostPosted: Tue Jan 30, 2018 11:34 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20783
Location: NE Indiana, USA (NTSC)
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).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: 93143, Gilbert, nocash and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group