Jump to content
IGNORED

Gopher2600 (continuing development on Github)


JetSetIlly

Recommended Posts

1 hour ago, r_chase said:

Hey-o, how's it going? Just checking in on the development of this emulator and stuff. Did you add the Joy2B+ stuff yet?

I've not had chance yet, sorry.

 

Just looking at the Joy2b+ project now though https://github.com/ascrnet/Joy2Bplus and there's a chance that it might already be (partially) supported.

 

I have 2-button support in the emulator already. I have an XBox360 pad that I use and games that support 2 buttons work fine. It's not clear to me how a Joy2b+ joystick is attached to the PC but it might already be detected. Have you tried it? If it works, I'll just need to add support for a third button.

 

 

 

 

  • Thanks 1
Link to comment
Share on other sites

8 minutes ago, JetSetIlly said:

I've not had chance yet, sorry.

 

Just looking at the Joy2b+ project now though https://github.com/ascrnet/Joy2Bplus and there's a chance that it might already be (partially) supported.

 

I have 2-button support in the emulator already. I have an XBox360 pad that I use and games that support 2 buttons work fine. It's not clear to me how a Joy2b+ joystick is attached to the PC but it might already be detected. Have you tried it? If it works, I'll just need to add support for a third button.

 

 

 

 

I have tried the Xbox 360 controller and it does work. So, maybe a third button would be needed indeed. Thanks for your quick response.

Link to comment
Share on other sites

v0.20.0 of Gopher2600. I've sat on some of these new features for a long time and sometimes we need a milestone to encourage ourselves along.

 

https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.20.0

 

The big change in this version is better debugging for ARM cartridges. It's now possible to add breakpoints to the C code and to inspect local variables. This was very difficult to do correctly. Hopefully, I've worked out the major bugs but there are bound to be some left.

 

I won't go into too much detail - I'll leave that for a future document. In the meantime, here's a screenshot of the @SpiceWare CDFJ demo project, "Collect3", as seen through the Gopher2600 debugger

  • The source code window now includes breakpoint information in addition to performance information
  • The new local variables window shows the local variables that are in scope at the current execution point

image.thumb.png.a3223e4e90e78dee00ef04a401b4c3c2.png

 

Adapting existing CDFJ and DPC+ projects for the new debugger is very easy. A new page on the Gopher2600 wiki explains the process:

 

https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Preparing-ARM-Enabled-Projects-for-the-Gopher2600-Debugger

 

As well as CDFJ and DPC+, all aspects of Gopher2600 now support the new ELF and ACE formats. The ACE format still needs work but many ACE ROMs do work well (albeit very slowly 🙂) Thanks to @ZackAttack @MarcoJ and @Al_Nafuur for help with this.

 

As part of the work on ELF and ACE, I have also implemented the Thumb-2 instruction set. This extended instruction set is found in modern ARM CPUs, such as those found in the UnoCart and PlusCart. There will be some instructions that I haven't implemented yet but the all the major instructions are present. The upshot of this is that ELF and ACE projects can be compiled for ARMv7 if required.

 

 

Away from the ARM side of things, there are a few new features. The notable ones:

  • Implementation of the Wickstead Design bankswitching format and support for very small Atari cartridges (1k etc.)
  • Better stereo effect. The new method preserves some of the distortion that can be heard in the mono mix that emulates the hardware
  • Better indication of scanline jitter on the timeline window. Screenshot below taken of the infamous Snow White ROM, which jitters like crazy.

image.thumb.png.3ccdcd4d3c5c0d9f3b35448fd73f793e.png

  • For terminal users, some new commands have been added to support the new debugging features. For instance, "DWARF LOCALS DERIVATION" will explain the how the locations of the current local variable were derived. Useful for some people.
  • I've also added better emulation of how the PlusCart sends data over the network. The hardware PlusCart sends data relatively slowly which means it's possible for data to be corrupted before it's actually sent. It is now possible for a running game to corrupt this data in the same way.

And bug fixes of course:

  • An obscure bug in audio generation was fixed. Remarkably, this bug was related to RSYNC. Entirely my fault and an interesting one to think about.
  • A small mistake in the RIOT address bus mask, causing some games to fail when reading the Timer (for example the original Lock'n'Chase from MNetwork)
  • and many more I'm sure I've forgotten about (but everything is in the git log for the interested)

 

 

 

 

 

 

Edited by JetSetIlly
  • Like 5
  • Thanks 3
Link to comment
Share on other sites

  • 1 month later...

https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.21.0

 

The most significant change in this version is a 13% to 18% increase in performance (measured by uncapped framerate).

 

Also significant but maybe less noticeable is improved scaling of the TV image. In earlier versions, the image was sub-obtimal when scaled to non-integer scaling values, resulting in visible artifacts in many ROMs, particularly those with flickering displays.

 

