Andromeda Stardust Posted March 14, 2016 Share Posted March 14, 2016 ^^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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 14, 2016 Share Posted March 14, 2016 When I am testing on Stella, I always have the FPS info enabled, plus a conditional breakpoint which checks the scan lines. 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 15, 2016 Share Posted March 15, 2016 ^^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. 1 Quote Link to comment Share on other sites More sharing options...
BigO Posted March 15, 2016 Share Posted March 15, 2016 ^^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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 15, 2016 Share Posted March 15, 2016 It would really help to know if it happens in the joystick version as well. Quote Link to comment Share on other sites More sharing options...
BigO Posted March 15, 2016 Share Posted March 15, 2016 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". Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted March 16, 2016 Share Posted March 16, 2016 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 16, 2016 Share Posted March 16, 2016 Before I release something, I always eliminate all known bugs. 2 Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 16, 2016 Share Posted March 16, 2016 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. 2 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted March 30, 2016 Share Posted March 30, 2016 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. Quote Link to comment Share on other sites More sharing options...
BigO Posted March 30, 2016 Share Posted March 30, 2016 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. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted March 30, 2016 Share Posted March 30, 2016 ...I had no luck in replicating the glitch. I take that back: savestate.zip 1 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted March 30, 2016 Share Posted March 30, 2016 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. Quote Link to comment Share on other sites More sharing options...
BigO Posted March 30, 2016 Share Posted March 30, 2016 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. Quote Link to comment Share on other sites More sharing options...
BigO Posted March 30, 2016 Share Posted March 30, 2016 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. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted March 30, 2016 Share Posted March 30, 2016 (edited) 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 March 30, 2016 by alex_79 Quote Link to comment Share on other sites More sharing options...
+stephena Posted March 31, 2016 Share Posted March 31, 2016 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 31, 2016 Share Posted March 31, 2016 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted March 31, 2016 Share Posted March 31, 2016 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 31, 2016 Share Posted March 31, 2016 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? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 1, 2016 Share Posted April 1, 2016 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. Colony 7 - CX-22 Hack v0.4 (NTSC).bin Colony 7 - CX-80 Hack v0.4 (NTSC).bin 3 Quote Link to comment Share on other sites More sharing options...
BigO Posted April 1, 2016 Share Posted April 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 1, 2016 Share Posted April 1, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
Lynxpro Posted April 1, 2016 Share Posted April 1, 2016 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]. Quote Link to comment Share on other sites More sharing options...
Lynxpro Posted April 1, 2016 Share Posted April 1, 2016 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? Quote Link to comment Share on other sites More sharing options...
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.