GBA emulator for the DS by Darkchen *UPDATE*

[Nollog]

If darkchen can get an api("sdk"), then surely someone else could add the ability to load .nds's too, maybe darkchen could even look into it himself, though it's far beyond the scope of a VBA port.

btw, rapidshare link is on his/her blog now, woot.

 

[Exophase]

I would be extremely surprised if this were really VBA. VBA doesn't even run this well on an OMAP3530 clocked at 850MHz, which is way more powerful than a TMS320DM6441. So either that isn't really the chipset used, he ported another emulator *cough*gpSP*cough*, or he optimized VBA several times more than anyone else has managed to do, in quite a short timeframe. I know he said he was looking into VBA before, but that was then.

 

[Nollog]

I would be extremely surprised if this were really VBA. VBA doesn't even run this well on an OMAP3530 clocked at 850MHz, which is way more powerful than a TMS320DM6441. So either that isn't really the chipset used, he ported another emulator *cough*gpSP*cough*, or he optimized VBA several times more than anyone else has managed to do, in quite a short timeframe. I know he said he was looking into VBA before, but that was then.

You could be right, s/he used the word "migration", not port.
It could be down to his/her English skills which I thought at first, or s/he could have just used[stolen] some code from VBA.

I Hope I'm wrong there though.

 

[Exophase]

I would be extremely surprised if this were really VBA. VBA doesn't even run this well on an OMAP3530 clocked at 850MHz, which is way more powerful than a TMS320DM6441. So either that isn't really the chipset used, he ported another emulator *cough*gpSP*cough*, or he optimized VBA several times more than anyone else has managed to do, in quite a short timeframe. I know he said he was looking into VBA before, but that was then.

You could be right, s/he used the word "migration", not port.
It could be down to his/her English skills which I thought at first, or s/he could have just used[stolen] some code from VBA.

I Hope I'm wrong there though.

I also doubt it's a new GBA emulator entirely, done this quickly by someone who didn't come into it knowing a lot about GBA and hasn't had a lot of time to develop a very thorough understanding of the architecture being worked on. It's not impossible though. Probably more likely than it being a tweaked VBA.

The whole thing is pretty mysterious.

