Stella 6.6 released

[Thomas Jentzsch]

2 hours ago, Rodney Hester said:

it's interesting that it's game-specific!

That's because of how the paddles work. The paddle range which is used for the screen position varies between games. And that means, the deadzone position varies too. It can be even outside the visible area and then you will not notice it.

[+sramirez2008]

Donation sent!  Recently purchased an Atari VCS 800, added Windows 10 (via external SSD drive) and downloaded the latest version of Stella.  For me, Stella makes this microconsole worth having...at the current price of course.  Many thanks to everyone involved with Stella.? 

[Keatah]

Yes Stella's gotta be a real shitkicker here. Round it out with Altirra for 8-bit support. And MAME for early arcade classics and 7800 compatibility.

[Rodney Hester]

Prior to testing the R77 development branch deadzone changes, I wanted to get a feel for how paddles behave with the 2600-daptor D9 on the existing public build.

 

I set analog paddle sensitivity to 83% (saw that recommendation somewhere), left all other settings at default and tried Breakout.  I'm *not* seeing any hesitation or 'stopping point' at the _left_ of the screen (on NTSC), only dead-center of the screen.

 

I also tried Super Breakout, and saw the same thing (an apparently deadzone right in the center), which suggests to me that what I'm seeing is *not* the "Linux deadzone" problem.

 

What is it, and how do I get rid of it?

[Rodney Hester]

Strange - I can't edit my prior post.

 

I've done more testing, and came to the conclusions (regarding Breakout with D9+paddles on R77):

 

- 6.5.3 has the deadzone nearly all the way to the left

- Somewhere in the 6.6 development cycle, it moved to the center, but otherwise behaves exactly the same

- The very current build of Stella 6.6 for R77 (with the second+third attempted deadzone fix) has no effect

- The very current build of Stella git for R77 (with the same fixes) also has no effect (but hides extensions by default, yay! not a fan of the Atari logo so prominent next to each entry though...)

 

Rodney

 

[Capt Moore]

1 hour ago, Rodney Hester said:

Strange - I can't edit my prior post.

 

I've done more testing, and came to the conclusions (regarding Breakout with D9+paddles on R77):

 

- 6.5.3 has the deadzone nearly all the way to the left

- Somewhere in the 6.6 development cycle, it moved to the center, but otherwise behaves exactly the same

- The very current build of Stella 6.6 for R77 (with the second+third attempted deadzone fix) has no effect

- The very current build of Stella git for R77 (with the same fixes) also has no effect (but hides extensions by default, yay! not a fan of the Atari logo so prominent next to each entry though...)

 

Rodney

 

Darn. I was really hoping this was an easy fix.  Hopefully someone can figure out what is going on with the “sticky” paddle/deadzone issue.

 

If/when the new version is released, I will try it for myself anyway. 

[Thomas Jentzsch]

2 hours ago, Rodney Hester said:

- Somewhere in the 6.6 development cycle, it moved to the center, but otherwise behaves exactly the same

Yes, we changed it so that the center is about the middle of the screen. This helps with self centering controllers.

Quote

- The very current build of Stella 6.6 for R77 (with the second+third attempted deadzone fix) has no effect

Yup, that's why there is no official release yet. Still working on it...

Quote

- The very current build of Stella git for R77 (with the same fixes) also has no effect (but hides extensions by default, yay! not a fan of the Atari logo so prominent next to each entry though...)

That's WIP for 6.7, glad you like it so far. The icons are meant replace the extensions. The icons are useful, they describe the type of the file. E.g. when all type of files are displayed and also for zip-files containing more than one valid ROM.

Edited November 27, 2021 by Thomas Jentzsch

[Capt Moore]

1 hour ago, Thomas Jentzsch said:

Yes, we changed it so that the center is about the middle of the screen. This helps with self centering controllers.

Yup, that's why there is no official release yet. Still working on it...

That's WIP for 6.7, glad you like it so far. The icons are meant replace the extensions. The icons are useful, they describe the type of the file. E.g. when all type of files are displayed and also for zip-files containing more than one valid ROM.

Thanks for the update.

[+Al_Nafuur]

Is there a way to see that the ROM is using PlusROM functions?

 

[Thomas Jentzsch]

37 minutes ago, Al_Nafuur said:

Is there a way to see that the ROM is using PlusROM functions?

