2nd Cpu, Utilised Much In Emulators?

[Aaaaaaaa]

He deserves double-Guru status ... he can have mine ... (I still have no clue why Hando made me Guru :blink: )

You wouldn't be saying that if you read my code

Eg. part of the current is the following:

int *p = (int *)0xFFFFFFFF;
signal(SIGSEGV, segvfn);
sigsetjmp(segvenv, 1);
*p = 0;

Not exactly friendly, but the only thing I can think of at the moment to get the OS to do what I want

*whooosh* right over my head.

He still deserves god status

 

[Squidge]

I've doubled checked the code. If I put the battery check code back in right now, I lose 10fps. There's nothing wrong with the code you've written it must be something in the driver behind /dev/batt.

Hmmm, I've just taken my old PC Engine emu that was doing 60 fps @ 200mhz in Bomberman'94 and removed the battery checking code. It now runs at 72fps

It definitely didn't have that kind of a hit when I first implemented the battery checking code!

Also, I got the first alpha version of my linux hacker working on the same emu, and it increased the fps by 3 so far (it already used the hardware blitter).

So that's a grand total of 15 fps improvement. I really wonder what I could get this to when it becomes a little more advanced.

The bad thing so far - it isn't 100% stable, and also currently crashes unless you compile it with -O2 rather than -O3

*dreams of 100fps pc-engine at stock clock speed*

 

[Epicenter]

That's probably not your fault. -O3 screws up a lot of things. When I compiled a highly-optimized version of MAME for an old K6-2 box of mine, -O3 would make it crash all the time.

 

[OMG]

I've doubled checked the code. If I put the battery check code back in right now, I lose 10fps. There's nothing wrong with the code you've written it must be something in the driver behind /dev/batt.

Hmmm, I've just taken my old PC Engine emu that was doing 60 fps @ 200mhz in Bomberman'94 and removed the battery checking code. It now runs at 72fps

It definitely didn't have that kind of a hit when I first implemented the battery checking code!

Also, I got the first alpha version of my linux hacker working on the same emu, and it increased the fps by 3 so far (it already used the hardware blitter).

So that's a grand total of 15 fps improvement. I really wonder what I could get this to when it becomes a little more advanced.

The bad thing so far - it isn't 100% stable, and also currently crashes unless you compile it with -O2 rather than -O3

*dreams of 100fps pc-engine at stock clock speed*

Does your emu have sound? Also you and Vobbo united could get 100fps PCE at 200mhz Or maybe just vobbo

 

[Epicenter]

When your emulators combine, I am SquidgeHU6280PCE! ..... that doesn't have much of a ring to it.

 

[OMG]

or.... SquHU6280!

 

[DaveC]

*dreams of 100fps pc-engine at stock clock speed*

With *SOUND*

 

[PSyMastR]

*dreams of 100fps pc-engine at stock clock speed*

With *SOUND*

Doesn't vobbo have sound in his private release?

 

[Winterkid]

or.... SquHU6280!

Hmmm... Might need a bit of a rethink on the name there.
Maybe some brainstorming might be in order.

 

[DaveC]

*dreams of 100fps pc-engine at stock clock speed*

With *SOUND*

Doesn't vobbo have sound in his private release?

Dunno since it is *PRIVATE* :blink:

 

[zzhu8192]

People have tried to shift various tasks onto the 940, but in the end they have found out that it runs no faster (sometimes slower) than having everything on the 920.

However, this is simply because of the type of tasks being shifted onto the 940. Some tasks will benefit greatly, others will show no performance increase - we just need to find out the right type of task.

There are people working on getting sound going without using Linux (so the 940 can do audio playback, and not just audio processing), vblank irq's, hblank irq's, palette tricks via hblank irq's, etc... Since we can't use interrupts on the 920, the 940 could be very useful for these roles.

Myself, I'm working on a Linux Accelerator - don't want to say much more yet until it works properly, but hopefully it'll speed up apps running under it *without* changing the clock speed of the processor.

So this is where the "high tech" threads are

I'm doing some serious stuff with the 940t now; really hoping to see some results soon...
Just a few questions in case anyone has tried these

1) I was wondering if anyone has experience with the impact of battery life when using the 940 without pause, does the battery drain twice as fast?

2) Does the 940t CPU consist of 4k code / 4k data separate caches, or is it a unified 4k?
Do you guys know what the cache policy is? e.g. 4-way associative?
I might need to do some manipulation to get it to fit well in cache.
I'm trying the un-inline some funcs and abstract some other functions to get a smaller code footprint.
It's technically more instructions to call functions because of stack setups and stuff, but I wonder if
it can fit completely in 4k whether it'll run much faster.

3) If I were to use the technique described in the Dzz tutorial for the 940t, will there be a problem if I compile some C++ code and link it into an elf .bin file? i.e. will there be symbol issues or wierd compiler code generation for C++ compared to C that might mess with the code entry/call? I'm thinking it shouldn't matter...


Thanks.

BTW, Reesy and Squidge, you guys are awesome. Do you guys develop for
these types of devices professionally?

 

[DaveC]

I'm doing some serious stuff with the 940t now; really hoping to see some results soon...
Just a few questions in case anyone has tried these

