Standardizing 6502-style SPC700 syntax

There is one "official" syntax for SPC700 opcodes, which Sony allegedly made to hide the fact that there's a 6502 struggling to get out. There have been several attempts to adapt 6502-like mnemonics for the SPC700, such as byuu's bass and blargg's macro pack, which use slightly different syntax. In order to promote sharing of applicable code between NES and Super NES music engines, I'd recommend standardizing 6502-style assembly syntax as byuu suggested. A different syntax for the basic instructions in each assembler makes it harder to move code from one assembler to another or even to read code that someone else posted to a forum or pastebin. I'd like to get as many SNES developer and music hacking communities as possible to join in this standardization effort so that all views can be represented.

My goal is to be able to share as much code as possible between an NES game and the Super NES port of the same game, on the principle of not repeating oneself. Anything that the NES and Super NES versions share would be written in plain 6502 mnemonics, and anything specific to the Super NES could use 65816 or SPC700 instructions. A music engine, for instance, can be divided into music sequence interpretation (which should be shared) and instrument playing (which obviously can't be shared because the 2A03 PSG is not the S-DSP). Sharing code allows a bug fix or feature addition to propagate to the other platform. But anything not shared can use the extra instructions.

Another goal is to ease 6502 and 65816 programmers into SPC700 more gently, even if they're making Super NES-exclusive projects. I prefer to try to make the world a better place by avoiding or correcting misfortunes instead of blindly submitting to them.

First off, what assemblers support SPC700-in-drag? And what are the differences among their syntaxes?

I'm assuming that the common 6502 instructions will have 6502 syntax. Is the goal to make up new three-character 6502-like mnemonics for all non-6502 instructions, so that one can take full advantage of the instruction set without ever using the official syntax? In my own code using the macro pack I've mostly used 6502, with some SPC-700-specific instructions occasionally. For some test code I've stuck to SPC-700 only, for clarity.

Reply to message from Why no SNES homebrew scene?


I went back and found the message and I had never seen it, or it appeared to just be a pitch for your assembler at the time.

So far I've done two things, which don't seem to preclude anything you and tepples are talking about: I made a macro package that accepts standard SPC-700 syntax. I made another optional macro package that accepts the subset of 6502 instructions that have essentially direct equivalents (slight differences, e.g. PUSH PSW doesn't have all the exact same flags on the stack, POP A needs a comparison with zero afterwards to implement PLA). This macro package works with the first so that the standard SPC-700 syntax is still fully-supported. Thus, unless your proposal suggests to make the 6502 instructions behave differently (which would seem to break 6502 code reassembled with this), it is a compatible extension of what I've done.

I made a specific point to not innovate anything in these macro packages. I had to make a concession with direct versus absolute addressing, due to the lack of a macro to differentiate and the conflicting approaches for 6502 and SPC-700 and that they share some mnemonics. My thought was that it should either consistently use direct-page where possible, or require the user to do it manually. Since the former can't be done, I chose the latter, rather than inconsistent behavior.


I have little interest in trying to make custom 6502-like mnemonics for SPC-700 instructions, so you'll have no differing opinions on how it should be done. If there are current incompatibilities with my 6502 macro pack, I'd be fine getting that fixed.

EDIT: additions

I just looked at some of your SPC-700 instructions in 6502 clothing and I'm wondering what the benefit is. For a 6502 programmer using the SPC-700, you'll have to learn new mnemonics either way, so why not learn SPC-700 ones for non-6052 operations?

This highlights that making a 6502-like instruction set is yet a third distinct macro pack project. The first allows SPC-700 on ca65. The second allows common 6502 code shared between a 65xx and SPC-700, or just more familiar coding most of the time. The third that's being discussed here is a new instruction set that's 6502-like for 6502 programmers to learn instead of SPC-700. It's designed to be familiar. It's a new language so besides being familiar to a 6502 programmer, it doesn't give any benefits over using SPC-700 assembly.

Yeah, like I said, some major goal differences separate us on the SPC700.

Yes, when it comes to things like pla acting differently on flags between the processors, I don't attempt to compensate. It has to be a 1:1 mapping for a debugger/tracer to work with it. But then "pop a" really doesn't tell you that the flags are different from 65816's "pla", either. You still have to learn to work with the chip you are on.

The benefit to me is that SPC700 syntax is awful. Really awful. It looks ugly, and it takes me longer to visually parse out "mov x,y" than "txy"

The 65816-like syntax is nearly twice as compact while accomplishing the same thing, and avoids the nasty "src,dest" vs "dest,src" confusion. That's a real problem for me because I hop between lots of assembly languages all the time: x86/amd64, ARM, SPC700, 65816, 6502, GBZ80, HG51B, NEC uPD, GSU1, etc. Have also done minor stuff in MIPS, SPARC and PPC.

But yes, it also requires making 6502-analogues for the SPC700-only instructions. And those instructions definitely deviate strongly from a traditional 6502.

If you really see no value in what I'm trying to do, then I suppose we can at least classify your pack and my table as separate goals. I don't think there's too much overlap. I'm not trying to have 100% portable code between 6502 and SPC700. I'm trying to make reading and writing SPC700 more bearable.

The very title of this thread (Standardizing 6502-style SPC700 syntax) is self-contradictory. You want to standardize something which is inherently non-standard.

So I see two separate goals: covering all instructions with a self-consistent set of mnemonics and allowing code sharing. I'd say that if an SPC700 instruction also exists on 65C02, 65816, or HuC6280 (such as txy), use the mnemonic from that CPU. That might mean exceeding 3 characters for things like smb3.

Bregalad: Standardizing need not involve ISO, IEC, ITU, IEEE, Ecma, or any comparable organization. It can also mean "creating a parallel community practice that will be treated as a standard by the community".

Oh the xkcd of it all.

Which is why we need to get as many of the 14 standards' stakeholders on board as possible.

I'm not going to say "absolutely not" to four-letter opcodes, but I'd really like to avoid it if possible.

Definitely many opcodes where it'd help a lot, had to make dbnz <label> into bne --y=label. There's no three-letter abbreviation for "decrement and branch if not zero" which makes sense, so we have to express the decrement behavior in the operand section.

But I'm a really, really big fan of the visual symmetry that equally sized opcodes adds. It's one of my favorite features of 6502 syntax.

DBNZ and CBNE appear to be literally just macros for a DEC, DEY, or CMP followed by a BNE. A disassembler could just treat it as one opcode that expands to two instructions, which would cause a problem for the assembler. The 6502 assembler would want to emit two instructions, while the SPC700 assembler would emit one.

You keep framing these differences as separation, conflict, but I'm not understanding where the conflict is.


Even with this 1:1 mapping it just means that a PLA will show up on yours as PLA; AND #$FF. It seems that the way to think about this is not that with my sp65c02 macro pack its meaning of PLA is differeny, but that its PLA is a macro that expands to (the real) PLA; AND #$FF (since the point of the macro pack is to share code between this and 6502).


nocash uses traditional OPERATION OPERAND [,OPERAND...] syntax for 6502, because it's beneficial to him, and there's no conflict, because he can use his, you can use yours, I can use mine, tepples can use his, etc.


I don't understand the implicication that we have to have the same values, goals, and do things the same way. So what if I see little value to me in making 65xx-style syntax for all instructions? It doesn't matter what I think regarding its value to you and others that like 65xx-style syntax and are able to code more quickly in it. It's not like I'm going to try to stop you or try to make it difficult for my macros to work with yours.


Yes, exactly as I understand it.


Actually, it's people in a community wanting to make an intentional shared language that attempts to meet everyone's needs, rather than each person doing their own thing and having multiple incompatible variations that hamper code sharing and learning.


Yeah, when I saw TSB in byuu's 65xx-style SPC-700 instruction list, I thought of HuC6280 and how ones like that would be a good source for ideas and "closer" adherence to 65xx.


That's an interesting solution. Why would a 6502 assembler be a problem, since this code isn't meant for 6502 assembly in the first place?

if you're suggesting that the macro pack for shared code between 6502 and SPC-700 support this, I don't think it results in any speedup, just a savings of one byte, so it's pretty underwhelming.

> You keep framing these differences as separation, conflict, but I'm not understanding where the conflict is.

They're different. If one writes code for one, it either won't work or will be behave differently in the other. Eg my pla won't set flags as yours will. Yours will reject my version of dbnz.

But believe me, I'm very, very well acquainted with the idea of having different implementation styles for different purposes. I make my own everything, just about. XML->BML, IPS->BPS, Snes9X->bsnes, pth->libco, Qt->phoenix, SDL->ruby, boost/zlib/libpng->nall, iNES->manifests, etc.

It's just, you know, kind of the reason tepples made this thread was to discuss a unified syntax. I'm always open to the idea of changing my design when people raise good points, so I don't mind this discussion even if nothing comes of it. But I'm also not going to let it stop me from trying out my idea, either.

> Actually, it's people in a community wanting to make an intentional shared language that attempts to meet everyone's needs, rather than each person doing their own thing and having multiple incompatible variations that hamper code sharing and learning.

You see, you just say you don't get it, and then you respond showing that you do get it. That's why tepples made the thread, and I'm happy to at least make an attempt to collaborate and compromise, different goals be damned. If nobody else wants to compromise on their different goals, then that basically just proves the original point I was making in the other thread. It's like herding cats.

Am I all for a universal goal? You bet. Is there a rat's chance in hell of that happening? Nope. And that's fine, it's to be expected.

That said, even if we can't come to an agreement, I am sure if we listen to each other we can at least each improve our own implementations.

> Yeah, when I saw TSB in byuu's 65xx-style SPC-700 instruction list, I thought of HuC6280 and how ones like that would be a good source for ideas and "closer" adherence to 65xx.

Heh, I took TSB from the 65816. Good idea though to look at other 6502 derivatives like HuC for inspiration. I think I'll do just that.

byuu, your messages to me here and in the other thread have been hurtful and I dread them. I'd really appreciate if you could stick to the technical arguments. You keep lamenting about how things can't happen, and these negative predictions are detrimental to me even participating at this point. I'm trying to understand the situation and offer my ideas, but I don't want to get attacked for misunderstanding or asking for clarification.

The topic here is syntax, which I understand to be the characters you enter into an assembler source file.

As I understand it, the goal here is to create a 65xx-style syntax for all SPC-700 instructions.

I'm not clear on how this relates to 6502 code and SPC-700 code using official syntax. From what I can tell, one can port 6502 code to this new ISA. One can also write fresh code with this new ISA as well. Am I on track so far?

From what you've said, this new ISA doesn't aim for compatibility with 65xx, only a similar style of instructions. Thus, it's not 6502 (semantic differences) and it's not official SPC-700 (syntactic differences). Am I following correctly here?

It's easier to discuss semantic differences between similar syntaxes if the disputed semantics are right in front of us. Apart from anything related to decimal mode or interrupts, what are all the semantic differences between SPC instructions and corresponding instructions of the 65C02?

* POP A, POP X, and POP Y don't affect the flags.

* RET doesn't increment the return address by one as on the 65C02, and likewise CALL pushes the address of the opcode of the next instruction.

* The N, V, Z, and C flags are set the same for all supported instructions, including in the same bit positions for PUSH PSW etc. but the other flags differ.

I took a while to survey the topic. To avoid sunk-cost bias from wrecking things, I'm going to ignore my ca65 macro packs and byuu's bass.

We start with the 65xx and SPC-700 architectures. Those have official assembly syntaxes and are supported by multiple assemblers. All good. But there are improvements to the tools that would suit some users better:

Familiar syntax

65xx has syntax that is pleasing to many programmers, and is the main one for programming the SNES. The SPC-700's syntax is of a different style that is unpleasant to some programmers, at the very least different which is added mental load. Since the SPC-700 has the same core architecture as the SNES's 65816 processor, it can be given a new assembly syntax in 65xx style that is easier for 65xx programmers to learn and switch to and from while programming on the SNES's 65816.

The familar syntax approach is a new instruction set architecture (ISA), only similar to 65xx and SPC-700. In general code in the new ISA can't be assembled as 65xx code (more instructions, differing semantics for some common mnemonics), and can't be assembled as standard SPC-700 code (same instructions, but different mnemonics/syntax). One either writes new code for this ISA, or does a one-time port of 65xx/SPC-700 code to it. Regardless, there's no need for syntax/semantic compatibility since it's a new ISA meant to be directly coded for.

The question of syntax and semantics is entirely a style issue, so there is complete flexibility for the new ISA to be whatever is most pleasant to program with.

One possible additional constraint mentioned was having a 1:1 correspondence between the new ISA's mnemonics and SPC-700 instructions. That is, each instruction in the new ISA generates exactly one SPC-700 opcode. This allows a disassembler's output to match the assembler input.

Code sharing

SPC-700 is very similar to the 65xx and the core 65xx instructions are supported virtually identically. This means that there is a direct/nearly-direct correspondence between these instructions, and conversion can be done automatically. It could be a script that converts source code between formats, or macros that do it during assembly.

Naturally the code sharing approach doesn't introduce any new assembly language or syntax, since its purpose it merely to allow code in (a subset of) standard 65xx and SPC-700 syntax to coexist in an SPC-700 project. It should allow both to be used in the same source file, with as few restrictions on the 65xx code as possible, and for code that is allowed, as few differences in semantics as reasonably possible.

To avoid silent bugs when moving working 65xx code over, the supported 65xx mnemonics should have semantics as close to nearly identical as practically possible, and list instructions/cases for which it's not so the user can scan the code for them and be mindful when changing it. For example, the 65xx PLA sets flags based on A, while the near-equivalent POP A on SPC-700 doesn't set flags. Translating PLA into POP A; AND A,#$FF; results in the same flag behavior at minor cost. At the impractical end is the 65xx RTS which pops the 16-bit return address off the stack, increments it by one, then jumps to it. The SPC-700 has RET, which does the same except it doesn't increment it. Translating between the two would be prohibitively expensive and unnecessary in most cases as 65xx code normally uses RTS as a complement to JSR, which behave the same on SPC-700 as an RET after a CALL.

Preferably when sharing SPC-700 code, it should be written in SPC-700 assembly language. This ensures that people using one of the multiple SPC-700 assemblers can use it with minimal change. The code sharing should preferably only be used inside a project, to faciliate sharing.

Merging the two

It may be possible to merge the two improvements, if one designed the new ISA so that it had the same syntax and semantics (where reasonably possible) as the common 65xx instructions, and didn't conflict with standard SPC-700 instructions and addressing modes. This runs the risk of trying to meet too many constraints without compensating benefit, and resulting in a less-useful design.

As far as constraints go, there's not much to relax of the constraints on the code-sharing improvement. Its purpose is to allow coexistence of standard 65xx and SPC-700 code in a project, thus it needs to accept the syntaxes of both, and provide 65xx semantics where reasonably possible. If these were to be violated merely to allow a preferred syntax in the new ISA, then the new ISA might as well not hamper itself with remaining compatible with 65xx/SPC-700 code and get the maximum benefit of being able to use whatever syntax is most pleasant for its users. Put another way, if the new ISA were incompatible with standard 65xx and/or SPC-700 code, such code would have to be ported to work with the new ISA, thus there'd be no point in trying to support 65xx or SPC-700 code and limiting the ISA's design choices.

If one didn't care for standard SPC-700 compatibility, one might be able to make the new ISA allow 65xx code sharing with less effort. The same steps would need to be taken as above for avoid silent bugs. Any new mnemonics should not match any 65xx ones, and any common mnemonics should have semantics as close as practically possible. The 1:1 mnemonic-opcode constraint might conflict with avoiding silent bugs, or require changing an almost-same behaving instruction to have a different mnemonic than the 65xx near-equivalent.

You're one of maybe ten people I truly have very deep respect for on the internet. I absolutely meant no disrespect or rudeness at all, so I apologize if you took it that way.

This is really why I hate the internet, you really can't convey emotion or intent behind words. Personally, I'm participating in this thread with no emotions whatsoever. I'm not angry, upset, or anything of the sort. I'm honestly not even that concerned about this. I've had my SPC700 syntax in for around two years now, I just do my own thing.

I have always been a very direct person. If you were to cook something and asked me what I thought, and I didn't like it, I'd tell you it sucked. Some would see that as rude, I would see it as honest feedback. I certainly could be an encouragement echo chamber to say your food was great, but why even ask me what I thought if you already knew the answer would be positive no matter what?

But like I said, I've always greatly appreciated your insights and help, so if you aren't able to look through my words and see there's no ill intent, I would be willing to filter what I say. The last thing I'd want is to upset you. (Again, there's no sarcasm or hidden meanings or belittling implied there. That's an honest statement.) I'd be open to your advice on how to do that, tact really has never been my strong suit.

Back onto the thread ... yes, I am a very negative/pessimistic person. It stems from 15 years of experience. Most people don't like to collaborate on improvements: they either like to stick with the norm, or innovate on their own. Myself, if I think I can do something better, I'll throw out backward-compatibility and do it the way I think is best. I'm frequently ripped apart all over the internet any time I dare deviate one iota from the established expectations. Far worse than anything in this thread (I've been called insane for sorting by game instead of by filetype, autistic for writing a high-requirement emulator, a Nazi for wanting to rename SMC files to SFC files, etc.) So I have a very thick skin.

I spent two years eliciting feedback for an IPS successor. Eventually I finally release it, and immediately everyone hates it. I tried for months to get other SNES emulators and set maintainers interested in board markups. I eventually just gave up and did it myself, and even went and bought 2000+ games to get the markups myself. I spent a good week or two arguing here about iNES and that went absolutely nowhere. Received zero interest in my idea to make a truly portable micro-language to externally emulate NES mappers. When I try and think of successful format collaborations with others, nothing comes to mind at all. (When we avoid formats/specifications, things go great, eg coprocessor research.) I love it when people work with me, but I'm perfectly fine being entirely self-sufficient, too.

When I look at this thread, my honest impression is that we both had different goals. I don't see a strong reason why we both have to compromise. So if you don't want to, it's not like it's a bad thing, it's just what it is. From your own words:

"I have little interest in trying to make custom 6502-like mnemonics for SPC-700 instructions"
"I just looked at some of your SPC-700 instructions in 6502 clothing and I'm wondering what the benefit is"

If you like the idea, I'd love your participation. If you don't, then I wouldn't want you to dredge through it just for my sake.
But it sure sounds like the latter, and that's why I said that we weren't likely to reach a unified syntax.

Again, I don't even think we necessarily need to. Your idea has a specific utility, as does mine. When I made BML, I could have done the same with XML for the sake of uniformity. But instead I specialized to get a more optimal solution to what I wanted. I had no use for entities, document validation, tags within text, etc. Instead I made something far easier to edit by hand. That mattered a lot when I hand-created 750 game definitions in a row. I see your ca65 macro pack as an optimal solution to ca65 users wanting identical code to run on both the 6502 and SPC700. I see my syntax as an optimal solution for not having to learn two wholly different mnemonics to work on the core SNES system. If we attempt to make a unified syntax, which I am willing to try, we will end up both succeeding less in our original goals.

So again, tepples' goal was one syntax to rule them all. I say it's not doable, and I'm deeply sorry that upsets you, but it's my honest opinion, and I don't know what to do other than lie about it. My goal, though, is to recognize that both of us have amazing ideas and great insights, and that these insights might help me improve your ca65 pack, and yours might help me improve my bass table. So what if we don't reach 1:1 parity? Let's see how close we can get anyway.

I've gotten the impression lately that you weren't all that interested in my input. When I suggested different ideas for your ca65 pack and for the SPC700 test ROMs, you seemed to dismiss them entirely, as you already made what you wanted. So what I took away was that you weren't too interested in listening to feedback and making changes. You had your way of doing things, and that's perfectly okay, nothing wrong with that. I certainly have my own projects where I won't consider any changes. Sometimes what a project needs to be successful is a strong leader / decision-maker, to prevent infinite bikeshedding and get a unified vision out there that isn't a clusterfuck of 80-ways-to-do-the-same-thing like most ISO/ANSI/IEEE specifications.

If you do want to participate ... my most pressing issue that I've love advice on, is how to handle the opcodes that only exist in SPC700.

dbnz, cbne, bbc/bbs[0-7], ora that doesn't apply to the accumulator, and multi-operand opcodes since the 65xx already uses , in addressing. My ideas are in the bass table and in my SNES debugger loki, but I'm absolutely willing to change any of it.

I think the 1:1 parallels eg "mov a,#$00 -> lda #$00" is very easy for us all to agree on, and need not be discussed much.

Thinking more about blargg's version. I think I see the source of confusion.

So, blargg has not in any way created a 6502 syntax for the SPC700. Instead, he's written two programs in one: the first, is a 6502 -> SPC700 opcode translator; the second, is an SPC700 assembler. They are combined into one program, ca65. And as such, we are addressing it like an SPC700 alternate instruction set, because that is what it appears to be. But that's not it at all. It would be fairer to say that it's a source code translator, along the lines of Java -> C translators.

In this context, it doesn't make sense for it to support SPC700-specific opcode mnemonics. Or even SPC700-specific instructions at all, except in the event that using one would better simulate 6502 behavior, if that occurs at all.

Thank you blargg for the comprehensive write-up.


The one big change in this case would be to tables used by dispatchers using the RTS trick. This leaves PLA/PLX/PLY as the significant difference.


Most of the time,* culture leaves open a way to give honest feedback without rudeness. "I see a lot of room for improvement."


Sometimes the answer has to be "the cheese is moving, so move with it."


If only you'd told zzo38, who had been working on a similar idea.


I'm not upset. At least I learned that handling of PLA is the big sticking point.


* Feel free to point out exceptions.

"Does this dress make me look fat?"

...shit...

Hmm, let me try ...

> "Does this dress make me look fat?"

a) You have filled in the dress well.
b) You have expertly taken advantage of the space available in the dress.
c) Good news, you won't need to exchange your dress for a smaller size.
d) The dress does not make you look fat. The fat makes you look fat.

