Getting closer...

[ptitSeb]

Awesome news!! I can't wait!

So I saw the specs for the possible upgrade SoC and noticed the OpenGL 3.0 support. Does the OMAP5 in the Pyra have native support for full OpenGL 3.0? If not I'll be getting that upgrade as soon as it's available. But if the OMAP5's GPU already supports OpenGL 3.0 (and not just GLES) then I'll wait a few years before I get a SoC upgrade.

The OMAP5 page on both wikipedia and TI's website fail to mention OpenGL support, one way or the other.

GLES 2.0 support (and 1.1) support for OMAP 5 only. No 3.0, no full Desktop GL.

 

[trix]

Then I am also excited for the first SoC upgrade, if it supports full OpenGL 3.0!

I mean we can do a LOT with GLES and that compatibility layer we use on so many Pandora games, but real full OpenGL 3.0 would enable so much more.

Anyway I'm mostly excited just to finally turn the two computers I always have with me (Pandora and smartphone) into one superior device!

 

[EricB]

I am also excited for Soc Upgrade although i would prefer Quad over Quadlite as it seem to support H.265.
I know 4k is a bit overkill but i encoded some of my Bluray in H.265 and would be nice to stream them on my Pyra.
I can easily do it on my phone though which supports it so not really a deal breaker.

Glad to see the wait is almost over. Only two more months™

 

[Bibifuret]

READY TO COME OUT OF GERMANY

 

[levi]

That is probably the most positively Bavarian gif I've ever seen!

 

[elvissteinjr]

The i.MX SOC looks solid, but not much of an upgrade compared to the OMAP5. As in raw numbers, the CPU and the GPU might be a little bit slower, but offer more cores and graphics APIs. I know you shouldn't take the numbers at face value, but they don't get me excited to be honest.

The i.MX offers HDMI 2.0a. Is the port on the mainboard capable of supporting that? I'm not sure if the ports change with HDMI versions like it's the case with USB.

 

[EdenR]

With this delay i hope in an upgrade cpu board!

 

[Stainy]

With this delay i hope in an upgrade cpu board!

Do what? let me man release the thing first... upgrades come later

 

[notaz]

Also, Wifi is now A LOT better. In our testing environment, we had six different Wifi networks with different distances and various strengthes.
Whereas the old mainboard could only find two of them, the new mainboard instantly did find all six at once, and the signal quality was a lot better as well.

Well even my board sees a lot of networks and can associate with them, but is unable to transfer any data mysteriously, so at this point it's much more important to test the speeds and connection stability on various routers.

Well... there's a possible SoC being released which could become the first CPU Board Upgrade:
The i.MX8 M QuadLite, which is the mobile version of the i.MX8.

Ugh that's going back to pandora's level of single thread performance. Cortex-A53 is basically A7 with 64bit support. Yeah 4 cores is nice, but emulators and games that are likely to be ported won't use multiple cores. Shouldn't be too bad for some things, but it will be a visible performance downgrade from OMAP5.

 

[Eight Bit]

Ugh that's going back to pandora's level of single thread performance. Cortex-A53 is basically A7 with 64bit support. Yeah 4 cores is nice, but emulators and games that are likely to be ported won't use multiple cores. Shouldn't be too bad for some things, but it will be a visible performance downgrade from OMAP5.

I'm un-knowledgable but I always find your different, down to earth view on this kind of things very interesting.
Just out of curiousity, would it make multi-tasking better at least? Like the ability to run different tasks on different cores at the same time?

 

[rSl]

finally, it all lines up for my birthday... ONCE AGAIN!
perfection takes time, i love reading good news, so... no hurry.
man, it will be *superawesome++* to hold my verry own pyra in my little sweaty hands!!
i can feel it, it's soon!

 

[Caine]

Spoiler

Well, my contact has checked that all the fixes have been made to the molds, but the samples need to be produced.
The important thing is that the changes have been done.



Sure, that's a bummer, but not we can do about this here.



Thorough testing. It works as good as my smartphone, but you should still test it with different routers, etc.
The important thing is that the revised layout has fixed the Wifi issue.
As all other known issues of the mainboard has been fixed now as well, the layout is fix and we can safely consider the mainboard to be finished as well.



That was to be expected if you follow the news:
CPU board production takes 6 weeks, Mainboard production takes 4 weeks.

