With this, I wasn't seeing any output with -display curses. It does work with -nographic or using a vnc connection to qemu's display, as well as on the two physical machines I currently have access to.
24 karma · joined February 17, 2021
For a reference, the 8088 build needs a bit more than that to account for stacks, the VM code, drivers, and memory needed for the actual hardware. (Around 384KiB physical RAM on an 8088/8086 works well from my testing, but I've tested with 285-320KiB in non-standard configurations under a few emulation targets).
I use RetroForth as a working environment on Unix [mostly OpenBSD & FreeBSD], with an (unreleased) userland written in it, along with some use of external standard utilities. I'm still working on improvements around chaining programs via a pipe-like structure, but it's been my main environment apart from Konilo for a few years now.
I can say that the display & overall performance is noticeably faster on the two actual computers I tested on than under qemu on my Linux system.
The standard OS is derived from Android, but has no Google Play services and only supports side loading (which works well via ADB; I've not tried other app stores like FDroid). It doesn't have a lot of standard Android things like a home screen/launcher, no notifications, and no UI for switching between apps other than using the sidebar to bring up the application list and going back that way. There are no speed modes for adjusting refresh rates.
IMO, it's a great eink notepad & sketch book, and makes a good ereader with something like koreader, but it's not good as an Android tablet.
I'm hoping to have the documentation considerably improved over the remainder of the year. Apart from the current work on the hypertext manual, a larger book format manual and tutorial are being worked on, though they're both very incomplete at present.
On the internal/external bits, Konilo is largely intended to be a self contained environment, but it is possible to use in some contexts with outside tools. I'll write up something on this in the next few days and will post a reply in this thread with a link once it's done.
In Konilo, that example would look like:
:variable d:create #0 comma ;
'ORANGES variable
I'm personally not averse to file systems. I've implemented (but not yet published) a couple for testing purposes. It's probable that one or more of these will eventually be included in Konilo. But that won't happen until I write a program that needs this and have an implementation that I'm happy with.
From a quick reading of the linked system:
- ilo is little endian (for block & rom format); if you wanted to keep external compatibility, this would need to be dealt with. It's not difficult to do this; e.g., the 68k Mac version does this: fossils.retroforth.org:8000/ilo/file?name=vm/ilo-68k-mac.c&ci=tip
- this system presents some memory limits that would necessitate changes to ilo. Two aspects stand out to me.
First, separate code & data sections, with a limit of 64K each. ilo's standard memory area is a flat 65,536 32-bit words, needing 256K. This can be reduced, but will then not work with a standard Konilo rom. (The memory layout in the Konilo rom can be edited by modifying the assembly, but the overall reduction in available space will be very limiting for a full Konilo system. It'd be fine for using just the basic wordset in the rom or for assembly programs).
Second, memory is divided into 2K banks, so a bit of work in ilo may be needed to deal with that. The previously linked Mac version can deal with this as well.
- performance will be slow.
ilo is internally a 32-bit system. I've built & run it on an old 8088 MS-DOS system, but it's very slow there. I suspect it'd also be quite slow here as this is another 16-bit system.
I don't have the timings for this, but starting up a minimal Konilo system on an emulated Mac Plus (mini vMac @ 1x, emulating an 8MHz 68k CPU) takes 1m8s. It took quite a bit longer to start up on the DOS system.
Though again, this is when running Konilo. It'll be much faster with smaller assembly programs or things that do less i/o.
I use FreeBSD and OpenBSD, the ports/packages for others are contributed by others.
RetroForth is smaller and easier to build than gforth or Factor. I actively use it and seek to improve it, and I've been told the documentation is good, though I still feel I have a long way to go on that front. It's not a traditional Forth, but it works well for me. I borrow things from traditional Forth, colorForth, Factor, 8th, and other languages when I think they make sense for my needs. Releases are quarterly, with daily snapshots provided.
Gforth is big and I find it to be difficult to build from source. If you need or want a traditional/standard Forth, it's probably what I'd recommend if using one of the commercial ones isn't an option. Definitely build it from source though; the releases are infrequent and the development versions have a lot of bug fixes and improvements.
Factor is big, has lots of interesting stuff, but apart from stacks and colon decisions, really doesn't feel like Forth to me. It is under active development, but releases other than snapshots are very infrequent (last in 2018). Building from source isn't something I've done with this in years, and platform support is more limited (Linux, Windows, macOS, on x86 or x86-64). I've borrowed some ideas and terminology from Factor over the years and would consider it worth learning from.
The canonical source for the documentation is in doc/book, with HTML formatted copies in doc/html and a Markdown copy as doc/RETRO-Book.md. The glossary of words is also included separately as a text file under the doc directory.