maybe release vs debug type of build? And some other thoughts about this project

[ped7g]

Just thinking loud...

One may want a bit different code for debug build (especially with CSpect, as it unfortunately provides the break as instruction, and not external list of breakpoints, but even in custom code author way, the debug may have some extra things like border color changing for performance measurements, etc).

And if there would be such distinctions of build variants, maybe it would be possible to automate some items, like: --zxnext=cspect -D_DEBUG=1 compile time options for sjasmplus

Maybe along with provided default include file defining BREAK as macro checking for IFDEF _DEBUG and emitting the CSpect break only then, so the release versions would not contain them without the define.

---

Also I would personally add -debug to the debug type of run for CSpect, so it will start on the first instruction (hm, maybe makes less sense if one is using full system card image to emulate, I'm usually using NEX files directly without full image, so then -debug is very convenient).

---

Finally, do you think adding the default include would be too much for a skeleton? Or does it make sense to provide multiple templates like in high level language: (similar to your current hello world, but just jr $), similar to yours but moving constants to separate include, and adding the EXIT/BREAK macros, for dot commands and maybe even for completeness

Can you take a look and evaluate if this Constants.asm file would be good fit? I would love to see this naming scheme to spread across Next project, as I have strong personal bias for it (as author), so I can understand if you will think otherwise. :) (just asking)

I can also try to help you build the templates for dot/tap if you are interested.

(I'm not planning to use this, because I prefer make over other build tools, but I like your project and if you need some more support on sjasmplus side, or with Next assembly code, let me know - I have of course seen your request for output dir option, and it makes sense to me, so as time will permit, I will try to add it to sj).

[shred]

Thank you for your thoughts!

I was also thinking about that ant debug should invoke the assembler with different options, but that doesn't seem to be possible with ant, at least it's not easy. While I developed the skeleton, I wasn't sure if ant was actually a good choice, or if I should use write a cheap build tool in Python myself. I think I'll ditch ant and do the latter in one of the next versions. I also considered make, but always found its syntax even worse than that of ant. :wink:

I have tested the -debug option in #CSpect, but actually found no good use case for having the debugger started at that early stage. The first thing I always did was pressing F1 and let the emulator run to my first BREAK. But I guess this is a matter of taste, and it would just be adding a line to the build.xml file if you prefer the -debug option.

I think a standard set of include files is a must for the skeleton, but I haven't found official ones yet. I will investigate a little deeper, but I will gladly use your Constants.asm unless there is an official set provided by the SpecNext team (which I would prefer just because it's "official").

About the dot/tap templates: I'm not sure if I like to invest the time for having multiple templates. The skeleton is primarily made for the Spectrum Next, so I think generating nex files is sufficient at the moment. It's also not a big deal to change the output format if one wants to. If there are other requests for that feature, I may change my mind though.

What do you think?

[ped7g]

About includes... well, there is not truly "official example for others", but there are some sources of the tools included on the official distro, Garry Lancaster is using this file often: https://gitlab.com/thesmog358/tbblue/-/blob/master/src/asm/dot_commands/nexthw.def

But I find them more confusing because they hide the actual Next register value, while my constants keep it in the name, so it's still readable when you are just looking at particular code, without jumping to the definition back and forth.

(there's few more "default" includes, but IIRC Garry is using z88dk or Zeus for assembling, so some of them may require syntax fixing for sjasmplus)

---

about make - yes, syntax takes some learning. But the advantage is the feature-power and speed of the tool, you will hardly reach similar results in python/ant/gradle and other replacements (especially as I have to use gradle in my paid work, I can assure you it's not even funny how backward this stuff evolved in last 30 years). But it takes time to get familiar with make and exploit it fully, and as I don't use it often, I keep forgetting it too, so I can understand your stance. :)

[ped7g]

about dot files... where, changing between NEX and DOT is definitely not trivial. Not because of the assembler directives, those trivial are, but because of the design of the code, it's usually one-way ticket at beginning of the project, to pick the correct file format depending on what you want to do with your project (dot commands are more versatile and better for tools, NEX files are better for final SW which takes over machine without regret).

I.e. both are valid Next file formats and used often.

[shred]

About the includes: To be honest, I was surprised to find the register values as a part of the name. For me, the main reason for using constants is that I won't have to remember their values. :smiley: But I wouldn't prefer Garry's includes either. Well, I probably have a very strong opinion on that because I was actively writing assembler code for almost 15 years, back in the good old Spectrum and Amiga times.

About gradle, I know what you mean, as I do a lot of Java stuff. Well, gradle is much more than just a make tool, as it also takes care for downloading the dependencies. It would be way too much for just building some SpecNext tools for fun.

About the dot files: I got you wrong. I thought it's just another file format like nex, tap or sna. So yes, a very simple "Hello World" dot example would be useful.

I guess I will let the skeleton as it is for now, to find out if other people are using it, or if I'm the only one who is writing SpecNext programs on Linux. I also can't wait any longer to start my first ZX Spectrum Next project and collect some experience, rather than putting much more time in this project. :laughing:

[ped7g]

Well, I'm linux only (and if I would count years since my first assembly code, then I'm doing assembly like 30+ years, but not all of them actively, some years of those were near zero code).

But my toolchain is sjasmplus + make + git + Kate + image magick (and KDevelop + gcc for sjasmplus itself). I don't use VSCode (yet). And from emulators I use all two-and-half of them (CSpect, ZEsarUX and my own fork+patch of ZEsarUX), as each of them has different issues and bugs. :)

About values in names.. well, you don't need to remember them, why? They are there to be visible. Although sometimes when I don't remember the name of next reg, but I remember its number, I type the NR_4C to let the editor find the constant by that end part. But if I remember only the name, or part of name, then I type like _LINE_ and let editor show me list of all relevant ones to pick the correct...

GL with your project, don't spend too much time on tooling... that was my biggest mistake, I just wanted to find some assembler and start some game, and then I did quick peek into the assembler source and boom ... 9 months gone... :D

[shred]

Oh, so you're on Linux too? When I was looking for tutorials for programming the ZX Spectrum Next, I mostly found Windows and a bit MacOS, so I assumed I'm probably the only one... :smile:

I agree that I shouldn't spend too much time on tooling. I needed the skeleton tool myself, and if it helps others to start a project too, it was certainly no waste of time. But I doubt that more than a handful of people will ever use it.

Edit: I like VSCode, but the autocompletion feature is just driving me crazy me when writing assembler. I wish I could turn it off in an .editorconfig file. Maybe I should give KDevelop or Atom a try.

[ped7g]

the auto-completion is far from perfect in Kate either (I often end up ctrl+tabing into Constants.asm to search there and copy+paste, in the early phase of project when the main.asm doesn't contain the particular term I need yet). And if often gets into way while writing regular instructions, trying to change every ret into return from some comment.

But once you are used to it and can control it, it's not a big issue. After all, coding in asm means only a small part of time is spent actually writing the source (most is thinking / reading source / debugging), and the autocomplete annoys me only mildly, and only during that write time (and it also helps and works nicely for some use cases, so it's not rubbish all the time). So I can live with Kate/KDevelop as is, it's not driving me crazy enough to switch the editor.

But I was under impression mborik's Z80 macro assembler plugin for VSC deals also with autocomplete dabatase (as it drives also refactoring and understands sjasmplus advanced constructs like struct, etc), so I would expect it to work at least ok-ish. But I guess that may be also about personal preference, what you find good/ok/bad.