@neal It was like the only sound card from that era of which Amiga's 8bit DAC's were not superior.

Fast-forward, when it comes to audio, Windows up to this day has absolutely nothing offer. GUS is the only bright spot in the history of running MS operating systems :-)

By now Pipewire is the superior choice for audio in my opinion of any operating I'm aware of. CoreAudio was amazing when it first came out but compared to the current Pipewire it looks and is a relic.

That's I why I targer my Clarity DAW exactly for Linux + Pipewire. It's all about technical superiority and I want to sacrifice 0% of it. Apple made the same choice with Logic Pro.

They are about the same era but:

GUS: legendary sound
SB16: legendary bad sound

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.

@pavel thanks this motivates me to put a bit more effort to it thank you, appreciate this :-) it's my way to escape from the world of clawbot.

@pavel, and the next target after this is STE, as I said. That machine has been itching me for some time. And this trip back to 486 seems to give enough push move on that next. The hardware features and the unusually large amount of memory appeal to me.

It's also fun to try tools like devpac out and be more in discovery mode than with PC:

https://www.atarimania.com/utility-atari-st-devpac_29589.html

@pavel It's still my local NAS, which holds my local Gits :-) I can ping you once I release it. 486.md is a doc that I've putting short remarks over the course of working this.

It's my therapy project, half coding and half reading old magazines and other cool stuff that you can find e.g. from archive.org. Thus, I want to make it nice and polished and even go through my remarks before putting this out. That said this will be in shape rather in weeks than months :-)

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

I created a shitty Python script in 2011 for indexing my photos and it has stuck intact since.

Since I'm finding myself using the same script I created a new C version with:

- xxhash32 hashing. Previous had md5, which was not great choice. I dropped the support.
- For JPEG content hashing instead of opaque file hashing.
- For CR2 still file hashing but I will change this soon.
- cp alike semantics and behaviour. Skips on collision (instead of overwriting).
- I created Debian packaging files but no energy to move this forward.
- Neither sys_read nor sys_write calls ;-)

Not actually proud of the last bullet.

There's this weird "tape drive cult" still going on strong in the user space.

Now the torch has been taken by the agents and they carry worst of the 70s to the future generations and onward.

Future plans in less than five years:

1. Fix content hashing for CR2.
2. smb:// (with libsmbclient)
3. ssh:// (with libssh)

I'll put out my old backup tool adhoc-backup also out again. It was originally in bash but out of curiosity wrote the new version with Zig. It's not great but I use it all the time and release it soon'ish :-)

I don't know why I did not like it before but finally found a companion for mc: nnn :-)

It will be painful experience to switch my root 4096-bit RSA PGP key so better to time it for quantum safety.

What is the quantum safe mainstream PGP key type, which would be also kernel.org compatible pick?

MS-DOS indie gamedev, demoscene and similar "oldschool" forums usually recommend one of these options:

1. DJGPP
2. Turbo C++
3. Watcom C/C++

I possess MiSTeR FPGA with ao486 core so thought that would be a cool target to play a bit with but I need a development environment.

So... I created a development kit repository, providing tools to create MS-DOS COM an EXE files with the current GCC. It also provides ao486-simulation configs for dosbox-x and x86box. Finally it has a QEMU launcher emulating 486 SX 33 MHz, which matches ao486.

And yes, it's GCC + GAS thing plain and simple. I'm not really familiar with nasm etc. Before GAS it was TASM (Turbo Assembler) :-) Important thing here is that it has a C orchestrator and does not require FASM to provide MZ stub.

AKA edit-compiler-run delivered :-)

As a test run I have a test program does only some silly graphics but does give 486 a good test run given that:

1. 486 optimized codebase with a mentionable portion assembly (and I really did enjoy this).
2. Weird display mode in 320x240 256 color resolution and page flpping.
3. Configures memory to flat realmode (aka "unreal mode") and piggybacks lua-precalculated texture and palette to an additional .rodata_32 section.

Will be out in the foreseeable future...

#MiSTeR #FPGA #Ao486 #DOS #486

It's incredibly slow progress to get this basic UI stuff ongoing for a daw. That said, this will pay back with complex UI views daws tend to have such as track mixer and arrangement.

I've played mindgames what if I would leverage cairo or similar library, and really weighted that option with critical mindset. Then when looking deeper I cannot really guarantee same way latency as if I control rendering surface. The quality of the whole app would suffer by a factor.

Finally, a DAW can have however many data points on display animating at the same time, which is already with custom UI framework a technical challenge to render properly.

Based on these conclusions I rather spend hour or two a day doing basic UI stuff from scratch with no progress for few weeks, month or even longer than do that. It's sucks now but conditions at least increasingly will get better.

Leveragng feels attractive at first but is a route where conditions will only get increasingly worse.

It's awkward but all "similarity search" type of thing options are actually really bad. So I'll do my audio sample indexing engine. I.e. a search like e.g., in Splice.

It's not very complicated to do a basic one, and it can be easily implemented first as a separate application.

@oleksandr I guess still we settle at some point :-)

@jani