Siemens is doing BTW amazing job in open source IMHO. Bumping a lof of to cool projects they have spinned off all the time.

Reminder to myself:
npm config set prefix ~/.local

Servo is now passing 1.9M subtests at wpt.fyi: 1,903,187 / 2,131,264 (89,3%) 🎉
See https://wpt.fyi/results/?product=servo

reminder to myself: -DLUAJIT_DISABLE_FFI

I think I also publish at some point my personal backup tool of which I've been using for ages in various forms. I don't know how backup tools work, never used them, and it has been implemented over that basis :-) This is actualy only backup tool I've ever used.

/* KOPIO on-disk format structures */

static const uint8_t KOPIO_MAGIC[8] =
{ 'K', 'O', 'P', 'I', 'O', '7', '7', '7' };

“nippu - does one thing right”

https://codeberg.org/jarkko/nippu

I just need something simple and stupid as it is quite often :-)

I.e.,

#include <stdio.h>
#include <nippu/nippu.h>

int main(void)
{
	const struct nippu_node *node;
	const unsigned char *data;

	if (nippu_lookup(&assets, "/hello.txt", &node) != NIPPU_SUCCESS)
		return 1;
	if (!nippu_is_file(node))
		return 1;

	data = nippu_data(&assets, node);
	fwrite(data, 1, (size_t)nippu_size(node), stdout);
	return 0;
}

I sometimes wonder how many of the people who think compiler injected safety checks are great have heard about icache :-)

AI competition and deregulation in the United States have caused "pop-up" data centers to be created like mushrooms in the rain, and energy for them is largely produced with fossil fuels. Other resources, such as water, are also consumed in shocking amounts.

So remember that if you rely dominantly on agent infrastructure, it will come at the expense of basic human resources, and you will destroy the planet for future generations. Appealing to the economy is irrational, because the economy is always ultimately a virtual issue and a matter of contract.

Nvidia's hardware is quite bad in terms of energy use in terms of environmental specs, because it's half a graphics card, and not just for inference etc. designed. Only Google (maybe someone else) has energy efficiency in order, because they produce an ASIC designed for the purpose, the Tensor Processing Unit (TPU).

Tech is not problem, humans are once again. E.g., my use of inference in my sample browser pakki is probably example of such case as it runs smart sample search just fine on my X390 ThinkPad :-)

Pakki - a sample browser i'm putting together :-) it has also AI and interference run with CPU/GPU (works fine on my X390 Thinkpad).

The only AI app I've made so far...

If there's a magic button that generates all the code in the world, I can only assume that everyone is pushing that button. How I adjust my focus on topics such as AI is to look into smaller scale not as crowded areas such as local AI, which has the similar optimization challenge as all optimization challenges I love :-)

1. pfffft for FFT
2. libonnxruntime for inference
3. https://github.com/LAION-AI/CLAP/ for epoch models.

This is was hard one in its own way:

https://github.com/himmelblau-idm/himmelblau/pull/1079/changes/83c1b07599e75d8d4c86e7df4ddace3ff34383db

I.e. simple patch but finding exactly correct simple patch of unlimited choices was the sudoku here.

I left out dynamic update as it requires:

1. Detection of "no sessions for user" (probably through loginctl?).
2. Maintaining "no sessions" state while e.g. running recursive chown.

I did not figure this out yet and even if I had it appears to me to be at least complex in size as my initial patch. Since the current returns error on dynamic change, it leaves door open to add a opt-in flag for it later.

#himmelblau #linux #systemd

created a vga esque home page to fit this ao486 leisure time work: https://jarkko.codeberg.page/

for 486 SX authenticity it uses 24:8 fixed point at run-time no floats :-)

I decoupled the protected mode extender in ao486kit as its own project called TinyPM.

TinyPM is basically a single process protected mode kernel, which exists back to MS-DOS instead of shutting down when its only process dies.

TinyPM builds tpm.exe, which runs .TPM files, which are 32-bit relocatable binaries of their own format.

The project includes scripts:

- scripts/mktpm.lua: Takes base address zero 32-bit elf and creates a TPM file.
- scripts/linktpm.lua: Links tpm.exe and a .TPM file into a self-hosted executable.

Decoupled module in ao486kit:

- tinyfb: graphics library
- tinygus: hardware playback routines for GUS
- tinypm: my protected mode extender

OMG I found an *active* GUS fork of ao486:

