GP32 Corruption On New Blus


According to Reesy on IRC, these settings seem to do the trick (Dr. MD runs with the new settings on BLU+) :)

So... could someone create a few (about 2-3) REALLY simple programs and compile them each one time with the OLD settings and another time with the NEW settings (don't change anything else, please!) and send them to me?

I'm trying to look for Hex differences in the files and find out if you can Hex-Edit them... IF it's possible, I'll write an auto-patcher :)
 
\/\/000T !

That fixed the gray bar problem like a treat!! I tested them on my GIF viewer compiled with Mr.Mirkos SDK. It also still works perfectly in geepee32, which I take to mean that it will also work on the older BLU (as well as the BLU+)

Now the only problem is that the top scanline appears at the bottom.

This looks like it is caused by offsetting the pixel data that is displaying to the screen by 1 pixel, which causes the klast pixel at the end of each scanline to wrap to the bottom of the next one:

e.g: Pretend the LCD is only 4 by 4 pixels rather than 320x240. The pixel data in the image SHOULD display like this:

37BF
26AE
159D
048C

But is actually displaying like this:

26AE
159D
048C
?37B

Please note: The rotated image pixel data is '0123456789ABCDEF'

Great work so far. The gray bar problem is by far the worst. This 'wrapped scanline' is hardly noticeable, but annoying to have all the same.

Any ideas?
 
Bad news:

I just compared the two files... they are nearly TOTALLY different.
So I guess simple Hex-Editing is NOT possible to get old programs working...

Looks like we definately need the help of the guru-devs here...
 
HA! Thanks!
Great! Looking better...

There are a lot of changes, but these are repeating values that always change into the SAME ones!

This is only true for the beginning of the files - but maybe this is where the LCD get initialized.

At the later parts, the files are TOTALLY different... but maybe we don't need to change anything there...

EDIT: Some more looking...
The first difference is always the fourth byte from the start of the program.
It's always DIFFERENT, but if, for example, the fourth byte is 0C in the normal and F0 in the patched file, all following 0C change to F0, too (until the string FXP2 comes... after that, everything's totally different).

First, I have to find a way, how the patched value is getting calculated... and then what other bytes change and why... definately gonna be a hard nut to crack.

Does anyone know what the FXP2 is?
Is this the beginning of the program and everything before that the header?
 
I think I know -

The programs have been compressed into fxe. So hex editing them is not going to work, and that is why so much of the file is different, because it is compressed data, and who knows what that 'looks like'. Need to uncompress them from fxe back to gbx (or whatever they are called) and THEN do the hex editing, and then compress them again.

I will uncompress them and repost them...

EDIT: I can recompile them and supply the bin file (uncompressed) but this won't help us because with existing apps we don't have the luxury of recompiling. We need to find a tool that extracts an fxe back to its uncompressed state. Anyone??
 
pea posted on Dec 15 2004 at 03:17 AM said:
I think I know -

The programs have been compressed into fxe. So hex editing them is not going to work, and that is why so much of the file is different, because it is compressed data, and who knows what that 'looks like'. Need to uncompress them from fxe back to gbx (or whatever they are called) and THEN do the hex editing, and then compress them again.
Click to expand...

Aaaah! That's why! I was wondering myself ;)

I will uncompress them and repost them...
EDIT: I can recompile them and supply the bin file (uncompressed) but this won't help us because with existing apps we don't have the luxury of recompiling. We need to find a tool that extracts an fxe back to its uncompressed state. Anyone??
​
Click to expand...

Well, we can think about that AFTER we found out if it's possible.
A lot of old programs aren't compressed.

BTW: Most of the important GP-software is still in development or had the source code released. So we could recompile them :)
 
Last edited:
Once I get my BLU+ I try to make a "all around" fix that would allow running legacy software in new BLU+ without a need of patching old programs. Well see.. :blink:
 
mr.spiv posted on Dec 15 2004 at 02:50 PM said:
Once I get my BLU+ I try to make a "all around" fix that would allow running legacy software in new BLU+ without a need of patching old programs. Well see.. :blink:
​
Click to expand...

Cool.
You're definately better than me <g>

I smashed my old Samsung LCD and are getting a BLU+, so I'm happy if you can do this :D

I'll still try to find this workaround until that :)
 
Last edited:
mr.spiv posted on Dec 15 2004 at 12:50 PM said:
Once I get my BLU+ I try to make a "all around" fix that would allow running legacy software in new BLU+ without a need of patching old programs. Well see.. :blink:
​
Click to expand...