I'd like my macro pack to not unnecessarily be incompatible with something you and tepples (and hopefully others) are working on. I don't want needless technical problems that could be worked out. That's why I want to understand what you and him are planning. Then we can see what the technical landscape is and where each of our goals fall, and what sorts of solutions meet them all more smoothly than others.

Yes, I don't plan on working on a 65xx-style instruction set for the SPC-700. I'd share more of what seem practical problems with it but I don't get the sense that there's room for that, which is fine, because it doesn't really matter either way. I don't want anything I do to get in the way, which is why I'd like to understand at least the scope and goals, so I can see what is eliminatable and what is due to inherent incompatibility of the technical goals.


That may be the case, but I'm still interested in clarifying the goals, solutions, and seeing what actual conflicts they have.


The frustrating thing was the implication that it was due to me being inflexible or some other non-technical point. The way I approach these is to push for clarity of everyone's ideas and goals, to explore them all relentlessly until they're fully understood. Then look at the various issues and costs, and finally come back to our individual goals and see how they arrange things, and use them to further calculate costs and benefits to make choices where there are tradeoffs. If there are problems that force taking a less-ambitious approach, I want to be able to explain them and have them clearly justify leaving them unsolved.


The SPC-700 part is actually separate. You can use just it, and use ca65 as a standard SPC-700 assembler; no 65xx instructions. You can use a second header in addition and get the core 65xx instructions *and* SPC-700 instructions.

