> Closest you can get now is TI's newly announced TCI6636 monster chip.
> 4 x A15s + 8 x DSPs.

Freescale's QorIQ Qonverge B4860 might be even closer with its 4 x e6500 + 6 x DSP. While it has less DSPs than TI's chip, the e6500 is ISA-compatible (including AltiVec/VMX) with the Cell PPU and is dual-threaded just like the Cell PPU.

That is a cool one, isn't it?
Are we sure we don't just want to keep the ISA and move to well threaded SMP code under Qbox?
Let's face it, most other OS' are SMP capable, but they do it poorly.

Andreas_Wolf wrote:,
Quote:

Sounds like a great chip for MorphOS3.x to run on if we could ever implement some kind of SMP, or AMP, or what was the other kind of multi-core, or multi-processor implementation you mentioned in this or another thread.

I hope we can get some kind of multiple core/multiple processor support, without breaking all backward compatibility with all of our software. I wonder how much software we have right now that would NOT be broken, with a switch to SMP, or AMP? It has been clearly stated that most or all of the old Amiga 68k software would no longer work, but I am unclear about the status of the PPC ports, or original software that has been written specifically for MorphOS PPC and has no legacy Amiga 68k code, or dependencies?

Edit: Maybe if the price and performance is right, this QorIQ Qonverge B4860 super chip will be used as the successor to the X1000's PA6T chip on A-Eon's new boards that Varisys is working on for them. Trevor repeated his invitation to the MorphOS Dev. Team, and expressed his desire to have MorphOS3.x, AROS PPC, & AmigaOS4.x ported to his next PPC motherboards, as well as many versions of Linux PPC (he currently has 8 different Linux PPC distributions running on the X1000). Many MorphOS3.x users will not care about what A-Eon produces, or the possibility of running AROS PPC, or AmigaOS4.x in a multi-boot setup along side of MorphOS3.x, but there are some MorphOS users who are interested in running all these OSes on one computer. I just don't know how many MorphOS3.x users also are willing to pay for an AmigaOS4.x license? Obviously I would have, if I already did not have an X1000, but I don't regret my decision to purchase the X1000, as I still see it as a very unique computer, and I believe that many new software programs will be written that make my X1000 even more useful, plus now that tools are starting to emerge to help us take advantage of the on board XMOS chip and Xorro slot, I fully expect more users to begin playing with that processor and interface to create interesting projects.

[ Edited by amigadave 16.11.2012 - 20:27 ]

Actually, and I know Andreas will say this isn't necessary, but I like the idea of running Abox and Qbox concurrently.
Abox could be processor core specific (locked to a single core) and Qbox could support SMP.
And if you came up with some way to pass data back and forth, AMP for Abox w/o a lot of hassles.

Jim wrote:,
Quote:


Yes, if they can make the A-Box run as a task, or as a virtual machine, within the Q-Box. Maybe there is a way they can figure out how to allow the Q-Box to be fully multi-core/multi-processor capable, plus memory protected and multi-user (multi-user not important to me), so new software can be written in a modern way without the constraints of the legacy Amiga components. Then, after several years, when the software is all replaced with modern software, we can get rid of the A-Box and just use E-UAE to run legacy software, while everything else is running on a modern Q-Box system.

All wild speculation by someone who has little to no knowledge of how any of that can be made to work. I am just repeating the speculation of others that have suggested the same kinds of things previously.

> Sounds like a great chip for MorphOS3.x to run on if we could ever implement
> some kind of SMP, or AMP, or what was the other kind of multi-core, or
> multi-processor implementation you mentioned in this or another thread. [...]
> Maybe if the price and performance is right, this QorIQ Qonverge B4860 super
> chip will be used as the successor to the X1000's PA6T chip on A-Eon's new
> boards that Varisys is working on for them.

I don't see any reason for using the B4860 "super chip" when the T2080

- has the same amount of e6500 cores running at the same clock speed
- has two SATA2 controllers (instead of none at all)
- has two PCIe 3.0 + two PCIe 2.0 controllers (instead of four PCIe 2.0)
- has two USB2 controllers (instead of a single one)
- has a 14% faster memory controller than the B4860
- lacks the expensive (and useless for MorphOS anyway) DSPs and baseband stuff
- will be much cheaper than the B4860

The only relevant advantage of the B4860 over the T2080 that I'm aware of is that the B4860 has two memory controllers while the T2080 has just a single one. Are there any more advantages that are relevant for running MorphOS?
Apart from that, we already know from Trevor's AmiWest 2012 talk that what will most likely be used as the (higher end) successor to the X1000's PA6T chip is an e5500-based chip (most probably QorIQ P5020 or P5021). From the same talk we know that chips based on e6500 are supposed to be used by A-Eon only after that. I'm sure Trevor would have wanted to skip the e5500 and go directly with the e6500 but this is just not possible considering the time frames involved.

> I wonder how much software we have right now that would NOT be broken,
> with a switch to SMP, or AMP?

I don't know about SMP, but the introduction of AMP support into MorphOS wouldn't break any software. That's the nice thing about AMP, besides the easier implementation compared to SMP.

> It has been clearly stated that most or all of the old Amiga 68k software would
> no longer work, but I am unclear about the status of the PPC ports, or original
> software that has been written specifically for MorphOS PPC and has no legacy
> Amiga 68k code, or dependencies?

I don't think there's a difference in this regard between m68k binaries and PPC binaries, as they both use basically the same API.

> I know Andreas will say this isn't necessary, but I like the idea of running
> Abox and Qbox concurrently.

Huh? Actually, I discussed the matter of running ABox and multiple other boxes in parallel on a multicore system with you 2 years ago here on MorphZone:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7405&forum=3&start=9

