Stella 4.7.3 released

[Thomas Jentzsch]

Unfortunately no one has measured the sensitivity yet. I am looking for support here for quite some time, but not success.

 

The CX22 is definitely less sensitive and technically the CX22 requires two status changes for one step, where the other require only one. So that's where the 50% ratio comes from.

Edited December 21, 2016 by Thomas Jentzsch

[Trebor]

Unfortunately no one has measured the sensitivity yet. I am looking for support here for quite some time, but not success.

 

The CX22 is definitely less sensitive and technically the CX22 requires two status changes for one step, where the other require only one. So that's where the 50% ratio comes from.

 

Thank you, sir. The details are very much appreciated.

[tep392]

Unfortunately no one has measured the sensitivity yet. I am looking for support here for quite some time, but not success.

 

The CX22 is definitely less sensitive and technically the CX22 requires two status changes for one step, where the other require only one. So that's where the 50% ratio comes from.

In trackball mode, the pulses from the optical sensors go thru some cleanup and are then routed thru a selector to the xclock and yclock pins at the joystick connector. I've compared the cx22 schematic to the cx80 pcb I own and versions of the trackball should behave the same way. If there is a sensitivity difference between the two, it would have to be due to different number of teeth on the wheel or a difference in shaft diameter.

[alex_79]

If there is a sensitivity difference between the two, it would have to be due to different number of teeth on the wheel or a difference in shaft diameter.

True.

The fact is tha "CX22" and "CX80" in Stella refer actually to different encoding methods and not to the actual trakball models.

"CX22" stands for the original Atari Trakball encoding (used by both the cx22 and cx80 models!)

"CX80" stands for the Atari ST Mouse protocol (The misleading name comes from the fact that the first cx80 trakball which was documented in the Stella Mailing List was actually a modified unit that outputted Atari ST mouse compatible encoding and this led to believe that all cx80 were like that)

 

While testing the 2600 Trackballs hacks, some of us used third party trackballs and mice using adapters and/or modifying them to change the output protocol. The 50% ratio applies to trackballs with the same mechanic characteristics (for example a standard CX80 and one modified for ST mouse output).

http://atariage.com/forums/topic/243453-atari-2600-trak-ball-games/page-9?do=findComment&comment=3374393

It makes sense to use that same ratio in Stella when emulating one or the other protocol with the PC mouse.

 

 

[tep392]

Now I understand but it's going to continue to cause confusion if people keep saying CX80 when they are talking about ST mouse.

[alex_79]

I agree. I think it would be better to entirely ditch any reference to the actual models CX22 and CX80 and just call them Atari Trak-ball and Atari ST mouse protocols.

[Thomas Jentzsch]

I more and more tend to agree to the renaming.

 

And I really wish someone with a non-modified CX22/CX80 would compare the sensitivity to a modified CX22/CX80 or Atari/Amiga mouse.

[Keatah]

A question:

 

Is there any way to toggle max FPS while in-game with Stella? In Altirra I can smash the "F1" key and the emulator runs full speed ahead. Star Raiders hyperspace jumps happen instantly. MAME and Applewin also allow for such bursts of speed. I didn't see anything in the docs for Stella on this.

 

If not can this become a feature request? A bonus would be the ability to tune the game speed in-game, both up'n'down, by increments of 10 fps.

 

Oh and just out of curiosity, how does Stella determine what bank-switching scheme is in use? I don't need a lengthy explanation. Something along the lines of.. - it uses a database - or it checks which address lines or memory locations are being used. Or even, "it's just magic!"

Edited March 19, 2017 by Keatah

[TheHoboInYourRoom]

Oh and just out of curiosity, how does Stella determine what bank-switching scheme is in use? I don't need a lengthy explanation. Something along the lines of.. - it uses a database - or it checks which address lines or memory locations are being used. Or even, "it's just magic!"

It mostly searches the ROMs for certain load and store instructions associated with bankswitching hotspots, along with a simple heuristic based on file size.

[TheHoboInYourRoom]

For some reason I can't edit my last post, but if you're interested, this file has the checks and heuristics I mentioned.

[Keatah]

It works remarkably well, thanks for the info. I've only had to manually assign a scheme to a couple of roms out of thousands.

 

You can only edit your posts up to 1-hour after making them. Seems to be a common complaint.

[Keatah]

Stephana. I noted that you said you did something with ROM SELECTOR to reduce CPU usage. Unfortunately I still see 100% usage on my older Toughbook we take with on camping. It's a 2GHZ machine. 3.9.3 shows 1% or 2% which is essentially a background task. But like I said before, anything above and including 4.7.3, the UI pegs at 90-100%.

 

I did notice changing to D3D drops it to around 80%. So maybe the issue has something to do with the graphics API?. In emulation and playing games, cpu usage drops and hovers around 60-70% or so. Which is about right with all the stuff going on.

 

Don't know if that's something you want to still look at, considering we have 4.5GHz processors today. To them EVERYTHING is an idle task!

 

---

 

Have it be known and understood this isn't a complaint or bash. The work being done on this is really very nice and certainly appreciated. It may simply be time to upgrade my in-the-field gaming rig.

Edited March 28, 2017 by Keatah

[Thomas Jentzsch]

On my 3.4 Ghz i5 Stella 4.7.3. the ROM selector requires ~2.5%. A game like Frogger increases this to ~5% (4x Zoom). Disabling Software Rendering reduces this to ~1.5%. Setting Timing to Busy-Wait adds another ~1%. All other settings only have minimal impact if any.

 

I would try to make a clean install of Stella in an empty directory. Maybe some unusual setting is causing the problem.

[Keatah]

I've never seen Stella, any version, exceed 10 or 20% on my i7. So I'm good on my main emulator rig.

 