I'm trying to find a response to the survey I posted. My main interest in the new ISA is that it not trade off interoperability with everything else for some minor stylistic freedom.

Will the new ISA allow coexistence with standadrd SPC-700 assembly? Disallowing that would be unfortunate because anyone using the new ISA wouldn't be able to use SPC-700 code without rewriting it. It would also tend to polarize demo code and routines into two incompatible groups (whereas keeping SPC-700 compatibility means it is the "portable" language), which seems the opposite effect you want on the community.

Will the new ISA attempt to make 65xx code using the common set of instructions assemble the same and work the same (other than POP and RET differing slightly)?

> Then we can see what the technical landscape is and where each of our goals fall, and what sorts of solutions meet them all more smoothly than others.

So far, one of the big ones is flags. Many platforms have "inc <reg>", yet their flags will act differently between 6502/x86/etc.

With your goal of having the code work on both areas, the and #$ff is a good response to PLA. With my goal of just having nicer mnemonics, I wouldn't be able to insert the additional instruction after it. Our shared understanding is to use PLA instead of some other term. We both like the aesthetic of 65xx here.

> The frustrating thing was the implication that it was due to me being inflexible or some other non-technical point.

That was not in any way what I was trying to imply. Apologies if I made it seem that way.

To me, I think you have your goal, and I have my goal, and they are not 100% compatible. As I said, I'd like to bounce ideas off each other to maybe improve each of our ideas, but I don't expect perfect compatibility between divergent goals.

