Stella 6.0 PAL bug?

[winkdot]

Don't get one. At times when testing coding Stella runs the code and thinks it's PAL.

I have the following sets;

 

set kernel DPC+
set tv ntsc

Anyone else seen this? Driving me nuts.

[Thomas Jentzsch]

Probably your initial frames are closer to PAL than to NTSC. Then Stella auto detects PAL. Use the command line parameters to override auto detection.

[winkdot]

Thanks but this seems like a bad workaround. There has to be a better way. Stella should perform the set tv ntsc and not try and to get in the way.

I don't know much about PAL. Should I increase frames to defeat this issue?

[Thomas Jentzsch]

This is not a workaround, but a design feature. Else users would have to manually change the settings for all PAL games. There is a whole world besides NTSC.

 

For a fix, I can only guess without a ROM.

[winkdot]

Yea, big PAL world, I just don't know anything about it. I introduced code to waste cycles to get around it.

Anyway something changed there because I never saw this in earlier Stella releases.

Edited January 8, 2019 by winkdot

[JeffJetton]

I always kinda assumed that the autodetect just counts the number of (simulated) TIA HSYNCs that occur between VSYNC signals. Close to 262, consider it NTSC. Much more than that, call it PAL.

 

But if adding waste cycles gets Stella to undetect PAL in favor of NTSC, my theory must not be right, eh? (Unless those cycles were WSYNCs, I guess?)

 

Edited to add: Hmmm... looking at the Stella source--although my C++ is a bit rusty--I think it does in fact count lines between VSYNCs.

Edited January 8, 2019 by JeffJetton

[winkdot]

I always kinda assumed that the autodetect just counts the number of (simulated) TIA HSYNCs that occur between VSYNC signals. Close to 262, consider it NTSC. Much more than that, call it PAL.

 

But if adding waste cycles gets Stella to undetect PAL in favor of NTSC, my theory must not be right, eh? (Unless those cycles were WSYNCs, I guess?)

 

Edited to add: Hmmm... looking at the Stella source--although my C++ is a bit rusty--I think it does in fact count lines between VSYNCs.

No idea Jeffjetton. Wasting cycles fixed the issue for me. I have seen this multiple times sense the release of 6.0 but I never saw it before that. Not sure what the generated code is. A simple PFCLEAR fixed it. Does that generate a WSYNC?

[+Muddyfunster]

I'm using DPC+ on Dare Devil and also Tyre Trax with my roms set to NTSC and I don't see the same issue in Stella 6

 

Are you using anything like the title screen kernel? I found a couple of times I managed to cause that to screw up (my causing by not following the rules / settings) and I had roms picking up as PAL until I fixed my error.

 

or maybe you are doing too much before the first drawscreen? hard so say without seeing the bin and or code.

Edited January 8, 2019 by Muddyfunster

[DirtyHairy]

Anyway something changed there because I never saw this in earlier Stella releases.

 

I don't recall any changes to that domain, but 6.0 has been a long time in the making, so I could be wrong. If you truly think you have spotted a regression, then please send us the ROM. Apart from that, I can only echo what Thomas said: If your game generates messy frames for too long, it might trip up autodetection.

 

Edited to add: Hmmm... looking at the Stella source--although my C++ is a bit rusty--I think it does in fact count lines between VSYNCs.

 

 

It does

Edited January 8, 2019 by DirtyHairy

[JeffJetton]

No idea Jeffjetton. Wasting cycles fixed the issue for me. I have seen this multiple times sense the release of 6.0 but I never saw it before that. Not sure what the generated code is. A simple PFCLEAR fixed it. Does that generate a WSYNC?

Oh, you're using bB? Not sure there. I don't imagine that it would, inherently.

 

Then again, now that I think about it, adding more WSYNCs to your frame would probably only make Stella more certain that it's PAL over NTSC (because each frame would have more lines, not fewer). So that's not it either. :-(

[JeffJetton]

 

It does

 

Woo-hoo!

[+SpiceWare]

Sounds like you're doing way to much before your first drawscreen.

[winkdot]

I'm using DPC+ on Dare Devil and also Tyre Trax with my roms set to NTSC and I don't see the same issue in Stella 6

 

Are you using anything like the title screen kernel? I found a couple of times I managed to cause that to screw up (my causing by not following the rules / settings) and I had roms picking up as PAL until I fixed my error.

 

or maybe you are doing too much before the first drawscreen? hard so say without seeing the bin and or code.

Likely doing too much. I have not used the title screen kernel.

Edited January 8, 2019 by winkdot

[winkdot]

Sounds like you're doing way to much before your first drawscreen.

I think I must be. Oh on another subject I'm using your SFX engine (love it, great job!) but I have an issue with it (or something else) I can't figure. At times it gets sound stuck on and I'm just not sure what in my code is causing it. Ever heard of that before?

[+Muddyfunster]

I think I must be. Oh on another subject I'm using your SFX engine (love it, great job!) but I have an issue with it (or something else) I can't figure. At times it gets sound stuck on and I'm just not sure what in my code is causing it. Ever heard of that before?

I had this happen sometimes when going back to the title screen.

 

I think

temp1=sfxoff()

worked for me.

 

Maybe repost that as a separate query in the bB forum ?

Edited January 9, 2019 by Muddyfunster

[winkdot]

I had this happen sometimes when going back to the title screen.

 

I think

temp1=sfxoff()

worked for me.

 

Maybe repost that as a separate query in the bB forum ?

Thanks, I need to do more testing but that seemed to do the trick. I have not played it yet but your new game looks very nice. Looking forward to it.

The game I'm currently working on has been a fight all the way. Hope it's worth it.

[+SpiceWare]

temp1=sfxupdate() needs to be done after every drawscreen.

 

Based on Muddyfunster's comment and your followup it seems like you're using the bB titlescreen routines and the sound issue sometimes occurs when returning to the menu - that suggests sfxupdate is not being called while the titlescreen is shown. I'm not familiar with it, but suspect it has adds a new drawscreen command which likewise needs to be followed by a call to sfxupdate.

 

...

 

Yep - in the PDF from the zip found here I see this on page 9:

 

 

 

 
              titlepage
               gosub titledrawscreen bank2
               if joy0fire || switchreset then goto gamestart
               goto titlepage

---

titledrawscreen appears to be the titlescreen equivalent to drawscreen, so change the above to this:

 
              titlepage
               gosub titledrawscreen bank2
               temp1=sfxupdate()
               if joy0fire || switchreset then goto gamestart
               goto titlepage

---

Once you've done that you can then add sound effects to the menu as well, such as a short beep or click whenever the user changes an option.