2nd Cpu, Utilised Much In Emulators?

[nubie]

The main problem for speed on the snes is still the graphic emulation. If you do everything apart from rendering the graphics, the fps goes through the roof, showing that the rest of the system isn't really a bottleneck at all.

I am just guessing from what Reesy says.

Does this mean that if he fixes the rendering problem inherited from the GP32 (screen on a 90 degree crap-out) that we will see full-speed and the transparency/video emulation can be implemented with fixes using the speed gained?

Do you think that if the screen space on the GP32 had been correctly oriented we would have seen a speed-up in the GP32 Emulation coupled with faster-running ported GP2X emulators?

Edit: Similar line of thought, with Reesy's skill in video hardware output programming wouldn't it be best if he worked with the firmware guys or was helped to make a library/driver/layer to speed up ALL video output on the GP2X?

Then the knowledge he has of drawing to the screen will be available for Homebrew, for Emu's, For Ports, and everyone.

Unless of course Hardcore Homebrew is going to release the restrictions on him.

 

[Reesy]

Does this mean that if he fixes the rendering problem inherited from the GP32 (screen on a 90 degree crap-out) that we will see full-speed and the transparency/video emulation can be implemented with fixes using the speed gained?

Nope, it means rendering can be sped up in 8bit mode, but transparency requires 16bit, with each pixel being written on its own. So basically it doesn't matter which way the frame buffer is organised, it just makes porting harder. In the GP2X 8bit mode without transparency you can write code to write 4 pixels with one instruction, this speeds things up.

Do you think that if the screen space on the GP32 had been correctly oriented we would have seen a speed-up in the GP32 Emulation coupled with faster-running ported GP2X emulators?

It would have been a breeze...but no use crying over spilt milk.

Edit: Similar line of thought, with Reesy's skill in video hardware output programming wouldn't it be best if he worked with the firmware guys or was helped to make a library/driver/layer to speed up ALL video output on the GP2X?

Well it doesn't require any skill, just patience. I imagine the people who write the librarys have far more experience than me, the only experience I have is from writing a few emulators for the GP32/GP2X. All I know is that to get as much speed as possible you have to reduce the amount of instructions used in the code and also reduce the amount of memory reads/writes.

 

[nubie]

Slightly off-topic:

@Reesy, Unai, and Zodttd:

Why does Reesy Identify that Linux is causing a slow-down in his emulator, the very speedy DrMDx, and Unai and Zodttd don't see any problems on video output with their admittedly slow emulator?

I would also like to know what kind of bandwidth is consumed by full-motion, full TV video uncompressed.

As the GP2X is a video-processing device by design of the MMSP2, how does all that bandwidth get onto the TV-Screen scaled in real-time and yet we have trouble with emulator video drawing? Is it going through a hardware processor/2d video accelerator we aren't using yet?

I know Reesy seemed excited about being able to draw 4 or more pixels in one operation (not possible on GP32 due to screen rotation), how could the 2d accelerator help us out?

 

[Reesy]

Slightly off-topic:

@Reesy, Unai, and Zodttd:

Why does Reesy Identify that Linux is causing a slow-down in his emulator, the very speedy DrMDx, and Unai and Zodttd don't see any problems on video output with their admittedly slow emulator?

Simply because I have basically the same code on the GP2X as I do on the GP32. The only major difference between them is on the GP2X Linux is running in the background. At 60Mhz I lose 20fps on the Gp2X version of DrSMS when compared to the GP32 version.

As the GP2X is a video-processing device by design of the MMSP2, how does all that bandwidth get onto the TV-Screen scaled in real-time and yet we have trouble with emulator video drawing? Is it going through a hardware processor/2d video accelerator we aren't using yet?

At the moment any use of the 2D hardware seems to be unreliable, it will work 1 minute and break another. Its probably because we are not setting up the device correctly. When this becomes more stable it could be used to speed things up. I'm still playing with some ideas which regards this but until I can get the device working stable I do not want to invest any more time in it.

I know Reesy seemed excited about being able to draw 4 or more pixels in one operation (not possible on GP32 due to screen rotation), how could the 2d accelerator help us out?

ITS 4 PIXELS AT A TIME!!!! How can one not be excited by that....I ask you. Yes the 2d chip can help....when its stable.

 

[moz]

carrying 4 bottles of beer at a time is better and faster than 1

 

[Jarska333]

carrying 4 bottles of beer at a time is better and faster than 1

But if you slip and fall... h34r:

Never keep all your bottles of beer in the same basket.

 

