Add support for Z280

[fbelavenuto]

Is your feature request related to a problem?

No.

Describe the suggested solution:

Add support for new opcodes and addressing modes for the Z280 chip.

[ped7g]

quick checking the feasibility, based on docs here: https://github.com/Konamiman/Z280TechnicalManual

• chapter 5.5. seems incomplete, but together with appendix C and D it's probably enough to have all encodings

new syntax required:

• ld a,<label>/ld a,<$ + 6> for PC relative addressing -> check if this syntax could work, all operators using < are binary, so unary < seems not ambiguous. Also it's more like enclosing parentheses case than operator, also angle-delimiters are already used in INCLUDE filename parsing, so not completely alien to sjasmplus (I guess I would skip the ld a,(pc + 2) variant as the +2 here is meant as real machine code while +6 in <$+6> is meant to be recalculated by assembler from starting address of current instruction.
• ld a,(HL+$1234) 16bit displacement for HL/IX/IY => could hopefully work same way how (ix+d) works now and not clash with anything old
• ld a,(SP+2) -> same as 16b displacements for HL/IX/IY (well, so it's the above with HL/IX/IY/SP support) =>LGTM
• ld a,(HL+IX) - 16b displacement of HL/IX/IY by HL/IX/IY register => LGTM
• new instructions => covered by old syntax in all cases as far as I see

TODO research:

• [ ] MMU support, check if current virtual device memory model would work also for Z280 or it's different too much and would require new features to support working with multi-page memory.
• [ ] keep in mind the MMU can differentiate between opcode reads and data write/reads from memory, targeting different physical memory page on the same 16bit offset depending on MMU configuration => my first guess is that this is not an issue for current sjasmplus, but should be tested if Z280 support ever happens.

Overall this looks feasible, quite a lot of new opcodes or rather variants of old instructions with new arguments producing different machine code, which may slow down regular Z80 assembling if added under dynamic flag (then again it would probably slow down maybe only invalid syntax cases if the Z280 extensions would be checked as last option in the current parsing, so valid Z80 would match as early as without Z280). In worst case maybe locking this under compile time define and produce completely alternative binary for Z280 support, not doing it through dynamic switch.

But this also looks like lot of work, and not sure who would verify/test it in practice, I don't have any Z280 machine and from the quick read about it it sounds like very rare chip, not used commercially much. Not on MY priority list high enough to start this on my own, if somebody else want to put enough hours into it, I can advise.

[ped7g]

If I'm guessing correctly OP's identity then I would not expect any more input from him, sadly.

So if someone else wants this to happen, now not only person having some HW for verification is needed but somebody adopting the idea as their own, taking over this and pushing this further.