Cool does this have anything to do with the NES emu? I hope so as it is so close to being near perfect now. The sound is a bit stuttery/crackly but that is it. If that was improved it would be awesome.

 

[Squidge]

When the 940 is enabled, and runs at the same speed as the 920, it uses about 30mA extra.

The 940 has seperate 4KB instruction, and 4KB data cache.

C++ code will make your code bloat, and trying to use it like DZZ does in his demo tutorials is brave - lots of things are done behind your back, so expect lots of undefined symbols or unexplained crashes and the like if you try.

I don't develope for these kind of devices as a day job, but I do develop for various embedded platforms that contain processors such as ARMs, yes - mainly for car audio entertainment stuff.

The main reason my emu is much faster than Vobbo's is simply because it's not as compatible. I'd love to see the speed of it with an asm core however, and I do have one sitting here that's about 75% complete... I just paused it when vobbo announced his, but I may continue it just to see how fast I can get it to go

 

[OMG]

When the 940 is enabled, and runs at the same speed as the 920, it uses about 30mA extra.

The 940 has seperate 4KB instruction, and 4KB data cache.

C++ code will make your code bloat, and trying to use it like DZZ does in his demo tutorials is brave - lots of things are done behind your back, so expect lots of undefined symbols or unexplained crashes and the like if you try.

I don't develope for these kind of devices as a day job, but I do develop for various embedded platforms that contain processors such as ARMs, yes - mainly for car audio entertainment stuff.

The main reason my emu is much faster than Vobbo's is simply because it's not as compatible. I'd love to see the speed of it with an asm core however, and I do have one sitting here that's about 75% complete... I just paused it when vobbo announced his, but I may continue it just to see how fast I can get it to go

Does yours use the full colour palette for the PCE or not? As Vobbo said that if he used the lss amount one. forget what its called, then he would get at least another 25fps. Battle of the PCE emulators

 

[Squidge]

Yes, it uses the full 16-bit color palette, and not the 8-bit one. Although for a speedup, I could use one of my recent hacks so it uses an 8-bit mode, but still has the 512 color PCE color palette rather than the 256 color palette your normally limited to in 8-bit mode.

 

[zzhu8192]

When the 940 is enabled, and runs at the same speed as the 920, it uses about 30mA extra.

The 940 has seperate 4KB instruction, and 4KB data cache.

C++ code will make your code bloat, and trying to use it like DZZ does in his demo tutorials is brave - lots of things are done behind your back, so expect lots of undefined symbols or unexplained crashes and the like if you try.

I don't develope for these kind of devices as a day job, but I do develop for various embedded platforms that contain processors such as ARMs, yes - mainly for car audio entertainment stuff.

The main reason my emu is much faster than Vobbo's is simply because it's not as compatible. I'd love to see the speed of it with an asm core however, and I do have one sitting here that's about 75% complete... I just paused it when vobbo announced his, but I may continue it just to see how fast I can get it to go

Appreciate the reply, as always. So 30 mA doesn't sound too bad. On the wiki it claims that the gp2x draws close to 400 mAh with both cpu's running, so I'm guessing about 370mA without the 940?

Pretty cool that you work on embedded platforms.

I guess I'm not "really" using C++ in this case, mostly just the syntax enhancements. I don't really prefer it honestly. If I'm gonna take a hit for C++, I might as well go Java, and take an even bigger hit. I got some demos running written in Java for the GP2X though. They seem to run okay. Unfortunately the smallest size program compiles to about 5 megs.

 

[Epicenter]

I got some demos running written in Java for the GP2X though. They seem to run okay. Unfortunately the smallest size program compiles to about 5 megs.

Ah, Java. The mark of speed, efficiency and compactness. Let's hear it for Java! :lol:

 

[OMG]

I got some demos running written in Java for the GP2X though. They seem to run okay. Unfortunately the smallest size program compiles to about 5 megs.

Ah, Java. The mark of speed, efficiency and compactness. Let's hear it for Java! :lol:

I didn't realise that was sarcasm for a minute!

 

[zzhu8192]

So here's the thing. I've been working on a port of Visualboy Advance for the gp2x.
If you've ever looked at the code, you'll see that it's organized/refactored quite well,
although at the great expense of speed.

I actually put the 940 to use on this port, and it definitely makes a difference.
I was able to get close to a 2x speed up. Of course I did some serious profiling on the code before hand to see which part was sensible to parallelize.

So right now I got a version that runs about 1/2 speed of what the normal speed should be, at 1 frame skip (i.e. 30 fps) even with sound.

It seems, however, and my 940 pointers are a little messed up from the 940 side. What's strange is that the pointer values are obviously pretty close to what they are supposed to be, since the screen is drawing from the 940 side, but it's drawing with an offset. My other variables also seem to be a bit off, as some synchronization variables seem to be not changing state when viewed from the 920 side, even though I'm pretty sure the loops are executed to completion on the 940 side.

I wonder if I have to mess with the Dzz asm code in the setup portion.

The last thing is that the 940 seems still too slow... That's why I was trying really hard to reduce the code size to fit in 4k. It's currently about 32k.

 

[Reesy]

Is that 30fps emulating GBA or GBC ?