Testing different capacitors can be done while we're waiting for the PCBs.
Testing whether the known issues had been fixed and that Wifi works fine had a higher priority, as those were mandatory to ORDER the mainboards (they might've needed layout changes).

So if we first would've worked on fixing the sirring noises instead of testing Wifi and fixed, the mainboard production would've been delayed by a couple of weeks.
Not a good idea if you ask me.



Not really one more iteration. The layout is now done and tested, nothing more is needed.

But how should we build prototypes without the mainboards?
Also, where is the problem with that if the CPU boards need 6 weeks in production and the mainboards 4 weeks (could even be sped up to 2 weeks for a bit money more)?
The important things are...

a) The mainboard has been tested and works
b) The mainboard is being produced in parallel to the CPU board and both should arrive at GC at the same time.



What's the problem with that? The cooling we had is already working fine (it cools the CPU down by 20°C).
But why shouldn't I try to improve that even further while we're waiting for the PCBs to arrive?

Sure, I could sit down and play some games and have fun... but trying to improve it even further if it doesn't delay anything is even more fun.
We know it works and we can start production with the already working solution


I'm not sure if you understood the post correctly, but the mainboard IS already fixed, the CPU board has a 99.99% chance of being fixed (as these simulations are very accurate usually), cooling solution is also working fine, the molds should've all fixes included as well.
The ONLY thing not fixed yet is the capacitor sirring noise, but we always had the plan to work on that while the boards are being produced.

So what we're doing now is WAITING for everything to be produced (PCBs and cases) so we can do a final check (though the final mainboard has already been checked, but we need more to be able to produce the prototypes )



It depends on what you define as "finished".

If "finished" means: The layout and design files are now done, no more fixes are needed, then basically everything except for the sirring noise has been finished.
If you define "finished" that everything has been done AND thoroughly tested (which is what we need the prototype for), then yes, we still need to check the CPU board and the case.
Heating solution and mainboard have already been checked, so these could be considered as being finished then as well.