https://github.com/xolod79/ao486_MiSTer/tree/GUS

SB16 is a CPU hog with worst imaginable sound.

486 SX-33 + 16 MiB + GUS is ideal :-) GUS is a legend, love it.

After I've landed ao486 I have already +1 retroproject on my drawing board.

I happen to own one Atari STE:

1. Has a blitter and DACs
2. This one out of this world 4 MiBs RAM
3. Has a VGA adapter.

I just need to get UltraSaTan to get on going :-)

Major difference to ao486 is that i will be just m68k assembly without C (that said neither ao486 has whole a lot of C).

https://codeberg.org/sjmulder/sudo.com

I never liked writing apps until I found the joy of writing non-portable apps :-) For me non-portability is a feature. And for my personal project the only decent GUI library is either Vulkan-GLSL or framebuffer.

Even in programs I use myself I love this feature, like for instance in foot, which is the best terminal emulator for Wayland I know.

As a sidekick from my DAW project just to do something more scoped to get the code in field testing I wrote a sample browser called PAKKI.

Somewhat opionated specs:

1. libwayland
2. inotify
3. Vulkan+GLSL or uses AVX2/NEON optimized software rasterizer.
4. AI 🧟 Uses ONNX and https://github.com/LAION-AI/CLAP. Enabled text/tag search for instruments, voices, percussions, foleys etc.
5. Very basic wave editing functionalities with zero crossing detection automatically.
6. Pipewire-only.
7. DSP also in AVX2/NEON SIMDs.

I wanted to do Splice search type of in my local file system and I have now similarity search, recognization of samples to percussion and stuff like that. And it has collections/favorites type of usual features.

I'll put this out at least sooner than the DAW like within few months. This really did not exist at least not in the form I would care about it. Sononym is quite good but it has too many features and not available everywhere I want it to be (I own actually a license).

PAKKI is like test bench for GUI and DSP stuff at basic level and I think it meld as browser of audio resource in Clarity DAW...

Cron and systemd timers is my OpenClaw 🤷

I’ve had so much fun with the 486 SX-33 lately that I haven’t even touched the Switch 2 I got over the weekend.

I’m putting together a devkit for the MiSTeR FPGA ao486 core, and more generally an environment for retro game and demo-style projects. Toolchains in this space have been fairly grim so far: DJGPP, Turbo C++, or Watcom C/C++.

AO486 DEVKIT

• GCC and LLVM support. COM output is supported through a linker script, and EXE output is supported as well. A Lua script prepends an MZ header to the EXE.
• A chain loader switches to protected mode and loads the program into extended memory.
• Rather than relying on DOSBox or 86Box, I tuned QEMU very carefully. It now feels surprisingly close to the ao486 core in practice.
• If this were a 386 SX devkit, I would probably have gone with flat real mode or so-called “unreal mode”. On a 486, though, the 0x66 and 0x67 prefixes used for 32-bit instructions already eat into performance on what is still a fairly modest CPU. The pipeline is only 16 bytes long.
• There is a small proof of concept included, but only the bare minimum. I’m saving the more interesting material for my own retro projects. The idea is to provide a blank canvas built on a much better SDK.
• 486.md covers 486-specific assembly optimisation details. In practice, it is quite a different beast from either a 386 or a Pentium. This is the sort of material that is fun to read on its own, so it felt worth writing.
• The package includes the Unscii font, apparently pulled from GitHub, though I can no longer find the exact source URL. The original project is here: http://viznut.fi/gfx/fonts/
• It also includes tmodplay, a MOD player. Unfortunately, the Sound Blaster 16 implementation in ao486 is pretty awful. For that era of PC hardware, the only really good option was the Gravis Ultrasound.
• The target configuration has 16 MiB of RAM. That would have been an unusual combination back in the day, but those are the ao486 defaults, so I’m leaning into a kind of retro-modern setup. The other default was some completely absurd number.
• There is also a proof-of-concept demo with a four-layer parallax scroller and various informational texts.

I’m not really a game or demo developer myself, but I can at least provide much better SDKs, so I felt like fixing one long-standing problem in the retro scene. It is released under the MIT license so people can do whatever they like with it.

I should also check whether that FPGA core supports VESA 2.0, because that would allow 320x240 with chunky pixels. VESA 1.x was awful.

#Intel #486 #ao486 #MiSTeR #FPGA