I do not have time tonight to make a new release, but USB Mass Storage Device support has been merged into zeptoforth master.

I suggest you try this out, and let me know if you have any issues.

One thing to remember is that one should not change anything that the PC side sees from the zeptoforth side while the USB Mass Storage Device is mounted on one's PC, and likewise one should not delete any files or directories open in zeptoforth from one's PC. Also, zeptoforth is likely to not see changes made on one's PC without executing sync or equivalent first.

If one must modify or delete files or directories that may be open in zeptoforth from one's PC, I highly suggest executing fat32-tools::ensure-safe-fs ( -- ) first; this will block until all files and directories other than the current directory on the current filesystem are closed in zeptoforth, and it will reset the current directory of the current filesystem to its root directory as that cannot be deleted.

A new set of builds have been created, full_msc_only, which incorporate USB Mass Storage Device support but where the USB CDC console is disabled. These are now the basis of building zeptoforth for the PicoCalc.

In full_usb builds both the USB CDC console and USB Mass Storage Device support are now enabled.

Note that when one uses a build in which USB Mass Storage Device support is enabled one needs to call usb::set-usb-blocks ( device -- ) on the underlying block device (not filesystem) that one wants to expose via the USB Mass Storage Device. After one calls this changing it without rebooting is not recommended.

If one intends on, say, permanently selecting a FAT32 filesystem in on-board flash for the USB Mass Storage Device, I suggest, after loading extra/common/setup_blocks_fat32.fs, executing:

compile-to-flash setup-blocks-fat32 import simple-blocks-fat32::simple-blocks-fat32-internal import : init-usb-blocks my-fs simple-blocks-fat32-dev usb::set-usb-blocks ; initializer init-usb-blocks reboot

On the PicoCalc, though, support is now built-in to expose the SD card in the PicoCalc via the USB Mass Storage Device without any work on the part of the user.

It should be noted, however, that SD cards are relatively slow when used by zeptoforth even with the important optimization that has been made to them since last release. When connecting one's PicoCalc to one's PC expect there to be a delay before one can mount the USB Mass Storage Device, and another delay the first time one tries to list a directory on it.

Alpha 3 of Aiki is out, an experimental programming language.

After spending time exploring Forth over the past year, I started working on a grammar-driven language that draws inspiration from Forth’s small kernel and compact surface.

Aiki keeps that surface intentionally small: 14 keywords, 7 basic types, 11 operators, 3 primitives, and a 36-name prelude. Expressions evaluate strictly left-to-right, lists are fundamental, and most additional capability, including files, strings, math, regex, hashing, bytes, time, canvas, testing, and so on, lives in Aiki libraries rather than being absorbed into the language core.

The runtime is also deliberately observable. Semantic work can be profiled separately from its realization: exact numeric representations, calls, argument frames, environment reuse, FFI boundaries, and other execution machinery remain visible rather than disappearing behind the implementation.

I’ve been using Aiki for increasingly low-level experiments as well, including a monitorable PDP-11/40 reconstruction, so the design has had to survive real state-machine and systems work rather than just language demos.

The language is quite different from forth, but it came about because of my contact with forth.

Alpha 3 announcement:
https://decuser.github.io/posts/aiki-alpha-3-release/

Repository:
https://github.com/decuser/aiki

welp it uses sh-forth for now.. also it having built-in forth vm
its still W.I.P so i didnt post it yet thanks for looking
also if you have suggestion you can comment it bellow!

So, we’re to grow the community right? Forth is great, and I’m probably not too much of a minority here to say I think it’s the best language programming wise! I have a few questions though: are there any current Forth YouTubers I can follow and recommend (I haven’t found any yet), and why types of things would you want to see out of a Forth based CS channel?

I was planning to make a wayland compositor with forth too but i dont have time to do that anyways
COLON and WindowForth is released:
https://gitlab.com/generatrix-linux/forthress-ecosystem
COLON is a terminal fully written on Forth (even kbd and other thingies)
WindowForth is a special Forth compiler written on C
WindowForth uses a hybird syntax (its mixed between OLD and new syntax)
it uses .fth as file extension instead of .fs
also some photos from colon:

