GP32 Gp_initframebufferbp

[fdave]

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?

 

[synkro]

I didn't dare to aks the same questions but it seems that everbody knows but me thank you!

 

[foft]

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

 

[fdave]

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?

 

[GPnator]

Ah fdave is back :lol:

 

[Drumaster]

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!

 

[pea]

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.

 

[synkro]

hmm... with what refresh rate of the LCD do I get the best outcome on both BLU+, FLU and Original

 

[foft]

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

 

[fdave]

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?

 

[fdave]

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.

 

[trooper]

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

 

[Jr2swiss]

Shadowrun doesn't work I believe

 

[Reesy]

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

 

[pea]

Reesy, thats great!

so something like this?

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?

 

[Reesy]

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+

 

[Drumaster]

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.

 

[Reesy]

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

 

[Drumaster]

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.

 

[Antiriad]

Reesy and fDave: Just wondering, are all the opcodes of the 68000 documented somewhere?