Stella 3.7 released

[+stephena]

Ok, it's time for another Stella release. I'm glad to say that Blargg TV filtering is finally available There are also some other nice changes, and a few bug fixes. Perhaps the biggest change other than Blargg is that this release marks the retirement of the Win98/2000 port. Unfortunately, this decision is final, and that port won't be coming back. As for the Blargg TV effects, please keep the suggestions constructive. There is more work to do in this area, and there are definitely improvements to be made, particularly with respect to the scanline emulation. Anyway, here's the changelog:

 

• Added Blargg TV effects, with presets for Composite, S-video, RGB, and badly adjusted TV, and well as a custom mode with full configurability of contrast, brightness, gamma, etc. Many keyboard shortcuts and commandline arguments were added to support this; see the documentation for a detailed explanation. These effects are OpenGL-only. Special thanks to Ian Bogost and the Georgia Tech Atari Team for the preliminary implementation.
  
• Updated the CompuMate keyboard handler to recognize more keys on an actual keyboard, instead of having to remember the weird combinations used on the original CompuMate keyboard (although those original keys will continue to work). Related to this, fixed bug whereby 'ghost keys' would be detected by the CompuMate, particularly after pressing 'Enter' to start a game from the ROM launcher.
  
• Added emulation for MindLink controller using the mouse; the 'Bionic Breakthrough' and 'Telepathy' ROMs now work.
  
• Updated FA2 bankswitch scheme (Star Castle) to emulate load/save high score functionality to the Harmony cart flash RAM.
  
• Added ability for ROM launcher to 'descend' into ZIP files when it contains more than one ROM file. This means you no longer have to unzip a multi-file archive before using each ROM. Thanks go to Roland Schabenberger (webOS maintainer) for this idea and sample code.
  
• Several improvements to the debugger/disassembler:
  - The 'resolvedata', 'showaddr' and 'gfxformat' commandline arguments are renamed to start with 'dis', indicating that they're used with the built-in disassembler.
  - Zero-page code addresses no longer have their high-byte truncated, and system equates (TIA and I/O registers) are now properly marked as such.
  - The Distella '-r' option (Relocate calls out of address range) is no longer the default, resulting in output more consistent with normal usage of Distella. Related to this, added the '-dis.relocate' commandline argument (and associated UI item) to toggle this dynamically.
  
• Fixed bug in EFSC bankswitch scheme state saving; the Superchip RAM wasn't actually being loaded and saved to state files.
  
• Improved speed of loading and saving state files, as well as slightly reducing their size. Because of this, old state files will not work with this release.
  
• Replaced commandline argument 'uselauncher' with 'exitlauncher'. The new option specifies the behaviour of the ROM launcher when exiting a ROM (always exit to launcher, or only when the launcher was actually used). This setting can now be changed in the GUI.
  
• Several updates to the internal properties database:
  - 'Juno First' ROMs now use an AtariVox/SaveKey when possible
  - 'Astroblast' ROMs now use the paddles by default
  - 'Star Castle 2600' ROMs added
  
• Changed key-combo for enabling TIA objects and collisions to be toggled on and off with the Alt-period and Shift-Alt-period respectively (instead of having two separate keys to turn them on and off).
  
• When working on the commandline, relative filenames are now correctly handled (current working directory is used).
  
• The Windows 98/ME/2000 builds have been discontinued, due to code and features that are only available on Windows XP/SP3 and later.
  
• Updated included PNG library to latest stable version.
  

 

As usual, Stella can be downloaded from the Stella homepage. Please consider a donation if you find Stella useful. Bug reports can be reported directly to me or in this thread.

[israelg]

Great !!!

 

I will try this later....!

 

Thanks,

 

I.G

[TrekMD]

Cool! Heading there now to get it.

[TwiliteZoner]

Thanks for all the work you do on this.

Edited June 1, 2012 by TwiliteZoner

[ClassicGMR]

Awesome. Will be grabbing this tomorrow when I get home.

 

Thanks stephena!

[+Random Terrain]

As for the Blargg TV effects, please keep the suggestions constructive.

 

That means he doesn't want people saying that Blargg sounds like the noise a pirate makes when he vomits.

[+stephena]

As for the Blargg TV effects, please keep the suggestions constructive.

 

That means he doesn't want people saying that Blargg sounds like the noise a pirate makes when he vomits.

 

Actually, I was hoping that the comments won't be "this is crap, it doesn't look like my TV"

 