[Gadget]

carrying 4 bottles of beer at a time is better and faster than 1

But if you slip and fall... h34r:

Never keep all your bottles of beer in the same basket.

Or pull the bottles of beer around on a trolley! Even better still is to carry just one keg =D

 

[moz]

But if you slip and fall... h34r:

Never keep all your bottles of beer in the same basket.

slip and fall? im sorry youve confused me for someone else


now slurp and fall is a different matter

 

[nubie]

ITS 4 PIXELS AT A TIME!!!! How can one not be excited by that....I ask you. Yes the 2d chip can help....when its stable.

I can't get excited because I can't afford a GP2X, on the other hand I could get excited, go farther into debt, and buy another GP2X.

I didn't mean to sound belittling to Reesy, but more to ask what Unai and Zod are doing wrong. AKA if they did it the right way (the Reesy Way) maybe it would work better? What are they doing, in other words, who is Unai, I am off to read all his posts and see if he ever communicated the general idea behind his hardware access.

carrying 4 bottles of beer at a time is better and faster than 1

Have you seen the commercial with the "german" inventors who made the six-pack:

I discovered a way to carry 6 beers at the same time. Brilliant!! But we don't have to drink them all at the same time. Brilliant!!

 

[mraellis]

another gp2x lol ?

 

[Reesy]

I've not looked at reesy's latest code, but I would think that the current speedup is due to the forced nature of fastsprites and possibly other optimisations, rather than the removal of the battery checking code.

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.

Ouch! I'm sure I would have noticed such a huge frame rate loss, but then again, lots of things have been changed since that code has been implemented (including several new firmware updates), so I suppose any one of those could cause the slow down.

Just goes to show I suppose - never assume anything! Just because something works well in one firmware release, don't assume it'll work well in the next, specially when GPH is involved

Reesy, have you removed the hardware blitter code completely from this version? Just as a lot more people are saying it works without 'tricks' such as klonekeen(sp?)

Yes its all disabled at the moment, its a shame because you get a couple of extra FPS by using to clear the frame buffer but it just causes too many issues at the moment. It also causes issues in DrMD, so its the Minimal SDK which is the problem rather than how the emulator is using it.

 

[Squidge]

I've not looked at reesy's latest code, but I would think that the current speedup is due to the forced nature of fastsprites and possibly other optimisations, rather than the removal of the battery checking code.

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.

Ouch! I'm sure I would have noticed such a huge frame rate loss, but then again, lots of things have been changed since that code has been implemented (including several new firmware updates), so I suppose any one of those could cause the slow down.

Just goes to show I suppose - never assume anything! Just because something works well in one firmware release, don't assume it'll work well in the next, specially when GPH is involved

Reesy, have you removed the hardware blitter code completely from this version? Just as a lot more people are saying it works without 'tricks' such as klonekeen(sp?)

 

[Squidge]

I didn't think Rlyeh's SDK had any blitter code in it - I just hack the hardware regs directly.

I'm working on some code at the moment which doesn't kill Linux, but just moves it to the side a bit So you still got Linux for all the file i/o etc (ie. emu menus), but it falls asleep when you want full control (emu running).

It'll be interesting to see what the differences in speed and compatibility are WRT the 2d hardware.

 

[Shikaku]

Can we make a God status just for Squidge?

XD

 

[TelcoLou]

Can we make a God status just for Squidge?

XD

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

 

[OMG]

Can we make a God status just for Squidge?

XD

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

'For outstanding Citizenship and Persiveriance in the eyes of the law'

 

[Reesy]

I didn't think Rlyeh's SDK had any blitter code in it - I just hack the hardware regs directly.

Sorry, yes your right. I moved your code into my version of Minimal so I could implement it in DrMD.

I'm working on some code at the moment which doesn't kill Linux, but just moves it to the side a bit So you still got Linux for all the file i/o etc (ie. emu menus), but it falls asleep when you want full control (emu running).

Wow, that sounds like the perfect solution. Let us know when you have something going.

It'll be interesting to see what the differences in speed and compatibility are WRT the 2d hardware.

Well everybody should keep their fingers and toes crossed. It usually goes horribly wrong when they mess with the hardware.....BLU+ anyone?

 

[Squidge]

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

 

[Reesy]

Cool, save the linux context and then crash out of it Die Linux Die!
Nice idea, I like it.

 

[OMG]

To me that means. WOOOB WOOOB WOOOB WOOOB. *Falls back onto a cushion made out of Fenix*