JetSetIlly

Yes. If you click on the function name it'll open up another tab in the profiling window listing the most expensive source lines in that function. If you click on the source line, it'll open up the source window itself so you can see the line in context. You can set breakpoints on a source line from the source window. If execution is halted at a breakpoint, the local variables window will show the current variables as best as it can * * because you're most likely compiling with optimisations enabled, local variables and breakpoints might not always work exactly as you would expect. But that's standard advice for debuggers and optimising compilers, nothing really specific to Gopher2600. I doubt you'd be calling memset() anywhere yourself directly. It's most likely a byproduct of the compilation/linking process. A good enhancement to Gopher2600 would be the construction of a call graph to illustrate how the functions fit together.

The icon after the HiScore value on the menu screen doesn't like correct either.

It's just been confirmed to me that this issue [in gopher2600] is OS related. A Mac with an older version of the OS was fine and is now no longer fine after the upgrade to 13.5.2 Ongoing discussion on the Apple forums: https://discussions.apple.com/thread/254744079

At the bottom of one the copies of the "Stella Programmer's Guide" on the Internet, there's an additional page dealing with PAL/SECAM conversions. At the very bottom of this page it says: "PAL sounds works fine on SECAM with one exception: when a sound is to be turned off, it must be done by setting AUDV0/AUDV1 to 0, not by setting AUDC0/AUDC1 to 0. Otherwise, you get an obnoxious background sound". Has there been any research done on this? Any ideas how the "obnoxious background sound" might sound? (I don't have a SECAM 2600 here)

@Andrew Davie have you upgraded to macOS Ventura 13.5.2 yet? Have you seen a difference in the VSYNC affecting flickering displays when running Gopher2600?

I'm reading that to mean that you have two monitors attached to the Mac. It's a long shot but it might be that although they're both 60Hz, they're not syncing at the same time and the OpenGL window is taking it's VSYNC from the other monitor. Can you move the window to the other monitor? How about disabling one of the monitors? Are they both DisplayLink devices? (I used to run two monitors here and it caused similar issues but in my case, the monitors were running at different refresh rates)

Thanks. I'll have to think about this.

I've pushed an update so that the SDL version is logged. What's the refresh rate of your monitor?

It's a VSYNC issue. First thing to check is the OpenGL Swap Interval settings. F10 brings up the preferences window and it's in the Playmode tab in the OpenGL Settings section. You might have a stale setting in the gopher2600 preferences file. I tend to run with the Ticker option but "Sync with vertical retrace" is good if the monitor refresh is close to the TV refresh The other thing to check is the version of SDL you're compiling against. MacOS changed how they handled VSYNC a couple of OS versions ago and it was something that plagued other SDL programs until SDL made a change that fixed it. I did a bunch of this research with @AndrewDavie helping on the MacOS side of things. I can dig out the references and SDL github issues if you're interested.

I can replicate something like what you're describing by having autofire enabled at a rate of 1Hz

I'm not. In Stella, the humanoid remains stationary for as long as the fire is being held.

This is probably a very dumb question but I assume the "2600 Cartridge Port" is literally just a port cannibalized from a real 2600, or am I mistaken? Which model of 2600 is the most suitable donor / easiest to remove? Or are they all the same.

This technique wouldn't work for the newer ELF ROMs. In these ROMs, the data returned is potentially completely dynamic. i.e. the byte returned for a given cartridge address can be different on every access.

Indeed. You wouldn't want to change it. M4 is pretty good.

Holy smokes! I didn't realise Stella used m4. Not seen that since Sendmail was all the rage.

v0.25.0 of Gopher2600. Full change log on the release page: https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.25.0 Main improvement in this version is the implementation of the ARM FPU. This was added to support @MarcoJ's RPG game, Lords of Biscay. Secondly, with significant encouragement from @ZackAttack, I've managed to improve the performance for ELF ROMs that use the StrongARM functions. About 30% improvement in some cases. There's more work to be done in this area and hopefully will translate to performance improvements for ACE ROMs and quite possibly, CDFJ too. I've attached two videos. The first is another video of Zack's Wushu Masters. I've left the FPS window open in this video so you can see there's still room for improvment. More significantly perhaps, the video shows the game's different arenas! wushumasters.mp4 Secondly, another video of Zack's raycaster demo. I've uncapped the framerate to show the performance improvement. simplescreenrecorder-2023-09-13_20.57.45.mp4 In both cases, the emulator is fighting for CPU time with the video encoder so performance is actually a little better in reality.

Stella+

Excellent work. I was thinking about something like this last week during all the talk of the limitations of cartridge dumpers. It'll be interesting to get Gopher2600 working in a similar manner. Well done! I'm looking forward to seeing it in action. Meanwhile, if you need any help with anything I'm happy to help

Fair. It's an unfortunate aspect of the software development scene.

It's far too late now but one thing you could have done is change the licence to GPL v3. The project's Copyright.txt file says it be modified and distributed using "version 2 of the license, or any later version" . The change doesn't require agreement from previous contributors as they've already implicitly agreed with that. But of course, you might be happy without the anti-Tivoisation clause that was added in v3. It's nothing to do with me really but I'd prefer it if the 2600+ was user upgradable. IMO, that would make a potentially good product into something great.

Small point of correction but it's important. Stella isn't in the public domain. It's copyrighted and licenced under the GNU GPL v2.

I stand corrected on that point 🙂

The licence requires that the consumer be informed that software has been licenced under the GPL and therefore notification of the underlying copyright. It therefore *does* require that they give mention the creator in some way. It doesn't have to be on the box or anything like that but they do have to include or reference the licence somewhere. The underlying point though is that Atari are trying to curry favour with fans of the 2600. Alienating the Stella developers, regardless of any legal obligations, is a very strange way of doing that. Of course, we don't know if they are using Stella but I'd be very surprised if they're not.

It's not been tested in court and so is not settled law. It can be argued by lawyers as being a requirement. But it's a fringe opinion and not one I hold necessarily, the GPLv3 is explicit about the requirement for this reason.

The GPLv3 makes the requirement explicit but it is arguably a requirement of GPLv2 too https://sfconservancy.org/blog/2021/jul/23/tivoization-and-the-gpl-right-to-install/ but opinions differ on this.