awesome-uxn

during storage). consequently, if your computer needs batteries, after 10 years you're dependent on access to not just a market but a full-fledged industrial economy to keep your computer running. a friend of mine in rural romania has been trying to build a usable lead-acid battery from scratch to provide energy storage for his solar panels, and it's motherfucking difficult without that supply chain 2. batteries have a lot of failure modes that destroy the devices they power. overheating, swelling, leaking corrosive electrolytes, and too much voltage are four of them. if these failure modes were very rare (like once in 100 battery-years) that might be okay, but they aren't for me these are fatal flaws, but for others they may not be. if you can afford batteries, you can run for one hell of a long time on a single 18650 lipo on a milliwatt. a coin cell can deliver a milliwatt for a month as for uxn, uxn is the first attempt at frugal "write once, run anywhere" that's good enough to criticize. everyone should read devine's talk about its aspirations (https://100r.co/site/weathering_software_winter.html) however, uxn is not frugal with cpu, or fast, nor is it good for programmer productivity, and it’s not all that simple. It’s designed for interpretation, which inherently means you’re throwing away 90% or 95% of even a single-threaded cpu, and it’s not designed as a compilation target, which means that you’re stuck programming at the assembly-language level. This is pretty fucking fun, but that’s because it makes easy things hard, not hard things easy; the offgrid notes lionize oulipo (https://100r.co/site/working_offgrid_efficiently.html) as a result of the efficiency problems, the platforms with complete uxn implementations (see https://github.com/hundredrabbits/awesome-uxn#emulators) are the luxurious ones: microsoft windows, linux, amigaos, the essence operating system, anything that can run sdl or lua and love2d, gameboy advance, nintendo 64, nintendo ds, playdate, and the nook ereader: all 32-bit or 64-bit platforms with ram of 4 mebibytes or more, except that the gba only has 384 kibibytes, and there were amigas with as little as 512k (though i don’t know if they can run uxn). more limited machines like the gameboy, ms-dos, and the zx spectrum do not have complete uxn implementations (384k is the same amount of ram as the apollo3, so it's probably feasible, as you say) the uxn machine code is basically forth. forth is pretty aesthetically appealing to me, and i've gotten to the point where forth code is almost as easy for me to write as c code (though i have to look things up in the manual more often and have more bugs). however, it's much, much harder for me to read forth than it is to read c. it's harder for me to read forth code than to read assembly for any of 8086, arm, risc-v, i386, or amd64. possibly i just haven't written enough forth to have the enlightenment experience yet, but currently my hypothesis is that forth is just hard to read and that's it, and that the really great thing about forth is not actually the language but the interactive development experience the varvara display model is not a good fit for the memory-in-pixel displays, which only have one bit per pixel, while varvara requires two. also, evaluating things 60 times a second is not a good fit for low-power systems of any kind. and i'm not sure how well the existing varvara applications will work at 400×240 or tolerate a requirement to use fonts many pixels tall in order to be readable (a lot of the above notes are from xpasm.md in http://canonical.org/~kragen/sw/pavnotes2.git/ if you're interested in the context) as for tools for software development, program launching, editing text, editing fonts, editing other graphics, and sequencing music, i'm confident i can write those myself if i have to. i've written a compiler in a subset of scheme that compiles itself, a compiler in a forth-like language that compiles itself, various toy text editors, various virtual machines in under 150 lines of code, and various pieces of music synthesis software, and i've designed a few fonts of my own (though not using software i wrote) maybe i should set up a patreon for this or something, maybe people would be interested in supporting the project

rstanding is that if the power loss isn't too great, an all-metal internal screw terminal[1] might improve device durability: * The power source could be replaceable. AA, AAA, LiPo, solar, etc * If you don't solder to the metal part, even sandpaper or a conveniently shaped rock could remove oxidation * For a case, internal screw terminals could turn a charging port into an easily replaceable component ## 2. UXN/Varvara: From your blog, I see an "artemis apollo 3 board"[3] is being used. From a Sparkfun page[4], it seems to have enough ram to host graphical Varvara. I was initially doubtful of UXN despite loving the idea, but: 1. The UXN community seems to have built a self-hosting ecosystem[5] of: * development and GUI ROM launching tools * text, font, and graphics editors * music sequencing tools 2. The UXN VM is light: 64k system ram, 4-bit 2-plane color, and misc state and debug 3. The core UXN VM is simple: a minimal implementation fits in under 150 lines[6] of C89 [1]: https://en.wikipedia.org/wiki/Screw_terminal [2]: https://wiki.xxiivv.com/site/varvara.html [3]: https://blog.za3k.com/zorchpad-update-cardboard-mockup-mk1/ [4]: https://www.sparkfun.com/artemis [5]: https://github.com/hundredrabbits/awesome-uxn [6]: https://wiki.xxiivv.com/etc/uxnmin.c.txt