GP32 Corruption On New Blus


foft

foft

Certified Guru
Joined
Mar 14, 2004
Messages
480
Location
London, UK
Website
www.scrameta.net
What details are known on these from a programming perspective. Does it fail with:
i) Anything at high clock speed?
ii) Anything that inits display without SDK?
iii) Changing clock and not setting LCDCON1 properly? i.e. high framerates.

My port of Atari800 uses the SDK for init etc. Please can someone check if it works?

Thanks,

Mark

----------------------
Update: After looking through the pinned one in the general talk forum I found a bit more out...

I found a post from donjj saying that the display settings should be changed to:
Vertical back porch :0x08
Vertical front Porch :0x02
Vertical sync pulse width :0x5
Horizontal back porch :0x32
Horizontal front porch :0x2
Horizontal sync pulse width :0x1e
Click to expand...

Apparently anything written using the official SDK should be fine. Now someone just needs to automate the LCD type detection somehow for hardware banging apps then all is well I guess?

So I guess the answer to my question above is (ii). Is that correct!
 
From what I've heard, it seems to be a combination of 1 and 2.
Projects built on Mirko's SDK seem all to have the one-line-bug (where the last line is the first or something), my 50MHz liquid seawolf works without the bar, the 133MHz cave copter has the bar - but diab0l's diabolic pong running on 14 or 20MHz has it too.
Might have to do something with the different versions of Mirko's SDK though.
 
I just did a brainstorming to find a solution... I don't know the GP32 very deeply, so if anything isn't possible, just tell me.

We all know a lot of old programs won't be updated anymore, so just changing the SDK and recompiling isn't really a solution.

So what we need is a solution so ALL the old stuff runs perfect on new BLUs.

