Discussion of the Tabor / A1222 mainboard
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4693 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: 4693 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
  • Butterfly
    Butterfly
    rob
    Posts: 90 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: 9937 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: 9937 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
  • Butterfly
    Butterfly
    rob
    Posts: 90 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: 9937 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: 71 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.10
    PowerBook 5.8 MorphOS 3.11
    Amiga 1200 BPPC/BVision AOS4.1 FE
  • »05.01.18 - 09:28
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 9937 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