I Got Gpsp (gba) Running With Sound!


kamakazieturtle posted on Dec 8 2006 at 06:51 PM said:
cowai posted on Dec 8 2006 at 06:31 PM said:
What happened to all the posts?
Dude I know. Its like everyone just left. I don't know, I really hope that release comes out tonight though. Zodttd and Exophase rock so hard for this.

Stop bugging the devs. Seriously ... <_<
 
Last edited by a moderator:
TelcoLou posted on Dec 8 2006 at 06:54 PM said:
kamakazieturtle posted on Dec 8 2006 at 06:51 PM said:
cowai posted on Dec 8 2006 at 06:31 PM said:
What happened to all the posts?
Dude I know. Its like everyone just left. I don't know, I really hope that release comes out tonight though. Zodttd and Exophase rock so hard for this.

Stop bugging the devs. Seriously ... <_<
Not bugging, just really excited. I know how long it takes, I'm just really happy we finally have a gba emulator. :)
 
Last edited by a moderator:
daclassicgamingmaster posted on Dec 8 2006 at 07:07 PM said:
kamakazieturtle: I adblocked your signature because my eyes are very offended.
 
Last edited by a moderator:
inu64 posted on Dec 8 2006 at 04:15 PM said:
nothing today????

I guess not. It is not good to badger devs for fast releases. It is ready when it is ready. I don't think they like being rushed like thay are working at a job for a boss.

Relax. If you really need GBA so quick there are alot of cheap GBA-SPs floating around with flashcarts. I heard they run GBA games full speed with full sound and 100 % compatibility ;)
 
Last edited by a moderator:
DaveC posted on Dec 8 2006 at 07:22 PM said:
inu64 posted on Dec 8 2006 at 04:15 PM said:
nothing today????

I guess not. It is not good to badger devs for fast releases. It is ready when it is ready. I don't think they like being rushed like thay are working at a job for a boss.

Relax. If you really need GBA so quick there are alot of cheap GBA-SPs floating around with flashcarts. I heard they run GBA games full speed with full sound and 100 % compatibility ;)

They look reallllly nice on a DS screen too :D
 
Last edited by a moderator:
TelcoLou posted on Dec 9 2006 at 12:25 AM said:
They look reallllly nice on a DS screen too :D

I think they look better on a PSP screen, blurryness notwithstanding ;P