Preliminary support for the Stelladaptor has been added. As I don't have a Stelladaptor, this was done with the guidance of @SpiceWare Note that only Joystick and Paddle are supported for now. Driving controllers aren't yet supported by the emulation at all.

 

The debugger can now magnify the TV screen. This can be seen either as part of the popup window under the mouse or as a separate window. This is very much a work in progress so what we see here is a first sketch.

 

image.thumb.png.dbbf92e131a86c1398fb065ec7b6d845.png

 

There are several bug fixes but the most important one is the correct calculation of the Call Frame Address with respect to ARM programs. This improves the reliability of local variable inspection.

 

 

 

 

 

 

 

  • Like 8
  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

I gave this emulator another try today.  I like how I can just start it and load a ROM via the GUI now.  The GUI still needs a bit of work though... the only way I could find to edit the CRT preferences was by having the debugger view open.... and then exiting that to see the results.  Is there a reason why the menu isn't shown / easily accessible from the regular emulation view?

 

I ran Paint The City as a test and there seems to be some strange artifacts with the right most playfield pixel column and the last line of the bottom road section.  Also, it just barely fits on the screen... is there an option to change the number of scanlines visible?

 

The emulator seems to work relatively well performance-wise, but does have the occasional stutter..  I did notice that the emulator seems to struggle with performance when the mouse cursor is moving over it, which seems a bit odd.

Link to comment
Share on other sites

4 minutes ago, splendidnut said:

I gave this emulator another try today.

Thanks for taking another look, it's changed significantly since you last commented.

 

4 minutes ago, splendidnut said:

I like how I can just start it and load a ROM via the GUI now.  The GUI still needs a bit of work though...

Do you mean the GUI for the ROM selector? If so, I agree. I've not done much work on it at all really. I'll revisit that part of the project this weekend I think. Do you have any suggestions for improvements?

 

4 minutes ago, splendidnut said:

 

the only way I could find to edit the CRT preferences was by having the debugger view open.... and then exiting that to see the results.  Is there a reason why the menu isn't shown / easily accessible from the regular emulation view?

 

The Preferences window can be opened with F10 when in playmode (regular emulation mode)

 

The full list of hotkeys is on the project's GitHub wiki. https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Hotkeys

 

4 minutes ago, splendidnut said:

 

I ran Paint The City as a test and there seems to be some strange artifacts with the right most playfield pixel column and the last line of the bottom road section.

 

I'm trying PaintTheCity NTSC 20220224 and I can't see any real differences between the Stella and Gopher2600 emulations.

image.thumb.png.e52149bd60dba089e413033a8cdb5d74.png

 

Can you highlight the areas where you see the artifacts?

 

4 minutes ago, splendidnut said:

Also, it just barely fits on the screen... is there an option to change the number of scanlines visible?

There isn't. However, in the debugger, you can "uncrop" the screen. This shows how the screen fits into the wider TV frame. The gray dotted lines indicate the top and bottom VBLANK areas and when HBLANK is turned off. The purple dotted line is the most recent VSYNC scanline.

 

image.thumb.png.3639fd52c4968764a1fbbde4caa2ce82.png

 

4 minutes ago, splendidnut said:

I did notice that the emulator seems to struggle with performance when the mouse cursor is moving over it, which seems a bit odd.

It's hard to comment on that because I don't see that effect here and nobody else has noticed it. I'll note it down as an issue though.

 

Out of interest, what specification is your computer's hardware?

 

Link to comment
Share on other sites

36 minutes ago, JetSetIlly said:

Do you mean the GUI for the ROM selector? If so, I agree. I've not done much work on it at all really. I'll revisit that part of the project this weekend I think. Do you have any suggestions for improvements?

ROM selector is fine.  It would be nice to be able to access things from a main menu; the debugger has it but it doesn't show for regular emulation mode.  When in emulation mode, the Tab key shows the ROM selector, but it would be nice if it showed the menu instead of or in addition to.

34 minutes ago, JetSetIlly said:

Out of interest, what specification is your computer's hardware?

Intel Core i5-4570 @ 3.2ghz with an Nvidia Geforce GT 1030 running Windows 7.  The issue with the mouse cursor is probably tied into how your program handles the Windows Event loop.  I'm guessing MouseMove events are piling up and overwhelming the event processing code.

Link to comment
Share on other sites

1 minute ago, splendidnut said:

ROM selector is fine.  It would be nice to be able to access things from a main menu; the debugger has it but it doesn't show for regular emulation mode.  When in emulation mode, the Tab key shows the ROM selector, but it would be nice if it showed the menu instead of or in addition to.

Interesting idea. I'll play around with it this weekend

 

1 minute ago, splendidnut said:

The issue with the mouse cursor is probably tied into how your program handles the Windows Event loop.  I'm guessing MouseMove events are piling up and overwhelming the event processing code.

 

Maybe. I don't have the issue here but I'm not using Windows and don't have access to it. I'll take another look at it though.

 

17 minutes ago, splendidnut said:

