Xgp-kids: Most Potential Ever!

[zaiprzie]

If GP would just make the res of the GP-KiDS to be 320x240(or even atleast as big as the gba or nds), they sure will be seeing a bit more sales for this handheld(atleast for me, I would buy one for my little bro and sis). How much would making the screen a bit larger cost anyway?

 

[Orkie]

I can't imagine it would cost too much extra. Surely their current displays are fairly expensive because they are a non-standard size?

 

[JaqMs]

Well at he is right that GBA emulation at or near full speed is doable on the XGP Kids .. but it doesn't have anything to do with assembly. It has to do with the 2 systems sharing a processor architecture ..

I just said that GBA emulation is impossible on the GPKids, so you shouldn't even be questioning that.

Yes, he should, because you're wrong. You don't even own a GP2X, so you aren't in the best position to make assertions about what is or isn't possible. The CPU horsepower required should be there, and with a bit of overclocking it's even more feasible. The GP2X does not have any decent 2D acceleration, so the biggest limitation I can see for 'acceptable' GBA performance is the small RAM capacity-- meaning you could probably kiss playing GBA games that are over 4MB goodbye. Unless SD-DMA works and is very fast you'd see a LOT of slowdown trying to read a game ROM from SD in realtime. (I'm sure if you owned a GP2X, you'd be familiar with the slideshow effect that comes from trying to read massive amounts of GFX data from the SD card in Gngeo2x. You don't see it much, but when you first start a game you can, and it's pretty noticable.)

Why are you talking about GBA emulation on the GP2X. Do you see the word GP2X in my post?

 

[OMars]

Why do you feel you have the requisite knowledge to say what's potentially possible on any given handheld? Uh-oh, the GBA emulator is being coded in assembler!! It must run full-speed upon completion, then. Next stop, N64 emulation! As long as it's written really, really well, it's bound to emulate fullspeed.

Don't randomly bring up points that aren't part of the conversation, it makes you look foolish. I have the utmost confidence and hope in anyone working on the GBA emulation scene for GP2X, but you act like you're participating in it yourself and know what you're talking about.

The gba is not very similar to the n64. Assembler would have to bring the speed up, as it is used in DrMD and look at the effects of that. I am not saying anything written in asm will run full speed, but don't doubt the developer who is programming the project. Ok, now go watch the remake of Charlie and the Chocolate Factory.

Well, he is right that GBA emulation at or near full speed is doable on the XGP Kids .. but it doesn't have anything to do with assembly. It has to do with the 2 systems sharing a processor architecture ..

Yes, but wouldn't asm make a big difference? From what I gather you are saying if two machines are similar then you really don't need to program in asm... :unsure:

 

[Hwrd]

[/quote]
Yes, but wouldn't asm make a big difference? From what I gather you are saying if two machines are similar then you really don't need to program in asm... :unsure:
[/quote]

Sorry to butt in but, what happens when the processors are similar is that many of the CPU instructions can be directly run (and do not require additional steps on the emulating processor FOR THAT INSTRUCTION(s)). This can make emulation faster than when emulating a vastly different processor.

