Stella Version 2.0 Released

[+stephena]

After seven months of work, it's finally here

 

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

Stella is a multi-platform Atari 2600 emulator.

 

Changes are as follows:

 

* Added integrated GUI. Stella is now a fully graphical application, and all

settings can be changed dynamically while the application is running. That

means the commandline is no longer required (but support is still there

for those who want to use it).

 

* Added ROM launcher. You can now exit a game and start playing another one

from directly within Stella (you no longer have to quit Stella and

restart it).

 

* Because of the integrated GUI and ROM launcher, StellaX and KStella

(the Windows and Linux frontends) have been discontinued. The OSX

port now uses the launcher as well.

 

* Added an integrated debugger for game developers. This is currently

the first version of a debugger in Stella, but it's already quite

usable.

 

* Added new sound subsystem, which is much faster and more accurate.

Related to this, added stereo sound output (used by some homebrew games).

 

* Added ZIP support. Stella can now open ROM's compressed in zip

format.

 

* Added cartridge 'frying', thanks to Fred "batari" Quimby. This

emulates the action of turning the power button on and off on a

real Atari, often resulting in some strange effects.

 

* Added ability to edit current ROM properties from directly within

Stella, which can then be saved directly into the 'user.pro' file.

So creating a properties entry for a new ROM can be done without

any external tools.

 

* Added initial support for using Stella in an 'arcade-box'

environment without a keyboard. This consists of an in-game

menu for choosing common actions in Stella, as well as using the

joystick navigate the mouse pointer.

 

* Reworked properties system to use both a system-wide 'stella.pro' and

a per-user 'user.pro' properties files. Changes made by the user

and stored in 'user.pro' are no longer erased when upgrading Stella.

 

* Added support for cartridges with 3E bankswitching format.

 

* Added preliminary Cheat support.

 

* Added 'Alt/Shift-Cmd' z, x, c, v, b, n keys to enable/disable the

P0, P1, M0, M1, BL, PL bits in the TIA, respectively.

 

* Added 'Alt/Shift-Cmd .' key to disable all bits in the TIA.

 

* Added 'Alt/Shift-Cmd /' key to enable all bits in the TIA.

 

* Added 'Alt/Shift-Cmd g' key to switch dynamically switch between

software and OpenGL modes while Stella is running.

 

* Added 'Ctrl/Cmd r' key to reload the ROM currently being emulated.

 

* Added 'Alt/Shift-Cmd s' key to merge the current game properties

into the properties file.

 

* Added 'help' commandline argument. Launching Stella from the

commandline with no options now starts Stella in ROM launcher mode,

instead of showing help (as in previous versions).

 

* Added the following commandline arguments for developers:

"pro, type, ld, rd, tv, lc, rc, bc, format, xstart, ystart, width

height, cpu, hmove". Developers can consult the manual for

further details.

 

* Removed 'mergeprops' commandline argument, since there are now

dedicated keys to either save or merge game properties.

 

* Removed 'hidecursor' commandline argument. Stella will now

automatically decide when to use this setting.

 

* Fixed framerate when switching between NTSC and PAL modes. Stella

now uses the correct framerate based on the format of the ROM,

in terms of both video and audio.

 

* Added 'configure' support to the build process for both Linux and

Win32 (using MinGW). Developers can now use the familiar 'configure;

make; make install' commands to compile Stella.

 

* Further consolidation and integration of SDL. This should lead to

faster operation and a more consistent look for all ports.

 

* Fixed some 64-bit issues. Stella now compiles and runs correctly

on AMD64 and PPC64 Linux systems.

 

* Updated the Stella manual with pictures of the new integrated GUI.

 

Have fun ...

[Thomas Jentzsch]

:thumbsup:

[mos6507]

Congrats. Will check this out tonight.

[seemo]

Thank You !

 

Simone

[vdub_bobby]

Good job!

[+Nathan Strum]

Thank you! Can't wait to check it out!

 

(Time passes)

 

