MilliForth-6502: The smallest Forth real programming language for 6502 | Hacker News Reader

MilliForth-6502: The smallest Forth real programming language for 6502

github.com

121 pointsrbanffy39 comments

I always get the impression that people spend more time writing Forth interpreters, rather than writing Forth programs to solve actual problems.

Forth exposes both problems and solutions that aren't germane to the bulk of everyday computing systems:

1. I want to debug my assembly code with a REPL

2. I don't want abstraction, I want minimalism

3. I want to write solutions in the context of specific hardware

When you have all three, you have Forth's wheelhouse. Minimalism means you do get a sense of "seeing the Matrix" - the machine is controlled precisely to your specification. But as soon as you think that you can layer on a more abstract idiom, even those that are usually conventional in high level programming, it also reveals that it really won't help you do that. Either you DIY that abstraction, or you revert to the same load-store imperative paradigms you'd use for a large assembly program.

The answer everyone else is using is to add an operating system and an application language as a starting assumption, and then slowly grind through every issue caused by giving up control at the base layer to these more automatic systems.

I think there is a reasonable place for Forth as a runtime target for compiled code, but the style of code that it supports prefers "flat" designs, like dataflow/FBP languages, because of the explicit stack. Once you aim towards Algol and Lisp and start automating stack movements, the programs become coupled to that design and way of thinking.

> The answer everyone else is using is to add an operating system and an application language as a starting assumption, and then slowly grind through every issue caused by giving up control at the base layer to these more automatic systems.

The OS community generally understands in theory, although this is much less accepted in practice, that mechanism and policy should be separated as much as possible. Forth, operating systems, Smalltalk, etc. all converge on making programmed systems, if in substantially different contexts, and this becomes a question of layering abstractions. A Forth-like OS that would solve your problems is related to microkernels and exokernels. Minimality and simplicity is essential for foundational services.

I know that's what I do! It's a fun exercise, and Forth is uniquely suited to writing Forth interpreters. Forth really only has a few areas where it excels and they are incredibly niche ones at that.

We did write Forth to solve actual problems, but that was back in the 1980's, when computers used to have a Forth based BIOS, or solving engineering problems on a HP-48 (yes I know RPL isn't exactly Forth).

I started like this. My current system, which is the second or third attempt, serves me every day. I have some kind of server that has been running 24/7 for maybe a decade, and it is my go-to language for testing, prototyping and other throwaway scripts - which I actually frequently salvage, despite the fact that they were written for a version of the system that no longer exists because I'm still tinkering with it and don't care about backward compatibility much.

It's a fantastic way to bring up new hardware at the bare metal layer and do nontrivial things. But unless you're Jeff Raskin or something, building out, say, a word processor or something of similar complexity is a bit more daunting.

It’s a fun activity, and if you still solve “real problems” on a 6502, then it’s because you really want to anyway.

That being said, Forth is great for “exploratory programming” of hardware. I rarely, but still sometimes bootstrap Forth for that reason.

Here's what I'm hearing:

How would you design a Forth interpreter to encourage more people to solve actual problems with it? :)

This might be a bit out of date since I haven't looked in a few years, but my sense is that the standard libraries and documentation are often lacking. A batteries included standard library for gForth that could conveniently do basic things like make an HTTP request, display a dialog, or play a sound, without having to awkwardly bind to C APIs, would be really nice.

Not sure that will swing it, have a look at https://github.com/JohnEarnest/Mako/tree/master Which is basically a Forth for games, that runs on the JVM, and in the browser.

The issue as I see it, is that you have to have a model of the datastack in your head at all times. That's fine for your own code, but for other people's code, stack diagrams will only take you so far.

The ability to scan code, rather than reading it, allow you to mentally drill down when you are ready. Forth requires immersion.

Something like https://xorvoid.com/forsp.html I'm guessing is really the bridge. Something that allows variables without being too complex.

This is what I miss about the Red Power mod for Minecraft. I wonder if GregTech would see the fun in adding some sort of CPU that wouldn't be the worst emulation stacked inside of hand written 'machine' op functions...

Offhand, anyone know of any good (either long stable, or better, well maintained and likely to persist) CPU emulators for Java? Something that does 'web assembly' might fit the task if it's reasonable to transpile a fake binary format into real WASM.

The first good search result I got was : https://github.com/dylibso/chicory : better than wasmer-java for this use case since it doesn't depend on native binaries.

Relating this back to the topic. It would be interesting to have to, at least copy in someone else's if not, write your own Forth interpreter to help bootstrap computers.

This is where it gets interesting. The comments are both hilarious and educational.

https://github.com/agsb/milliForth-6502/blob/main/scrs/jones...

I bet they could get it even smaller for the 6809

Was playing with a 6809 system not long ago and, yeah, FORTH maps really nicely to it. S reg = parameter stack, U reg = return stack, Y reg = interpreter pointer. Inner interpreter is a single two byte instruction (jmp ,y++).

I'd always wanted to play with the 6809 and it really is a slick little 8 bit cpu.

That's how I did it in 1983 (but I think with the roles for S and U swapped).

