Search results

No, as @elvissteinjr stated, the Vita's SGX has 4 cores of its own that are not CPU cores, but GPU cores, and the Pyra's has 2. -God Ginrai

I'm all for the Pyra and know we can get great software on it as long as people are willing to write code for it, but let's be realistic here: Almost nothing in that video is possible on the Pyra. The entirety of that video was faked, and even if some of that stuff could theoretically be...

That's a neat little game. I tried the example level and it was really fun. :) -God Ginrai

You're mistaking the cart for the horse here. Saying that "open source software is good because it is not proprietary" is the same thing as saying "watermelons are good because they aren't lemons". They are 2 different kinds of software, and one isn't good or bad because it isn't the other...

Rather than "proprietary software bad", I think we should be saying "open software good". There's nothing wrong w/ using Discord. There's just everything right about using IRC. ;) -GodGinrai

Hope you're willing to patiently wait for that CPU board upgrade, then. (Or possibly even a successor <.<) -God Ginrai

To be quite honest, I think having FPGA tech on the next Pyra CPU board would be great. Obviously we'd still need a main CPU. But if we could get our CPU to dynamically set an FPGA depending on what system we are emulating, then that would be awesome. Not sure if FPGA tech (and powerful...

I'd say it's the opposite. Specifically having gone through the Pandora and other similar projects w/ long lead times before, I would say that a stable stream of updates (even if light in content) generally keeps a community better placated than long periods of time w/ no information. -God Ginrai

I was a GBAX customer who did get his device w/o having to pay a premium. I always felt that I got mine because I kept constant email communication to make sure that I wasn't getting lost in the shuffle. -God Ginrai

Can't we just make the nub click be the middle mouse button? -God Ginrai

SDs are supposed to last users a long time as well, but everyone has had one die on them at one point. AFAIK, these are both using NAND flash, so the risk is just as likely here. The difference is that if we were defaulting to a microSD instead of the soldered memory, we could just replace the...

Yea, I think reversing it is what I actually meant by disabling the automatic selection. The difference in the implementation would be that when the eMMC dies, the user isn't stuck having to hold a button all the time. That's a big difference. And your "best method" is exactly the situation...

You could easily have this functionality still be just as flexible by making the L1 just disable the automatic selection. That way, the functionality works best for the majority of users using the microsd while still allowing that flexibility of choice. Yes, but this leads to the issue that...

I see what you mean. However, could it not have been possible for the hardware to detect an inserted card and signal the mux automatically based on its presence? Since you can only use one or the other, it would make sense to assume that if you have a card in the microSD slot, that you intend...

Is it not possible to have U-Boot detect if the power-on was charger-induced or power-button-induced and load a charging microkernel instead of the regular kernel? I remember this being discussed, but never implemented, back on the Pandora. -God Ginrai

But it is in no way security. As I mentioned, you can boot from the left SD slot without holding L1, which means that any security issue that the microSD slot might have had exists with the quite obvious left SD slot. The requirement to hold L1 is not a feature. It's a bad decision that...

That's sophistry. It is as much a feature as "delay slots" are. It is a detriment to a standard expected use of the device and can lead to future issues and annoyances. And there is nothing about that that makes it more secure, given that you can already boot from the left SD without having...

Even that would be preferable. The issue with a u-boot config in the eMMC means that you're back to that L1 shit when your eMMC dies. The whole point of the internal microSD was to allow users to use that instead of the eMMC to allow the user to swap their default boot medium with little...

If the part I bolded wasn't there, this process would be perfect. Why the hell does it require L1 to be pressed here? And this is at the hardware level? Oy vey. -God Ginrai

You can't just make it boot from eMMC whenever an internal microsd is not inserted? That seems like the most logical way for it to work. -God Ginrai