νδπ @ndpi@merveilles.town

In many cases, generality is at odds with simplicity. This is why it is so remarkable — and beautiful — to find a simple, general solution. Unfortunately the pursuit of that beauty can be a siren call for engineers, whose real-world domain rarely admits both.

The FSF needs to make some serious course corrections if they want to reverse their descent into irrelevancy.

One thing it doesn’t seem that they’ve understood is that fundamentally in a free society it’s the people that matter, not the ideas in your manifesto.

Circling the wagons around the “good old boys” club won’t do anything to improve the FSF’s claim to leadership in such a movement. New organizations without such a burden will replace them.

Going in the deep end on this and trying to integrate Cairo + Pango + OpenGL. It's a lot of work just to get some 2D graphics on the screen... Hope it's reasonably fast.

Having a bit of trouble integrating SDL2 and Dear ImGui. I'd like to use SDL2's render functions, but I'm not sure how to square that with ImGui's own rendering when they must share an OpenGL context... At the moment SDL wins, so no ImGui objects are drawn.

Eyeing The Open Book and wondering if it's worthwhile to try building one.

In other news, my Kindle auto-updated and now it will neither connect to my WiFi nor let me turn it off. Fuck off, FAANG, and quit trying to control what I do with my own damn devices!

Ok, here’s what I’m thinking. Maybe I can create some read-only blocks of Forth source as a linkable ELF file and map them into the binary at the flash area. Then you could LOAD them from user programs and FORGET them when you’re done, doing application switching in the classic Forth manner. That would keep the newly defined dictionary words in RAM, but hopefully there’s not going to be too many of those. If it’s an issue I could look at compiling them as well.

Aww man, the flash is read-only. Can't use it for block storage apparently. That's a real bummer!

I wonder what other options there are. I had considered, for example, using an SD card since you can talk to them over SPI. That wouldn't work in the emulator but it would on a real board. I'm going to have to look at how you can compile the Forth source into the hex file so that it can be written to flash as part of JTAG programming.

Fleshed out most of the core assembly primitives, including NUMBER. I’m still running in the debugger for now, but I’ve verified that basic operations like addition and subtraction work! I’ll have a read through the Forth parts of Jonesforth later; I expect they should run mostly unmodified on my kernel.

Oh wait! It's not 512K, it's 512 MEGABYTES. Holy smokes, that's a lot of data.

Currently sitting at a little under 4K when assembled and linked. There's still a few primitives I haven't implemented, but I think there should be lots of space for libraries and for block storage on the flash chip (it's 512K)

Fleshed out a minimal interpreter and got it to assemble today. No support for reading literals, few built in words. It doesn’t run yet, which is unsurprising, so tomorrow will be a debugging day! Hoping to get to the point where I can at least print the version number.

😬 Feeling a bit antsy about all the assembly I'm writing with no testing whatsoever. Writing a test harness for this stuff feels like it'd be about as much work as finishing the Forth, so I'm just pushing along and hoping I get it mostly right. Right enough to debug, at least.

Wishing there were something akin to Blinkenlights for RISC-V. It would help immensely as I'm learning the assembly language.

Spent the past hour pondering how to translate two lines of x86 assembly into RISC-V. This is going to be quite a learning experience.