James Bowman

Well there's an active community of people writing their own operating systems. Why do that when Linux is available? I don't think a further reason is required for the hobbyist. But there are various actual products which result from efforts to create a minimal forth that are interesting. One of my favorites is the J1 CPU: https://www.excamera.com/sphinx/fpga-j1.html Also I think many of these personal forths have explored interesting areas of programming language design, and when I have read about those which have been made public I often learn something new. It's like code poetry.

Also worth checking out James’s simplified version designed for the Lattice iCE40 [1][2]. [1] https://www.excamera.com/sphinx/article-j1a-swapforth.html [2] https://youtube.com/watch?v=rdLgLCIDSk0

> Another impressive one is J16 which is an amazingly small FORTH machine Did you mean the J1? https://www.excamera.com/sphinx/fpga-j1.html

This is really cool. Thanks for doing this and sharing the instructions. Also note, James created the Gameduino 1 & 2, which are worth checking out. http://excamera.com/sphinx/gameduino/ http://excamera.com/sphinx/gameduino2/

Unfortunately the question is, strictly speaking, unanswerable. The best one could do is come up with a specific design and estimate the number of gates needed, and then one couldn't be sure exactly how suboptimal the design in question is, regarding gate count. One of the most basic design choices is probably how much and which work to do using dedicated logic, and how much to do using general purpose logic and microcode. One may get an idea of the order of magnitude of gates required by taking a minimal CPU core (say, the j1 core from http://excamera.com/sphinx/fpga-j1.html), writing a minimal lisp interpreter on that core, and adding the gates needed to store the interpreter to the number of gates used for the core. This is left as an exercise for the reader.

This always mede think back to J1 Forth CPU https://excamera.com/files/j1.pdf

The first choice was the Gameduino, also an FPGA-based solution. I have misplaced my bookmark for the documentation covering the previous hardware revision, but current version 3X is MOAR POWAH just on its own, this seems to be a natural tendency: https://excamera.com/sphinx/gameduino3/index.html#about-gameduino-3x Edit: found it! https://excamera.com/sphinx/gameduino/index.html

Can you give some insight on how the J1 fits in all this? The presentation explaining what drove its invention suggests it actually was faster than the register-based alternative, although I'm sure that is also partially because it only focused on the instructions needed for its task. [0] https://excamera.com/sphinx/article-j1a-swapforth.html [1] http://www.forth.org/svfig/kk/11-2010-Bowman.pdf

This talk covers some of the design decisions that lead to the design of the uxn stack machine. https://vimeo.com/771406693#t=85m30s C source code of the VM, 100 lines. https://git.sr.ht/~rabbits/uxn/tree/main/item/src/uxn.c An example assembly file for that stack machine https://git.sr.ht/~rabbits/uxn/tree/main/item/projects/examples/exerci… Another stack machine designed to target FPGA with an elegant design, mentioned in the talk above. https://excamera.com/sphinx/article-j1a-swapforth.html

I've heard of the ZPU in passing but never looked in much detail - I didn't realize there was a GCC back-end for these machines. James Bowman's J1 CPU [0] is also stack-based and has definitely helped me shape my preferences. [0]: https://excamera.com/files/j1.pdf

Here is some interesting Forth software, including a Space Invaders game and an IP networking stack including IP, ARP, UDP, DNS and DHCP [1]. It runs on the J1 custom Forth CPU built on an FPGA [2]. The author says it was originally designed to run an array of Ethernet cameras on a robot. 1. https://www.excamera.com/files/j1demo/docforth/ 2. https://www.excamera.com/sphinx/fpga-j1.html Edit - also mentioned here by adastra22, I see.

Given that you need a really simple ISA, and probably also good code density, how about a Forth CPU, like https://excamera.com/sphinx/fpga-j1.html?

the chip can do some video, but low res: - https://excamera.com/sphinx/store.html#gameduino-3x-dazzler-for-pico-3… - https://www.adafruit.com/product/4984

He also refers to another repo with a very small Python implementation of a raytracer. There, the author links to an article how he managed to speed up raytracing in Python by a factor of 130, going from 15 seconds per image to 115ms: http://www.excamera.com/sphinx/article-ray.html

It will fit in an 8K easily. There was a version of the j1 (that this was based on) running on an IceStick with a 1K part. https://www.excamera.com/sphinx/article-j1a-swapforth.html

You could also check out James Bowman's "Gameduino" line of graphics boards [0:2] (which includes a Forth-programmable CPU, the J1 [3], implemented on FPGA) [0] https://excamera.com/sphinx/gameduino/ [1] https://excamera.com/sphinx/gameduino2/ [2] https://excamera.com/sphinx/gameduino3/ [3] https://excamera.com/sphinx/fpga-j1.html

