Or, what I did over the Holiday break. I've historically spent lots of time investigating the low-level plumbing of FORTH, always intrigued by its implementation, porting it, rewriting NEXT, but never really using it. I borrowed much from the FORTH playbook when architecting PLASMA, so I took the past couple of weeks to implement FORTH in PLASMA to create a REPL environment. Programming in PLASMA is a more traditional edit/compile/run loop that can be a little slow on a 1 MHz 8 bit CPU.

The goals were pretty straightforward: interactivity and debugging were of paramount importance. Writing it in PLASMA itself may have initially been a questionable choice, but in the end it created a better programming environment than I could have imagined. As a first class citizen of the PLASMA environment, it had instant access to all the PLASMA modules I've been building for the past decade. From floating point to high-res graphics libraries and everything in between.

As I was focusing on debugability, I chose an ITC model to allow for easy introspection into a running program. However, I quickly realized that it wasn't a very big leap of logic to have the compiler also output compiled PLASMA byte code. The debugging features were lost, but the performance improvement is dramatic. Switching between the two modes is seamless and ITC or PBC (PLASMA Byte Code) words can call each other. PLASMA byte code is a direct match to low-level FORTH constructs.

There are still a few places where I'm unsure about the proper implementation of some words, especially the more esoteric compiler constructs. The built-in vocabulary is pretty minimal on purpose, the idea was to be able to expand using available PLASMA modules and some glue words. It also looks suspiciously like an early '80s wordset, as that is what I'm most familiar with.

Here is a (worse than usual) video running through some examples: https://youtu.be/picPyXAk77I?si=Td2En5Z3oxVTzh0z

A floppy disk image ready for your favorite Apple II emulator can be downloaded here to play along at home: https://github.com/dschmenk/PLASMA/blob ... PLFORTH.PO

And for more information about PLASMA you can check the GitHub site: https://github.com/dschmenk/PLASMA
or the Wiki for details about the VM and libraries: https://github.com/dschmenk/PLASMA/wiki

Lastly, the source for PLFORTH as written in PLASMA: https://github.com/dschmenk/PLASMA/blob ... lforth.pla

I am happier than I would have imagined to have a REPL environment that also doubles as a useful scripting language for the PLASMA environment. Always looking for useful feedback

That's great! Your demo of the colours program about the 10min mark, first in the debuggable mode and then in the plasma bytecode mode, is quite striking!

Excellent debugging tools!

I've begun the task of documenting some of the unique aspects of PLFORTH. Ugh, not my favorite: https://github.com/dschmenk/PLASMA/blob ... PLFORTH.md

I'd really appreciate feedback from you FORTHers, and especially non-FORTHers. Some understanding of FORTH comes from usage, and I haven't really used it a great deal.

Thanks for your time checking out my project. And I apologize again for that video. I'll redo it later and try and make it less cringe-worthy

You may have noticed I mentioned *three* ways of compiling Rod's colors but only showed two. Well, the PLASMA compiled one runs about 20% faster than the PLFORTH byte code version, but the video was getting too long and I bungled the way I ran it, so it got left on the virtual editing floor. Even then, I was pretty impressed how fast the PLFORTH byte code version ran. There were only a handful of places in the compiler that required checking for the compile mode and generate ITC vs PBC. Being able to test and debug code in the ITC version before committing to the PCB version has completely changed how I view programming "on the metal". Doing the edit/compile/run (crash/reboot) sequence using the PLASMA compiler gets a little tedious. Having a REPL environment available to PLASMA makes programming on 45 year old hardware fun again.

Thanks! Let me know if there is something to improve upon. I don't always know what others want in their programming environment.

I ultimately decided on a vocabulary that satisfied my desire to have a glue & scripting language for PLASMA. Keeping it minimalistic allows for quicker loading (PLASMA modules are relocatable and relocation is done at load time) and smaller size (still about 13K). Additional features can be loaded from source and PLASMA modules if desired. I forwent the more esoteric FORTH compiler, input, and number formatting words. What's left is a good match to the intended usage; PLASMA linkage, debugging and flow-of-control words: