Forth support

[cstrotm]

Hi Steven,

thanks for the very enlightening talk about 8bitworkshop at KansasFest 2020.

I was unaware of 8bitworkshop, but I will surely use it for future projects. It's really great.

In your talk you mentioned that you are interested to add other languages to 8bitworkshop in the future, maybe Forth.

I'm part of the team that maintains VolksForth, a Forth system for 6502, Z80/i8080, 8086 and 68000 machines.

VolksForth is currently on the Forth83 language level, but we have add-on code to make VolksForth compatible with ANSI-Forth '94 and the latest Forth 2012 standard.

From the machines supported by 8bitworkshop, VolksForth runs on

• C64
• Apple II
• MSX (experimental port available, but not checked into Github)
• MS-DOS PC

in addition, it also runs on

• Atari ST
• Apple 1
• Atari XL/XE (possibly on Atari 5200, never tried)
• 8080/Z80 CP/M machines
• py65 (Python based 6502 Emulator)

We have plans to support these machines in the future

• Amiga
• Sinclair QL
• Amstrad CPC (without CP/M)
• Sinclair Spectrum
• m68k Linux
• 68000 based MacOS
• Apple Lisa

You find VolksForth on https://github.com/forth-ev/VolksForth

VolksForth is written in VolksForth (not Assembler or C or other language), it Meta-Compiles to other targets. The plan is to be able to metacompile from each target to any other supported target.

If you are interested in collaborating integrating some Forth system into 8bitworkshop, let me know.

[sehugg]

Thanks for pointing this out, I used GraFORTH for the Apple ][ back in the day. I wonder how you could run the cross-compiler in a browser, maybe via something like https://github.com/remko/waforth? Or I guess you could emulate one of the supported platforms.

[cstrotm]

I wonder how you could run the cross-compiler in a browser, maybe via something like https://github.com/remko/waforth? Or I guess you could emulate one of the supported platforms.

Using a cross-compiler would limit the usefulness of Forth on the target. To get the most out of Forth (e.g. interactive development, Forth as a "scripting language" inside the application), the Forth system should run interactively on the target (the emulated machine).

Most Forth systems are "image" based systems like Smalltalk. To develop an application, you load the Forth system in memory and as a programmer you change the Forth system to become you application. The Forth kernel will still be embedded inside the application. Also, many Forth programs extend the Forth engine while compiling the code. Doing that with a cross compiler is complex for the developer and, in my view, would be contrary to the goal of 8bitworkshop to deliver a platform for easy learning

I envision having the code editor (for sequential files, optional for block files), a debugger (Forth tracer and Forth de-compiler, disassembler) and the REPL-CLI in the Web browser. These modules would interact with the Forth kernel running live inside the emulated target machine via a simple, memory mapped I/O interface. That would enable to inactively compose graphics and test code on the live target.

The IDE could optionally support multiple Forth engines on each target (selectable by the user), for example blazinForth, Durex-Forth, VolksForth etc. on the C64 target.