Quote:

Actually, I was under the impression that Acube was to develop the firmware for the platform.

Quote: I was thinking the same...but ..

[ Edited by tlosmx 04.01.2018 - 18:25 ]

Quote:

Its not really an issue for me, as Tabor holds no appeal for me.
But Acube would be the natural company for the T2081 laptop project to go to for firmware (after all, they've already been tapped for design work).

i can say sure yes about openlaptop and acube :)
i know many people involved in this project and for sure acube is involved


[ Edited by tlosmx 04.01.2018 - 18:46 ]

Quote:

Quote:

Quote:

So it's not all doom and gloom after all.

[ Edited by rob 04.01.2018 - 20:19 ]

> about freescale or nxp ... we are speak now about the same company ;-)

My point was that the board you mentioned was not from this company, just the SoC is.

> about pi3 ... blender using the 4 cores on the pi is faster in blender bench compared
> the x5000-20 that use two cores . [...] if you render something you will have same time

So the X5000/20 is about twice as fast per core as the Raspberry Pi 3. And as the X5000/20 is about twice as fast as Tabor, Tabor is about as fast per core as the Raspberry Pi 3. Just as I said :-)

> the T2081 laptop project

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=10318&start=104 ;-)

>> The issue described by Daytona will make porting for Tabor oh-so-more-funny for the devs.

> [...]
> So it's not all doom and gloom after all.

The comment you replied to was about the compatibility problems developers will have to cope with, not about speed (non-)issues. What does speed help when it's not working right, except that it'll crash and burn or show nonsense faster?

Quote:

Only if they are using SPE code. If you can get the same performance from Tabor as the Sam460 with standard FPU code then you may not have a need for special binaries.

> Only if they are using SPE code. If you can get the same performance from Tabor as
> the Sam460 with standard FPU code then you may not have a need for special binaries.

It's also relevant for the other way round, i.e. the developer has provided only an executable compiled for standard FPU (because, for instance, the program isn't developed anymore) which calls a (system) library that on the user's system is compiled for SPE. This is assuming Hyperion will provide the Tabor version of OS4 compiled for SPE in the relevant parts.
Or, even better, imagine an executable compiled for standard FPU or SPE, which calls two different libraries, one compiled for standard FPU and the other one for SPE.

Quote:

In that case could a blacklist be implemented, similar to the one for using or not 68k JIT emulation? SPE and FPU libraries are supplied, SPE ones are used by default unless you blacklist the program so it uses FPU ones or viceversa.

> In that case could a blacklist be implemented, similar to the one for using or
> not 68k JIT emulation? SPE and FPU libraries are supplied, SPE ones are used
> by default unless you blacklist the program so it uses FPU ones or viceversa.

Apart from the added complexity for the user who'd have to manage such blacklist and a whole new dimension for source of errors, I guess such solution would be possible as long as such library is only being used by either only one running program or by several concurrently running programs all being compiled for either FPU or SPE.
But what if two programs running concurrently, one compiled for FPU and the other for SPE, try to call the same library? If one type of library (FPU or SPE) is already in memory, can the other type of the same library be loaded in addition? AFAIK (not being a developer), AmigaOS cannot hold several versions/types of the same library in memory at the same time.

Update:

> This is assuming Hyperion will provide the Tabor version
> of OS4 compiled for SPE in the relevant parts.

Seems they will. Hyperion director Costel "Cyborg" Mincea says (Google translation):

"modern compilers, like the GCC and probably also vbcc, use FPU instructions automatically for optimization, since the FPU is simply much faster in floating-point calculations (logically), but also already with many integer operations. So far in all NG machines was a CPU with neat FPU, so that was always applied. This means that in EVERY piece of software that has been translated with GCC for AmigaOS, there are tons of FPU instructions. Also in virtually every component of AmigaOS itself. So every little pup needs to get through the FPU emulation. At least the hotspots in AmigaOS therefore have to be remodeled and built especially for SPE (and thus with middle-aged GCCs, because newer SPE's no longer support) so as not to keep the handbrake energized with full force"
http://translate.google.com/translate?sl=de&tl=en&u=https://www.os4welt.de/viewtopic.php?p=35351%23p35351

Addendum:

> Even board developers from the "inside" (UltimatePPC)
> made the same mistake before. [...] A-Eon should have
> known better, or at least the OS4 people advising them.

Interesting insight into Hyperion's and OS4 developers' role in Tabor's CPU choice given by Hyperion director Costel "Cyborg" Mincea (Google translation):

"When the first request came, it was just a glimpse of it and a "should fit" given [...]. Only at the time were actually almost finished the prototypes and the "should fit" probably the subjunctive was overlooked. When, a little later, a closer look [...] revealed that the FPU was not IEEE compliant, it was already too late and A-EON had progressed so far that they did not want to row back ... I've tried all the way to the end, to move A-EON to a change, even if that would have increased the cost [...]. [...] But all my warnings, requests and incantations were ignored, so I just shrug my shoulders"
http://translate.google.com/translate?sl=de&tl=en&u=https://www.os4welt.de/viewtopic.php?p=35368%23p35368

