Preparing for a Prototype

[Grench]

https://forum.xda-developers.com/ve...l/official-note-3-verizon-bootloader-t3359370

https://forum.xda-developers.com/note-3-sprint/help/galaxy-note-3-att-sm-n900a-rooting-t3389892

US versions with custom roms
[doublepost=1501875186,1501875112][/doublepost]

Also not true. I have never bought a phone through tmobile, always an international phone, and never told them my IMEI... but I use their sim

Your first link is to an exception for -some- versions of the Verizon Note 3.

Your second link is about an AT&T Note 3 - but stops where it's time to do anything about the locked bootloader.

Apparently tmobile isn't as strict about getting the IMEI as AT&T is. Go figure - AT&T is a pain.

Specific to the AT&T version of the Note 3:
https://forum.xda-developers.com/ga...enmod-13-0-t3238064/post63634929#post63634929
"N900A is AT&T's variant and it's bootloader is so tightly locked it cannot even fart if it wanted to.
No Cyanogenmod or any other AOSP ROMs for you, mate. If I remember correctly, there was a way to flash Samsung based ROMs on the thing, but not AOSP.
Sorry that you had to learn it that way.
If you wanna tweak phones, buying them from AT&T is the worst idea ever. "

This thread has a better chance of working:
https://forum.xda-developers.com/note-3-att/development/rom-aryamod-v7-2-n900a-t3193884/page24

However - reading through the thread its pretty hit & miss. But - you're right. There may be hope yet for these 'old' phones.

 

[Swordfish II]

Yeah I don't know what the "safestrap" method is but it looks like there is some success.

Sucks that they make it so hard though.

Good luck

 

[WizardStan]

Also not true. I have never bought a phone through tmobile, always an international phone, and never told them my IMEI... but I use their sim

Before my carrier had its unlimited Canada and US data plan, when I visited the states I needed a SIM card. I just walked into a T-Mobile shop, picked up a SIM card, gave the cashier $10, and walked out. One of my earlier smart phones was from T-Mobile, we're talking, like, 15 years ago, but I needed it unlocked to use it on my Canadian carrier. I called them up, gave them the IMEI, gave them the date I purchased it, they verified their records and within an hour I had a code. They've been so good to me I have difficulty understanding why anyone would bother with anything else.

 

[Grench]

The race is on...

The two year anniversary for my prototype pre-order is coming up in 50 days. (October 19th)

There are multiple Pyras in developer hands and many issues have been smoothed out. Is it possible that I might get a Pyra prototype before the 2 year anniversary?

Which will happen first?

 

[Grench]

Sandisk has released a new microsdxc card with 400GB of storage. They also announced a 1TB sdxc card over a year ago - but that has never actually been made available for purchase. But - with this listing, the 400GB microsdxc becomes real.

https://www.amazon.com/SanDisk-Ultra-microSDXC-Adapter-SDSQUAR-400G-GN6MA/dp/B074RNRM2B

So, since I periodically create a 'max theoretical pocketable Pyra storage' article. it is time to update.

32GB - The Pyra is slated to have a 32GB internal eMMC drive.
400GB - Behind the battery door there is an sdxc slot.
512GB - Left sdxc slot (current maximum sdxc orderable)
512GB - Right sdxc slot
---------
1456GB = 1.4TB max internal storage without adapters

Pocketability is still possible with very low profile USB to microsdxc adapters like these:

https://www.amazon.com/aceyoon-Adapter-480Mbps-MicroSDXC-MicroSDHC/dp/B06XKVS1XD

With two USB 2.0 ports and two of those adapters:
400GB left USB 2.0
400GB right USB 2.0
---------
2256GB = 2.2TB max internal pocketable storage

The Pyra has cracked the 2TB theoretical maximum pocketable storage threshold!

No - I can't afford to buy all that media. Yet.

 

[Grench]

The race is on...

The two year anniversary for my prototype pre-order is coming up in 50 days. (October 19th)

There are multiple Pyras in developer hands and many issues have been smoothed out. Is it possible that I might get a Pyra prototype before the 2 year anniversary?

Which will happen first?

Happy 2 year anniversary to my prototype pre-order!

Back to waiting.

 

[Grench]

Since it looks like we may be actually getting close to a final release to the prototype pre-pre-orders, I thought I would look around and consider what is available for day 0.
https://pyra-handheld.com/repo/apps

Good start, but needs more cowbell. The 19 apps listed misses some Pandora classics. So, I started thinking about some of the games I had spent the most time with on my Pandora. Who needs to do what to get these up and running on the Pyra?

Audacious (In Debian repository - should just be an, "#apt install audacious" away, right? So, things like that should, "just happen."

But, what about those that won't? The repo has 19 custom ports (largely thanks to @ptitSeb and @sebt3 and @TrashyMG). I can think of a few 'must haves' that are missing though.

Super Geometry Dust
https://pyra-handheld.com/boards/threads/super-geometry-dust.55772/
Made by forum member @wermy. Last seen on these boards in August of 2014.
I would love to see this dual nub oriented game brought forward to the Pyra. Hope it can happen.

Vulture's Eye
https://pyra-handheld.com/boards/threads/vultures-eye-port.62174/
Ported by forum member @keek. Last seen on these boards in June of 2016.
This is an isometric tile interface coupled with the otherwise character based Nethack. It is highly engrossing and is low CPU enough that the Pandora could play it for -hours and hours- without impacting the battery.

So, using the listing format from those two, what did you love playing/using on the Pandora that is not in the Debian repository and should be resurrected onto the Pyra?

It is strangely feeling like 2 Months is becoming a real possibility.

 

[levi]

Yes, Super Geo Dust is a good idea. I gave up on that game due to my dodgy Pandora nubs, but I'd love to be able to give is a go.

Since it's easily possible to mount pnds as some kind of iso file (usually squashfs these days, but maybe SGD is early enough it's a plain iso), it shouldn't be beyond the will of man to pull the binary out. The CortexA8 in the Pandora is an Armv7-A part, as is the CortexA15, so a lot of stuff will just run without any recompilation. There's be some tricky bits, especially anything that depends on the exact NEON register geometry, or things that depend on Notaz's SDL super scaler, but most things will be basically runnable I suspect.

 