Here's a screenshot trying to capture the artifacting:

image.thumb.png.002c513200e15022c1d61a421caf90b4.png

 

I can see it. Very strange. Does this only happen with CRT effects enabled?

 

Link to comment
Share on other sites

5 minutes ago, JetSetIlly said:

I can see it. Very strange. Does this only happen with CRT effects enabled?

Yes, so maybe the framebuffer needs to be larger to hide the artifacts for those effects.

 

6 minutes ago, JetSetIlly said:

Maybe. I don't have the issue here but I'm not using Windows and don't have access to it. I'll take another look at it though.

 

I played around a bit and for some reason, turning OFF vsync (switch to Immediate Updates) fixes the issue and decreases CPU usage.

Link to comment
Share on other sites

7 minutes ago, splendidnut said:

Yes, so maybe the framebuffer needs to be larger to hide the artifacts for those effects.

Hmm. Maybe. I'll look into it.

7 minutes ago, splendidnut said:

I played around a bit and for some reason, turning OFF vsync (switch to Immediate Updates) fixes the issue and decreases CPU usage.

Interesting. VSYNC is something I've struggled to get working well in all instances if I'm to be honest, so there might be a clue here.

 

What's your monitor's refresh rate?

 

 

@Dionoid does setting VSYNC to "immediate updates" solve your problem?

 

image.png.c932cf3bcbb2d9ec120f6775fed55b00.png

 

Edited by JetSetIlly
Link to comment
Share on other sites

15 minutes ago, splendidnut said:

My refresh rate is set to 75hz.  So yeah, there's probably quite a fight going on trying to keep things in sync when VSync is turned on.

I usually run with a 60Hz refresh rate because that works best with NTSC ROMs with flicker ROMs. But I've just tried with a 75Hz refresh rate and it seems to run okay. Turning VSYNC off causes CPU usage to actually go up. So there's definitely a difference between how Linux and Windows are treating the display.

 

It's something to think about.

Edited by JetSetIlly
Link to comment
Share on other sites

On 3/23/2023 at 10:15 PM, JetSetIlly said:

@Dionoid does setting VSYNC to "immediate updates" solve your problem?

Immediate updates make a big difference, and it seems the speed is very close to running on an actual Atari 2600. However it seems to skip frames a few times a second.

But yes, much better on my Windows machine.

Link to comment
Share on other sites

Just now, Dionoid said:

Immediate updates make a big difference, and it seems the speed is very close to running on an actual Atari 2600. However it seems to skip frames a few times a second.

But yes, much better on my Windows machine.

 

Thanks. I need to setup a Windows machine so I can investigate this further. It seems both you and @splendidnut have similar issues. Ideally you'd be running with VSYNC enabled.

 

@johnnywc@Al_Nafuur have you noticed this issue on your Windows machines?

 

Link to comment
Share on other sites

40 minutes ago, JetSetIlly said:

What is performance like when VSYNC is enabled and the emulation is in full-screen mode? Full-screen mode can be toggled with F11.

I did some more testing and found that "Sync with vertical retrace" actually gives me the smoothest emulation, and seems to be pretty close to the real thing. The sound still stutters sometimes, and switching to full-screen mode doesn't solve that. So full-screen seems to give me similar performance as running in a window. 

And the performance in debug mode also got a boost since the latest version of Gopher!! Nice!

Link to comment
Share on other sites

1 hour ago, JetSetIlly said:

What is performance like when VSYNC is enabled and the emulation is in full-screen mode?

Same for me.  Which is to be expected because I don't see anywhere to set the video resolution / refresh rate for full screen mode within Gopher.  So that means that Full-screen mode is basically the same as Full-sized Window mode.

 

As for the actual performance numbers:  30-35% CPU usage with VYSNC on (CPU fan spins up),  10-15% with it off (CPU fan stays quiet).

Link to comment
Share on other sites

26 minutes ago, splendidnut said:

Same for me.  Which is to be expected because I don't see anywhere to set the video resolution / refresh rate for full screen mode within Gopher.  So that means that Full-screen mode is basically the same as Full-sized Window mode.

Correct. Full screen mode in this case is SDL's FULLSCREEN_DESKTOP which is really just a borderless window.

 

Link to comment
Share on other sites

4 hours ago, Gemintronic said:

Any chance input macro support is bring considered?  Right now I'm testing procedural dungeon creation and I have to manually take 128 screenshots.  If I could toggle turbo mode, move with the joystick and trigger a screenshot with a script/macro I'd be in heaven :)

Nice idea!

 

One thing I have in place is a way of recording input and being able to play it back, testing the integrity of the emulation as it proceeds. I developed it so I could experiment with the emulation and to make sure that I didn't break any previously working ROMs. It's not quite suited to your needs but I'm sure I can adapt the system so that it will.

 

I'll play around with it this weekend and see what I can do.

 

I'll probably come back to you with questions about what you need.

  • Like 1
  • Thanks 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...