6502.org

I'm no expert on spreadsheets, but I suspect it will run with non-MS software like LibreOffice, won't it?  The file types have become pretty much industry-standard, so MS software is hardly needed for anything anymore.
People make a lot of unexpected progress that way.
Can you give a link, or just attach it here.

(This may be a partial repeat of material on preceding pages, just summarized:)  The Kowalski package BDD refers to seems to be popular on the forum.  The final version released by Michael Kowalski is here (.zip download, with executable for DOS/Windows, but can be used with Mac & Linux under WINE).  More info here.  It's all on github too.  However, our own Daryl Rictor (forum name "8BIT") subsequently modified it and produced V1.2.15.  This was the final version that recognizes only the 8-bit processors.  Version 1.4.0.9 (again by Daryl, and available on his page) recognizes the 65816 for assembly, and now its simulation extends to the '816 also (starting 7/18/24), no longer being limited to the '02.  He will no longer be developing the 1.2 series though, and says that although he will continue to do bug fixes on the 1.4 series, he's done adding features.

That's what I used on the Apple //c, Merlin Pro.

Attaching my current spreadsheet. For my first back-to-life project I wrote a hex/ascii dumping program, in the "asm hexdump" sheet. just type in lines in the "assembly" column and code comes out the "compiled" column. When using Apple][js I just open the monitor and paste the compiled block right in. Don't try to insert or delete columns or rows, that's very likely to break things. Just make a copy of that sheet and clear the contents (select and delete) and put your own code in. It's "hard coded" for about a thousand lines but there's no reason it can't go higher. In most cases it'll turn the red Compiled cell red if there's a problem, though it can't tell you what's wrong. Most of the magic is handled by incremental processing in hidden cells which you can widen up if you're curious to see what's inside the black box.

I've only been playing with it for a few days, if you have (reasonable!) suggestions for additions, improvements, or bug fixes, let me know. (arithmetic on the addresses is probably NOT going to happen)

For me the main benefits of an assembler are automatically adjusting the jump offsets, resolving subroutine addresses, translating opcodes, and of course storing code commentss. My notes aren't for you, they're for me, because I quickly forget details. (and that's why there are so many comments in my code) Anyway, this does what I need it to do. The biggest benefit for me lately is recalculating branch offsets when inserting code during development. It's a huge time-saver, and I've found that bad branches are responsible for most of my bugs when not using an assembler.

Woz would be proud.

My point was that your .xlsx file worked fine in LibreOffice.  I don't have Windows or use any Windows software.

Here are some things that come to mind about the value of an assembler, starting with the most basic stuff:

• I think it's good for beginners to start out assembling by hand, so they get a good feel for what has to happen at the lowest levels, then build upon that to higher and higher levels.  As you assemble by hand, you quickly learn all the op codes you commonly use.  However, obviously you'll soon want to graduate to using the mnemonics and hide the op codes, as well as let the assembler figure out the addressing modes, so you can advance to greater things.
• The next thing you run into might be conversion between hex and decimal.  Converting by hand, or even if you have a calculator that does it quickly, slows you down.
• At about the same time, you'll start to get tired of having to fix branch distances and jump address as you make changes to the code that scoot targets around because a routine got longer.  (Shorter is not as bad, because you can leave segments unused.  One thing I did when I was starting out however was to put in trios of NOPs here and there, so there was some room for inserting instructions without having to re-do so much.)
• Then you'll find that dealing with addresses and constants gets cumbersome as the project grows, and you want to be able to use descriptive names.  That's where labels come in.  A label for a constant will typically be followed by the EQU ("equate") assembler directive and an expression that can be turned into a value for the assembler to remember for when that name is referenced.
• You'll want to be able to start (or pick up) assembly at a particular address, which is where the ORG (origin) assembler directive comes in.  If you need to move a whole set of routines, all the addresses are adjusted automatically.
• You'll want to define data areas, for example strings or tables that will go into ROM.  (Variables and variable arrays will always go into RAM.)
• It should have a good set of operators for expressions, for example +, -, *, /, =, <, >, <=, >=, right and left shifting, arithmetic and logical AND, OR, XOR and inversion, value of the current program counter, etc., and of course allow comments.
• The assembler must produce the appropriate output.  There will usually be choices of binary, Intel Hex, Motorola S-Record, and possibly others, and a .lst (list) file which has the source code with the assembled hex off to the left, which sometimes proves valuable for making sure you got what you intended.
• There will usually need to be at least two passes, and possibly more until the phase errors disappear.
• You'll want to accommodate conditional assembly, meaning, "If such-and-such is true, assemble the following lines; otherwise assemble these other ones," and make these nestable.
• You may want to bring in another file, using the INCL (include) assembler directive.  This should be nestable, meaning the one you bring in should be able to call in yet another one, and so on.
• You'll want to be able to define macros.  A macro is like a subroutine that the assembler itself runs, and it usually generates code, or it may even just take care of some other housekeeping.  It needs to be able to accept input parameters, and it can have conditional assembly such that the machine code that results depends on the input parameters and optionally other conditions you have set up in the assembler.  Macros should be nestable too, meaning one macro should be able to invoke another one, to shorten its definition.
• Error messages should not leave you guessing or hunting for what the problem is.

As for comments, I would not say you had a lot.  "Self-documenting code" does not mean you don't have to comment.  It just helps.  Even if the code is very clear about what it's doing, it does not tell why you chose to do it that way.  The comments are not optional.  There have been times that I looked at something and thought, "Wow, there's a better way to do that!" and then after wasting a lot of time on it, came full circle because I re-discovered why it had to be done the way it was and not the way I thought was better.  Comments would have saved the time.  The DOS/ANSI character set (called code page 437) is great for drawing smooth diagrams to illustrate your keypad's key numbers, a data structure in memory, etc. in your source code.  I sometimes catch bugs when further commenting code that's already working but not exhaustively tested yet.  I comment as if trying to explain it to someone else who hasn't been following my train of thought on it.  (If I come back to change it a year later, I'll need the comments anyway.)  As a result of this madness, no user has ever found a software bug in any product or automated test equipment I programmed.  The projects have had up to 10,500 lines of code.

An hour-long video about the Oberon language has a couple of quotes I really liked (at around 36 minutes into in, give or take):

• Programs must not be regarded as code for computers, but as literature for humans.
• Reducing size and complexity is the triumph.

"Beauty is more important in computing than anywhere else in technology because software is so complicated.  Beauty is the ultimate defense against complexity." —David Gelernter
"Good programmers know what's beautiful and bad ones don't." —David Gelernter

I have a list of feature requests for if someone writes an assembler, here.

Hilariously, I think my Excel assembler breaks every single one of your requests

My office is a mess, but my programming is kind of OCD, and I do try hard to make my work fit into David Gelernter's (above) quotes.
There's a lot to be said for familiarity.  But that's also why I recommended, on that page, allowing flexibility, to accommodate people coming from other assemblers, and making one's shiny new assembler able to handle source code written for other ones, with minimal changes.

My office is well beyond a mess, but is, in a perverse way, organized around my work habits and physical limitations.

As for programming, I too am somewhat OCD with how I organize my source code.  Even the stuff I write in Thoroughbred Dictionary-IV BASIC is highly organized, with comment blocks, in particular, being carefully formatted for readability.  It’s almost like assembly language in appearance, the latter which I have been writing far longer than I have any higher-level language.
The late Jon Postel once said something to the effect of “be liberal in what you accept, and conservative in what you emit.”  Making an assembler be liberal in what it will accept can be a challenge, and there is an argument supporting the insistence that a 6502-family assembler follow the MOS Technology/WDC assembly language standard—which has existed since the 6502’s genesis.  If one standard is followed, interchangeability will also follow.  Minor deviations are usually tolerable, even to old fuddy-duddies such as me, but gross differences are not, especially differences that are the result of nothing more than wanting to “be different.”  In other words, one should not let one’s ego override good design.

I'm a bit late to the party, but welcome Virtual1, well done in constructing and thanks for sharing your unorthodox assembler.

thanks! I'm a big fan of "working with what you have". Most people either have Excel or use one of the free alternatives. And for simpler projects or patches, this might be enough to get the job done, at no additional cost to them.

Not 6502-related, but ... I once regularly used Excel as a source code editor. Because it was the best tool for that particular job.

It's just a derail... don't feed the trolls.