Now Im Pissed...

[Vimacs]

sure, but you minimize the risk, and if something realy fails, theese to have VERY great support.

 

[andyB911]

Now Im Pissed...

Well you should learn to handle your drink!

I'll get my coat...

 

[Epicenter]

I just hooked my gp2x up to an ammeter to see how much current it draws.

Booting: 500 mA
Sitting idle in the menu: 350 mA
Playing a game: 500 - 600 mA depending mostly on the sound
Running the Yeti3d demo: 550 mA
Watching a video: 700 - 800 mA

Given these numbers, the video decoding helper core is clearly using a ridiculous amount of power. Probably more than both the 920T (looks like around 100-150mA given that the power draw is so significantly lower with the 920T sitting idle at the menu.) When a video player is ported that DOES NOT utilize this helper chip for its decoding (once running at a reasonable speed, not unreasonable at all since comparable ARM9 based processors in PocketPCs manage the same decoding tasks purely in software just fine) it should significantly increase battery life in video playback; even with a heavy ARM920T overclock. ARM9 cores just don't use that much power.

A backlight control is absolutely crucial. Backlights generally use more power than the CPUs in the systems they occupy.. the '2x appears not to be an exception.

Sigh. I was just about ready to buy a GP2X after I heard the joystick would be fixed. Now more battery problems? It's too hard to buy a GP2X

You won't read about the hundreds of people buying '2xes and using them uneventfully..

 

[Mudi]

Here, read about mine.

I bought mine. It came in the mail. At first I thought the screen came scratched (it took me about 10 minutes before I tried removing the second screen.) I updated to the latest firmware. Went very smoothly, no problems. 1600mAh batteries last an average of 2.5 hours, and they are old 1600mAh batteries. Every SD card I've tried has worked correctly. The default joystick cap is playable, though not ideal. I just recently updated to open2x, and the whole thing went very smoothly with no problems at all.

There, see, they occasionally do work as they are supposed to

 

[AireTamStorm]

Best way I've found to discharge batteries is to put the things in a GBA and leave it on overnight. Connecting them to things like lights or other run-until-it-dies devices also help.

Heres my benchmarks:

Radio Shack 1800s: 1:45-1:55 of video.
6-7 hours idle.

Quantaray 2500s: 2:45 or so of video.
Nearly 10 hours idle.


I was really impressed by the lifetime demonstrated. I run out of video on the SD card before I run out of battery (1 GB). I haven't benchmarked things like TV-out or peripherals in action yet, will get those in as soon as I get my damned unit back from repair.

since comparable ARM9 based processors in PocketPCs manage the same decoding tasks purely in software just fine)

