screenshot
MorphOS, what are you waiting for?

> screenshot

Looks like what was shown half a year ago:

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=11102&start=34

I still would prefer OpenSCAD :D

Quote:

Needs a lot of "Boost"

Quote:


Yes, I've just added a picture to the gallery because SMP is really a milestone.

BTW: running on 12 threads

Quote:

Is it "silly SMP"?

Quote:

We don't call it like that. It's SMP with (AFAIK) the limitation that there is one main core.

Well, 'silly' or not, it seems to offer the opportunity to utilize the additional cores.

Quote:

So it is what was *previously* called "Silly SMP"?

Quote:
"Silly" means "We got it but you are still waiting"
"MorphOS NG will be AROS done right!" For sure, two more weeks.

Quote:
Indeed, but Boost is not rocket science
http://aminet.net/package/dev/lib/cppboost

The AROS64 SMP looks nice, but sadly for many users it still do not work.

I tried on many virtual machines, Virtual PC, qemu, VMWare and a real one, but the SMP Part never took place, the application (the one from the image/video) runs but do not use multiple cores all stay on Core 0. (used nightlies and compiled self from Source)

Questions on IRC are not really reached an satisfying answer, besides "bad luck" and "maybe the virtual machine do something bad in the ACPI"

I know from others that they have the same problem. I look into from time to time.. but it seems no advance here.

I wanted to play with it, add support for it to FreePascal but when I can't try that at home..... I know thats alpha state...

'Silly SMP' is better than nothing, but I'd truly be surprised if anyone ever got SMP to work 'properly' with a shared memory address OS. Seems impossible by concept alone to me.

[ Edited by KennyR 16.08.2017 - 22:13 ]

While I think this multi processing support (SMP, raher ASMP, but that does not matter that much) is quite a remarkable progress and may suggest to do the same for MorphOS I still favour a clean cut: I mean we have some things that need fixing - most imprtant of course multi processing and the address space issue (somewhat castrated 32 bit - what's 1.8 GB of RAM today with all these demanding webpages...). Introducing this will break compability to some extent eventually and would still be rather patched. Hence I prefer the clean cut: 64 bit MorphOS with SMP for the cost of broken binary compability and probably a little different API (but hopefully as similar as possible and reasonable).

What's 1.8 GB of RAM today with all these demanding webpages?
Well, if OWB 1.25 fixes all memory leaks you can live with 1.8 GB pretty sure.

Quote:

I totally agree with everything you wrote above, but hope that the MorphOS Dev. Team will add something like Run-in-UAE, or something similar, that integrates UAE seamlessly into the OS, so we can still enjoy running old Amiga software, without needing to manually start up an instance of UAE, and then choose which Amiga software we want to run within it. It would be nice to be able to just double click on an icon of an Amiga software/game, and just have it run, and also quit UAE, if the Amiga software/game is exited.

Another thing that I would like to see included in MorphOS for x64, is a way to run Linux software and games seamlessly from the MorphOS desktop. Just like AmiKit/Alice does, with AmigaOS3.x and Linux, but obviously, I would want it to be better, and not to depend on having MorphOS for x64 to be running on top of a thin Linux distro.

Quote:

No. It is a completely new approach, which does not have much in common with silly-smp.

Silly-smp was started on hosted and tried to keep most of the (user) code unchanged. It reached a state, where all started programs got distributed at task-startup to different cores. Runtime-scheduling between different cores was still missing. Worked "only" on hosted. Forbid() was quite a performance killer. But it proofed that SMP can be done.

Current approach is different ("more general") and tries to get rid of many (all) cases where Forbid() needs to halt all other cores. Was mainly developed for x86_64 bit CPUs. Up to now there is no automatic distribution of tasks to the different cores. All code runs on core0, special coded code can run on all other cores without Forbid() speed penalties. *Is really not on a state where it is of any use for end-users.* Even application developers will have no benefit either.

> I would like to see included in MorphOS for x64 [...] a way to run Linux software
> and games seamlessly from the MorphOS desktop. [...] I would want it [...] not to
> depend on having MorphOS for x64 to be running on top of a thin Linux distro.

I doubt that's technically feasible.

SMP AROS is a time for celebration.

Also AROS ARM Native is another time for celebration.

Neither have finished.

In Two Weeks, I will donate to Bounties and Patreons so Power2People L.L.C. and independent contractors can be interested in finishing. And then my desired laptop with battery door, large internal keyboard including numeric, large 17+ internal monitor, many USB and SD, ARM processor, no need for fans, Non Vidia graphics, ATI or AMD or whatever it is, is better, a laptop that does not malfunction, ... perhaps this desired laptop will exist eventually.

Also Morph S.R.L. must release SMP and 64 and other updates for MorphOS on POWER and other desired hardware. Perhaps if I donate to Bounties and Patreons they will also be interested.

Quote:

Emulator is better.

DOS BOX is an Emulator.

A-Box should also be an Emulator.

@In_Correct:

True... A-Box should be an emulator and Ambient should run outside A-Box.

The problem is, that this is a huge work:
- Define interfaces/create libraries for the outside world which is SMP/... compatible, but isn't far from the existing ones.
- Port the whole system to this... apps, etc.

Of course, on long term, the system will benefit from this, but it is not easy.

I don't think AROS has been aimed at Amiga compatibility for a long time, more at pushing the limits of the Amiga-style OS and API. They have traditionally eschewed emulation and legacy compatibility in favour of technical advances 64 bit support, multi-core, etc even if it detracts from the original mission of being source compatible. And I don't mean this as an insult, but if you're following AROS developments hoping it'll become a AOS or AOS NG replacement, you're probably going to eventually lose interest.

> Power2People L.L.C.
> Non Vidia
> Morph S.R.L.

;-)

> must release SMP and 64 and other updates for MorphOS on POWER

This would require Talos II to be released first.

>This would require Talos II to be released first

Why, what's wrong with the G5 or X5000?

>>> must release SMP and 64 and other updates for MorphOS on POWER

>> This would require Talos II to be released first

> Why, what's wrong with the G5 or X5000?

Nothing wrong, but they are not POWER. The G5 is very close though, as it is a trimmed-down POWER4.

Quote:

Oh, I get your point.
Personally, I'd just like to see SMP adopted for our current ISA.

Power? I don't know how everybody else feels about laying out $2700.
Personally, I can't help but think that if a dual cpu extended ATX board can be built for $2700, couldn't a single cpu ATX board be built for less?