In the case of the GBA vs GPx, you have to also emulate the graphics chip capabilities (sprites, backgrounds, etc). And that does not come so cheaply (from a number of instructuions required perspective.

Hope this helps and hope I'm not too far off...


PS: ASM would help in either case, but ASM is not a magic bullet.

 

[Epicenter]

Why are you talking about GBA emulation on the GP2X. Do you see the word GP2X in my post?

For all intents and purposes, the XGP Kids is like a lower-spec'ed GP2X. The CPU architecture is the same, the main difference there is 4K caches instead of 16K. There is less RAM. And there may not be a 2D blitter, but the GP2X's does very little for emulation anyway. The CPU clock is 140 MHz instead of 200. Odds are, they overclock to 200 Mhz anyway. So, the feasibility of GBA emulation on both machines will be similar.

The gba is not very similar to the n64. Assembler would have to bring the speed up, as it is used in DrMD and look at the effects of that. I am not saying anything written in asm will run full speed, but don't doubt the developer who is programming the project. Ok, now go watch the remake of Charlie and the Chocolate Factory.

...

Yes, but wouldn't asm make a big difference? From what I gather you are saying if two machines are similar then you really don't need to program in asm... :unsure:

ASM isn't like a tool you implement, it's a full language. You are writing instructions specifically for the processor manually, so that you can optimize the work it does at the lowest possible level. Most code is written in C/C++ and other higher-level languages, where a compiler translates the code to ASM, and often doesn't do the best job of it, resulting in less efficient code than if you wrote highly optimized ASM for your application on your own.

Now, you can write a fast ASM CPU Core to emulate another architecture. Like you'd need to write a MIPS CPU emulation core for the ARM9 platform to emulate the N64. If you are emulating the same platform (ARM7) you can just translate the instructions and run them natively on the ARM9, since it already understands that code. This carries about 10 times less overhead and requires 10% or less of the amount of work the CPU would normally have to do.

For an emulator that already natively runs CPU code and doesn't emulate an ARM7, the best thing to do is to write the 2D graphics emulation code in ASM to keep it snappy, and do your drawing, if possible, using 2D acceleration. This is possible on the XGP/Mini but not on the GP2X, and probably not on the XGP Kids.

As for the issue of N64 emulation. There just isn't enough CPU horsepower to emulate the N64 on a machine without a 3D accelerator, period. You'd be lucky to get close to 10 FPS. On the XGP/Mini you should still not expect to get close to full speed, because emulation of a 96 MHz MIPS processor is an enormous task. It might be playable, but forget about full speed.

 

[Exophase]

Epicenter, you talk a lot about using virtualization techniques to emulate GBA on platforms with ARM. You talk about it as if it's a determined fact that it can be done. Actually, you seem to speak this way about a lot of things that are only concepts on paper.

Let me ask you, if it's such a straightforward concept why hasn't anyone done it in any appreciable way for a console that requires low level emulation? I've only seen it done for high level emulations (ie, VirtualPC, CXBX) where programs for the platforms are strictly user-mode only. The way you talk about it, you'd think we'd have fullspeed GBA emulators for GP2X by now. In fact, you'd think we'd have them for GP32. Yes, there was an attempt at virtualization for GBA on GP32, and while I hear a lot of people talk about it I've never seen any worthwhile indication that it actually got anywhere useful.

You're really oversimplifying things. You can have a 100% compatible CPU and still have complete direct virtualization will probably still be impossible because you have to share privelaged mode with the emulator and the game you're emulating. Every GBA game on the face of the planet has a custom interrupt handler, this is not in BIOS code (only the prologue/epilogue is) and can't be HLE'd. This handler may (probably will) use mode switch instructions that expect the GBA's supervisor/IRQ modes to be what it set them to at the start of the game. Now, assuming you can even get access to these in a way you want (throwing out Linux) you'd still be competing with the same stack space as the GBA game.

It might be possible to find a hack around this, for instance if the platform supports FIQ you might be able to do all of your emulator code in it (an FIQ handler) because GBA doesn't have FIQ (and most games won't touch those registers). Last I heard most handheld devices do not support FIQ, I assume this isn't common to support it because it's not even in MS's WinCE emulator. Even if it does, you'll still have to write your own device drivers, which is a less than pleasant task (depending on say, the support in the BIOS on the device).

