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.

[Ped7g]

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

v1.14.5 changelog:
* fix crash when opening source file fails
* DISP / ORG warns about being used inside DISP block (also docs extended)

[Shadow Maker]

@Ped7g could you add to your fork this patch to support 2 more commands for interactive debugging? https://zx-pk.ru/threads/9361-breakp...l=1#post178902 Not the patch per se, but the main idea to create a file with list of breakpoints.

[Ped7g]

@Ped7g could you add to your fork this patch to support 2 more commands for interactive debugging? https://zx-pk.ru/threads/9361-breakp...l=1#post178902 Not the patch per se, but the main idea to create a file with list of breakpoints.

Sure I can.
But I spent about 1h reviewing the patch and web, and I got to a point where I am a bit confused.

The old patch seems to create file with list of 4-character long hexa addresses, i.e.:
1234
BCDE

I have very little idea about what is the current version of unreal and it's specifications, but if I would guess by this project:
https://github.com/mkoloberdin/unrea...bgbpx.cpp#L679

the breakpoints file format is now more complicated, allowing for various conditional expressions, but just simple 4char hexa data will be not read at all.

Can you please confirm what kind of breakpoints file can be used with what emulator, and at which version? Should I add the original form from patch? Would it help to add also some new form compatible with that parser in source I link above?

I'm planning to add also ZEsarUX type of output, which will look like this (and can be used by mixing it into the command line while launching the emulator):
--enable-breakpoints --set-breakpoint 1 "PC=1234h" --set-breakpoint 2 "PC=0BCDEh"

Maybe I can even add support for any-expression (the ZEsarUX allows for something like "PC=1234 AND B=255 AND C=123", etc...), although I'm not sure how useful that will be, if I will add it, I will probably not verify the syntax too much, so it will require good knowledge of emulator on the side of the coder writing asm, to use it correctly.

