An almost naked Pyra

[___]

Auja, Drastic, Gpsp and PCSX Rearmed would be great to have on Pyra, as this are the Emus i use the last months verry often on Pandora

lol now all non Germans will rush to the repo to find out what kind of emulator "auja" is... it's sort of the German equivalent to saying "oh yeah". I love when you mix German expressions with english matze! it's cute.

 

[Exophase]

Auja, Drastic, Gpsp and PCSX Rearmed would be great to have on Pyra, as this are the Emus i use the last months verry often on Pandora

I remember back before Pandora was released I said I'd be disappointed if gpSP was still needed to get good enough performance for GBA emulation. I am going to be much more disappointed if that ends up being true for Pyra.

I recommend a port of mGBA. It is much more accurate and compatible than gpSP and it should be at least somewhat faster than VBA. The author has also shown interest in doing more optimizations down the road, especially since there are ports for 3DS and Vita, which have even lower single-threaded performance than Pandora.

 

[Linux-SWAT]

There's also this one :
https://github.com/blastrock/meteor

 

[EvilDragon]

Just updating here to let you know I sent something yesterday in case you didn't see the PM, since I know PMs can be easy to miss sometimes.

Yep, seen it! Will try to test ASAP

 

[PSC]

Just curious, why it is not a good choice to use a 64bit SOC? I read those posts said that the Linux support for 64bit ARM is immature, but I thought that the 64bit ARM chip is similar to X86-64, which is support 32bit OS/application simultaneously. I didn't mean that Pyra should be 64bit machine, 32bit is acceptable for me, and I hope to get one as soon as possible. I just curiously.
Thanks for everyone, I enjoy to read those posts while waiting for Pyra.

 

[levi]

A 64bit ARM chip would make a good SoC for the Pyra if one were available that didn't overheat, didn't cost silly money and was available in quantities of a thousand or so. As you say, ARM64 includes support for the old 32-bit instruction set too - it's part of the specification, so it should be possible to run a 64bit ARM chip exclusively in 32-bit mode, indeed I think some phones currently being sold do that.

 

[Exophase]

A 64bit ARM chip would make a good SoC for the Pyra if one were available that didn't overheat, didn't cost silly money and was available in quantities of a thousand or so. As you say, ARM64 includes support for the old 32-bit instruction set too - it's part of the specification, so it should be possible to run a 64bit ARM chip exclusively in 32-bit mode, indeed I think some phones currently being sold do that.

Yeah as far as I'm aware most Android devices with 64-bit SoCs released now, be it ARM or x86, run 64-bit Android. And of course 32-bit is supported or else all the legacy apps using NDK wouldn't work. I'd love to support 64-bit natively (with either ARM or x86) but it's a huge amount of work for me so that's probably not going to happen any time soon.

For right now the only 64-bit SoCs that are anywhere close to viable options use Cortex-A53. Most of the lower end SoC makers skipped Cortex-A57, but at least some of them have Cortex-A72 SoCs planned (MediaTek already has one out) Cortex-A53 is not a great choice performance-wise.

I would say that looking forward the most realistic alternatives to TI appear to be Rockchip, then Intel.

Rockchip's rk3288, the SoC in GPD XD, has over time received fairly good Linux support. AFAIK Rockchip have even gradually started to push to mainline it. ARM has been better about releasing Linux userspace binaries (that support OGL ES 3) for Mali-T6xx+ than IMG has been, especially with old Series5XT stuff like in OMAP5. There's a board for sale with an rk3288 running Linux and drawings are available. I don't know offhand that it's available through distributors, but given how widely it's used in various products I have a pretty good feeling it can be acquired in low quantities one way or another, even if it's through Honk Kong warehouses. I'm sure the datasheets and support aren't anywhere close to TI level and that could be a showstopper, but maybe not - especially if a Chinese partner could be found who has some experience with it. And it lacks USB3 which will be a big problem for some. It's a major compromise, but unfortunately everything is at this point.

On the other hand, while it's a good SoC with a more power efficient quad core than what's in OMAP5 (and it supports proper LPDDR3), it's still only 32-bit. There's a big downside to pulling the trigger on any new board before a decent 64-bit SoC is available. So I'm hoping Rockchip releases a 16/14nm Cortex-A72 SoC at some point and that it looks as viable as something as rk3288 does, if not moreso.

 

[matzesu]

I remember back before Pandora was released I said I'd be disappointed if gpSP was still needed to get good enough performance for GBA emulation. I am going to be much more disappointed if that ends up being true for Pyra.

I recommend a port of mGBA. It is much more accurate and compatible than gpSP and it should be at least somewhat faster than VBA. The author has also shown interest in doing more optimizations down the road, especially since there are ports for 3DS and Vita, which have even lower single-threaded performance than Pandora.

Well, a better GBA Emulator than GPSP would allways be better, mybe whit Enhanced Graphics, and Gyrosensor Support for Yoshis Universal Gravitation and Wario Ware Twistet, and more compability.. (GTA, the NES Collection gGames)..

Im fine whit gpSP, but its not the Emu i want to stuck on Pyra if there are better alternatives..

 

[Klumpen]

"Sword of Mana" and "Mario & Luigi" can't be finished in gpSP.
I had some very frustrating moments there later in the game thanks to emulation problems.

 

[AnimatedFreak]

