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.
Oh, I didn't know UEFI text mode didn't use VGA text mode! That could be an important consideration. But I suppose you can still frob the VGA registers to set VGA text mode, right? Even if you boot under UEFI?
64kW of RAM @ a 4 byte (32-bit) word size, so 256KiB of actual RAM for the applications running on ilo.
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).
For RetroForth, I have a new interface under development that may be somewhat like this. A screenshot can be seen at https://imgur.com/a/z4jhq6e
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.
Your sidebar reminds me of the computer I learned to program on. A TRS-80 Model III.
I went through a short period of figuring out interesting peek/poke memory addresses for modifying the BASIC system, and found the "80" used as the scroll width. Setting that to 60 allowed me to create a non-scrolling status sidebar like that for my first programs/games.
It strikes me that it would have been great to have had a Forth machine back then. That early version of BASIC didn't have a (language accessible) stack! Not even a return address stack, aka GOSUB. So I used strings as a stack to implement a small text adventure parser. (And later, on a computer with graphics pixels, I used BASIC strings as a heap for defining and drawing simple 3D vector objects.) Then I learned Pascal.
Desperate times. Desperate measures. But Forth would have been great.
I'm not well versed in qemu's various options. When I didn't specify a BIOS image, it seems to be using SeaBIOS, not UEFI, and hangs on "Booting from Hard Disk...". I should be able to start doing proper videos soon; I've been slowly working towards that.
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.
This is a minor pet peeve of mine, actually. I would understand if qemu defaulted to BIOS booting, though I'd prefer that it try UEFI then fall back to BIOS/CSM at this point, but it's actively difficult to do UEFI on qemu; you have to actively feed it the ROM by path, and last I tried you had to include a -pflash for writable storage even if you weren't doing anything with it (thankfully this appears to have been fixed). I really wish they just let you do something like -boot-firmware=uefi,bios or such. (And again, in 2025 I really think UEFI should just be the default, with fallback to CSM/BIOS for backwards compat)
The countervailing force here is the desire for command line backwards compatibility. Every time you change a default to be something that makes more sense today, you break the existing working setups of some unknown number of people...
The approach the project has settled on is to say that providing user friendly defaults should be the job of a "management layer" piece of software like libvirt, and QEMU proper should concentrate on providing flexible and orthogonal options which that other software can use to tell it what to do.
Does qemu make an effort to preserve backwards compatibility with its cli? Because I have distinct memories of getting caught by them changing the way multiple parts of their command line work.
But in this case, my suggestions should be fairly backwards compatible; retaining the default of BIOS but adding a simple `--firmware uefi` option would change nothing for existing users, and even defaulting to `--firmware uefi,bios` should be mostly compatible since it just tries UEFI and then promptly falls back to BIOS.
Yeah, we do try to maintain at least some back compat. Some things go through a deprecate-and-drop cycle, but that is more often driven by "the old thing is a pain to maintain internally" than by "the new thing is more user friendly".
New top level command line options are rare these days, and magic "do what I mean" options also rare: we tend to prefer "tell us specifically what you want".
Maybe we should have new command names with defaults that are reasonable this decade, keeping qemu-system-i386 and the like for backwards compatibility?
Like apt vs apt-get? Yeah, I could potentially go for that. Although in the case of qemu I'm not entirely convinced that we need to go that far because I think it would only take small tweaks to make the existing tool friendlier.
Supernote hasn't posted anything about the potential future Linux system. I'm personally not expecting this to actually come around.
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 not sure I'd quite count this as Forth; it's more of a very simple monitor for loading and running code. It's not a bad approach for use with a host Forth though.
Konilo is not an ANSI Forth. It's a unique dialect with similarities to my older RetroForth system, which is also not a traditional model.
In Konilo, that example would look like:
:variable d:create #0 comma ;
and using it would appear as:
'ORANGES variable
While much of the system is complete, documentation has been lacking, partly due to me not investing much time on this while things were evolving. Now that it's stable, I am working on this, and have added some information to the manual (see https://konilo.org/manual) to help clarify that it's not a traditional Forth model.
Thanks. It is great as I can run under my ipad both pythoista and ish even. But changing the basic syntax will be hard for beginner. May I suggest have some tutorial. In particular for both external (say vim or any external shell script) and internal (hoe to use any editor and save the current work in progress) use. I found it hard even to navigate under your hypertext, sorry …
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.
Filesystems introduce complexity that may not be needed, especially on smaller targets.
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.
ilo could likely be made to work, though with some limitations.
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.
