I Got Gpsp (gba) Running With Sound!

[TelcoLou]

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 ... <_<

 

[kamakazieturtle]

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.

 

[daclassicgamingmaster]

kamakazieturtle: I adblocked your signature because my eyes are very offended.

 

[TelcoLou]

kamakazieturtle: I adblocked your signature because my eyes are very offended.

 

[Shikaku]

kamakazieturtle: I adblocked your signature because my eyes are very offended.

 

[DaveC]

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

 

[TelcoLou]

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

 

[Exophase]

They look reallllly nice on a DS screen too

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!

 

[fargo]

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

 

[DaveC]

They look reallllly nice on a DS screen too

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.

 

[Exophase]

They look reallllly nice on a DS screen too

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..

 

[slaanesh]

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?

 

[Exophase]

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)

 

[Goemon4]

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!

 

[cowai]

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!

 

[krosfyah]

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.

 

[Exophase]

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.

 

[sam fisher]

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

 

[hackgrid]

I think zodttd likes threads with 50+ pages, so there will be a new release in 11 pages

 

[Shikaku]

I think everyone likes threads with 50+ pages, so there will be a new release in 11 pages