I was thinking about DEBUG a bit ago. There's a story, it may even be true, that Chuck Moore bootstrapped ColorForth using just DEBUG and a floppy. Now, to be

I was thinking about DEBUG a bit ago. There's a story, it may even be true, that Chuck Moore bootstrapped ColorForth using just DEBUG and a floppy. Now, to be fair, you can develop in DEBUG with DEBUG, and an editor (EDIT.COM perhaps). Create "prog.txt" and C:\> DEBUG < prog.txt. Boom, "assembler". But I was considering what it might be like to have JUST DEBUG. You have DEBUG, you can load a file, you can write a file, but that's it. (So, no DEBUG < prog.txt). And how now, you're in a real "image editing" mode. You just have a blob (or blobs) of RAM that you can load and save to disk, and DEBUG with which to manipulate it. Saving images. How would one approach that? I was thinking, fundamentally, that I'd create "lots of subroutines", and have them all starting in a 16 byte "page" boundary, i.e. XXX0. If nothing else, this gives you a bit of buffer to expand a routine in place (maybe you'd use a 32 byte block size), without necessarily impacting the entire program. It would also make routine address stand out 1000, 1020, 1040...10A0, 10C0, etc. Cognitively (perhaps) a teensy bit better to manage than just random locations. You could write mostly PIC (position independent) code. And you can see, perhaps, how easily a Forth style can be adopted. Ideally, higher level code ends up being mostly JSR 10A0; JSR 20C0; JSR ... That's essentially what "direct threaded code" is. You could, to a point, almost make it straightforward to relocate an address. If you REALLY need to move 10A0 to 3440 (vs simply putting a "JMP 3440" at 10A0), you can hunt down whatever the JSR opcode is, followed by your address. Odds are, thats a routine to monkey patch. It's an interesting thought experiment.