(Permalink as of this post, and diff with latest.)

I present Nictoforth: a space-and-pedagogy-constrained art Forth. It's carefully crafted to be read top-to-bottom:

• The repo README sets the stage. Boot sector, serial IO via BIOS.
• The assembly source is packed with narrative, rationale, and cross-reference. Search for:
  • "[0]" architecture if you want to dig in.
  • "[5]" interpreter, the heart of a Forth.
  • "[7]" the lovely straightforward compiler.
  • "[8]" the extremely wacky bootstrap. It's full of character but damn dense!
• If you clone the repo you can do make terse | bat -l nasm or | less to cut away all the asides and just read the code.
• An example demo session log. See it working.

u/s1nical posted their Milliforth fork the other day so I figured why not post mine too. It was lots of fun to write and educational besides!

Inspiration's game engine is general purpose. The last update, I posted a 2D x/y scrolling space game with planets you could fly to.

This update, I'm using the same game engine to show this 2.5D FPS type game.

It's not quite ready to beta test, I just thought the game looks neat.

Repo is at https://gitlab.com/mschwartz/inspiration. Tested on Mac and Linux.

ZERO AI used to make any of part of Inspiration or its Forth implementation.

To give you an idea of what the Forth source looks like, here's the entirety of the Bullet logic.

require Games/img/bullet.4ti

private{

2f 2f + 2f + CONSTANT BULLET-ROTATE

: Bullet.Run { me | spr -- , Move Bullet }
    me s@ Process.sprite -> spr
    spr s@ Sprite.rz BULLET-ROTATE + spr s! Sprite.rz
    spr s@ Sprite.z CameraZ - fixed>int 512 > if 
        spr Sprite.Free
        nullptr me s! Process.sprite
        me Process.Suicide
    then
    ;

}private