hehehe, NO. first off, PocketPCs don't use ARM9s (except lower end ones), they're packin Xscale CPUs. Some of which have MPEG decoder functions on them. My iPAQ hx2795 is able to play any video I want. AT 624 MHz. My previous unit @ 400 MHz: WMV encoded at under 320KBps video and 192 KBps audio. The unit before that @ 200 MHz: Not a chance for playing DivX, and anything I could play resembled RealVideo for dialup. (3600's outperform many modern budget Pocket PCs ) and that was running StrongARM.

Now, I don't transcode my avi's before putting them on the GP2X. Its running at 200 MHz, and plays my video within satisfaction. Thats beating my old 400MHz Pocket PC, which had twice the RAM.

Now, who is to thank? That chip.

 

[aapje89]

just buy from gp2x.de or gbax.com, they test evy single gp2x before sending them out.

thats not gonna help me now....

by the way, liksang also test their units, but my problem is not really testable, I mean when I put in fresh batteries it works normal but after like 1.5 or 2 hours it already isn't working whilst I have 2400mah ansmann batteries. GRRR

@AireTamStorm: are you sure that after 9 hours when you unit is still running it is not frozen, im sure that I can leave it displaying the main screen for 10 hours but mine just freezes after some time, but the screen looks normal. And when I try to reboot it, it will hang at boot.
What does your unit display when its batteries are empty, does it just freezes like mine?

 

[White Demon]

A mate of mine had a similar problem with his GP2X from Lik-Sang. He sent it back, and they told him that they had it working fine for over two days, but they sent him a new one anyway (which he has no problems with). So you should send it back if you believe it really is a problem (which from the sound of it, it is). Just make sure to tell them in detail what is happening, what you're doing etc.

And to send back to Lik-Sang, you have to get an RTA from them, so you will have to email them first.

 

[aapje89]

A mate of mine had a similar problem with his GP2X from Lik-Sang. He sent it back, and they told him that they had it working fine for over two days, but they sent him a new one anyway (which he has no problems with). So you should send it back if you believe it really is a problem (which from the sound of it, it is). Just make sure to tell them in detail what is happening, what you're doing etc.

And to send back to Lik-Sang, you have to get an RTA from them, so you will have to email them first.

thanks, I think I'll do that.

 

[Epicenter]

Best way I've found to discharge batteries is to put the things in a GBA and leave it on overnight. Connecting them to things like lights or other run-until-it-dies devices also help.

I said that way back on Page 2. God, read the thread already.

hehehe, NO. first off, PocketPCs don't use ARM9s (except lower end ones), they're packin Xscale CPUs. Some of which have MPEG decoder functions on them. My iPAQ hx2795 is able to play any video I want. AT 624 MHz. My previous unit @ 400 MHz: WMV encoded at under 320KBps video and 192 KBps audio. The unit before that @ 200 MHz: Not a chance for playing DivX, and anything I could play resembled RealVideo for dialup. (3600's outperform many modern budget Pocket PCs ) and that was running StrongARM.

Now, I don't transcode my avi's before putting them on the GP2X. Its running at 200 MHz, and plays my video within satisfaction. Thats beating my old 400MHz Pocket PC, which had twice the RAM.

Now, who is to thank? That chip.

Uh. XScale is a bastardization of ARM9 by Intel. They won rights to the old StrongARM architecture in a legal battle a while back. It's essentially a new chip inspired by the ARM5TE architecture and compatible with ARM code. It's ramped up to very high clockrates, but has very low overall efficiency-- this is why most XScale-based PDAs get fairly poor battery life and produce very noticable amounts of heat under heavy load. Due to the exceedingly low efficiency of these chips, a "pure" ARM9 implementation like the ARM920T in the Gp2x's MMSP2 usually performs to the same performance level of an XScale of TWICE the clock speed. For example, an XScale @ ~400 MHz will perform on par with a pure ARM9 or on the PDA front, Samsung's S3C2410 SoC based on the ARM920T, at 200 MHz! Reviews have proven this again and again as the reviewer picked up a shiny new PDA with a 624 MHz XScale only to find it was not significantly faster than the 312 MHz ARM9 derivative-based PDA they reviewed the month before.

You'll also see something interesting if you overclock an XScale, like Intel pretty much does at the factory for you by ramping up the rated clock speed and testing it to be stable.. you can get a ~312 MHz XScale and take it up to 700 MHz, but you won't see much in the way of performance gains past ~450-500 MHz. The performance actually starts to DROP the more you overclock. I've witnessed this firsthand; the chip burns through your battery life but provides no actual performance gains. Clearly high clock scaling does not aid the XScale architecture in performance. (Although this seems to be how it got its name. It scales well. It just doesn't get more done.)

Furthermore, as for hardware video decoding support, relatively few PDAs utilize it. For example, of Dell's famous x5x line, only the x50v-- their highest end and VERY expensive PDA has a video decoding helper core, and it's accompanied by a 3D accelerator-- see many of THOSE in PDAs? I didn't think so.

Yet, on my 2 PDAs with 300 MHz XScale processors (again, relative performance of a 150 MHz pure ARM9-based PDA) I was able to play XViD and DivX videos with encoded audio (e.g. AC3, MP3) without incident, achieving a full 24 FPS or 29.97 FPS often without an overclock of any sort, or with an exceedingly tiny one to ~400 MHz (again, rough estimation of ARM9 performance, 200 MHz.) This was with no hardware acceleration for video or audio decoding whatsoever-- all decoding done entirely in software. I don't know WHAT kind of video playback software you were using, but the video QUALITY should not vary based on the speed of the system unless you did a bad job of encoding it-- e.g. FAR too low a bitrate to look decent. You could also be using some downright terrible programs for playback. I never had problems playing most video files at more-than-acceptable framerates with my XScale at 200 MHz, UNDERCLOCKED, relative performance level of a 100 MHz pure ARM9; and if you had a PDA with a 200 MHz CPU at STOCK it was probably a pure ARM9-based SoC.

Your 'facts' definitely do not add up.

 

[machina2o2]

Just to report 2500mah MAHA batteries im getting similar run times as our OP here.

Did discharging 3x with MAHA high rated charger/discharger. Did the whle leaving the batteries running till they die thing over and over but i cant get the batteries to last longer than my communte which is a little under 2 hours.

 

[iignotus]

Not exceedingly on-topic, but I just tried out some Rayovac run-of-the-mill 10-for-a-buck AA batteries. I put them in my gp2x, turned it on, and went straight for Metal Slug 4 (in gngeo), overclocked to 266mhz, with sound at near full volume. They lasted 33 minutes before everything stopped and the screen faded away. Not bad in a pinch I'd say.

 

[AireTamStorm]

I've heard all the crap about XScale in terms of poor performance (thus the 3600 outperforming many modern low ends comment), but they still have the MPEG decoding functions on them. And what uses these functions depends on the software thats utilizing it. For instance, if you use Windows Media, I've noticed that video playback is very poor for what little formats it supports, but with things like TCPMP deskop-aimed video plays very well. Try looking in the options panels on that little piece of software, its ALL ABOUT Intel Xscale "optimization" etc etc etc... The fact is no handheld I know of can play desktop video at 200 MHz on an ARM architecture. My 3600 (StrongARM) cannot, and it outbenchmarks some of the top-of-the-line Pocket PCs of today in alphabetical sorts, Floating point math, etc. So you tell me why my XScale Pocket PC can play all the video my 3600 cannot, yet can't list me a directory as fast as my 3600 does.

Edit: Did I say "facts"?

Edit 2:

@AireTamStorm: are you sure that after 9 hours when you unit is still running it is not frozen, im sure that I can leave it displaying the main screen for 10 hours but mine just freezes after some time, but the screen looks normal. And when I try to reboot it, it will hang at boot.
What does your unit display when its batteries are empty, does it just freezes like mine?

Hmm, maybe. I think I came back, got fed up waiting for it to die, and shut it off.
Usually, my unit stops doing whatever is was doing, and then does 1 of 3 cool effects:
-Pixels slowly wipe to the side and white fills the screen, then the backlight dies.
-Suddenly the screen gets drawn over by vertical lines of random color, then fade to white again
-Random color blits everywhere, followed by backlight death

 

[Epicenter]

I've heard all the crap about XScale in terms of poor performance (thus the 3600 outperforming many modern low ends comment), but they still have the MPEG decoding functions on them. And what uses these functions depends on the software thats utilizing it. For instance, if you use Windows Media, I've noticed that video playback is very poor for what little formats it supports, but with things like TCPMP deskop-aimed video plays very well. Try looking in the options panels on that little piece of software, its ALL ABOUT Intel Xscale "optimization" etc etc etc... The fact is no handheld I know of can play desktop video at 200 MHz on an ARM architecture. My 3600 (StrongARM) cannot, and it outbenchmarks some of the top-of-the-line Pocket PCs of today in alphabetical sorts, Floating point math, etc. So you tell me why my XScale Pocket PC can play all the video my 3600 cannot, yet can't list me a directory as fast as my 3600 does.

The XScale itself, to my knowledge, has NO integrated video decoder. Optimizations for this processor may utilize enhanced instructionsets like MMX, SSE and SSE2 on the PC side of things. But the likelihood of the CPU containing a video decoder all its own? Exceedingly unlikely. System builders for PDAs use SoCs with different varieties of parts, which they select based on what the device will do. Much like the MMSP2. A CPU (an XScale, an ARM9 etc.), LCD handling hardware, card reader interfaces, USB interfaces, sound hardware, so on and so forth. Some would include a video decoder for higher-end machines. Some would not, for lower-end lower-cost machines. Every machine with an XScale being coupled with a hardware video decoder? I'd have to call BS on that.

Example:
http://www.intel.com/design/pca/applicatio...nots/280006.htm

Intel® PXA27x Processor Family Video Decoder Display Performance Optimization Application Note
The Intel® PXA27x Processor Family is equipped with system level features which enable advanced video and multi-media applications. These features include:

* Intel XScale® microarchitecture enhanced with Intel® Wireless MMX™ technology
* Capability of the LCD controller to display the YUV 4:2:0 format, eliminating software conversion from YUV to RGB
* On-chip SRAM large enough to be used for a frame buffer

Mentions of hardware features that help FACILITATE video decoding on the XScale processor, e.g. the high-speed framebuffer-capable RAM on the die of the chip, potentially much, much faster than off-chip RAM as used in other processors. Any mention of an actual hardware decoding unit? No.

 

[AireTamStorm]

I didn't say decoder UNIT, I said MPEG functions... which I believe are in the MMX, SSE, SSE2 and the newer SSE3 instruction sets. By all means correct me if I'm wrong.

And you still didn't answer my question.

So you tell me why my XScale Pocket PC can play all the video my 3600 cannot, yet can't list me a directory as fast as my 3600 does.

 

[Epicenter]

I couldn't tell you, since your statement is circumstantial and anecdotal in nature. There are so many variables it's an unanswerable question without more info .. your player, the codecs you used, if the video was the native resolution of the PDA or if it had to be scaled, if you were in portrait or landscape mode and rotation had to be applied, video bitrate, native framerate, optimizations (as we discussed), clockrate you operated the machine at while playing the video are just SOME of them. It's much too loaded a question to just answer succintly-- and your test case, for this reason, cannot be so easily equated to the GP2x's software decoding capabilities in such a manner as "It's not an XScale, it can't do software decoding".

Don't quote me as I do not use the MMX/SSE instruction sets personally, but I do not believe they embody any sort of predefined MPEG decoding functionality. They are only instructions that, when used in assembly bits added to a program, are of better use for multimedia functionality e.g. video decoding than standard math operations would be. How much of a benefit these truly provide, I do not have benchmarks to quantify for the XScale. However, using an XScale processor performance equivalent of the ARM920T @ 200 MHz in the GP2x, I've seen satisfactory performance in players that I do NOT believe have this functionality. For example, VideoLAN (VLC). An overclock might be required to achieve full framerate on some particularly high-bitrate videos, but if the video is 320x240 and does not need to be SCALED, it should decode rather well in software alone with no helper units on the GP2x's ARM920T-- with a fast and well-optimized player! That is my predominant point and I am sticking to that.

Bear in mind, a lot of the battery issues people experience may be caused by the scaler-- it seems to be a MAJOR power hog. Note the huge battery drain using TV Out, which does appear to need to perform some scaling to generate a TV-compatible signal.

 

[Crazy Goat]

Wireless MMX adds 16 64bit registers, which allows the Xscale processor to run four MACs or eight adds single cycle.

The WMMX is usually used in video and game acceleration.



But, with the introduction of the PXA27x - a graphics co-proc was added. I believe there were 2-3 variants. The 2700G aided in 2D and 3D acceleration, and the lower end models were used for 2D acceleration.

 

[AireTamStorm]

I couldn't tell you, since your statement is circumstantial and anecdotal in nature. There are so many variables it's an unanswerable question without more info .. your player, the codecs you used, if the video was the native resolution of the PDA or if it had to be scaled, if you were in portrait or landscape mode and rotation had to be applied, video bitrate, native framerate, optimizations (as we discussed), clockrate you operated the machine at while playing the video are just SOME of them. It's much too loaded a question to just answer succintly-- and your test case, for this reason, cannot be so easily equated to the GP2x's software decoding capabilities in such a manner as "It's not an XScale, it can't do software decoding".

Don't quote me as I do not use the MMX/SSE instruction sets personally, but I do not believe they embody any sort of predefined MPEG decoding functionality. They are only instructions that, when used in assembly bits added to a program, are of better use for multimedia functionality e.g. video decoding than standard math operations would be. How much of a benefit these truly provide, I do not have benchmarks to quantify for the XScale. However, using an XScale processor performance equivalent of the ARM920T @ 200 MHz in the GP2x, I've seen satisfactory performance in players that I do NOT believe have this functionality. For example, VideoLAN (VLC). An overclock might be required to achieve full framerate on some particularly high-bitrate videos, but if the video is 320x240 and does not need to be SCALED, it should decode rather well in software alone with no helper units on the GP2x's ARM920T-- with a fast and well-optimized player! That is my predominant point and I am sticking to that.

Bear in mind, a lot of the battery issues people experience may be caused by the scaler-- it seems to be a MAJOR power hog. Note the huge battery drain using TV Out, which does appear to need to perform some scaling to generate a TV-compatible signal.

Now this I can agree with.

A while back Intel implemented something called "Wireless MMX" into XScale chips. These contained special instructions from the MMX and SSE instruction family lines. Therefore, I can't see any drops or stops at high motion parts in higher bitrate video, on a higher end processor.

What I didn't agree with was the statement that the ARM chip alone could handle video, seeing as "Pocket PCs do it fine in software mode". Pocket PCs (mine at least) for the type of video I use requires the heavy utilization of special multimedia instructions, which the XScale contains and the software (tends to) use. Some of these videos get my P4 up to 20% or so CPU usage (using i686 binaries), so its quite hard to believe that the ARM architecture can take it without being somewhat designed for it.

The video decoder chip you mentioned is probably (as you said) the one utilizing so much power. However, I neither believe that it was put on the board for nothing, nor that not using it would be a good idea. Even if we wrote a player for lower bitrate video that utilized only software, it wouldn't be practical for the average Joe that can't even remember the keyboard shortcuts for copy and paste. (not that the GP2X in itself is either.)

What WOULD be a good idea: To write algorithms that test the video and audio bitrates to see if the ARM can manage the media solo, and if so, disable the features provided by the chip on board. This way, its transparent, and effective.

I think TV out starts at 320x240 and scales it up to the maximum resolution. Thats what it LOOKED like at least, on my TV. I know there's a chip that handles/aids scaling, so I'm not sure that adds too much overhead.

 

[Crazy Goat]

A while back Intel implemented something called "Wireless MMX" into XScale chips.

Beat you to it.

I think TV out starts at 320x240 and scales it up to the maximum resolution. Thats what it LOOKED like at least, on my TV. I know there's a chip that handles/aids scaling, so I'm not sure that adds too much overhead.

The MagicEyes co-proc has a max resolution of 1024x768 - I am quite sure it is capable of rendering content at NTSC and PAL standards.

 

[aapje89]

omg, go fight somewhere else than in my thread!

 

[AireTamStorm]

Beat you to it.

ugh I know >_<
You finished while I was still in the middle of it.
Anyway, I did confirm that Wireless MMX has some SSE and MMX (obviously) instructions in it, not sure about SSE2, didn't dig that far. It also has some new instructions, not just copies.

The MagicEyes co-proc has a max resolution of 1024x768 - I am quite sure it is capable of rendering content at NTSC and PAL standards.

You're probably right. They said 720x480 in the specs, but thats a weird res, I don't believe that too much. Most NTSC TVs display at one of these 3 resolutions: 640x480; 800x600; 1024x768. If they had that weird res some TVs might not support it (I don't thoroughly know the specs for TVs, this is just from experience). So it would make sense if these higher res modes are supported. That'll also mean good things when trying to hook the GP2X up to a PC CRT with a keyboard and mouse (since 1024 is a popular res for desktops). Then we'll have a very cheap Linux ARM PC. (I'm so going to get shot up for practicality on this one though >_<)