SjASMPlus от z00m

[Ped7g]

https://github.com/z00m128/sjasmplus...es/tag/v1.14.4

v1.14.4 changelog:
* in lua scripts: sj.calc(..) (alias _c(..)) now substitutes defines and macro arguments
* error reporting inside LUA and MACRO refactored to give better info about origin of error
* macro-arguments parser now recognizes C++ numeric literals with apostrophe as digits-group separator
* added few example utility macros in tests/macro_examples/sj_library.asm (neg r16)
* added SAVENEX SCREEN BMP sub-command to include BMP loading-screen
* added support for V1.3 of NEX file format (new commands: CFG3, PALETTE, COPPER, new screen modes)
* the assembler will instantly exit when run at Big-Endian platform (the rest of code is broken on BE)
* updated syntax-highlight file for KDE5 editors (Kate)

As always, if you have some issue, post small source example here and describe the problem, hopefully I will be able to figure out what is going on, and fix it.

-------

I have seen the question in the other thread:

Народ, а насколько возможно переделать Sjasm под другие процы типа мотороловских 6800 или наших 1801ВМ1 и так далее. Вроде исходники ассемблера есть. Никто не заморачивался этим вопросом?

The Z80 instructions parsing is quite heavily baked into the code, so it's not super simple to change it to other CPU (like just replacing some table, you have to write the code for instructions parsing). And the parsing helper functions are not 100% beautiful with amazing API, although it's getting very slowly better, but I'm not going to do big rewrite for v1.x of sjasmplus, because of lack of time.

If you don't mind any of this, and you want to write the 6800/1801BM1 instructions parser, I believe the rest of the assembler will mostly fit nicely along, and in case of some hard friction I can help.

I'm not going to do the 6800 myself, because I have no experience with the CPU and no spare time for this, but I would welcome (and help with final details) pull request if the changes would be reasonably confined, covered well with automated tests and there would be done some research between current 6800/1801BM1 developers what syntax is useful and acceptable... It's just not in my interest, so I basically don't care too much, except helping with the final stage.