There can be message displayed whenever the ROM communicates. See Developer settings/Emulation/Display external access message (didn't find a better wording which combines SaveKey/AVox and PlusROM communication).

Edited November 27, 2021 by Thomas Jentzsch

[+Al_Nafuur]

47 minutes ago, Thomas Jentzsch said:

There can be message displayed whenever the ROM communicates. See Developer settings/Emulation/Display external access message (didn't find a better wording which combines SaveKey/AVox and PlusROM communication).

?

 

My question wasn't clear. I meant the information that it has been detected by the emulator that the ROM is a PlusROM enabled ROM.

 

e.g. the information gopher2600 shows in his debug screen:

 

In Stella these Informations could be shown in the debuggers "Cartridge" tab or in a additional tab:

[Thomas Jentzsch]

41 minutes ago, Al_Nafuur said:

I meant the information that it has been detected by the emulator that the ROM is a PlusROM enabled ROM.

No, that's not there. I suppose we could add it.

[Rodney Hester]

13 hours ago, Thomas Jentzsch said:

Yup, that's why there is no official release yet. Still working on it...

No worries or hurry, just wanted to provide testing feedback in case it was useful.  If you can easily reproduce on your end, no problem

[Dionoid]

Hi Stella team, thanks for this new release! The new ARM timing features look very useful.

 

I noticed that the official Debian package is still on version 6.5.2 (see https://packages.debian.org/bullseye/stella).

As I'm running AArch64/ARM64 on my development machine, using the official Debian build is the way to get Stella on that machine (other than building Stella from the sources myself). 

Maybe you want to contact the Debian package maintainer to update Stella to the latest version?

Edited November 29, 2021 by Dionoid

[Thomas Jentzsch]

3 hours ago, Dionoid said:

Maybe you want to contact the Debian package maintainer to update Stella to the latest version?

No clue how to do that. Why don't you contact him yourself?

[Dionoid]

1 hour ago, Thomas Jentzsch said:

No clue how to do that. Why don't you contact him yourself?

I realize you are right and I can contact them myself. I'll do that right away!

 

[Edit: Turns out that Stephen Kitt (a Debian maintainer) is already testing Stella version 6.6, see https://qa.debian.org/cgi-bin/watch?pkg=stella]

Edited November 29, 2021 by Dionoid

[Keatah]

On 11/16/2021 at 3:55 PM, stephena said:

Debugger: added Thumb cycle counting.

Would this affect gameplay/accuracy? Or is it confined to debugger usage?

[Thomas Jentzsch]

9 minutes ago, Keatah said:

Would this affect gameplay/accuracy? Or is it confined to debugger usage?

Yes, this improves accuracy. When Thumb cycle count is enabled and a game takes too much time in ARM code, the scanline count will change. Which affects e.g. framerate. When disabled, such a game would work perfect in Stella but not on real hardware.

 

There is a setting in the debugger which enables/disables the cycle count. 

[Rodney Hester]

Been poking about with the R77 build myself trying to fix the deadzone issue.

 

I've at least confirmed that we're using the joydev interface in SDL vs. the evdev interface.

 

The deadzone handling is in the horribly-undocumented kernel/armbian-linux/linux-3.4.113/drivers/input/joydev.c, but past that, things get murky.

 

I'm 99% certain that the also-undocumented input_abs_get_flat() function is what returns the deadzone 'width', but replacing calls to that function to 0 either have no effect or result in input being entirely broken.

 

Similarly, tinkering with joydev_correct() seemed to make little difference.

 

I'm not at all sure what the "proper" return value of input_abs_get_fuzz() should be - logs I've seen show it's generally either a 0 or 2, but forcing it to 0 kills input.  I'm not even entirely certain what those values represent.

 

I've poked pretty much every variable and function in that file with a stick and made unfortunately very little progress, but I'm increasingly confident that's where any fix will have to go.

 

Just figured I'd share the little bit of useless research I've managed, because I really want paddles to work properly! 

Edited December 14, 2021 by Rodney Hester

[+stephena]

We've come to similar conclusions, that changing various functions in the kernel is not doing anything.  We decided to change this in SDL itself, since we're using a custom build.  We actually have this fixed now, but it introduces another problem; the jitter is too much in UI mode.  So Stella needs to be extended to deal with that as well.  That's why we've been delayed in the 6.6 release for R77.

[Capt Moore]

14 minutes ago, stephena said:

We've come to similar conclusions, that changing various functions in the kernel is not doing anything.  We decided to change this in SDL itself, since we're using a custom build.  We actually have this fixed now, but it introduces another problem; the jitter is too much in UI mode.  So Stella needs to be extended to deal with that as well.  That's why we've been delayed in the 6.6 release for R77.

When I notice a bug, I notice a good one….

 

Thanks for all the effort so far. 

[Rodney Hester]

NEVER MIND - local install of some SDL2 headers conflicted with the ones included with r77 stella, resolved

 

----
 

Which toolchain is this:

 

https://github.com/DirtyHairy/r77-firmware-ng/commit/6d4411ece9bd12607e413e97177ec53743359f32

 

associated with?

 

I ask because attempting to build latest head with gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf results in this while building SDL2:

  CC     build/SDL_threadprio.lo
/work/r77-firmware-ng/lib/sdl2/sdl2/src/core/linux/SDL_threadprio.c:79:28: error: unknown type name 'Sint64'
   79 | SDL_LinuxSetThreadPriority(Sint64 threadID, int priority)
      |                            ^~~~~~
make[3]: *** [Makefile:670: build/SDL_threadprio.lo] Error 1

 

Edited December 15, 2021 by Rodney Hester

[Rodney Hester]

Ugh.  My shiny new buildbot is now cleanly producing gcc 10 sdcard.img images with zero errors...and zero bootability.  No clue what's wrong.  uImage appears to be intact and starts up on a different card with a prebuilt image, but can't nav the UI except with the fire button.  Strange stuff.

 

Guess I'll be waiting for the official build like everybody else.  ?

[Thomas Jentzsch]

Looks like we finally fixed the dead zone issue on R77. So there should be a Stella 6.6 for R77 release soon.

[Rodney Hester]

Understood - any chance the docker image will be updated for gcc 10?  I've been over my local build image with a fine-toothed comb and just can't find anything wrong with it, I truly don't get why it's not booting.  There really isn't that much too it.