Discussion of the Tabor / A1222 mainboard
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4857 from 2009/1/28
    From: Delaware, USA
    Quote:

    tlosmx wrote:
    Tabor is all Varisys and acube dint nothing . i was thinking the same about tabor that there was acube hands on it ... but no they at the end didnt nothing on that crappy.


    Actually, I was under the impression that Acube was to develop the firmware for the platform.
    "Never attribute to malice what can more readily explained by incompetence"
  • »04.01.18 - 19:17
    Profile
  • Butterfly
    Butterfly
    Posts: 80 from 2017/9/10
    Quote:

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

    I was thinking the same...but ..

    [ Edited by tlosmx 04.01.2018 - 18:25 ]
  • »04.01.18 - 19:24
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4857 from 2009/1/28
    From: Delaware, USA
    Quote:

    tlosmx wrote:
    Quote:

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

    I was thinking the same...but ..


    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).
    "Never attribute to malice what can more readily explained by incompetence"
  • »04.01.18 - 19:30
    Profile
  • Butterfly
    Butterfly
    Posts: 80 from 2017/9/10
    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 ]
  • »04.01.18 - 19:45
    Profile
  • rob
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    rob
    Posts: 118 from 2008/7/22
    Quote:

    koszer wrote:
    Quote:

    CMTX wrote:
    VoxelNoid works fluently at 720p with all settings to max on my mdd g4 1.25 soooo...


    Oh yeah? But does it get anywhere near the spectacular count of 1075037508 FPS? LOL...
    The issue described by Daytona will make porting for Tabor oh-so-more-funny for the devs.


    Quote:

    Three Tower57 port Tabor fun facts:

    - the latest SPE build reaches up to 80 fps. This simply demolishs the sam460ex, factor 2.

    - when running the latest FPU (!) build on the Tabor it reaches up to 40 fps (!) (old OS version, first fpu-emu).

    - when running the latest FPU build on the sam460ex it reaches up to 40 fps.
    So the Tabor is even en par with the sam460 if running the version which is incompatible with its FPU :)

    And before you say sth. a la "then you optimized away most fpu instructions"...
    Wrong, think, man, think - and don't forget that the SPE build runs twice as fast... Yeah, the SPE is a pretty fast FPU unit indeed, but looking at the emu-speed that whole A1222 delivers (y)

    Still anybody out there making up stories about the A1222's performance compared to the SAMs or about the power of the SPE? LOL


    Quote:

    Yes, I know: VoxelNoid and VoxelBird on Tabor are nice, but I suppose most of you were curious about Wings ;)

    And here it is:
    The current Wings Remastered Demo (no, it's not finished yet) build, compiled for SPE, running on the Tabor.

    As being said before the Warp3D driver still contains FPU code (which ironically is actually inside to improve performance on systems with standard FPU) which is the cause for severe performance penalties because it constantly triggers the exception-based FPU emulation.

    But even then: as you can see everything but strafing and dogfight run smooth as butter, and even those two mission types are still playable! The Tabor is certainly a pretty powerful beast if unleashed!

    Now imagine if that driver was modified to not trigger the emulation anymore...

    As always with the Tabor videos here: the sound-driver is not done yet, therefore nothing but silence for now, unfortunately.


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

    [ Edited by rob 04.01.2018 - 20:19 ]
  • »04.01.18 - 21:18
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    > 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 :-)
  • »05.01.18 - 01:19
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    >> 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?
  • »05.01.18 - 01:31
    Profile
  • rob
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    rob
    Posts: 118 from 2008/7/22
    Quote:

    Andreas_Wolf wrote:
    >> 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?


    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.
  • »05.01.18 - 08:03
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    > 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.
  • »05.01.18 - 09:10
    Profile
  • Butterfly
    Butterfly
    emeck
    Posts: 93 from 2014/7/15
    Quote:

    Andreas_Wolf wrote:
    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.


    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.
    PowerBook 5.2 MorphOS 3.12
    PowerBook 5.8 MorphOS 3.12
    Amiga 1200 BPPC/BVision AOS4.1 FE
  • »05.01.18 - 09:28
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    > 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.
  • »05.01.18 - 10:33
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    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
  • »13.02.19 - 21:19
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    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.
  • »14.02.19 - 20:59
    Profile
  • Paladin of the Pegasos
    Paladin of the Pegasos
    Zylesea
    Posts: 1912 from 2003/6/4
    Professionalsm looks different...
    --
    http://www.via-altera.de

    Whenever you're sad just remember the world is 4.543 billion years old and you somehow managed to exist at the same time as David Bowie.
    ...and Matthias , my friend - RIP
  • »14.02.19 - 21:37
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    BSzili
    Posts: 491 from 2012/6/8
    From: Hungary
    Quote:

    Zylesea wrote:
    Professionalsm looks different...


    It's "just like the 060" guys, move along.
    I see the jimmies have been rustled.
  • »15.02.19 - 11:20
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4857 from 2009/1/28
    From: Delaware, USA
    Quote:

    Zylesea wrote:
    Professionalsm looks different...


    +1

    Tell them to avoid Socs with that core and they...
    "Never attribute to malice what can more readily explained by incompetence"
  • »15.02.19 - 20:34
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    KennyR
    Posts: 673 from 2003/3/4
    From: #AmigaZeux, Gu...
    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.
  • »08.04.19 - 21:29
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4857 from 2009/1/28
    From: Delaware, USA
    Quote:

    KennyR wrote:
    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.


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »08.04.19 - 21:41
    Profile
  • Moderator
    Kronos
    Posts: 1910 from 2003/2/24
    Quote:

    Jim wrote:
    In private, ALL MorphOS developers I've discussed this board with want no part of it.


    No need to add "in private", all relevant MorphOS developers were pretty outspoken on the Tabor's brainfart level from the start.
    --------------------- May the 4th be with you ------------------
    Mother Russia dance of the Zar, don't you know how lucky you are
  • »09.04.19 - 08:17
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4857 from 2009/1/28
    From: Delaware, USA
    Quote:

    Kronos wrote:
    Quote:

    Jim wrote:
    In private, ALL MorphOS developers I've discussed this board with want no part of it.


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




    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »09.04.19 - 12:52
    Profile
  • Moderator
    Kronos
    Posts: 1910 from 2003/2/24
    Quote:

    Jim wrote:

    It wasn't a "brainfart", it was a poorly thought out, flat-out badly researched decision.



    Well tell us then how you would define a "brainfart" ;)
    --------------------- May the 4th be with you ------------------
    Mother Russia dance of the Zar, don't you know how lucky you are
  • »09.04.19 - 13:03
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10593 from 2003/5/22
    From: Germany
    > 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.
  • »09.04.19 - 14:21
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4857 from 2009/1/28
    From: Delaware, USA
    Quote:

    Kronos wrote:
    Quote:

    Jim wrote:

    It wasn't a "brainfart", it was a poorly thought out, flat-out badly researched decision.



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


    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.
    "Never attribute to malice what can more readily explained by incompetence"
  • »09.04.19 - 15:50
    Profile