crc_

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.

Thanks; I'll start doing that when running on Linux. (I had missed this, as my main dev box is running OpenBSD which doesn't have kvm)

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).

I wasn't aware of the clash when I chose the name, unfortunately.

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.

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.

Thank you for the feedback.

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.

There is a floppy image on the x86 page. I also have multiboot compatible kernels linked there for use with GRUB or similar bootloaders.

There is some limited graphics support. The underlying system (ilo) has a branch for x11 providing a limited framebuffer and pointing device support, and the native x86 system optionally supports a low resolution display (but no mouse yet). My son & I are working on expanding the graphics functionality, though we aren't expecting to have this work finished until later this year.