Notices by Spindley Q Frog (spindleyq@mastodon.social), page 6

@six ok I need the source for this

Oh shit I just realized I could prepare speakers notes and dump them to the serial console :D

I have conquered my RAM problems by removing slide compilation from the picture altogether - each slide is now stored in a seperate file, which is thrown at the Jorth interpreter directly. The word to parse strings, when run in non-compile mode, overwrites the same block of memory every time it encounters a new one, so no more than one bullet point lives in RAM at a time.

@carver yep! Though it's one thing to read people claim it, it's another to live it firsthand

Progress: was able to reduce the amount of "near" data to the point that all BGI fonts load (I _really_ wanted GOTH.CHR for a truly illegible title card), made a really cool mid-presentation in-game demo, wrote a bunch more slides

Setback: now the sheer amount of text blows through my RAM budget for compiled Jorth code

@endomain I'm glad! Honestly this one has been hanging over me for months, so I'm kind of glad to finally be tackling it

@pupy Text scrollers that are nothing but five minutes of rambling about how late it is and how you need to put some text here followed by a long string of greetz are not interesting to look at!!

Arrrgh I was getting super weird results calling farmalloc and pulling my hair out and it turned out I just forgot to #include <alloc.h> so the compiler assumed a 16-bit return value instead of giving me a sensible error or warning

@pupy I like the demoscene a lot in theory

But there are a LOT of reeeal boring demos

Some decent music though

@pupy nerds like to watch textured cubes fuck

I need to rethink using the word "easily" when hard 64kb memory limits are involved. I assumed BGI would load fonts into dynamically allocated "far" RAM, but instead it tries to load it into the data segment and fails if I don't have 18kb of 64kb free. This sucks!

I can't switch to the "compact" memory model (which makes all data pointers 32-bit "far" pointers and allows more than 64kb of data) without significant extra work, because Jorth is built on the pervasive assumption of 16-bit pointers. I'd have to significantly rework string handling at the very least.

It seems needlessly difficult to say "store this big statically allocated array in a new segment and refer to it with a far pointer but keep everything else in one near block" :/

Just, a rare overwhelmingly positive presence in this fucked up industry, and though I never met him, I already miss him.

I haven't read / watched as much of his work as I should, but I recently listened to a talk he gave about TiddlyWiki, which happened basically because he thought TiddlyWiki was cool and he wanted to hang out with the author. So why not propose a joint talk at a conference with the author and then hack up some weird Erlang tooling to connect all the TiddlyWikis in the world together? https://youtu.be/Uv1UfLPK7_Q

@nicknicknicknick who won Most Wizards this year?

@thomasfuchs daaaaaaamn

@thomasfuchs I own an official After Dark Flying Toasters tie and it is one of my most prized posessions

@dosnostalgic still rad!!

@dosnostalgic is that Asteroids bit playable??

@polychrome Thank you!