DSP Unmute

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: DSP Unmute

Post by Near »

I seem to be one of the few here that prefers the "native" mnemonics
I'm well aware that changing the mnemonics for a CPU is highly controversial.

But I really felt this was a special exception: the SPC700 is absolutely, unequivocally, a shameless 6502 clone. Just like the HuC6280, it adds a few new instructions on top of it. Unlike the HuC, it also reorders the opcode bytes -- but nobody is writing code in db statements, so who cares?

The native mnemonics were almost certainly a thinly veiled attempt to avoid licensing fees for the use of the 6502 instruction set. And in this case, they are truly gross mnemonics that force you to think about parameter ordering (src,dest vs dest,src) and leave tons of holes that are not obvious until you get assembler errors for missing opcodes.

I've emulated ~15 processors now in higan, and the only other time I've made up mnemonics were when opcodes were not documented and I had zero choice (uPD96050 and Cx4). So this was not a decision I made lightly.

That said, I understand and respect if you do not care for this. Sorry to inflict it upon you ... perhaps someone could write a translator so people can work with whichever set they prefer :)
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: DSP Unmute

Post by 93143 »

byuu wrote:Unlike the HuC, it also reorders the opcode bytes -- but nobody is writing code in db statements, so who cares?
That's good to know. I've occasionally coded in db statements to get around bugs in the ancient version of WLA DX I've been using, and the only piece of real SPC700 code I've ever written is self-modifying... it hasn't been assembled or tested, but I'll get around to it someday...
Post Reply