Wow! How? I guess you either need to have the loader dynamically patch the programs after unpacking or have some kind of watchdog on an interrupt checking the LCD regs? Are there any handy unused but active interrupts? Or have you got another strategy?

Thanks,

Mark
 
Last edited by a moderator:
maybe this can help (censored):

How to decrypting GP32 games...

Note:
I cannot guarantee that this method will work for every game.
Should work for games that only rely on .gxe/.gxc SecuMax encryption should work.
GamePark knows this method and undoubtly will introduce new copy-protection schemes.

Follow these steps:
- ***** ***** into *** file (in case of downloaded app) and/or ***** into *** file (in case of game)
- load the *** in the GeePee32 emulator
- pause emulation
- place a breakpoint at $0C000000 so execution pauses when starting the game
- select the game in the bios game selection menu
- make sure the breakpoint activates
- dump the memory starting from $0C000000 with length $00800000 (complete 8MB ram)
- close the emulator
- run the ***** tool to convert the memory dump to an unencrypted executable (GXB)
- find a GXB launcher that sets the game path correctly or find an encrypter
- report yourself to GamePark
Click to expand...

If any DEV would need the program, please PM me (with email adress. But ONLY PM me, if you are a well known DEV (like Reesy, foft, Squidge etc.). I won´t hand it out to anyone else. If you are not a DEV: DON'T PM ME
 
Whoops, yeah, don't eMail it to anyone else... this is part of how to make warez of GP32 games...

Luckily, it's not that easy as Geepee doesn't load your bought games that easy...

Anyways:

pea, have you uploaded the uncompressed files yet?
 
EvilDragon posted on Dec 15 2004 at 09:28 PM said:
Whoops, yeah, don't eMail it to anyone else... this is part of how to make warez of GP32 games...

Luckily, it's not that easy as Geepee doesn't load your bought games that easy...

Anyways:

pea, have you uploaded the uncompressed files yet?
​
Click to expand...

I totaly understand your worries.
That´s why i wrote this "disclaimer" ;) :

Horscht posted on Dec 15 2004 at 09:18 PM said:
If any DEV would need the program, please PM me (with email adress. But ONLY PM me, if you are a well known DEV (like Reesy, foft, Squidge etc.). I won´t hand it out to anyone else. If you are not a DEV: DON'T PM ME
​
Click to expand...

Also, the above mentioned program allows you you uncompress compressed fxes.
 
Last edited by a moderator:
Horscht posted on Dec 15 2004 at 09:34 PM said:
Also, the above mentioned program allows you you uncompress compressed fxes.
​
Click to expand...

Wait a second - you mean loading and saving the memory with geepee, right?
Or do you mean there is a program which automatically uncompresses a FXE?

If the FXE is exactly the same as it was before compressing, this would be REALLY useful for the Hex-Editing stuff.
 
Last edited:
Hi ED,

Sorry about the delay. Work has been very busy (I AM work, so I can take a break whenever :) )

I have uploaded the uncompressed files. They are 'bin' files, but I am pretty sure that they are the same as gxe (or whatever they are called), but maybe missing the correct header or something? Does someone want to clarify that?

Anyway, file is called 'example.patch.2.zip'
http://www.pea.co.nz/gp32/downloads/

Good luck
 
Hmm...

I found SOME similarities, but tons of differences I don't know anything about.
The two files have even different sizes (the patched one is 40-80 bytes smaller), so it's not as easy as I thought.

I tried patching the 256color demo manually using all the similarities I found - but with the only success that the file restarts the GP32 :/

The files are still pretty big - is it possible to compile a lot smaller programs (i.e. just a Hello World!)?
This may be the only way I find out more about the differences...

Just create the normal FXEs. Thanks.
 
Right, I'm certainly not a brilliant coder by long shot, but it crossed my mind to wonder, given that the old LCD settings are (unless I'm much mistaken) included in the SDK by default, and the new ones have to be added in, surely that means the one with the settings has a fair few lines more code than the other one?

Which in turn could potentially result in a compiler outputting radically different results more.

So perhaps the reason the files are so different is because the one that doesn't have any settings in at all (i.e. uses assumed ones) needs to have a set, but a set of old ones, formatted in precisely the same way as the new (so as to make the source as close to identical as possible), prior to compiling?

Anyone know the old settings?
 
You must log in or register to reply here.

Similar threads

porg
Report on Rebirth OpenPandora LCD response time: Tearing, Ghosting & Co
Replies
4
Views
4K
porg
porg
Back
Top