[WizardStan]

The CortexA8 in the Pandora is an Armv7-A part, as is the CortexA15, so a lot of stuff will just run without any recompilation

There's more than just the CPU to consider. I'm pretty sure the Pandora is using soft-float ABI where the Pyra will be using hard-float ABI. Anything that uses any floating point instructions will not work.

 

[levi]

Hmm, good point. That's going to cover quite a lot of stuff then. But presumably it's not beyond the wit of this community to come up with a ginge-type thing which either statically or in-time spots those FPU invocations and patches them.

I had just noticed that the A15 has a longer pipeline than the A8 and wondered if that was going to cause any problems. I think Exophase told me that that was no longer the ball-ache it was when Digital extended the pipelines on their StrongARM chips and broke all of the PC-relative addressing, and that nowadays ARM chips take the relative address as relative to the instruction being executed, not the latest being fetched, so you never need to work as if you were actually a few instructions ahead of where you are now when writing the code these days.

 

[Letalis Sonus]

which either statically or in-time spots those FPU invocations and patches them.

AFAIK the ABI type is actually being looked at when loading the binary, so you need to take care of that as well to be even able to do that. After that you need to have a shim that cleanly shifts the data from the stack into FPU registers and vice versa for each function - I kind of doubt that there's an easy way to reduce this to just a set of generic shim functions. You'll likely need to know how many FPU arguments are being passed, that information is not part of the symbol, either.

However, the flash is rather roomy, we could just go dual-stack and provide the essential libs for both ABIs. The only thing that needs special care is probably the GPU driver.

 

[sebt3]

Audacious (In Debian repository - should just be an, "#apt install audacious" away, right? So, things like that should, "just happen."

Yup, I wont port audacious as there's no point (or too small to actually care about this).

But, what about those that won't?

The issue here is the lack of 3D drivers (or to be more exact, the fact that it's currently not working)
Nowadays nearly all games depend on GL(es) one way or an other. Even 2D games still depend on 3D drivers (SDL2...). I ported the few I wanna have that dont depend on 3D.
And as far as I know nobody is working on that issue...

The worst of all is : we have all the tools now to make porting games a breath. Since there's an input daemon there's no input code to change to make the port work (unlike the pandora). And because of ptitSeb's GL4es project (that should be part of the OS) there's no gl->gles conversion to be done. So a "port" should now just be a recompilation... once the 3D drivers are working properly...

It is strangely feeling like 2 Months is becoming a real possibility.

yup

 

[levi]

The only thing that needs special care is probably the GPU driver.

I doubt it, the GPU shim driver speaks OpenGLES and other graphics primitves, so if you're using GL4ES, or SDL2 and normal things like that you'll be fine. There are probably some environment variables designed to configure the frame buffer which will be ignored for now, but once we have the TI binary and the GPU shim kernel driver working, it should basically look the same as the pandora in terms of graphical tricks.

I'm also a little disappointed that not much is going on in getting the GPU all rigged up, but I've had it explained before that there's no point in doing that before the kernel is hardened. Maybe also a majority of the people currently coding aren't gamers and are just looking to get the desktop and apps running at present, but hopefully there's still time for that to change as prototypes go out to developers who are more focussed on gaming. This does suggest we might have a problem every time the kernel receives a big update from debian sources, which is a good reason perhaps to go with a stable debian version which will only give us the security updates.

 

[Grench]

So, without GPU drivers, Super Geometry Dust might not happen.

What about things like Vulture's Eye? I would be a bit shocked if it actually got into 3D acceleration - not much for animation going on there. Are there other 2D Pandora games that could/should be given a shake?

 

[klapse]

Hase! HASEHASEHASEHASE

 

[levi]

And Space Rocks!

 

[Grench]

Hase! HASEHASEHASEHASE

And Space Rocks!

I don't think I've played or even seen either of those. Got links?

 

[ible]

i think you're a heretic if you haven't heard of hase. i don't even own a pandora and i know about it.

http://repo.openpandora.org/?page=detail&app=hase_prototype-hase_prototype-12345

 

[Grench]

i think you're a heretic if you haven't heard of hase. i don't even own a pandora and i know about it.

http://repo.openpandora.org/?page=detail&app=hase_prototype-hase_prototype-12345

So kind of like Angry Birds Space (gravity wells) only without the constant commercial interruptions and more varied firepower. I like it.

The screenshots look 2D. Am I right that this one could theoretically be playable day 1?

 

[levi]

It is 2D, but perhaps not in the way you're thinking. It uses a lot of scaling and a hell of lot of rotation functions, so I guess that's actually using GL/es rendering for speed. Might have a few dependencies on other work being done therefore, so maybe a day 2-months(tm) rather than a day 1.

FWIW, I consider if to be Worms with gravity, but I don't know this game Angry Birds Space.