SjASMPlus от z00m

[Ped7g]

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

v1.14.0 changelog:
- INCLUDE bugfix, now searching paths according to original documentation (may break some projects)
- UNDEFINE had undocumented feature of removing also labels, cancelled (was broken beyond repair)
- R800 `MULUB` was producing wrong opcode all those years... fixed
- MODULE names can't contain dot any more! MODULE and ENDMODULE resets non-local label to "_"
- --syntax option: "m" (switch off low-mem access warning) and "M" added, "A" removed
- macro expansion can be inhibited by using "@" in front of instruction
- expression evaluator was not stricly 32 bit (64b binaries could have produced different results than 32b binaries)
- reading memory addresses 0..255 directly emits warning, use "; ok" comment to suppress it.
- several tests added to improve the code coverage: https://coveralls.io/github/z00m128/sjasmplus
- as tests were added, minor bugs were found and squashed (errors wording, etc)

Documentation http://z00m128.github.io/sjasmplus/documentation.html (or in the package/cloned source).

Last time I wrote there will be no 1.14, but some bugfixes did change the behaviour of the assembler a bit more than I wished (may even break some old projects, although unlikely or they can be fixed very easily), so I moved from 1.13.

But the idea is still the same, this is one of the last 1.x versions and there will be bugfix-only on 1.x in the future. And I'm going soon to start the "2.x" branch (which will probably start as 1.90.0, releasing changes feature by feature, so you will be able to follow the development all the time, the 2.0 will be released when the changes with regard to syntax and behaviour will be finished and stabilized).

If you have some project which did work with v1.10+ and is broken with v1.14, let me know about the issue. It may still require some changes on the project (it was not my goal to stay 100% backward compatible), but the changes should be very small and simple to do.

If you have some non-upgrade issues, or feature requests, feel free to ask here, or add feature request in github.

Thank you for your support everyone, have a great time.

[Advertiser]

[Ped7g]

Кажется получилось!
...

In my project I have much text data (text dialogs).
...

I finally found a time to review Reobne's script, and it's excellent.

