[jdiff]

With their stance of permacomputing, you don't think the two go hand in hand? A simple VM that can be implemented quickly on almost any hardware or underlying tech stack you can scrounge together? The only thing they'd be really against is designing new hardware to run Uxn "natively," which would seem to push you exclusively to reuse what you have.

[kragen]

100r's Uxn/Varvara aspires to be that, but that's not the same thing as succeeding at it. AFAIK the smallest computer with a full Uxn/Varvara implementation is a Nintendo DS [correction! Game Boy Advance], which is faster than the Sun workstation I was using in the 90s (though it has less RAM). You probably aren't going to get it running on an eZ80-based TI calculator, for example, or an Arduino UNO.

It's a good first step in that direction, the first attempt at permacomputing good enough to criticize.

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

[jdiff]

The Gameboy Advanced has a full emulator with the standard devices, and incompleteness is often not a dealbreaker as long as it supports the devices you need. There are incomplete emulators for ESP32 and STM32 based devices, DOS, and even an extremely limited emulator for the original Gameboy.

Many of these might be more powerful than your 90s workstation, but if someone's scavenging technology they're more likely to find a Chromebook than a Sun.

[kragen]

You're right, that's smaller. I think I was confusing the DS and the "Game Boy Advance", because I was thinking of a machine with a few hundred K of RAM. The GBA is a 16MHz ARM7TDMI with 288KiB of RAM, not counting the 96KiB of VRAM; the Nintendo DS's main CPU is a 67MHz ARM946E-S, and it has 4MiB of RAM.

As for what you're more likely to find in usable shape in a hypothetical collapse scenario, it probably depends on what kind of scenario you're talking about. Certainly vastly more Chromebooks exist than Suns, but the Chromebook's SSD only has a few months of data retention, so you probably won't be able to get it to boot if it's been sitting around unpowered for many years. All the Sun SPARCs are going to be in non-working order because their IDPROM batteries will have died, but some older 68000-family Suns like the 3/60 I theoretically still have are probably okay, because their IDPROMs are actually PROM rather than battery-backed RAM.

(Of course you also have to worry about capacitors drying out.)

What's vastly more common than Chromebooks, Suns, or GBAs, though, are Flash-based microcontrollers like the AVR family and 48MHz members of the STM32 family. (You can probably salvage a couple out of the wreckage of the drone that killed your parents.) And those will probably still be in working order, unlike anything SSD-based. I don't think Uxn is a good fit for those chips.

In a multiple-centuries sort of collapse scenario you also need to worry about the retention time of the NOR Flash in these microcontrollers. Hopefully if they lose their memory you'll still be able to rewrite it, but if the manufacturers used Flash to implement some supposedly-read-only memory, they might not bother to mention it.

In the collapse scenario we're actually in at the moment, GBAs, Nintendo DSs, and Chromebooks are all immensely more expensive than such microcontrollers. That seems likely to remain true even after the PRC invades Taiwan in a few years.

[jdiff]

Could you explain more what's wrong with the STM32 family as a target? The Playdate's got a complete implementation and an STM32 heart. And other members of the family have seen other non-system-specific implementations, although neither is complete. I'm not deeply familiar with the family, so insight is welcomed, but I don't immediately see why they'd be unsuitable.

And while they're far more numerous, ultimately I think they're less likely to be used for personal computing. Sifting through the ruins, if you can find any functioning personal computer, you can get started immediately. Even if you don't have a compiler, you certainly have a web browser and write permissions. All you need to bring is the emulator spec.

That's an easier bar to clear than harvesting chips, a set of other working parts, gathering documentation for each, ensuring you have tooling and likely libraries for each, and most critically: enough existing, functioning tech to program it all. But if you already have that, you already have everything you need to compute without bootstrapping a new device. Not to say it wouldn't be worth the effort, but it's not an easier or alternative path to personal computing, just a path to share or persist it.

[kragen]