Unfortunately it seems that instead of talking about the idea at hand, we're going to spend ten pages talking about what we feel the idea is about. We've yet to even begin to cover any of the interesting technical points and we're on post #22 :/

> My main interest in the new ISA is that it not trade off interoperability with everything else for some minor stylistic freedom.

That is exactly what it is. You downplay it a bit by saying minor, but I can see how if it's not an issue to you, you would feel that way.

The goal here is a 1:1 mapping of SPC700 official mnemonic <> 65xx-like mnemonic. If that goal doesn't interest you, or you don't like it, that's fine. I can continue developing it independently. If it does, then I'd like to hear your feedback on what to call the various SPC700-only instructions to fit the 65xx mold.

If you're worried it's going to split up existing code, well, you're right. If it catches on, it will do just that.

I think our styles and ideals just diverge here. You see no reason to modify existing standards for elegance alone, whereas I see no reason not to improve an existing standard where possible. Reasonable people can disagree on whether the changes are improvements. In this case, I think it's a worthwhile improvement.

> Will the new ISA allow coexistence with standadrd SPC-700 assembly?

It's a table-based assembler (and you can even modify the table dynamically), so yes that is entirely possible. I would hope someone wouldn't interleave the two formats in the same exact function, but they could have one function in traditional syntax one in another. That's still not ideal, I suppose.

