Cybearg Posted March 25, 2013 Share Posted March 25, 2013 I'm working on making PAL versions for my finished games, preferably PAL50 for compatibility reasons, but if I lap a "set tv pal" in top of most of my games, all the colors are grey. This doesn't have to do with the color palette--I have already set the colors to work correctly with PAL60, but if I try PAL50, Stella reports the games have 313 scanlines @ 49.84fps => PAL and all the colors are grey, even if though they're correct for PAL. What is causing this less-than-50 FPS issue? This applies both to a standard kernel game and a multisprite kernel game. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 25, 2013 Share Posted March 25, 2013 Are you sure you're using PAL color values in bB? it's not enough to set the Region: PAL in VisualbB. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 25, 2013 Share Posted March 25, 2013 I'm working on making PAL versions for my finished games, preferably PAL50 for compatibility reasons, but if I lap a "set tv pal" in top of most of my games, all the colors are grey. This doesn't have to do with the color palette--I have already set the colors to work correctly with PAL60, but if I try PAL50, Stella reports the games have 313 scanlines @ 49.84fps => PAL and all the colors are grey, even if though they're correct for PAL. What is causing this less-than-50 FPS issue? This applies both to a standard kernel game and a multisprite kernel game. You need to have an even scanline count for PAL, otherwise it will have color loss. Make your scanlines 312 instead of 313. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 25, 2013 Author Share Posted March 25, 2013 You need to have an even scanline count for PAL, otherwise it will have color loss. Make your scanlines 312 instead of 313. So the problem is that PAL takes more cycles than NTSC? So I will have to simplify the cycle count somewhere in order to make it work with PAL50? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 25, 2013 Share Posted March 25, 2013 I tried compiling the ms.bas multi-sprite kernel game and nitebear.bas standard kernel game and they all worked with "set tv pal" Indeed many of the colors were grey but not all of them. As well the cycle count stayed at a steady 313. As Cybearg never posted source I cannot be sure he's just using colors that are valid for NTSC and grey on PAL. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 25, 2013 Share Posted March 25, 2013 theloon, that may well be a secondary issue, but the odd-numbered scanline count is the primary issue. Cybearg, which kernel are you using, and can you post the source files? Quote Link to comment Share on other sites More sharing options...
+stephena Posted March 25, 2013 Share Posted March 25, 2013 You can toggle this in Stella with Control-L, but it really should be left on, and the actual cause of the irregular scanline count fixed. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 25, 2013 Author Share Posted March 25, 2013 Indeed many of the colors were grey but not all of them. As well the cycle count stayed at a steady 313. As Cybearg never posted source I cannot be sure he's just using colors that are valid for NTSC and grey on PAL. This doesn't have to do with the color palette--I have already set the colors to work correctly with PAL60, but if I try PAL50, Stella reports the games have 313 scanlines @ 49.84fps => PAL and all the colors are grey, even if though they're correct for PAL. theloon, that may well be a secondary issue, but the odd-numbered scanline count is the primary issue. Cybearg, which kernel are you using, and can you post the source files? This applies both to a standard kernel game and a multisprite kernel game. I'll attach one of them to the post. You can toggle this in Stella with Control-L, but it really should be left on, and the actual cause of the irregular scanline count fixed. I'm not worried about being informed of the FPS count or anything--just that everything is grey. joyridePAL.bas joyride.inc Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 25, 2013 Share Posted March 25, 2013 I'm not worried about being informed of the FPS count or anything--just that everything is grey. Ctrl + L = Toggle PAL color-loss effect: stella.sourceforge.net/docs/index.html 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted March 25, 2013 Share Posted March 25, 2013 I'm not worried about being informed of the FPS count or anything--just that everything is grey. What does this have to do with using Control-L to toggle color-loss effect on and off?? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 25, 2013 Share Posted March 25, 2013 What does this have to do with using Control-L to toggle color-loss effect on and off?? He forgot to hit Control-L for "listen" on his ears. Happens to me, too Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 25, 2013 Author Share Posted March 25, 2013 He forgot to hit Control-L for "listen" on his ears. Happens to me, too I was thinking ALT+L, which is used to toggle the FPS counter on and off, so I thought that stephena was trying to let me know how to turn off the FPS counter, in case he thought that I was complaining about seeing the scanline/framerate count. Good to know about the CTRL+L, though it would still be gray on a real PAL machine, wouldn't it? So I still need to know what's causing the issue. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 25, 2013 Share Posted March 25, 2013 (edited) So I still need to know what's causing the issue. Omegamatrix already replied with the cause and the fix: You need to have an even scanline count for PAL, otherwise it will have color loss. Make your scanlines 312 instead of 313. It has nothing to do with cycles, just the number of scanlines which MUST BE EVEN for PAL. Edited March 25, 2013 by SpiceWare Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 25, 2013 Share Posted March 25, 2013 All this is a bit worrying as the games I tried with PAL settings came up 313. Bataris ms.bas example is dead simple so I don't know why it would have an inappropriate amount of cycles by default. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 25, 2013 Share Posted March 25, 2013 Bataris ms.bas example is dead simple so I don't know why it would have an inappropriate amount of cycles by default. That's easy - batari's in the US and the color loss routines in Stella used to not work correctly, so it would have been easy to overlook it. December 22, 2006 ... Fixed bug in PAL colour-loss emulation, which wasn't actually being done for the original Stella and z26 palettes. Quote Link to comment Share on other sites More sharing options...
+stephena Posted March 25, 2013 Share Posted March 25, 2013 That's easy - batari's in the US and the color loss routines in Stella used to not work correctly, so it would have been easy to overlook it. There's actually still an issue with the colour-loss effect with Blargg filtering; it doesn't work in that mode either. This will take some time to fix, as the issue is somewhat involved. Long story short; when testing ROMs, make sure to try it with and without TV effects enabled. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 25, 2013 Share Posted March 25, 2013 As batari is busy with other projects I wonder if bB users should make their own new color chart adjusting for this. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 25, 2013 Share Posted March 25, 2013 I don't think it's been wrong that long... there was a tweaking of the NTSC overscan/vblank timing a year or so back. I think it probably got introduced then. I have no bB environment at work, but I'll check it when I get home. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 25, 2013 Author Share Posted March 25, 2013 (edited) It has nothing to do with cycles, just the number of scanlines which MUST BE EVEN for PAL. So, uh, HOW do I set the number of desired scanlines exactly? So far as I know, that's all done in the kernel, and kernel tweaking is beyond my level of understanding, especially if it involves reordering the kernel's cycle counts. I get that I need an even number. I saw Omega say that, don't worry. But in my experience so far, the only thing that causes scanline counts to be off is running out of cycles, QED. Edited March 25, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 25, 2013 Share Posted March 25, 2013 (edited) Ah, I thought you missed that part as your response didn't mention the scanline count. I don't program in bB so I tend to not realize just how much of what's going on it hides from you. The kernel is just the part of the code that draws the screen. There's also code for Vertical Blank and Over Scan, during which non-visible scan lines are being generated by the TIA chip. The sum of the scanlines for vertical blank + kernel + overscan should be 262 for NTSC or 312 for PAL, if one of them is off then PAL can experience the color loss problem. Routines for Vertical Blank and Over Scan both tend to utilize a timer, TIM64T, to know when to end. I suspect bB is updating the timer with an incorrect value when PAL has been selected. Looks like RevEng is going to check it when he gets home, so he might have a fix for you this evening. If you'd like a short term fix you could add this just before drawscreen: asm sta WSYNC ; the WSYNC must be all caps end drawscreen that should give you 314 scanlines for PAL (and 263 for NTSC), both of which are within display tolerance. Edited March 25, 2013 by SpiceWare Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 25, 2013 Share Posted March 25, 2013 Does someone use PAL50 nowadays? AFAIK people don't like slower speed and prefer PAL60. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 25, 2013 Share Posted March 25, 2013 If you'd like a short term fix you could add this just before drawscreen: asm sta WSYNC ; the WSYNC must be all caps end drawscreen that should give you 314 scanlines for PAL (and 263 for NTSC), both of which are within display tolerance. Unfortunately that won't work. bB code runs in overscan, and the first thing "drawscreen" does is wait for INTIM to finish. Does someone use PAL50 nowadays? AFAIK people don't like slower speed and prefer PAL60. For sure. That's probably why it took so long for anybody to find the bug. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 25, 2013 Author Share Posted March 25, 2013 Well I'd be happy to just do PAL60, but I was under the impression that it severely limited television compatibility, especially with older televisions (the kind that the 2600 are "supposed" to be played on). Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 25, 2013 Share Posted March 25, 2013 bummer, though that does make sense. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 25, 2013 Share Posted March 25, 2013 It would be nice to know from Albert how many people buy PAL50 carts (obviously when PAL60 carts are available too). Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.