PAL Gray?

[RevEng]

Ok, I did some archaeology on the problem. It appears to be introduced in bB 1.1d, as 1.1c and 1.0 both work fine. As a side note, if you use the player1colors kernel options with 1.1d, it produces the correct 312 lines.

 

Anyway, the temporary fix is to copy the standard kernel I've attached here into the directory of any PAL50 projects that don't use player1colors. The temporary change I made was to adjust the value used for TIM64T, but since bB sets this value at compile time, it should be permanently addressed in the bB C source code.

 

std_kernel.asm

 

bB bug report to follow when I've had a chance to dig... I'm a bit too tired to dig further into it now.

[Cybearg]

There is the same problem with the multisprite kernel.

 

After looking at RevEng's fix, I made a similar fix for the multisprite kernel, attached.

 

Both work now with PAL50 with full colors and the proper 312 scanlines when using these. I'll just make sure that they're defined only for my PAL games using custom includes. Thanks!

multisprite_kernel_pal.asm

[enthusi]

Hm, what you call PAL50 here _is_ PAL, right?

PAL60 is just something that 'might' (and usually does) work on TVs. Which is framerate of NTSC, so the code IS ntsc code. The only thing between PAL60 and NTSC are the colors used in software so if played back on a PAL machine it will show proper colors.

[Cybearg]

Hm, what you call PAL50 here _is_ PAL, right?

PAL60 is just something that 'might' (and usually does) work on TVs. Which is framerate of NTSC, so the code IS ntsc code. The only thing between PAL60 and NTSC are the colors used in software so if played back on a PAL machine it will show proper colors.

Yes, I just wanted to make that distinction.