Stella Version 2.2 released

[+stephena]

Stella version 2.2 has been released (http://stella.sourceforge.net). Stella is a multi-platform Atari 2600 emulator. Please note that the files may not be available on all Sourceforge servers yet. So patience ...

 

I know I sound like a broken record, but the anticipated TIA restructuring and debugger improvements promised for this release had to pushed ahead yet again. Lack of developers/time ...

 

Here's what's new:

 

* Added new ROM browser option which works like a normal filesystem browser, allowing navigation throughout the filesystem. The old mode of browsing is still present, and can be toggled at runtime. Related to this, fixed bug whereby sorting in the ROM launcher sometimes didn't work.

 

* Integrated stella.pro properties into the application, resulting in faster startup time. Now Stella can be redistributed as a single binary; no external files are needed, but they will still be used if present.

 

* Reworked ROM properties files once again. The 'user.pro' file has been removed, and all user-defined properties are stored in 'stella.pro' instead. You should delete all properties files when upgrading to this version, to take advantage of the speed increases.

 

* Reworked settings files once again. Removed all references to a global settings file. Each user now gets a user-specific settings file only. If that file doesn't exist, the built-in defaults are used.

 

* Added 'conditional saving' of the cheatcode and settings files, so that these files are only written to disk when absolutely necessary. This doesn't really affect desktop systems, but is very useful for systems with flashram-based storage (GP2X, WinCE, etc).

 

* Reworked Settings class, hopefully fixing a bug whereby settings weren't being saved in certain cases (most evident in the OSX port).

 

* Added 'tiadefaults' commandline option, which can also be toggled from within the GUI. This option disables all TIA positioning 'tweaks' that typically make a game look better, and present the image exactly as it would appear on a real 2600.

 

* Added jitter-detection code for the paddle emulation, which should eliminate an annoying 'jittering' effect when using paddles with a Stelladaptor.

 

* Related to jitter-detection, added '-pthresh' commandline option and GUI entry, which sets a bound below which the emulation detects jitter.

 

* Fixed crash when adding one-shot cheats.

 

* Fixed bug in RAM comparitive searches in the debugger.

 

* Fixed bug with setting snapshot naming type from the GUI (it was always being set to 'romname').

 

* Re-added low compatibility CPU emulation mode, since it benefits some slower systems. This is activated with the commandline argument '-cpu low'.

 

* For the OSX port, added Universal binary support.

 

* For the OSX port, reworked the menu handling, so that certain menu options are only enabled when it makes sense to do so.

 

* For the GP2X port, fixed joystick deadzone issues and scroll bug in ROM launcher.

 

* For the GP2X port, fixed issue with PAL ROMs causing a crash because of screen size. A message is now shown indicating that PAL ROMs are not yet supported.

 

 

Please report any bugs here or to the Stella mailing list. Enjoy!

[Shannon]

Not sure who works on the GP2X version, but the sound in Ms. Pacman sure makes some pretty nasty sounds. Especially when you get killed. In fact I think the sound on the GP2X sounds like it's too high pitched or something (try playing adventure).

 

I like the function to remove the hmov lines on the left, neat.

 

Mouse speed freaks out if you change the framerate. For example I set it to 1 and the mouse slowed down to a crawl.

 

I'd say more but I have not done much with it except browse around a little and run a few "quick" tests.

Edited April 9, 2006 by Shannon

[+Nathan Strum]

* Added new ROM browser option which works like a normal filesystem browser, allowing navigation throughout the filesystem. The old mode of browsing is still present, and can be toggled at runtime.

Thank you! That works great!

 

The new release is looking awesome. Thanks for all your hard work in continuing to improve Stella.

 

Question: Will the bugs in G.I. Joe and Kool-Aid Man be addressed by the future TIA restructuring?

[Paul Slocum]

The emulation is looking really solid, but that new (since I've used it) file browser has some UI design problems. I usually use the windows explorer to launch ROMs by association, but I'll post my issues with the interface anyway. I might start to use the browser (at least for non-dev gaming) if it was a little better designed.

 

If you're going to use a focus/tab based interface, whatever you click on should get the focus of input. But the way it's designed, the file list never gets focus (only the buttons can). So you end up with the problem where you use the arrow keys to select a game, hit ENTER, but the focus is on, say, "options", so it brings up the options menu instead of running the game. The file list itself should be a tab-able, focus-able item, and when it has focus, ENTER should always run whatever game you've selected.

 

Also, ideally "Go Up" should be an item in the file list. And it would be much easier if the path was shown. I have ROMs in a lot of different folders and it's difficult to navigate without seeing the path.

 

Sorry to complain, and thanks for a great emulator.

 

-paul

[Shannon]

Yeah the interface is just a teeny bit clunky and inconsistent.

 

Unfortunately on a GP2X it is too easy to accidently move the highlight right or left while scrolling without even realizing it (thanks to the crappy stick).

 

I dont know how many times I accidently exited out of stella.

[+stephena]

Not sure who works on the GP2X version, but the sound in Ms. Pacman sure makes some pretty nasty sounds. Especially when you get killed. In fact I think the sound on the GP2X sounds like it's too high pitched or something (try playing adventure).

It's a concession for the hardware on that device. I think one of the sound frequency parameters is set to 22050 instead of 31400, because it was causing some other problems. Of course, these weird sounds are the result. We're still looking into it, but as I don't personally have a GP2X, it's going to be slow going.

Mouse speed freaks out if you change the framerate. For example I set it to 1 and the mouse slowed down to a crawl.

I'll look into it. But we're actually thinking about removing the framerate option anyway, at least for non-developers. I really question its usefulness at this point.

[+stephena]

* Added new ROM browser option which works like a normal filesystem browser, allowing navigation throughout the filesystem. The old mode of browsing is still present, and can be toggled at runtime.

Thank you! That works great!

 

The new release is looking awesome. Thanks for all your hard work in continuing to improve Stella.

 

Question: Will the bugs in G.I. Joe and Kool-Aid Man be addressed by the future TIA restructuring?

Yes, I hope so. Brad Mott (original Stella author) will be back for the next release, so I'm sure we can get these annoying TIA bugs fixed for good.

[+stephena]

The emulation is looking really solid, but that new (since I've used it) file browser has some UI design problems. I usually use the windows explorer to launch ROMs by association, but I'll post my issues with the interface anyway. I might start to use the browser (at least for non-dev gaming) if it was a little better designed.

This is the first release of Stella with this new interface, so bugs are to be expected. I agree that there are usability issues that have to be addressed, and hopefully with some feedback we can take care of them.

If you're going to use a focus/tab based interface, whatever you click on should get the focus of input. But the way it's designed, the file list never gets focus (only the buttons can). So you end up with the problem where you use the arrow keys to select a game, hit ENTER, but the focus is on, say, "options", so it brings up the options menu instead of running the game. The file list itself should be a tab-able, focus-able item, and when it has focus, ENTER should always run whatever game you've selected.

Yes, I agree. However, this assumes one has a 'tab' key. Overall, I haven't really figured out how to create an interface that works intuitively for both normal systems (keyboard and mouse) and 'small' systems (only a joypad). So my compromise for the ROM launcher was that left/right directions select buttons, and up/down scrolls the list. If I make the romlist tab/selectable, there's the chance you can get in that mode and not get out of it, since on a smaller system one doesn't have a mouse or tab key to select anything else. I'd appreciate any advice on resolving this issue.

Also, ideally "Go Up" should be an item in the file list. And it would be much easier if the path was shown. I have ROMs in a lot of different folders and it's difficult to navigate without seeing the path.

These aren't too difficult to do; I just didn't get any feedback when designing this new launcher mode. I appreciate all feedback, and would definitely like to improve the GUI. It is inconsistent, since it was never meant to be used as a tabbable (sp?) interface, and assumed that a keyboard and mouse would always be available. Certain portions have been converted; others have not ...

[vdub_bobby]

Yes, I agree. However, this assumes one has a 'tab' key. Overall, I haven't really figured out how to create an interface that works intuitively for both normal systems (keyboard and mouse) and 'small' systems (only a joypad). So my compromise for the ROM launcher was that left/right directions select buttons, and up/down scrolls the list. If I make the romlist tab/selectable, there's the chance you can get in that mode and not get out of it, since on a smaller system one doesn't have a mouse or tab key to select anything else. I'd appreciate any advice on resolving this issue.

Would switching focus on LR/UD work? I.e., focus on the romlist with tab or UD and focus on the buttons with tab or LR.

 

One thing I would like is to be able to remap buttons from the launcher, rather than only within a game, especially since the remappings are universal.

[+stephena]

Yes, I agree. However, this assumes one has a 'tab' key. Overall, I haven't really figured out how to create an interface that works intuitively for both normal systems (keyboard and mouse) and 'small' systems (only a joypad). So my compromise for the ROM launcher was that left/right directions select buttons, and up/down scrolls the list. If I make the romlist tab/selectable, there's the chance you can get in that mode and not get out of it, since on a smaller system one doesn't have a mouse or tab key to select anything else. I'd appreciate any advice on resolving this issue.

Would switching focus on LR/UD work? I.e., focus on the romlist with tab or UD and focus on the buttons with tab or LR.

Possibly, but that still wouldn't take care of the 'twitchy' pad in GP2X incorrectly moving left or right when you don't want to. After writing the last few messages, I'm thinking of just reworking the GUI eventhandler, making it remappable and adding a 'switch between elements' action that must be bound to some joystick button or keyboard key. That way, the launcher can be changed to act as a "real" tab-able interface, since there will in effect always be a 'Tab' key. That should fix the problem that Paul Slocum mentioned, and also take care of twitchy/crappy pads. And doing that will also help GP2X users in other ways, since they could then map certain buttons to 'Home', 'End', 'Go Up', etc and more quickly navigate the GUI.

One thing I would like is to be able to remap buttons from the launcher, rather than only within a game, especially since the remappings are universal.

Not sure about this one, since it's possible to use Stella without the internal launcher, and those people must still be able to remap events. Besides, the current remapper deals with emulation events, so it more properly belongs in a menu accessible from the emulation mode. Now, if/when I add remappable GUI actions, that dialog box should definitely belong to the launcher, and be accessible from there. I guess I could make the current remapper belong to the launcher, but still be accessible from the emulation mode??

[Thomas Jentzsch]

Stella is really getting better and better now.

 

When are you going to fix the remaining emulation bugs (e.g. visible in Splatform)?

[Godzilla]

Well, I just want drop a note of thanks for the fact that this emu is still developed and supported :-) Now I want to go try it on my gp32blu 166. (Does it work on that or do you need a 2x?) how about dreamcast?

[vdub_bobby]

I guess I could make the current remapper belong to the launcher, but still be accessible from the emulation mode??

That'd be perfect.

[Paul Slocum]

I haven't used a GP32 so I'm probably not a good person to say, but my first guess would be to adjust it to standard mouse/keyboard UI, drop the "Select" and "Go Up" buttons, and then make A=ENTER and B=TAB (or t'other way round) for the GP32. But since I haven't used one, that might be inconsistent with other GP32 stuff.

 

If it's impossible to make it work consistently both ways, then maybe just use target #defines to customize each interface to it's physical interface.

[+stephena]

Stella is really getting better and better now.

 

When are you going to fix the remaining emulation bugs (e.g. visible in Splatform)?

See post #7.

[+stephena]

I haven't used a GP32 so I'm probably not a good person to say, but my first guess would be to adjust it to standard mouse/keyboard UI, drop the "Select" and "Go Up" buttons, and then make A=ENTER and B=TAB (or t'other way round) for the GP32. But since I haven't used one, that might be inconsistent with other GP32 stuff.

 

If it's impossible to make it work consistently both ways, then maybe just use target #defines to customize each interface to it's physical interface.

If I go with adding remapping abilities to the GUI eventhandler (and at this point that makes the most sense), there's no reason to add platform-specific defines at all. A set of default mappings can be created, and the user will be free to remap those to whichever buttons/keys that they want. That's how the current emulation remapper works, whereby the same platform-independent code works for all ports.

 

I only wish that I could have seen these suggestions in the development phase, and not just after a new release

[Paul Slocum]

Sorry, my primary connection to the Atari world these days is just the Atariage main RSS feed. Next time you have a release candidate maybe you can get Albert to post that you're looking for testers. There are probably others like me who read the main news but don't closely follow the boards or any specific projects. And I'm always ready to try out and complain about UIs.

[+stephena]

Sorry, my primary connection to the Atari world these days is just the Atariage main RSS feed. Next time you have a release candidate maybe you can get Albert to post that you're looking for testers. There are probably others like me who read the main news but don't closely follow the boards or any specific projects. And I'm always ready to try out and complain about UIs.

There's a Stella nightlies page, where the current CVS code is compiled and packaged each night (Linux and Win32 only, for now). Address is as follows: http://www.hardcoders.org/stella_nightly. So there's no need to make an announcement. Anyone can try the latest version and see how it works for them.

[Room 34]

Just downloaded the OS X version of 2.2 and so far, so good. I'm still finding the file browser a bit clunky. (I'd rather have the option of accessing ROMs through a regular OS X interface, but I understand this concession probably has to be made to keep up-to-date OS X ports coming, so I'll accept it!) Emulation seems great and I'm still happy about the phosphor effect that was introduced a while back.

 

I fired up a nice game of Demon Attack, and realized it's been WAY too long since I've played any 2600. I've been longing for it for weeks, I think, without even realizing it! Thanks guys for all of your efforts to make this happen!

[vdub_bobby]

A few comments about non-working items in the debugger.

 

1. As Zach noticed (see his bloggy), this conditional break doesn't work:

breakif *PF2==$00

2. The TIA Tab:

a) I also noticed that, contrary to the docs, the TIA strobe buttons don't work. Also, you can't edit GRPx or PFx directly, either by (double-)clicking on the little boxes or by directly entering values in, and the top-line of TIA values is mislabelled - according to the docs, they should show the values read by the CPU but when you click on one of them the label below shows the *read* label (VSYNC instead of CXM0P, etc). And further, though I haven't looked too deeply into what is going on, the values in the top-line TIA registers surely don't reflect the state of the TIA, since they all change drastically just when single-stepping through code that doesn't effect the TIA, read or write, at all!

b) Also, the checkbox editing of the ENAMx and ENABL is kind of worthless since the values are immediately reset (to whatever they were before) once you step through any code.

c) Checking the RESET flag for M0/M1 has odd behavior: It looks to me like checking that flag has no effect, but after checking it, stepping through one line of code, unchecking it, and then stepping through another line of code sets the missile position to the appropriate player position + *16*

 

You're always asking for comments

[Shannon]

Someone over on the gp32x forums suggested this, and it seems to help but it still gets odd results. (like delayed sound). But at least it's not screeching anymore. I wonder if there is a way to fine tune it a little more.

 

Change the values of these variables from

 

freq = 31400

tiafreq = 22050

 

to

 

freq = 15700

tiafreq = 15700

[Zach]

I am pleased with the improvements to Stella. I just started using the debugger, and it may not be perfect, but it is definitely making homebrewing easier.

 

Please note a slight bug that causes Four-Play to display incorrectly. The two right lines should be green rather than blue.

 

I use php to color the two right lines, and after studying the problem, I believe that the 'b' bit of the status register is copied as 0 when it should be 1.

 

I wrote quick program that sets the status register to #%01111111 and copies to PF1. The difference is clear.

[+batari]

I am pleased with the improvements to Stella. I just started using the debugger, and it may not be perfect, but it is definitely making homebrewing easier.

 

Please note a slight bug that causes Four-Play to display incorrectly. The two right lines should be green rather than blue.

 

I use php to color the two right lines, and after studying the problem, I believe that the 'b' bit of the status register is copied as 0 when it should be 1.

 

I wrote quick program that sets the status register to #%01111111 and copies to PF1. The difference is clear.

EDIT: just read up and I was wrong in my reply... But an alternative to setting it via PLP (I think) would be to start the game like this:

 

e.g.:

 

$FFFB:

BRK

.word $FFFB

.word start

 

You can always PLP, as I think you did. But the way you did it could also cause weird errors since I think you set the D flag (this burned me once and it took me a long time to track down.)

Edited April 15, 2006 by batari

[Zach]

You can always PLP, as I think you did. But the way you did it could also cause weird errors since I think you set the D flag (this burned me once and it took me a long time to track down.)

Actually for both the test program and Four-Play I set the bits one at a time.The color of the grid is $b4 which translates to Nv1BdIzc. The I flag is set at the beginning as usual, the N flag is set with a cmp, and AFAIK the B flag is always 1. For the test program I just used SED, SEI, lda #0, etc. to set flags.

 

By "weird errors" from setting the D flag, do you mean unexpected arithmetic or something else?

[+batari]

By "weird errors" from setting the D flag, do you mean unexpected arithmetic or something else?

Yes. I once had the "brilliant" idea that a PLP could be used as a way to pop the stack without affecting the accumulator, until weird things happened, as I used ADC/SBC in multiple places, including the kernel.