Well, I checked it out. (Couldn't wait.) It doesn't seem to support subdirectories for ROMs. For instance, I break down my ROMs by manufacturer, or homebrew games, prototypes, etc. But it won't let me change directories once I'm in the main ROM list.

 

For example, it will show the Parker Bros. subdirectory (and others) but if I double click on that, instead of opening it and showing the games in it, it starts going through a SuperCharger load screen, over and over, until I quit the app. (This is on OS X, 10.4.2.)

 

So does this mean all ROMs now have to reside in a single directory?

Edited October 17, 2005 by Nathan Strum

[+stephena]

Well, I checked it out. (Couldn't wait.) It doesn't seem to support subdirectories for ROMs. For instance, I break down my ROMs by manufacturer, or homebrew games, prototypes, etc. But it won't let me change directories once I'm in the main ROM list.

 

So does this mean all ROMs now have to reside in a single directory?

949844[/snapback]

Unfortunately, yes, that's what it means. The ROM launcher isn't a directory browser, but just a listing of one particular directory. That's the way the StellaX and KStella frontends worked, so that's what I modelled it on.

 

The good thing about it is that you don't have to use the launcher if you don't want to. If launched with a ROM name, Stella will not use the launcher and instead go directly to the ROM. That also means that other people can create OSX-specific frontends if they want; the internal one can be overrided.

 

We may change this for a future release, depending on how many requests we get. But AFAIK, x26, StellaX and KStella frontends all work this way.

[NE146]

The frying and cheat support sound very interesting! I will definitely have to try this out once I get home

[+stephena]

The frying and cheat support sound very interesting!  I will definitely have to try this out once I get home

949861[/snapback]

Just a reminder that (as described in the changelog) the cheat support is very preliminary. That means a little window pops up and you can enter a cheat. The cheats can't be saved, and they are one time, meaning they aren't applied per-frame. See the included cheat.html manual for more info.

 

This will all change in the next release, where Stella will support a database of cheats, which can be saved, applied per-frame or one-time, enabled/disabled using a GUI, etc.

[vdub_bobby]

Does Stella 2.0 require more horsepower to run at full speed? I could run Stella 1.4.2 at full speed fullscreen and windowed (at any/all zoom settings) but Stella 2.0 will not run at full speed unless it is in the smallest window.

 

???

[+stephena]

Does Stella 2.0 require more horsepower to run at full speed?  I could run Stella 1.4.2 at full speed fullscreen and windowed (at any/all zoom settings) but Stella 2.0 will not run at full speed unless it is in the smallest window. 

 

???

949893[/snapback]

What OS are you using? And on what type of hardware (video card and CPU)? I'll bet you're using Windows, right? We did switch from using partial dirty rects in Win32, because it seemed faster to do so. Perhaps that assumption was mistaken??

 

Just to make sure, you're not using OpenGL mode on a non-OpenGL system, are you?

[+Nathan Strum]

We may change this for a future release, depending on how many requests we get.

 

Put me down as "1".

[vdub_bobby]

Does Stella 2.0 require more horsepower to run at full speed?  I could run Stella 1.4.2 at full speed fullscreen and windowed (at any/all zoom settings) but Stella 2.0 will not run at full speed unless it is in the smallest window. 

 

???

949893[/snapback]

What OS are you using? And on what type of hardware (video card and CPU)? I'll bet you're using Windows, right? We did switch from using partial dirty rects in Win32, because it seemed faster to do so. Perhaps that assumption was mistaken??

 

Just to make sure, you're not using OpenGL mode on a non-OpenGL system, are you?

949898[/snapback]

I really don't have a clue about modern hardware and stuff. But this is what I found after poking around a little:

Windows 2000

Intel® Pentium ® 4 CPU 1.80 GHz AT/AT COMPATIBLE 523,755 KB RAM

RADEON 7000 / RADEON VE

 

And no, not using OpenGL mode. I tried that and it looked terrible and didn't run any faster.

 

And mark me down for a request for changing the front end. Actually, I can handle keeping all the roms in one directory, but the alphabetical sort in the listing drives me nuts since it sorts all lower case letters after ALL upper case letters. Makes it a pain for development, since generally all WIP roms have an initial lower-case letter and don't have an associated .pro entry.

 

And speaking of .pro entries and development...developing a paddle game using Stella is so annoying that I can't imagine anyone doing it: since the .pro entries are based on MD5 checksum, which will change everytime you change your code, every time you make a modification to your code you have to create a new .pro entry before you can test it in Stella. This would be MUCH easier if you could have .pro entries load based on filename also.

 

Did that make sense?

[+stephena]

Does Stella 2.0 require more horsepower to run at full speed?  I could run Stella 1.4.2 at full speed fullscreen and windowed (at any/all zoom settings) but Stella 2.0 will not run at full speed unless it is in the smallest window. 

 

???

949893[/snapback]

What OS are you using? And on what type of hardware (video card and CPU)? I'll bet you're using Windows, right? We did switch from using partial dirty rects in Win32, because it seemed faster to do so. Perhaps that assumption was mistaken??

 

Just to make sure, you're not using OpenGL mode on a non-OpenGL system, are you?

949898[/snapback]

I really don't have a clue about modern hardware and stuff. But this is what I found after poking around a little:

Windows 2000

Intel® Pentium ® 4 CPU 1.80 GHz AT/AT COMPATIBLE 523,755 KB RAM

RADEON 7000 / RADEON VE

 

And no, not using OpenGL mode. I tried that and it looked terrible and didn't run any faster.

 

And mark me down for a request for changing the front end. Actually, I can handle keeping all the roms in one directory, but the alphabetical sort in the listing drives me nuts since it sorts all lower case letters after ALL upper case letters. Makes it a pain for development, since generally all WIP roms have an initial lower-case letter and don't have an associated .pro entry.

 

And speaking of .pro entries and development...developing a paddle game using Stella is so annoying that I can't imagine anyone doing it: since the .pro entries are based on MD5 checksum, which will change everytime you change your code, every time you make a modification to your code you have to create a new .pro entry before you can test it in Stella. This would be MUCH easier if you could have .pro entries load based on filename also.

 

Did that make sense?

949920[/snapback]

I'll have to check out this hardware combo. If you're willing, I can send you a modified version of Stella 2.0 with the old rendering method, to see if it works faster for you.

 

I can easily change the sorting to mix upper and lower case ROMs correctly.

 

As for the paddle issue, you can do 'stella -lc paddle ROMNAME' and have it use the paddle for the left controller (lc). This will override what the .pro file says. Or edit the controller type within Stella through "Game Properties", and then do a game reload (Ctrl-R).

[mos6507]

It crashes with a runtime error when I hit F12 on the Windows version. What is F12 supposed to do?

 

Also, I tried using it to open a zip file of Colony7 but it wouldn't work. Do zips only work if the only content of the zip is the bin? Colony7 had the sourcecode in there also.

[Room 34]

Sweet! First thing I did when I saw this was jump over to http://stella.sourceforge.net.

 

I'm very happy to see the Mac OS X version available right along with all of the others!

 

Since I am sick in bed for tonight and probably tomorrow with a fever of 103 (yes, I am "hot blooded"), this will probably get some serious attention!*

 

 

 

 

*That is, it will receive serious attention for as long as I avoid falling into a delirious stupor. I can actually feel the heat emanating from my face...

 

Edited October 17, 2005 by Room 34

[vdub_bobby]

I'll have to check out this hardware combo.  If you're willing, I can send you a modified version of Stella 2.0 with the old rendering method, to see if it works faster for you.

Sure.

I can easily change the sorting to mix upper and lower case ROMs correctly.

 

As for the paddle issue, you can do 'stella -lc paddle ROMNAME' and have it use the paddle for the left controller (lc).  This will override what the .pro file says.  Or edit the controller type within Stella through "Game Properties", and then do a game reload (Ctrl-R).

Thanks, and - I looked and I couldn't find a command-line switch that would turn on paddles; guess I should have looked again.

 

Of course, no front end though.

[+stephena]

It crashes with a runtime error when I hit F12 on the Windows version.  What is F12 supposed to do?

 

Also, I tried using it to open a zip file of Colony7 but it wouldn't work.  Do zips only work if the only content of the zip is the bin?  Colony7 had the sourcecode in there also.

949952[/snapback]

F12 takes a snapshot. I'll have to investigate why it crashes. What version of Windows are you running? And what type of CPU?

 

As for the other problem, oops It only looks at the first thing in a zipfile, which isn't necessarily a bin/a26 file. This was supposed to be fixed before the release, but I forgot about it.

 

Seems like a .0.1 version will be coming.

[+stephena]

Thanks, and - I looked and I couldn't find a command-line switch that would turn on paddles; guess I should have looked again.

It's listed in the manual, and from the the commandline with 'stella -help'. All properties in Stella can be overridden from either the commandine or with 'Game Properties'. There should never be a need to manually create a .pro entry.

[keilbaca]

Great, cheats.

 

Time to scratch Stella 2.0 off of the HSC allowed emulators list.

[+stephena]

Great, cheats.

 

Time to scratch Stella 2.0 off of the HSC allowed emulators list.

950058[/snapback]

Well, you knew this was coming with the debugger. Even if I disabled cheats, one could still use the debugger and either modify RAM or patch the ROM. Come to think of it, one could patch a ROM anyway even without the debugger, and it would achieve the same effect. Or you could modify the snapshots, to make it seem like you got a higher score.

 

You really should scratch all emulators off the HSC. Once you have a hardware simulation underneath a ROM, you can pretty much do anything. And based on the number of requests I was getting for a debugger, it was only a matter of time.

 

Edit: Also forgot to mention that Stella has had save state support for over a year. That's another reason why it shouldn't have been used in contests.

 

It may seem strange that I'm saying not to use Stella, but I really feel that contests should be restricted to real hardware, and the progress of an emulator shouldn't be held back because of it. Because like I said, once you simulate the hardware, you're already cheating.

Edited October 18, 2005 by stephena

[keilbaca]

Great, cheats.

 

Time to scratch Stella 2.0 off of the HSC allowed emulators list.

950058[/snapback]

Well, you knew this was coming with the debugger. Even if I disabled cheats, one could still use the debugger and either modify RAM or patch the ROM. Come to think of it, one could patch a ROM anyway even without the debugger, and it would achieve the same effect. Or you could modify the snapshots, to make it seem like you got a higher score.

 

You really should scratch all emulators off the HSC. Once you have a hardware simulation underneath a ROM, you can pretty much do anything. And based on the number of requests I was getting for a debugger, it was only a matter of time.

950065[/snapback]

 

I fully agree with the whole not using emulators altogether, but not everyone has every game, especially the rare/homebrew ones, or has enough cash for a cuttle cart/2/krok cart.

 

Its very cool you added it, and I think its great. It just can't be in the HSC though. Unless you add like a little message in the corner saying cheats enabled or something, and make it so its kinda transparent and display it over the game, then I say its fine.

 

But, its up to Ze_ro.

[+stephena]

Its very cool you added it, and I think its great. It just can't be in the HSC though. Unless you add like a little message in the corner saying cheats enabled or something, and make it so its kinda transparent and display it over the game, then I say its fine.

 

But, its up to Ze_ro.

950070[/snapback]

I think I discussed this with Ze_ro before. I can possibly add comments to a snapshot that says whether cheats were enabled, what version of Stella created the file, etc. But someone can always resave that file in Photoshop or something, and remove the comments. Or since all the emulators are open-source, they can edit the code directly.

 

Long story short; people who want to cheat are going to cheat. And there's no way around that one. Or if there is, I'll be glad to take a stab at implementing it.

[supercat]

You really should scratch all emulators off the HSC.  Once you have a hardware simulation underneath a ROM, you can pretty much do anything.  And based on the number of requests I was getting for a debugger, it was only a matter of time.

950065[/snapback]

 

What about having two Official Modes with the following features:

1. In Official Mode 1, all options not on a 2600 are disabled except shap-shotting the game state (which should not pause the action; the game state should be held in RAM until play is complete).
   
2. In Official Mode 2, "blank-screen" pause is allowed, and game state may be saved to files (with the game screen blanked)
   
3. Official Mode may be disabled at any time (perferably with an action that won't get performed accidentally), or Mode 1 may be switched to Mode 2. Switching Official Mode on when it was off, or switching from Mode 2 to Mode 1 would require restarting the ROM image.
   
4. Loading a game smapshot saved in Official Mode would indicate what mode was in effect when it was saved, but would exit Official Mode.
   
5. Game snapshots and screenshots saved in official mode should be tagged with the MD5 checksum of the loaded ROM image file being used (in the case of SuperCharger games, this may not be the same as the current code image).
   

Game contests could specify whether Official Mode 1 or 2 is required, and the MD5 checksums in screen shots and snapshots would help ensure that people were using the correct ROM images (this could be useful, even in cases where people aren't deliberately cheating, if a game has been released in more than one ROM version).

 

Although IMHO game contests should allow games to be played on real hardware, adding an Official Mode to an emulator would help emulator entries to receive the status they deserve.

[keilbaca]

You really should scratch all emulators off the HSC.  Once you have a hardware simulation underneath a ROM, you can pretty much do anything.  And based on the number of requests I was getting for a debugger, it was only a matter of time.

950065[/snapback]

 

What about having two Official Modes with the following features:

1. 
    
    
    
    
   
2. In Official Mode 1, all options not on a 2600 are disabled except shap-shotting the game state (which should not pause the action; the game state should be held in RAM until play is complete).
    
    
   
3. In Official Mode 2, "blank-screen" pause is allowed, and game state may be saved to files (with the game screen blanked)
    
    
   
4. Official Mode may be disabled at any time (perferably with an action that won't get performed accidentally), or Mode 1 may be switched to Mode 2. Switching Official Mode on when it was off, or switching from Mode 2 to Mode 1 would require restarting the ROM image.
    
    
   
5. Loading a game smapshot saved in Official Mode would indicate what mode was in effect when it was saved, but would exit Official Mode.
    
    
   
6. Game snapshots and screenshots saved in official mode should be tagged with the MD5 checksum of the loaded ROM image file being used (in the case of SuperCharger games, this may not be the same as the current code image).
    
    
   

Game contests could specify whether Official Mode 1 or 2 is required, and the MD5 checksums in screen shots and snapshots would help ensure that people were using the correct ROM images (this could be useful, even in cases where people aren't deliberately cheating, if a game has been released in more than one ROM version).

 

Although IMHO game contests should allow games to be played on real hardware, adding an Official Mode to an emulator would help emulator entries to receive the status they deserve.

950077[/snapback]

 

Also adding to that, in Official Mode 1, disable print screen, and when you take a snapshot, it prints either HSC or High Score Club, or something similar directly onto the picture.

 

EDIT: Maybe even with this, say when you take the print screen it will say Official mode 1 or something, and then it can be a official way to do scores for the Twin Galaxies!

Edited October 18, 2005 by keilbaca