Jump to content
IGNORED

Stella 3.5 released


stephena

Recommended Posts

OK, it's time for a late Christmas gift; a new release of Stella. There are some nice improvements here, but one major drawback - the removal of TV effects. This was due to a reworking of the OpenGL backend, and will re-appear (as Blargg filtering) in the next release.

 

I'd like to take this opportunity to mention that Stella is now 'DonationWare', similar to Atari800MacX. The application will remain freely available, but I've added a link (http://stella.sf.net/donations.php) to the webpage that solicits donations in any form you wish. While cash is customary in such a case, I'm actually much more interested in hardware donations, particularly homebrew carts (where the developer feels that Stella was very helpful in their endeavours). So, just throwing the idea out there, and special thanks to all the people that have contributed in any way so far. As for the donation suggestions, anyone that can donate a working Commodore 128D will have priority for getting their most requested feature added to Stella (if at all possible) :)

 

Back to the Stella release, the changelog is as follows:

 

* Stella is now DonationWare! Please see the DonationWare link on the main webpage for more information.

 

* Added several improvements to the joystick management code. Joystick event mapping is now saved per device, meaning that if you map events to a certain joystick device, remove the device and then later insert it again, Stella will remember the original mapping.

 

* The total number of joysticks present and their associated properties (number of axes, buttons and hats) is now dynamic. That is, there's no longer a hard-coded limit on the number of joysticks that Stella can use, or the number of buttons, etc that it contains. This fixes a serious bug with PS3 controllers with 27 buttons, whereby adding a mapping for joystick 0 would inadvertantly change settings for joystick 1, and could potentially lead to a program crash.

 

* Added 'mcontrol' commandline argument, which can specify to use each mouse axis as a separate paddle. The old (and default) behaviour can be activated by setting this argument to 'auto'. Related to this, removed redundant 'usemouse' argument.

 

* Huge restructuring of the OpenGL code, making it compatible with OpenGL 2.x+ features (such as vertex buffer objects), while at the same time keeping compatibility with OpenGL 1.5 / OpenGL ES. Because of the required changes, TV effects were removed (they will be added again for the next release).

 

* Improvements to audio handling, particularly for certain cases of Windows, ATI video cards, and OpenGL mode. The sound device is now opened only once when Stella starts, and is paused between loading different ROMs. This fixes a problem whereby sound could possibly not be functional after loading the first ROM. Related to this, removed the 'audiofirst' commandline argument as it's now redundant.

 

* Fixed bug with displaying the ROM launcher in Windows XP; the initial load was sometimes taking up to 30 seconds to complete.

 

* Added logging facility, whereby the output of the application is available within Stella itself. This can still be printed to the console, or also saved to a file. Add the 'loglevel' and 'logtoconsole' commandline arguments which control these settings, and removed the 'showinfo' argument as it's now redundant.

 

* Updated DPC+ bankswitching scheme to latest code provided by SpiceWare.

 

* Added MAMCR handling to the Thumb ARM emulation code. Note that MAMCR isn't actually emulated, it is just ignored for now. This fixes a bug whereby accessing MAMCR would crash the ARM emulation.

 

* Added 'thumb.trapfatal' commandline argument, which causes the Thumb ARM emulation to either trap on a fatal error (throw an exception to the debugger and exit emulation) or simply log the error and continue. This should normally always be enabled, but can be disabled by developers for testing reasons.

 

* Updated default snapshot directory to be much saner and easier to find. For most systems, it now defaults to the users 'Desktop'. Note that the commandline argument has changed to 'snapdir'.

 

* The debugger 'print' command now indicates "special" addresses if they are read-only ®, write-only (W) or read-write (R/W).

 

* Fixed a bug where scrolling the mouse-wheel in certain debugger UI items would cause the program to crash; scrolling now works as expected.

 

* Fixed minor display issue in the debugger RAM area; some addresses were being displayed as '...'.

 

* Fixed compile issues in the latest versions of Ubuntu and Debian, and fixed UNIX desktop file so that Stella will launch with a ROM when selected from its icon. Thanks go to Stephen Kitt for this code.

 

* Updated included PNG library to latest stable version.

 

* Updated the credits list in the documentation, listing people that have donated hardware to the Stella team.

 

As usual, bug reports and feedback are appreciated in this thread, by email, or whatever method you prefer. Stella can be downloaded at http://stella.sourceforge.net .

  • Like 6
Link to comment
Share on other sites

I'd like to take this opportunity to mention that Stella is now 'DonationWare', similar to Atari800MacX. The application will remain freely available, but I've added a link (http://stella.sf.net/donations.php) to the webpage that solicits donations in any form you wish. While cash is customary in such a case, I'm actually much more interested in hardware donations, particularly homebrew carts (where the developer feels that Stella was very helpful in their endeavours).

 

Thanks for all of the hard work, stephena! Stella is a totally indispensable homebrew tool.

 

Expect a couple of carts from me sometime in the new year! :thumbsup:

Link to comment
Share on other sites

Thanks for the update! I installed it and I'll do some testing in the next days. Meanwhile I have a minor bug report (it was also on previous versions) and a couple of suggestions:

 

 

When you switch to "fixed debug colors", the playfield takes the players' color if the "score mode" is enabled (bit 1 of CTRLPF set). I wrote this simple test rom to show the problem:

debug_color_test.bin

post-10599-0-70398100-1325288184_thumb.png post-10599-0-00391300-1325288191_thumb.png

The rom displays some text using players and playfield. The "PF" text is made using the playfield (in fact you can disable it by pressing ALT+N), but if you enable the fixed debug colors it seems that player 0 and 1 are used in the second line.

 

 

I'd like to see some additions to the I/O tab in the debugger:

- SWCHB (W) and SWBCNT (because Stella now support using RIOT port B as output).

- TIA input ports (INPT0-5) and status of latches (bit 6 of VBLANK) and grounding transistors (bit 7 of VBLANK)

 

Thanks again for all the hard work! :thumbsup:

Link to comment
Share on other sites

As for the issues with... the TIA tab, I'll look into it for the 3.5.1 release.

You mean the debugger crash when switching to the TIA tab?

 

I should have said 'wishlist items for the TIA tab'. I was referring to a previous post about adding SWCHB and SWBCNT UI items.

 

Are you saying that switching to the TIA tab is causing crashes? If so, please explain exactly what you do to make this happen (ROM used, any other info you thnk it appropriate, etc).

Link to comment
Share on other sites

Nevermind. It crashed with 3.4.1. The latest version has fixed it. :)

 

OK, I assume it was addressed with this changelog note:

* Fixed a bug where scrolling the mouse-wheel in certain debugger UI items would cause the program to crash; scrolling now works as expected.

 

That being said, I don't recall anybody reporting this bug to me. I happened to find it on my own, without feedback from anyone. I guess my point is that if you find a bug, you should report it. I don't always catch them by myself.

Link to comment
Share on other sites

OK, I assume it was addressed with this changelog note:

No, not related to scrolling. Under certain conditions, it just crashed during BD development when switching to the TIA tab for the 1st time.

 

OK, so this one concerns me (and hasn't been reported before). It concerns me since I don't know what I could have done to fix it, meaning it still may not actually be fixed. If it is, great, but I'd really like to find exactly what it was to confirm that it's actually fixed.

Link to comment
Share on other sites

When you switch to "fixed debug colors", the playfield takes the players' color if the "score mode" is enabled (bit 1 of CTRLPF set).

 

This is now fixed, and will be included in the next release.

 

I'd like to see some additions to the I/O tab in the debugger:

- SWCHB (W) and SWBCNT (because Stella now support using RIOT port B as output).

- TIA input ports (INPT0-5) and status of latches (bit 6 of VBLANK) and grounding transistors (bit 7 of VBLANK)

 

It's easy enough the add the RIOT port B stuff, but it would be nice to have a test ROM to properly test whether it works.

 

As for the TIA ports and latches, those are easy enough to add as well, I think.

Link to comment
Share on other sites

When you switch to "fixed debug colors", the playfield takes the players' color if the "score mode" is enabled (bit 1 of CTRLPF set).

 

This is now fixed, and will be included in the next release.

Thanks!

:thumbsup:

 

It's easy enough the add the RIOT port B stuff, but it would be nice to have a test ROM to properly test whether it works.

Here are two test roms, one for each of the two RIOT I/O ports.

swcha_test.bin

swchb_test.bin

 

Both rom display 3 hex values on 3 lines. From top to bottom you have the port data register content [sWCHA ( W ) - SWCHB ( W )], the data direction register [sWACNT - SWBCNT] and the value read from the port [sWCHA ( R ) - SWCHB ( R )]. The order is the same used in the Stella debugger.

post-10599-0-05122800-1325450107_thumb.png

 

You can change the data register and data direction register contents:

If you are testing PORT A, use the SELECT switch on the console to select the current digit (indicated by the blinking cursor) and RESET to change its value. If you are testing PORT B use a joystick in the left port (move the stick to select the digit and press the button to change the value).

Link to comment
Share on other sites

Here are two test roms, one for each of the two RIOT I/O ports.

 

Thanks for the test ROMs. I've added the UI items to the debugger, and can confirm that changing the settings as you've described are reflected in the debugger. However, I can't (yet) get it to work in the other direction: setting something in the debugger and seeing it in the ROM. Is there some order I should follow in changing the bits in the debugger for SWCHB(W) and SWBCNT?

Link to comment
Share on other sites

If you change bits in the debugger, the test rom should only reflect changes in SWBCNT, but not in SWCHB(W). That's because the program cannot read back what has been written in the data register, so it just remembers the last value written to the port (stored at memory location $81). Reading the register returns SWCHB( R ), which is affected by SWBCNT and/or console switches status.

Edited by alex_79
Link to comment
Share on other sites

If you change bits in the debugger, the test rom should only reflect changes in SWBCNT, but not in SWCHB(W). That's because the program cannot read back what has been written in the data register, so it just remembers the last value written to the port (stored at memory location $81). Reading the register returns SWCHB( R ), which is affected by SWBCNT and/or console switches status.

 

Well in that case it's working! This will be included in the 3.5.1 release, sometime this month.

Link to comment
Share on other sites

Nice work and thanks for adding the ability to specify each mouse axis as a separate paddle. I just downloaded 3.5 and was able to get my 2 spinners working on my mame control panel (one is mouse x axis - the other is mouse y axis). It works perfectly! I was just asking a couple weeks ago if it was possible and I can't believe you already added it! Thanks for an awesome program!

CP with 2  spinners

Link to comment
Share on other sites

Nice work and thanks for adding the ability to specify each mouse axis as a separate paddle. I just downloaded 3.5 and was able to get my 2 spinners working on my mame control panel (one is mouse x axis - the other is mouse y axis). It works perfectly! I was just asking a couple weeks ago if it was possible and I can't believe you already added it! Thanks for an awesome program!

 

It looks like you're in luck with the timing. This feature was actually requested about a year ago, but I'm only now getting around to adding it. Good that you only had to wait 2 weeks :)

Link to comment
Share on other sites

stephena , thank you for another great release.

 

 

 

Nice work and thanks for adding the ability to specify each mouse axis as a separate paddle. I just downloaded 3.5 and was able to get my 2 spinners working on my mame control panel (one is mouse x axis - the other is mouse y axis). It works perfectly! I was just asking a couple weeks ago if it was possible and I can't believe you already added it! Thanks for an awesome program!

 

Cool panel. Question: using the two spinners as you described. What game(s) do you do that on?

Link to comment
Share on other sites

I'd like to see some additions to the I/O tab in the debugger:

- TIA input ports (INPT0-5) and status of latches (bit 6 of VBLANK) and grounding transistors (bit 7 of VBLANK)

 

Thanks again for all the hard work! :thumbsup:

 

I'm looking into this now, but I'm wondering what info should be available. It's very easy to add UI items that are read-only and just show the current state. However, I'm not sure how to represent input for INPT0..INPT3. These are specifically read-only registers, dependent on the values currently on controller pins 5 and 9. I can't 'write' them, because there's nothing there to 'write'.

 

It would make more sense if the controller area showed an item with data from pins 5 and 9 (which can be modified) and then show INPT0..INPT3 as read-only, dependent on the state of those pins.

 

I guess my real question would be, is read-only sufficient for this, or do you need read-write? And if the latter, how would other controllers be represented? One of the wishlist items was to add actual controller views in the I/O tab, so that you'd see joystick buttons for a joystick game (as it is now), a paddle widget for paddle games, etc. I think it makes more sense to go that route, and then just show the actual registers below it as read-only. However, adding this for all devices is something I may not get done for the 3.5.1 release. But it would be quite cool to have it there ...

Link to comment
Share on other sites

One of the wishlist items was to add actual controller views in the I/O tab, so that you'd see joystick buttons for a joystick game (as it is now), a paddle widget for paddle games, etc. I think it makes more sense to go that route, and then just show the actual registers below it as read-only.

I agree, that would be the best approach. I'd go with just a read-only view of the registers (actually you only need to show bit 7, so it will take little space in the I/O tab) until the various controller views can be added.

Link to comment
Share on other sites

One of the wishlist items was to add actual controller views in the I/O tab, so that you'd see joystick buttons for a joystick game (as it is now), a paddle widget for paddle games, etc. I think it makes more sense to go that route, and then just show the actual registers below it as read-only.

I agree, that would be the best approach. I'd go with just a read-only view of the registers (actually you only need to show bit 7, so it will take little space in the I/O tab) until the various controller views can be added.

 

I'm really going to try to get this into the next point release. It's not like it's something that just popped up; it's been in the Stella tracker (TODO list) for at least a year or two. I can probably get it done in a week if I can find some time to dedicate to it (and nothing else).

Link to comment
Share on other sites

stephena , thank you for another great release.

 

 

 

Nice work and thanks for adding the ability to specify each mouse axis as a separate paddle. I just downloaded 3.5 and was able to get my 2 spinners working on my mame control panel (one is mouse x axis - the other is mouse y axis). It works perfectly! I was just asking a couple weeks ago if it was possible and I can't believe you already added it! Thanks for an awesome program!

 

Cool panel. Question: using the two spinners as you described. What game(s) do you do that on?

 

To add to the duel spinners list:

Street race - works great X and Y separate axis

SuperBreakout - works by is not a simultaneous play game

Breakout - 2nd player doesn't seem to work on separate axis

 

Indy 500 - 2nd player doesn't seem to work on separate axis - I know the driving control is a whole other animal - but that would be bad a** to get that game working 2 players. My arcade spinner controls this game just like a driving controller (360 degrees rotation). It's a bit too sensitive, but I can play with the settings

 

I'll add more later when I go through the list and test the multi-player paddle games

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