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.

[JonJones84]

I've built one of Plasmo's Z280 SBCs and it's currently booting with RomWBW so I have hardware I can help test with. My C++ skills are obsolete so not sure how much I can help with contributiing code. (I'd need some bootstrapping!)

[ped7g]

I wouldn't worry about C++ implementation too much (you could probably get pretty far by mimicking surrounding code and letting me polish it in review), but having somebody understanding Z280 and be able to track down all required changes, write test .asm files, verify with HW and overall help to maintain it actively in following years - that's the open position.

Fabio (OP) passed away.

Also this is lot of work (probably spanning across year+ if I'm mostly implementing it, at my spare time pace), and I see near zero demand for this, so this has to be really labor of love. I don't think there is practical value to justify this beyond "I just want to do this".

[JonJones84]

I've been doing some research into Z280 opcodes and stumbled upon a similar request in Z88DK.

Paulo pointed out that for Z88DK the blocker was that Z280 supports LD (IX+nn),A (Opcode DD77nn) and LD (IX+nnnn),A (Opcode ED2Bnnnn) so the assembler can't work out the opcodes until after the size of the offset parameter is known.

Would this be solveable in Sjasmplus?

[ped7g]

Is there solution? Several.
Is there solution easy and intuitive to use and making everyone happy? Unlikely. :)

Explicit solution would be to introduce source tag to make it clear which one is user expecting, considering the backward compatibility the byte variant is obvious, current syntax. The word variant would then need some extra tag like ldw (IX+n),a or ld (IX+"something"n),a.

This gives full control to user, if they forget to choose, the smaller variant is default (and would fail, if not sufficient), the con I can see is that the user may be not aware of what the correct 16b syntax is and struggle to fix code which requires it and that for frequent 16b usage the user will type more.

Then there are implicit solutions where assembler will use some heuristic to decide which one it will be. These still require some kind of explicit source tag being available to override heuristic in edge cases (first con), and with 3-pass assembling the most naive heuristic will cause issues because forward-referenced symbols will be zero at first pass, and letting this to be decided by N-pass feels wasteful anyway (plus N-pass is still not available).

So, I guess it would be possible to track in expression evaluator usage of symbols and if any non-equ symbol (or equ with large value) was used, consider resulting number "large", for constant expressions known in first pass the actual result is result and can be checked for -128..+127 range, and decide the instruction form based on that.

I'm struggling to think of intuitive and nice source tag, the best I can think of right now is something like ld.wd using the 68000 (IIRC) ".w" like way to suffix instruction with size, but ".w" alone would make it look as word is written into memory, so "wd" as "word displacement". Similarly, ld.bd could be used to explicitly request byte variant in case implicit heuristic would be used. Another direction is using some tag inside expression like (IX+word(...)), but right now this feels to me like hairier and asking for more trouble/clashes somewhere down the line in real usage.

Considering the Z80 -> Z280 historical progression, the explicit "byte by default, word when new keyword used" seems OK to me, at least for asm programmer (I can see this would be more painful to decide for C compiler as it is generating the code and the code is later linked so it may even use external symbols, but at assembly language I think we can demand of user a bit more focused input and be explicit about their intent). The implicit heuristic sounds like lot of effort and never be perfect anyway. It could make difference if there is heavy usage expected, but I wouldn't expect it to be used that much.

[ped7g]

But your comment made a bit worried why I didn't note this one in earlier comments, I guess I must have missed it, or back then I had some "obvious" solution on mind which I can't think of right now, so bringing this up here was valuable.

I would personally consider the "explicit ld ... being 8bit displacement and ld.wd for 16b" good enough as first draft and this point closed (definitely still open for feedback and objections).

edit: oh, I guess it was this

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

I just didn't realize usage of forward referenced symbols will cause the detection of 8b vs 16b displacement complicated?

[JonJones84]

Thank you. I'll carry on looking at what I can do to help with this feature.

[JonJones84]

I would personally consider the "explicit ld ... being 8bit displacement and ld.wd for 16b" good enough as first draft and this point closed (definitely still open for feedback and objections).

In some of the docs I've found, the opcode LDW appears to be used, so that's another option.

[JonJones84]

Another challenge I've found is that the offical Z280 opcodes clash with the unofficial Z80 opcodes. From what I can see in the Sjasmplus source, the unofficial opcodes are accepted all the time. Maybe a precursor feature would be to make the unofficial opcodes optional?

[ped7g]

The current option like --i8080 already have to deal with similar issues, so there are ways to deal with it in current code base.

The question is how ugly will be the result, ie. how much new code added and how much of it will be almost-duplicate-copy-paste-with-tiny-change and where it will be better fit to add runtime dynamic branch.

It's difficult to estimate this without actually doing it, but I'm pretty sure it will get more ugly than it is now, and right now it's not exactly most prettiest code. :D

At some point it would probably make sense to drop customized parsers per instruction and create data-driven syntax->opcode maps, enabling to support also completely different CPUs, but while that will shift complexity of code around and contain it from spreading indefinitely, it will probably cost some performance (or maybe not, tighter parsing code with extra indirection layer could still outperform larger direct code if it happens to fit caches better and play nicer with speculative execution - these things are supper hard to guesstimate without actually trying both variants under real life load and profiling).

Anyway, at current state of project and maintainers it's unlikely to justify any large refactoring in current state. Maybe after adding Z280, making it correct, making it work and then profiling and looking at resulting source code, it will become more justifiable to some huge architectural change, but I think the Z280 is still close enough to pass as some kind of horrible patch-over-current-source. :)