"Sword of Mana" and "Mario & Luigi" can't be finished in gpSP.
I had some very frustrating moments there later in the game thanks to emulation problems.

yes I had the same problem. Also Kingdom Hearts Chain of Memories I can't get pass the opening FMV :/

 

[rygD]

"Sword of Mana"...can't be finished in gpSP.

That sucks (for all games that have this problem). I haven't played this in a very long time, and don't remember seeing it in my collection in recent years. We really need emulators that let you complete games. I would have been pretty pissed to put time into a game and be unable to complete it.

 

[fusion_power]

Does a 64 Bit (ARM) architecture actualy needs more or less power than a 32 Bit architecture or doesn't that matter at all?

 

[TrashyMG]

Does a 64 Bit (ARM) architecture actualy needs more or less power than a 32 Bit architecture or doesn't that matter at all?

My senses says it does, but it's for sure not a doubling in power consumption. just have a feeling with the extra addressing needed for 64-bit, more memory usage etc...

 

[matzesu]

Ditnt Tryd this 2 Games, because i have the second new Mario and Luigi Game on 3DS (Dreamteam Bros) and ditnt play Swords of Mana..
I have Crashes in GTA Advance, and the NES Classics Games (where even the Revo K101 have its Problems.., mybe its a ROM Problem in the Classics Collektion Games..

So a GBA Emu for the Pyra, should be a bit better than GpSp, but for the first few months, GpSP also works for me..

 

[ptitSeb]

I have a build of recent build Retroarch, with mGBA and Meteor, but mGBA core was just crashing and meteor was super slow. I'll try to compile a standalone version of mGBA, to see the result...

 

[levi]

Well, supporting the extra bus widths and instructions will require extra transistors, so more current is leaked, so while it's doing nothing it'll take more current. While it's doing work it's more complicated, and depends how you measure it - per kinstructions it's probably still more current, but per actual work done it may well be more efficient for certain tasks. That's all assuming process tech is the same, and cache sizes etc. (and of course, a similarly sized cache on a chip with 64-bit fetch would only be good for half as many instructions as a 32-bit cache would).

FWIW, I'm also not sure how many different applications 64-bit registers would be good for. For manipulating 3D vertices before sending them off to the GPU it'd be useful, but NEON already supports all the 64-bit registers you could shake a stick at. But 64bit is newer, and will benefit from newer designs and processes faster than any 32-bit processers that still get made will.

 

[Exophase]

Well, supporting the extra bus widths and instructions will require extra transistors, so more current is leaked, so while it's doing nothing it'll take more current. While it's doing work it's more complicated, and depends how you measure it - per kinstructions it's probably still more current, but per actual work done it may well be more efficient for certain tasks. That's all assuming process tech is the same, and cache sizes etc. (and of course, a similarly sized cache on a chip with 64-bit fetch would only be good for half as many instructions as a 32-bit cache would).

FWIW, I'm also not sure how many different applications 64-bit registers would be good for. For manipulating 3D vertices before sending them off to the GPU it'd be useful, but NEON already supports all the 64-bit registers you could shake a stick at. But 64bit is newer, and will benefit from newer designs and processes faster than any 32-bit processers that still get made will.

AArch64 supports 32-bit forms of instructions to avoid having to activate the upper halves of the functional units, for exactly this reason.

The instructions themselves are 32-bit, there is no increase in fetch, but pointer size goes up so there'll be an efficiency and performance hit for programs that use a lot of pointers. That's why a 32-bit ABI mode like x32 on x86 Linux is desirable. Pointers are still 32-bit but you get the other benefits of the 64-bit instruction set like the increased registers.

 

[matzesu]

An Mgba Port for Pandora would be great,
And hopefully an Pyra Port isnt that divicult..
But the topic is about the Case, so hopefully next week whe will see more pix

 

[levi]

Ah, that's good to know. So the extra registers and 64-bit instruction decode transistors are left completely unpowered while the processor is in 32-bit mode? Neat!

I guess you're right about the cache sizes, thinking about it. Assuming a split Harvard-style cache, the instruction cache will still be full of 32-bit wide instructions, so that doesn't need to grow, and while the processor can pull data out of the data cache 64 bits at a time, if a developer needed that resolution on 32-bit processors they'd have needed to load two 32-bit values into two registers. If a developer on an A64-capable processor only needs 32-bits of precision that's all they need to push and pull from the cache. There's a slight risk lazy devs will use parts that are too big, but the number of people coding to the metal these days mean most of them know what they're doing, I'd hope. Presumably in C code, ints, longs and so on are still the same width.

Edit: I guess that's a typo where you say pointers are still 32-bit at the end there, as you previously say that pointers go up in size. The way I read the docs I can currently find is that absolute addresses are now 64 bit, so that sort of pointer is now 64 bit, but register relative addressing is still 16-bit (8-bit 2's complement relative base and 8-bits of exponent). But you can't load and store those, so I guess that's irrelevant.

 

[Mrk]

Hello Mrk, welcome to the boards. First time poster I see.
What made you faint? The Psion? The concave/convex keys? The dillema? Or the first post, with pictures of the Pyra?

the "Psion" is fantastic (one of the best handheld of all time) but I fainted for TRANSPARENT PYRA ! Amazing
[doublepost=1455908075,1455907778][/doublepost]

welcome on board, i love your ava, btw.!

Thanks for the kind words! My fav C64 game was ARCHON ;-)