EDIT: pirate comments are welcome

[Aegis]

Can't try it out right now (at work) - did the phosphor effects make it in? Either way, congrats Stephen and thank you!

[Keatah]

I have not looked at this exact release yet. But on the recent beta releases I've always preferred to set the scanline intensity to 10-20%. Anything else seems overkill. Now, having not actually seen a real 2600 on a real old-school CRT actually mfg in the 1970's *SINCE* the 70's, I don't recall ever seeing such "high-powered intensity" like when setting it to like 90 or 100.

 

These are settings that produce the best image, today, to me, on my existing monitors..

tv_filter = 5

tv_scanlines = 10

tv_scaninter = 1

tv_contrast = 0.46

tv_brightness = 0

tv_hue = -0.08

tv_saturation = 0.3

tv_gamma = -0.24

tv_sharpness = -0.44

tv_resolution = -0.16

tv_artifacts = -0.38

tv_fringing = 0.3

tv_bleed = 0.46

I can't believe the slight hue adjustment of a few ticks makes Video Pinball look perfect! I suppose that's because I could have grown up with it on a mal-adjusted CRT to begin with? Everybody says no, the hue should be 0.00, and I'm not color blind. In fact I can see colors nobody else can!

 

I don't like that the save-game-states are not compatible. I have a good number of them. I don't suppose there's a way to convert them over easily..?

Edited June 1, 2012 by Keatah

[Keatah]

Ok, I was unable to save and then load back a saved-state file. Even a fresh one. I'll go through stuff again, and see if I'm making any mistakes.

[Keatah]

I just have to mess with 3 keys, right?

F9- savestate

F10- change slot (toggle through 0-9)

F11- load state

Right..

I'll review my operating procedures and see if I'm making some dumb mistake. Or have a messed up config file, somehow.

[Keatah]

Well, I just tested 3.6.1 and it worked.

It saved state 0 and loaded state 0 fine.

 

In 3.7 I can't get it working..

It says "State 0 saved" when making a file.

it says "Can't open/load from state file 0" when trying to load a file.

 

Here's a save-state file, rom, and config from 3.7, generated today.

Enduro (1983) (Activision) 3.7.zip

Edited June 1, 2012 by Keatah

[+stephena]

!@*#&, arrgh on state files. Confirmed in Windows, but not in Linux or OSX. In fact, I'm able to load the state file you send in Linux perfectly fine. I guess there'll be a 3.7a release for Windows very soon.

 

