There's a legend (perhaps me misremembering, or simply making it up, thus making it a legend rather than an anecdote) that Chuck Moore did something like this that eventually ended up as ColorForth.

The story is simply that he started with MS-DOS, some floppy disks, and DEBUG. Starting there, he bootstrapped to being able to boot something from a floppy, and just pushed on from there.

Its an interesting development idea of simply molding a RAM image to your liking with little more than POKE, PEEK, BLOCKMOVE and READ/WRITE the RAM image. The assembler is a tasty treat, but hardly necessary, and perhaps not as helpful as one would like since while the mnemonics are nice, its the labels that give an assembler its real power.

I always visualized putting subroutines at 16 byte boundaries, if only to make the addresses stand out a bit in the hex noise, but also to give a little wiggle room to make changes without stomping on other code. Thinking how cautious one has to be, particularly on an MS-DOS machine, you have to be knowing one misstep, one stuck loop, and you're reloading from disk again. "Save early, save often". Plus that one point when you're in the phase of writing the floppy bootsector and you now, suddenly have a larger step to go from bootable primitive Forth kernel, to one that can self-host, even if it's just defining code words as blocks of hex numbers, forgoing an actual assembler early on. But, ideally, by that point, you're already comfortable with block of hex code, however now you don't have the benefit of a disassembler outside of the carbon based meat computer stuck in your head.

I think after a day or two of full immersion in this environment, disassembling hex code would be mostly straightforward. Woz is said to have 6502 binary memorized. It doesn't really take much, you don't need to memorize it all. Knowing a dozen instructions can take you a long way.

Anyway, always been an interesting thought exercise. Nice to see something similar. I like the primitive base Forth used.