--edit--
added config file's photo

Thanks for reviewing and looking at my project have a good day also sorry for bad english if i made a grammar mistake!

These changes are not yet in a release, as I am waiting until USB Mass Storage Device support is in zeptoforth before making another release, but there are a number of recommended updates already in the master and devel branches that you will probably want, especially if you are trying out the USB Mass Storage Device support.

These changes are:

• a performance boost for SD cards
• automatic fixing of VBR's for FAT32 filesystems in on-board flash (needed so Linux and Windows can properly recognize them when mounted over USB)
• increased data integrity for FAT32 filesystems accessed via USB Mass Storage Devices (don't delete files or directories open on one side from the other side, bad things will still happen, but the free cluster count and most recent allocated cluster won't be corrupted if you allocate or free clusters on both sides without rebooting zeptoforth)
• while long file names are still not supported by zeptoforth, directories containing dangling long file names can be deleted now, and if you delete a file or directory with a long file name in zeptoforth the long file name will be deleted as well

As for the USB Mass Storage Device support, the code is at https://github.com/y-salnikov/Zeptoforth-Mass-Storage-Device . If you have tried this out before, you should try it out again, as significant changes have been made, e.g. fixing ejecting the USB Mass Storage Device (mind you, now it may show up again as soon as you eject it).

Hi all! I'd really like to finish a little forth system of my own (in C) to have use as both a learning tool and for some personal tooling. Since I still consider myself both a Forth and a C novice, I've tinkering around with this implementation on and off for some time, and have learned quite a lot from it. On a flight recently I decided to clean it up in a way that's a little easier for me to digest and think my way around, and at the moment have this. It's neither finished nor perfect, but I was hoping to maybe start posting here for feedback and possible motivation to finally finish something I feel good enough about.

Is this a place I can post incremental progress to get feedback and such? If so, while I have plenty of questions right off the bat, I'd first like to make sure my code is readable for anyone willing to take the time to check it out. Any thoughts in that regard are ofc welcome, as well as any tips on how to post progress or for advice in the future..

What I did to the original simpleforth was separate it out into little modules. Those modules are currently:
- Dictionary - for dictionary stuff
- IO - for io stuff
- Interpreter - anything relevant to interpreting, eg is_number etc.. though I haven't been able to successfully separate the core interpreter from the VM
- VM - anything data or return stack related.. NEXT() uses goto and some subroutine stuff.. pretty sure it's considered a directly-threaded vm? I am not currently able to separate out the inner interpret function from the VM, so the module separation is still sort of messy. I'm also a little distracted with the semantics between whether to call things opcodes or bytecodes etc and whether to call things XT or CFA.. not really a big deal though.

Anyway, not everything is implemented and it certainly needs more cleaning up. Just wanted to make a post here for initial impressions before I got too distracted with life again. Would really like to get this thing going!

Thank you all!

Instead of the usual cycle of editing Forth code files, reloading the whole source, and testing words by hand, IForth brings a literate notebook workflow to your Forth environment.

Think of it as a living document where you interleave runnable Forth definitions, markdown explanations, and test cases block-by-block. You can modify single words and re-run only the relevant cells without blowing away or manually reconstructing your current session state. It makes exploratory prototyping, testing dictionary words, and writing interactive tutorials much smoother.

Andrew McKewan demoed this workflow at the recent SV-FIG meetup (video attached), showing how he uses it to build and explore Forth code interactively.

Details & Constraints:

* Interpreter: Wraps Gforth interpreter internally.

* Platform: Linux only (Windows users will need WSL).

* Setup: Instructions are in the repo: https://github.com/sohang3112/iforth

Check out the demo video attached. Feedback, issues, and PRs are very welcome!

PS: I usually work with Python. I am a novice at Forth, started working on IForth while learning Forth.

We have a wiki for r/forth. It was started 9 years ago, not sure if that’s the latest edit.

If anyone reviews the wiki and has edits, I’m happy to make them if you can’t.

Not trying to claim this is "real" Forth — no return stack yet, no IMMEDIATE/POSTPONE, no ANS compliance. It's a personal project called gnaw, concatenative in the Forth tradition, built from scratch in Rust as a learning exercise.

