SjASMPlus от z00m

[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 случаем не планируется?

[Advertiser]

[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... )

[NEO SPECTRUMAN]

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.

ну синтаксис IDA и bgb вообще предлагает использовать квадратные скобки
может по ним можно отличить gb код от z80

F0 F6 - ld a, [$FFF6] - IDA
FA B5 DB - ld a, [$DBB5] - IDA


F0 F6 - ldh a,[$FFF6] - bgb
FA B5 DB - ld a,[$DBB5] - bgb

но все равно придется проверять
есть ли обращение к FF page

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

насчет
LD A,($FF00+nn)
LD A,($FF00+C)
LD ($FF00+nn),A
LD ($FF00+C),A
LD HL,SP+nn

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

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

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.

по хорошему нужна полная поддержка синтаксиса IDA
чтоб про дизассемблированное в IDA можно было сразу скомпилировать

в IDA запихнут синтаксис от rgbasm-а
но сам rgbasm не пригоден к использованию
(так как редкостное ***** а не компилятор
я потратил сутки чтоб заставить его просто компилировать... )


то есть сейчас есть отличный дизассемблер (IDA)
но нет к нему нормального компилятора
...по крайней мере так было несколько лет назад

[Ped7g]

F0 F6 - ld a, [$FFF6] - IDA
FA B5 DB - ld a, [$DBB5] - IDA

good, that's sjasmplus compatible way (with adding magic detection of $FFxx for `ld a,(a16)` turning it into `ldh a,($xx)` = that's extra new code, but tiny one)
(adding `ldh` extra is also tiny work, such changes are generally OK and can be expected).

You can even enforce square brackets in sjasmplus with `--syntax=B` option .. which may be default for GB mode (?), by default the square brackets are only optional in sjasmplus.

LD A,($FF00+nn)
LD A,($FF00+C)
LD ($FF00+nn),A
LD ($FF00+C),A
LD HL,SP+nn

my first guess would be (in sjasmplus mostly compatible way, "easy" to add):
ldh a,[$xx] + ld a,[$ffxx] ; impossible to create 3byte `ld a,[$ffxx]` (except using `db` or other hack)
ldh a,[c] + ld a,[c] ; `ld a,[$ff00+c]` would be INVALID syntax, that's too much fuss, `ld a,[c]` must be enough
ldh [$xx],a + ld [$ffxx],a ; impossible to create 3byte `ld [$ffxx],a` (except using `db` or other hack)
ldh [c],a + ld [c],a

The `ld hl,sp+nn` is tricky ... if I don't need to follow other assemblers, then the simplest thing is to create extra mnemonics like `addhlsp $nn`
If I *must* follow some other assembler syntax, I need to first see it, to evaluate how much pain it will be.

`add sp,$nn` can use default syntax, needs just extra trap in implementation, but `add sp,anything` is invalid on Z80, so such trap will not clash with regular Z80 implementation, that's easy to add to add (pun intended).

.... in the end, I'm 100% sure the syntax will be "sjasmplus" tainted, not 100% compatible with other assemblers, but at least something like 99% would be nice.

EDIT: that "ld a,[$ffxx]" detections would happen after evaluation of the expression, i.e. you can write in source `ld a,[my_variable_in_ffxx_memory]` with regular label, and it will emit 2B opcode if the final result is in $FFxx range. ... but that means that you can not assemble regular `ld a,[a16]` opcode with $ffxx value, like for self-modify code, you will have to use `ld a,[0000..feff]` or `db $FA : dw your_ffxx_initial_value` to get the 3B encoding, otherwise the LD magic will collapse it to 2B encoding.

- - - Updated - - -

по хорошему нужна полная поддержка синтаксиса IDA
чтоб про дизассемблированное в IDA можно было сразу скомпилировать

It's usually impossible to directly compile the disassembled source. And when the syntax does pass and some binary is received, it's usually impossible to keep identical binary.

For example I would expect IDA do disassemble `FA 00 FF` as `ld a,[$FF00]`, but by assembling that back you will get `F0 00`.

That's a common problem with disassembling + assembling machine code on all platforms, and I have zero will to pursue "perfect" results, that's not the point of assembler. Besides that you can always use the original source, and modify that, no need to disassemble any good SW (because good SW comes with sources .. if it doesn't have sources, it's not GOOD .... max OK-ish, but not good+). (yes, I'm kinda radical in this).

So all your IDA examples, etc... keep in mind it will work in 90-99% cases only and that's what I would try to achieve, but it will never be 100% binary identical, there will be always a way to derail the IDA+sjasmplusGB tooling into producing different binary. And I don't care, that's not a real issue for real good SW.

So the effort is to get as close as possible. Let's say in ideal case any IDA source will assemble to *expected binary* (even if different from original), i.e. the syntax will be mostly understood. And if even that will be too much pain, some instructions may need hand-patching to "fix" their syntax.
(*expected binary* = from the source you will be able to tell, how the binary will look, i.e. stable machine code is produced, no random variants... if the produced binary is not identical to original, then it will be different in every assembling, and you can tell already from the source, that the resulting machine code will differ ... there should be no "surprise" involved).

- - - Updated - - -

... so.. if you can produce examples of all GB specific instructions, how they are disassembled by IDA, it will help to see, how compatible it is with sjasmplus...
You can use that spreadsheet in my post to see which instructions are different, and disassemble those for me. The identical instructions will simply use current sjasmplus syntax. If you know about case where that is not compatible with IDA, let me know, it's a good info. I may then decide to either change the sjasmplus, or simply be not compatible with IDA.

But so far (square brackets) the IDA syntax is sjasmplus compatible.