+stephena Posted February 3, 2017 Author Share Posted February 3, 2017 Kid! Believe me, it doesn't feel like it. At least not over the past few months. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 14, 2017 Share Posted February 14, 2017 Maze Craze auto-detects as PAL. FPS appear to be off too. I suspect both are related to the VSYNC-less random maze generation when the game initializes. The prior version auto-detects as NTSC: Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 15, 2017 Share Posted February 15, 2017 (edited) I noticed it's intermittent 50% PAL detect, 50% NTSC detect. This in Windows build. Edited February 15, 2017 by Keatah Quote Link to comment Share on other sites More sharing options...
+Trebor Posted February 16, 2017 Share Posted February 16, 2017 Confirmed intermittent and unable to determine a particular pattern. For example, I've experienced twice in a row PAL, as well as 4 times in a row NTSC detection (Not in that particular order). Doesn't matter if I start a 'session' cold or continuously load the ROM. Tested with the attached ROM containing the following properties: CRC32: 0098E428 MD5: F825C538481F9A7A46D1E9BC06200AAF SHA-1: ABA25089D87CD6FEE8D206B880BAA5D938AAE255 Maze Craze (1978) (Atari).bin Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 16, 2017 Share Posted February 16, 2017 (edited) Bug report on this goes back to 2009.. http://atariage.com/forums/topic/150402-stella-30-released/?p=1886501 ..which reminds me, maybe the old reports could point to things long forgotten yet still needing attention. Edited February 16, 2017 by Keatah Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 16, 2017 Author Share Posted February 16, 2017 We may have to just add specific ROM properties for this one, instead of relying on autodetection. Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 16, 2017 Share Posted February 16, 2017 Nothing wrong in that. That's what the properties file is for, right? ..to cover rare or customized cases.. It's not like 500 roms are failing the same way. Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 16, 2017 Author Share Posted February 16, 2017 As for old bug reports, feel free to report them again if they (a) haven't already been fixed and (b) aren't already mentioned here. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 17, 2017 Share Posted February 17, 2017 Maze Craze auto-detects as PAL. FPS appear to be off too. I suspect both are related to the VSYNC-less random maze generation when the game initializes. I noticed it's intermittent 50% PAL detect, 50% NTSC detect. This in Windows build. Confirmed intermittent and unable to determine a particular pattern. For example, I've experienced twice in a row PAL, as well as 4 times in a row NTSC detection (Not in that particular order). Doesn't matter if I start a 'session' cold or continuously load the ROM. I still need to sit down and take a close look at what's going on there, but if a ROM takes a long time to settle onto a proper frame pattern, autodetection is fragile. The variance between different runs is a consequence of the randomness injected into the initial state (timers, registers etc.). I am afraid that this may well be a corner case for which adding ROM properties and moving on is the best option. Imho, autodetecting TV mode is not really in the domain of emulation, and as such I think it is best to find a sweet spot between accuracy and complexity instead of trying to cover all corner cases 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 17, 2017 Share Posted February 17, 2017 How should we handle games which are switchable between PAL and NTSC? A configuration will not help here. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 17, 2017 Share Posted February 17, 2017 (edited) How should we handle games which are switchable between PAL and NTSC? A configuration will not help here. Autodetecting mode changes at runtime would be a possibility, but I have a vague feeling that leaving both TV mode and frame start open for autodetect at runtime will prove to be too fragile to work well for all ROMs. I used to be more enthusastic about that, but after analyzing and fixing the the edge cases we have identified so far, I am afraid there'll be too many variables in the game. I think the current situation is not too bad: such ROMs runs in the mode that was preselected at startup, and if you want to run the other mode, you have to modify the configuration accordingly ,either via the launcher or via the command line. You can either adjust the console switches to immediately select the desired mode on startup, or you can set a fixed TV mode. That's arguably more hassle than dynamic autodetection, but still more comfortable than switching consoles and TV sets Edited February 17, 2017 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
+Trebor Posted February 17, 2017 Share Posted February 17, 2017 I think the current situation is not too bad: such ROMs runs in the mode that was preselected at startup, and if you want to run the other mode, you have to modify the configuration accordingly ,either via the launcher or via the command line. You can either adjust the console switches to immediately select the desired mode on startup, or you can set a fixed TV mode. That's arguably more hassle than dynamic autodetection, but still more comfortable than switching consoles and TV sets Could a command line option (I.E. -tv.region or -tv.mode <ntsc|pal|secam>) be added? Looking through the current options, such a selection does not appear to be available. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 17, 2017 Share Posted February 17, 2017 (edited) Could a command line option (I.E. -tv.region or -tv.mode <ntsc|pal|secam>) be added? Looking through the current options, such a selection does not appear to be available. It's already there, though slightly disguised as a 'debugging option' stella -format PAL Edited February 17, 2017 by DirtyHairy 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 17, 2017 Share Posted February 17, 2017 (edited) And you can switch while playing via hotkeys (CTRL+F). Edited February 17, 2017 by Thomas Jentzsch 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 17, 2017 Author Share Posted February 17, 2017 The Display.Format ROM property (accessible from the commandline with '-format') will do this. In fact, when I say we should make something use a specific format in ROM properties, I simply change "Display.Format" from 'Auto' to whatever type we want (NTSC, NTSC50, PAL, PAL60, SECAM, SECAM60). 2 Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 21, 2017 Author Share Posted February 21, 2017 Maze Craze (and other NTSC variants) now have an 'NTSC' setting, and do not do autodetection. Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 21, 2017 Share Posted February 21, 2017 Maze Craze (and other NTSC variants) now have an 'NTSC' setting, and do not do autodetection. Is that internal to the emulator or external in a file we can read/edit? Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 21, 2017 Author Share Posted February 21, 2017 It is internal initially, but if you make any changes to a ROM properties in the GUI it saves the properties to a file called stella.pro. So anything that is set internally can always be overridden by the user. EDIT: You can see the (very large) file used internally here. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 23, 2017 Share Posted February 23, 2017 On my lunch break I was taking a look at atari2600land's latest issue in Celery and had trouble getting started because the paddle detection code no longer works in 5.0. Celery supports both joystick and paddle, which controller is plugged in is detected when the console's powered up. The detection code is this: Reset CLEAN_START lda INPT0 ; DGS sta Controller ; DGS paddle if D7 = 1 after which a simple bit Controller is used to run joystick or paddle specific code. This works on hardware as well as in the prior version of Stella. celery50dgs.zip Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted February 23, 2017 Share Posted February 23, 2017 Absence of testers.. unless reports come flooding in that say I've tested! I've tested! I myself have run about 40 or so randomly chosen games in casual play. I have nothing to report. --- I really hate to say it but the novelty of emulation like we had in the 1990's, the magic of running your old games on the PC, has toned down these past years. Or so it would seem if you listen to the vocal minority. And yet, today, we have some of the best efforts and results to date. Many of today's emu's are viable console replacements - and them some - with all their side tricks and amenities. PC emulators picked up a stigma along the way of being hard to configure, not accurate, not fully compatible, "just off", frustrating, and in general not a nostalgic experience. And just "because PC." But that hasn't been true of the better ones for a long time. Yet, emulation is actually becoming a premier way to play the classics today. The tide is turning. In a sleeper kind of way. The advantages that emulation offers both consumer and corporation *are* becoming evident. But enough of this for now. It'll all be in a book I just started called Principia Emulata. Lol nice! The next step will be FPGA simulation. Funny I saw the thread title and thought Kevtis realeased a new core for Zimba NT Mini! Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 23, 2017 Share Posted February 23, 2017 (edited) The current state of FPGA emulation isn't that far enough along to equal Stella yet. Too bad the current devs aren't using the FPGA + CPU all-in-one combos. It will be interesting to see if FPGA can surpass software emulation. Especially in versatility. But this isn't the thread to discuss such a topic. Edited February 23, 2017 by Keatah Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 23, 2017 Author Share Posted February 23, 2017 On my lunch break I was taking a look at atari2600land's latest issue in Celery and had trouble getting started because the paddle detection code no longer works in 5.0. Celery supports both joystick and paddle, which controller is plugged in is detected when the console's powered up. The detection code is this: Reset CLEAN_START lda INPT0 ; DGS sta Controller ; DGS paddle if D7 = 1 after which a simple bit Controller is used to run joystick or paddle specific code. This works on hardware as well as in the prior version of Stella. celery50dgs.zip How were you able to test this in prior versions of Stella (where it worked), and now (where it doesn't)? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 24, 2017 Share Posted February 24, 2017 How were you able to test this in prior versions of Stella (where it worked), and now (where it doesn't)? Load the ROM, use the in-game menus to switch controllers to Paddles, then reload the ROM. Controller variable's in $9C. In 5.0 bit 7's off Bit 7's on in when run under the older versions. This is the one I still have on my system as my work on BUS Stuffing's in it. I don't recall what version of Stella I had installed when I wrote the detect code last July, but it was definitely older than 4.8_pre as I fetched that source on September 27th per the date stamp of the folder I created to hold the source. hmm... based on a hexdump of this screenshot, from a few days before the detect code, I was most likely using Stella 4.7.1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 24, 2017 Author Share Posted February 24, 2017 Confirmed, and issue created here. Quote Link to comment Share on other sites More sharing options...
Andromeda Stardust Posted February 24, 2017 Share Posted February 24, 2017 The current state of FPGA emulation isn't that far enough along to equal Stella yet. Too bad the current devs aren't using the FPGA + CPU all-in-one combos. It will be interesting to see if FPGA can surpass software emulation. Especially in versatility. But this isn't the thread to discuss such a topic. The ARM on the melody boards is too modern, but it can emulate good old cart bus. Don't toss your Harmony carts yet; you might still need them... 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.