Assembly language isn't that hard. I wrote a FORTH interpreter with a pretty good standard library in 3000 lines of 6809 assembly that pretty much worked right the first time.

Today you could spend as much time getting the build to work with npm or maven for something very simple.

Macro assemblers are nowhere near as much fun on the x86 (and other 80's era micros) as they are on something like the IBM 360 or AVR8 with a big register file... If you've got 32 registers you can write macros where the register names are parameters and avoid a lot of the meaningless activity involved in "calling conventions" in programming languages like C.

Was the FORTH interpreter for your own use or did you sell it? I ask because it's always fun to see someone on HN that wrote products I saw in the pages of Rainbow long ago.

It was for my own use.

It was unusual in quite a few ways. For one thing it was subroutine threaded which made it a little faster than most FORTHs, also it used self-modifying code in an inner loop to save a cycle in an important place.

Most FORTHs at the time used block-based disk I/O because you could do that without a real operating system and have some nice benefits such being able to copy a block of source code to the screen buffer to edit in place, easy memory allocation, etc.

OS-9 had a handle-based API for filesystem access basically the same as UNIX and MS-DOS 2.0 so my FORTH used that. OS-9 had a choice of text editors, including a vi clone so I didn't feel the need to embed an editor in the interpreter.

Everyone wrote plain assembly in those days. If you were lucky your assembler did nice things like symbolic constants.

It was a skill pretty much everyone knew.

It's fair to assume this is handcrafted and hand-optimized code, as machines back then were typically too small to use for many tasks. Any code generated would have added bloat making the whole project untenable.