(then again, I sometimes have the feeling that 90% of the products on the market couldn't be considered as being "finished" then, as they often seem to be missing some thorough testing...)



Weeeell... if the Chinese New Year ends in July, then yes, it would be summer until we receive the PCBs to do the prototype production run.
Otherwise, I don't see a reason why it should take longer. Global Components have ALWAYS been fast and reliable when it comes to production, so why should they NOT produce them?

Regarding the cases: I've got 25 sets of the previous revision here.
The ONLY fixes that have been made was to the shoulder buttons, the stylus holder and the keyboard part (as the holes were a bit off).
Everything else IS already in the final revision.

Yes, I can understand why one can be pessimistic and think things will take years.
But you should still see the facts of what has been done and what not.
[doublepost=1516715316,1516715296][/doublepost]

Yep, that's exactly how it is

Oh sheesh... I did it again. Sorry @EvilDragon, this was not so much a comment on the project as a voicing of my own frustrations, pessimism and depressive mood. I'm just, how can I say this...going through a rough time. I really wish I could share in the optimism, but the world is very black for me these days

Perhaps the Xan reference was too weak, so for the record: I have full confidence in you, I know you will bring this to a satisfactory end and I am with you all the way however long it takes. Thank you for your attention to detail and keep up the good work.

 

[Silent-Hunter]

@Caine Hey, I hope things get better for you.

 

[levi]

Yeah 4 cores is nice, but emulators and games that are likely to be ported won't use multiple cores.

With most of the systems being emulated having multiple CPUs on board, wouldn't it actually simplify some emulators to be able to run those different cores on different physical cores? Maybe not most systems, but an awful lot of arcade boards were built that way, and most of the Sega consoles. And with newer systems having programmable GPUs doing a lot of the work, wouldn't it help to be able to run those simulations on a dedicated core?

 

[slaeshjag]

With most of the systems being emulated having multiple CPUs on board, wouldn't it actually simplify some emulators to be able to run those different cores on different physical cores? Maybe not most systems, but an awful lot of arcade boards were built that way, and most of the Sega consoles. And with newer systems having programmable GPUs doing a lot of the work, wouldn't it help to be able to run those simulations on a dedicated core?

It can be very difficult to avoid timing problems when threading out tasks that you'd think are obvious targets for threading. Synchronizing emulation between different threads can easily eat up any performance advantage you might otherwise expect from using several cores rather than just one.

 

[levi]

True, but didn't the original hardware have to handle those same synchronisation problems. I guess we're emulating strictly in order cores on an out-of-order architecture which might mean things often happen slightly quicker than they would if you're just counting cycles, but maybe that will buy you the extra time to put an 'I'm ready' signal in the shared cache or something.

 

[notaz]

Just out of curiousity, would it make multi-tasking better at least? Like the ability to run different tasks on different cores at the same time?

Sure.

Oh sheesh... I did it again. Sorry @EvilDragon, this was not so much a comment on the project as a voicing of my own frustrations, pessimism and depressive mood. I'm just, how can I say this...going through a rough time. I really wish I could share in the optimism, but the world is very black for me these days

Do you also get like just a handful of hours of sunshine over almost the entire autumn/winter season where you live?

True, but didn't the original hardware have to handle those same synchronisation problems. I guess we're emulating strictly in order cores on an out-of-order architecture which might mean things often happen slightly quicker than they would if you're just counting cycles, but maybe that will buy you the extra time to put an 'I'm ready' signal in the shared cache or something.

Don't forget the code on old consoles runs directly on hardware, often with fixed timing, while a modern OS thread can be be scheduled away anytime because OS decides it needs to do something else, so things will go out of sync very quickly. You just have to sync all the emulated parts very frequently, it can be done but it becomes complicated quickly and is just not worth the effort really. But in certain cases, for more HLE-like emulation like PSP where all games use standard firmware libs that can be replaced, threads can be useful, yeah.

 

[rSl]

...going through a rough time. I really wish I could share in the optimism, but the world is very black for me these days

i wish you lots of good energy, so you can see the light again soon!
all the best!

 

[EvilDragon]

Well even my board sees a lot of networks and can associate with them, but is unable to transfer any data mysteriously, so at this point it's much more important to test the speeds and connection stability on various routers.

Ah, interesting, we had a lot more issues there.
Yeah, I intend to fully test it with download speeds.

One thing to note though:
Nikolaus ran the GTA04 OS on the Pyras (an old and new one) which has a network analyzer included which shows all networks in a nice graph at the same time.
The old Pyra showed a HEAVY variation of the quality of each network, whereas he new one was a lot more stable.
It also had a 10 to 15dB better quality signal than the old one.

Ugh that's going back to pandora's level of single thread performance. Cortex-A53 is basically A7 with 64bit support. Yeah 4 cores is nice, but emulators and games that are likely to be ported won't use multiple cores. Shouldn't be too bad for some things, but it will be a visible performance downgrade from OMAP5.

Oh, thanks for the info. Based on the DMIPS speed I expect the i.MX8 M to be a little faster than the OMAP5:
(https://en.wikipedia.org/wiki/Comparison_of_ARM_cores)

I didn't think the A53 would be that bad... but thanks for clarifying

Oh sheesh... I did it again. Sorry @EvilDragon, this was not so much a comment on the project as a voicing of my own frustrations, pessimism and depressive mood. I'm just, how can I say this...going through a rough time. I really wish I could share in the optimism, but the world is very black for me these days

No harm done
I can fully understand that. It's pretty hard sometimes to keep myself motivated with all these issues we have to fix...
I have expected a way smoother run and I had expected to deliver the Pyra years ago, so yeah... sometimes it's hard for me to stay optimistic as well

 

[vcoleiro1]

Ah, interesting, we had a lot more issues there.

Oh, thanks for the info. Based on the DMIPS speed I expect the i.MX8 M to be a little faster than the OMAP5:
(https://en.wikipedia.org/wiki/Comparison_of_ARM_cores)

I didn't think the A53 would be that bad... but thanks for clarifying

The Wiki page backs up what notaz said.

1) The single core DMIPS for the ARM Cortex A53 is 2.3

2) The single core DMIPS for the ARM Cortex A15 is 3.5 - 4.1

3) The single core DMIPS for the ARM Cortex A8 is 2.0


For emulation which commonly uses a single core, the ARM Cortex A53 based i.MX8 M would be way worse than the Omap5 . The i.MX8 M would be almost as bad as the Pandora judging by those figures, just as notaz said