One of the interesting points of this syntax though is that it's entirely amenable to direct machine-based translation, much like those fancy C code formatters.

If you don't like SPC700 syntax, there is a literal 1:1 transformation to the 65xx-syntax I am proposing. And vice versa. No instructions are added / removed / changed in any way. The resulting binary is identical in either format.

> Will the new ISA attempt to make 65xx code using the common set of instructions assemble the same and work the same (other than POP and RET differing slightly)?

Having trouble with this question. POP/RET are the known differences. If there are more differences like this, they will also remain different. All I am attempting to do is rename each mnemonic to a more 65xx-like name. It should mostly reflect what's going on to a 65xx programmer, but should not be reason to think it's literally a 65xx chip. You will still have to learn the differences between the chips.

I can see someone getting in the habit of using MOS syntax for instructions present in the 6502 family and Sony syntax for other instructions, depending on what ends up happening with the syntax for the non-65C02 instructions.

So for the "code sharing" side of the equation, I'd recommend adding a few macros used by shared code.

• The macro RTSADDR x, y, z, ... would emit .WORD x, y, z, ... in SPC700 mode or .WORD (x)-1, (y)-1, (z)-1, ... in 6502 mode.
• The macro PLAS ("pull A and set flags") would emit PLA AND #$FF in SPC700 mode or PLA in 6502. The name is inspired by ARM's S suffix on ALU operations that affect the flags.

