GP32 Just In Idea!

[fdave]

I think the problem is that *just in case* the firmware version number happens to be wrong, users will have no way of setting the LCD version except for flashing new firmware.

I guess this is ok though.

If we didn't have to use a text file at all, that would be a lot easier/cleaner solution.

​

Ok, here's my point:

If you app is a nice app, it'll have a plain text config file ANYWAY,so you can have an BLU+ option in that. I'm not disputing that. I'm just disputing having it as the canonical way of detecting a BLU+.

If you go for the text file, there has to be a way of the user setting the text file, therefore you have to be able to see the screen, and if you can see the screen then you can just have a menu option anyway (like the 50hz/60hz switch) so it's pointless having the file?

Also, excellent point about the flash card being shared between devices. Yet another reason why it is a hacky solution.

Another idea - can you in some way poll a register on the LCD itself, to query what it is? Like a status register which is different on the old and new LCDs? That way even if someone replaced their LCD and reflashed their GP32, your code would still autodetect right.

Just my 2c...

Also - I don't have a GPETC directory on mine. So your code may crash on mine anyway. :blink:

 

[Rattboi]

Ok, here's my point:

If you app is a nice app, it'll have a plain text config file ANYWAY,so you can have an BLU+ option in that. I'm not disputing that. I'm just disputing having it as the canonical way of detecting a BLU+.

If you go for the text file, there has to be a way of the user setting the text file, therefore you have to be able to see the screen, and if you can see the screen then you can just have a menu option anyway (like the 50hz/60hz switch) so it's pointless having the file?

This isn't totally true, since usually you can still see most of the stuff on the screen between programs, it's just distorted/corrupted.

Also, excellent point about the flash card being shared between devices. Yet another reason why it is a hacky solution.

Another idea - can you in some way poll a register on the LCD itself, to query what it is? Like a status register which is different on the old and new LCDs? That way even if someone replaced their LCD and reflashed their GP32, your code would still autodetect right.

AFIAK, there isn't any way to poll the LCD directly to see which one it is. Also, there is no like "Default settings" for the LCD if you reset it or anything like that.

Also - I don't have a GPETC directory on mine. So your code may crash on mine anyway. :blink:

If you always create the GPETC folder in your code, it will be fine. It won't create it if there's already a directory by that name, and if there isn't, the directory will be made. Viola!

 

[mr.mirko]

This is the code i use in my new SDK version ...

// Here we must decide what machine we are running on.
// 1st we check the bios version
// 2nd we check if the User pressed the R or L Button ( this will override bios check )
//   R = Blu+
//   L = gp32 normal, flu, blu
short gp_initFramebuffer(void *add,u16 bitmode,u16 refreshrate) {
  u32 bios=0;
  u32 biosv=*(int*)0x1014; 
  if (biosv<0x01030606) bios=0; else bios=1;
  if (gp_getButton()&BUTTON_L) bios=0;
  if (gp_getButton()&BUTTON_R) bios=1;
  if (bios==1) return (gp_initFramebufferBP(add,bitmode,refreshrate));
  return (gp_initFramebufferN (add,bitmode,refreshrate));
}

 

[The Phantom]

Both BLU and BLU+ have firmware number 0x01030606.

 

[RobertJ]

As someone has already mentioned, the official SDK bases it on the firmware version
As someone else has already mentioned, future firmware/bios releases may not work using this system.

Hence the file. Otherwise we would just use the firmware version as the official SDK does. or not?

​

Gnnnnh!

GNNNNHHHH!

Gamepark changed the make of the LCD panel, but they did not change the SDK did they, because their LCD init code works fine with both and clearly works with custom firmware as well.

They aren't going to release a new GP32 version that doesn't work with their own SDK as it would make all software out there unusable, and if they did, they'd deserve to go under. But I think we can assume that this isn't likely.

The answer is so bloody simple, its driving me mad!

This is only a problem for people not using the official SDK, so they should just change their code to init it exactly the same way as the official SDK does, and then there is no problem.

Anything else, including detection attempts of which model of LCD panel is there, is just completely unnecessary and WILL cause more problems than it solves.

As we say in London....

...Soooort iiit aaaaaaaaaaaaaaaaaaaaghhhhht!

 

[Reesy]

No your right Gamepark did not change the SDK, but they did change the bios. If you look at the code that actually does the LCD init in the bios you will notice that it uses different values from the previous bios. Gameparks SDK just calls this bios function, thats why it works on the BLU or BLU+.

We could just call the same bios function from other SDK's but I'm not sure if the bios function expects the system to be setup for the standard gamepark SDK, ie system variable stored at particular points in memory.

 

[mr.mirko]

As someone has already mentioned, the official SDK bases it on the firmware version
As someone else has already mentioned, future firmware/bios releases may not work using this system.

Hence the file. Otherwise we would just use the firmware version as the official SDK does. or not?

​

Gnnnnh!

GNNNNHHHH!

Gamepark changed the make of the LCD panel, but they did not change the SDK did they, because their LCD init code works fine with both and clearly works with custom firmware as well.

They aren't going to release a new GP32 version that doesn't work with their own SDK as it would make all software out there unusable, and if they did, they'd deserve to go under. But I think we can assume that this isn't likely.

The answer is so bloody simple, its driving me mad!

This is only a problem for people not using the official SDK, so they should just change their code to init it exactly the same way as the official SDK does, and then there is no problem.

Anything else, including detection attempts of which model of LCD panel is there, is just completely unnecessary and WILL cause more problems than it solves.

As we say in London....

...Soooort iiit aaaaaaaaaaaaaaaaaaaaghhhhht!

​

I really would help here, but i dont have a blu/blu+, so i cant write/test new blu+ detection/new register settings...

If someone knows a way to diff a BLU and BLU+ it would help very mutch...

 

[RobertJ]

I really would help here, but i dont have a blu/blu+, so i cant write/test new blu+ detection/new register settings...

If someone knows a way to diff a BLU and BLU+ it would help very mutch...

​

Craig must have a BLU+ handy, surely.

Mirko, if you could use the official source as a guide to calling the bios to setup the LCD, and it works fine on your GP32, Craig could test it.

 

[the_Diabologic]

how do the fws do it?
i mean, they show up properly on both, blu-- and rest
so, if you just take their code and set the lcdcons wiith that, it should work just fine on both systems

P.S.: is anyone willing to test things on their blu+ for me?
i'm working on a gfx-lib atm (16bpp, 8bpp and kind of corrupted 4bpp modes supported atm ), so it would be nice to see wether my settings work or not

 

[the_Diabologic]

I really would help here, but i dont have a blu/blu+, so i cant write/test new blu+ detection/new register settings...

If someone knows a way to diff a BLU and BLU+ it would help very mutch...

​

Craig must have a BLU+ handy, surely.

Mirko, if you could use the official source as a guide to calling the bios to setup the LCD, and it works fine on your GP32, Craig could test it.

​

i guess the problem is, that you lose most of your control once you start using swis
it's nice to code those things without having to use GP's code