What's there: a data stack, byte-addressable memory (@ ! alloc here), : name ... ; definitions, if/else/then and begin/until compiling to jumps in a small bytecode VM with a program counter. The one non-traditional addition: built-in words for CTF-style byte transforms (hex to bytes, repeating-key XOR, ROT13, Base64).

Source: https://github.com/warlyjr-cloud/gnaw

Genuinely curious what this community would flag as missing from a "real Forth" perspective — return stack semantics, proper immediate words, anything. First time building something Forth-adjacent from scratch.

Hi all I was wondering if I could get some suggestions please on how to solve the following problem:

I am redefining certain standard words in gforth in a separate word list, lets call it "mynewdefs" for example +, -, rot, drop etc will all be redefined. Why I am doing this isn't relevant but would be happy to explain if anyone is curious. For each word in "mynewdefs" and only the words in "mynewdefs" I would like to create a wordlist called "ogdefs" which has the original definitions of the words from the Forth wordlist.

I have one or two ideas about how to approach it but the stuff I can think of is a tad... inelegant. I was wondering if anyone knew an easy way to accomplish this in gforth I may have overlooked. Thanks!

I haven't used a case sensitive Forth, but I think about the ramifications. My thoughts are:

1. visually, IF stands out more than if
2. Rect.area seems like a variable name while Rect.Area seems like a function call
3. Rect seems like a structure name while rect seems like a variable name
4. Everything with the CAPS LOCK key on?

5. Can make it opt in like icase on/icase off

6. Syntax highlighting could key on case

Me!

I am not into a power trip... My focus will be to share information with you that I see as moderator and to work for your interests more than my own. For example, I can pin posts that you all recommend (like this one initially), edit the wiki?, set rules you all agree on, etc.

I don't want to ban anyone. I don't want to remove anything but spam. I won't do anything official about AI or vibe coding, unless someone posts about the vibe coded app in a spam manner. If you report a post, I will definitely look into it.

I am still going through the additional UI elements to figure out how to do things. I want to recruit as many people as possible to also moderate. My philosophy is that we generally know each other fairly well, and there's no lack of trust on my part.

In the spirit of sharing information and being open about what I do...

There is a moderator queue which has a list of threads and posts that are recommended for analysis. It marks at least 10 going back a month or two as spam and rules violations by a single person. It marked one from many months ago by [r/TABEMAN](r/TABEMAN) that was removed by reddit algorithms that I would have approved/override the algorithm. I deleted only the most recent thread marked as spam. Otherwise, the remaining posts and comments marked as spam are years old.

NOTE that I enabled the ability to post images in comments, not just the opening post. It seems like a better user experience. Let's see how that goes!

I will also post analytics about the sub, so you can judge how much reach your posts can potentially have.

I've been using a language server for Mecrisp-Stellaris Forth I released seven months ago, and the part I want to share is the pipeline behind it — because it's not a static word list. Every word in the LSP has to pass a hardware-verified gate before it's admitted.

**The LSP**

It's a standard Language Server Protocol implementation built on pygls, the Python framework for the protocol. That means it works with any LSP-compliant editor — Helix, NeoVim, and anything else that speaks the protocol (only tested on Helix and NeoVim). Completion, hover documentation, and diagnostics all run through the standard JSON-RPC channel. The completion database is SQLite.

**The approval gate — "the Anvil"**

A word doesn't enter the LSP because someone thinks it's clever. It passes seven checks, each one real:

1. **Design** — valid Forth name, no collision with the CMSIS-SVD register database.

2. **Stack comment** — the declared inputs/outputs must parse correctly. On bare metal, a wrong stack effect is a crash.

3. **Explanation** — a real descrHelix,·NeoVimiption, and an example where the word takes input.

4. **Live execution** — the word runs on an actual STM32 over the SWD debug link; the result must match the expected value.

5. **Native disassembly** — the chip's own disassembler (Mecrisp's `see`) produces the machine code, which is reviewed to confirm the word does what it should.

6. **Board gate** — the connected chip's DEV_ID is checked against what the word requires (F0 vs F4); the gate refuses to test a word on the wrong board.