I know some people will yell at me for bringing this up, but just as a mild draft (I'm not even able to work on gpSP GP2X yet :( ), I do think using the ARM940T to convert to 32bit 4:2:2 YUV would be doable if the rest of the emulator was fast enough. This is the format the accelerator takes, and indeed it is filtered using a hardware digital filter, which probably looks pretty nice. It would happen after the emulator is done rendering the display but before the following virtual vblank. This wouldn't be too bad of a time to do it because at this time the game is for the most part not accessing a huge amount of data so there would be decent spatial/temporal locality for the main CPU's L1 data cache. The 940T CPU would be running a very small piece of code that would fit into its miniscule L1 instruction cache, and while this code would be somewhat memory bandwidth intensive it would be more computationally bound. There shouldn't be an insane amount of contention for the memory bus between the two CPUs, so there probably would be some significant speed gained from factoring this between them.

I'm kinda surprised other emulators aren't doing this (to the best of my knowledge). And lack of documentation isn't an excuse, the Magic Eyes chipset is very thoroughly documented!
 
Last edited by a moderator:
Exophase posted on Dec 9 2006 at 04:32 AM said:
I know some people will yell at me for bringing this up, but just as a mild draft (I'm not even able to work on gpSP GP2X yet :( ), I do think using the ARM940T to convert to 32bit 4:2:2 YUV would be doable if the rest of the emulator was fast enough. This is the format the accelerator takes, and indeed it is filtered using a hardware digital filter, which probably looks pretty nice. It would happen after the emulator is done rendering the display but before the following virtual vblank. This wouldn't be too bad of a time to do it because at this time the game is for the most part not accessing a huge amount of data so there would be decent spatial/temporal locality for the main CPU's L1 data cache. The 940T CPU would be running a very small piece of code that would fit into its miniscule L1 instruction cache, and while this code would be somewhat memory bandwidth intensive it would be more computationally bound. There shouldn't be an insane amount of contention for the memory bus between the two CPUs, so there probably would be some significant speed gained from factoring this between them.

I'm kinda surprised other emulators aren't doing this (to the best of my knowledge). And lack of documentation isn't an excuse, the Magic Eyes chipset is very thoroughly documented!
That is just fantastic. Making use of the second CPU while minimizing possible contention between the two CPUs over the memory bus is really smart. I hope other emulators benefit from this. Take your time guys :D
 
Last edited by a moderator:
Exophase posted on Dec 9 2006 at 01:32 AM said:
TelcoLou posted on Dec 9 2006 at 12:25 AM said:
They look reallllly nice on a DS screen too :D

I think they look better on a PSP screen, blurryness notwithstanding ;P

I know some people will yell at me for bringing this up, but just as a mild draft (I'm not even able to work on gpSP GP2X yet :( ), I do think using the ARM940T to convert to 32bit 4:2:2 YUV would be doable if the rest of the emulator was fast enough. This is the format the accelerator takes, and indeed it is filtered using a hardware digital filter, which probably looks pretty nice. It would happen after the emulator is done rendering the display but before the following virtual vblank. This wouldn't be too bad of a time to do it because at this time the game is for the most part not accessing a huge amount of data so there would be decent spatial/temporal locality for the main CPU's L1 data cache. The 940T CPU would be running a very small piece of code that would fit into its miniscule L1 instruction cache, and while this code would be somewhat memory bandwidth intensive it would be more computationally bound. There shouldn't be an insane amount of contention for the memory bus between the two CPUs, so there probably would be some significant speed gained from factoring this between them.

I'm kinda surprised other emulators aren't doing this (to the best of my knowledge). And lack of documentation isn't an excuse, the Magic Eyes chipset is very thoroughly documented!

A better idea, could the 940T be used to get more speed out of the emulation? Wouldn't that be a better use of it than just using it to blurr out the image? In Picodrive the 940T is used for sound emulation and it does speed things up alot. Many games now run at 60 FPS FS0 with sound.

I know some like their blurred out stretched images but I would think speed and sound quality would be a priority over stretching.
 
Last edited by a moderator:
DaveC posted on Dec 9 2006 at 04:26 AM said:
Exophase posted on Dec 9 2006 at 01:32 AM said:
TelcoLou posted on Dec 9 2006 at 12:25 AM said:
They look reallllly nice on a DS screen too :D

I think they look better on a PSP screen, blurryness notwithstanding ;P

I know some people will yell at me for bringing this up, but just as a mild draft (I'm not even able to work on gpSP GP2X yet :( ), I do think using the ARM940T to convert to 32bit 4:2:2 YUV would be doable if the rest of the emulator was fast enough. This is the format the accelerator takes, and indeed it is filtered using a hardware digital filter, which probably looks pretty nice. It would happen after the emulator is done rendering the display but before the following virtual vblank. This wouldn't be too bad of a time to do it because at this time the game is for the most part not accessing a huge amount of data so there would be decent spatial/temporal locality for the main CPU's L1 data cache. The 940T CPU would be running a very small piece of code that would fit into its miniscule L1 instruction cache, and while this code would be somewhat memory bandwidth intensive it would be more computationally bound. There shouldn't be an insane amount of contention for the memory bus between the two CPUs, so there probably would be some significant speed gained from factoring this between them.

I'm kinda surprised other emulators aren't doing this (to the best of my knowledge). And lack of documentation isn't an excuse, the Magic Eyes chipset is very thoroughly documented!

A better idea, could the 940T be used to get more speed out of the emulation? Wouldn't that be a better use of it than just using it to blurr out the image? In Picodrive the 940T is used for sound emulation and it does speed things up alot. Many games now run at 60 FPS FS0 with sound.

I know some like their blurred out stretched images but I would think speed and sound quality would be a priority over stretching.

I didn't say that it wasn't, but the emulator is far from in its proper state, until there's a dynarec implement speed can't be assessed at all. And GBA isn't very parallelizeable, the sound doesn't really take much CPU time to emulate.

The PSP version of gpSP only uses 1 of the PSP's 2 CPUs and does okay, so..
 
Last edited by a moderator:
Exophase posted on Dec 9 2006 at 06:57 PM said:
The PSP version of gpSP only uses 1 of the PSP's 2 CPUs and does okay, so..
Oh oh... What you talking about? Now i feel stupid; the PSP has two CPUs? I've never investigated this at all... Is it a similar setup to the GP2X?
 
Last edited by a moderator:
slaanesh posted on Dec 9 2006 at 12:37 PM said:
Exophase posted on Dec 9 2006 at 06:57 PM said:
The PSP version of gpSP only uses 1 of the PSP's 2 CPUs and does okay, so..
Oh oh... What you talking about? Now i feel stupid; the PSP has two CPUs? I've never investigated this at all... Is it a similar setup to the GP2X?

It does have two CPUs, and unlike GP2X the second one has the same amount of cache (no VFPU though.. and neither have an MMU). But you have to be in kernel mode to use it, which is not possible for firmware 2.80 (the highest that they've found an exploit for running homebrew on.. so far)
 
Last edited by a moderator:
ths emu is amazing! i just tried it with metroid fusion clocked at 266 and it played damn close to full spead (w/o sound) cant wait to see the next release of this, great work zodttd!
 
Is Zodttd dead? He said he was going to do a release on friday?
I'm sorry for this n00bness. But I starting to get a little crazy. It's not my fault, it's Exophase and Zodttd for this incredible emulator! :)
 
Don't do that. It's the most annoying thing in the world for devs. Go for a walk or read a book or whatever if you find yourself getting obsessive.
 
subcon959 posted on Dec 10 2006 at 05:11 PM said:
Don't do that. It's the most annoying thing in the world for devs. Go for a walk or read a book or whatever if you find yourself getting obsessive.

That's one of the reasons I don't set release dates. Ever. ;)

I haven't seen zodttd in a while, unfortunately :(

If it were up to me you'd all be getting one release a month, tops ;p

But they'd be big ones.
 
Last edited by a moderator:
Exophase posted on Dec 10 2006 at 05:21 PM said:
subcon959 posted on Dec 10 2006 at 05:11 PM said:
Don't do that. It's the most annoying thing in the world for devs. Go for a walk or read a book or whatever if you find yourself getting obsessive.

That's one of the reasons I don't set release dates. Ever. ;)

I haven't seen zodttd in a while, unfortunately :(

If it were up to me you'd all be getting one release a month, tops ;p

But they'd be big ones.
I prefer it that way. Except if you are the amazing vobbo. He brought gifts of 10FPS increases a day :)
 
Last edited by a moderator:
Back
Top