Jump to content

Recommended Posts

^^It is possible some CRTs may be more sensitive to sporadic fluctuation in frame rate than others. I think every developer should be logging scanline counts in Stella because playing on the Harmony with a more tolerant CRT, they may not even notice a roll glitch that could effect other people's sets. Also playing on an HDTV or even through an upscaler, a momentary loss of sync could cause the display to blank for up to several seconds, potentially resulting in a game-ending bug.

Share this post


Link to post
Share on other sites

When I am testing on Stella, I always have the FPS info enabled, plus a conditional breakpoint which checks the scan lines.

  • Like 1

Share this post


Link to post
Share on other sites

^^It is possible some CRTs may be more sensitive to sporadic fluctuation in frame rate than others....g.

Yes. Experienced this with our DK Arcade 2600.

The first barrel screen is doing more than can be done in one frame. The barrel movement is split among frames. The scanlines and blanking were changed to allow more processing. It is at 270 scanlines and 58.22fps. Go non-standard signal!

 

With the hammer and hammer music going, it is as far as we can go. I'd love to have diagonal barrels and the chasing fireball!

 

I would have screen bounces on the RCA set.

The SONY WEGA set was rock solid.

 

And, unfortunately, 2 playfields are "drawn" from data, and that will blank out new sets and projectors.

 

If that ever goes to cart, we'll need a large disclaimer.

And there are plenty of bugs. The tiny elevator platforms are hard to program, and strange things happen (or death) when not centred.

 

Once on the girder level I jumped a fireball over a rivet and trapped it there in the space. (I think this can happen on the arcade game.) It vibrates back and forth. But then for some reason it got free, floated up to the top girder, but was moving along 2 pixels below the platform.

So strange things not programmed can happen.

  • Like 1

Share this post


Link to post
Share on other sites

^^It is possible some CRTs may be more sensitive to sporadic fluctuation in frame rate than others. I think every developer should be logging scanline counts in Stella because playing on the Harmony with a more tolerant CRT, they may not even notice a roll glitch that could effect other people's sets. Also playing on an HDTV or even through an upscaler, a momentary loss of sync could cause the display to blank for up to several seconds, potentially resulting in a game-ending bug.

I've never noticed screen roll with other games, but that could just be that I don't play any other games with the same issue. I can only say that I have no indications of a general electronics problem with the TV. It never was unstable when it was our main set and doesn't do anything goofy with any other 2600 games or O2 games.

 

I haven't been able to clearly identify any possible way to reproduce the issue since it's so sporadic. I almost never look at the city down at the bottom of the screen. It could even be related to the shield or buildings or something being hit.

Share this post


Link to post
Share on other sites

It would really help to know if it happens in the joystick version as well.

Share this post


Link to post
Share on other sites

It would really help to know if it happens in the joystick version as well.

I understand completely.

 

Since it didn't happen in the five games I reported on earlier, I will just have to try some more when I get time.

I'm not sure at what point I will have proven the negative in the original since it doesn't happen during every game in the TB version. But, I'll keep playing video games for the greater good.

 

If anyone else is interested in trying to reproduce the problem by playing the original joystick controlled Colony 7 version, that would be appreciated.

 

It might be helpful, though less direct, if a more observant person could reproduce the problem with the trackball version and report on the circumstances under which it occurs.

 

The screen roll always catches me off guard. The game requires a pretty large percentage of my focus. Other than activity possibly being clustered toward a corner of the screen I haven't been able to provide much other than "it works perfectly except for when it doesn't".

Share this post


Link to post
Share on other sites

I am looking forward to be able to purchase these trackball games eventually in the AA store. I hope you get the screen jerks smoothed out.

Me also. Whether it's a switch cart, an automatic Trak-Ball detecting cart if there is code space, or just the version I need.

PLUS there's 2600 Scramble and 2600 Xevious.

Al's Store needs helper elves to get something in the Store to spend our Spring Income Tax Refund money on!!

 

And then the new Pac-Man 4K Supercharger cassette, and/or Cartridge. And then the new Pac-Man 8K if adding speed to PacMan when cornering is added, that will be done.

post-29575-0-83520800-1458127427_thumb.jpg post-29575-0-00951300-1458127446_thumb.jpg

post-29575-0-71400500-1458127493_thumb.jpg

post-29575-0-53644100-1458127537_thumb.jpg

post-29575-0-17863900-1458127556_thumb.jpg

post-29575-0-86044400-1458127595_thumb.jpg

  • Like 2

Share this post


Link to post
Share on other sites

I'm curious. Have any of you played Colony 7 to any significant extent? I'm still seeing screen rolls as I mentioned a while back and was wondering if any of you are seeing it.

I played Colony 7 a bit today on real hardware (NTSC 0.3 cx80 version, difficulty set to "A") and I experienced a screen roll as well.

 

There's so much going on, that it 's really hard to mentally capture what's happening on the screen at the time of the glitch.

Same here, I couldn't really notice anything useful to help sorting out the bug.

 

I played some rounds in Stella as well and set a breakpoint ("breakif _scan==#263") to check if the scanlines count exceeds 262, but I had no luck in replicating the glitch.

Share this post


Link to post
Share on other sites

I played Colony 7 a bit today on real hardware (NTSC 0.3 cx80 version, difficulty set to "A") and I experienced a screen roll as well.

 

[...]

 

I played some rounds in Stella as well and set a breakpoint ("breakif _scan==#263") to check if the scanlines count exceeds 262, but I had no luck in replicating the glitch.

