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.

Recently published this video about how I explore JONESFORTH using a gdb trace file:

https://youtu.be/giLsd-bik6A?si=t7E-OwKJLYffHKcs

this is an interesting minimal implementation - how does it compare to other forths?

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.

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

It sounds like OKAD [1].

In my very modest experience, I once wrote a system that I could boot from a floppy, edit, then recompile. For this I needed to make an assembler, or rather I was willing to meet the challenge of writing an assembler for the 8086, which was notoriously difficult (not really for the subset I needed, which did not include the complex addressing modes for one thing).

When it came to writing the changes on the floppy I was very scared to trash my hard disk (writing to HD or floppy was just a value in a register when you use the BIOS API), but fortunately I found an old Toshiba laptop that had an external power-on switch for the hard disk! That thing was running at 10 Mhz in "turbo" mode!

Bottom line: I spent a lot of times reading the ISA specs, write the assembler in Forth, and compare/check its output with an actual assembler. It would have been more efficient to enter directly the instructions in hex, I think, except maybe for the boot sector.

[1] https://www.ultratechnology.com/okad.htm

If you read the colorforth source (there’s only around 1000 instructions of assembly, it’s not a long read), there’s a real sense that much of the design (pretokenization, color tags, etc) are built around the punchline of a single (with rep prefix) instruction being used to linear-search the dictionary — going to trivial hardware-supported data structures here constrains the implementation a bunch, but there’s magic in self-imposed constraints.

It does. I am certainly no Woz, but I used to program a KIM-1 by hand assembling with pencil and paper from a programming card, then keying hex codes into its onboard keypad. After a few days you don't need to look at the card much. It's really quite practical - it's actually easier than dealing with editor and assembler tools. After fifty years, I still recall that A5 encodes LDA.

I can’t weigh in to the Moore story, but I loved reading “Bootstrapping” series by Compiler Crimes.

https://compilercrim.es/bootstrap/

there's a similar story by kragen on .. hmm HN or maybe SO where he describes a bootstrapping from a micro hand crafted asm monitor to forth to more and higher level languages. "stuck-in-a-basement" kindof challenge.

It sounds like OKAD [1].

[1] https://www.ultratechnology.com/okad.htm

Recently published this video about how I explore JONESFORTH using a gdb trace file:

https://youtu.be/giLsd-bik6A?si=t7E-OwKJLYffHKcs

this is an interesting minimal implementation - how does it compare to other forths?

I can’t weigh in to the Moore story, but I loved reading “Bootstrapping” series by Compiler Crimes.

https://compilercrim.es/bootstrap/

Agreed, though I would say that 6502 is a lot more straightforward to memorize than x86. A lot fewer addressing modes and every instruction is always just a byte, possibly followed by immediate data. The 6502 was a little gem.

PlanckForth: Bootstrapping an Interpreter from Handwritten 1KB Binary

This project aims to bootstrap a Forth interpreter from hand-written tiny (1KB) ELF binary. This is just for fun. No practical use.

How to build

Only xxd is needed to build PlanckForth.

$ git clone https://github.com/nineties/planckforth.git
$ cd planckforth
$ make
xxd -r -c 8 planck.xxd > planck
chmod +x planck

Implementations in other languages are in others.

Hello World

The hello world program at the beginning looks like this.

$ ./planck
kHtketkltkltkotk tkWtkotkrtkltkdtk!tk:k0-tk0k0-Q

After bootstrapping by bootstrap.fs, it looks like this.

$ ./planck < bootstrap.fs
." Hello World!" cr

bootstrap.fs can also take a file as an input program like this.

$ cat example/fib.fs
: fib dup 2 < unless 1- dup recurse swap 1- recurse + then ;
20 fib . cr
$ ./planck < bootstrap.fs example/fib.fs
6765

Running Tests

$ make test

Builtin Words

code	name	stack effect	semantics
Q	quit	( n -- )	Exit the process
C	cell	( -- n )	The size of Cells
h	&here	( -- a-addr )	The address of 'here' cell
l	&latest	( -- a-addr )	The address of 'latest' cell
k	key	( -- c )	Read character
t	type	( c -- )	Print character
j	jump	( -- )	Unconditional branch
J	0jump	( n -- )	Jump if a == 0
f	find	( c -- xt )	Get execution token of c
x	execute	( xt -- ... )	Run the execution token
@	fetch	( a-addr -- w )	Load value from addr
!	store	( w a-addr -- )	Store value to addr
?	cfetch	( c-addr -- c )	Load byte from addr with sign extension
$	cstore	( c c-addr -- )	Store byte to addr
d	dfetch	( -- a-addr )	Get data stack pointer
D	dstore	( a-addr -- )	Set data stack pointer
r	rfetch	( -- a-addr )	Get return stack pointer
R	rstore	( a-addr -- )	Set return stack pointer
i	docol	( -- a-addr )	Get the code pointer of interpreter
e	exit	( -- )	Exit current function
L	lit	( -- n )	Load immediate
S	litstring	( -- c-addr )	Load string literal
+	add	( a b -- c )	c = (a + b)
-	sub	( a b -- c )	c = (a - b)
*	mul	( a b -- c )	c = (a * b)
/	divmod	( a b -- c d )	c = (a mod b), d = (a / b)
&	and	( a b -- c )	c = (a & b)
\|	or	( a b -- c )	c = (a \| b)
^	xor	( a b -- c )	c = (a ^ b)
<	less	( a b -- c )	c = (a < b)
u	uless	( a b -- c )	c = (a unsigned< b)
=	equal	( a b -- c )	c = (a == b)
(	shl	( a b -- c )	c = a << b (logical)
)	shr	( a b -- c )	c = a >> b (logical)
%	sar	( a b -- c )	c = a >> b (arithmetic)
v	argv	( -- a-addr u )	argv and argc
V	version	( -- c-addr )	Runtime infomation string