Native is always best but developing natively means your dev env - assembler/compiler/debugger - must live in the same address space as your target program. Things were super tight keeping your assembler/monitor and code lived in 8’16k total.
Very true. On my 6809-based Radio Shack Color Computer 1, I'd upgraded to 16KB by the time I got into learning assembly which made it less tight - especially since writing even a 1KB program in 8-bit assembler took a long time. 6809 assembly code could be even more byte efficient than 6502 or Z80 due to its indirect addressing modes, multiple 16-bit registers, etc.
One option that made tight memory much more workable was Radio Shack selling an editor/assembler on ROM cartridge, so it didn't take up any RAM for its own code (with the catchy name EDTASM+). Odd to recall there was a time you could pop down to the local neighborhood store and pick up an assembler.
Obviously, all of these tools were primitive by later standards but it all worked quite well and I spent countless hours using it. I later upgraded the Coco RAM to 64K then added a floppy disk drive (quickly followed by a second floppy). This allowed me to use the disk based version of EDTASM+. All that memory and storage. It felt like living in the future :-).
One option that made tight memory much more workable was Radio Shack selling an editor/assembler on ROM cartridge, so it didn't take up any RAM for its own code (with the catchy name EDTASM+). Odd to recall there was a time you could pop down to the local neighborhood store and pick up an assembler.
Obviously, all of these tools were primitive by later standards but it all worked quite well and I spent countless hours using it. I later upgraded the Coco RAM to 64K then added a floppy disk drive (quickly followed by a second floppy). This allowed me to use the disk based version of EDTASM+. All that memory and storage. It felt like living in the future :-).