I did adjust it slightly (to detect markers at beginning of line) and few other minor changes, and added it as official lua example in the repository:
https://github.com/z00m128/sjasmplus...s/lua_examples (all the "lua_inctext" files/folder)
(for your project you need only the https://github.com/z00m128/sjasmplus...ua_inctext.lua file and "includelua" it in your ASM source, remaining files are part of example + test)

So the "inc_text" file can now look like this:

>>Text1
Hello!!
Ready?
>>	DB 0     ; turn it into zero-terminated string by adding zero
>>Text2
SOS!!!
 >> \_o_/
>>Text3
GAME OVER
PRESS ANY KEY
>>Final
>>	RLCA
>>	JP Final
>>	BYTE "SEVER",0,"BURAN",0

It's still possible to use assembly lines in the file (just prepend them with the marker you want to use, default marker is ">>"), which I was at first a bit sceptical about, if I should keep it there, but after some thinking... it doesn't add any extra syntax to original text+labels thing, and it allows to insert short code or zero bytes after string like ">> DB 0". So I kept that feature there.

Also it did show bug in listing file of v1.14.0 (when bytes are emitted from lua, and parse_line is used too), so I fixed it, if you want "correct" listing like in the example, you will have to build sjasmplus from the github source (or get v1.14.1 release later, when it will be released).

So thank you again for your help with this, and for your patience, in the end it seems quite solid feature.

(BTW v1.14.1 probably soon, as the Microsoft VS builds were very broken and I managed to configure windows builds in the Cirrus CI, so now I can check myself if I did break the windows builds.. still a bit cumbersome, but better than no windows check at all, if you are building your own sjasmplus from sources and using VS, definitely avoid v1.14.0 and get fresh sources from github, there are many problems fixed for VS builds ... or just build with MinGW/MSYS2/etc, the GCC windows builds were OK all the time, just VS is difficult to maintain for me).

[Ped7g]

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

... just small bugfixes/polish, documentation refresh, etc... nothing important, if v1.14.0 is working for you, the v1.14.1 should do the same.

If you did want to build sjasmplus from sources (or debug it), with MS Visual Studio, then upgrade to v1.14.1 for sure, there were serious bugs in older versions, making VS builds crashing on some features. Now it should work mostly identically to official exe (built with MinGW GCC8.2), except few minor differences in `--fullpath` handling, etc..

edit: I'm very interested into any bug reports or issues, as the plan is still to make this one of the last v1.x releases, so I hope it will be rock solid stable, and everyone who needs Z80 assembler can use this version for many years without running into some trivial bug or getting damaged machine code from correct ASM source.

Checking my TODO: there is one open issue when you would try to assemble STDIN and literally input source code manually from console, then it needs many many Ctrl+D presses to finish the assembling (should work well when you just redirect some output of previous command to sjasmplus), and otherwise I am not aware of any "bug", everything else is "feature" :P

[Sayman]

Вопрос: условия в макросах добавили или нет ещё?

[Ped7g]

Вопрос: условия в макросах добавили или нет ещё?

What do you mean precisely? The reasonably simple cases work for me, like:

; conditions_in_macro.asm
testCond    MACRO arg1?, arg2?, arg3?
                IF arg1?
                    DB  arg2?
                    IF !arg1?
                        never happens
                    ENDIF
                ELSE
                    DB  arg3?
                    IF $8004 <= $
                        DB  "..."
                    ELSE
                        jr  nc,.localLabelInCondition + '!'
                    ENDIF
.localLabelInCondition
                ENDIF

            ENDM
    
        DEVICE ZXSPECTRUM48 : ORG $8000
        OUTPUT "conditions_in_macro.bin"
        testCond 1, 'A', 'B'    ; A
        testCond 0, 'A', 'B'    ; B0!
        DB " "                  ; " "
        testCond 0, 'C', 'D'    ; D...
        OUTEND

The binary contains expected "AB0! D..."

Maybe if you would combine them also with DUP and emit macro inside macro which has conditionals, etc... I'm not claiming it's 100% bug free, but AFAIK it works.

If you have some example of something what doesn't produce correct result, just post it here or open issue on github, thank you.

-----------------------------------------------------------------

EDIT: one thing "obviously" (if you know how sjasmplus works, hehe) does NOT work, you can't only start/end conditional block in macro, i.e. the whole block must belong to the same macro.. i.e. things like:

MyEndIf MACRO
        ENDIF
    ENDM

    IF 1
        nop
    MyEndIf

will NOT work, and I don't have any plan to support them, not even in v2.x (I mean, they may happen by accident if I rewrite the parser in certain way and I was toying with that idea for a short while, but I don't find these important, actually opposite, seems like code smell).

edit2: unfortunately, similar logic does apply DUP/EDUP blocks and others, basically any block (dup-edup, if-endif, macro-endm) should be nested in other block fully, interleaving start/end of different types of blocks will in 99% not work... and that's something I'm thinking about for v2.x, to allow things like conditional EDUP, but it's very complicated, so rather do not expect this ever working. I'm also not completely convinced this is real limitation, so far I had never issues to organize my code around these rules, but as always, by posting real-world issue with real project helps tremendously to shift my bias...

[Ped7g]

slowly going toward 1.14.2 release... so far the changelog looks like this:

- added i8080 mode (--i8080 CLI option) (it's still Z80 Zilog syntax, just limited instruction set)
- small improvements/polish/extra-info in docs, INSTALL, README, few new tests added
- cmake script fix of SYSTEM_LUA=ON option, CirrusCI configs added for macOS and FreeBSD
- few fixes of memory leaks, invalid memory access, double free/delete, ...

Basically nothing important for ZX coder, no bugs affecting code were found in 1.14.1, so no fixes. Sayman also didn't respond, so I guess everything works well for him... (the code is now really well covered with tests, so I don't expect too many new bugs to be found, maybe in the parts which are not covered well like TRD and HOB functions, but I don't know anyone using those and I'm not familiar enough with those formats to write tests by myself, so if somebody is bored enough, sending me test similar to TAP/NEX may help to cover it more)

