New And Improved Unified Xgp Design Poll

[DaveC]

Well, it really depends on the application, but I've found that some 4:3 apps, including games, don't look too bad on a 16:9 display resized (altering the aspect ratio of the image, yes it does look a bit squashed, but it doesn't look too bad). Another option is to maintain the existing aspect ratio and resize to 362x272 or thereabouts, but I think it's actually less aesthetically pleasing than squashing the display.

It isn't just about aspect ratio. Fractional stretching distorts the pixels because some are doubled some are not giving a very uneven distorted look. It just looks horrid. Yes you can add a filter which just blurrs out and attempts to hide the uneven scaling but it just ends up overcooked and blurry.

Graphics just look better when displaying at 1:1 resolution. The point was that 320 x 240 matches most emulated games very well. Sometimes you have a small border but at least the image is sharp. If the main focus is not going to be emulators then yes more res is better.

 

[Shikaku]

Actually, there are algorithms that give very nice doubling resolution ratio out there. I believe it is in MAME or some tangent version of it, but the point is is that scaling up CAN look nice...

http://scale2x.sourceforge.net/

That's what it is

http://www.hiend3d.com/hq2x.html

Also this

This is why I prefer 640x480 by 320x240 or that 480x272 whatever thing. Sometimes scaling can be nice, but not to change ratios...

 

[Lancer-X]

2xSaI is nice, and _fairly_ cheap in terms of efficiency, but it would depend on the application in question whether such a thing is applicable or not.

The problem is that doubling isn't very good for 320x240 -> 480x272, but there are other decent resizing algorithms. Performance is the main worry, though.

It can be emulated just fine on the GP2X, I just have a feeling that it won't be quite as snappy for the more graphically-intensive titles due to the complexity of the 2D subsystem-- it's similar to the SNES and look at the trouble emulator authors have had with that. The existing emulators are also rather slow and clunky C, not tiny, fast optimized ARM9 ASM. So odds are you'll still be looking at a good bit of overclocking even with the ARM7 CPU code running natively. The XGP series would have the extra kick of 2D acceleration for handling all those pesky things like transparencies.

The tiresome thing is that a lot of the GBA's graphical stuff is very nonstandard, especially when it comes to multiple layers, weird priority values and partial transparency. I suppose it depends how much compatibility you're going for, but either way, everything is going to be working against the poor person trying to use hardware acceleration to boost graphical performance.

I'm sure it could be done though!

 

[Epicenter]

Actually, there are algorithms that give very nice doubling resolution ratio out there. I believe it is in MAME or some tangent version of it, but the point is is that scaling up CAN look nice...

http://scale2x.sourceforge.net/

That's what it is

http://www.hiend3d.com/hq2x.html

Also this

This is why I prefer 640x480 by 320x240 or that 480x272 whatever thing. Sometimes scaling can be nice, but not to change ratios...

On a side note, this looks vector based and would probably be quite snappy on the S3C2460 .. if you didn't do scaling in hardware on the GPU

 

[Shikaku]

Performance with the XGP if it has the FPU can be very good. I really am guessing that regular scaling would be almost or just be "free," as in the GP2X. I can guess these processes would not be too hard to implement, and would not affect speed much

 

[DaveC]

Actually, there are algorithms that give very nice doubling resolution ratio out there. I believe it is in MAME or some tangent version of it, but the point is is that scaling up CAN look nice...

http://scale2x.sourceforge.net/

That's what it is

http://www.hiend3d.com/hq2x.html

Also this

This is why I prefer 640x480 by 320x240 or that 480x272 whatever thing. Sometimes scaling can be nice, but not to change ratios...

Doubling is ok because it is even. Every pixel is doubled. 2:1, 3:1, 4:1 etc.

The fractional scaling like 1.5:1 is where things look ugly. This is because you selectively double some pixels while leaving others at 1:1.

 

[rei_yano]

I suppose I agree that if anybody can be succesful with the xgp at widescreen aspect its gotta be gamepark. I imagine that only a fraction of the apps out there would take real advantage of it all. leaving most of everything out there either squashed or cut off. That is a big fear of mine. that would suck major nuts.

you know if they made the xgpmini a widescreen as well I wouldnt be saying much of anything becuase of the easability of programming for both machines at the same time. not that I am a developer. Im only at a very novice level of python as I type this and that isnt making much even on the pc. maybe a text adventure lol. but I still think about the dev community and what would make things easier for them. another thing is I dont see much media in widescreen right now. only movies. some tv shows but not many.

I would be really happy if there was like 300 + apps on the xgp that were specifically made to be enjoyed via widescreen. and mind you all these apps gotta kick ass. no rpg maker garbage. I still dont see emu being enjoyed on the unit however. I imagine a lot of complaints. if xgp doesnt satisfy the emuholic types I hope that GPH takes the chance to satisfy these customers cuase they are a big chunk of the gp/gph community.

 

[Epicenter]

I guess I could deal with it if the XGP was widescreen; I'd really prefer it not be though since I won't be buying a Mini in the foreseeable future (I just cannot stand a screen that small, it's too hard to discern any real detail.) I can tolerate stretched out emulators if they are at least filtered well, I suppose, since emulation on a handheld is always going to be inaccurate (there is usually not enough horsepower to port an emulator for a PC like KEGA Fusion or Gens which are super-accurate as far as emulators go) .. or Nestopia for NES (which is much more accurate than FCE, so forth), so what's the big deal in sacrificing a little more 'genuine' appearance.

My bigger concerns to widescreen in the full XGP are:
- Emulation limitations might bother other people more, and emulator support and popularity is crucial to the XGP's success. Homebrew is only half of what made the GP32 famous after all, and emulation is the vast majority of the GP2X's appeal by and large.
- The unit will be bigger and bulkier, and more cumbersome to hold than if it had a narrower display.
- More pixels = More chance of dead pixels, which shouldn't be an issue as much if the displays are good, at least. But who knows if GP will have a dead pixel policy?
- More backlighting for the bigger screen, more power draw. Won't matter if it's LED-lit, will matter if it has some kind of a CCT.

 

[Exophase]

Should they opt for the S3C2460, it'll be enormously more powerful than the GP2X. A 266 MHz CPU clock is just the start, you should be able to overclock to well beyond 300 MHz out of the box. A full FPU means two things:
- Massive speed boosts for Float-intensive programs, especially 3D games like Quake, Doom, etc.
- If floating point and Integer code are used proportionally, it will work like having 2 parallel processors working on the same program .. because essentially it will. Used correctly, you could see performance gains approaching 100% at the same clockrate in a lot of tasks!
- The AFP9 unit is also a vector processor, which will help provide huge performance boosts for things like the GTE in PSX4ALL, compounded with the huge CPU speed boost.
- The 2D/3D accelerator will provide major gains to 2D emulators, enormous gains to 3D emulators, and allow a whole new generation of 2D homebrew, with vastly superior graphical intensity capabilities than anything the GP2X can run. No longer will the machine grind to a halt when you throw a thousand sprites and alpha blending at it, either.
- The entire memory subsystem will be dramatically faster, due to the use of MobileDDR instead of slower SDRAM (effective clockrate of 266 MHz) and if Samsung is making the SoC, we can rest assured SD DMA won't be broken like in MagicEyes chipsets, which means streaming data off the SD card in realtime without interrupting the CPU's work.

266+MHz CPU with FPU, VFPU, 2D/3D accelerator, DDR SDRAM.. sounds like PSP to me! But ARM instead of MIPS (worse instructions per clock ratio, but less instructions needed) and only one CPU. I'm assuming it has an MMU, which is a huge advantage for emulators.. IF it can be accessed normally (no weird hacks like in GP2X!)

I'm not 100% sure if a typical single precision VFPU will work well for GTE emulation in PS1.. I hope so as much as you do, because of emulation opportunities on PSP. It's just that PS1's GTE is a fixed point accelerator, operating at a high 48bit precision. Unless the VFPU has double precision components (unlikely) there will be some major loss of precision in going from that to 32bit floats. Whether or not it can handle that is anyone's guess.

Also, 2D acceleration is great, but doesn't GP2X have some? It seems to me like it's vastly underutilized, but there. Of course 2D via 3D acceleration can be a lot easier to use and usually gives all of the benefits if not much more. But like Lancer-X said, using hardware acceleration for 2D is anything but trivial, in fact, for systems like GBA it's impossible to do completely, at least not in any kind of straightforward way. People just don't realize this, they see a system that blits tiles and thinks that it's easy to map to acceleration. But these consoles are usually drawn line by line and have some very weird notions of layering/priority and blending. On the other hand, most emulators have very inefficient software renderers. My emulator, gpSP, is 100% software rendering but it smokes the performance of VBA's renderer.

Having parallel integer/floating point pipelines will never give a 100% speed increase, it's superscalar but nothing close to having two cores. Code is just far too integer/branch dependant, you can't escape this, in all but the most intensive scientific computation applications (which no one using an XGP will care about). I agree that it's a good thing though. It was only the careful pairing of integer/FPU in Pentium ASM that enabled games like Quake to be so fast on those CPUs, I think.

Question: what is the cache like with that CPU package? I mean size and set associativity. Most of these systems have very little cache (well, normal amounts of L1, but no L2) that is also not very associative. Their CPU clock to memory clock ratios aren't so bad, but there's still a ton of latency on DDR SDRAM, probably well over 100ns, which doesn't suit the ~4ns clock rate very well. Some L2 cache (I dunno, 128kb?) would be great, it could possibly get there in 2-4 clock cycles...

I still don't really understand the big deal about having some wasted screen space. Like mentioned you could even put extra information there. Although it should be asked, would a 480x272 screen be proportionally larger than a 320x240 one? If not I can see it being a hindrance. But the thing about emulator accuracy... most emulator inaccuracies don't affect a majority of games at all. Stretching the screen would affect all of them pretty noticeably. Stretching a 256x224 display to 480x272 would be pretty awful, in fact.

 

[Epicenter]

266+MHz CPU with FPU, VFPU, 2D/3D accelerator, DDR SDRAM.. sounds like PSP to me! But ARM instead of MIPS (worse instructions per clock ratio, but less instructions needed) and only one CPU. I'm assuming it has an MMU, which is a huge advantage for emulators.. IF it can be accessed normally (no weird hacks like in GP2X!)

The big advantage of the ARM microarchitecture here is the extremely low power consumption. MIPS chips drink power like water. Also, in my experience there's just not as much in the way of custom ASM code for common tasks for MIPS chips as for ARM ones (emulator cores spring very readily to mind.) There is an MMU, and there's no hacking necessary .. there's not really any hacking normally needed with an ARM processor and some RAM, except that the MMSP2 handles it strangely, tying the RAM to individual processors so addressing memory that is tied to the 940T from the 920T is an odd task to perform.

As for 'one CPU'.. the PSP, as far as I can tell, has just one CPU. The vector/FPU is a coprocessor, as is the 2D/3D GPU. I don't see any validity to the common claim there are 2 333 MHz MIPS chips in the PSP. If there were, I imagine it'd tear through its battery much faster than it already does, even at 222 MHz per chip.

I'm not 100% sure if a typical single precision VFPU will work well for GTE emulation in PS1.. I hope so as much as you do, because of emulation opportunities on PSP. It's just that PS1's GTE is a fixed point accelerator, operating at a high 48bit precision. Unless the VFPU has double precision components (unlikely) there will be some major loss of precision in going from that to 32bit floats. Whether or not it can handle that is anyone's guess.

Zodttd, one of the main developers of PSX4ALL, suggested the idea, so I imagine it's possible. Loss of some precision is probably not that big an issue. Emulation is an inherently inaccurate process. At any rate, if memory serves, PS1 games did a good bit of rounding off of coordinates, resulting in some interesting quivering of polygons.

Also, 2D acceleration is great, but doesn't GP2X have some? It seems to me like it's vastly underutilized, but there.

The GP2X has a blitter, but that's most of what it can do-- blit. It just copies memory quickly and does a few other things faster than you could do fully in software, like fill solid shapes. I've thrown big workloads at it, and it always buckles under the pressure-- the PS1 and Saturn were snappier at 2D than the MMSP2's blitter is, so you really need to rely on the ARM920T to do most of the work. It really does limit the hell out of you if you want to do something truly graphically intense as I am. Its functions are also very limited, so you can't really program it to do just what you want it to do, as far as I can tell. MagicEyes isn't keen on releasing documentation either, they'd rather let Dignsys write software for their clients and hide how the hardware works so they can keep it their little profitable secret.

Using acceleration on the S3C2460 or the VRender-3D will probably mostly entail a custom SDL library like Paeryn's-- maybe he'd want to work on one; who knows. You could also use SDL's OpenGL wrapper directly for new applications that don't use SDL conventions already.

Of course 2D via 3D acceleration can be a lot easier to use and usually gives all of the benefits if not much more. But like Lancer-X said, using hardware acceleration for 2D is anything but trivial, in fact, for systems like GBA it's impossible to do completely, at least not in any kind of straightforward way. People just don't realize this, they see a system that blits tiles and thinks that it's easy to map to acceleration. But these consoles are usually drawn line by line and have some very weird notions of layering/priority and blending. On the other hand, most emulators have very inefficient software renderers. My emulator, gpSP, is 100% software rendering but it smokes the performance of VBA's renderer.

I wouldn't recommend trying to accelerate most parts of drawing the display in an emulator. However, things like actually blitting the tiles, handling transparency, and offloading the tasks of scaling and rotation from the CPU will provide significant framerate boosts. The GP2X's GPU does extremely little to aid the first one, and nothing to aid the rest. Also, it's worth mentioning that VBA's renderer is a fucking abomination. It takes over 20 minutes of tweaking to get it to run at full speed on my Athlon 64 X2 machine a lot of the time, other times it'll run happily on a machine with a 600 MHz processor. It's just plain BAD.

Question: what is the cache like with that CPU package? I mean size and set associativity. Most of these systems have very little cache (well, normal amounts of L1, but no L2) that is also not very associative.

I don't have that many details about it, but I know it's Harvard-architecture L1, 16KB instruction and 16KB cache, both 4-way set associative with a 32 byte line size. Sure, I'd love some L2 cache, but for their purpose, this seems to work just fine.

I still don't really understand the big deal about having some wasted screen space. Like mentioned you could even put extra information there. Although it should be asked, would a 480x272 screen be proportionally larger than a 320x240 one? If not I can see it being a hindrance. But the thing about emulator accuracy... most emulator inaccuracies don't affect a majority of games at all. Stretching the screen would affect all of them pretty noticeably. Stretching a 256x224 display to 480x272 would be pretty awful, in fact.

Oh yes, it's going to look disgusting on a lot of systems. You'll probably have to just scale the image til it's 272 pixels tall and accept what width you get .. then maybe put some sort of border or menu options there. For the people who don't mind scaling it out of proportion, that can be an option. The screen will definitely be bigger at 480x272; it's big and pretty but ultimately not more useful, and makes the machine bigger and more cumbersome to hold. I prefer that when I hold a handheld, my hands nearly meet in back-- it gives me a good solid grip and more comfortable control overall.

The one way I can see that I as a developer would really benefit from a widescreen display is it the machine was fully comfortable to use turned on its side, for better play of vertical shooters. But this'd be original ones .. emulated shooters are generally 320x224 and won't fill the display.

 

[MWeston]

Epicenter, what do you think about a question asking people what type of memory cards to use and how many slots on the system? Is it universally accepted that SD cards are the way to go or maybe some sort of mix between two card choices is the favorite? What do you think?


Michael

 

[Exophase]

As for 'one CPU'.. the PSP, as far as I can tell, has just one CPU. The vector/FPU is a coprocessor, as is the 2D/3D GPU. I don't see any validity to the common claim there are 2 333 MHz MIPS chips in the PSP. If there were, I imagine it'd tear through its battery much faster than it already does, even at 222 MHz per chip.

The PSP has two complete 333MHz MIPS CPUs with full cache each.. it's not just a claim, there are a number of homebrew apps that actually USE both. Bear in mind that PSP uses a custom MIPS32r2 implementation, not an off the shelf one (even has some additional instructions). And I can't see any reason why MIPS would inherently use more power than ARM. It's a much simpler architecture in pretty much all aspects.

 

[Epicenter]

Epicenter, what do you think about a question asking people what type of memory cards to use and how many slots on the system? Is it universally accepted that SD cards are the way to go or maybe some sort of mix between two card choices is the favorite? What do you think?

Well, CF cards are a dying breed, Memory Stick is rather expensive just because it's a Sony product, and the other formats haven't really gained any large-scale acceptance across any wide array of devices yet. I don't even need to mention why SMC and MMC wouldn't be good ideas, either. If you need just a couple really good reasons, SD cards are tiny and cheap.

The PSP has two complete 333MHz MIPS CPUs with full cache each.. it's not just a claim, there are a number of homebrew apps that actually USE both. Bear in mind that PSP uses a custom MIPS32r2 implementation, not an off the shelf one (even has some additional instructions). And I can't see any reason why MIPS would inherently use more power than ARM. It's a much simpler architecture in pretty much all aspects.

I'll take your word on that; I haven't found technical specifications that mention more than 1 CPU, however. I'd have to wonder if the second core was in some way crippled-- if homebrew programs used it and commercial games don't, as your statement implies. Though it could also boil down to that game engines just don't parallelize well.

As for power consumption, MIPS chips in the past have traditionally used more power than their ARM counterparts. I can't say if this is the exact case with the implementation in the PSP; MIPS claims it uses less. I have to doubt it, though, since they advertise in the same page processors with 400 Mhz clockrates with a claimed 0.5w power consumption. Now, if you compare that to an ARM1176JZ(F)-S at 400 MHz, using ARM's spec of "Speed Optimized" rather than "Area" (more power consumption, so these are more 'worst case' figures than anything), the figure would be 0.18w. That's a pretty dramatic difference. Another of MIPS' designs offers 2 1 GHz cores with 5w of power consumption. 2 ARM11s at the same clockrate (They do scale that high) would put you at 0.9w with the same "Speed Optimized" design.

 

[MWeston]

Well, CF cards are a dying breed, Memory Stick is rather expensive just because it's a Sony product, and the other formats haven't really gained any large-scale acceptance across any wide array of devices yet. I don't even need to mention why SMC and MMC wouldn't be good ideas, either. If you need just a couple really good reasons, SD cards are tiny and cheap.

Yeah, I figured that the only two real choices were SD and CF. I wonder why CF is considered a dying breed? I have heard that from others too. I like the idea of having access to microdrives as well as flash memory cards because of the 4,6,8,12,....15GB possibilities. Sure they use more power but it is negligible when copying a game to RAM before executing and then powering down the card again.

 

[Epicenter]

Yeah, I figured that the only two real choices were SD and CF. I wonder why CF is considered a dying breed? I have heard that from others too. I like the idea of having access to microdrives as well as flash memory cards because of the 4,6,8,12,....15GB possibilities. Sure they use more power but it is negligible when copying a game to RAM before executing and then powering down the card again.

CF is just turning up in less and less devices, and is still bigger, clunkier and costs more than comparably-sized SD cards. Microdrives kick ass, yes, but you would need the XGP to correctly power down the cards when not in use-- it won't happen automatically.

 

[Exophase]

I'll take your word on that; I haven't found technical specifications that mention more than 1 CPU, however. I'd have to wonder if the second core was in some way crippled-- if homebrew programs used it and commercial games don't, as your statement implies. Though it could also boil down to that game engines just don't parallelize well.

Your first guess is correct - user mode programs do not have direct access to the second CPU. You need to be in kernel mode to do this. In commercial games the second CPU is used by the SDK (on firmware) for audio/video playback. It was probably deemed not worth the trouble to program games for parallel CPUs, given the massive failure of doing this on say, the Saturn.

As for power consumption, MIPS chips in the past have traditionally used more power than their ARM counterparts. I can't say if this is the exact case with the implementation in the PSP; MIPS claims it uses less. I have to doubt it, though, since they advertise in the same page processors with 400 Mhz clockrates with a claimed 0.5w power consumption. Now, if you compare that to an ARM1176JZ(F)-S at 400 MHz, using ARM's spec of "Speed Optimized" rather than "Area" (more power consumption, so these are more 'worst case' figures than anything), the figure would be 0.18w. That's a pretty dramatic difference. Another of MIPS' designs offers 2 1 GHz cores with 5w of power consumption. 2 ARM11s at the same clockrate (They do scale that high) would put you at 0.9w with the same "Speed Optimized" design.

PSP's Allegrex CPU is only single issue (chances are those CPUs you cited are not), I believe the same as the ARM CPUs you're referring to. The cache amounts are the around the same, and the die size for Allegrex is quite small (90nm, which is about as small as you'll get if you aren't Intel). I don't expect that a standard ARM implementation really has any room to improve anywhere near that much over Allegrex unless Sony and the other hardware vendors behind it messed up. It's true that ARM is very energy optimized, it has to be for all the mobile devices it is in, but Allegrex is too. It was afterall made for a device with a large emphasis on battery life Remember though, MIPS just specifies the ISA (and then, not exactly either.. in fact, Allegrex outright violates what is supposed to be required by the MIPS32r2 spec by only offering single precision FPU and having different encodings of some instructions). The bottom line is, PSP's CPU isn't off the shelf like what Gamepark would be using, so you can't compare it to whatever off the shelf equivilents you find.

Still, CPU power usage only accounts for a fraction of the overall power draw.

 

[DaveC]

I still don't really understand the big deal about having some wasted screen space. Like mentioned you could even put extra information there. Although it should be asked, would a 480x272 screen be proportionally larger than a 320x240 one? If not I can see it being a hindrance. But the thing about emulator accuracy... most emulator inaccuracies don't affect a majority of games at all. Stretching the screen would affect all of them pretty noticeably. Stretching a 256x224 display to 480x272 would be pretty awful, in fact.

It is not a matter of wasted screen space as much as it is a matter of getting a smaller image size if displayed at 1:1.

If you display Genesis at 1:1 it is actually smaller on a PSP than it is on a GP2X. It will be even smaller yet on the proposed 4" XGP screen. If you scale vertically to maintain aspect it will be about the same size (the GP2X screen is actually a hair taller than a PSP screen) . At that point you will have an image that is stretched and fuzzy and it won't be any bigger still than it is on the Gp2X, and will be still smaller on an XGP. So for emulation on the PSP/XGP you get a choice of smaller and 1:1 or blurry and stretched.

But again it depends on what you want out of it. if it is emus you are getting a worse image with a widescreen, if it is movies you get a bigger screen.

 

[Epicenter]

Your first guess is correct - user mode programs do not have direct access to the second CPU. You need to be in kernel mode to do this. In commercial games the second CPU is used by the SDK (on firmware) for audio/video playback. It was probably deemed not worth the trouble to program games for parallel CPUs, given the massive failure of doing this on say, the Saturn.

The problem with using both CPUs in the Saturn wasn't that they were parallel but rather that the Master CPU had to spoon-feed data to the Slave, and they could not use RAM at the same time. I imagine there is probably something limiting them from being used more effectively, though I'm not sure what it'd be. Probably contention for the memory bus or something similar...

The bottom line is, PSP's CPU isn't off the shelf like what Gamepark would be using, so you can't compare it to whatever off the shelf equivilents you find.

At any rate, I don't believe a MIPS core would be well suited at all for Gamepark's applications-- mostly for the reasons of power and portability of software. Whichever component or components are responsible for the PSP's abysmal battery life though, won't be present in the XGP's SoC, at least. Should they opt for S3C2460, which is much more power optimized than anything MagicEyes produces, it should be dramatically superior to the GP2X's power consumption as well (especially without those awful scalers and TV out chips that were not made for a mobile application at all. They were meant to be used in a device with a constant AC power source.) Peformance-wise, with a touch of overclocking it should be able to do everything the PSP can do. The advantage being, it'll be open-source, homebrew-friendly, and use cheap media formats. As well as the aforementioned power bits.

 

[zaiprzie]

I am only going to post my comments on what I would wish the XGP Mini would be, because the XGP will be a no-buy for me unless it costs less than $250, and it doesn't seem that that's going to happen.

Go for the S3C2460 from Samsung,266 MHz with an FPU, 64(or 96, doesnt matter for me as long as it doesnt exceed that). Enlarge the screen a bit, resolution of 320x240, D-Pad, AA batteries if the battery life would be MORE than 3-4 hours. About the 2d/3d accelerator thing, why wouldn't GamePark only add a 3d accelerator, and make 2d available using the 3d accelerator(a lib or set of functions)? I'd imagine that would decrease costs a bit, and would allow for some fancy effects.

My Kirshaan(what cents are in egypt)

 

[vampire8bit]

For the XGPmini I say Gamepark should make it their emulation handheld and go for the samsung S3C2460 chip with all its specifications, 266Mhz CPU, D pad, 96MB, a 3.5 inch screen (same size as the GP2X) of resolution 320x240, AAbatteries,open source and linux obviously and that's about it for those who mainly want emulation (of course it'll play mp3 and movies as well) and develop the XGP as widescreen and for commercial games, have an analog controller ,3D, gps, wifi, TV tuner etc.