Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
The SPC700's instruction set is derived from the 6502's, but moves the instructions around and adds a few. But is it fully backwards compatible?
Assuming that the program fully separates data and code, such that opcodes are never used as data or operands, can a direct binary to binary transliteration be performed that leaves the SPC700 program operating identically to the 6502 version without changing any of the addresses of instructions?
The SPC700's instruction set is derived from the 6502's, but moves the instructions around and adds a few. But is it fully backwards compatible?
No.
At least not fully. The instruction set is mostly like a 65C02, but a few instructions (like BIT) are missing. Also, not all inner workings are the same (*1).
Assuming that the program fully separates data and code, such that opcodes are never used as data or operands, can a direct binary to binary transliteration be performed that leaves the SPC700 program operating identically to the 6502 version without changing any of the addresses of instructions?
With some luck. For example if there's none of the missing instructions used (*2). And no decimal arithmetics - as the SPC700 doesn't offer that (*3). Similar direct manipulations of flags may be problemetic, as structure and meanings differs (*4).
It might be a bit better when translating source code, but not much.
*1 - No decimal mode but Half Carry handling; moveable ZP, and more
*2 - Which could be detected by the translator
*3 - Harder to detect, but CLD/SED could throw a warning
*4 - Here it gets hard to manage, since a warning for every PLP would just flood the conversion listing.
One can think of the SPC700 as a sort of hybrid 8-bit processor that tries to be a 6502, 65816 (16-bit) and Z80/80x86 (decrement-and-loop type instructions). As such it does not fit nicely to any of the individual processor architectures. It uses Z80 (and 80x86) style half-carry/DAA/DAS BCD semantics rather than a decimal mode (making it differ from 6502/65816) and does not have dedicated 16-bit registers (making it not a Z-80 either!).
It will be much better to hand convert 6502/65816 code into a SPC-700 assembly. Automagic conversion is going to rely on too much magic to have reliable conversion of arbitrary 6502 code to SPC-700. Just the decimal mode alone can be an issue if the 6502 code does not statically use CLD/SED around decimal mode logic but conditionally sets it or loads it from a computed-value flag pull (for example computing a value with logic that includes I/O reads into A that results in setting D-bit, PHA, PLP).
You will find a lot of code that is cumbersome on 6502/65816 variants (COUGH bit manipulation COUGH) is a lot easier in SPC-700 assembly. Need bit fields? No problem! The SPC-700 can set (SETB), clear (CLRB) and branch (BBC/BBS) on bits arbitrarily and even perform logic within the first 8K of RAM as a large individually addressed bit-field (AND1, OR1, EOR1, etc.)! The Z-80 doesn't even have that one. There are decrement-and-branch instructions too with likenings to Z80 (and 80x86)'s famous DJNZ and friends. You even have cool extras like a multiply and divide operation! There are also some 16-bit operations.
With all these extra architectural features it is simply sub-optimal to even attempt a 1-to-1 style conversion since the SPC-700 is going to nicely solve a lot of problems in far fewer instructions than the much larger 6502/65816/Z80 implementations, which will incur further overhead in an automated conversion. Oh and did I mention the zero (direct) page can also use page one on the SPC-700 (by setting the P bit the direct page instructions will access page 1 meaning you can get a small amount of additional direct page from the bottom of the stack page where the stack never reaches and use the direct page addressing modes within a subroutine to easily handle stacked parameters).
Long story short: the architectural differences are sufficient that any attempt at automated conversions will generate grossly inefficient SPC-700 assemblies. A good overview of SPC-700 capabilities is here: https://wiki.superfamicom.org/spc700-reference
