GP32 Just In Idea!

[DaveMidknight]

Hi!

During the Holiday season I start programming a 1942 shooter, but I don't want to compile always two versions of the program (one for the blu+ and one for the other with the samsung display).

So I programmed a quick lcd config program (using the Gamepark SDK, so that it will work with all GP32) in which the user can choose which lcd version he has. The program then creates a small lcd.cfg file in the gpsys directory, which contains "lcd=0" (Samsung LCD) or "lcd=1" (Taiwan LCD). My program checks now at startup the file and sets up accordingly the lcd routine.

Now for my idea! Why don't all GP32 developer use this lcd.cfg in the gpsys directory. Most developer would only need to change a small part in their code. They wouldn't need to compile two versions of their programs and the user wouldn't need to look for the right version, just run the lcd config program once and that it's.

Greatings
Dave

LCD Config Program

 

[don]

The idea is actually pretty good, the problem is to create a 'standard', so that every coder knows about that.
BTW: Your idea would require opening and parsing the file, I'd prefer to just check for the file (ie: if there's a lcd.cfg, you got a BLU+).

 

[K-teto]

Yeah, checking if a file exists is much easier than parsing it, i agree with don, i hope the other developers agree too, and then use it as an standard.
Good idea, both DaveMidknight and don.

 

[synkro]

sounds good, maybe some standard routines for both SDKs so everybody can include it easily to your own code.

 

[pea]

The problem is that developers need to still have a BLU/BLU+ option somewhere in the menu, because it is not enough that all developers know about it, but all users have to know about it too, in order to put the text file there in the first place.

For example, paul just buys a new GP32 BLU+ and puts some games on it, but all of them have the gray bar issue. What does he do? He just wants to select a menu option, not generate text file and upload it to the right directory.

It would also help for people with multiple SMC cards, because the file has to exist on all cards.

It would also help when people format their SMC cards, because they don't want to generate and copy across a text file every time they do this!

 

[don]

It would also help when people format their SMC cards, because they don't want to generate and copy across a text file every time they do this!

​

If it's only one file that needs to go on a SMC... People need to learn about the BLU+ problem, so they should learn about the solution, too.

 

[craigix]

How about 2 filenames, either called bluplus or blu, if neither file exists the program asks the user then makes the correct file.

-Craig

www.gbax.com

 

[pea]

I agree. I think there still needs to be a menu option if the file doesn't exist...

Does the official SDK work with both the blu and the blu+ ?
If so, what are the differences?

 

[SvOlli]

So I programmed a quick lcd config program (using the Gamepark SDK, so that it will work with all GP32)

If the Gamepark SDK can do it, why can't anyone else?

I'm a bit lost here, since my daytime work was drawing my full attention away while the BLU+ appeared.
Are there any posts / webpages describing the BLU+/Samsung display problematic in detail?

Compiling different versions of a program for different hardware or detecting the hardware by the existance or content of a file is nothing more than a poor workaround and not a fix of the problem. Aww, come on, we can do better than this. And this problem is solvable and has been solved since the Gamepark SDK seems to do it correctly, from what I read.

From peeking in MrMirko's SDK one can tell that the difference is 'only' in 5 of the parameters, so all what's missing there is a good detection. The least we can do is to read out the LCD registers as the should contain some different values set from the firmware. So all software that's not a firmware replacement should just work.

Have all people with reverse engineering skills vanished?

Greetings,
SvOlli

 

[DaveMidknight]

Does the official SDK work with both the blu and the blu+ ?
If so, what are the differences?

​

The official SDK works with both the blu and the blu+ . I think it checks the firmware version to check on which GP32 it is running. So I don't know if it also works if you have a different firmware. The problem is, that the official SDK sucks. I'm using MrMirko SDK. But that is just my opinion.

I agree. I think there still needs to be a menu option if the file doesn't exist...

​

I also have the menu option in my program. Just in case that the user hasn't run the config program or if the file doesn't exist. But I save the value of the menu point in the lcd.cfg file. So even if you don't use the config program, after the first start of the program the lcd.cfg is on your SMC. That way the user don't have to create the file on their SMC.

