Stella Version 2.0.1 released

[+stephena]

Stella version 2.0.1 has been released (http://stella.sourceforge.net).

Stella is a multi-platform Atari 2600 emulator.

 

This is just a minor bugfix release for some issues in version 2.0. Changes include:

 

* Added 'dirtyrects' support, which speeds up rendering for some Windows users.

 

* Fixed bug where taking snapshots would fail if the snapshot directory

wasn't specified.

 

* Made ROM launcher case-insensitive, so upper and lowercase names are now

mixed in the correct order.

 

* Fixed ZIP ROM support to search the archive for ROMs ending with either

.bin or .a26 (case insensitive).

 

* ROMs which don't have an associated properties entry are no longer named

'Untitled' in the Stella window or when taking snapshots. The actual

ROM name is now used.

 

* Changed minimum height of debugger to be 27 lines in the prompt, or approx.

700 pixels high. This should make using the debugger easier for users

with lower resolution monitors. Related to this, the RomWidget now uses

all possible vertical space when changing the debugger height.

 

* Fixed bug related to upgrading Stella and event mappings being incorrect.

Stella now detects this, and uses the default mappings. So upgrading

to version 2.0.1 means your event mappings will be reset.

 

* Fixed bug in loading debugger symbol files generated on different

operating systems.

 

* For the Windows port; added exe installer based on InnoSetup.

 

* For the Windows port; compiled icon into Stella, so it now looks like

a real Win32 application.

 

* For the OSX port, reverted window resize key combos back to 'Cmd =' and

'Cmd -' to match the 1.4.2 release.

 

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

[vdub_bobby]

I couldn't find 2.0.1 at http://stella.sourceforge.net/ - the version available for download is 2.0; not 2.0.1

 

Did I try to get it too quickly?

Edited October 25, 2005 by vdub_bobby

[Albert]

I was using Stella 2.0 yesterday with Mac OS X. First, great job, it's really nice to have an integrated user-interface and it makes using the emulator much easier. Also, the debugger looks quite slick. One question, though. Is there any way to toggle the emulator into Full-Screen mode? I tried Cmd-Enter, but that did not work, and that's the sequence used by many such programs (to mimic the "Alt-Enter" in Windows used by many apps).

 

Thanks!

 

..Al

[+stephena]

I couldn't find 2.0.1 at http://stella.sourceforge.net/ - the version available for download is 2.0; not 2.0.1

 

Did I try to get it too quickly?

953998[/snapback]

I just updated the main webpage, but it's probably not yet on all sourceforge servers.

[+stephena]

Is there any way to toggle the emulator into Full-Screen mode? I tried Cmd-Enter, but that did not work, and that's the sequence used by many such programs (to mimic the "Alt-Enter" in Windows used by many apps).

953999[/snapback]

Strange, it's supposed to work. That shortcut was there in version 1.4, and it should still be there. I suggest trying the 2.0.1 release; hopefully that will fix it. Also, the keys to resize the window are now Cmd-= and Cmd--, just as they were in 1.4.2 (the 2.0 release had them as Shift-Cmd).

 

Anyway, you could always go into the video menu and change fullscreen with the toggle button. But the shortcut should be working as well.

[atarimac]

Al,

The Cmd-Enter shortcut works for me on the Mac. You might want to try what Steve suggested as well, to see if the menu item works. Of course, that would be a problem if it worked, and the shorcut didn't, as you wouldn't be able to get back from fullscreen.

 

Mark

[Albert]

Al,

  The Cmd-Enter shortcut works for me on the Mac.  You might want to try what Steve suggested as well, to see if the menu item works.  Of course, that would be a problem if it worked, and the shorcut didn't, as you wouldn't be able to get back from fullscreen.

954053[/snapback]

I just tried it again (with Stella 2.0, haven't grabbed the new version yet) and Cmd-Enter works just fine. I'm gonna' have to blame this one on myself--not sure what the heck I was doing yesterday!

 

Thanks,

 

..Al

[+stephena]

Al,

  The Cmd-Enter shortcut works for me on the Mac.  You might want to try what Steve suggested as well, to see if the menu item works.  Of course, that would be a problem if it worked, and the shorcut didn't, as you wouldn't be able to get back from fullscreen.

 

Mark

954053[/snapback]

I was referring to the 'Video Settings' dialog, accessible when pressing the 'Tab' key. So even if you are in fullscreen and the shortcut doesn't work, you can still get back into Video Settings and toggle it off again. Is there also a 'video menu' in StellaOSX?

[midget35]

This is an extension to the 2.0 thread, regarding Solaris:

 

The warp issue described by Great Hierophant relates to two red planes passing above & below the player during warp. The planes have parts 'missing' on the far right side (best observed when one selects a destination and then warps to it from the map grid).

 

Also- a small point- but I remember the 1st map screen in Solaris consisting of a much brighter white grid & icons. It may be my imagination, but the colour seems slightly dull blue.

 

This also seems prevelent in the colour of the remaining lives indicator in the bottom left of the action screens (and possibly part of the player ship too).

 

Are PAL pallettes the issue (are they even emulated?)

 

Nonetheless; the quality of emulation for Solaris is staggeringly good. I am extremely impressed.

 

Thanks as always

 

* EDIT

 

More issues:

Bobby Geht Nach House PAL:

 

Lives & level no. absent from bottom of screen

 

The charcter dies straight away once the game is started (sinks into ground).

 

The graphics on the final screen (w/ the house) are largely wrong. Most notably: the lower right quarter of the screen flashes inexplicably.

 

More pallette issues? Parts of the background on the 5th screen seem to have disappeared. EDIT: confirmed: z26 seems to have recreated colours almost perfectly, quite different to Stellas.

Edited October 26, 2005 by midget35

[+stephena]

This is an extension to the 2.0 thread, regarding Solaris:

 

The warp issue described by Great Hierophant relates to two red planes passing above & below the player during warp. The planes have parts 'missing' on the far right side (best observed when one selects a destination and then warps to it from the map grid).

I just spoke to Brad Mott (original Stella author), and he confirms that there are some positioning bugs in the TIA code, and that they affect many different games. Also, the TIA restructuring for version 2.1 will fix all these items.

 

As for the palettes, that's a hotly debated issue Because of the differences in NTSC/PAL TVs, no one can really say if z26 palette is more accurate than Stella, or vice versa. But if you prefer the z26 palette, it can be selected in Stella (Ctrl-p or access the Video Settings dialog). The better solution is to provide the ability to edit and save the palette from within Stella, and this is coming in the 2.1 release.

[+stephena]

This is an extension to the 2.0 thread, regarding Solaris:

* EDIT

 

More issues:

Bobby Geht Nach House PAL:

 

Lives & level no. absent from bottom of screen

 

The charcter dies straight away once the game is started (sinks into ground).

The first one is due to incorrect stella.pro entry. If you go into 'Game Properties/Display' and edit YStart to be 45 and Height to be 245, the lives and level reappear. I'm unable to duplicate the character dying; it doesn't happen for me.

[midget35]

> I'm unable to duplicate the character dying; it doesn't happen for me.

 

This is a strange one! It seems that with both Stella & Z26, this only happens sometimes (perhaps 20% - 30% of the time).

 

Start Stella & load the rom. If the character does not die straight away, then repeat the process. DO NOT just reload the rom: fully exit the emu & then restart, & load the rom. Sooner or later you will witness this strange phenomenon.

 

I am only vaguely familiar w/ the cartridge frying feature of newer Stella versions, would this explain it?

 

---

 

The palette issues are not as exaggerated as I thought earlier- but I can confirm that the PAL colours are more accurate in Z26 (for BGNH). (Please disregard earlier observations, I haven't done you the courtesy of looking into it enough myself yet)

 

---

 

Thanks a lot Steph

[+stephena]

> I'm unable to duplicate the character dying; it doesn't happen for me.

 

This is a strange one! It seems that with both Stella & Z26, this only happens sometimes (perhaps 20% - 30% of the time).

 

Start Stella & load the rom. If the character does not die straight away, then repeat the process. DO NOT just reload the rom: fully exit the emu & then restart, & load the rom. Sooner or later you will witness this strange phenomenon.

Because of the way Stella is written, reloading the ROM is the same as exiting and restarting. The entire state of emulation is reset on each ROM (re)load, so it shouldn't be necessary to completely exit and restart the emulator itself. I will experiment with this.

I am only vaguely familiar w/ the cartridge frying feature of newer Stella versions, would this explain it?

No, because frying is only activated if you press 'Backspace'. Otherwise it's never used.

The palette issues are not as exaggerated as I thought earlier- but I can confirm that the PAL colours are more accurate in Z26 (for BGNH).

Yes, would agree that some of the PAL colours are quite a bit off. But I decided to implement editing of colours in a future release, rather than hard-coding values in.

[midget35]

Because of the way Stella is written, reloading the ROM is the same as exiting and restarting. The entire state of emulation is reset on each ROM (re)load, so it shouldn't be necessary to completely exit and restart the emulator itself. I will experiment with this.

 

Sory to be so impatient, but I'm dying to know if you have encountered the 'instant death' bug yet?

 

It's very hard to explain away, and I seem to be able to recreate it with some ease!

[+stephena]

Because of the way Stella is written, reloading the ROM is the same as exiting and restarting. The entire state of emulation is reset on each ROM (re)load, so it shouldn't be necessary to completely exit and restart the emulator itself. I will experiment with this.

 

Sory to be so impatient, but I'm dying to know if you have encountered the 'instant death' bug yet?

 

It's very hard to explain away, and I seem to be able to recreate it with some ease!

955212[/snapback]

Yes, I've noticed it, but as you say, only when restarting the emulator, not when reloading. I can't explain it, especially since z26 also does it, and the code in both emulators is quite different. Even more inexplicable is that it doesn't happen when reloading the ROM in Stella, only when restarting the whole application.

 

I have two suggestions. First is that the real cartridge acts that way. Second is that there's some race condition in the code (something is happening before it should), but it only happens some of the time. I have no estimate on when this will be fixed, since I don't know where to start. Perhaps I should use the debugger to debug this problem

[midget35]

It's SO SO strange! I had this game for years and I don't recall the problem (though I might be wrong).

 

Don't get me wrong- I'm not nagging for a fix- I'm just fascinated to know what it could be !?!?

 

I have no estimate on when this will be fixed, since I don't know where to start. Perhaps I should use the debugger to debug this problem

 

Haha! I like your style!

 

I shall keep looking into it myself, thanks for the continued swift responses!

 

Regards!

[Albert]

So, I needed to take some screenshots for some games to be released at the upcoming Philly vgXpo. I fired up Stella 2.0 (hmm, I need to install 2.0.1!), but F12 is mapped to the Dashboard (as of OS X 10.4), so that's not a very good default in OS X. I discovered the handy, built-in event mapper (very nice!) and remapped Snapshot to Enter and went back to the game. I then pressed Enter and BOOM! Stella disappears. I fired Stella back up, tried again, but mapped Snapshot to a different key (Delete), returned to the game, pressed DELETE and Stella abruptly vanished again.

 

This time, before loading a binary, I saw the "Snapshot Settings" tab under "Options" in the game selection dialog. There was no default path, and I assume this is what was causing Stella to quit when I was trying to take screenshots. As soon as I set this to a valid path, it worked fine. My suggestion would be to include a "snapshots" directory as part of the default installation, and set the default path to this newly created directory the first time the app is run (or during install, although in OS X, installing just means dragging the Stella folder into your Applications (or some other) directory).

 

As an aside, when you have a smaller dialog on top of another, it is confusing as to which buttons are active. It would be nice if only the dialog on top (in focus) has the buttons at full brightness. In my opinion the buttons on the parent dialog should be darkened considerably.

 

Thanks!

 

..Al

[supercat]

I have no estimate on when this will be fixed, since I don't know where to start. Perhaps I should use the debugger to debug this problem

955273[/snapback]

 

My guess would be that BGH doesn't cleanly initialize all the video registers before showing the first frame, and the behavior may depend upon where in the scan line the CPU starts executing code. Does Stella randomize that? Is there any way to force a particular value?

[+stephena]

This time, before loading a binary, I saw the "Snapshot Settings" tab under "Options" in the game selection dialog.  There was no default path, and I assume this is what was causing Stella to quit when I was trying to take screenshots.  As soon as I set this to a valid path, it worked fine.  My suggestion would be to include a "snapshots" directory as part of the default installation, and set the default path to this newly created directory the first time the app is run (or during install, although in OS X, installing just means dragging the Stella folder into your Applications (or some other) directory).

The crashing was caused because of a bug that occurs when you don't have a specified snapshot folder. Once you set one, it works fine (as you've already realized). A fix for this was included in version 2.0.1 (item #2 in the Changes listed above). Please try that version. It also includes other fixes, like not naming a snapshot as 'Untitled.png' when no properties exist for that ROM. Also, I sent you a PM asking to post the 2.0.1 release, as it documents all these changes.

As an aside, when you have a smaller dialog on top of another, it is confusing as to which buttons are active.  It would be nice if only the dialog on top (in focus) has the buttons at full brightness.  In my opinion the buttons on the parent dialog should be darkened considerably.

The topmost dialog is the only one which can have active buttons, and it's impossible to have more than one dialog active. I guess we could tweak the colours a little, or make the in-focus dialog a little more clear.

 

As for your last comment, do you mean to darken the button colours for all underlying dialogs?

Edited October 27, 2005 by stephena

[Haunted]

Stella's event mapper doesn't seem to register input from a joystick or POV hat (D-Pad). Click on an event, press "map," and press a direction on the stick or pad; nothing will happen. I don't think it's a controller problem (I tried 2 different controllers) and there are no problems mapping an event to a controller button. Fortunately, up/down/left/right are mapped to the joystick axes by default, and Stella has no difficulty accepting the joystick's input while actually playing a game. It'd be a problem if you favored a more estoric controller setup, though, or if you wanted to use the POV hat.

 

Also, if you press numlock or capslock while in the event mapper, it will interpret it as a continuous press. So if you map event1 to capslock, then try to map event 2 with capslock still on, it will think the capslock button is being held down and instantly map event2 to capslock as well.

 

Finally, it would be nice to be able to remap the paddle directions and button to something other than the mouse, so you can play a multi-player game even if you only have one mouse.

 

Anyway, great work so far. Stella's now my 2600 emu of choice.

Edited October 28, 2005 by Haunted

[+stephena]

Stella's event mapper doesn't seem to register input from a joystick or POV hat (D-Pad). Click on an event, press "map," and press a direction on the stick or pad; nothing will happen.

The joystick code is currently quite basic, and only supports axes and buttons, not hats or other items that may be on some gamepads. A fix for this is coming in the 2.1 release.

Also, if you press numlock or capslock while in the event mapper, it will interpret it as a continuous press. So if you map event1 to capslock, then try to map event 2 with capslock still on, it will think the capslock button is being held down and instantly map event2 to capslock as well.

I'll look into this one. Sounds like an SDL issue.

Finally, it would be nice to be able to remap the paddle directions and button to something other than the mouse, so you can play a multi-player game even if you only have one mouse.

This is also coming in version 2.1. In fact, the entire joystick/mouse/paddle input code is due for a minor overhaul. Another problem we currently have is the order that joysticks are numbered in Stella. For example, assume you have gamepad A (Gravis) and gamepad B (Microsoft). Depending on how the pads are plugged in, Stella will always treat A as the left 2600 port, and B as the right 2600 port, and if you want to switch them, you either have to plug them in in a different order, or remap all actions in the Event Mapper. Obviously, there should be an option that lets you determine which stick to treat as which port, and this will be fixed in 2.1 as well.

[+batari]

First I would like to say that the debugger is great! It enabled me to find long-standing bugs in my two minigames in no time, and to get them released before the deadline. The ability to view a scanline at a time and watch the kernel draw the screen is especially helpful for getting a kernel working properly.

 

The only suggestions I have (Specific to OSX, which may have already been addressed) are:

 

CMD-O for opening a new game seems to have been removed.

 

The window size of the debugger is a little too tall for my 1024x768 screen. It seems that you can't (or I don't know how to) use the full 768 pixels in a window, so the bottom is cut off. If you could (or if someone can tell me how to) make the window 1024x700 or thereabouts, it would be perfect.

[supercat]

First I would like to say that the debugger is great!  It enabled me to find long-standing bugs in my two minigames in no time, and to get them released before the deadline.  The ability to view a scanline at a time and watch the kernel draw the screen is especially helpful for getting a kernel working properly.

956438[/snapback]

 

I've not tried Stella yet (early bird gets the worm, but the second mouse gets the cheese) but one thing I'd like to see would be an emulator that could take snapshots of the machine state every second or so while running full speed and while recording all controller inputs and the moments they occurred, and then go back and replay stuff in slow motion in a debugger to see what happened.

 

Too often, I find that I'm running the game and I notice that something wrong just happened, but by then of course it's too late to start logging and see what's going on. If the game could snapshot every second or so while running realtime, that would be quite helpful.

[+stephena]

First I would like to say that the debugger is great!  It enabled me to find long-standing bugs in my two minigames in no time, and to get them released before the deadline.  The ability to view a scanline at a time and watch the kernel draw the screen is especially helpful for getting a kernel working properly.

That was our goal; to help homebrew developers get releases done more quickly, and generally make it easier to track down bugs. Look for many more debugger improvements in the next release.

CMD-O for opening a new game seems to have been removed.

If you're using the built in ROM launcher, pressing Escape while playing a game brings you back to the launcher to select another one. So in this case, Cmd-o seemed redundant. I suppose we could tie it to the Escape event.

The window size of the debugger is a little too tall for my 1024x768 screen.  It seems that you can't (or I don't know how to) use the full 768 pixels in a window, so the bottom is cut off.  If you could (or if someone can tell me how to) make the window 1024x700 or thereabouts, it would be perfect.

This was addressed in the 2.0.1 update, specifically for OSX users with 1024x768 and a large dock. Go into the debugger prompt and enter the following command 'height #27'. This will reduce the prompt height to 27 lines, which is the smallest it can go. You'll have to exit the debugger and reset the ROM, since the GUI doesn't yet know how to resize itself (will be fixed for next release). The next time you enter the debugger, it will use the new height.

[+stephena]

I've not tried Stella yet (early bird gets the worm, but the second mouse gets the cheese) but one thing I'd like to see would be an emulator that could take snapshots of the machine state every second or so while running full speed and while recording all controller inputs and the moments they occurred, and then go back and replay stuff in slow motion in a debugger to see what happened.

It's on our TODO list, but I don't know if we can get it done for the next release. The infrastructure is already there, since Stella can load and save its state. All that's needed is to design a way to do it efficiently, and be able to control the rate at which it proceeds (pause, ff, etc), so you can see exactly what's happening.

 

A rudimentary way would be to just save states every second, and then upon loading, just reload those same states every second. The better way would be to use deltas, and have each successive state save only the differences. This would also be useful in itself as a debugging aid, since you'd see exactly what changed on each iteration.