Jarkko Sakkinen
Posts
5356Following
346Followers
532OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 2 days ago
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
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
0
2
5
Jarkko Sakkinen
jarkko
Edited 2 days ago
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.
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.
0
0
2
Jarkko Sakkinen
jarkko
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.
It's not very complicated to do a basic one, and it can be easily implemented first as a separate application.
0
0
0
Jarkko Sakkinen
jarkkoOK so you can without v4l2loopback.
Smoke test:
gst-launch-1.0 \
videotestsrc ! \
video/x-raw,format=YUY2 ! \
pipewiresink mode=provide \
stream-properties="properties,media.class=Video/Source,media.role=Camera"
iPhone/Airplay:
uxplay -vs 0 -vrtp "config-interval=1 ! udpsink host=127.0.0.1 port=6000"
gst-launch-1.0 -v \
udpsrc port=6000 caps="application/x-rtp,media=video,clock-rate=90000,encoding-name=H264,payload=96" ! \
rtph264depay ! decodebin ! videoconvert ! \
video/x-raw,format=YUY2 ! \
pipewiresink mode=provide \
stream-properties="properties,media.class=Video/Source,media.role=Camera,node.description=iPhone Camera"
Test page used: mozilla.github.io/webrtc-landing/gum_test.html
In Firefox the config option you’re looking for is called media.webrtc.camera.allow-pipewire.
3
1
2
@ethorsoe It's weird. I've looked up on Matrix like every five years and there hasn't been a single client to consider even as half-decent. There's no like "user experience".
Like even as archaic as mutt there's really well considered user experience and that's why it is so effective (and e.g., I still use it).
Like even as archaic as mutt there's really well considered user experience and that's why it is so effective (and e.g., I still use it).
0
0
0
And not understanding the function, up- and downsides etc. of different ways the license open source software gets people ripped off these days.
And that's why e.g. Linux self-governs it so well because it has a proper license enforced legal framework to do so.
And that's why e.g. Linux self-governs it so well because it has a proper license enforced legal framework to do so.
0
0
0
Jarkko Sakkinen
jarkko
Does kernel.org have Matrix? This use would be really mainly for kernel stuff.
And actually if I want personal Matrix, I'd like to create a separate one for that.
And actually if I want personal Matrix, I'd like to create a separate one for that.
1
0
1
Jarkko Sakkinen
jarkko
RISC-V with MMU has neither complete spec: https://marcin.juszkiewicz.com.pl/2026/03/10/risc-v-is-sloooow/
0
0
0
@pinkforest LGPL terms are technically very hard to implement when using Rust. How the linking works enforces GPL to anything using that dependency, even if you purposely wanted to use LGPL+ to allow fair even proprietary use (like e.g., ffmpeg).
1
0
0
@pinkforest OK so how does it allow to use copyleft licenses effectively in those tiny units? I'm lost with this talk about storage space and runtime overhead, which have absolutely nothing to do with the topic. This is about IP protection e.g. with LGPL.
1
0
0
Jarkko Sakkinen
jarkko
Edited 6 days ago
For open source to surive, I think there should be radical shift towards wider use of copyleft licenses. This is the reality now, and it is better to accept it. And BTW, I was never a huge GPL advocate before.
How to tackle this with Rust and especially cargo, is an open question that needs to be resolved.
Throwing one potential solution: theoretically cargo could detect LGPL in dependency chains and make DSOs of these crates, which would be piggybacked into a virtual filesystem in the executable.
I'm not sure tho does that still comply for LGPL 2.1 when used e.g., in proprietary context.
There's also ABI work ongoing to get a stable DSO ABI for Rust but perhaps distribution problem could be resolved without resolving the ABI problem?
How to tackle this with Rust and especially cargo, is an open question that needs to be resolved.
Throwing one potential solution: theoretically cargo could detect LGPL in dependency chains and make DSOs of these crates, which would be piggybacked into a virtual filesystem in the executable.
I'm not sure tho does that still comply for LGPL 2.1 when used e.g., in proprietary context.
There's also ABI work ongoing to get a stable DSO ABI for Rust but perhaps distribution problem could be resolved without resolving the ABI problem?
2
1
4
Jarkko Sakkinen
jarkko
I totally get now why Logic Pro is AU-only. Having multiple plugin hosts in a DAW has devastative effect on latency compensation.
By having only CLAP latency compensation becomes a problem, which is elegant to resolve, not least because the standard has this inevitable reality recognized and addressed.
Thus, in my world everything is CLAP :-)
By having only CLAP latency compensation becomes a problem, which is elegant to resolve, not least because the standard has this inevitable reality recognized and addressed.
Thus, in my world everything is CLAP :-)
0
1
0
Jarkko Sakkinen
repeated
repeated
openSUSE Linux
opensuse@fosstodon.org#openSUSE is dropping pcr-oracle in Full Disk Encryption #FDE. systemd-pcrlock now handles #TPM2 policy, fixing rollback attacks and simplifying maintenance. Migration is just two commands! 🔒🐧 Find out more. #Linux https://news.opensuse.org/2026/03/11/dropping-pcr-oracle/
0
5
0
@pinkforest
Recipes:
1. Have a local Git hosting.
2. Understand in detail your licensing framework.
3. Never publish until understanding both source code and licensing framework in-depth.
4. Learn about supplemental claims. Look examples of this. Plugin hosts is one of the examples where this needs special attention.
5. Learn not to publish because the opposite is preprogrammed feature of human psychology. We like to show our shit too eagerly and sometimes this causes troubles :-)
6. For the rest of your life, for better or worse, failing or not failing, you plan everything when it comes to:
6a. licensing
6b. releases (e.g. time line for initial publication)
7. Understand the source code. Don't push anything until you do. There are no ways to get around this. By doing this e.g., LLM becomes a tool, and you become a contributor.
There's stuff that Rust and also Cargo could do here and change the game a bit but enough is enough, let's save for another day :-)
Recipes:
1. Have a local Git hosting.
2. Understand in detail your licensing framework.
3. Never publish until understanding both source code and licensing framework in-depth.
4. Learn about supplemental claims. Look examples of this. Plugin hosts is one of the examples where this needs special attention.
5. Learn not to publish because the opposite is preprogrammed feature of human psychology. We like to show our shit too eagerly and sometimes this causes troubles :-)
6. For the rest of your life, for better or worse, failing or not failing, you plan everything when it comes to:
6a. licensing
6b. releases (e.g. time line for initial publication)
7. Understand the source code. Don't push anything until you do. There are no ways to get around this. By doing this e.g., LLM becomes a tool, and you become a contributor.
There's stuff that Rust and also Cargo could do here and change the game a bit but enough is enough, let's save for another day :-)
0
1
2