JetSetIlly
-
Posts
763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by JetSetIlly
-
-
7 minutes ago, Thomas Jentzsch said:
There seems to be a problem with cart RAM access. The green underground "barriers" shouldn't be there.
But only the low 3 bits of the playfield are affected. The data (all 8 bits) is loaded from cart RAM, pushed onto the stack and loaded from there for display.
The icon after the HiScore value on the menu screen doesn't like correct either.
-
1
-
-
15 hours ago, SpiceWare said:
I recently bought a Mac Studio to replace the Mac Pro I bought in 2014. It's the stock M2 Ultra version:
It runs, but when run in a window with just the CRT output the screen updates are not very good
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
-
1
-
-
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)-
1
-
-
3 hours ago, SpiceWare said:
I recently bought a Mac Studio to replace the Mac Pro I bought in 2014. It's the stock M2 Ultra version:
After migrating from the Pro I uninstalled/reinstalled brew, which updated the Go compiler for Apple Silicon. I then got the latest source for Gopher2600 (as of the 14th), and built an Apple Silicon version.
It runs, but when run in a window with just the CRT output the screen updates are not very good. With flicker set to the default 2 the bricks in the reflective walls often appear stationary instead of flickering between the 2 positions. Flicker rate of 2 means draw the bricks in one position for 2 frames, then draw them in the other position for 2 frames, so 2-3 consecutive frames are being skipped whenever the reflective walls appear stationary.
@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?
-
1 hour ago, SpiceWare said:
Mac shows both monitor refresh rates are 60 Hz, which I confirmed via monitor's OSD.
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.
-
1
-
-
9 minutes ago, SpiceWare said:
Wonder if another version of SDL might still be on my system somewhere... Doesn't look like Gopher's log outputs the SDL version, just OpenGL version:
I've pushed an update so that the SDL version is logged.
What's the refresh rate of your monitor?
-
1
-
-
1 minute ago, SpiceWare said:
Wasn't familiar with that option in Stella - sure enough, it was turned on. Turning it off fixed what I was seeing, thanks!
I recently bought a Mac Studio to replace the Mac Pro I bought in 2014. It's the stock M2 Ultra version:
After migrating from the Pro I uninstalled/reinstalled brew, which updated the Go compiler for Apple Silicon. I then got the latest source for Gopher2600 (as of the 14th), and built an Apple Silicon version.
It runs, but when run in a window with just the CRT output the screen updates are not very good. With flicker set to the default 2 the bricks in the reflective walls often appear stationary instead of flickering between the 2 positions. Flicker rate of 2 means draw the bricks in one position for 2 frames, then draw them in the other position for 2 frames, so 2-3 consecutive frames are being skipped whenever the reflective walls appear stationary.
When I run in the debugger the screen the walls flicker as expected. If I set the flicker rate to 1 the walls usually flicker as expected, with only occasional frames getting skipped.
Any ideas why CRT view by itself would refresh the screen so poorly compared to having the full debug environment showing?
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
-
2
-
-
5 hours ago, SpiceWare said:
Anybody else seeing this difference between real hardware and Stella?
I'm not. In Stella, the humanoid remains stationary for as long as the fire is being held.
-
1
-
-
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.
-
1
-
-
6 hours ago, batari said:
But if you don't want to dump the cart, at least you could cache known ROM data if you knew it was ROM, and would not need to fetch from ROM every single cycle. That could provide the speed boost you need and allow for more time for when you really have to interact with the cart.
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.
-
1
-
-
1 minute ago, Thomas Jentzsch said:
I guess it shows the age of Stella. And why should be want to change it?
Indeed. You wouldn't want to change it. M4 is pretty good.
-
3 minutes ago, Thomas Jentzsch said:
I think the core emulation does that:
https://github.com/stella-emu/stella/blob/master/src/emucore/M6502.m4
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!
Secondly, another video of Zack's raycaster demo. I've uncapped the framerate to show the performance improvement.
In both cases, the emulator is fighting for CPU time with the video encoder so performance is actually a little better in reality.
-
5
-
1
-
-
6 minutes ago, Al_Nafuur said:
Proposals for a project name:
Stella+
-
3
-
3
-
-
5 hours ago, Al_Nafuur said:
I am currently working on a new project which is in an early WIP/PoC phase ( I even haven't come up with a name for the project)
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
-
1
-
1
-
-
1 minute ago, Thomas Jentzsch said:
For many years, I never bothered with any licensing. I guess I wouldn't even have started this hobby with all the lawyers around like today.
Over the years I have learned that licenses are required because there is significant money in our hobby now. But I can't say I like them and I am mostly not interested.
Fair. It's an unfortunate aspect of the software development scene.
-
4
-
-
12 minutes ago, DirtyHairy said:
This is not true. Changing the license requires explicit permission permission from everybody who has contributed to the codebase, or removal of those pieces. With a project with a history so long as Stella's, this is simply not realistically possible.
9 minutes ago, Thomas Jentzsch said:Even if we wanted to (which is not the case at all), changing the license like you describe, is very close to impossible. Numerous people ave contributed to Stella under its current license. They all would have to agree to change it. This is never going to happen. Stella is a group effort.
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.
-
2
-
-
1 minute ago, Nall3k said:
This, 100%. You can’t put something as free to use in the public domain and then turn around and demand or expect payment.
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.
-
6
-
2
-
-
1 minute ago, Thomas Jentzsch said:
We know.
I stand corrected on that point 🙂
-
16 minutes ago, M-S said:
They took it for free, because it is for free. If you wanted to make your own emulation box with Stella the only requirement is to post the source code if you make any changes to the original. Of course there are unwritten rules like "Give a mention to the creator" but they aren't required.
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.
-
5
-
-
34 minutes ago, desiv said:
I would think that legally, anything that is "arguably a requirement" means it is almost definitely not a legal requirement.
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.
-
3
-
1
-
-
1 minute ago, DirtyHairy said:
Afaik this is only the case for GPLv3, and Stella is GPLv2.
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.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Frantic (2600)
in Homebrew Discussion
Posted
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.