I think we first need to find out, if programs written for the new LCD work on the old ones (though I'm pretty sure they will, as all the old commercial GP32 stuff from GP runs on the new ones).

Problem is: Most devs don't have a new BLU for testing purposes, I guess.
Well, some of you may know that I just cracked the Samsung screen of my BLU (Ouch!) and I just ordered a new one from Lik-Sang.
So I'll get a Taiwanese LCD one the next weeks and willing to test out anything you need.

Additionally, I came to 2 kinds of solution. As only the LCD data has been changed, they may work...

1. If it is possible to find the LCD sequence in a compiled file (similar to the clock speed), it should be possible to write a Patcher Tool which looks for that sequence in any file and replace it with the new one.

2. Since every game is loaded up by the firmware, maybe it's possible to write a firmware which checks for the LCD sequence in the loaded file and autopatches it while loading, so it will use the correct sequence.
Could be tricky, maybe it's even impossible, but it would be the perfect solution for everybody.

Anyways, what do you guys think?

If I can help out by testing, etc. just contact me (PM, eMail, ICQ, sometimes on #gp32dev).

BTW: I'll try out as many programs I can as soon as I get my new BLU and post lists which run fine and which don't.
 
EvilDragon posted on Dec 12 2004 at 08:02 PM said:
I just did a brainstorming to find a solution... I don't know the GP32 very deeply, so if anything isn't possible, just tell me.

We all know a lot of old programs won't be updated anymore, so just changing the SDK and recompiling isn't really a solution.

So what we need is a solution so ALL the old stuff runs perfect on new BLUs.

I think we first need to find out, if programs written for the new LCD work on the old ones (though I'm pretty sure they will, as all the old commercial GP32 stuff from GP runs on the new ones).

Problem is: Most devs don't have a new BLU for testing purposes, I guess.
Well, some of you may know that I just cracked the Samsung screen of my BLU (Ouch!) and I just ordered a new one from Lik-Sang.
So I'll get a Taiwanese LCD one the next weeks and willing to test out anything you need.

Additionally, I came to 2 kinds of solution. As only the LCD data has been changed, they may work...

1. If it is possible to find the LCD sequence in a compiled file (similar to the clock speed), it should be possible to write a Patcher Tool which looks for that sequence in any file and replace it with the new one.

2. Since every game is loaded up by the firmware, maybe it's possible to write a firmware which checks for the LCD sequence in the loaded file and autopatches it while loading, so it will use the correct sequence.
Could be tricky, maybe it's even impossible, but it would be the perfect solution for everybody.

Anyways, what do you guys think?

If I can help out by testing, etc. just contact me (PM, eMail, ICQ, sometimes on #gp32dev).

BTW: I'll try out as many programs I can as soon as I get my new BLU and post lists which run fine and which don't.
​
Click to expand...


As i dont owne a BLU, i cant check some informations.
I use the official settings for LCD registers, from the (offical) pdf file.

To1:
This "could" be possible, but we dont know if the bug depend on cpu-clock/refreshrate/bit mode, or just some common settings ?
All gp32 official games run in 40Mhz cpu clock. So if they all run fine, this could be a hint, that the bug lies on changing the "default" clockrate.

To2:
The Firmware can not change the lcd settings you set, after you loaded a new programm. Every started programm comes with its owne lcd settings.


It would be nice if someone could test the clockspeed tester on my HP, and test some clocksppeds, if the bug appears/disappears on different clockspeeds.
 
Last edited by a moderator:
Hi guys.

I just coded a simple app with Mr.Mirko SDK, and it has the screen corruption thing happening. This is NOT the 1 pixel line at the bottom, its various bars across the top 1/5 or so of the screen.

It happens as soon as the sceen is initialised.

Sorry Mr.Mirko - your site is not available for me to download the tester...
 
Further testing:

Same app (loads and displays a gif from smc):

@33MHz - corrupt
@40MHz - corrupt
@66MHz - corrupt

I'm looking forward to testing with the clock speed tester, but I think the result will be the same - this is independent of clock speed.

Mr. Mirko - where can I find these 'Porch' settings in your SDK source?
 
mr.mirko posted on Dec 13 2004 at 03:32 AM said:
As i dont owne a BLU, i cant check some informations.
I use the official settings for LCD registers, from the (offical) pdf file.

To1:
This "could" be possible, but we dont know if the bug depend on cpu-clock/refreshrate/bit mode, or just some common settings ?
All gp32 official games run in 40Mhz cpu clock. So if they all run fine, this could be a hint, that the bug lies on changing the "default" clockrate.

To2:
The Firmware can not change the lcd settings you set, after you loaded a new programm. Every started programm comes with its owne lcd settings.


It would be nice if someone could test the clockspeed tester on my HP, and test some clocksppeds, if the bug appears/disappears on different clockspeeds.
​
Click to expand...

To1:
Doesn't look like it - according to the above information from GamePark, it looks like only the LCD porche and pulse is different...

To2:
Yeah, I know that it isn't possible AFTER you loaded it... but AS LONG as you are loading, the firmware could look into the code and change it, right?
(Well, I don't know, I'm just assuming ;))

This would be some kind of patch like solution no. 1 - only automatically on the fly.

Geeez, I hope my new BLU is coming soon, so I can do more testing...
 
Last edited:
Me again... just found the clock speed tester on another website. Let me know if its the wrong one:
http://www.gp32news.com/gp32news/index.php...y&id=51&lang=en

Results:
As soon as the tester starts, and its sitting on the menu screen, the screen is already corrupt (wide bars across top 1/5th of screen).

The tester allows me to select 133, 160, 164, 166 etc. It doesn't matter which I choose - all have same result (though they run fine).

corruptlcd1.jpg


corruptlcd2.jpg


One nice thing I found out - my new BLU from Lik-Sang runs at at least 166MHz out of the box :) It higher clock speeds it simply freezes on the menu selection screen.
 
pea posted on Dec 13 2004 at 04:46 AM said:
Further testing:

Same app (loads and displays a gif from smc):

@33MHz - corrupt
@40MHz - corrupt
@66MHz - corrupt

I'm looking forward to testing with the clock speed tester, but I think the result will be the same - this is independent of clock speed.
​
Click to expand...

Hmm... would it possible for you to compile it using the original SDK?
 
Last edited:
No problem, I can do that :)

Also I wanted to know: do all the apps that were compiled with the official sdk work ??
 
Also I wanted to know: do all the apps that were compiled with the official sdk work ??
Click to expand...

That is the point of this whole excersize - to see if we can narrow it down to the SDK.. we will know more after you have compiled your 'hello world' app :)

BTW, apparently not all official games work .Pinball Dreams(?) suffers from extreme slowdown issues, but who knows if it uses the official SDK for everything...
 