Now, I'm not saying it's impossible. But you're pretty much saying it's a sure thing. When it comes to emulators it's best not to talk about things the way you do. Besides the fact that it's pretty conceited, you're probably getting a lot of people's hopes up for something that may never happen (and if it doesn't I'm sure you'll just say that no one tried). When I set out to do my GBA emulator I figured that it could be done, specwise, on paper, but I wasn't sure. I didn't say a single thing publically until it was ready to be released. The fact is, there were all kinds of unexpected results along the way. I'm sure this happens to a lot of emulator authors. You speak a lot about hardware and emulation but have you done any specifically hardware demanding emulators? I'd really like to know.

 

[tritt_conner]

- Deleted. -

 

[Epicenter]

Epicenter, you talk a lot about using virtualization techniques to emulate GBA on platforms with ARM. You talk about it as if it's a determined fact that it can be done. Actually, you seem to speak this way about a lot of things that are only concepts on paper.

Let me ask you, if it's such a straightforward concept why hasn't anyone done it in any appreciable way for a console that requires low level emulation?

Had you been paying attention, you'd know there was already a GBA emulator using this technique in development. Take a look at the GP2X Development subforum, and so far, it's working. It's been done before; look at N64 emulation on the PSP. Use of MIPS code on a different-but-compatible MIPS processor. Same idea.

And there are some 'ideas on paper' that are sure things. For example, it is a 'sure thing' that there will be enormous speed increases, probably close to full speed operation, once a real 3D accelerator is used instead of software 3D, which is never an elegant solution.

Sometimes it's necessary to be a lot more than the pessimism you presently show. There'd be no enthusiasm for the XGP series at all if people were convinced it was a GP2X with a 266 MHz overclock out of box, which is what a lot of people make it sound like. It's more necessary to laud its potential, as was done when the GP2X came out. And most of the predictions of what it could do were correct. I am not making absurd claims like that Dreamcast or PS2 emulation or other such craziness is likely.

 

[rei_yano]

getting tired of all this negativity here. Im sure they have another goddamn argument in store too. Im telling you they are all conspiring against us.... <_<

 

[Exophase]

Had you been paying attention, you'd know there was already a GBA emulator using this technique in development. Take a look at the GP2X Development subforum, and so far, it's working.

I pay plenty of attention. First of all, that technique is static recompilation, NOT virtualization, and it even falls back on interpretation when necessary. Go read the thread, I had a lot to say about it.

Second of all, until that emulator actually shows signs of doing SOMETHING what difference does it make what is it indevelopment? There was a "virtualizing" emulator in development for GP32 too. Did that ever run GBA games fullspeed? That's a rhetorical question, you don't have to actually answer that.

It's been done before; look at N64 emulation on the PSP. Use of MIPS code on a different-but-compatible MIPS processor. Same idea.

And you're wrong again. Daedalus using a dynamic recompiler, which is much different than virtualization. It's the exact same technique as my GBA emulator for PSP. And the CPU in PSP is NOT compatible with the CPU in N64. N64 has 64bit integer registers, double precision floats, and is big endian instead of little, amongst other things. And Daedalus is FAR slower than fullspeed right now, even though PSP's CPU is nearly 4x the clockspeed of N64's.

Now, XGP Kids has an even greater than 4x advantage in clock speed over GBA, and can probably get CPU emulation down in full speed. BUT there are other concerns, like the cache amount and overall RAM speed, because GBA can access its IWRAM and WRAM with 0 clock cycle delays (that's 128kb total).

And there are some 'ideas on paper' that are sure things. For example, it is a 'sure thing' that there will be enormous speed increases, probably close to full speed operation, once a real 3D accelerator is used instead of software 3D, which is never an elegant solution.

The things you're saying are definitely not sure things. And like usual you vastly overestimate 3D acceleration for 2D console emulators, where you CAN'T map the more expensive features (like alpha blending in GBA, for instance) to their hardware equivilents, no matter how much it might superficially look like the same thing to you they aren't. Not to mention that you can't naively handle a line based renderer with 3D acceleration.

Again, my GBA emulator at this point, 100% software rendered, can often outperform an SNES emulator that uses both of PSP's CPU cores AND hardware acceleration for the blitting.

Sometimes it's necessary to be a lot more than the pessimism you presently show. There'd be no enthusiasm for the XGP series at all if people were convinced it was a GP2X with a 266 MHz overclock out of box, which is what a lot of people make it sound like. It's more necessary to laud its potential, as was done when the GP2X came out. And most of the predictions of what it could do were correct.

What predictions? What amazing feats were predicted for GP2X that have come true? If full speed GBA or PS1 emulation were on that list then they haven't come true (I don't care how much either are being worked on, until they're done they're not done).. If the predictions were "it'll be able to emulate SNES fullspeed" then uh, congratulations ;P

I am not making absurd claims like that Dreamcast or PS2 emulation or other such craziness is likely.

Well, no. Your claims are certainly far more realistic than that. And this can possibly be done, but you shouldn't state things like GBA emulation on XGP Kids with certainty. Of course we both don't know if anyone will even want to work on an inherently crippled emulator in the first place, so it's probably moot.

I mainly made my post to demonstrate that virtualization doesn't work as an emulation technique most of the time, for console emulators. You must use recompilation. And I haven't heard of a purely static recompiler ever working, save for ones hand tuned for specific games. For GBA I'm pretty sure it will never work for a majority of games because of several reasons I outlined in the development thread for it. Dynamic recompilation is usually the best you will get (but dynamic compilation can be very deeply compiling).

 

[Epicenter]

Very well, you've got some good points. However, you seem to have a terribly cataclysmic view of everything, don't you? .. Such a machine has much more potential than you give it credit for. 3D emulation of any sort will have a huge boost in performance present, a point I doubt you could possibly hope to dispute-- and regardless of how godly and amazing your 2D renderer you mention in every one of your posts may be, there are accelerations that can be managed using 2D/3D GPUs. After talking to emulator authors, I've been assured of that. Sure, not everything can be.

A lot of the slowdown on the GP2X isn't emulation of graphics subsystems or due to the inefficency of the renderer. It's trying to blit all that data to the display. I throw about as much data at the display in a game I'm developing to match a high-end emulator, and it tasks the hell out of the system. Whether I'm hitting a limitation of the blitter, the memory bandwidth, or whatever else I cannot be sure, but the GP2X's 2D 'acceleration' is sorely lacking. When the blitter has to work too hard, the ARM920T is probably being tasked, too. And in an emulator, there's not much CPU time left, if any at all with multiple CPU cores and other subsystems being emulated all at once on it-- not much to fall back on.

At any rate, I recommend we wind this discussion down a bit, because our little debate has spanned 3 threads now and it seems we're mostly repeating ourselves now..

 

[Exophase]

Okay, I'll be sure to make this my last one.. it'll be a little more positive ^_^

Very well, you've got some good points. However, you seem to have a terribly cataclysmic view of everything, don't you? .. Such a machine has much more potential than you give it credit for. 3D emulation of any sort will have a huge boost in performance present, a point I doubt you could possibly hope to dispute--

Absolutely, and 3D renderers will almost always improve the quality of the graphics as well. 3D rendering is great for 3D emulation, although it can suffer some compatability problems, depending on the platform.

I also want to add that 3D acceleration is usually great for NEW 2D games. I'm a big supporter of using 3D for 2D games, and I think dedicated 2D hardware is long obsolete.

and regardless of how godly and amazing your 2D renderer you mention in every one of your posts may be, there are accelerations that can be managed using 2D/3D GPUs.

I don't want to come off as bragging, just want to make it clear that in this case it is just about sufficient (well, I mention it every time you mention 3D acceleration for 2D emulators, to be fair ;P)

After talking to emulator authors, I've been assured of that. Sure, not everything can be.

The problem is that sometimes you either have to get all or nothing or hardware, it might not be possible to do a hybrid solution.

A lot of the slowdown on the GP2X isn't emulation of graphics subsystems or due to the inefficency of the renderer. It's trying to blit all that data to the display. I throw about as much data at the display in a game I'm developing to match a high-end emulator, and it tasks the hell out of the system.

Yes. I should possibly mention that gpSP in particular renders directly to VRAM and then uses the graphics hardware to scale the image to the screen, as a texture. So I am using the 3D hardware, and it's great (bilinear filtering for free is a huge win for a lot of emulators).. just not using it for the rendering stages.. Want to iterate once more that 3D hardware is a huge win, and if XGP has bilinear filterted textures (all things indicate it will) then that alone is a big help, even if it makes things "fuzzy" (a lot of people happen to even prefer that, over something blocky.. I for one don't mind it much of the time)

