65c02-specific instructions with different opcodes

[lordsteve]

Sometimes I look at the 65c02 opcode map and don't always like how the designers allocated unused opcodes from the 6502 map to support the new 65c02 instructions.

If one were to make a 65c02-ish soft core which included the same 65c02-specific instructions assigned different locations in the opcode matrix, what would break? It seems to me that most of the software libraries I see for 6502 and friends are distributed as source code. (For example, EhBASIC and the source code repository on this webpage.) So, a simple reassemble (with a compatible assembler, there's the rub) would solve the problem.

Are there any must-have libraries or programs which come in binary only?
Is this a horribly horrible idea?

[BigEd]

It could be done, but it does seem like it only makes for more work! Making up an assembler - and disassembler perhaps - is the first stumbling block. At present, there must be half a different assemblers in common use, each with a slightly different syntax. So, source compatibility is something of an approximate idea. It's handy that one can pick up a source, and use the author's preferred aassembler.

As for running binaries as-is, that would happen very commonly with games. Moderately commonly with monitors, although as you say source might be available. I will often use a BBC Basic ROM on any given emulator, or at least try to. Or maybe load an EhBasic binary. Although source is available, binary is immediately usable.

[GARTHWILSON]

I don't know of anyone using Jeff's tricks for single-cycle I/O yet, but they do rely on the 65c02's single-cycle NOPs in the _3 and _B columns. See http://wilsonminesco.com/6502primer/potpourri.html#Jeff

[Arlet]

I would also look at exactly how many resources you can save with this trick. It could be smaller than you think.

[BigDumbDinosaur]

I suspect all of this was carefully considered 35-odd years ago when the 65C02 was on the drawing board. You may be tilting at windmills.