6502.org

There are a few advantages to comments that use a line prefix:

• Auto-formatting tools generally work better with them, because they require less syntactical analysis than block comments, particularly block comments with word-based delimiters. (Many reformatting tools can't even be programmed to properly reformat your example above without manual marking of the first and last lines in the block to exclude COMMENT and END_COMMENT.)
• A line prefix makes it easier to use programs like grep to extract or strip out comments.
• Perhaps just a personal thing, but I generally find the semicolon-prefixed version of things like that easier to read because the comments are clearly set off in a way that scans quickly, especially if the comment is very long. I certainly prefer BDDs current version he posted below to one without the semicolon prefixes.

Of course I'm sure that the COMMENT / END_COMMENT thing also has its particular advantages; I just wanted to point out some of the advantages a line prefix has. And also note that easier formatting for formatting tools is not an advantage of block comments, unless you're using a relatively primitive formatting tool. All of the reasonably sophisticated ones deal exactly the same even with bullet points, hanging indents and suchlike, whether or not a comment prefix character is used.
This analogy is broken in so many ways:

• The new car is free of cost, for God's sake.
• You're driving a non-standard car and asking folks writing code for you for free to write yet more code (and do more support work) to support your non-standard car in addition to the standard.
• The propeller-heads here are not unnamed; you can easily go find out who they are, and you even had an opportunity to give input on the new standards.
• You are perfectly welcome not to visit web sites you don't want to visit, but complaining about web sites you don't even want to visit is merely dragging your problems into other peoples' lives. If you don't like something you don't want to use, especially when you had a opportunity to influence that design that you were too lazy or ignorant to take, just shut up about it already.

The author has already graciously offered to make the application Firefox compatible once the codebase is a little more stable. They've also enumerated the specific APIs that don't currently work on Firefox, so it's likely you could even use the application today without touching the load/save/usb-serial features and have an enjoyable time. This seems like an unnecessarily negative attitude toward someone sharing their creation. The feedback that Firefox-compatibility would be useful has been addressed.

Tuna, your project is very cool. Given your ambitions for compatibility with common assemblers, it could be very cool to see it on the command line (via node, deno, whatever). Another neat capability would be load/save from github (or other web-scm) repositories. If you don't want to just go on and do a VS Code plugin

Nice project Andy! (One might say, don't feed the trolls.)

Since you clearly don't want to use the tool I'm providing for free, please can you provide your IP address and I'll ban you from my site to make sure you can't be offended.

I've just checked it on the current release of Firefox (91.0.2 (64-bit)) and it works just fine. If you aren't running a reasonably recent release, can I take it from your analogy that you never check and replace your tires, oil or belts in your automobile, and complain that other people's cars "brake too well"?

Thank you. I'd very much like to make it work with github at-al, but have so far committed to making it a completely static web page (no back end server) - that makes authenticating to web-scm repos a bit of a challenge.

A command line tool should be easier to create once I've rounded out the core functionality a little.

That one is easy.

Every assembler using the "trailing h" notation requires starting with a numeric digit.

So it is written like 0FEh

I am cheap. For commenting out a block of code, I use
The assembler already has conditional assembly constructs.

Also, what output format can the assembler produce? An o65 file is essential for relocation of binaries at load time.it has been mentioned here already that separate link stage is desirable which would require a linkable file format.

Does it support arbitrary nested blocks?

I use this a lot in my code with xa65, that has .( and .) for block demarcation.

It's not a goal (at present) to generate relocatable binaries. Running within the browser, the assembler produces a listing output and writes binary to the emulated system. A command line version would obviously have to write a binary file (or files) - but as there are plenty of command line tools out there, it's not a priority to 'compete' with existing, mature offerings.

Internally, the assembler supports an arbitrary number of nested scopes, which will be available when I add block level directives.

Doh! Of course. That'll teach me not to engage the braincell.

Not every one. Some, such as certain MSX assemblers, will simply look up the token as a symbol first and, if a symbol with that name is not found, process it as a hex number if it's in a valid format for that. So `LD A,BAH` will use the value of symbol `BAH` if it exists, or the hex value BA if it doesn't.

If that strikes you as unfortunate, I believe the assembler also allowed Motorola-style hexadecimal literals, so you could just use `$BA`.

(I don't recall the name of the assembler in question, unfortunately. But it may have been multiple assemblers that all did this; I got the impression that this kind of thing was not uncommon in the MSX world.)

Can I throw in a vote for &FE as well.

Does your conditional assembly accept if-defined label-name as well as if label-name? #IFDEF helps a lot with much of the code I write as unknown defaults can easily be set.

Some assembler use the ampersand for octal Good point.

Also what about if-used label-name?
I use this for (assemble-time) libraries, to only include code that has actually been referenced.

André