Beauty competition.


Legodude522 said:
That link must be buried somewhere. My order was recent so I'm sure y'all will get yours before me, 23 March 2020.
Click to expand...
Also the order monitoring mechanism was interrupted by the update to this forum website, wasn’t it?
 
@EvilDragon The Dark Chrome looks almost exactly like what I want in the images, but looks brighter in the video. Can you explain to me if it looks darker than the gray area on the back of the original 3DS you showed in that video?

-God Ginrai
 
Phlyra said:
Thanks for the info! So these are potentially instead of the heat pipes, or additional to? IIRC, the heat pipes are supposed to be arriving any day now...
Click to expand...
Search function seems to be working correctly again after the outage earlier and I came across this regarding heat spreaders:

EvilDragon said:
Fujitsu aren't the only ones with such solutions.
There are some synthetic carbon (I think) pads which let you distribute the heat or move it anywhere you want.
And special silicone mats that can shield the heat (so that it doesn't warm up critical areas like the battery). You can actually put these mats on a 200°C stove and put your finger on top of it :)

We've got both here and can test whatever we want. We got enough space between the PCB and the battery compartment to shield, we got enough space between the CPU and the PCB to use some heat distribution if need be.

The main idea is to move some of the heat to the SD Card slots (which have a large metal case and are open, so they can exchange the heat with fresh air) and use large copper areas in the PCB for heat distribution.
The most important thing is to DISTRIBUTE the heat, so that it doesn't stay in one tiny spot.

I've opened some tablets which use the carbon stickers I mention above. They mostly only have a 4x4cm sized carbon sticker on top of the CPU. It doesn't connect anywhere, it just exists to distribute the heat to a wide area, so that the overall temperature is lowered.

The EVM doesn't do anything like that.
It has a very simple heatsink on the SoC that doesn't do much: According to my measurements with a temperature meter, it only lowers the temperature by about 10 - 15°C.

Additionally, the EVM is not very optimized regarding power usage. Without even switching it on, I used up to 300mA when I measured.
And the heat from the EVM doesn't seem to come from the CPU only. When I did my testings, it seemed to me that the PALMAS (the power chip) also adds a lot to the heat, and it sits near the OMAP5.
I was able to measure up to 120°C when running the EVM with full stress test for a while, whereas Nikolaus only measured up to 65°C yet on the Pyra CPU board (also with stress test).

I can imagine the PALMAS heats up a lot on the EVM - it needs so much power that a Pandora AC adaptor isn't powerful enough to run it without crashes... and as all the power distribution goes through the PALMAS... yep, that generates quite a bit of heating.
The EVM was never built to be optimized in power usage, it's built so customers can evaluate all features.

When I was running the EVM with X and standard usage, I measured about 55 - 60°C.
Nikolaus measured about 35 - 40°C for the same on the Pyra PCBs.

So I don't think it'll be that bad, but sure, it'll generate a lot more heat than the Pandora when you fully stress it.
Click to expand...

So it would appear that they are pretty much just carbon stickers/pads?

Surprising that they should be taking so long to arrive but then I guess that’s the current situation for you...
 
daveshah said:
First you will need to start with a Buster installation (I think dist-upgrade should work, otherwise install one of the newer images). Then, to install the new kernel - instructions from @aTc on IRC as I haven't tried this on my own unholy hybrid of Letux and PyraOS that I am currently developing with:



Hopefully, this should start up with a correctly rotated screen.

For the TILER+3D, first download and extract tiler_shim somewhere. apt install supertux or whatever you want to play (TORCS works too but is quite slow).

Then wherever you extracted tiler_shim; run `./init.sh` followed by `./run.sh /usr/games/supertux2` (if running from SSH or serial, make sure DISPLAY and XAUTHORITY are set)

I have only tried SuperTux on the uEVM, so I can't guarantee it will behave correctly on the Pyra hardware (resolution settings might need changing, etc).

Have fun :)
Click to expand...

So - I was trying this out and got to download the tiler_shim.tgz and...

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

I downloaded it twice, same error. Doing this on Marble, my Pyra prototype. Is the tiler_shim.tgz archive in some weird format or corrupt or ?

Thanks!
 
irccloud where I uploaded that has been having a very bad day today...

Try this link instead: http://ds0.me/tiler_shim.tgz
Post automatically merged:

Sorry, I'm an idiot, looks like I created a tar archive with a tgz extension for some reason. Try renaming it to .tar and all should be fine (I'm so use to stuff auto-detecting compression that I didn't notice when I was using it).
 
daveshah said:
irccloud where I uploaded that has been having a very bad day today...

Try this link instead: http://ds0.me/tiler_shim.tgz
Post automatically merged:

Sorry, I'm an idiot, looks like I created a tar archive with a tgz extension for some reason. Try renaming it to .tar and all should be fine (I'm so use to stuff auto-detecting compression that I didn't notice when I was using it).
Click to expand...

More mystery...

Interesting. tilershim.tgz extracted fine on my Kubuntu main X86 workstation but won't extract on the Pyra.

I will try renaming it on the Pyra - maybe it is just more sensitive.
 
@daveshah Getting closer. Renaming to .tar made the archive work on the Pyra.

Trying to run ./tiler/init.sh results in an error though:

modprobe: FATAL: Module pvrsrvkm_omap_omap5_sgx544_116 not found in directory /lib/modules/5.6.15-letux-lpae-tiler
[default]
WindowsSystem=libpvrDRMwSEGL.so
DefaultPixelFormat=RGB888
PVR: (Error): SrvInit: PVRSSRVInitSrvConnect failed (129) [0, ]
/opt/omap5-sgx-ddk-um-linux/bin/pvrsrvctl: SrvInit failed (alreaddy initialized?)
(err=PRVSRV_ERROR_SRV_CONNECT_FAILED)

Thoughts? Where did I screw up?
 
Due to various naming possibilities and the fact that the proper Pyra kernel usually loads the module automatically anyway that error can probably be ignored for now.
 
daveshah said:
Due to various naming possibilities and the fact that the proper Pyra kernel usually loads the module automatically anyway that error can probably be ignored for now.
Click to expand...
Yeah - something isn't clicking. I'll just have to wait for you to get a Pyra. :)

I tried loading Supertux 2.0 and the opening screen is still a slide show. Getting closer.

Mods: If you want to get this technical support conversation out of the news, you are welcome to move it to: https://pyra-handheld.com/boards/threads/preparing-for-a-prototype.76956/

Thanks!
 
You must log in or register to reply here.

Similar threads

EvilDragon
Keymat Sample Pictures!
2 3
Replies
47
Views
17K
ibisum
ibisum
urjaman
White-On-White Fields With A Black Theme
Replies
5
Views
2K
urjaman
urjaman
D
Improved promotional media
Replies
11
Views
4K
Grench
Grench
rygD
Dark theme
Replies
7
Views
5K
DrHAX
DrHAX
T
I think my Gamepark is about to pack in
Replies
5
Views
2K
SephirothIce
S
Back
Top