"A-EON has constructed a reliable statement from a vague preliminary information on our part and then put a lot of money into Tabor on its own initiative, before we were even close to consciously and specifically deal with Tabor. [...] So, if you want to blame somebody, then please someone who did not listen properly and equated his wishful thinking with reality because he could not wait. Again, since the FPU issue was known, I (and not only myself) have tried unsuccessfully to get A-EON to switch. Yes, that would have cost A-EON some money, but it would have been worth it all the time. Instead, they have elsewhere burned money [...] in addition caused by the incompatible FPU additional effort"
http://translate.google.com/translate?sl=de&tl=en&u=https://www.os4welt.de/viewtopic.php?p=35387%23p35387

Inexplicably, all this happened *after* the 2012 UltimatePPC fiasco and also *after* Trevor Dickinson sought to contact the UltimatePPC developers in 2013.

Professionalsm looks different...

Quote:

It's "just like the 060" guys, move along.

Quote:

+1

Tell them to avoid Socs with that core and they...

Addendum:

> Interesting insight into Hyperion's and OS4 developers'
> role in Tabor's CPU choice given by Hyperion director
> Costel "Cyborg" Mincea (Google translation): [...]

Trevor Dickinson's take on this:

https://www.youtube.com/watch?v=eckRnq0-9Bs (at 23:00)

Edit:

"As the FPU was non standard we checked with the core AmigaOS 4 developers on the suitability of the CPU and after we were given the green light we contracted to design the new motherboard"
https://www.exec.pl/article.jsp?nid=189&Amiga_present_and_future:_interview_with_Trevor_Dickinson

[ Edited by Andreas_Wolf 20.04.2019 - 21:47 ]

Tabor has died now. It is dead. Money has been spent and wasted, and there's no longer money left to spend getting it back on track, even if there was a suitable CPU.

Please don't keep banging on about it like OS4 on the Playstation, TroikaNG, or any of the other hardware boards that never happened. Please just let it die in peace.

Quote:

One hopes so. Once I found out what Soc it was based on, I wanted no part of it. In private, ALL MorphOS developers I've discussed this board with want no part of it.
The fact that it might perform as well as a SAM460 is irrelevant as that performance level is barely adequate and was surpassed by the first system Aeon released.
I wholly support the X5000, and would love to see support for Power 9 based Raptor engineering boards.
But...if you want a cheap board, then it should be based on NXP's T10XX Socs, plain and simple.
Moving back to a 32 bit CPU with a non-standard floating point unit is just plain stupid.
Again, it's like buying lime green polyester slacks from a discount store.
If they really wanted to screw you, they'd sell you two for the same price.

Quote:

No need to add "in private", all relevant MorphOS developers were pretty outspoken on the Tabor's brainfart level from the start.

Quote:

Yes, but in private a couple have admitted to actually receiving them, and still not considering the port (sorry for the disclosure of private info guys).

It wasn't a "brainfart", it was a poorly thought out, flat-out badly researched decision.
Pul Gentle's people wouldn't hve given it two thoughts as that Soc under Linux had support for its FPU (which now of course has been depreciated).

I would have bought a T10XX based Tabor. Now I'm waiting for the X5000/40, and I may buy a Blackbird.

But Tabor...no f'ing way.

Quote:

Well tell us then how you would define a "brainfart" ;)

> in private a couple have admitted to actually receiving them

Interesting :-)

> it was a poorly thought out, flat-out badly researched decision.

As shown in comments #314 and #318, Trevor actually asked the core OS4 developers for their opinion, who told him that the e500v2's non-standard FPU would pose no real issue and could be worked around. Seems this was sufficient for him to go forward with the project, even in light of the prior UltimatePPC fiasco and all the public discussions around it, which he surely was aware of.

> that Soc under Linux had support for its FPU

Yes, and add the fact that the Linux ecosystem is mostly source-based so that binaries are easily adapted to the target hardware by compilation, whereas the Amiga one is mostly based on distributing pre-compiled binaries with no public source available, making emulation inevitable in case of incompatibilities.

Quote:

Kronos, a "brainfart" is a mistake made in a moment from of lack of consideration.
This was researched and planned out...badly.
A brainfart can be excused, this supposedly thought out decision was fatal to the project and can't be.
Maybe some will be foolish enough to buy Tabor to run OS4 on. It will be a weak OS4 system and a poor basis for a Linux system as an ARM or X64 based system (OR an X5000) will walk all over it.

And yes Andreas, while its inconsiderate of me to repeat it, two developers you are well familiar with either have them or at least were offered the boards.

If Tabor hasn't received significant parts investment or a large number of boards manufactured, then now would be a good time to look at adapting Acube's T2080 laptop board design to a mini ITX desktop board.
50% faster clock, twice the cores, four times the concurrent threads, better Soc I/O, and a 64bit CPU (not 32 bit).
Or, again, considering investing in a T10XX design.

Tabor was and is a bad/stupid design, poorly suited for our market (and weak for any other).
Outside of trusting Ben Herman's, I'd consider it Trevor's first major mis-step.