@Tuvok

keep em coming

@OlafS25

Whenever a subject of this nature is brought up in any Amiga forum, I remember all of the doom-and-gloom in the Amiga magazines around 1989-1990 concerning Workbench 2.0 being incompatible with around 60% of the Amiga software at the time. When 2.0 came out, I upgraded. I eventually got a kickstart switcher to run old games. I found the upgrade worth it even though it introduced some incompatibility. If AmigaOS 4.3 or higher breaks compatibility with 68k, there will be workarounds. The new features will be worth the change in my opinion.

@AmigaOldskooler

@Goos

Cool! Thank you!

Does AmiBoing still work for Hi-Score saving? Maybe I lost my password, I can't log in.

@328gts



69043 I'm right behind you! hahaha

@LiveForItQuote:

Interesting video, thanks! I could follow and more or less understand up until AWS Lambda, then I was lost.

@tao

forget DE/AA OS5, it was Amiga Inc project, that is out of the picture..

Not a lot information has shared about sate of SMP in AmigaOS4.1..
so we left guessing...

The fundamental issue for SMP is that core do not see the same content, etch core has unique L1 cache.. when data is shared between the core, the L1 cache, most be synchronized.

https://www.youtube.com/watch?v=r_ZE1XVT8Ao
https://www.youtube.com/watch?v=7yrK_9PderQ

protocol-driven cache coherence, has a lot issues.
1. Lack of Scalability (The "Bus Traffic" Problem)

Snooping Protocol Limits: Common hardware protocols often rely on "snooping" (broadcasting) to inform other cores of changes. This works well for a few cores, but as the number of cores increases, the traffic on the interconnect bus becomes a massive bottleneck, slowing down all processors.

2. High Performance Overhead (Latency and Bandwidth)

Coherence Misses: In a multiprocessor system, if multiple cores constantly write to the same data (false sharing), the hardware must invalidate the cache lines in other cores. This leads to high cache miss rates, which are far more costly than simple memory latency.

3. Inflexibility and Inefficiency

the basic issue you can do protocol-driven cache, but it inefficient, because flushes caches too often, you want the OS to control this..

this comes down to ownership of the data, what core has accessed what data, you don't want the cache to be flushed when its not needed, but you do want to flush it, if you most do so. so keeping tack of what core, did what when. to what data..

"to what data" part is the issue in AmigaOS..

Its up to AmigaOS programs to snoop public lists, because there is lack of locking mechanisms, that specify what data, that is locked, we often have to use the most powerful tool to get ownership, by disabling multitasking, for short periods. Instead of proper lookup functions. Lets say I want to obtain a task or process structure by pid, without blocking the OS, and without risk of reading something that might be freed from memory, without notice. Maybe I want to obtain a msgport by name. There is function called FindPort but does not guarantee ownership or shared lock. The msgport can be deleted without notice. unless you prevent other task form running.

dup post

dup post

@Hans

Your 100% right, the ability for an LLM to generate Linux code is pretty solid. Creating OS 4 code is a struggle for sure. The use of an MCP helps a TON, but, as you point out, most of the examples are outdated and can confuse it.

I have provided updated examples that strongly positively influence the final output.

It's going to be an interesting area over the coming months. I hope this starts the discussion to build a repo of solid code examples so anyone can make good OS 4 code with an LLM.

Cheers,
Bill

@rjd324
@all

My mistake, I forgot to post the date!

Anyway, it's this coming Saturday

Thanks for the suggestions. Based on no real consensus I figured I'd go with Arch since I've used it before but after one failed attempt at getting it to boot I decided life's too short and went with Manjaro.

Oddly it's the only distro I've ever tried that doesn't detect any speakers attached to my onboard sound but I'll sort that later. Hopefully. I already have my second GPU isolated and ready to mess about with qemu.

And it has officially turned into amigaworld.net. Congratulations!

The definition of "68K support" has meandered over the course of this thread, but it appears to come down to Exec's current design holding back SMP and introducing security and stability issues. I'm not currently much of an Amiga developer, so can't get much more technical than that. From what I recall of the Hyperion "legal papers" posted to another site, their mandate was originally a quick and dirty port to PowerPC. I think the original idea was that OS5 would be along shortly (within a decade?) and this would be good enough. But there was no SMP when all this was being worked out, and here we are 20 years later.

I don't know where @LiveForIt gets his information, but if this is the current state of Amiga SMP

Quote:

then yes, something has to change. Apparently the Extended Memory API for virtual memory is quite straightforward, but even that doesn't get used. Part of me wishes this could be put off until we've done everything once -- hello new sound API, new printer API, Unicode, NGFS for everyone, etc.! But again, here we are.

I'd love a fancy system using a real hypervisor (would like to try Linux NixOS sometime), but the quick and dirty solution this time does appear to be further integrating EUAE. I wonder if the interest in this thread mirrors A-EON's and Hyperion's priorities? OS 4.2 without real SMP would be a great disappointment.

@all

Interesting discussion. My first reaction to this thread's title was "of course not!" However, I see that the discussion is much more nuanced.

Adding essential modern OS features will definitely need a backward-compatibility break. But, that doesn't mean that we can't maintain the ability to run old AmigaOS software via a sandbox of some sort.

I put some thought into how this could be done a while ago, and recorded it in my "Saving AmigaOS" series. I see some similar ideas being thrown around here. The "Saving AmigaOS" series is part of the Kea Campus Archive, which is available here.

Hans

@tekmage

I did a quick skim-read of your blog post, and was impressed with your attempt to solve the biggest problem with AI code generation for AmigaOS: the lack of good example AmigaOS source-code. LLMs are only as good as their training data. They generate decent code for common software tasks that match code in their training data. They suck with novel stuff, and anything for which they haven't been trained.

Your solution is to directly give the AI agent AmigaOS-specific example code.

Did you find enough example code for this to work?

Hans

@AmigaOldskooler

List updsted

@LiveForIt

Thank you. I really appreciate your explanation.


---
redfox

Hi All,

I published a blog on using Google's Antigravity to produce OS 4 code:

https://os4coding.net/blog/tekmage/will-ai-make-2026-year-amigaos-4

I'm currently having it finish the ZuneFig OS 4 port. I hope to have it ready around end of March.

Cheers,
Bill

OpenSuse here works well

That's been my distro of choice since the AmigaOne pre-os4 days.