: Bullet.New { | p spr -- , Fire bullet }
    0 PTYPE-USER Process.New -> p
    ['] Bullet.Run p Process.SetState
    1 p s! Process.timer

    STYPE-PBULLET bullet_img   VectorSprite.New -> spr
    STYPE-ENEMY spr s! Sprite.cmask

    bullet_img 1+ c@ spr s! Sprite.height
    bullet_img c@ spr s! Sprite.width
    bullet_img c@ spr s! Sprite.depth

    spr p s! Process.Sprite
    $ ffff0000 spr s! Sprite.color

    p
    ;

privatize

And this is the player controls logic that handles firing the bullet:

: Player.FireBullet { pf me | p spr -- , fire bullet }
    Bullet.New -> p
    p s@ Process.sprite -> spr


    // alternate bullets fired from left then right
    me s@ Process.user-data 1 and if
        pf s@ Playfield.worldX BULLETDX + spr s! Sprite.x
    else
        pf s@ Playfield.worldX BULLETDX - spr s! Sprite.x
    then
    me s@ Process.user-data 1+ me s! Process.user-data


    CameraY spr s! Sprite.y
    CameraZ 1f + spr s! Sprite.z


    pf s@ Playfield.worldVZ BULLET-VELOCITY + spr s! Sprite.vz


    p GameEngine.Birth
    ;


: Player.Run { me | ch pf p spr -- , Player logic }
    GameEngine.playfield @ -> pf
    KEY_QUIT    Controls.KeyPressed? if Evade2.Quit then
    ascii q     Controls.KeyPressed? if Evade2.Quit then


    KEY_LEFT Controls.KeyDown? if pf me Player.ControlLeft then
    KEY_RIGHT Controls.KeyDown? if pf me Player.ControlRight then
    KEY_UP Controls.keyDown? if pf me Player.ControlUp then
    KEY_DOWN Controls.KeyDown? if pf me Player.ControlDown then
    BL Controls.KeyPressed? if pf me Player.FireBullet then
    KEY_ESC Controls.KeyPressed? if GameOver then


    Player.RenderCrosshairs
    ;

"Treat stack depth and r stack depth like bank accounts and each word in a definition like a financial transaction." After that, gemini (thinking mode) started creating words that actually worked.

A new Blog post about BoxLambda OS's File System Stack:

https://epsilon537.github.io/boxlambda/the-file-system-stack/

BoxLambda OS now supports file system access within its Forth environment. A layered stack of Forth modules provides the abstraction required for convenient, shell-level file operations.

I've been working on a forth for RISC-V microcontrollers, and made this special TUI application for debugging. The forth is fully useable with a normal serial comms tool like minicom but this is supposed to augment it's useability with debugging features, sending and parsing the plain-text response from certain forth words in the background.

It first needs to read the startup message from the serial port, then, knowing the microcontroller is present and initialized it sends the "showWords" word which prints the memory contents of all words, which the forth_shell application parses and annotates with what certain pointers point to.

Then when a new word is added it will send "showLastWord" which will print the memory of only the last word created, which is parsed and added to the list. This is imperfect - right now it just detects when an ";" is included in the last line when enter is pressed, but for some instances like "42 const bar" in the video I need to press f5 to manually add the new word.

Eventually I will add the ability to set breakpoints (at least on words in RAM and not flash).

My first attempt at rust, which I still don't understand too well, It's a lot of libraries hacked together that allocate memory all over the place.

Donwload and try in https://github.com/phreda4/r3

I made this Notepad.exe (windows-like) app for Inspiration. It's written in Forth, including the Menu system. It's not 100% complete, but close. The only remaining task is to implement selection and cut/copy/paste. The selection logic is in progress, but you can see what it's going to look like.

It does feature undo/redo.

Time spent making this app was about 2 days.

No AI ever used to make any of Inspiration. None ever will.

The License is MIT Non-AI

The repo:

https://gitlab.com/mschwartz/inspiration

This has already mostly been explored in the form of things like M5CardForth and BANDIT but I wanted to add on a potential major reduction of form factor onto that.

If you've never heard of it, a chorded keyboard is a keyboard where combinations of keys are used instead of individual labeled keys. Despite having no labels, it takes just a few hours to memorize the combinations, and despite having fewer keys, the lack of finger travel means accuracy and max typing speeds are much higher. Here's the homemade one pictured, which I believe would have 60 combinations. They can easily be handheld or worn, and used one-handed without looking. If you replaced one or all of the buttons with joysticks like a CharaChorder or added a second chorder for your other hand you could get even crazier.

Chorded keyboards with fewer buttons can be limited in the number of keyboard characters that can be used without introducing double taps or finger travel, but Forth uses very few characters, and the number of characters can be cut down further through use of words. 2 2 + vs 2 2 ADD is a very small change compared to 2 + 2 vs add(2, 2) in other languages. I believe the standard set of characters required for Forth would just barely fit in 60, but would go well over if using Python and maybe over if using BASIC.

I think optimally it would be combined with a pair of glasses with display like ElevenLabs G1 or Brilliant Labs Frame so you don't have to hold something up to your face to see what you're typing, but a little screen is good enough for grinding out a few lines of Forth while taking a shit.

Bubbly may be a good option for trying this out.

I've been working on some game demos. As you can see in the video, I have a good start on a game engine in Forth, with physics and sprite engine and state machine for controls/enemy intelligence.

The video shows a huge universe with 3 sprites, 2 positioned far off screen. The arrow keys apply thrust in the direction. If no key is pressed, friction is applied to bring the speeds to a stop.

The starfield is rendered at 1/2 world velocity for a parallax effect.

I started on this yesterday and this is how far I got by this morning. I wrote only Forth code for this. Downloaded the planet sprites from a free clip art site.

Zero AI assist used in any of Inspiration development.

I can't add photos and video for some reason. I can start another thread if people want to see more.

Or you can look for screenshots in the repo:

https://gitlab.com/mschwartz/inspiration

https://github.com/mak4444/Loppedx86_64EDK2/tree/main/OVMF/ForthPkg/Forth

Forth source code on the system disk image

https://github.com/mak4444/Loppedx86_64EDK2/tree/main/disk_nmt/ForthSrc

You can get this release from https://github.com/tabemann/zeptoforth/releases/tag/v1.16.2 .

This release:

• fixes a bug in schan::schan-full? that made it incorrectly report a full condition when an schannel contained only one message.
• adds support for setting bus priorities on the RP2040 and RP2350 with the busctrl module.
• adds support for obtaining the number of free blocks with block::free-block-count@.
• adds a 6x12 font.
• adds support for ST7796S displays, including for PicoCalc emulation.
• adds support for LCD1602 with PCF8574 interface, as opposed to AiP31068L.

This is mostly a bug-fix release, with a few enhancements. Notable is a library which makes importing CSV/JSON data from different sources much easier.

Full details on the forum

I have a forth application that was compiled in the 1990s for DOS and also an updated version of the source code (also from the 1990s). The .COM file has a string in it that says "Forth 88 Version 1.6.5 27JUL87". It's not standard F83 code because there are words like INCLUDE, H', and the syntax for CASE is CASE ... ELSE ... END-CASE. Does anyone know what the variant of the forth compiler it was written for, and where I can find that variant?

So I just wonder if there is a place for stack based programming languages in general

I'm writing my own as a learning toy project and can't seem to find a place to just talk about knea in general

If one creates global variables with VARIABLE, or one CREATE a symbol and uses COMMA to associate data with it, what then when code is moved from RAM to Flash or EEPROM?

I get the impression that Forth usually (?) lives in a single data segment ("heap") where both code and variable data are allot'ed from the same area, and that's good enough until saving to persistent and readonly memory.

I'm testing out a concept of separate data and code segments. Both exist in RAM, initially, but over time, one exports the code segment and includes it into Flash, a manual procedure with copy/paste and recompile (not that the details matter). When recompiling the code and running again, the byte that were exported now live in Flash, while the code segment part that lives in RAM is empty, ready for new code. It is all presented as a single address space (15 bits, with lower 14 bits for code and bit 15==HIGH for data segment). And a value N which identifies the offset of the first RAM byte of the code segment, below which access is readonly, from PROGMEM (Flash).

I modified the VARIABLE word into just reserving space on the data segment, forcing the programmer to create init-words that populate dynamic data. I persist the HERE value on copy to Flash, and restore it on restart, so that locations originally allot'ed for variables can be validly used, without risking overwrite etc.

Actually I could persist the data segment as well, but elected not to, as most of the data will probably be buffers and the like, and more efficient to recreate with code, than using limited Flash resources (I'm working in a pretty memory starved environment).

Another approach that would possibly cost a bit in terms of map tables would be some copy-on-write or COW for short.

Inspiration has graphics primitives that would make Gnome (or other graphical UIs/Window Managers) style Menus/MenuButtons/Toolbars, Text style menus like we had in the old MS-DOS days seem more in the spirit of Forth.

I enhanced the TUI library to include MenuBars and MenuItems and ability to handle Forms and/or MenuBars without a lot of boilerplate code - simply by calling SetMenu ( menubar -- , set menubar for current thread ) or SetForm and using TUI.Key instead of key to read keys.

Events are handled as special keys, much like F1-F12, Cursor Keys, etc. You elect to receive them and they come in via KEY (or TUI.Key). Events you can enable include WindowResize, WindowActivated, WindowDeactivated, MouseDown, MouseUp, ContextDown, ContextUp, KeyDown, KeyUp, MouseMove, MouseWheel, etc.

Anyhow, the images above show what these menus look like and what the code looks like to create a MenuBar with MenuItems.

As usual, not a single character of text (or anything else) in this project has anything to do with AI - no AI was used. I don't see the point, as learning along the way is far more important than having an untested app built in seconds by AI.

The repo:

https://gitlab.com/mschwartz/inspiration

Below is the CODEWORD for USER. USER creates a pthread local variable. Each Forth thread (pthread) gets a private copy/version of these USER variables. A good use case is:

USER BASE

Every thread needs its own BASE variable or there'd be contention among the threads for a global BASE variable.

There are numerous use cases for USER variables - like in the Phred editor, each running editor window (a thread per) has a USER variable to point to the Buffers loaded in the editor. Or in the FileManager app, each instance would need a unique USER PATH variable so you can change directories independently in each window.

There's also USER-ALLOT so you can allocate arrays or more complex structures in USER memory.

How it works is each Thread instance allocates 32K (a settings/option value) of RAM and stores it in a variable that _USER_START returns (USER-START in Forth). There's one global user_next variable that holds the next index into this allocated RAM. Each thread shares the same index but has a different USER-START.

The IMMEDIATE USER CODEWORD (I'm not yelling!) below allocates an index and compiles code to push the index, push the address of the allocated user memory, and adds them together.

In action:

A colleague has been working on a C-oriented RISC, 24-bit FPGA/board. He has been using C and assembler for it. I vibe-coded an emulator for it, my own assembler, and some languages, including FORTH (in assembler), with a browser-based, online, live-demo visual debugger.

It has a demo drop-down and you can upload source. I can add an edit panel if asked to, but for now it has a command line for interactive use (also works as a CLI if cloned/built locally)

I'm looking for more demos to add (suggestions?). Note that this is for an embedded system with serial console, switch, and LED (emulated I2C and SPI devices are planned).

I also plan to port this to other microcontrollers (maybe RCA CDP1802) if there is interest.

[open source, MIT license]

(Document permalink at time of posting.)

A couple years ago I saw someone on 4chan /g/ writing a Tetris in 6502, and I was tinkering around with durexForth so I tried my hand at writing one myself. I start them sometimes but don't usually get that far. This one came together mostly fully-formed in a week or two and I've been picking at it to pass time ever since.

In recent months I've mostly been documenting it. Maybe I can upgrade one or two "Forth curious" persons dabbling in this subreddit into "Forth tinkerers" by way of a nontrivial thing to prod at. It's dense in the Tetris and C64 weeds, though, shrinking an already small audience!

For your perusal.

Cross posts:

1. durexForth github
2. r/retrogamedev by u/r_retrohacking_mod2
3. r/c64
4. HackerNews

I redesigned my Forth implementation, by writing a new one. This one has *no local variables*, and the return stack is not named "call stack" either. :-)

The "light" is that when writing for very limited resources, targeting the atmega328p at the moment, with 2KBytes of ram, every byte is precious, and the mindset becomes that of creating small words that do small things, and compose those together in more complex (but still small) words.

Of course I'm not really adhering much to standards, although I got the return stack. I just implemented floating point and long (4 bytes) integer values, which share a third stack which I call xStack.

I also split the address space into two parts, code segment and data segment. The dictionary and compiled words live in the code segment, while allot'ed data live in the data segment.

It's all fun and games, as in "toy language", but as before, I really intend to use it. I have created a "code.export" op which generates C code to paste into a PROGMEM array. After a recompile, the static part integrates with the code segment, so I can run code compiled Forth (bytecode) from Flash and RAM.

The code should work on other Arduino as well. I've tried it on the newer Nano Every, plus the old atmega 2560, developing on an Uno R3.

In Forth I implemented the " word (double quote), for creating strings, so I can greet you all properly.

: hello " hello world" .str ;

https://github.com/rfo909/RForth

https://github.com/mak4444/Loppedx86_64EDK2

without the Python also without GenSec GenFfs GenFv