Also with the machines having extra memory beyond 64kiB address range, if you can give me info how to add also memory paging info to the breakpoint, it will be even better (I'm not even sure how to do that in ZEsarUX, will take a look, maybe it does support something like "PC=... AND somethingLikeMemoryPage=...", or I can ask Cesar to add it maybe... (just talking loud while thinking).

...

So, please specify correct format with list of emulator+version which supports it, so I can add that to documentation, and add examples of different types of breakpoints output for different emulators. And some examples how the output file should look (please make it explicit if hexa values like "BCDE" need initial zero or not, and if they need suffix/prefix like 0xBCDE or 0BCDEh - the old patch seems to produce only "BCDE"? That's a bit weird.)

Thanks.

[Shadow Maker]

Sure I can.
But I spent about 1h reviewing the patch and web, and I got to a point where I am a bit confused.

The old patch seems to create file with list of 4-character long hexa addresses, i.e.:
1234
BCDE

I have very little idea about what is the current version of unreal and it's specifications, but if I would guess by this project:
https://github.com/mkoloberdin/unrea...bgbpx.cpp#L679

the breakpoints file format is now more complicated, allowing for various conditional expressions, but just simple 4char hexa data will be not read at all.

Can you please confirm what kind of breakpoints file can be used with what emulator, and at which version? Should I add the original form from patch? Would it help to add also some new form compatible with that parser in source I link above?

I'm planning to add also ZEsarUX type of output, which will look like this (and can be used by mixing it into the command line while launching the emulator):
--enable-breakpoints --set-breakpoint 1 "PC=1234h" --set-breakpoint 2 "PC=0BCDEh"

Maybe I can even add support for any-expression (the ZEsarUX allows for something like "PC=1234 AND B=255 AND C=123", etc...), although I'm not sure how useful that will be, if I will add it, I will probably not verify the syntax too much, so it will require good knowledge of emulator on the side of the coder writing asm, to use it correctly.

Also with the machines having extra memory beyond 64kiB address range, if you can give me info how to add also memory paging info to the breakpoint, it will be even better (I'm not even sure how to do that in ZEsarUX, will take a look, maybe it does support something like "PC=... AND somethingLikeMemoryPage=...", or I can ask Cesar to add it maybe... (just talking loud while thinking).

...

So, please specify correct format with list of emulator+version which supports it, so I can add that to documentation, and add examples of different types of breakpoints output for different emulators. And some examples how the output file should look (please make it explicit if hexa values like "BCDE" need initial zero or not, and if they need suffix/prefix like 0xBCDE or 0BCDEh - the old patch seems to produce only "BCDE"? That's a bit weird.)

Thanks.

Basically it is same as ZEsarUX PC=1234h. Of course breakpoints support conditionals and stuff, but realistically speaking, when you develop in assembler, then all you would need is a PC breakpoint, to stop on the exact routine you want to develop. Anything complex would be not really usable through the assembler and would be done through debugger itself (I am speaking about my own experience, it can vary between coders I think, but I really fail to see usability of complex breakpoints inside the assembler - you generally set them while you are deep in debugging, and you do not know the conditions when you write the code, and usually you find these conditions when you debugged a lot from the starting point, so you would not really need such breakpoint, as, naturally, you're right now is in correct place and in debugger already, not in assembler).

So, this format works good enough. You cannot set a breakpoint to a precise page in Unreal (IIRC, maybe it is different now, but I think no), so nothing really complex is needed. It is just a plain format, it treats any number as hex, so 4 characters is enough (Unreal works with hex only, so no need in prefixes). In any case, if something more complicated would be needed, we can extend the format further later.

I think latest Unreal source codes are here http://dlcorp.nedopc.com/viewtopic.php?f=27&t=1525 but there are tons of forks nowadays, so hard to tell.

[Ped7g]

Basically it is same as ZEsarUX PC=1234h.
...
I think latest Unreal source codes are here http://dlcorp.nedopc.com/viewtopic.php?f=27&t=1525 but there are tons of forks nowadays, so hard to tell.

So I downloaded the `us0.39.0.src.7z`, and checked quickly the source (not full of course, I'm not *that* fast), and I don't see any code capable to load file like this:

1234
BCDE

So I believe that old patch format is not usable with latest unreal (but also from unreal changelog I can't easily guess which old versions of unreal did support such simple format).

If you have some emulator which works with such simple breakpoint file, please try it to be 100% sure, and then post the emulator name + version - otherwise I think this format is useless and I'm not going to add it.

The 0.39 emulator seems to expect file like this (reading the source in text editor, so not sure if it is using regular clib "sscanf" or some custom-patched which will then read different things):

r0=0x1234-0xBCDE
x1=07654
w0=12345

Notice the values have prefixes (and "07654" is octal value 4012 and "12345" is DECIMAL!).

First character must be one of "r, w, x" (I guess it's read-mem, write-mem, exec-instruction type?).
Second character is single digit to select index of CPU. The two address values form a range (if only start of range is specified, then end of range is equal to start).
(EDIT: this range is not sanitized everywhere, so it can cause segfault if you specify large number in the file
- but also it may mean it can set breakpoint to large memory, if the variable "cpu.membits" is more than 64kiB, but I'm not going to hunt this down, would need to open the project in regular IDE first)

I.e. this again does not match your info. I don't need "like/similar" info, I need *precise* info (I don't know how to run unreal emulator, and I'm not going to spend another day trying to compile it and to learn how to use it and looking for some test files or rom files, etc... => so I can't try these things by myself easile => not easy, not happening soon)

From the source of 0.39 and help files there seems to be some debugger console or something, where it is maybe possible to export/save current breakpoints (there is SaveBpx() function).

Can you try open some app in the emulator, add few breakpoints at two-three addresses (like 0x1234 / 0xBCDE), and export them, and then post the resulting "bpx.ini" here?

Or try to build the "bpx.ini" file the way how I'm describing it above (trying out also different prefixes for octal/hexa/decimal), and try to load that into emulator, if it loads correctly.

Or if some other format works for you, then just confirm it works with that unreal 0.39 and post example file which was working (if you can even find source code parsing the file, that will be excellent, because I did find so far only these "bpx.ini" parsers).

[Shadow Maker]

So I downloaded the `us0.39.0.src.7z`, and checked quickly the source (not full of course, I'm not *that* fast), and I don't see any code capable to load file like this:

Or if some other format works for you, then just confirm it works with that unreal 0.39 and post example file which was working (if you can even find source code parsing the file, that will be excellent, because I did find so far only these "bpx.ini" parsers).

Yes, you're right, format was changed while I was not aware. Sorry for that. I used outdated build.

So yes, format is as you told:

r0=0x1000-0x1100
r - breakpoint would execute on r/w/x
0 - always 0

Why do you want to compile it from source files? There is binary right next to them http://dlcorp.nedopc.com/download/file.php?id=3013 You can run it just executing "unreal.exe"... or "wine unreal.exe" if you're not using windows...

Example of bpx.ini I want:

x0=0x5FFB
x0=0x70EF
x0=0x7246

x - means execution breakpoint (could be r for memory read breakpoint or w for write memory breakpoint)
0 - always 0 for spectrum breakpoint

If you want, I can attach it as a file, but it is really same, I just copy-pasted from existing working bpx.ini

So basically it is same as what I told before, but with static x0=0x for every line. It is also possible to make an area breakpoint like x0=0x5000-0x6000 but I do not think this have much use, but it is up to you. You can also support type of breakpoint (r/w/x).

Regarding system - I suppose you can use any of these according to

int n = sscanf(Line, "%c%1d=%i-%i", &Type, &CpuIdx, &Start, &End);

but Unreal itself uses hexadecimal notation, when you save breakpoints, so I suppose better to use hex.

Did I describe everything clear?

[Ped7g]

"Why do you want to compile it from source files? There is binary right next to them http://dlcorp.nedopc.com/download/file.php?id=3013 You can run it just executing "unreal.exe"... or "wine unreal.exe" if you're not using windows..."

I prefer to be able to rebuild the project, so I can also debug it or modify for experiments... but even bigger issue is the "exe", I don't have windows, and my "wine" config is kinda flaky and broken, as I don't use it very often and can't remember what experiments I did with it, but I can't run windows executables easily... Anyway, it would highly likely take me at least half a day to make it work and to learn how to use it, probably whole day.

So it's quicker just to take a look at the source code and let *you* confirm if I understand correctly how it works

The new info is perfect, now I'm sure the code I have seen is used, and I did understand it correctly, so I know how to produce working bpx.ini from sjasmplus.

If you will pull latest sources of sjasmplus from github, it's now implemented.
(check the last commit and new asm test files to see the usage, the docs are not updated yet... next thing to do)

[Shadow Maker]

"Why do you want to compile it from source files? There is binary right next to them http://dlcorp.nedopc.com/download/file.php?id=3013 You can run it just executing "unreal.exe"... or "wine unreal.exe" if you're not using windows..."

I prefer to be able to rebuild the project, so I can also debug it or modify for experiments... but even bigger issue is the "exe", I don't have windows, and my "wine" config is kinda flaky and broken, as I don't use it very often and can't remember what experiments I did with it, but I can't run windows executables easily... Anyway, it would highly likely take me at least half a day to make it work and to learn how to use it, probably whole day.

You're very optimistic. You cannot make unreal working in any other OS, as it is strongly tied to WinAPI But I would use it gladly if you really make it working. (PS: yes, I understand that you mean wine, not unreal, I told it just to illustrate that it is windows-only tool and no point in trying to compile it anyway).

So it's quicker just to take a look at the source code and let *you* confirm if I understand correctly how it works

Actually I also do not use windows for years. So I am in the same boat, I am using wine for that. But as I was the one who asked for it... I did not have a choice, I guess?

The new info is perfect, now I'm sure the code I have seen is used, and I did understand it correctly, so I know how to produce working bpx.ini from sjasmplus.

If you will pull latest sources of sjasmplus from github, it's now implemented.
(check the last commit and new asm test files to see the usage, the docs are not updated yet... next thing to do)

Ok, thanks. I will take a look, but on weekend. Maybe you will write update the doc in meantime, hehe

[Ped7g]

yup, docs are now added and uploaded too.

I did test the ZEsarUX mode myself, had to patch the ZEsarUX a bit as it's currently not working as expected with the command line options (loading the snapshot from command line will disable breakpoints, so I patched it in my fork). Anyway, the command line options outputted by sjasmplus are correct, so the sjasmplus part is done.

I will not test the Unreal myself, but the content of file seems to me correct, so let me know if it fails for some reason.