Note that what you're describing is directly threaded code; traditional FORTH uses indirect threaded code: http://www.complang.tuwien.ac.at/forth/threaded-code.html

You're right, I forgot the indirection. Inner Interpreter instruction is actually: JMP [,y++]

it's easily the king of 8-bits, the best of the bunch

the 6309 with its extensions... even more so

I found a very nicely done text file documenting the 6309 extensions that I am attempting to link to here in case other readers are like me in admiring the 6809 architecture and are curious about what got tweaked ... https://www.6809.org.uk/dragon/6309.txt

The excellent book Threaded Interpretive Languages recommends the Signetics 2650 and the RCA 1802 for writing FORTH like languages. I was surprised because the latter is slightly obscure and the former I had never even heard of.

Heh - I was looking for examples of 6502 Forth. I did fine fig-forth, but this looks interesting too now. This always happens on hacker news - I have some interest, and I see it on the front page of Hacker News soon after.

There was a Forth IDE for the Commodore 64 by HES, if that's of any interest.

There were plenty, I have a small collection of them! Most of them, including HES’s “64 FORTH”, are heavily fig-forth based. The thing I really like about 64 FORTH is the SOURCE word, which shows you the source code (at least the portion of it that is forth) for each word, so when I mess with forth on the C64 I mostly use that one.

Not trying to be harsh, just a bit of snarky humour, but they should partner with the “6502 as a service” folks and offer obsolescence as a service.

I did have some good times with my 6502, as well as a dalliance with Forth… but I don’t really miss it when I’m playing with my 10 cent 32 bit RiskV chips and marvelling at the beauty of their ISA. It brings to mind a Joe Cocker song.

I haven't seen or touched a 6502 based computer since 1986. Are people using those ancient computers or actually using new(er) ones? I see 6502 based kits are available as are some new SBCs.

Both.

You can buy trainers with old chips like this, z80, CDP1802, 8080, 6509 etc.

The main advantage of the new SBCs is simplicity vs anything more modern and easier to deal with than a retro computer. The advantage of a retro computer is it has some intrinsic value and probably a large body of contemporary software.

They still manufacture 6502s (and some periph chips) and you can license the core IP for your FPGA/ASIC [1]. There are dev boards (I have a W65C02SXB and it's kinda nifty) [2]. You can buy them from Mouser. There's apparently still demand in the embedded space that justifies keeping them in production.

[1] https://www.westerndesigncenter.com/ [2] https://wdc65xx.com/Single-Board-Computers

olimex sells one too https://www.olimex.com/Products/Retro-Computers/Neo6502/open...

I build my own 6502 from Ben Eaters kit -- expanded it quite a bit now with more changes in progress.

Why? Why not use a modern and more powerful chip like the ESP32?

Is that a serious question? Because you can slap a 6502 on a breadboard, make your own busses with wires, and understand every single aspect of it, hardware and software.

Ben Eater also had a video series about designing and making his own CPU from logic chips. He switched to 6502 likely because progressing up the stack, it started to become too big.

Of course it's a serious question. When I do a micro controller based project, processor selection is an important consideration. One can slap an ESP32 or a CH552 or dozens of others on a breadboard too and do everything you mentioned. But, I honestly haven't ever considered any of the ancient microprocessors.

I'm building a 6502 system to build a 6502 a system -- it's a hobby. The challenge is accomplishing things using limited technology. It's art. I'm building the computer (with paging and "kernel mode"), an operating system, programming languages, GUI, etc. Keeping it 8bit also helps keeps the scale small and doable.

When I do a "microcontroller project" then I slap an ESP32, Arduino, or Pi Pico on the breadboard -- not a 6502.

These projects are not done to solve “real problems”, they are done as educational engineering challenges and playgrounds. Of course a modern microcontroller does everything and much much more, but it is also extremely opaque, and even the ones considered “simple” nowadays might not be fully understandable in every single aspect by just a single person.

Now, nothing prevents you from still using a 6502 based project for “real problems” as well, and it’s fun to use your pet project for something practical every once in a while, but that’s usually not the focus. The focus is learning, building, intentionally reinventing the wheel so to speak.

In my previous comment to you, I mentioned how Ben Eater made a self-designed CPU in his excellent video series, before switching to the 6502 to explore higher abstraction layers. In that case it may be more obvious that the focus was on designing the CPU itself, not on any a priori application use case for it.

Because you like and are more familiar with the 6502? That's why I would/do.

What's the fun in that?

oh hell yeah. makes me want to go grab a 6502 box from the gar-age. Do the rPi Pico 2W next!

Nick checks out.

Have you seen: https://wdc65xx.com/Single-Board-Computers

At one point, I was living somewhere that had access to someone's C64 and I wrote a VT100 emulator in FORTH to access a remote VAX via 300bps modem into MeritNet. Then I wanted to do graphics on the VAX and remembered the GiGi (which ran BASIC with DEC Regus graphics if booted in standalone mode) and began creating my own escape-sequences to draw. This led to discovering the NAPLPS standard and then to building my own backend BBS using 900 (reverse bill) numbers for C64 dialup users. Years later I saw the PRODIGY service at a Sears store and smirked.

Reply on news.ycombinator.com