In view of this, I really wonder how you arrived at your strange conclusion about my alleged stance on this.

> if you came up with some way to pass data back and forth, AMP for Abox w/o
> a lot of hassles.

Pass data between main core and auxiliary core for ABox, not between ABox and QBox, right?

>Pass data between main core and auxiliary core for ABox, not between ABox and QBox, right?

Yes. I wouldn't think there would be much to gain by having threads between the boxes.

And sorry if I misinterpreted your stance on concurrent operation.
Keeping Abox on one core still allows for some serious SMP work with processors like the P4080.

> Yes, if they can make the A-Box run as a task, or as a virtual machine, within the Q-Box.

As far as I have understood the MorphOS box concept as it was described back in the days, all concurrently running boxes would run in parallel directly on the Quark kernel, not nested into one another. On a single-core system Quark would then act as the scheduler, or as the hypervisor on a multicore system.

Andreas_Wolf,
Quote:

Andreas, you're assuming that David is aware of how a micro kernel based OS is structured.
I used Minix and Microware's OS-9 in the '80's so I've got some idea.

Most OS have a monolithic structure. In a micro kernal, the very core of the system, the basic essential services in a tightly protected package that controls and schedules all other processes.

Note the two words I highlighted in Andreas' text because they illustrate that he's familiar with this. The OS (or in our case a process 'box') sit on not embedded in/incorporated into the kernal.

I've never understood why this practice is not more common is OS design except that it is easier to write monstrous amounts of sloppy code.
Its a much more elegant, efficient, and protected way to design a system.

When I first realized how MorphOS was structured I became seriously impressed with its developers.

Hobbyist OS? Pah! They've been hobbling along improving and focusing on Abox.

But this thing has the capacity to be a real monster.

Quote:

Can you please stop shilling for os4 and aeon here? Its enough that you have already turned into a os4 meglomaniac on amigaworld

If trevor wants to bankrupt himsel putting out expensive hardware with a mandatory driverless os4 licence, thats his problem, hothing to do with mos.

[ Edited by cheesegrate 18.11.2012 - 15:50 ]

cheesegrate,
Quote:

Personally, I'm very impressed with Trevor and A-eon and think that what they really need is a good OS.
Say one that from its inception was designed to support SMP.
One based on the idea of Amiga compatibility as a transition as opposed to a base for future development.

So Dave has my encouragement to keep talking.

With A-eon reorganized and no direct ties to Hyperion they're free to pursue what ever they want.
And IF you've been paying attention to Andreas' posts you might be aware that what they are probably looking into building would be MUCH better suited to OUR OS (thanks to Quark).

>> As far as I have understood the MorphOS box concept as it was described
>> back in the days, all concurrently running boxes would run in parallel directly
>> on the Quark kernel, not nested into one

> Note the two words I highlighted in Andreas' text [...]. The OS (or in our case
> a process 'box') sit on not embedded in/incorporated into the kernal.

Actually, you misread and misquoted me. I wrote in my reply to amigadave that the boxes ran "in parallel directly on the Quark kernel, not nested into one another", as that's what amigadave proposed ("the A-Box run as a task, or as a virtual machine, within the Q-Box").

> Andreas, you're assuming that David is aware of how a micro kernel based OS
> is structured.

No, I'm not. The ABox running within the QBox as amigadave proposed wouldn't be against the microkernel concept in any way as the QBox would still be running on Quark. It's just that this is not how I have understood the way the MorphOS box concept was thought out.

Yes, I guess that was your intent and that it more directly addresses David's question.

Andreas_Wolf,
Quote:


It's not just the way the concept was "thought out", it wouldn't work in an SMP environment.

>> I wrote in my reply to amigadave that the boxes ran "in parallel directly on the
>> Quark kernel, not nested into one another", as that's what amigadave
>> proposed ("the A-Box run as a task, or as a virtual machine, within the Q-Box").

> Yes, I guess that [...] it more directly addresses David's question.

What question? My reply was to a *statement* he made.

>> The ABox running within the QBox as amigadave proposed wouldn't be against
>> the microkernel concept in any way as the QBox would still be running on Quark.

> It's not just the way the concept was "thought out", it wouldn't work in an SMP environment.

I don't understand. What wouldn't work in an SMP environment and why?

Andreas_Wolf,
Quote:

Why would you think that would work any better then trying to implement SMP with Abox directly Andreas?

>>>> The ABox running within the QBox as amigadave proposed wouldn't be against
>>>> the microkernel concept in any way as the QBox would still be running on Quark.

>>> It's not just the way the concept was "thought out", it wouldn't work in an
>>> SMP environment.

>> I don't understand. What wouldn't work in an SMP environment and why?

> Why would you think that would work any better then trying to implement SMP
> with Abox directly Andreas?

In case "that" is referring to "ABox running within the QBox": Technically I don't see a problem with running a single-threaded ABox as a task within an SMP-capable QBox which in turn runs on an SMP-capable Quark kernel. That would be similar to how the hosted variant of AROS runs.

Good answer.
And it helps clarify the difference between running this in layers (Abox in Qbox) and as separate processes.

Makes me wonder how Ambient (or its Qbox equivalent/replacement) would have to evolve to handle the cross box display issues. How drop and drag might work etc.

Don't think Q and A/Box would need to run on different display at all.

What would be needed might be is a new high-level GFX-API that is a bit more modern. On top of that there would be a layer with most of the old API to allow existing apps to work.

Some compability might be lost and drag&drop might need conversion routines or not work at all for in some cases but thats still better than running 2 displays.

Thanks Kronos,
When I try to wrap my mind around the idea of one box running SMP and the other running on just one core, I have difficulty figuring out how the compatibility issues would be resolved.
But considering how well they have been so far, I guess I don't have to much to worry about.