Whether I'm hitting a limitation of the blitter, the memory bandwidth, or whatever else I cannot be sure, but the GP2X's 2D 'acceleration' is sorely lacking. When the blitter has to work too hard, the ARM920T is probably being tasked, too. And in an emulator, there's not much CPU time left, if any at all with multiple CPU cores and other subsystems being emulated all at once on it-- not much to fall back on.

Perhaps. You can't really avoid that to some extent with a software renderer, that is, where you have to render every pixel.. but for most platforms that isn't a huge amount, and even going from 320x240 to 256x224/240 for NES/SNES or as low as 240x160 ends up being a small amount of pixels. It's nothing like software rendering 2D on PC at resolutions like 1024x768+, which even today is still quite taxing. But it is undesireable.

At any rate, I recommend we wind this discussion down a bit, because our little debate has spanned 3 threads now and it seems we're mostly repeating ourselves now..

*nod* I think we've made our points and I'm pretty sure we at least see a little where the other is coming from.

 

[awakenjsy]

I was surfing the net and found this article posted at the following address

http://aving.net/usa/news/default.asp?mode...mp;btb_num=6656

Just wanted to share the information.

 

[Epicenter]

Ah, this must be the show they mentioned to me... the unit looks pretty solid so far.

 

[KoH]

Do you know if the sd card will stick out like that all the time, or is that just a picture showing you where it gos.

 

[Alex.]

Ah, this must be the show they mentioned to me... the unit looks pretty solid so far.

I know, they've got everything right, from the branding "GP KiDS" to the glossy finish. It's only too bad they didn't simply redesign the old GP32 with upgraded specs and slightly smaller casing. A pocket-sized GP32 running on SD cards would have gained quite the popularity here, despite the GP2X.

- Alex

 

[Epicenter]

The design is very illogical, but GP has said before, it was too late to make any real changes. If they do sell it to another company to produce then I'm sure that company will be able to secure software for it, or get it developed. You could really build some pretty impressive games for such a device, if you can write very highly optimized code and use the memory creatively. It's not that powerful of a machine, but if you can tolerate scaling, perhaps there's a bit of emulation that could be accomplished on it as well. And we can at least be assured it'll make a damn fine audio player. Maybe I'll write a couple simple apps for it to play around with it, but I intend to focus my efforts on their higher-end hardware.

The finish I especially like. It looks like translucent plastic with a white coat of paint underneath-- the style used by Apple's older iBooks and the DS Lite. I've always been very fond of it, and it make scratches extremely subtle and hard to notice-- the paint is on the inside so it can't scrape/fall off.

As for the SD slot, I am sure the cards go all the way into the unit. That's clearly a demonstrative picture to show what variety of card it will accept.

 

[KoH]

Do you know if they have a price yet, I will be looking for a new mp3 player in the spring, I wanted something that can do more then play mp3's, such as emulators. The size of the kids modellooks pretty easy to carry around as an mp3 player, unlike the Gp32, GP2X & PSP.

Also in the link above it says that its going to be released in the first half of 2007, does anyone know anymore than this, 8 months is a long time

 

[Epicenter]

GP doesn't seem sure of a release date yet. But they said $75 for the target price.