Now more than ever because you can define it code. Here is a CPU written in 200 lines of Verilog. https://excamera.com/files/j1.pdf

A quick google search yielded this: http://excamera.com/sphinx/fpga-cpu.html

I totally agree here, if you want low level I think j1 forth (http://www.excamera.com/sphinx/fpga-j1.html) and for lisp I really liked http://www.buildyourownlisp.com which uses modern C libraries so it polishes your C knowledge too.

I believe this was on hn recently (uses icestorm as mentioned by others): http://www.excamera.com/sphinx/article-j1a-swapforth.html

Huh? There's loads of cheap dev kits for a few 10's of bucks on eBay. Example: http://www.ebay.com/itm/ALTERA-FPGA-Cyslonell-EP2C5T144-Minimum-System… This uses the EP2C5T144. Some basic getting started info here: http://www.leonheller.com/FPGA/FPGA.html [Leon Heller] You can run a free copy of Quartus and use it to run Verilog / VHDL cpus, or anything else you want to do. Same applies to the Xilinx FPGAs. A really cool example project: http://excamera.com/sphinx/fpga-j1.html

in action in ice40 fpga using icestorm http://www.excamera.com/sphinx/article-j1a-swapforth.html

I have something along those lines in progress now... if you mail me at the address on this page: http://excamera.com/sphinx/index.html I will let you know when it launches.

If you are interested in a more "conventional" Forth chip, check out the J1[1]. It's 200 lines of verilog, so you can put it on an FPGA pretty easily. But it's even easier than that because the J1 is the basis of the Gameduino[2]. The Gameduino is a shield for Arduino that gives you a VGA interface, sprites, and graphics. [1]: http://www.excamera.com/sphinx/fpga-j1.html [2]: http://excamera.com/sphinx/gameduino/

I'd imagine that examining an efficient stack architecture like the J1[1] would be even more refreshing. No need for register allocation and tremendous gains in code density. You lose the ability to do out-of-order execution, but in many situations independent operations can still be combined into a single clock cycle, and the CPU is still faster because it simply has less work to do. [1] http://www.excamera.com/sphinx/fpga-j1.html

Working link: http://excamera.com/sphinx/gameduino/index.html#gameduino

this greybeard is looking forward to going retro videogame mad with gameduino. http://excamera.com/sphinx/gameduino/

I ran out to Barnes & Noble and bought your book right after seeing your post and seeing one nearby that had it in stock. (Amazon was going to take a couple weeks to send it. Actually some other company was the sender. Weird. Also I didn’t notice you had it online but I like having the book and paying you anyway. :) ) So I picked up the book Thursday and finished the basic ray tracer Friday :) Not counting chapter 5 of course so there’s a lot more that I can add from here but it’s made me interested in multi-processing to make it faster, (mine is in unoptimized Python currently, using pygame to have a canvas/window and calling it for each pixel), maybe using GPU shaders to do it (never used those before), and learning about techniques other people are using[1][2] (from YouTube etc), and going down the rabbit hole of old CGI animations from the last 50 years[3]. Looking forward to the second half of the book this weekend. I have written a basic renderer before. I did an independent study class in college and I wrote a stereoscopic one for the iGlasses VR headset[4] in the 90s (you just have to draw using two cameras and interlace the images). [1] https://youtu.be/A61S_2swwAc “NamePointer - I made a better ray-tracing engine” [2] https://excamera.com/sphinx/article-ray.html “A reasonably speedy Python ray-tracer” [3] https://youtu.be/WV4qXzM641o “The Compleat Angler (1978)” Ray tracing animation with refraction, rippling water, etc. from 1978! [4]…

I still doubt it's better at reducing complexity because that stuff is horrific in RTL. I can express it with a parallel programming language with ease. A parallel programming language with macros and automatic placement onto cores/DSP's would be even easier. Describe it, compile, and it probably runs. With hardware, I'm looking at several more layers of verification, testing, material checks, and so on. High-level synthesis tools on the other hand might make your claim true. They're a combo of HW and SW languages. "A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86. " Simpler for who? The person implementing both a Forth implementation and a x86 processor? Or the person just implementing a Forth on x86? I've seen Forth implementations in SW. They're trivial. Compilers, libraries, and hardware do all the heavy lifting. I'll put it to the test, though, as I feel you might have picked a good example. J1 Forth CPU Verilog code http://excamera.com/files/j1demo/verilog/j1.v eForth assembler for Z80 & such in few assembly instructions http://www.figuk.plus.com/4thres/systems.htm Forth interpreter in Ada (1985) http://www.forth.com/archive/jfar/vol3/no2/article7.pdf Maybe it's just that I don't know Verilog. However, the Verilog code looks more like the assembler in second link. It's like a pile of gibberish. The Ada code is very…