Hello, Stefan Karrmann <[email protected]> skribis:
> My hard binay seed is a monitor, which takes octal encoded octets (aka > bytes) as input, writes the octets in reverse order into the memory, and > finally jumps to the new code. It's size is: > > - for octal keyboard input on x86: 32 octets (!) > - for octal uninitialized serial input on x86: 34 octets > - for octal initialized serial input on x86: 41 octets > - for octal linux input on x86: 48 octets > > - for octet keyboard input on x86: 18 octets > This make sense, if we use the alt numpad input method. > > For those, who don't regard octal encoded octets as real source code, I > provide a second binary seed which implements a forth nucleus. I call it > itf or indirection table forth. > The sizes for this interpreter are much bigger than the sizes of the > monitors but still small in comparision to a boot sector (512 octets): > > - 75 octets for bios monitor on x86 > - **__81__** octets for bios standalone on x86 (!) > i.e. six of them fit easily into one boot sector! > For easier development we have: > - 102 octets for linux monitor on 32 bit x86 > - 101 octets for linux standalone on 32 bit x86 > > The bootstrap code in forth source code is still in its development phase. > I've compiled and tested the first colon words. The next task is a more > normal forth interpreter and a regular dictionary. This is truly impressive! I’m of those who don’t regard octal-encoded octets as “real source” :-), unless it’s short and comes with extensive comments (which is more or less what stage0 does, IIRC). The tiny Forth kernel remains super small though, well done! Thanks, Ludo’.
