My experience jumping from SAM460LE to X5040.

@kikems


Your cats seem to have found a nice comfy spot !

Gart RX/HD driver is available also for 460 and is working very well since months. Simply there is no public update of it but don't ask me why

@afxgroup

It's a great news for all SAM460 owners, better news when it's available. Congratulations for Hans, he resolve an endemic and historical problem with coherence caches in SAM systems.

We can add also the unreleased kernel fix for Pegasos 2.
AmigaNG Mysteries..

The mystery is simple; just like with the 68k, AmigaNG can now be emulated.
Luckily (for them), good hacking isn't interested in AmigaOS emulation.
Otherwise, it would have already been done.

Clearly, real hardware is always best for anything.

@afxgroup
Quote:
I really hope it will eventually make it to the surface (I wouldn't mind if it would be as a part of new ES version, AmigaOS 4.2 or simply a standalone product like RadeonHD driver). Definitely, it is a highly demanded and absolutely crucial piece of software for Sam460 users.

@Djk83
Sam460 users probably have it best of all AOS4 devices when it comes to updating their equipment.
I think it could always be worse if you bought the A1222+ under the influence of “marketing.” Zero nothing... not even a hint of an update.

@kikems

congrats I went from a Samflex@800 to X1000 and still enjoying the boost and waiting for the day we can finally use our extra core(s)

@328gts

Quote:

I don't want to take away your illusion of multicore support, but it's not just the kernel that has to provide this.

All the software we already use under AmigaOS 4.1 has to be multithreading-capable, and I don't think this is the case.

@smarkusg

Quote:
Two years ago, when I was starting to consider buying a native hardware for AmigaOS 4 and was gathering information, I got this odd feeling that people pay fair amount of money for their machines (which are brand new commercial products) but then have to rely on forums and community to solve any problems they may possibly encounter. While I really do appreciate the awesome community support (and this actually raised my interest in the topic even more!), I withheld my decision for a while because of this potential lack of support.

I don't have any personal experience with other machines and hence cannot comment on that, but certainly I'm very happy about how ACube approaches this. The support is there, and definitely Sam is alive and kicking! It's a great feeling, knowing that your favourite platform is under active development (such a convenience that with update 2015.d, finally I don't need to switch keyboards to access the UBoot).

Even if at some point in time I will choose to buy more powerful hardware, I will certainly keep my Sam460 with me.

@Maijestro

Quote:

At the same time, as long as the OS itself does not support multithreading, there's probably no motivation for developers to go that way. Correct me if I'm wrong, but I believe that once SMP support is there, the software utilising the new possibilities will start to emerge.

Right or wrong, I've carried the impression that the difficulty adding SMP support was because the developers were trying to make it work for legacy software. If it's a matter of bolting on new API's, I'm okay with that. There isn't such a mass of OS4-specific applications and games that the important software couldn't be rewritten/recompiled. I'll take any progress at this point.

Since there already exists multicore hardware, and correct me if I am wrong, multitasking especially when doing processor intensive things should be somewhat improved with an SMP kernel.

@Maijestro

Quote:
Not quite. Even single threaded programs can benefit from SMP, because tasks from other apps are running on different cores. Let's say you're running a video player, email client and web-browser at once. Even if all of them were single threaded (which they almost certainly aren't), they'd still get to run on one core each on a machine with more than 3 cores.

When running one app, you still get the benefit of multi-threaded drivers an OS processes being able to run on other cores.

So the overall performance is still higher... until the apps hit an external bottleneck such all trying to access shared but slow hard-drive.

Hans

I remember the first multiprocessor implementations in the era of MacOS 7 and Windows NT to XP. Usually use a MP library for some apps that's really send diferent task of aplication to diferent processor, really was't multithread or multiprocesing system simply manage diferent parts of app to the next free cpu.
Some apps like Lightwave can run on multiple processors but speed of render not was 2 or 4 times faster only increment around 20-30% with 2 processors and 40% with 4 processors. But if you launch multiple instances of lightwave on old Windows NT-XP every instace of app launch to different procesor.
For example If you have 2 processors and launch 2 instances of Lightwave and send render task, every render task was running on diferrent cpu, this give you double speed rendering but you need double of ram to run two times the same app. If you load only one Lightwave and send render task to Multiprocesor libraries you only obtain 20-30% of increment in render speed.

Today with modern OS multiprocesing and smpt apps really works but was a fake multiprocesing apps and OS in the era before Windows 7 and MacOSX.
An implementation like older OS and apps that simply send new tasks to next free core or the core with less workload It should be possible without making a change to AmigaOS that could cause incompatibilities and break system for existing apps. This is not the best multicore architecture but it can be a useful implementation for Amiga NGs with multiple cores. Adding a new Multiprocesor.library that can help you to send diferent task of new apps to different core can be usefull for new apps or games, for example if a game with an multiprocesor library in mind detect more than one core, can send IA of game to one core and the other task of game to other core and left main core free for OS.

I'm not an experienced developer, all of this is based on my experience as a user with multiprocessor computers in the 90s and 2000s. The early implementation of multiple processors for MacOS and Windows was easy because they did it this way and it didn't interfere with all the applications that were already developed without multiprocessing in mind. As Hans say, simply send every app to the next free core help user experience without make radical changes in the AmigaOS. It is a very crude implementation of the multiprocessor for the OS but should be easy and fast to implement than new OS with real multithread manager.