The STM32 family is awesome! There's nothing wrong with it as a target! But, basically, by trying to use Uxn on most STM32s you're turning a Pentium-133 into a 386-40, with a corresponding reduction in the kind of functionality you can deliver. Also, you have to write all your software in assembly language.

The most popular model of STM32 is probably the STM32F103C8T6 https://www.st.com/en/microcontrollers-microprocessors/stm32... used on the Blue Pill, which is a 72 MHz Cortex-M3 with 64KiB of Flash and 20KiB of SRAM, consuming up to almost 0.2 watts at full speed. The Cortex-M3 is 1.24 Dhrystone MIPS per MHz https://developer.arm.com/Processors/Cortex-M3 so that's about 89 Dhrystone MIPS. Looking at historical Dhrystone results https://netlib.org/performance/html/dhrystone.data.col0.html similarly powerful CPUs include a 133MHz Pentium, a 66MHz PowerPC 602 (as used in a PowerMac 7100 or an RS/6000 250), a 100MHz PA-RISC HP 9000/715, and a 110MHz μSPARC-II as used in the SPARCstation 5.

We ran web browsers and did video playback on these; they're totally adequate for personal computing as I understand it.

As another piece of context, remember that the original Macintosh had 128KiB of RAM, 64KiB of ROM, and a 7.8MHz 68000 that achieved roughly 0.4 DMIPS (according to the above link). It could run a WIMP GUI, MacPaint, MacWrite, and a WYSIWYG version of Microsoft Word, despite its only mass storage being slow floppies, thousands of times slower and smaller than SD cards.

Currently popular personal computing machines are significantly faster. The Raspberry Pi 3 is about 2.5 DMIPS/MHz, 2201 DMIPS http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks..... So if you take CPU-bound software that barely runs fast enough on the Pi 3 and run it on the STM32F103C8T6, it will run about 250 times slower. A response that it manages in 100 milliseconds on the Pi 3 will take almost 30 seconds.

But that's assuming it's not memory-bound! The Blue Pill only has 20KiB of RAM, while the bigger machines it's being compared to typically had 2–64 MiB of RAM. You can run 64KiB of code (or data) from Flash, but not self-modifying code, because Flash can only be erased blockwise. (A minimum of ten thousand times, so this is a viable thing to do a few times a day.) You can access off-chip memories, but not at anywhere near 72 MIPS. With the LDM and STM instructions you can theoretically read and write the on-chip memory at something like 250 megabytes per second, 2 gigabits per second, while off-chip SPI (which supports DMA!) tops out at 0.018 gigabits per second, roughly 100× slower. Still, the original Macintosh's floppy was closer to 0.0001 gigabits per second.

Here are the top five most popular STM32 models listed on Digi-Key, with 53000 units or more in stock https://www.digikey.com/en/products/filter/microcontrollers/...:

US$1.73 STM32F030R8T6 (48MHz, 8KiB RAM, 64KiB Flash, Cortex-M0) https://www.digikey.com/en/products/detail/stmicroelectronic...

US$1.21 STM32G030K8T6 (64MHz, 8KiB RAM, 64KiB Flash, Cortex-M0+) https://www.digikey.com/en/products/detail/stmicroelectronic...

92¢ STM32G030F6P6 (64MHz, 8KiB RAM, 32KiB Flash, Cortex-M0+) https://www.digikey.com/en/products/detail/stmicroelectronic...

US$3.08 STM32L071CZT6TR (32MHz, 20KiB RAM, 192KiB Flash, Cortex-M0+) https://www.digikey.com/en/products/detail/stmicroelectronic...

US$3.25 STM32L071RZH6 (32MHz, 20KiB RAM, 192KiB Flash, Cortex-M0+, tiny BGA form factor) https://www.digikey.com/en/products/detail/stmicroelectronic...

