[HN Gopher] Ilo - a Forth system running on UEFI
___________________________________________________________________
Ilo - a Forth system running on UEFI
Author : rickcarlino
Score : 99 points
Date : 2025-10-21 13:05 UTC (9 hours ago)
(HTM) web link (asciinema.org)
(TXT) w3m dump (asciinema.org)
| kragen wrote:
| Ilo/Konilo is pretty cool, but I already knew that. What I didn't
| know about was qemu-system -nographic.
|
| Any idea why crc is specifying a custom BIOS image? QEMU comes
| with a default one, right? Questions like these make me wish
| asciinema supported recording voiceovers.
|
| I'm guessing that the slow text screen updates are some kind of
| an artifact of unoptimized UEFI implementation, and/or QEMU,
| because I'm pretty sure Konilo is a lot snappier than this
| running under Linux, even though the Ilo implementation is not a
| highly optimized virtual machine.
| crc_ wrote:
| 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.
| kragen wrote:
| Thanks!
|
| It makes sense that it would default to using SeaBIOS; QEMU
| has a lot of options whose defaults were more reasonable 20
| years ago.
| yjftsjthsd-h wrote:
| 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)
| kragen wrote:
| Maybe we should have new command names with defaults that
| are reasonable this decade, keeping qemu-system-i386 and
| the like for backwards compatibility?
| yjftsjthsd-h wrote:
| 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.
| kragen wrote:
| Yeah, exactly.
|
| I don't think you can make those small tweaks without
| breaking tens of thousands of users' production setups
| which depend on those defaults.
| pm215 wrote:
| 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.
| yjftsjthsd-h wrote:
| _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.
| deivid wrote:
| you probably should set the serial port speed
| kragen wrote:
| Oh, I didn't realize -nographic was using a serial port.
| That's probably why it's slow!
| ddingus wrote:
| It may default to 9600... tons of devices will fall back
| to that, given no other instruction
| coolcoder613 wrote:
| There are actually two similar options, one is -nographic,
| which simply shows the serial terminal, and the other is
| -display curses, which will show the VGA text mode console on
| the terminal.
| oersted wrote:
| A Forth-like command-line shell (bash replacement) does sound
| quite interesting actually, particularly if the stack is
| displayed on the side and is not implicit.
|
| It's rather concise, most functions tend to be a single short
| line. Its syntax is minimal (or non-existent according to some),
| it's just flat white-space separated tokens. It has
| imperative/interactive semantics, in the sense that every
| successive word makes some changes on the current state (the
| stack).
|
| All of this makes it quite amenable to be used as an OS shell I
| think, it seems obvious in retrospect.
|
| The idea of starting with an empty Forth and creating a whole
| universe of automations and DSLs for your system, one command at
| a time, is quite pleasing, in a purist sense, although perhaps
| not entirely practical.
|
| Does such a shell exist? Not as minimal as Ilo, one you can
| actually use in a modern system instead of bash and the like,
| ideally with a nice display of the stack. Probably Factor is the
| most appropriate Forth-like to build it on, it already has a good
| REPL mode, it would mainly involve adding a bunch of utilities
| for practical command-line use.
| kragen wrote:
| One of the most useful ways to use Forth is as a command-line
| shell for scripting assembly-language primitives on a small
| computer, like, 64KiB of RAM or less. (Ilo has 64KiB of RAM,
| IIRC.)
| crc_ wrote:
| 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).
| kragen wrote:
| Sorry! I appreciate the correction. I forgot that it was
| word-oriented.
| crc_ wrote:
| 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.
| Nevermark wrote:
| 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.
| pjmlp wrote:
| During the 8 bit home computer days Jupiter Ace, and ROM
| replacements for ZX Spectrum.
| delaminator wrote:
| The BBC Micro had / has a ROM so you can boot straight into it.
|
| https://www.acornelectron.co.uk/info/electron/acornsoft_adde...
|
| I still have mine
| kjs3 wrote:
| There was also the Jupiter Ace[1], which was sorta a Sinclair
| ZX with Forth in ROM.
|
| [1] https://www.jupiter-ace.co.uk/
| rpcope1 wrote:
| Honestly I've experimented with doing something basically like
| this doing a bunch of modifications to zforth and using it on
| RP2040 and RP2350 and it actually works really nicely. It's
| amazing the functionality you can fit down onto those MCUs
| basically building an old school computer with a Forth
| interface like the Canon Cat was.
| gjvc wrote:
| the name "ILO" clashes with "Integrated Lights-Out" management as
| used by (or was used by) some server hardware vendors.
| imglorp wrote:
| IPMI - standard DRAC - Dell iLOM - Sun/Oracle
| iLO - HP IMM - IBM
| buildbot wrote:
| XSCF - Fujitsu/Oracle SPARC
|
| (I wonder how they got that acronym)
| kragen wrote:
| It looks like they generated random four-letter
| combinations until they found one that wasn't used.
| imglorp wrote:
| Possibly eXtended System Control Facility.
| buildbot wrote:
| Ooo also, there is the RMC in some HP Alphaservers
| LargoLasskhyfv wrote:
| eXtended System Configuration Facility?
| p_l wrote:
| BMC - vendor neutral RedFish - Current DMTF standard
| replacing IPMI ALOM - sometimes encountered in the wild
| as part of iLO :O HMC - IBM on non-x86 systems (except
| OpenPower), not compatible with anything else RSA -
| used to be IBM IMC - Cisco
| crc_ wrote:
| I wasn't aware of the clash when I chose the name,
| unfortunately.
| throw0101c wrote:
| Ah, Forth-as-BIOS. Memories of Sun SPARC (and Apple PowerPC):
|
| * https://en.wikipedia.org/wiki/Open_Firmware
|
| * https://apple.fandom.com/wiki/Open_Firmware
| davidw wrote:
| No reference in those articles to the open firmware song?
| Pity...
|
| https://www.youtube.com/watch?v=b8Wyvb9GotM
| DonHopkins wrote:
| : OpenFirmwareSong ( - ) \ By Mitch Bradley.
| \ Sung to the tune of "The Flintstones".
| ." Firmware" cr ." Open Firmware" cr
| ." It's the appropriate technology," cr ."
| Features" cr ." FCode booting" cr ."
| Hierarchical DevInfo tree." cr ." Hack Forth" cr
| ." Using Emacs on the keys," cr ." Save in" cr
| ." NVRAM if you please." cr cr ."
| With your" cr ." Open Firmware" cr ."
| You can fix the bugs in no time" cr ." Bring the
| kernel up in no time" cr ." We'll have an FCode
| time!" cr cr \ Thank you and good
| night! reboot ;
| DonHopkins wrote:
| When Mitch Bradley put OpenFirmware on the OLPC (One Laptop Per
| Child), he implemented this easter egg:
|
| >You may be amused to know that the firmware has an Easter Egg
| of the Conway's Life. If you press the rocker pad (left side of
| screen) to the right after powering on, you will get a
| randomly-select amusement, one of which is Life. It uses the
| traditional life-death rule with a wrap-around field, and
| initial conditions that result in a fairly long number of
| generations before steady-state. Specificially, the initial
| state is a glider gun and an R-pentomino. The pentomino
| evolution eventually wrecks the gun, but things get pretty wild
| for awhile as gliders wrap around and interact with the debris
| from the pentomino. It almost stabilizes several times, but
| then something will set off another burst of activity for
| awhile before it finally dies out.
|
| https://news.ycombinator.com/item?id=21049568
|
| DonHopkins on Sept 23, 2019 | parent | context | favorite | on:
| OLPC's $100 laptop was going to change the world (...
|
| That's Mitch Bradley's Open Firmware Forth, which was also on
| Suns, post-NuBus PowerPC Macs, Pegasos, and IBM Power Systems!
|
| I used to call it "L1-A Forth", because that's the Forth you
| got when you pressed "L1-A" on a Sun keyboard to get into the
| boot monitor. He also made a great version of that Forth system
| with a metacompiler that ran under Unix (Forthmacs), which I
| used a lot.
|
| https://github.com/MitchBradley
|
| https://github.com/MitchBradley/openfirmware
|
| https://en.wikipedia.org/wiki/Open_Firmware
|
| https://web.archive.org/web/20121119070656/https://elinux.or...
|
| http://macos9lives.com/smforum/index.php?topic=1965.0
|
| https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs
|
| Also:
|
| https://news.ycombinator.com/item?id=38689282
|
| >Mitch Bradley came up with a nice way to refactor the Forth
| compiler/interpreter and control structures, so that you could
| use them immediately at top level! Traditional FORTHs only let
| you use IF, DO, WHILE, etc in : definitions, but they work fine
| at top level in Mitch's Forths (including CForth and Open
| Firmware).
|
| More about Mitch and OpenFirmware:
|
| https://news.ycombinator.com/item?id=29261810
|
| https://web.archive.org/web/20090920123423/http://radian.org...
|
| >And lest you think this is some kind of Apple-paid rant, I'll
| mention Mitch Bradley. Have you read the story of Mel, the
| "real" programmer? Mitch is that guy, in 2008. Firmware
| superhacker, author of the IEEE Open Firmware standard, wrote
| the firmware that Sun shipped on its machines for a good couple
| of decades, and in general one of the few people I've ever had
| the pleasure of working with whose technical competence so
| inordinately exceeds mine that I feel I wouldn't even know how
| to start catching up. Mitch's primary laptop runs Windows.
___________________________________________________________________
(page generated 2025-10-21 23:00 UTC)