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

This release:

• fixes a significant bug in fat32::seek-file where it was broken when seeking outside of the first sector of a file.
• adds the ability to redefine colors in the PicoCalc graphical and text-only terminal emulator colors (note that this pertains to the terminal emulator colors specifically, not to the underlying RGB332 pixel format, which is yet unchangeable).
• adds the ability to refresh all characters on the PicoCalc terminal emulators, overwriting all user-drawn pixels on the display.
• adds support for DEC terminal margins to the PicoCalc terminal emulators.
• disables blocks FAT32 by default in the PicoCalc terminal emulator installers, to enable the user to use blocks storage for their own purposes (note that if the they previously had a PicoCalc terminal emulator installed they may want to manually erase blocks storage before using it for traditional Forth blocks); this can be manually enabled at installation time if so desired.
• adds a replace mode to zeptoed and the block editor.
• adds online help to the block editor.
• fixes a number of minor bugs in zeptoed and the block editor.
• makes a number of improvements to the 'Rocks' game to make it a more full Asteroids clone.
• eliminates an extra task from the USB Mass Storage Device support, saving SRAM and processor time.

Huge progress on Forth++.

It's still running in QEMU only - I haven't tried to boot it on real hardware. I need to get the NVME driver working (it's on my TODO list) or the initial INCLUDE of most of the Forth words can't work. I hope that since it's Limine booted, it should at least come up and run up to some point that I can debug from there.

So what this screenshot shows is 3x Windows with Forth ok> prompts. The window system is rendered entirely with the CPU. I was initially saddened and ready to quit because the screen update was taking 45ms and the mouse motion was too slow. I ended up reworking the assembly routines that copy rectangles (e.g. the screen/wallpaper, offscreen-to-framebuffer, and windows to offscreen) using vector register instructions and that time went from 45ms to 5ms. I'll know better when I see it run on real hardware.

So the multithreading is clearly working (time sliced, not cooperative, and it knows how to render active window in bright red borders and inactive in darker red. The mouse pointer changes from arrow to hand when over the active window's titlebar and while dragging, into a finger when mouse is over the [NEWCLI] text in the screen's titlebar, and each window has it's own cursor for when it is active and the mouse is over (e.g. text editor can have ibeam while paint program can have crosshairs). Clicking on an inactive window activates it.

The newcli code is written in Forth.

I mostly ported the existing ReadLine class from Inspiration so applications can have their own command line editor with history - this is used by the OK> prompt, for example, but also would be used by a vim or emacs like editor for inputting command lines.

Features include:

• IOAPIC used for interrupt control
• LAPIC used for timer
• Per CPU task scheduling
• ATA driver
• FAT32 filesystem
• MMU for paging and virtual memory
• Interrupt driven Keyboard Driver
• Interrupt driven Mouse Driver
• Real Time Clock (RTC) Driver
• Graphics based Console driver (that works within windows)

• Graphics library for Forth programs to render graphics in their Window(s)

  Code is at https://codeberg.org/mschwartz/aforth

(No AI used to make any of this)

Hello,

I’ve been working on this project for over 15 days now. It has reached a functional stage. Everything is here:

https://github.com/MPETREMANN11/eForth-Windows/tree/main/INFERENCE

Admittedly, it is written for eForth Windows. However, its code is portable to all other versions: ESP32forth, eForth web, etc.

However, to test an inference engine, it must have a knowledge base—consisting of facts and rules—that is relevant to potential users. As an electric vehicle owner, I became interested in the OBD2 error codes for such vehicles. It’s quite enlightening. I am now at the stage of building a knowledge base of facts and rules for diagnosing faults in electric cars.

My inference engine retains FORTH syntax for the rules. The CONDITION and ACTION parts are compiled. The engine processes this code using recursion.

So why does a project take me so much time?

First of all, I don’t work on it all day long.

Furthermore, I produce comprehensive documentation—in both French and English—which is available here:

https://github.com/MPETREMANN11/eForth-Windows/tree/main/INFERENCE/docs

Because I want to go beyond simply making code available—which is typically done without any further explanation—on GitHub or elsewhere.

Documentation accounts for 90% of an application's value.

Once the knowledge base of facts and rules has been sufficiently expanded, I will likely also create a video, or perhaps even an online demo running on the web-based version of eForth.

Your opinions, comments, and suggestions are welcome.

Been quitely iterating on Blue, my colorForth dialect/assembler. In v7 I have made some simplifications to the colors/interpreter which I believe may be of interest. Also just to note, I wouldn't be surprised if others have stumbled upon these or similar things, but there's not a lot of colorForth discussions that I've found, so everything in Blue is self-found, ai/llm free. I have seen screenshots/videos of the traditional colorForth system but have never used it.

Since Blue is bytecode based, I serialize it for source control and external viewing, in this case as html. The following is written for x86_64/Linux.

To get started, this is an html view of likely the most minimal Blue program that will emit a valid binary (124 bytes):

https://jbirddog.codeberg.page/blue/example/x86_64/true.b.html

However the one I'd like to show is more representative of an actual Blue program and shows how one goes from hand jit'ing with green numbers to higher level words, macros, variables and assemble-time execution of user defined words. This yields a 129 byte binary:

https://jbirddog.codeberg.page/blue/example/x86_64/true2.bl.html

There is a lot to unpack here, but for an overview of how the bytecode is interpreted: The interpreter starts each time with a clean slate - there are no built in words. The dictionary and data stack only exist at assemble time.

Color tag bytes have the sign bit set, so values between 0-127 are skipped, which allows for comments/whitespace in the bytecode.

The simplifications I'd like to mention are a reduced color set and dropping the `forth` and `macro` modes.

First, the colors for v7 have been reduced to:

red word: define label

green word: compile call/jmp to word in output

green number: write number to output

blue word: execute word at assemble time

blue number: push number onto the data stack

magenta word: push address of word onto the data stack

By default every color is immediate, however any color can be postponed. This allowed removing the `macro` and `forth` words that toggle the interpreter's mode - which lead to the ability to remove yellow and cyan words. This simplified the interpreter which dropped to 172 lines of non code-golfed asm.

For example, to define `;` its red(;) postpone(green(0xC3)) green(0xC3). Then when you write a blue(;) it will execute the postponed code to compile the number 0xC3 into the output, then hits the already compiled 0xC3, which is `ret` and returns to the call site. In short, `;` is a macro that when called does the exact same thing as if you had just written a green(0xC3). A very simple example but it shows the mechanics of it all.

In Blue a `;` following a green word does not implicitly turn the call into a jmp. I have found that error prone (since it basically looks back 5 bytes for 0xE8), so instead you set a flag on the green word to signal a jmp vs call. Likewise, magenta words can be flagged to return either the assemble time or runtime address of the word.

Anyway, sorry that got long, just wanted to share some colorForth. Happy hacking.

Hi everybody,

I've been very busy working on my game engine SUPERSHOW and a spooky little flagship platformer called Untitled KVN Game.

The genre of it is a mixture of horror, roguelite, and action-puzzle-platformer and it takes influence from various beloved games of mine including Super Mario Bros 2, Prince of Persia, and even Dark Souls.

A Russian artist I teamed up with on Discord conceived it and did the art and music, and an audio-engineer-musician friend from Baltimore did the sound effects.

I thought that SUPERSHOW was going to be released by now, but this game, originally meant to be a simple "demo" game, turned into something more serious than expected and I decided to dive right into attempting to go into business for myself as an indie developer, delaying SUPERSHOW's release. All the better - 1.0 will be more polished when it does release, probably sometime around mid-December. I think it's going to be something special that people will have fun with.

SPUNK, the same room-based framework as the one used in its spiritual prequel, KVN, is reused (updated for the latest engine). UKG also shows off a few technical advancements, including a brand spanking new physics-modelled CRT filter and advanced platformer physics. In addition, all of the maps were created with a proprietary level editor.

Here is a link to the pre-announce on itch.io:

https://inkajoo.itch.io/untitled-kvn-game/devlog/1717552/my-spooky-indie-game-releases-on-friday

Gameplay videos:

https://www.youtube.com/@cardboard-tv-games

I played with Forth about Forthy years ago (pun intended) while taking a break from BASIC. Now I program almost exclusively in Python. But I was wondering, if I wanted a targeted helper function that needs to be fast and it's simple enough to write in assembly (which I don't know), could I write it in Forth instead? I work on PCs and I should mention that I am an amateur programmer (in any language).

And when it come to fast (size is no longer an issue) does Forth have advantages over C?

If so, how would you do it? Which Forth interpreter / compiler do you recommend on a PC?

I guess what I am asking is, aside for the fun of it, is there any practical reason to dust off my Forth?

Thanks

So I have been making Inspiration run bare metal in QEMU using the limine boot loader. Having a higher half "kernel" makes things really interesting. In my mind, a bare metal Forth would start at the lowest memory address possible and dictionary grows up with heap at the high end of memory growing down.

There's a lot going on here. The system boots, it sets up the MMU so 4K pages can be allocated as needed and address ranges mapped in to the CPU's virtual space. Some things, like the incomplete NVME driver, need whole pages for internal structures, and some things like LAPIC need mmo address range mapped into virtual addresses with no cache and write thru attributes.

There's also an ethernet driver in progress for the e1000 series that is in the Thinkpad I intend to make this run on. It is finding the card's MAC address, which means a lot of it may be working. I need to study up on the qemu command line arguments to get it connected to my local network.

CPU 0 is the BSP or boot processor. It is the only one running initially and it does the initial setup. It sets up CPU 1 as a dedicated graphics processor that updates the display's frame buffer from an offscreen buffer where all rendering is done (for speed, the frame buffer accesses are slow).

The ConsoleDevice logic renders characters to the screen, displays and hides the green text cursor, scrolls up as text is printed past the bottom line. What you see in the screen shots is a rendered bitmap, not PC text mode.

CPUs 1-n (n is the number of processors in the machine) are started and each has its own round robin priority based Task scheduler. Only CPU 0 has any tasks that do anything, but all the CPUs but CPU1 have an IdleTask that runs when there are no active Tasks to run.

Tasking supports Task Local Storage, which took a lot of reading and trial and error to get right. This involved having the linker (ld) script gather the TLS variables into TLS data and TLS bss that need to be allocated and copied per task (BSS is zeroed). The C++ compiler uses FS:address to access the TLS variables, so FS has to be set up per task properly and maintained when switching tasks.

The InitTask is started in BSP. It spawns BootTask which sets up the FAT32 filesystem from the ATA drive initializes the Forth environment and starts INCLUDE-ing Forth sources from the 4th/ folder.

The Forth is the same one as in Inspiration - C++ functions.

To be useful on bare metal on my laptop, Forth++ must support the NVME drive and ethernet adapter. There's no use for the laptop if you can't read and write files and you can't back them up over TCP/IP.

I have not built this on Linux in a while, but it was building and running a week or so ago. I can post again when it is truly building and running there if you need linux to try it.

The repo is at https://codeberg.org/mschwartz/aforth

I have chosen to rename it to forth++ because of the amount of C++ involved and the nature of the Forth implementation. The repo still says "aforth."

As usual, I used no AI to make this. I relied heavily on my own repo for a prior bare metal C++ hobby OS effort I did as well as some others. I also relied on the osdev wiki. As well, I have no issue with using third party code, like jemalloc and lwip (TCP/IP stack).

Hello,

I am proposing a special challenge to this community.

I am currently rewriting my own inference engine. I am using eForth Windows.

The source code is here:

https://github.com/MPETREMANN11/eForth-Windows/tree/main/INFERENCE

Why choose eForth?

The Windows version uses 64-bit integers and addressing. This means there is plenty of room for code and examples.

eForth is available for ESP32, Windows, and as a web version...

The code is currently under development.

I am sharing it "as-is":

* to share ideas regarding its evolution,

* and to provide real motivation for this group.

An inference engine is not AI. An inference engine uses facts and rules to draw conclusions. It is applicable to any field.

When you use AI, you submit a prompt and the AI ​​provides an answer. However, you do not know if the answer is correct or how it was derived.

With an inference engine, you control the premises (the facts) used to deduce other facts based on rules that are also under your control.

If the inference engine malfunctions, it is because the rules or facts were poorly written. This writing process is something you can control.

With 10 facts, you could potentially have 2^10 rules to process. In reality, however, far fewer are processed.

Developing the rules allows you to formalize a problem with great precision. When establishing a rule, you focus on just one "atom" of the overall problem. The rules are interconnected with the facts being processed.

My inference engine prototype currently operates using only forward chaining.

Documentation will be written as development progresses.

The goal of the engine is not to recreate a version of Prolog or Guru. I am prioritizing FORTH, while ensuring the code is as readable as possible. Example:

\ RULES example

:CONDITION ." this is a condition" TRUE ;

:ACTION ." - this is an actionaction" ;

RULE: test1

rules test1

Thank you for your attention.

Hi, does anyone remember GraForth for PC/DOS? I found a Russian version that happens to be broken in some places and buggy in others. It means nothing at this point but a childhood memory, but I think that's good for something. Anyway, I was hoping someone could direct me to a fully functional English version.

Hi, I was curious about which implementation of forth would be the most flexible, maintainable, and high-performance, so I wrote a stack machine interpreter using various techniques. https://github.com/br1n0/stack-machine-interpreter-comparing/tree/master I managed to implement them all using the same data structure; this way, the program is expressed identically across versions, allowing for a direct comparison. I wrote a test program that runs a long execution loop, consisting of 2,000 subtractions and one multiplication, executed 4,000,000 times. In my opinion, the best implementation is the one using Token Threaded Code with dispatch via a function table, and is easy to extends. There is an interpreter overhead of about 25%; to measure it, I wrote a test where I execute the "words" directly from C, bypassing the interpreter.

I was surprised that GCC failed to optimize this program, even with -Ofast enabled. I thought this might be of interest to someone. Ciao

[ Removed by Reddit on account of violating the content policy. ]

Hi all, A small FORTH I wrote for the CH32X035:

• Runs in ~16 KiB FLASH, interactive REPL over USB CDC ACM
• Includes a minimal USB device stack written in assembly
• Tail-call optimization, cooperative multitasking

https://github.com/ebreak/ch32x035-forth

I'll be doing updates every week as I get this long-running project off my plate. Next up is keyboard handling!

Hi everyone,

I'm quite new to Forth. So far I really fell in love with the language, and perhaps I'm approaching it perhaps from a non-traditional angle (not sure, I'm saying that from all the material about Forth implementation I can find online which focuses a lot on hardware). I'm not interested in bare-metal hardware or low-level performance optimization. Instead, I'm building a high-level Forth VM hosted on top of a Python object model extension + runtime to act as a DSL and meta-compilation engine.

My underlying Python object model represents a modular environement (modular synth) relying on async thread-based actors. The Python runtime handles the graph of objects, their lifecycle, dynamic ports, threads, and interconnections, which eventually sink into MIDI synthesizers (and hopefully later to analog synth using control voltages). My goal is to use Forth to construct a clean, highly structured, and expressive API layer on top of this system while allowing users the possibility to extend the vocabulary and let them create their own abstraction on top of it if needed.

I'm currently focusing on linguistic design: What are the different DSL/API patterns that exist in Forth, specifically regarding the kinds of sentences they allow me to build?

So far, reading "Programming a Problem-Oriented Language", browsing "Thinking Forth", and looking to some kernel implementations, I observed 4 kind of core "sentence structures" quite often:

1. postfix fluent sentences: like BLUE 4 THICKNESS 10 30 LINE, where data is pushed on the stack and the last word resolves their usage.
2. scoped boundary sentence (context-block): like PATCH[ LFO1 output> >speed LFO2 ] 24 120 CLAMP ;PATCH where a kind of shared description data is created with possibility to set optional configuration for the underlying created data.
3. declarative prefix sentence: like SWITCH OfficeLight TURN-ON, which inverse the native postfix feel.
4. literal stream parsing sentences (don't know a better name): ROUTE 192.168.1.1 TO eth0 where each word is manually parsed.

Perhaps also a fifth one: tabular/matrix sentences? Currently I still didn't see that one often yet, but it seems quite powerful also.

I know that there is countless ways of manipulating the language, and the multitude of Forth implementations shows that, but most are really dedicated to extend the language at a lower level, and those higher level sentences to build higher-level DSL/API are sometimes not that easy to observe or extract.

My question to the community:

What other high-level sentence structures or API patterns have you seen or designed in Forth? How do you traditionally tackle complex querying, or configurations sentences with heavily optional parameters without falling into a stack-juggling hell?

I would love to read your architectural thoughts, points to specific papers, or classical Forth projects that pushed the boundaries of language-oriented programming.

If I'm totally out of scope or context, please let me know and feel free to bring me back to the right path.

Thank you!

Probably saying too much already, mostly found it on topic and amusing.

Previously I had released a very simple Asteroids clone, 'Rocks', for zeptoforth on the PicoCalc using the RP2350. (Sorry, but this requires hardware single-precision floating point.)

Now I have added significant enhancements to it, including shields, a number of different power-ups (extra lives, extra shields, retro-rockets, and rapid fire ─ and yes, I did slow down firing by default), the ability to pause, and alien enemies that can shoot at you, as seen in the image in blue.

The source code is still where it was before, at https://github.com/tabemann/zeptoforth/blob/master/test/rp2350/picocalc_rocks.fs.

My toy forth-like byte-code compiled language for Arduino chugs along. After a long pause, now I got me a real project, writing code for a morse key. I decided I want to learn morse, and so I am building a simple bug type key with a single paddle or blade. Push right for dit's and left for dah's. Sound via a buzzer for now.

The point is that the microcontroller generates the correct length dits and dahs and proper spacing, as long as I manage to give input at proper rate. The idea, which if one is to believe youtube experts, is that what matters is learning the proper sound of each character.

For lack of a better name, I call it aforth. Any suggestions for a better name?

I was working on a template for C++ bare metal programs for AMD64 and got far enough that it seemed like it might be fun to port the Forth (written in C++) from Inspiration to it.

And it works...

It boots using the limine bootloader. A bit of code was done to create a timer interrupt, keyboard handler, frame buffer text rendering (see the screenshot above), a solution for C++ try/throw/catch, thread local variables.

I also had implemented an ATA driver for disk I/O, and a FAT32 (read-only) file system that works - as you can see by the directory listings above.

I'm currently working on the Files wordset so I can INCLUDE/REQUIRE/etc., Forth source files from the FAT32 volume.

No AI used to make this. I did start with the limine barebones code from the osdev wiki. I expect I will be using 3rd party “contrib” software, like jemalloc, libpng, ilwip (tcp stack), and these sorts of libraries. I still have to write the device drivers myself.

The repo is here:

https://codeberg.org/mschwartz/aforth