So any of these devices is probably pretty capable of running the kinds of apps Uxn is directed at, if you hook up a screen and speaker to them. They have less RAM than the original Macintosh, but their CPU is around 100 times faster, and they can swap to off-chip memory, including MicroSD cards, which consume no power for memory retention, just reading and writing. When I was a kid, I ran word processors, high-level-language interpreters and compilers, spreadsheets, databases, and IDEs on machines that were less powerful than these chips in every way, including having less memory (though usually it was almost all RAM).

Take a look at https://rossumblog.com/2011/10/08/8-bit-device-kindles-ebook... and the rest of Rossum's blog by Peter Barrett to see the kinds of things all that CPU power can do despite the small RAM.

Power consumption seems worth a mention, because "minimization of energy usage" figures prominently in the permacomputing ethos as explained in https://wiki.xxiivv.com/site/ethics.html. Running at full speed, the higher-speed STM32 parts use more power, up to hundreds of milliwatts, while the lower-speed, lower-power STM32L parts are more like tens of milliwatts. By suspending execution, though, this power consumption is proportional to CPU load down to a few thousandths of a milliwatt. A Chromebook uses about 10000 milliwatts; a cellphone about 3000; and, according to https://www.eetimes.com/nintendo-gameboy-eases-down-the-road..., a Game Boy Advance uses about 200 milliwatts playing Donkey Kong.

(In human terms, 100 milliwatts is the amount of mechanical work per unit time done by pulling the pull cord to start a chainsaw or lawnmower about every 15 minutes. So, if you hooked up an electrical generator to such a pull cord, very roughly, you could keep a Chromebook running by yanking on the pull cord about every 10 seconds, a cellphone about twice a minute, a Game Boy Advance about twice an hour, or a 1-milliwatt STM32 about once a day.)

But these chips are probably not capable of running the apps Uxn is written for if they're running Uxn! I mean, if you're moving sprites around the screen or sounding tones with ADSR envelopes, that's handled by Varvara's "devices", which you can implement in native code, so they're just as lightweight as they would be in any other form. But your own application code is being interpreted by the Uxn bytecode interpreter, so 95% (my guess) of the CPU time is devoted to stack manipulation and interpretation overhead. So instead of 89 Dhrystone MIPS like a SPARC 5, you get 5 DMIPS. CPUs in this class from the above list include the 25MHz SPARCStation 1+, a 40MHz AMD 80386, an Amiga 2000, and a deskside 16.7MHz 68020 Sun 3/160C server http://www.obsolyte.com/sun3/, which was one of the very first Sun-3 models http://www.sun3zoo.de/en/history.html.

And you can't usefully JIT-compile Uxn code because it idiomatically relies on pervasive self-modification in order to squeeze a bit more performance out of the inherently expensive bytecode-interpreter strategy. Uxn is also not very suitable as a compilation target for higher-level languages like C.