UPDATE: I got someone to do some tests and it crashes in some pretty gpSP specific ways. Also, I hear that iPlayer is 330MHz MIPS, not 200MHz ARM - which is a good fit for gpSP and explains how it can run 3D stuff so well (gpSP ARM isn't good at stuff like that). So it's probably gpSP, which is also GPL, but I'm not going to waste my time trying to go after him. It's the same story as the guys selling the Dingoo A320. So long as they're not charging for the software itself then I can't really be bothered. You can all feel free to forward some of your appreciation to me though ;D

 

[Jacobeian]

this is interesting EXophase, and I think you are right, VBA has still trouble running fullspeed on the 700Mhz Wii PPC and the ARM maximal rated speed according to the SoC datasheet is 256 Mhz (link, screenshot).

Are there any other ARM-optimized GBA emu beside gPSp anyway ? it's very unlikely an emulator has been written from scratch in so few time

I also wonder if it's also using the extra DSP hardware in some way and even the DSi ARMs, which would be quite an accomplishment, and the reason why GPL should be mentionned and the sourcecode released !

Last things, even if it's not being sold, this is clearly going to boost iPlayer sales and I'd be very surprised if the SDK "leak" was not done on purpose... seems very suspicious to have a real SDK floating around, it's not like many people were going to developp stuff on that thing beside iPlayer devs themselves

 

[stanleyopar2000]

no...um for the GBA Emulator in the future... could slot 2 hardware be used for this also with future updates?

Done a full circle here; if you've got access to slot 2 and you own an expansion pack then you don't need an emulator, you can run GBA natively straight from slot 2.

um...the compatibility on it (SuperCard SD) sucks.

 

[Exophase]

this is interesting EXophase, and I think you are right, VBA has still trouble running fullspeed on the 700Mhz Wii PPC and the ARM maximal rated speed according to the SoC datasheet is 256 Mhz (link, screenshot).

Where did you hear that it's using that SoC exactly? I heard MIPS 330MHz, which makes a lot more sense for gpSP because gpSP ARM doesn't run 3D well but the PSP (MIPS) version does.

There are other reasons why it's very unlikely that this DaVinci chip is being used. The most obvious one is price. Even at quantity of 1000 it costs at least $33 per unit from the cheapest resellers. There is no way this can be going into a device that also has external SDRAM of some sort, gamecard interface, and PCB + packaging, and still cost only just over $40. This is not even considering the FPGA that it's said to have (and if it were using a DaVinci it wouldn't need one, since the DSP would be sufficient for the video decoding it's doing). They'd make a substantial loss rather than a profit. On the other hand, 330MHz MIPS fits the Ingenic jz4732 and variants, which is a very cheap and popular chip currently being used in a lot of cheap devices coming out of China.

Are there any other ARM-optimized GBA emu beside gPSp anyway ? it's very unlikely an emulator has been written from scratch in so few time

Yes, there's one that's competitive with gpSP's performance: it's called vBagX and it's available for Symbian. However, this is not open source but is instead a commercial product. In order for it to be used in this case there would have to be a three way financial deal between Vampent (makers of vBagX), iPlayer, and darkchen himself. Otherwise it'd make no sense, because there'd be no monetary incentive for Vampent to give it to them. This would go quite against what darkchen has said so far.

If it's MIPS then gpSP is the only thing that makes sense. Also consider that gpSP was ported to a Chinese PMP using the aforementioned Ingenic chipset and runs OK, so if that's what's being used here then there's a lot of precedence.

I also wonder if it's also using the extra DSP hardware in some way and even the DSi ARMs, which would be quite an accomplishment, and the reason why GPL should be mentionned and the sourcecode released !

Assuming it actually is using the DaVinci, but even then I doubt it. There's not a lot in current GBA emulators that can be easily factorized such that running it in another processor gains a huge performance advantage. Running the whole thing on such a DSP would be really bad despite it being twice the clock speed. That's because gpSP doesn't have a recompiler for it, and running interpreters on a DSP like that isn't good because it's not good at handling all the indirect branches that requires. There's just no way it'd perform as well as it does.

QUOTE(Jacobeian @ Sep 20 2009, 04:42 AM)

Last things, even if it's not being sold, this is clearly going to boost iPlayer sales and I'd be very surprised if the SDK "leak" was not done on purpose... seems very suspicious to have a real SDK floating around, it's not like many people were going to developp stuff on that thing beside iPlayer devs themselves

Yep, this is probably the best thing that can happen for iPlayer sales, I bet GBA emulation is going to be more popular than movie playback. But here you have a guy who was willing to do that for free, so why go ahead and strike a deal with him? Then if he gets in trouble somehow iPlayer has no connection or liability either. Sounds like a perfect situation for them. It is possible that there's a real SDK through other channels that at least works in some capacity because it's probably for a different application using the same system-on-chip that's in iPlayer. It could have been released by the SoC makers themselves.

Anyway, it's almost definitely gpSP because it crashes in ways only gpSP is known to, and it's probably MIPS. I think I've worked out the most likely scenarios.

 

[Jacobeian]

Where did you hear that it's using that SoC exactly? I heard MIPS 330MHz, which makes a lot more sense for gpSP because gpSP ARM doesn't run 3D well but the PSP (MIPS) version does.

from here: http://www.metagames-eu.com/content/view/2313/33/
it's written in french but as far as I understand it, the SoC has been identified as a TMS320DM6541
even if the chip name can not fully be read on the 1st picture, it clearly starts with TMS320DM, which are SoC from Texas Instrument
on the 2nd pic, you can also see an ASIC, Flash ROM and SDRAM

But here you have a guy who was willing to do that for free, so why go ahead and strike a deal with him?
because without the needded tools, he wouldn't have gone very far, and this makes free support for their product
he said he first asked them for a SDK but they refused: the fact that they even took the time to answer him make me think their answer was a little more complex, something like "ok, we give you some tools but you don't tell it comes from us"
QUOTE

It is possible that there's a real SDK through other channels that at least works in some capacity because it's probably for a different application using the same system-on-chip that's in iPlayer. It could have been released by the SoC makers themselves.

I doubt it: I mean, doesn't the iPlayer need to interface with the DSi video/audio hardware in some ways ? it's much likely the SDK (ot the dev tools) contains specific libraries or code to work with DSi hardware,

 

[amiga]

I thought the same, that it seems impossible that they are using the DaVinci chip but in this french website Metagames, they have pictures of the iplayer that seems to demonstrate it has the TMS320DM6541 chip.

What it's incredible because it too cheap too be true knowing the price of other gadgets that use this chip but of course I'm not gonna complain.

The possibilities of this card are really impressive I have to say, just thinking on a dslinux using the power of the iplayer would be fantastic.

 

[Exophase]

There's no such thing as TMS320DM6541. If you look at the number closely you'll see it could be TMS320DM35X (355 and 357 exist). That chip costs half as much, only has an ARM9 + fixed function MPEG decode engine, and can go up to 270MHz. So we've probably found the real chip. Maybe someone else will want to open theirs too?

Looks like gpSP ARM afterall.. the 3D games they tried might be the kind that render to IWRAM then DMA to VRAM, or maybe they did some extra code to improve the performance on it. Or it's vBagX, but I strongly doubt that because vBagX has poor sound and this doesn't. There's no way Vampent would fix it up for this then not update their official version.

because without the needded tools, he wouldn't have gone very far, and this makes free support for their product
he said he first asked them for a SDK but they refused: the fact that they even took the time to answer him make me think their answer was a little more complex, something like "ok, we give you some tools but you don't tell it comes from us"

I don't think them responding to him is very suspicious. Companies do often respond to these things. Not that I'm saying you're wrong or anything, there's just no outright evidence.

QUOTE(Jacobeian @ Sep 20 2009, 04:56 PM) I doubt it: I mean, doesn't the iPlayer need to interface with the DSi video/audio hardware in some ways ? it's much likely the SDK (ot the dev tools) contains specific libraries or code to work with DSi hardware,

As far as I understand iPlayer works on all DS's and nothing about it accesses DSi specific hardware. So in that regard it's just another flashcart. It obviously has code for loading and running homebrew in its own firmware - so long as it can run unencrypted binaries then it's entirely possible that using TI's compiler straight will be all you need to do to develop things for it.

 

[DominoBright]

So Chen is using your stuff? Well, that is a rotten move, but it's nice to see someone putting it to use for the DS.

 

[Jacobeian]

There's no such thing as TMS320DM6541. If you look at the number closely you'll see it could be TMS320DM35X (355 and 357 exist). That chip costs half as much, only has an ARM9 + fixed function MPEG decode engine, and can go up to 270MHz. So we've probably found the real chip. Maybe someone else will want to open theirs too?

yes, you're probably right, this one suits better with known facts


QUOTEAs far as I understand iPlayer works on all DS's and nothing about it accesses DSi specific hardware. So in that regard it's just another flashcart. It obviously has code for loading and running homebrew in its own firmware - so long as it can run unencrypted binaries then it's entirely possible that using TI's compiler straight will be all you need to do to develop things for it.

I mean DS or DSi video & audio hardware... isn't it how it works ?
I would have thought that the decoded video pixels (output from the SoC) need to be converted in DS format ? And the decoded sound must be send to DS audio hardware somehow...
I initially thought it was the role of the software that is running on DS/DSi, it reads video/audio data directly in known format from the cartridge slot (probably the cart SDRAM is mapped to it for direct access) and display/render it on the console, while the role of the software running on iPlayer ARM was to decode video (using the co-processor) or, in this case, to render GBA frames through an emulator. Maybe the ASIC's role is to convert decoded pixels into the proper format and store them on SDRAM... or isn't it such things on NDS, I'm not really aware of the tech details ?

 

[fudge143]

Man that is so cool. i wish you can do that with the EDGE. I want other cards but dont know wer people sell those

 

[Exophase]

I mean DS or DSi video & audio hardware... isn't it how it works ?
I would have thought that the decoded video pixels (output from the SoC) need to be converted in DS format ? And the decoded sound must be send to DS audio hardware somehow...
I initially thought it was the role of the software that is running on DS/DSi, it reads video/audio data directly in known format from the cartridge slot (probably the cart SDRAM is mapped to it for direct access) and display/render it on the console, while the role of the software running on iPlayer ARM was to decode video (using the co-processor) or, in this case, to render GBA frames through an emulator. Maybe the ASIC's role is to convert decoded pixels into the proper format and store them on SDRAM... or isn't it such things on NDS, I'm not really aware of the tech details ?

Yes, there has to be a program running on the DS itself that pulls data off the gamecard for audio and video. Whether or not iPlayer homebrew includes loading the DS part or not is unknown, but if so it's probably in a known format like NDS. It could be that the loader itself has a default protocol for taking audio/video off the bus and streaming it to DS, in addition to putting button presses and possibly touch stuff.. but my guess is that it's the former. It's true that either way there are things that have to be figured out, but it can probably be done with some extensive work.

But there will definitely need to be someone's code running on the NDS, because otherwise it's impossible to get data off the gamecard bus and into RAM/VRAM (also to upload input data to the card).

 

[Exophase]

Some clearer pictures here:

http://two.xthost.info/iplayerpics/

It's definitely labeled "TMS320 DM6541", whatever that is. I'm starting to think this isn't even a TI chip at all but a deliberate naming knock-off. Who knows.

 

[RedBaron]

Hi Darkchen
Any chance of an updated GBA Emulator for the iPlayer with better compatibly
Vars

 

[snikerz]

Looks like this project was abandoned, the blog is dead now: http://darkchen.blog.com