Code written for sharing would use RTSADDR and PLAS, allowing code sharing (blargg's goal) along with 1:1 correspondence of the actual mnemonics after macro expansion (byuu's goal). In the language of the C standard, PLA would mean "flags NZ are implementation-defined" and therefore nonportable, while PLAS would mean "flags NZ are set based on the value pulled from the stack."

Anyway, AND #$FF isn't the first instruction I would have guessed at first for "set NZ flags based on current value of A". Is there a reason why ORA #$00 or EOR #$00 wouldn't work?

That forces me back to four-letter opcodes.

But you know, that's honestly not a bad idea.

My disassembler / tracer would show: pla; and #$ff (zero interest in trying to 'roll-up' opcodes there)

But my assembler could easily take plas for that, and plas could exist in both 65816 and SPC700 mode. It'd just be an alias in the former.

And being forced back to four letters, I could handle cbne and dbnz so much more eloquently.

How about an RTSADJ constant that's 1 on 65xx and 0 on SPC-700? Then the above macro can be built unconditionally by the user, along with any other handling (like manually pushing an address to later return to):
.WORD (x)-RTSADJ, (y)-RTSADJ, (z)-RTSADJ, ...

As for the pop instructions, maybe PFA could signal pull and set flags and stay a three-character mnemonic. You'd also have PFX and PFY of course. And yeah, AND, ORA, and EOR work just as well, and are probably clearer, as AND suggests masking something off (and OR/XOR with zero is a common NOP on RISC). For X and Y you can use an increment/decrement pair (two bytes like the A case).