One difference I can sense is in the interpreter. In the case of the EndBOX, I'm creating a computer to run EndBASIC on, but EndBASIC has already existed for 5 years and is multiplatform: you can write a program and have it run in your browser via WASM, in the desktop version of the interpreter, or now in this new small form factor format. In the case of Micromite, it sounds like MMBasic is specifically designed for this machine.

Which brings me to something I have been thinking about recently: I think BASIC is the least interesting aspect to the EndBOX and the thing that might hurt the concept the most (because BASIC is old, limited, legacy, who cares about it, blah blah blah). I'm starting to think that the more interesting parts of this project are what I have built to take a Rust app that uses some APIs to talk to a "generic graphical console" or to "the hardware", and have that exact same app run on the web, on the desktop, and now natively on a small computer. And for the later case, I think the pipeline I developed to take the app and generate a full SD card disk image with a trivial command to run it in a standalone manner is interesting too. Stay tuned for a follow up blog post as I elaborate on these ideas...

The Maximite series had cousins, but it also evolved into the Picomite:

https://geoffg.net/picomite.html

Some of the cousins:

The BASIC*Engine:

https://basicengine.org/esp8266.html

As discussed here:

https://news.ycombinator.com/item?id=17674944

Followed later by the BASIC Engine Next Gen:

https://basicengine.org/nextgen.html

And more recently BASIC Engine RX:

https://basicengine.org/#_what_is_the_basic_engine_rx

Unrelated...

The Agon Light:

https://www.thebyteattic.com/p/agon.html

(Which I just noticed quotes me! :-) )

And Agon Light 2:

https://www.olimex.com/Products/Retro-Computers/AgonLight2/o...

And its 6502 equivalent, the Neo6502:

https://www.olimex.com/Products/Retro-Computers/Neo6502/open...

PS what happened to your project? i liked where you were going with it.

There is a config file that you can edit within BASIC to set the WiFi up though.

* The SD card I'm using in there is not the fastest. Easy fix.

* The kernel has some annoying pauses, particularly in WiFi initialization, that add a couple of seconds of delay. To fix this, I wanted to do driver loading via modules once the shell is already up and running, but unfortunately NetBSD hasn't modularized those drivers yet and it didn't seem trivial to do. Should be possible though.

* The rc startup framework is sluggish. I've been pondering a rewrite in native code to avoid huge shell scripts and to allow for parallel execution of early boot services, and that should help -- but it isn't done. (Ideally I'd just replace init with my own thingy.)

* The file system is not read only, so there is an initial fsck that adds a bit of a delay. I want to get to a point where it _is_ read only, which would eliminate this pause.

All in all, agree that 10 seconds is very far from "instant boot", but there is a lot of room for improvement.

A Librebooted ThinkPad takes 10-15 seconds to reach a login prompt which I think is perfectly satisfactory considering that prior computers with roughly equivalent computing power (say a Cray machine) would have taken considerably longer to get fully up and running from deadstart. Think of all the tape drives, the cooling system, the frontend mini etc. that would have to spin-up, start up or initialise.

Therefore statements like “Remember when turning a computer on meant instantly jumping into code?” are confusing since I would guess that the vast majority of computer systems throughout history did not satisfy this requirement.