←back to thread

237 points 0xCaponte | 3 comments | | HN request time: 0s | source
Show context
jvanderbot ◴[] No.44604300[source]
I love the contrast in "Low tech/bootstrapped tech" this way vs, say, duskos.org. I call this "rabbits vs forth" tech bootstrappers. [1].

It's somewhat strange to me that their tech journey is so narrative and ends up with a VM stack, rather than any kind of salvaged / repurposed hard tech. But then again, I'm probably on the forth side of the spectrum.

https://jodavaho.io/posts/rabbits-or-forth.html

replies(4): >>44604820 #>>44604869 #>>44604888 #>>44605710 #
jdiff ◴[] No.44604869[source]
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.
replies(1): >>44606296 #
kragen ◴[] No.44606296[source]
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.

replies(3): >>44606444 #>>44607404 #>>44611152 #
d66 ◴[] No.44611152[source]
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.

replies(2): >>44611719 #>>44612470 #
kragen ◴[] No.44611719[source]
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.

replies(1): >>44611941 #
1. d66 ◴[] No.44611941[source]
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.

replies(1): >>44611969 #
2. kragen ◴[] No.44611969[source]
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.
replies(1): >>44612244 #
3. d66 ◴[] No.44612244[source]
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.