Squidge's Mmu Hack: Discovery Of The Month :)

[grahf]

Thanks squidge. I donated you a few bucks, sorry it wasnt more.
And also thanks to the rest of you guys who make the 2x such a great system.

I know a lot of people hesitate to donate money. We all have priorities, and need the cash for some reason or another. But if your broke, just send a few dollars if its all you have. Every little bit helps.

 

[Crazy Goat]

I need to wait a few more weeks until anything magically appears in my paypal... I thank you for your work on the 2X, this was quite a good discovery...

 

[FFNoir]

Break out the booze everyone! This MMU hack has made Chrono Trigger playable. Kudos to Squidge for his hack and everyone who implemented it into the respecitve emulators.

 

[gaterooze]

Break out the booze everyone! This MMU hack has made Chrono Trigger playable.

At 275mhz it's 50+FPS in-game WITH SOUND. Drops to 20-25FPS in battle, not that you really notice

Squidge, do you think transparencies will now be plausible?

Really stunning work!

 

[FFNoir]

I dunno, I had Chrono in that range at 266 MHZ. and the drop in battles doesn't really bother me.

 

[moz]

it just occured to me that this this really is big news as not just emulators will benefit from this right?

 

[Dzz]

it just occured to me that this this really is big news as not just emulators will benefit from this right?

Any application that uses the frame buffers or other "high" memory as "working space" could benefit from this idea. Not all applications do that, but a fair number of apps using the hardware accelerated SDL probably do.

The extra complication is that if you write to the high memory that write will not immediately be available to the MMSP2 (frame buffer, blitter, etc) until the data gets flushed out of the cache. I am not sure how the users of this technique are currently dealing with the issue but it needs to be taken into account for correct operation. The likely symptoms would be missing, flashing, or incomplete graphics showing up on the screen. In some apps the normal memory access patterns are such that the cache will naturally get flushed quickly enough so that it isn't an issue.

 

[Franxis]

it just occured to me that this this really is big news as not just emulators will benefit from this right?

Any application that uses the frame buffers or other "high" memory as "working space" could benefit from this idea. Not all applications do that, but a fair number of apps using the hardware accelerated SDL probably do.

The extra complication is that if you write to the high memory that write will not immediately be available to the MMSP2 (frame buffer, blitter, etc) until the data gets flushed out of the cache. I am not sure how the users of this technique are currently dealing with the issue but it needs to be taken into account for correct operation. The likely symptoms would be missing, flashing, or incomplete graphics showing up on the screen. In some apps the normal memory access patterns are such that the cache will naturally get flushed quickly enough so that it isn't an issue.

I have such symptoms in the MAME game selection menu (game names, option names, etc). The text does not appear completely, it takes 1-2 seconds to appear completelly. I don't know how to 'flush' the cache manually. Anybody knows?

Regards.

 

[ingrin]

it just occured to me that this this really is big news as not just emulators will benefit from this right?

Any application that uses the frame buffers or other "high" memory as "working space" could benefit from this idea. Not all applications do that, but a fair number of apps using the hardware accelerated SDL probably do.

The extra complication is that if you write to the high memory that write will not immediately be available to the MMSP2 (frame buffer, blitter, etc) until the data gets flushed out of the cache. I am not sure how the users of this technique are currently dealing with the issue but it needs to be taken into account for correct operation. The likely symptoms would be missing, flashing, or incomplete graphics showing up on the screen. In some apps the normal memory access patterns are such that the cache will naturally get flushed quickly enough so that it isn't an issue.

Reading through the DRMD thread, I don't think they are (Reports of flashing and character animation issues).
Still, this is really a huge discovery, and once all the bugs are worked out I will joyfully add to my SD card. No big rush for me, I am completely happy with the performace of my old versions, anything else is icing on the cake

 

[nubie]

Any application that uses the frame buffers or other "high" memory as "working space" could benefit from this idea. Not all applications do that, but a fair number of apps using the hardware accelerated SDL probably do.

The extra complication is that if you write to the high memory that write will not immediately be available to the MMSP2 (frame buffer, blitter, etc) until the data gets flushed out of the cache. I am not sure how the users of this technique are currently dealing with the issue but it needs to be taken into account for correct operation. The likely symptoms would be missing, flashing, or incomplete graphics showing up on the screen. In some apps the normal memory access patterns are such that the cache will naturally get flushed quickly enough so that it isn't an issue.

Hmm, that is why DrMD beta5 is doing the bars and the flickering sprites, I suppose once Reesy gets the video code fully converted over to the GP2X we should be good. Amazing it is so good without being optimized huh?

Oh, yeah, will Vektar and Payback be benefitting from this?

 

[Squidge]

h34r:

Now I know this makes some really nice improvements, I'll be updating it with more functionality, which will include things like cache flush & drain functionality and other stuff.

 

[DaveC]

it just occured to me that this this really is big news as not just emulators will benefit from this right?

Any application that uses the frame buffers or other "high" memory as "working space" could benefit from this idea. Not all applications do that, but a fair number of apps using the hardware accelerated SDL probably do.

The extra complication is that if you write to the high memory that write will not immediately be available to the MMSP2 (frame buffer, blitter, etc) until the data gets flushed out of the cache. I am not sure how the users of this technique are currently dealing with the issue but it needs to be taken into account for correct operation. The likely symptoms would be missing, flashing, or incomplete graphics showing up on the screen. In some apps the normal memory access patterns are such that the cache will naturally get flushed quickly enough so that it isn't an issue.

I don't notice any of these problems in GnGeo. The only thing I notice is the blazing speed. His app must be one of the ones with the naturally flushing cache or something.

 

[NaCCuRiT]

well done.
And I must and did donated...

 

[Radek]

h34r:

Now I know this makes some really nice improvements, I'll be updating it with more functionality, which will include things like cache flush & drain functionality and other stuff.

Could it be used for memory filling?

And what about cache locking?
(being able to force constant caching of a memory area)

 

[pepone]

it just occured to me that this this really is big news as not just emulators will benefit from this right?

The extra complication is that if you write to the high memory that write will not immediately be available to the MMSP2 (frame buffer, blitter, etc) until the data gets flushed out of the cache. I am not sure how the users of this technique are currently dealing with the issue but it needs to be taken into account for correct operation. The likely symptoms would be missing, flashing, or incomplete graphics showing up on the screen. In some apps the normal memory access patterns are such that the cache will naturally get flushed quickly enough so that it isn't an issue.

I don't notice any of these problems in GnGeo. The only thing I notice is the blazing speed. His app must be one of the ones with the naturally flushing cache or something.

Maybe because of the HW accelerated SDL? DrMd use the minimal lib, no?
I guess Paeryn has make a good work to prevent this problem.

 

[Gadget]

I reckon this is THE single biggest breakthrough we will see in the life of the GP2X

 

[Radek]

I reckon this is THE single biggest breakthrough we will see in the life of the GP2X

Perhaps not.

Why you are so negative?

There is always a place for an improvement, remember.

 

[Wite_Noiz]

Donated!
Can't wait to see what else can be squeezed out of the little guy (the '2X... not squidge... sickos)

 

[PSyMastR]

Donated!
Can't wait to see what else can be squeezed out of the little guy (the '2X... not squidge... sickos)

Nobody was thinking that, so your the sicko.

 

[classicgmr]

Put this in the NES eumlator?

XD

Ooh ooh! Say it will be so!