SPC700 address modes

[spiller]

(BTW, is this an okay forum for general emulation development questions not directly related to ZSNES?)

Hi, I'm trying to emulate the SPC700, and the only two docs I've found on it are both a bit vague on how the address modes work. I can't find any official datasheets. I'm not expert at this stuff and it's tough to figure out exactly what to load from where.

By "address modes", I mean every type of comma-separated operand that could possibly follow a mnemonic in assembler source, because I need it divided up that finely for the trace debugger to know how to disassemble/format things for display and I need the debugger to make sure I implemented the rest of the processor right. :-/

Can those with more knowledge and experience on this advise me on whether I've got this right? I've made a list of all the address modes and how (I think) they're supposed to work. The symbols/formatting, too, I'm very unsure of. I've never done SPC700 assembly, so I'm sorta coming at this backwards.

Code: Select all

== Implied ==
Address: N/A
Value: Uses flags or addresses implied by the mnemonic.

== A ==
Address: none
Value: Accumulator

== X ==
Address: none
Value: Index X

== Y ==
Address: none
Value: Index Y

== YA ==
Address: none
Value: Word, using Y as the high byte and A as the low byte.

== SP ==
Address: none
Value: The stack pointer

== Carry ==
Symbol: C
Address: none
Value: The carry flag

== Immediate ==
Symbol: #$xx
Address: none
Value: Byte following the opcode

== Absolute ==
Symbol: !$xxxx
Address: 16-bit following the opcode
Value: At that address

== Absolute X ==
Symbol: !$xxxx+X
Address: 16-bit address following the opcode, + X
Wraps: Within 64 kB
Value: At that address

== Absolute Y ==
Like above.

== Absolute (Not) Bit ==
Symbol: !$xxx.d
Address: 16 bit-value follows the opcode. Low 13-bits are an absolute byte address. High 3-bits are a bit address within that byte.
Value: That bit.

== Direct ==
Symbol: $xx
Address: 0x0100 or 0x0000 plus the byte that follows the opcode.
Wraps: Within the direct page??

== Direct X ==
Symbol: $xx+X
Address: 0x0100 or 0x0000 plus the byte that follows the opcode plus X
Wraps: Within the direct page??

== Direct Y ==
Like above.

== Direct Indexed Indirect ==
Symbol: ($xx+X)
Address: 16-bit absolute address loaded from the Direct X location.

== Direct Indirect Indexed ==
Symbol: ($xx)+Y
Address: 16-bit absolute address loaded from the Direct location, then plus Y.
Wraps: Within 64 kB

== Indirect X ==
Symbol: (X)
Address: 0x0000 + X (so, does this mean it has range within page zero only???)

== Indirect Y ==
Like above.

== Direct Bit ==
Symbol: $xx.d
Address: Byte follows the opcode, added to 0x0100 or 0x0000. Bit is always encoded as part of the opcode (?)

== Relative ==
Symbol: label, probably, or $xx
Address: Byte follows the opcode, treated as signed, added to the instruction register

== Table Call ==
Symbol: decimal number
Address: 0xFFDE - (number * 2) loaded into instruction register

== PCall (what's this?) ==
Symbol: $xx (just a guess)
Address: Byte follows the opcode. Add to 0xFF00, then load into the instruction register.

Another question or two... does JMP !a jump to the absolute address (I think) or to the word at the absolute address? And JMP [!a + X] ... where in the world does that go?

Thank you for all help you can give.

[blargg]

Anomie's SPC700 doc should cover everything. He also has more docs.

[I.S.T.]

Linking directly to the file doesn't work with RHDN's set up, blargg.

Here's the entry for it: http://www.romhacking.net/docs/197/

Edit: I linked to the wrong document like a dombass. >.< Fixed.

[spiller]

Thanks. I sort of get it now I guess. So "(X)" and "(Y)" addresses, are they relative to 0x0000 or the direct page or what? They don't seem too useful like that.

Then again, that wouldn't surprise me: this is all around such an annoying chip. And that wrapping behavior is horrible... WHY do these chips have to wrap things within tinny 256-byte boxes? It just makes everything more complicated. Thank goodness for flat mode.

[blargg]

Things wrap on 256-byte boundaries because it was cheaper to use an 8-bit adder rather than a 16-bit one. But where does this wrapping occur except for direct page? The point of direct page is speed and compact encoding, so you want a small 256-byte page. If you don't want wrapping, you can use the !a+X addressing mode, which adds a 16-bit immediate value and X in a flat address space.

The (X) and (Y) addressing look to be documented wrong there, as these really address X+dp and Y+dp, where dp is either 0 or $100.

Linking directly to the file doesn't work with RHDN's set up, blargg.

They could mention that in their FAQ, which I checked before linking directly. Kind of stupid to impose an intermediate, this being the web and all.

[I.S.T.]

It's done that way for a specific reason, but I can't recall right now.

[Deathlike2]

It's to prevent outside bandwidth leeching IIRC.

[Nightcrawler]

It's to prevent outside bandwidth leeching IIRC.

That and for people like blargg who keep spreading RHDN links to files that aren't permanent and link properly instead. File names can and will change. Links such as the one I.S.T. gave are permanent, and won't change regardless of the file name, entry updates, server, directory structure etc..

I wouldn't call protecting our bandwidth and disallowing links to non permanent links on our site 'stupid'. I would call it 'smart' being that as long as RHDN exists, the link I.S.T. provided will remain working and the one blargg wanted to provide is not guaranteed to last any length of time. Permanent links are a better service to everyone.

[Squall_Leonhart]

excuses... excuses..

i mean.... err

Tea anyone?

[spiller]

The (X) and (Y) addressing look to be documented wrong there, as these really address X+dp and Y+dp, where dp is either 0 or $100.

Oh wow thanks! That probably would have caused me great confusion later on.

I actually finally got my Java implementations of the CPU and APU to communicate coherently. It's not too efficient yet, but it's basically running. I'm ecstatic.