> 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.

@Jim

Now I am confused.

First you said "Yes, but in private a couple have admitted to actually receiving them."

Then you said "two developers you are well familiar with either have them or at least were offered the boards."

Is this 2 different instances? One group that did receive boards and another group that either do or do not have boards?

#6

Quote:


Potato, Kartoffel, pomme de terre......

;)

Quote:

No...more specific. Brainfarts are spontaneous, this crap took planning...bad planning.

More like a "brainshit" than a "brainfart".

Nah, started as a brainfart and then noone had the brains/guts to stop it from being implemented.

Quote:

We refer to that as a "shart". Starts out as a fart, but then something more discusting occurs.

So maybe a "brainshart"?

I notice Acube doesn't seem too interested in discussing this board.
I thought they were to be involved, but outside of firmware I don't see it.

Someone else recently contacted me about the idea of a T10XX based board, but its really too big a project to take on without an experienced partner (i.e. - Varisys, Acube, Genesi, etc.). This idea never gained traction when I was pushing it, so I'm wary of re-involving myself with it.

Right now, I'm rooting for Roberto Innocenti's project. At least he had the sense to team up with a profession design company.

>>> in private a couple have admitted to actually receiving them

>> Interesting :-)

> yes [...], two developers [...] either have them or at least were offered the boards.

Backpedaling? :-)

> If Tabor hasn't [...] a large number of boards manufactured

It hasn't.

> then now would be a good time to look at adapting
> Acube's T2080 laptop board design

There is no T2080 laptop board design yet, just schematics, as the start of the board design phase requires the final chassis to be decided for first, which hasn't happened yet.

https://www.powerpc-notebook.org/2019/04/march-2019-schematic-updates/

> 50% faster clock, twice the cores, four times the concurrent threads,
> better Soc I/O, and a 64bit CPU (not 32 bit).

...as well as a standard FPU and AltiVec SIMD :-)

>> yes [...], two developers [...] either have them or at least were offered the boards.

>Backpedaling?

Not necessarily backpedaling, I was told two were received.
I just have this bad habit (probably from my business training) of always adding qualifiers.

>https://www.powerpc-notebook.org/2019/04/march-2019-schematic-updates/

>...as well as a standard FPU and AltiVec SIMD

Yes, that does make a difference, doesn't it?

Since the Soc is only part of the board pricing equation, and a T2080 is only about $150 more than a P1022...

As to 'only' having the schematics, hey, I'm actually surprised it got that far. And as to chassis, that does complicate board layout, but a specific chassis was discussed awhile ago.

If I could have dragged Bill Buck into this, sourcing a chasis might be easier. After all, he used to make laptops and even had prototypes of a low cost model made by a Mexican firm ATTO. If new C64 and Amiga cases can be made, a laptop case is only a bit more complicated.

> a T2080 is only about $150 more than a P1022...

Current pricing at distributors looks different than years ago. Lowest single-quantity prices I can find now are about 100 USD for 1.2 GHz P1022 and about 200 USD for 1.8 GHz T2080. Seems P1022 price has about doubled over the years, but I believe A-Eon stocked up with P1022 chips when it was still cheap.

>>> then now would be a good time to look at adapting
>>> Acube's T2080 laptop board design

>> There is no T2080 laptop board design yet, just schematics

> As to 'only' having the schematics, hey, I'm actually surprised it got that far.

Yes, it's just there's no work on board design started yet that could be adapted for anything.

> a specific chassis was discussed awhile ago.

This may be, but a week ago there was still no decision arrived at, as reported in the linked status update.

>> a specific chassis was discussed awhile ago.

>This may be, but a week ago there was still no decision arrived at, as reported in the linked status update.

Yes, but the point is we do more than discuss, we get scheisse done.

The design, when laid out, should lend itself to reworking as a mini itx board.

One thing I've been thinking about is would you keep the MXM connector, or and a PCI-E slot?
The former would make everything much more compact, but the later allows for more powerful graphics (then again, how much power does MorphOS need).

Periodically a vendor for Cadence Allegro contacts me to see if I want to upgrade my design software.
If the layouts get done (and Acube is ready to strt them), I may just have to blow the $1500.

If I had a functional layout, I have contacts that could build the prototypes.

After all, my company used to build hardware in the '80s and '90s.
Its just a LOT more complicated now.