So, the STM32 family is great as a target, but except for the higher-end members of the family like the 168MHz STM32F746 used in the Playdate (US$14.33 https://www.digikey.com/en/products/detail/stmicroelectronic...), Uxn is not great as a way to make them useful.

It's wonderful as a way to inspire us to imagine what could be, though!

I'll address your comments about the bootstrapping path in a second comment.

[kragen]

This is my response to your thoughts about the bootstrapping path, a sibling to my thoughts about the STM32. You say:

> Sifting through the ruins, if you can find any functioning personal computer, you can get started immediately. Even if you don't have a compiler, you certainly have a web browser and write permissions. All you need to bring is the emulator spec.

First of all, most collapse scenarios don't have an especially noticeable quantity of ruins. The Soviet Union collapsed in the 01990s; the GDP fell by half, the death rate skyrocketed, and they lost not only geopolitical influence but also significant parts of their high-tech industrial capacity. The People's Republic of China in some sense collapsed during the Cultural Revolution in the late 60s, losing significant parts of its cultural history, following the Qing dynasty's collapse in 01907. Syria is currently beginning to recover from a collapse into a civil war in 02011. Cambodia killed a quarter of its population and all its intellectuals in 01975–8 under the Khmer Rouge. The Imamate of Oman had been stable for over a thousand years until it collapsed under British bombing in 01957–9, bringing it under the control of the Sultanate of Oman, which still controls it today. About half of the Timbuktu Manuscripts were rescued from the onslaughts of Boko Haram after the collapse of Mali began in 02012, after centuries of being one of the greatest centers of learning in Africa; since then, that collapse has resulted in the overthrow of democracy by military coups in all three countries of the ASS. Suriname had a civil war in 01986–9.

If you want, you can read my slightly longer notes about most of those in https://derctuo.github.io/notes/pandemic-collapse.html; those are particular cases of recent collapses that I selected randomly in order to try to get a handle on the rough frequency with which countries collapsed.

Out of all of these cases, the only one with a really significant quantity of ruins to sift through was the Syrian Civil War, although there are a fair quantity of ruins in Ukraine now 33 years later, which you could argue in some sense resulted from the collapse of the USSR. Putin certainly does make that argument. I don't think I'll touch it any further.

If anything, booming economies like today's PRC might tend to have more ruins than collapsing societies, at least until a few generations into the collapse. People who can build new housing can afford to move out of the old housing; people who are struggling to survive have to patch the leaky pipes and the holes in the roof as best they can. The ruins all over the rural USA aren't the result of fentanyl and meth, but from people moving to the cities and selling their parents' farms to big agribusinesses.

So, let's get back to the scenario you proposed:

> if you can find any functioning personal computer, you can get started immediately. Even if you don't have a compiler, you certainly have a web browser and write permissions. All you need to bring is the emulator spec.

First, the likelihood of attempting something is only a weak inequality constraint on the likelihood of achieving it. Our intrepid hero is probably going to need those electronics hacking skills you're presupposing she lacks, because she's going to need to recap the PC's power supply and figure out how to run the computer off her car battery, which is a much easier task if your power supply needs to supply tens of milliwatts instead of tens of thousands of milliwatts. (Consider: my laptop charger died the day before last. It's a 65-watt USB-C charger and seems to be fully potted. Could you fix it? What would you have to know to build a replacement? How long will my laptop be useful without one?)

Second, where did you get the emulator spec? And, supposing you write a Uxn/Varvara emulator in browser JS, do you have existing ROMs to run on it? Or are you going to write the ROMs from scratch in Uxntal? If so, why not just write your applications in browser JS directly? My estimate is that you'll get roughly 20× as much useful computation per CPU cycle, and a browser pegging your CPU can easily double the baseline power consumption of a laptop. (In the case of this one, it goes from about 5 watts to about 10 watts.)

If you can get an emulator spec and ROMs, why not get a native-code IDE like Dev-C++ or Debian with Emacs from the same place you were getting those? A full Debian or NetBSD distribution is roughly one DVD.

If you want to prepare today for a possible future of scarcity, you can figure out how to harvest chips and put together tooling and libraries for them today.

[roughly]

> the first attempt <…> good enough to criticize.

Ooh, I like this phrase.

[kragen]

From Wiki:

http://found.ward.bay.wiki.org/view/good-enough-to-criticize

> Alan Kay described the Macintosh as the first personal computer good enough to be criticized. It was a serious step toward Kay's Dynabook. Not perfect, but in the right direction. In this 2017 interview Kay explains how he came to his vision and how it has been completely lost in mobile devices since.

https://www.fastcompany.com/40435064/what-alan-kay-thinks-ab...

While I think the implicit equation of Uxn with the 128KiB Macintosh is reasonable, the implicit comparison of me to Alan Kay is not.

[kragen]

Paywall, so, from https://web.archive.org/web/20170930235704/https://www.fastc...:

> Jobs always admired Kay, who in 1984 famously told Newsweek that the Mac was the “first personal computer worth criticizing.” Just before Jobs was fired from his first stint at Apple in the ’80s, he’d been pushing an effort to get the Dynabook built in Cupertino. The two would talk on the phone every couple of months until Steve’s passing, and Jobs invited him to the unveiling of the iPhone in January, 2007.