GP32 Gp_initframebufferbp


fdave

Final Dave
Joined
Apr 20, 2004
Messages
331
Website
www.finalburn.com
Should we just use gp_initFramebufferBP all the time now in order to support BLU+?

Or will gp_initFramebufferBP corrupt the display of previous GP32s?
 
fdave posted on Dec 29 2004 at 01:45 PM said:
Should we just use gp_initFramebufferBP all the time now in order to support BLU+?

Or will gp_initFramebufferBP corrupt the display of previous GP32s?

As I read it the display will be corrupted slightly (slight lines). As when using DrMD in BLU+ mode on a FLU. i.e. make it an option for now.

Thanks,

Mark
 
Last edited by a moderator:
synkro posted on Dec 29 2004 at 01:58 PM said:
I didn't dare to aks the same questions but it seems that everbody knows but me :) thank you!

Hehe, you know me, never afraid to ask the stoopid question! ;-)

So I tried it:
extern "C" int gp_initFramebufferBP(void *add,u16 bitmode,u16 refreshrate);

gp_setCpuspeed(66);
rate=gp_initFramebufferBP(framebuffer, 16, 85);


And it does seem to work (rate==76). And display seems ok on my original GP32, as far as I can tell. So is there any catch to using it?
 
Last edited by a moderator:
fdave > I didn't know you still wrote on GP32x. :)

Please finish your amazing Cyclone core. :)

So many people would love to see it finished, that would allow DrMD for example to have so many more games working.

Cyclone bugs prevents many games from working actually.

It's so sad. :(

Please fdave never give up, you're so close to make the perfection! :)
 
gp_initFramebufferBP seems to work fine on geepee32 aswell, but this is of course no indication as to whether it will work on a real BLU - geepee32 probably ignores those porch values anyway since it doesn't have a real LCD.
 
fdave posted on Dec 29 2004 at 03:33 PM said:
And it does seem to work (rate==76). And display seems ok on my original GP32, as far as I can tell. So is there any catch to using it?

Have a look at DrMD on your normal GP32. You'll see what I mean about the slight vertical lines when in BLU+ mode. It would seem odd that Mirko would add an extra function if the new one worked fine on both the BLU+ and the original. Otherwise the original should be changed instead...

Thanks,

Mark
 
Last edited by a moderator:
Drumaster posted on Dec 29 2004 at 08:20 PM said:
fdave > I didn't know you still wrote on GP32x. :)

Please finish your amazing Cyclone core. :)

So many people would love to see it finished, that would allow DrMD for example to have so many more games working.

Cyclone bugs prevents many games from working actually.

It's so sad. :(

Which games were you thinking of?
 
Last edited by a moderator:
fdave posted on Dec 29 2004 at 03:33 PM said:
synkro posted on Dec 29 2004 at 01:58 PM said:
I didn't dare to aks the same questions but it seems that everbody knows but me :) thank you!

Hehe, you know me, never afraid to ask the stoopid question! ;-)

So I tried it:
extern "C" int gp_initFramebufferBP(void *add,u16 bitmode,u16 refreshrate);

gp_setCpuspeed(66);
rate=gp_initFramebufferBP(framebuffer, 16, 85);


And it does seem to work (rate==76). And display seems ok on my original GP32, as far as I can tell. So is there any catch to using it?

Correction, about 50% of the time there are some faint vertical lines. Hmm.

Any 'official' word from Reesy or Mr. Mirko on the best way to make stuff run on all GP32s? Just curious.

By the way, I do pop into gp32x occasionally. I still have my GP32 and play on it a lot (usually GigaDrive and fGen32), but less spare time now to dev for it sadly. I still think it's the best handheld though because all the others are so closed off to casual developers.
 
Last edited by a moderator:
Here are just a couple off the top of my head, But there are many, Many more that don`t work because of the cyclone bug/s.

The chaos engine
Fantastic dizzy
Gods
Mega turrican
Turrican
Thunderforce 4

Trooper
 
fdave posted on Dec 30 2004 at 02:46 AM said:
fdave posted on Dec 29 2004 at 03:33 PM said:
synkro posted on Dec 29 2004 at 01:58 PM said:
I didn't dare to aks the same questions but it seems that everbody knows but me :) thank you!

Hehe, you know me, never afraid to ask the stoopid question! ;-)

So I tried it:
extern "C" int gp_initFramebufferBP(void *add,u16 bitmode,u16 refreshrate);

gp_setCpuspeed(66);
rate=gp_initFramebufferBP(framebuffer, 16, 85);


And it does seem to work (rate==76). And display seems ok on my original GP32, as far as I can tell. So is there any catch to using it?

Correction, about 50% of the time there are some faint vertical lines. Hmm.

Any 'official' word from Reesy or Mr. Mirko on the best way to make stuff run on all GP32s? Just curious.

By the way, I do pop into gp32x occasionally. I still have my GP32 and play on it a lot (usually GigaDrive and fGen32), but less spare time now to dev for it sadly. I still think it's the best handheld though because all the others are so closed off to casual developers.

I haven't found an automatic way of detecting what version the LCD is, so at the moment I default the LCD to samsung and let the user switch it if they have one of the new LCD's. Their selection is then saved in the menu options are used the next time they start DrMD.

I'm not sure if its possible or not, but maybe we could just read the bios version out of the bios and setup the LCD depending on the bios version.

AFAIK the bios version is held at 0x00001014.
For the old LCD's the value is 0x01030507
For the new LCD's the value is 0x01030606
 
Last edited by a moderator:
Reesy, thats great!

so something like this?
Code:
unsigned short *biosVersion = 0x00001014;

if (*biosVersion == 0x01030606){
  Gp_initframebufferbp( );
}else{
  Gp_initframebuffer( );
}
or better still, work it directly into the initframebuffer function...

But what happens with other bios flashes?
 
It won't work if you flash an old firmware onto your BLU+, but then again the old firmware will not work on the new BLU+ because it has the old LCD settings.

Your code looks good, as long as the bios area is readable. If it does work I think it should be added into the main Gp_initframebuffer routine and the Gp_initframebufferbp routine should be dropped. Then all people have to do is call Gp_initframebuffer and it will work on any BLU/BLU+
 
fdave posted on Dec 30 2004 at 02:41 AM said:
Drumaster posted on Dec 29 2004 at 08:20 PM said:
fdave > I didn't know you still wrote on GP32x. :)

Please finish your amazing Cyclone core. :)

So many people would love to see it finished, that would allow DrMD for example to have so many more games working.

Cyclone bugs prevents many games from working actually.

It's so sad. :(

Which games were you thinking of?
Yes many don't work, I can list all of them.

And some of them have the points bugs (the points account in Gynoug for example is really mad).

Please try to solve that fdave, you' re the only one who can do it. :)

P.S. : Give me your paypal account and I'll give you something if you try to finish your amazing Cyclone. :)
 
Last edited by a moderator:
Speaking of Cyclone bugs, I squashed a couple today. One was where the sbcd opcode was not decimal correcting correctly. The another was in the addx and subx opcodes where they were not setting the Z flag correctly. The time in streets of rage now works, the totalling of scores will probably work to but I can't be asked to get to the end of the level just yet :)

I'm going to do some tests but I think another reason why alot of games don't work is because not all opcodes are implemented yet. At the moment when an un-implemented opcode is encountered, the core just does an "or" opcode and continues executing. I'm going to change this is halt with an error saying "so and so" opcode not implemented.

Reesy
 
Reesy > I really hope we will get Cyclone as compatible as Musachi core one day! :)

fdave and Reesy : don't give up, you're the men. :)
 
Back
Top