By the way. For everyone who doesn't want to create their own lcd.cfg. Here is my lcd config program. LCD Config Program

Dave

 

[fdave]

The idea is actually pretty good, the problem is to create a 'standard', so that every coder knows about that.
BTW: Your idea would require opening and parsing the file, I'd prefer to just check for the file (ie: if there's a lcd.cfg, you got a BLU+).

​

Eh, did I miss something? What's wrong with autodetecting from the BIOS version?

A-la:

extern "C" int gp_initFramebufferBP(void *,unsigned short,unsigned short);

static int InitFrameBuffer(void *buffer,int depth,int rate)
{
  int bios=0;
  // Find out if it's a new LCD or an old one:
  bios=*(int *)0x1014;
  if (bios<0x01030606) return gp_initFramebuffer  (buffer,depth,rate);
  else                 return gp_initFramebufferBP(buffer,depth,rate);
}

 

[toxibunny]

if making a text file is a problem, surely a small program to create one would be a piece of piss to make.


personally, making a text file *is* a problem for me. I haven't put any more beats of rage mods on my GP because of the (admittedly *very* small) problem of having to edit the .txt file.

Isn't there a program already on GP32 that lets you open/create, edit and save .txt files?

 

[pea]

fdave - that is the preferred solution, obviously, but the possibility is that it doesn't work if the firmware/bios is flashed.

Has anyone tested this?

 

[DaveMidknight]

Hi,

fdave solution works fine (just tested), as long as every flashed firmware has the correct version. 1.66 for BLU+ and 1.57 or below for all the GP32 with Samsung LCD.

I check the Aquafish v5.01 and Slubman firmware. Both have the correct firmware version in their BLU+ and Non-BLU+ firmware.

So I think we can stick with fdave solution.

Dave

 

[The Phantom]

Hi,

fdave solution works fine (just tested), as long as every flashed firmware has the correct version. 1.66 for BLU+ and 1.57 or below for all the GP32 with Samsung LCD.

The non-plus BLU firmware version is also 1.6.6. (Recall that to distinguish BLU from BLU+ you have to look at the date code, not the firmware version because they're both 1.6.6). Besides, we don't know if there will be another non-plus BLU firmware version available in the future (unlikely maybe, but something that should be taken into account.)

The best solution would probably be to use the same way of initting the LCD that GPSDK uses, which presumably involves calling some BIOS function. I'm not sure whether or not anyone has reverse engineered this yet.

 

[synkro]

reading the BIOS version is IMHo not the key because of the various existing/coming BIOS's. What is the Problem with that .cfg? I just one standard procedure everybody has to code

1.) is there a cfg file?
2a.) NO: ask the user if he/she sees any grey bar of if he has a BLU+
3a.) create .cfg reboot GP32
2b.) YES: load .cfg

so what? only ONE reboot per SMC, I think this is acceptable. So all coders have to commit oneself to include these procedure (whick should be standard/open source/ for both SDKs)....

 

[The Phantom]

so what? only ONE reboot per SMC, I think this is acceptable. So all coders have to commit oneself to include these procedure (whick should be standard/open source/ for both SDKs)....

​

Why the reboot? You could just create the file and continue.

I don't understand what you mean by "for both SDKs" though. This doesn't apply to GPSDK. I still think that switching over to how GPSDK inits the screen is the preferable solution as it wouldn't require any user intervention at all.

 

[gp32rich]

Ditto! Why the need for a reboot?

It should go ...

1 check for .cfg
2 No? Ask (and create)
3 init with spec'd values

I think a standard needs to be decided upon.
I'm with craig, just look for the filename(s), much easier than opening a file and reading the contents.

If you're using GPSDK, just do the inits, no need to check for the file :/


Edit: Except... how can you ask without initing :S
So are re-init's a possibility? ^_^

 

[synkro]

because before you can prompt the user to make any kind of input you have to init the screen....

so.. wyh don't someone post the GPSDK init code then?

 

[gp32rich]

Damn! I was staring at the screen and you trumped me :lol: