A home-brewed 16-bit real mode OS made for the i386/x86 architecture that bootstraps itself into a complete FORTH environment.
Reactions: cyber ×5 (tanuki, Chowder, DoomHammer, Arek, sroka)
It can boot from a usb (or technically any other common storage devices, like hard disk or floppy, but I have not yet been able to test it physically) on any devices that have Legacy BIOS supported.
It has access to 64KB of addressable memory, but I plan to support up to 1MB when the need arises through the used of segmented registers.
The kernel itself is entirely written in assembly in ~3kb, but I plan to slightly reduce its size by offloading more of core words (functions) into the FORTH source code itself.
Currently the boot flowchar goes like this:
- bootsector: loads the kernel and FORTH source code from the storage device into RAM, then jumps into the kernel to initalise a working FORTH enviroment.
- the FORTH interpreter reads from the source code to finish initalizing the rest of the environment
- at the end of the source, if the QUIT word it read, it falls back into a REPL (read–eval–print loop) for debugging, development of programs, interacting with hardware, reading and writing blocks of memory, etc. essentially this is the shell of this OS.
This is a STC FORTH (Subroutine Threaded Code), which allows for some clever trickery and simplicity of inlining native machine code into FORTH words. When words are called, they are no interpreter loops. More on this here: https://www.bradrodriguez.com/papers/moving1.htm
WHY?
The strive for simplicity. Modern software culture is complexity hell. There are weaknesses in layering abstractions upon abstractions endlessly. Who understands the entirely of Linux from bottom to top? Who truly and fully understands how GCC’s C compiler works? Let’s return to monkey and explore what a single person can do, how productive can they be without the complete generational dependency of programmers before them.
Reactions: 
×2 (sroka, bartykraus)
GOALS
- complete and clean up the FORTH kernel and core wordset
- text & hex editor
- a blocks memory system that can read from and write to disk
3.5 extending addressable memory up to 1MB via segmented registers - graphics engine:
4.1 driver for drawing pixels to the screen
4.2 sprite and tile system - audio engine:
5.1 interact with the 1-bit pc speaker for sound output (issue: all my emulators break at this point, ideally this is developed on real hardware)
5.2 means to produce different waveforms
5.3 means to combine multiple sound channels into one for playback
5.4 etc. basically a DAW (digital audio workstation)
example of what forth code looks like, running from the OS shell
update: refactored control flow words to save on memory and did some tests
update: memory dump
: dump ( n a -- ) $fff0 and swap >r begin nl> dup .X ." : "
8 >r begin dup @ .X spc> dup c@ >r? 1+ dup c@ >r? 1+ next
16 >r begin r>? next ." | " 16 >r begin dup $20 < if drop '.'
then emit next next drop ;
Ok, so I’ve just stumbled upon this thread and I have two things to say:
- You’re crazy. I love it.
- We ABSOLUTELY NEED to test floppy boot. I have the hardware. I think HS3 has some too, though not sure if it works
I would love to try out boot from floppy and using it as a storage medium. Older systems in general is what is project is intentionally directed at. Not that it can’t run on newer hardware thanks to the legendary backwards compatibility from Intel 
Reactions: ×1 (tanuki)
nasm was throwing some errors for me, so I had to fiddle around with the code a bit. Probably broke something, but hey, I managed to get it to run 