I think the release will be done in couple of weeks or a month, something like that (unless there will be some unexpected activity worth a delay).

[NEO SPECTRUMAN]

- added i8080 mode (--i8080 CLI option) (it's still Z80 Zilog syntax, just limited instruction set)

ура
теперь будет проще адаптировать свои поделки к 8080
если ВНЕЗАПНО появиться такое желание

еще не тестировал
но по хорошему наверно надо чтоб
компиляция продолжалась до конца
и чтоб на z80, при этом, код был рабочим
но чтоб выкидывало ошибки
и номера строк где лежат z80 only команды

или же нужно 2 варианта режима i8080
при одном только предупреждения
а при втором уже пропуск z80 команд которых нет

- - - Добавлено - - -

Ped7g, а поддержка православного Sharp LR35902 случаем не планируется?

[Ped7g]

Ped7g, а поддержка православного Sharp LR35902 случаем не планируется?

The i8080 mode: it's actually still the same Z80 sjasmplus under, just not adding Z80 instructions into the string map at init (instructions like `rr` = "not recognized"), limiting registers (`ld i,a` is "illegal instruction", `ld a,i` will emit machine code of `ld a,0` with "label i not found"), and few more checks narrowing possible opcodes (`in a,(c)` = `in a,(N)` with "label c not found", etc..).

All of these types of errors are non-fatal, i.e. compilation will continue (machine code is usually not emitted for them, although if they can be interpreted as legit i8080 instruction with just missing symbol/label (i, r, ix, iy, c, ...), those get evaluated as zero immediate value and machine code with this zero value is emitted).

Check the listing files in `tests/i8080` for examples how the assembler is behaving and what/how errors are reported:
https://github.com/z00m128/sjasmplus...er/tests/i8080

(you can still help to improve it with feedback, if you think something of that is really wrong and you have idea how to improve it ... I'm quite OK with the current status, if I imagine I have Z80 asm file I want to make i8080 compatible, the current state would give me enough info and errors to know what to change ... plus I don't want to spend too much time on this, for me i8080 is minimal priority, it got added because it was minimal work and with the tests in place I'm not too afraid to break the Z80/Z80N parts ... also the z80.cpp after heavy refactoring is not that difficult to modify for this i8080 support).

About LR35902 - that's a bit more difficult, as it is not only limiting Z80, but changing some small parts of it. I will take a look and try to asses the difficulty... As mentioned above, due to test coverage I'm not afraid to break Z80, so I can give it some try. But then again, sjasmplus is strongly Z80 oriented with pretty much everything hard-coded, so it may turn out to be clashing too much with current implementation, not worth the effort.

Also the i8080 was reviewed by M.Borik and Busy, who are very familiar with it, they are doing lot of work lately on the PMD-85 computer (old Czechoslovakia 8bit from the ZX era, based on i8080), having fun there.

Do you know somebody being very familiar of LR35902, like doing GameBoy games, etc, who would be able to review the sjasmplus after such change, and asses it's usability, suggest improvements, etc?

(I was doing myself GameBoy Advance games, that was already ARMv6 CPU, so I'm unfortunately not familiar with this Z80 variant)

- - - Updated - - -

Did check the differences... seems doable.. not sure about syntax of some specials (should `ld a,($FFxx)` be automagically assembled as `ldh a,($xx)` ?? I think *yes* .... but `ld a,(hl+)` would end as `ldi a,(hl)` probably, just like the same fake instruction in current sjasmplus, not supporting the "hl+" syntax? Is it "good enough"?)

And I definitely need some "guarantor", who would check all opcodes and encodings after me, as by a quick search with google I already run into few technical references which slightly disagree between themselves or there's some info missing. Also seems there're subtle differences between GB, GBP and GBC, although I guess the machine code is identical, just the HW reacts a bit differently to some instructions ("STOP 0" seems to be rather "STOP $nn" and gets extra functionality in GBC, if I'm reading it correctly)???

So, if you know about somebody deeply familiar with the GB/GBP/GBC intricacies, who's willing to "sponsor" the sjasmplus (by making thorough review of the test+listing files, and also by commenting on the proposed syntax, plus recommendations about usability, if something like OUTPUT / SAVEBIN is enough, or there's some common format which would be very helpful, etc.. i.e. what is common in other assemblers and people would really miss that if I do just crude sjasmplus conversion like i8080 is). ... This may be about 8-40h effort. If you can find somebody willing to do this, I can add the LR35902 mode too.

[NEO SPECTRUMAN]

I'm not afraid to break Z80, so I can give it some try. But then again, sjasmplus is strongly Z80 oriented with pretty much everything hard-coded, so it may turn out to be clashing too much with current implementation, not worth the effort.

можно сделать отдельный SJASMPLUSGB
и вообще убрать из него z80

SAVEBIN

думаю с экспортом проблем особых не будет
gb gbc файлы не имеют какого либо заголовка
там вроде просто лежат 16к страницы друг за другом подряд (плохо помню)
и самих mapper-ов всего штуки 3

правда в начале ПЗУ там кажется есть контрольная сумма
если она не совпадает по моему запуск не происходит
(я не знаю как она считается)

но на bgb такой .gb можно и запустить
и в нем же исправить контрольную сумму если что
а потом можно запускать где угодно

who would check all opcodes and encodings after me

by commenting on the proposed syntax

я предлагаю поддержать синтаксис который генерирует IDA
+ у меня есть некоторый дизассемблированный GB код полученный в IDA
и я мог бы сравнить и проверить результат

[Ped7g]

можно сделать отдельный SJASMPLUSGB
и вообще убрать из него z80

дa, можно. (BSD-3 license, open source). But not *me*.

я предлагаю поддержать синтаксис который генерирует IDA
+ у меня есть некоторый дизассемблированный GB код полученный в IDA
и я мог бы сравнить и проверить результат

Again, if anyone [else] wants to create it, I certainly can't stop him.

But as long as we are talking about extra option to the sjasmplus I'm helping to maintain, the syntax of sjasmplus is to stay basically without change.

Luckily I don't know IDA, so I have no idea what's different, so for me this kind of comments (without actual content) are easy to ignore.

My question was if `ldi a,(hl)` is "good enough" (people will use sjasmplus even with this), or the `ld a,(hl+)` *must* be supported to make people even consider using sjasmplus for GB dev.

If the syntax must be modified as whole, because GB devs will not accept sjasmplus syntax, then this leads nowhere, I don't have time/will to rewrite all of it, and then later to maintain it.

I can add few exceptions here and there, maybe even "(hl+)" and "(hl-)", but if that will happen, it will be probably treated as fixed string, requiring it to be used in source in literal way (no extra space inside/etc). But as long as we are talking about *me* adding it to *zoom128's* branch, it's sjasmplus Z80 syntax in 95%, plus few important exceptions (which you must describe in greater detail than "like IDA", that means nothing to me and I don't want to invest my time googling how IDA looks)

контрольная сумма

I guess this one can be easily implemented with some macro in `DEVICE ZXSPECTRUM48` mode, just like there were those macros to calculate XOR/ADD checksums before. Even if it needs more complex formula of checksum. Such macro can be added to tests/macro_examples folder, so you will just include the asm file from there for definition, and use the macro at proper place after you have the header data in device memory defined.

Meanwhile I did create a summary of the opcode differences, if somebody wants to check if I have them Oll Korrekt:
LR35902_Z80_diff.ods.7z (it's ODS spread sheet file, two sheets)

Basically it all boils down to somebody else investing their time to prepare the resources/details/info for me, so I don't need to waste my time on that. And after implementing it, again somebody else will have to review + check the result.

You seem to be actively helping with this, so if you think you can go all the way along from start to finish, then it may become real (just don't expect it to be super simple, to deal with me ... I'm sometimes quite an ass ... and hole... )