I have this small test program:

mode7.fxe

Display is initialised with this:
Code: 
	GpGraphicModeSet(8, NULL);
	GpLcdSurfaceGet(&gpDraw[0], 0);
	GpLcdSurfaceGet(&gpDraw[1], 1);

An frames are flipped using this.
Code: 
	GpSurfaceFlip(&gpDraw[db] );

No clock speed change.
 
Runs fine on the BLU+ (Taiwanese BLU), except its a little slow (I don't know how fast its supposed to be though).

BUT - it does have the last line of the LCD copied from the top!! Hardly noticeable, but there non-the-less
 
Yes, it slows down when the angle is close to 90° or 270°.

So this means that even if we used the sdk, the small line is there... So most of the programs should have it ?! :blink:
 
So it seems SDK programs work properly - almost. Since the top/bottom lines are really left/right this is probably another horizontal timing issue. So we need a hack for the SDK software as well -> including commercial software. I expect this is just a firmware patch -> since the SDK must be finding out how to set the LCD up from somewhere.

Sooo - would it be easy to make the homebrew APIs (e.g. Mirko) use the firmware to change screen mode? Guess its just an SWI?

Has anyone tried a different firmware on the new BLUs? I'm guessing that all SDK programs would then have the horizontal lines. Is that the case?

Mark
 
I dont have a "faulty" blue, so i cant help finding a solution to the screen problem.
Someone should play with the following settings in the file: common.c
The best thing should be, if someone has a old gp32, a FLU, a BLUE and a BLUE+.
And test the new settings.

Code: 
short gp_initFramebuffer(void *add,u16 bitmode,u16 refreshrate) {
   u32 addr = (u32) add;
   u32 GPHCLK = gp_getHCLK();
   {  u16 BPPMODE = 12;     // default 16 Bit
      u16 CLKVAL = 3;       // default 16 Bit
      u16 ENVID = 1;
      u16 MMODE = 0;
      u16 PNRMODE = 3;
      switch (bitmode) {
         //case 16 : BPPMODE=12; break;
         case  8 : BPPMODE=11; break;
         case  4 : BPPMODE=10; break;
         case  2 : BPPMODE= 9; break;
         case  1 : BPPMODE= 8; break;
      }
      // Get the correct CLKVAL for refreshrate
      // works in all bitmodes now :)
      if (refreshrate <  50) refreshrate = 50;
      if (refreshrate > 120) refreshrate =120;
      CLKVAL = (GPHCLK/(83385*2*refreshrate))-1;
      if (CLKVAL == 0) CLKVAL=1;
      refreshrate = GPHCLK / (83385*2*(CLKVAL+1));
      rLCDCON1 = (CLKVAL<<8) | (MMODE<<7) | (PNRMODE<<5) | (BPPMODE<<1) | (ENVID<<0);
   }
   {  u16 LINEVAL = 320-1;
      u16 VBPD = 1;
      u16 VFPD = 2;
      u16 VSPW = 1;
      rLCDCON2 = 0;
      rLCDCON2 = (VBPD<<24) | (LINEVAL<<14) | (VFPD<<6) | (VSPW<<0);
   }
   {  u16 HBPD = 6;
      u16 HFPD = 2;
      u16 HOZVAL = 240-1;
      rLCDCON3 = 0;
      rLCDCON3 = (HBPD<<19) | (HOZVAL<<8) | (HFPD<<0);
   }
   {  u16 ADDVAL = 0;
      u16 HSPW = 4;
      u16 MVAL = 0;
      u16 PALADDEN = 0;
      rLCDCON4 = 0;
      rLCDCON4 = (PALADDEN<<24) | (ADDVAL<<16) | (MVAL<<8) | (HSPW<<0);
   }
   {  u16 BSWP = 0;
      u16 ENLEND = 0;
      u16 HWSWP = 1;
      u16 INVENDLINE = 0;
      u16 INVVCLK = 1;
      u16 INVVD = 0;
      u16 INVVDEN = 0;
      u16 INVVFRAME = 1;
      u16 INVVLINE = 1;
      if (bitmode<16) { BSWP=1;HWSWP=0; }
      rLCDCON5 = 0;
      rLCDCON5 = (INVVCLK<<10) | (INVVLINE<<9) | (INVVFRAME<<8) | (INVVD<<7) | (INVVDEN<<6)
               | (INVENDLINE<<4) | (ENLEND<<2) | (BSWP<<1) | (HWSWP<<0);
   }
   gp_setFramebuffer((u32*)addr,1);

return refreshrate;
}

I hope someone can find out the correct settings. I would help, but dont have the money to get a new gp32...

Mirko

Mirko SDK Homepage for gp32
 
The code you want to use is this


Code: 
short gp_initFramebuffer(void *add,u16 bitmode,u16 refreshrate) {
  u32 addr = (u32) add;
  u32 GPHCLK = gp_getHCLK();
  {  u16 BPPMODE = 12;     // default 16 Bit
     u16 CLKVAL = 3;       // default 16 Bit
     u16 ENVID = 1;
     u16 MMODE = 0;
     u16 PNRMODE = 3;
     switch (bitmode) {
        //case 16 : BPPMODE=12; break;
        case  8 : BPPMODE=11; break;
        case  4 : BPPMODE=10; break;
        case  2 : BPPMODE= 9; break;
        case  1 : BPPMODE= 8; break;
     }
     // Get the correct CLKVAL for refreshrate
     // works in all bitmodes now :)
     if (refreshrate <  50) refreshrate = 50;
     if (refreshrate > 120) refreshrate =120;
     CLKVAL = (GPHCLK/(109850*2*refreshrate))-1;
     if (CLKVAL == 0) CLKVAL=1;
     refreshrate = GPHCLK / (109850*2*(CLKVAL+1));
     rLCDCON1 = (CLKVAL<<8) | (MMODE<<7) | (PNRMODE<<5) | (BPPMODE<<1) | (ENVID<<0);
  }
  {  u16 LINEVAL = 320-1;
     u16 VBPD = 8;
     u16 VFPD = 2;
     u16 VSPW = 5;
     rLCDCON2 = 0;
     rLCDCON2 = (VBPD<<24) | (LINEVAL<<14) | (VFPD<<6) | (VSPW<<0);
  }
  {  u16 HBPD = 50;
     u16 HFPD = 2;
     u16 HOZVAL = 240-1;
     rLCDCON3 = 0;
     rLCDCON3 = (HBPD<<19) | (HOZVAL<<8) | (HFPD<<0);
  }
  {  u16 ADDVAL = 0;
     u16 HSPW = 30;
     u16 MVAL = 0;
     u16 PALADDEN = 0;
     rLCDCON4 = 0;
     rLCDCON4 = (PALADDEN<<24) | (ADDVAL<<16) | (MVAL<<8) | (HSPW<<0);
  }
  {  u16 BSWP = 0;
     u16 ENLEND = 0;
     u16 HWSWP = 1;
     u16 INVENDLINE = 0;
     u16 INVVCLK = 1;
     u16 INVVD = 0;
     u16 INVVDEN = 0;
     u16 INVVFRAME = 1;
     u16 INVVLINE = 1;
     if (bitmode<16) { BSWP=1;HWSWP=0; }
     rLCDCON5 = 0;
     rLCDCON5 = (INVVCLK<<10) | (INVVLINE<<9) | (INVVFRAME<<8) | (INVVD<<7) | (INVVDEN<<6)
              | (INVENDLINE<<4) | (ENLEND<<2) | (BSWP<<1) | (HWSWP<<0);
  }
  gp_setFramebuffer((u32*)addr,1);

return refreshrate;
}

Please note that I changed the VBPD,VFPD,VSPW,HBPD,HFPD,HOZVAL and HSPW values. I have also recalculated the value used to calc the LCD Clock from 83385 to 109850. This is calculated by

((VSPW+1)+(VBPD+1)+(LINEVAL+1)+(VFPD+1))*
((HSPW+1)+(HBPD+1)+(HOZVAL+1) +(HFPD+1))

(I've nicked this from Mr Spiv frate program, thanks for the help Mr Spiv).

Obviously this code is going to be okay for testing and finding the right values. But when we have established the correct settings we will need to work out a way of automatically using the right settings for the current LCD. We will probably have to check the BIOS version or something along those lines.

Reesy
 
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