EDIT: OK, try downloading again (there's a 3.7a version for Windows which hopefully fixes this).

[Keatah]

The last version that worked for me was "Stella-3.7_svn-test4-windows.zip"

[Keatah]

Seems to be working fine in 3.7a, all states 0-9 saved and loaded for demon attack.

I'll dick more with it tonight.

Edited June 1, 2012 by Keatah

[Trebor]

stephena,

 

Awesome, just awesome! Using the 64 bit edition of 3.7a and it is fantastic. Personally, I use the custom setting matching composite with a change to artifacts. From the 50 setting to 5; or tv_artifacts = -0.9 as it appears in the ini. Nothing written in stone though, I'm sure there will be some more tweaking...lol.

 

Really amazing; between the Blargg effects being implemented and having a CX-40 with USB makes it near impossible to tell the difference between emulation and the actual hardware now, Seriously, Stella sounded like the real thing for years, now it actually looks like it as well....Amazing, and thank you!

[Keatah]

Yeh it's pretty slick eh? There's so many things right with how it's put together.

Folks at the Panera Bread cafe' are sometimes amused at these old games.

[Keatah]

This version uses a little more cpu power doesn't it? I can eco-clock this down to 610MHz, with phosphors and all effects going, before slowdowns occur. So that's going to be the minimum specification.

 

You should be informed that this program consumes 2.4 watts of power over the quiescent state of ~12.4 watts (includes 14" monitor mobo/cpu/hdd/ram/kybd/basic speakers).

 

1.9 watts goes to the CPU

0.3 watts goes to the graphics chip

0.2 watts goes to the rest of the motherboard, ram, southbridge, and sound.

 

Anybody care to figure monthly cost and do a comparison against a real VCS and CRT?

Edited June 2, 2012 by Keatah

[Shannon]

Schweet!

[+stephena]

Good to hear that it's working fine and that the effects are semi-accurate. As for phosphor mode, it is present, but it's just the same as in previous versions (in that it's an idealized representation, not a true emulation). But at least it's not a regression. Further research is required to more accurately emulate the effect; there really should be some flicker, whereas now there isn't any at all.

 

As for the changes in CPU usage, adding phosphor mode to Blargg effects does use more CPU compared to the last beta version (as well as using more RAM). But I suspect this is the new baseline. Even if/when I improve phosphor mode, it's likely to move some of the processing from CPU to GPU. So while it could eventually use less RAM, I don't think it will get any faster (but I'm pretty sure it won't get any slower either).

 

BTW Keetah, that breakdown makes sense. My eventual solution to the phosphor/Blargg problem was to do it all on the CPU, and that's why you're seeing more CPU usage. So from the POV of what the code is doing, it all makes sense. I don't really consider it a regression, though, since without the current approach I would have had to leave out phosphor mode entirely.

[israelg]

Anyone still thinks he will get better results using a real Atari connected a modern LCD TV ?

 

(No argue about real CRT TV)

 

Great work...!

 

Thanks,

 

I.G

[Omegamatrix]

I found a major bug, but I don't know what version it began in. It occurs both in 3.7 and 3.7a. I'm using Win7 64bit.

 

 

In my program I wrote an endless loop (on purpose, testing purposes). The game did not crash. It kept showing the previous frame as a frozen image. I checked in the debugger and it was indeed going through the endless loop, but on the screen everything looked fine.

 

 

I noticed something wrong yesterday when I was testing a homebrew for a friend (sorry can't share any details or screenshots). This rom was unrelated to my program, but the bug was there too. It showed up because in the homebrew one of the console switches is used to go between a PAL and NTSC display. When going PAL ---> NTSC you can see a portion of the PAL screen (from a previous frame) still at the bottom. It looks like the framebuffer does not get cleared. Here is a mockup of a completely unrelated photo to convey the idea.

 

 

 

Offhand, would it be hard to keep an array of the last 15 frame scanline counts, and then switch between PAL and NTSC when the average changes? I know right now Stella checks this first thing, and then it's locked in for the whole game.

[+stephena]

I found a major bug, but I don't know what version it began in. It occurs both in 3.7 and 3.7a. I'm using Win7 64bit.

 

It would be helpful if you could narrow down the version by trying the past few releases (in reverse order) to see where it started. Also, is this OpenGL or software rendering? If the latter, please try OpenGL mode. And speaking of software mode, I'll be phasing it out over the next year or so.

 

In my program I wrote an endless loop (on purpose, testing purposes). The game did not crash. It kept showing the previous frame as a frozen image. I checked in the debugger and it was indeed going through the endless loop, but on the screen everything looked fine.

 

Can you provide this test ROM, and a description of how it should look?

 

Offhand, would it be hard to keep an array of the last 15 frame scanline counts, and then switch between PAL and NTSC when the average changes? I know right now Stella checks this first thing, and then it's locked in for the whole game.

 

Improving display autodetection is actually on the TODO list, since I've seen other ROMs that can switch from NTSC to PAL at runtime, after the autodetection has already run. Another thing that must be fixed is switching formats with Control-f. Right now it just switches the palette, but it should also switch the display properties too (scanlines per frame, size of window, etc). It's the last one that's really causing me a problem, because if a ROM starts out in NTSC mode and later switches to PAL, the actual window will be too small and will have to be re-created. And I don't want to have a situation where there's a ping-pong effect, with the window constantly changing size. That's the part I have to think about. But in any event, I was planning on improving this for the next release.

[Omegamatrix]

Okay, test roms. I tried both software and open GL mode. Same results. Now I know Stella used to go into a black screen when you hit an endless loop, but I can't find any older versions of Stella to tell where the change began.

 

Start the endless loop rom, press RESET, and enter the debugger. You will see the endless loop, and that the display never changes.

 

For the NTSC vs PAL, the program starts in PAL mode by default. Press the black and white switch while it is running and you will get this:

 

 

StellaBugs2.zip

 

 

Also, the palette stays in PAL mode when you switch back to NTSC. In the photo both background colors should be green.

Edited June 3, 2012 by Omegamatrix

[Omegamatrix]

Forgot to say, but using ALT-L is very helpful in both roms. In the EndlessLoop rom you see the scanline count continually increase, but the screen image stays frozen. In the PAL_vs_NTSC rom you can clearly see PAL is 312 lines at 50 FPS, and NTSC is 262 lines at 60 FPS.