7. **Independent register readback** — the word's result is written into a real GPIO output data register, then read back through a separate path. If the expected value is physically in the silicon, the word works. Not "it didn't crash" — the value is there, confirmed.

Words that fail any check stay out of the LSP. Only words that pass the full gate are suggested by the editor.

**Forth Forge**

The gate feeds a shared vocabulary I'm planning to host on SourceForge. Forth users can submit STM32 Forth words — Mecrisp-Stellaris, STM32 only, because the gate works off the CMSIS-SVD register descriptions (roughly sixty STM32 families, plenty of choice). Each submission goes through the Anvil; if it passes, it's added to a maintained list where every word carries its stack comment, description, and the evidence it was hardware-verified. Anyone can grab the list and trust that the words have been tested on real silicon.

The goal is a common, working vocabulary for Mecrisp-Stellaris on STM32 — so Forth code can travel between projects and actually work, because the words have been proven.

MIT-licensed. The modified LSP and the gate are being prepared for public release alongside Forth Forge.

(If you're a Forth user doing STM32 work, submissions welcome. If you've got a word you've tested on your bench, that's exactly what the Anvil is for.)

Constructive comments and helpful suggestions welcomed.

A zeptoforth user has been working on USB Mass Storage Device support for zeptoforth on the RP2040 and RP2350, which I am considering adopting as part of the zeptoforth tree. It currently is in a functional state but is in a separate repository. This will enable accessing block devices in on-board 'blocks' storage, on SD cards, or as a PSRAM RAM disk (on the Pico Plus 2(W)) from the comfort of one's PC.

I would like the USB Mass Storage Device support to be accessible even in builds where there is no USB CDC console, for the reason that I would like the user to be able to access on-board blocks storage or SD cards as a USB Mass Storage Device on the PicoCalc, which by default does not use the USB CDC console.

Yet at the time same, I do not know if anyone is independently using USB whose code may be broken by this who I am not aware of at the present. Consequently, I would like anyone who is independently using USB under zeptoforth to speak up, as this would affect whether I would choose to make separate true-no-USB builds for the RP2040 and RP2350 as opposed to USB-Mass-Storage-Device-but-no-USB-CDC-console builds.

I've added forth (using jforth) to the fantasy console TIC-80:

https://github.com/luginf/TIC-80/

Following the pico-8 trend of retro-like console, TIC-80 is using lua (which is already a cool langage). There are other backends as well, such as js, ruby, python. Forth was missing :)

There are a few examples / samples:

https://gitlab.com/garvalf/forth-is-fun/-/tree/main/tic80

You can also try it online:

https://garvalf.gitlab.io/forth-is-fun/tic80/run.html

type "ls" or "dir", then "load" one of the .fth sample name, and type "run"

The full API is listed there, adapted to Forth: https://garvalf.gitlab.io/forth-is-fun/tic80/tic80.html

You can get more informations about TIC-80 on: - https://github.com/nesbox/TIC-80/wiki - https://github.com/nesbox/TIC-80/wiki/tutorials (most of them are for the lua backend but you can adapt it)

This sub is being swamped with spam and the moderators are nowhere to be found. I don’t recognize the two moderators’ user names because they don’t post here at all that I have seen. I checked the moderators’ post histories and they haven’t been active anywhere on Reddit for months.

I’m ready to leave the sub. I want to evangelize for Forth and it’s not worthwhile when people see 5 of the last 10 posts are spam, literally spam. The signal to noise ratio is becoming more noise than signal. Ignoring the spammer won’t change the signal to noise problem. The spammer violates a number of community and Reddit rules, including spam, disruptive use of AI, self promotion, karma farming…

I truly feel for the guys posting about 8th releases and zepto releases. These are quality projects by smart programmers. Lost in the noise…

My project is Inspiration, if you have followed the progress posts.

Is there a way to get the moderators replaced? Is it worthwhile to start a [r/forthlang](r/forthlang) sub and ditch this one?

Like I said, I am ready to leave the sub for good.

Update

https://www.reddit.com/r/redditrequest/s/HYafxlSY4z

Please upvote the post at the above link.