So like, the thing that immediately jumped to mind seeing this is that if you're trying to write assembly for insertion into an existing program having it basically live assemble into byte representation as you work on it is pretty damn valuable for iterating on code while working under space constraints (esp. common on 6502).
It'd be nicer to have this kind of thing integrated into an editor (like vscode) with a live updating view of the assembled code, but I can definitely see myself using this.
>"if you're trying to write assembly for insertion into an existing program having it basically live assemble into byte representation"
This sounds interesting. Could you elaborate on what is meant by "live assemble into byte representation"? What exactly would the workflow be under which you would be doing this?
So imagine you're writing along in high-level language, that doesn't have a built-in assembler. But it does have the ability to store data in memory, and the ability to jump to a location namely the beginning of that data.
That is basically the native environment on many 6502 computers. You have basic, and usually you can call, or something to run a little machine language.
What you don't generally have is an assembler, unless you're on a BBC micro or something really spiffy like that.
You can open the spreadsheet, take me to origin, Constance a few instructions, and there are the bikes you need right there. It might be an 10 bytes or 20 bytes.
So you just typed them right in set up your call statement and carry on.
On these older or smaller computers, people do these kinds of things to get a little bit of speed, but they don't have a huge tool chain, or don't want to complicate call chain get that speed. Really they just want to tell the CPU to do a few things to be done with it.
Another case might be patching a piece of code.
So you reach a point where you need to code up a jump instruction, and then assemble the few instructions you need to make whatever changes going to make, and it returned so that the program may continue.
Open the spreadsheet type in the few things you need copy the bites done
You do have machine code monitors available for a lot of these computers, though. E.g. on C64, if you want that workflow you'd almost certainly have a freezer cartridge that almost universally had a machine code monitor built in.
You'll also have full macro assemblers with built in editors that'll load nicely out of the way that only becomes an issue if you're seriously RAM constrained.
This is really about a single environment that will just assemble a program that will run on that CPU, and it will do so in a really really super accessable way.
There are times when dealing with 6502 computers, and I honestly many small computers, or you just want a little tiny bit of machine code.
Now that said, people have written nice libraries with this thing, that can be called from the basic on Apple 2 for example.
> trying to write assembly for insertion into an existing program
Ah, all that was old becomes new again. One of my projects in university (35 years ago) was to write a pop-up 6502/8080 assembler for DOS. It hooked into the bios keyboard ISR, in a similar way to Sidekick (anyone remember that) and would assemble any code typed into the window on the fly.
The use case was to insert inline assembly code into high level languages without having to leave the IDE/editor.
It'd be nicer to have this kind of thing integrated into an editor (like vscode) with a live updating view of the assembled code, but I can definitely see myself using this.