I will try a new/separate installation to be sure.

[Keatah]

OK I did a fresh install. no change.

 

I did notice in the process of setting up my preferences, in 4.7.3, the cpu usage jumps up more and more as I increase the Launcher Width and Launcher Height. At 640x480 I get about 30% cpu usage. At 1024x768 it goes up to 100%.

 

So that's where I'm at. I can always continue using 3.9.3 on my portable. And call it a day.

[Thomas Jentzsch]

Since the CPU usage is not much different between launcher and games, something in your Toughbook is not right. What kind of CPU does it have? Any chance of updating graphics driver?

 

Even on my dead slow 1.33 GHz Atom-based convertible, Stella requires only up to 10%.

[+stephena]

From a technical POV, it makes sense that as the UI gets larger, it takes more CPU to render it (all other things being equal, the larger the texture to render, the more work to do). But the delta shouldn't be as large. Or put another way, it shouldn't be as noticeable to the end user.

 

Stella 3.9.x is a special case. It was using hand-written OpenGL code, and using dirty updates to only update the screen when changes have happened. Since then, we've moved to SDL2, which does OpenGL or Direct3D itself, behind the scenes (so it may not be as fast as my hand-written OpenGL code). And I remove dirty rectangle updates, since it was causing problems in other areas. I'm not opposed to looking at the latter again and attempting to re-enable it, if I can find the time. I suspect that not updating the screen 60 times per second, even if nothing has changed, will have some visible effect on CPU usage.

 

As well, note that Stella 5.0 is going to be slower in emulation, since it's doing so much more now. That's the price of more accurate emulation. For this aspect in particular, I have no issue. I'll gladly pay more CPU time to get a more accurate emulation.

[+stephena]

Have it be known and understood this isn't a complaint or bash. The work being done on this is really very nice and certainly appreciated. It may simply be time to upgrade my in-the-field gaming rig.

 

Just to be clear, I've never had a problem with constructive criticism, from you or from anyone else. Some of the best improvements in Stella have come from constructive criticism. It's just complaining for the sake of complaining, and non-constructive criticism that gets my goat. Your reported issue is a valid one that I hope to be able to address sometime soon.

[Keatah]

Since the CPU usage is not much different between launcher and games, something in your Toughbook is not right. What kind of CPU does it have? Any chance of updating graphics driver?

 

Even on my dead slow 1.33 GHz Atom-based convertible, Stella requires only up to 10%.

 

2.1 GHz Pentium M (ultra low voltage, works 10+ hours) SSE2 = latest instruction set.

Zero chance of updating the graphics drivers. It's a legacy product. The last driver was published in 2006-2008 IIRC.

 

Atom supports a higher OpenGL standard than my rig, so that's where I think the problem is. My portable supports OpenGL 1.3 100%, and some 1.4 and 1.5 functions. No 2.0 or higher.

 

 

From a technical POV, it makes sense that as the UI gets larger, it takes more CPU to render it (all other things being equal, the larger the texture to render, the more work to do). But the delta shouldn't be as large. Or put another way, it shouldn't be as noticeable to the end user.

 

Stella 3.9.x is a special case. It was using hand-written OpenGL code, and using dirty updates to only update the screen when changes have happened. Since then, we've moved to SDL2, which does OpenGL or Direct3D itself, behind the scenes (so it may not be as fast as my hand-written OpenGL code). And I remove dirty rectangle updates, since it was causing problems in other areas. I'm not opposed to looking at the latter again and attempting to re-enable it, if I can find the time. I suspect that not updating the screen 60 times per second, even if nothing has changed, will have some visible effect on CPU usage.

 

Yes I would tend to agree. It fits with what I observed and what I understand.

I also did a little test. I loaded up 3.9.3 and in the rom selector I flicked the scroll wheel back and forth real fast, like playing a crazed game of Tempest. The CPU usage shot up to 100%. When I stopped, it fell to 2% or 3%.

 

I suspect that SDL2 is falling back on software to compute and render the texture for the rom selector screen. It's probably doing that because the required OpenGL 2.0 functions are not present in my portable.

 

I don't actually see or note a slowdown in the scrolling. It's as fast as 3.9.3.

 

 

As well, note that Stella 5.0 is going to be slower in emulation, since it's doing so much more now. That's the price of more accurate emulation. For this aspect in particular, I have no issue. I'll gladly pay more CPU time to get a more accurate emulation.

 

Still have in-game headroom with 5.0 pre-6. But yes by all means continue making accuracy improvements.

Edited March 28, 2017 by Keatah

[Keatah]

Question:

 

Is there a way to execute the <ctrl-q> or <esc> commands through something else other than the keyboard? I was thinking like pressing 2-buttons on the mouse, or the mouse wheel and the right button. Something like that.

[+stephena]

You can remap 'Exit' to any key on the keyboard or anything on a joystick, but there's currently no way to map something to mouse events.

[Keatah]

I kinda figured as much. Ok.

[Keatah]

Is there any way to "center" the game image? Back in the day we could use the H.size, V.size, H.pos, and V.pos controls on the TV to get a perfectly centered display.

 

Stella doesn't really provide for this, does it? If it does, I'm clearly missing it.

 

Edited May 15, 2017 by Keatah

[Keatah]

Feature Request:

 

Is there a way to use the search box and search through all folders and sub-folders in a "master directory"? If not, perhaps prepending or appending the search term with a unique string could trigger the function. Something like from the old modem days, +++ or ~^~. When the search routine sees that it it would look in all sub-folders. To make it polished, the string could be user-definable too.

[+stephena]

This is a good request; perhaps you can add it to https://github.com/stella-emu/stella/issues. At some point I want to revisit the ROM launcher, and in particular offer more support for regular expressions.