[d66]

I'm not sure that's true. I have an eZ80-based emulator for the AgonLight2 that is already running well enough to run some real (console-based) ROMs: https://git.phial.org/d6/uxn-ez80/

(I'm new to eZ80 assembly so the project is going slower than it otherwise might.)

The AgonLight2 has 512K of RAM and a 20 MHz CPU which is more than enough for Varvara.

I agree that 8-bit computers of the era (e.g. Pet, Apple 2, C64, TI/99a, etc.) don't have enough RAM to give Varvara its own 64k of memory (though it wouldn't be hard to design a Varvara variant with a smaller memory space) but otherwise there really aren't major barriers. As far as permacomputing goes though, there are plenty of hosts out there with enough memory to comfortably run Varvara (anything 32-bit will be fine, most 16-bit computers would also be fine).

Based on my eZ80-based implementation I think any of the eZ80-based TI calculators with 128k or more of user-accessible memory could implement Varvara without major problems.

[kragen]

That'll be fantastic! I'd be delighted to see that! That would make those TI calculators the new smallest machines with a full Uxn/Varvara implementation, and much lower power than the GBA that is the current champion there; I'd really like to get some experience with what that's like, because I've found the experience of using Uxn to be inspiring so far.

I also hadn't seen the AgonLight2 before.

One quibble, though: the vast majority of 32-bit computers are microcontrollers, and most of them have less than 64KiB of RAM. (My comment at https://news.ycombinator.com/item?id=44611710 goes into more detail about the popular STM32 family.) They would be perfectly adequate for a self-sufficient personal computing experience (most of them have more total memory than the computers I used to run Turbo Pascal on, just less RAM, plus their CPUs are 1000 times faster, and they can read and write SD cards) but probably not with Varvara.

[d66]

That's a fair point.

A few of us have been discussing a modified Varvara spec that limits the system to a smaller amount of memory (e.g. 32k, 16k, or 8k). I think with a spec like that it would unlock many implementations that are not currently practical.

[kragen]

I think a more important consideration for currently produced microcontroller hardware is the ability to run from ROM, because then you can load your program into relatively abundant Flash instead of the much scarcer RAM. Some way of using virtual memory (take a look at Forth's approach, which doesn't require hardware support but doesn't work for code, only data) would also make a big difference. All of this doesn't necessarily depend on native-code compilation; microcontroller memory is a much more tightly pinching shoe than microcontroller speed.

[d66]

It wouldn't be idiomatic Uxntal but there's a relatively simple modification where load/store is from RAM space but jump/pc is from ROM space. For a subset of existing programs it would work fine, although the assembler would need some modifications to make the memory layout(s) a bit clearer.

[kragen]

Another minor correction: the well-known TI home computer was called the TI-99/4A, and it was a 16-bit machine, sharing the same architecture as TI's ill-fated line of minicomputers.