So, if I'm crazy at least I'm not alone. :)

 

Is that breakif being evaluated for every scan line?

Is there some way to detect the end of a frame and fire a break if the accumulated scan line count is less than 262? I assume that could throw off the TV's sync as well.

Share this post


Link to post
Share on other sites

Is there some way to detect the end of a frame and fire a break if the accumulated scan line count is less than 262? I assume that could throw off the TV's sync as well.

Not that I'm aware of. The pseudo-register "_scan" holds the current scanline count, so it's only possible to check if the count exceeds 262 at the moment. There's not a pseudo-register that holds the total scanline count of the last frame.

Share this post


Link to post
Share on other sites

I also just realized another potentially valuable piece of information. Since I started trying again, I have been unable to duplicate the glitch.

 

Alex's post made me start thinking about the version. I realized that I started trying to spot the cause of the glitch again only after I got my CX22.

 

All of my previous sightings of the gremlin were when I was using my hacked CX53 which means that I would have been running a "CX80" version of the program.

 

Thanks to Alex's detective work, there may be some hope of the programmer being able to track down the bug now.

Share this post


Link to post
Share on other sites

Not that I'm aware of. The pseudo-register "_scan" holds the current scanline count, so it's only possible to check if the count exceeds 262 at the moment. There's not a pseudo-register that holds the total scanline count of the last frame.

Well, your subsequent post showing that scanline count hit 263 means that I no longer care if it can detect a frame of less than 262 lines. :D

Share this post


Link to post
Share on other sites

After taking a look at the stella debugger documentation, I think that actually the _vsync pseudo-register can be used to check if a frame takes less scanlines than normal. In a 262 line frame VSYNC must be enabled for 3 scanlines starting from #259. So a conditional break like this

breakif { _vsync==#1 && _scan<#259 }

will trigger whenever VSYNC is enabled with a scanline count less than #259, that is if the frame is displaying less than 262 scanlines.

Edited by alex_79

Share this post


Link to post
Share on other sites

It would be easy enough to add a _scanEOF or some such pseudo-register that holds the number of scanlines in the last frame (hence the EOF). This information is already in the TIA class; it just needs to be exposed to the debugger.

Share this post


Link to post
Share on other sites

That would make the syntax a bit simpler. But more important would be a one-frame-undo (or at least beginning to current frame) when you hit a break point.

 

E.g. the save state above shows me the situation AFTER the bug has happened. This helps, but it would be much easier to find the bug, if Alex could have stepped back one frame and create a save state there.

Share this post


Link to post
Share on other sites

Yes, that falls under 'rewind functionality', which hasn't been added yet. There is a limited form of rewind, but it only starts recording while you're in the debugger and do step/trace/frame advance, etc, and only exists for that specific invocation of the debugger.

 

What we'd need for this use case is for the entire emulation to be doing recording while playing a game, and then when a breakpoint is triggered, there will be something to rewind to. That doesn't exist yet in Stella, but is (yet something else) on the TODO list.

Share this post


Link to post
Share on other sites

Yup, that's it.

 

Meanwhile I had a look to the save state. It helps a lot, because the problem is not inside the kernel, but a timer underflow below the display (only happening in NTSC version). By reducing the initial timer value a bit more, I was able to reproduce the bug.

 

Now I have to check how to fix this. I could increase that bottom timer a bit and decrease the top timer. But that would move the NTSC screen even more up. And it seems a bit off center already. Can someone please check the centering on real NTSC hardware?

Share this post


Link to post
Share on other sites

Here are fixed NTSC versions for CX-22 and CX-80. I tested the screen rolls and adjusted the code to fix the maximum timer overrun I found (184 cycles). And, in case there are even worse cases and the timer gets overrun again, I made the code a bit more robust. So the timer overruns become less annoying.

 

The whole screen moved up by 2 pixel. I hope this gives no problems on real hardware. It would be pretty bad if the score gets cut off. icon_smile.gif

Colony 7 - CX-22 Hack v0.4 (NTSC).bin

Colony 7 - CX-80 Hack v0.4 (NTSC).bin

  • Like 3

Share this post


Link to post
Share on other sites

Cool. I'll give it a try on real hardware as soon as I can.

 

I never sensed that the vertical centering on the previous versions was an issue. I'll specifically evaluate that in the new version on a couple of different CRT TV's just in case.

Share this post


Link to post
Share on other sites

Great.

 

I also have prepared some small improvements (more levels and scoring closer to arcade original) for this game, but I need Manuel's OK before I release that to public.

  • Like 1

Share this post


Link to post
Share on other sites

IDK but my CX-80 (acts like a CX-22) has gold dots under the buttons and they are nice. I'm not a big fan of dome contacts. They are hard and not very responsive. Why didn't Atari just use rubber/silicone membranes with carbon dots in their controllers like every other company?

 

I thought carbon dots were tried *first* on the 5200 joysticks along with the flex PCB and both turned out to be a disaster that doomed the 5200 to an early retirement. Dome contacts are used on the 5200 CX53 Trak-Ball Controller per Dan Kramer's dictates [and Atari Consumer management actually listened for a change].

Share this post


Link to post
Share on other sites

Hypothetical question here: What about using Amiga's code for their title screen launcher for some of their prototypes that allowed for multiple games on a single 2600 cartridge? Wouldn't that be more practical than relying on a hardware switch to be added to a cartridge in order to determine which TB version you want to play based upon the type of Trak-Ball/mouse you own?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...