The future of the Stella emulator

[+stephena]

Again, thanks for the support. I think what brought all this on is that I really need to take a break. I've been working non-stop for the past 6 months on home renovations (after working a full-time job during the day), and plus everything else going on and trying to get the next release of Stella out as well, I guess it's the straw that broke the camels back. As I've said, stepping back from something is an area I really need to work on. It's an OCD thing I think; I just need to work on something until it's finished. But I'm coming to realize that Stella will never really be finished and perfected, and thinking about it that way is going to drive me insane.

 

Anyway, I can say the words, but following through on it is something else. I'm going to take at least a two week vacation from everything, starting this Monday. That means no work on Stella, no work on the house, greatly reduced Internet, and (since I have vacation time coming up) no work on my real job either. Those of you that have read my posts in the past probably know I've said this before, but this time it's different. I feel if I don't step back from stuff, something is going to crack (not the least of which is my sanity). It's going to be hard, but it has to be done. I look forward to at least two weeks of basically vegetating in front of the TV, or doing some gardening work, or something other than computers.

 

See you soon, but hopefully not before July 4

[dwane413]

Hope you enjoy your vacation.

[+Nathan Strum]

Agreed - enjoy your time off. If you can manage it, I find it helps to get away. A change of scenery usually does wonders for me.

[Thomas Jentzsch]

Enjoy your vacation. I am myself talking an out-time from job and Internet etc. every year for three weeks. That really, really helps!

[+stephena]

OK, my vacation officially starts tomorrow. If anyone sends me messages and doesn't get a response for 2 weeks or more, then don't worry. I won't be checking AtariAge during this time, and probably not even checking my email. Or at least that's the intent; we'll see how it goes.

[ClassicGMR]

Enjoy your vacation!

Edited June 19, 2011 by ClassicGMR

[+Random Terrain]

I won't be checking AtariAge during this time, and probably not even checking my email. Or at least that's the intent; we'll see how it goes.

Good luck. The Internet is my daily vacation.

[Noelio]

Hey Steve,

 

Stella has always been my go-to 2600 emulator. Your work maintaining it over the years is definitely much appreciated by all and it still blows me away that a fellow Newfoundlander is on the case! You should pop a "made right here" logo in there somewhere.

 

As for software rendering support, I would nail down maybe one more release for it and give notice that it's the stella.x.x.software.render.FINAL and kill it. Stella, in its various versions, has been running perfect for me for an easy decade with no noticeable hiccups. If necessary, I don't mind rolling back to an older version for older hardware & software rendering etc.

 

"Great job m'son!"

 

PS: I'm going to do a little digging but I think I may have a 7800 here that I would be glad to donate. It would be a great opportunity to meet you as well. I've got my personal one that I must keep but I've also got a couple spares in unknown states of repair. I'll look into it either way but I'm in the process of renovation right now and everything is buried in boxes so it might take a little time to get to it.

[Keatah]

Stella is officially sanctioned by David Crane of Activision. He says to download it and ALL the roms!

 

 

49:09

Edited June 26, 2011 by Keatah

[potatohead]

Excellent! That's pretty cool for him to just put it out there like that. He knows it's still a lot of fun.

[+Random Terrain]

Stella is officially sanctioned by David Crane of Activision. He says to download it and ALL the roms!

You can make a video jump to the place you want:

 

http://www.youtube.com/watch?v=MBT1OK6VAIU&rel=0&fmt=35&start=2966

 

 

Add this to the end of a YouTube link: #t=49m26s [that's 49 minutes, 26 seconds]

 

Add this to the end of an embedded video link: &start=2966 [which is (49 x 60) + 26]

 

 

The video above will jump to 49:26 when you click the play button.

Edited June 27, 2011 by Random Terrain

[SeaGtGruff]

You can make a video jump to the place you want:

Thanks for that info, RT! Very useful to know.

 

Michael

[+Nathan Strum]

High praises from David Crane, indeed.

[Omegamatrix]

Stephena, this is a real big thank you from myself for all your hard work. Without Stella I wouldn't have been able to do half the hacks and programming that I have. I say move the emulator forward, and let other people finally upgrade their machines.

 

 

 

Jeff

[Thomas Jentzsch]

While Steven is enjoying his well deserved break, I have a feature request for developers:

 

Step back

 

Often you recognize errors in the debugger after they occurred. So it would be really helpful if you could step back then. A single frame alone would be very helpful, other options like more than one frame or e.g. stepping back to the start of a subroutine would be icing on the cake, but nevertheless helpful too.

 

I have no idea how complicated to implement that would be. I guess maybe saving all registers and ZP RAM at the start of a frame would be sufficient in most cases.

 

Alternatively a trace file like the one z26 creates would allow stepping back too, just not that comfortable.

[SeaGtGruff]

Step back

It seems like maybe to do this properly-- ideally, being able to step back an instruction at a time-- you'd need to save the status register after every instruction, not to mention the state of any RAM, the RIOT timer, all the CPU/TIA/RIOT registers, bank selections, input ports, collisions, etc.

 

I see what you mean about maybe just saving one snapshot of everything at the beginning of each frame, so you could at least back up one frame and start going forward again from there. But if you don't yet know what caused the error, could you rule out things like "the joystick was pressed in direction A at the wrong time"? If it were possible to save an actual cycle-by-cycle stream of all the data needed to truly "rewind" a program one cycle at a time, including rewinding any input, that would be awesome, but probably too resource-intensive-- unless you could perhaps save the stream to a "RAM disk" or memory block (rather than, say, writing it to the hard drive), but have a set length for how much you could save before the stream "wrapped around" and started to overwrite itself-- like you could always rewind up to a maximum of one or two frames, maybe depending on how much memory you've told Stella to allocate for your "virtual tape recorder" (or "virtual state recorder"? ) data stream.

 

Michael

[+stephena]

Step back

It seems like maybe to do this properly-- ideally, being able to step back an instruction at a time-- you'd need to save the status register after every instruction, not to mention the state of any RAM, the RIOT timer, all the CPU/TIA/RIOT registers, bank selections, input ports, collisions, etc.

 

I see what you mean about maybe just saving one snapshot of everything at the beginning of each frame, so you could at least back up one frame and start going forward again from there. But if you don't yet know what caused the error, could you rule out things like "the joystick was pressed in direction A at the wrong time"? If it were possible to save an actual cycle-by-cycle stream of all the data needed to truly "rewind" a program one cycle at a time, including rewinding any input, that would be awesome, but probably too resource-intensive-- unless you could perhaps save the stream to a "RAM disk" or memory block (rather than, say, writing it to the hard drive), but have a set length for how much you could save before the stream "wrapped around" and started to overwrite itself-- like you could always rewind up to a maximum of one or two frames, maybe depending on how much memory you've told Stella to allocate for your "virtual tape recorder" (or "virtual state recorder"? ) data stream.

 

Michael

I'm back! Well not yet really, it will be another week or two before I start coding again WRT rewind, this has been a frequently requested feature, and one that I've been considering for some time. Your description here is exactly what Stella currently does. When entering the debugger, each step performed (whether by a single instruction, a frame, or a scanline) saves the entire state of the emulation in a memory-backed data stream. That is, it's never written to disk, and recycles when it reaches the end (so the oldest state is thrown away). Then, each time you do a rewind, you simply step back one in the state queue and do a state load. It's actually a very simple concept. The main problem right now is that it's only done when you enter the debugger, usually after a bug has been triggered.

 

To have it work in the general case, you'd need to save states at each appropriate interval, or what I call the 'resolution' of the states. If you want to be able to step back a single instruction at a time, then obviously you need instruction-resolution. This one is the most intensive; it's basically a memory-based state save each time the PC is executed. Scanline and frame resolution follow the same idea, but are done less regularly. To be honest, I've never actually tried it, so my thoughts that it is intensive are just a gut feeling at this point. On a fast enough PC with enough memory, it might not even be an issue.

 

Note that this brings together several other ideas, and also some problems. For example, being able to rewind a frame at a time (or perhaps a second/60 frames) in the general case is what other emulators do when you rewind while playing a game. That is, you come to a hard spot in the game, rewind a little, and try it again. However, there are also some problems, particularly with viewing the contents of the TV screen after a rewind. This is because there's no actual framebuffer, so if we rewind and play from that point, at that instant there's nothing on the screen! The screen won't be drawn fully until at least one frame later, so if you're rewinding a single instruction at a time and then inspecting what that instruction would do when you step ahead, you won't necessarily see anything. BTW, this is also why I have difficulty implementing another feature; toggling TIA objects while the game is paused. You can change the object easily enough, but you won't necessarily see the change until the next frame.

 

I get around this in the debugger by saving the TIA virtual framebuffer as part of the state file. I cheat in the general case (ie, a normal state save) by leaving off the TIA framebuffer, because I know that once the state is loaded, the emulation loop is running and it will quickly regenerate the display. I suspect that if you were to load a normal state file while in the debugger, you'd see what I mean. Since it doesn't contain the TIA framebuffer, the display would go blank for awhile.

 

Anyway, the reason I bring this up is that saving the TIA framebuffer adds perhaps 50KB to the state file, which would normally be 1KB or less. So there are potential performance issues, and almost definitely memory issues. More feedback and testing is required for this ...

 

FInally, I assume you haven't seen the Stella code, and if not, good job on independently coming up with the state load/save algorithm that Stella is using

 

 

EDIT: OK, now you've got me started

 

Another option I've considered is not saving the state at all, or at least not the full state every single time. If we could instead save a full state at some larger resolution (say each frame) and then save events (with timestamps), a rewind could theoretically be done at any resolution. That is, if you want to rewind to the previous frame, just back up and you're done. If you want to rewind to the previous instruction, back up to the previous frame and then play until you reach the CPU cycle that you're looking for. The same is true for a rewinding by one scanline; back up the entire frame and then play until just before the scanline starts.

 

I didn't go with this idea for two reasons. First, saving the entire state each time in a brute-force fashion is much easier to understand and implement, and second, I wasn't entirely sure that it is deterministic (that is, if you rewind and play forward, will it always give the same results).

 

Now that I think of it, this would probably solve the TIA framebuffer issue too, since it would only be saved each frame, and not each instruction. And then pause could work too, since we could just rewind one frame, change the TIA objects, and then play ahead one frame. You'd be in the same place as before, but with the objects changed

 

Finally, the idea of logging events with timestamps is something I toyed with at one point. There's code in Stella save a stream of events (basically, the state of the controller pins in each frame), and then load that data. On load, it does a full state load, then updates the controller pins accordingly. This was going to be the basis for 'recording' a movie, except that the movie wouldn't be an actual video, but a file that one could open and let Stella play it for you. It worked well enough in initial testing, but I abandoned it because of lack of time, as usual.

[Omegamatrix]

Being able to step back from a breakpoint would be amazing if it could ever be implemented. I already use the debugger "rewind" all the time and IMHO it is one of the best features of Stella. Another feature I really like is seeing the absolute address a register is loading from. Thanks again for that, Stephena!!

[rxd]

Well I think Stella is awesome. Just had my Mame cabs pc die and replaced it with a Windows 7 64 bit pc and was surprised to see that there's a 64 bit version if Stella. Runs fantastic on my new pc and I couldn't be happier. Thanks for all your work.

[Kurt_Woloch]

Here's my take on Stella vs. z26, since I've used both emulators...

 

I think I started with Atari VCS emulation back in 1998 when I first got Internet access at work. At that time, z26 was a lightweight and working emulator, and Stella - as you mentioned - crashed on half of the ROM's because of unsupported instructions and such. Therefore, I started to use z26 and abandoned Stella. And as they say "Never change a winning team", I continued to use z26 until 2007...

 

In 2007 I got the PC I'm still using at home, which came with Vista pre-installed. That's when I realized that z26 didn't run on Vista (or at least I couldn't get it to work), but Stella did. So I switched over to Stella, and since it now worked great and didn't crash on half of the ROM's anymore, I continued to use it until today. I also have to say that I haven't done much software development lately, so I didn't really think about which emulator was best for development needs. For the time when I started, z26 was best, and now I use Stella and don't really have a reason to switch. We'll see if things change once I'm somehow forced to move up to Windows 7 (I moved down to XP after using Vista for a bit more than a month due to a missing scanner driver and some other oddities). If Stella works on Windows 7 (and since it worked on Vista, there's no reason to assume it won't work on 7), I'll probably continue to use it.

 

The main function still for me is to emulate the 2600 and all its games correctly, without crashing. Features like filtering or video recording aren't that important to me.

 

In closing, I want to thank you for having developed Stella, and even if it doesn't evolve further, it's definitely a great emulator. I think the most important thing would be to "keep it running" which actually isn't that much work, I think, but only ensuring it works on current hardware and the most important current OS's (which for me is still Windows XP, but might soon be Windows 7, and apparently already is in some countries).

[Keatah]

For the time when I started, z26 was best, and now I use Stella and don't really have a reason to switch. We'll see if things change once I'm somehow forced to move up to Windows 7 (I moved down to XP after using Vista for a bit more than a month due to a missing scanner driver and some other oddities). If Stella works on Windows 7 (and since it worked on Vista, there's no reason to assume it won't work on 7), I'll probably continue to use it.

 

The main function still for me is to emulate the 2600 and all its games correctly, without crashing. Features like filtering or video recording aren't that important to me.

 

In closing, I want to thank you for having developed Stella, and even if it doesn't evolve further, it's definitely a great emulator. I think the most important thing would be to "keep it running" which actually isn't that much work, I think, but only ensuring it works on current hardware and the most important current OS's (which for me is still Windows XP, but might soon be Windows 7, and apparently already is in some countries).

 

What he said, the same with me.

I used the Activision Action Packs (on win 3.1 and win95 i believe), then I got sophisticated and moved into PCAE, and upgraded to Z26. About 4-5 years ago I switched to Stella. I have not considered anything else for 2600 emulation since. I'll of course look at new emulators and evaluate them if and when they come out. But it isn't likely that any will surpass Stella anytime soon. Case in point, I was totally disappointed with what I saw in the last Z26 iteration recently, and, comparing the two, I think you'll agree that Stella is indeed the premiere VCS emulator.

 

As far as keeping Stella running on current hardware and os'es. I don't think you got much to worry about. Stella code isn't going to magically explode some day and all of a sudden stop working, right? Modern hardware is powerful enough to virtualize and emulate older operating systems; so if bad comes to worse and Stella has had its last update. You can always fall back on the sandbox and virtualization. At third option is to keep some legacy hardware around. And a forth option is to dual-boot into an older o/s.

 

Besides, I sort of already do that with M.A.M.E. I have to run an older DOS version of MAME(0.37b6) within DOSBOX on my xp machine. I use 0.37b6 because it is the last version of MAME that runs Liberator correctly. So it's an emulator within an emulator.

 

One thing though, is tablets and slates. As the future gets closer there could be a situation like this arising for Stella. I can see a lot of existing software not working on the new generation of tablets. Re-writes and re-compiles are going to be necessary if you want to spend a night on the town with a tablet. Or tablets will need to support older os'es. Either way, it won't happen overnight and there is plenty of time to find a solution!

 

Well now, having said all that I'm going to go play some Slot Racers and Air-Sea Battle!

[+stephena]

First of all, thanks again for the words of support. Obviously many people are using and enjoying Stella, but it doesn't always seem that way when you're the lone person working on a project without much feedback. Anyway, I'm (sort of) back from my vacation. I say sort of, since I'm back to working on the house. One more room to go. So Stella development will have to wait a little longer.

 

In any event, here's my preliminary plan for the next major release, from most important on:

 

1) Move to OpenGL as the default rendering system. Software mode will stay around for now in the fallback case, but it will be neutered. No advanced filtering, no zoom levels above 2x, etc. Basically, I want to gently encourage users to move to OpenGL. But if they absolutely can't, at least there will be a (featureless) fallback.

 

2) Related to (1), add Blargg NTSC filtering, and remove the current TV filters. This new filtering should be faster than the current ones, and more realistic. To get an idea, have a look at the Atari800 emulator, where most of the code/inspiration will come from).

 

3) Rewind support in the general case. That is, rewind works anywhere, both during a game (to go back past a difficult spot) and in the debugger (so that you can go backwards from a breakpoint).

 

Numbers (1) and (2) are relatively easy. I can see some potential issues with (3), but it would be very cool to get it working. But you might end up needing a more advanced system to use the feature (a faster CPU and/or more RAM than currently required).

 

And a few other things as spring cleaning for 4.0:

 

1) Support for Windows 98/2000 will be dropped. Since we're moving to OpenGL as the default and since those older OS's usually don't have OpenGL, it doesn't make much sense to continue. A final 3.x release will be available for those still using 98/2k. Sorry guys, it's been 11-13 years, and AFAIK most other emulators only work on XP and above.

 

2) I'll probably be moving to OSX Lion soon, which has a new version of Xcode. So the default-released version of Stella for OSX will be Intel-only, 32 & 64-bit. It will probably require either Leopard or Snow Leopard at minimum. However, unlike the case with Windows 98/2k, older versions of OSX/Xcode do have OpenGL, so I'll still do a PPC release (at least as along as I can keep Xcode 3.x working in OSX 10.7).

 

Overall, I think that concentrating on the parts of Stella that interest me and removing some of the cruft will give me more motivation to continue with development. I know it means some people may be left behind, but I am only one person; my time is limited and I need to decide how to best manage it. Otherwise, I'll run out of time completely and have to stop development altogether.

 

Finally, thanks for the offer(s) for a 7800 system. Someone has (in the process) generously donated a system. I'll post more info when I get it set up.

[+batari]

What version of OpenGL are you using?

 

I can see the logic here for dropping Win98 but not Win2k - Many of the OpenGL video cards have a single driver for either Win2k or WinXP. I think the reason newer emulators support XP and above is because the newer M$ compilers produce code that doesn't run under Win2k. Is that driving the change?

[+thegoldenband]

I'll probably be moving to OSX Lion soon, which has a new version of Xcode. So the default-released version of Stella for OSX will be Intel-only, 32 & 64-bit. It will probably require either Leopard or Snow Leopard at minimum. However, unlike the case with Windows 98/2k, older versions of OSX/Xcode do have OpenGL, so I'll still do a PPC release (at least as along as I can keep Xcode 3.x working in OSX 10.7).

Since Snow Leopard won't run on PPC, you can definitely drop PPC support if Stella comes to require it! Leopard is viable, though I personally have stuck with Tiger since it's generally faster on PPC hardware.

 

Also, most configurations using Tiger or Leopard only support OpenGL 1.5 and below. You probably know all about this, but there's a handy chart on Apple's website that I found during the last month, and which finally clarified some of my confusion regarding OpenGL support on OS X. My PowerBook G4 will handle OpenGL 2.0 if I boot into Leopard (I normally run Tiger), but there's definitely a speed penalty if I run more than one or two of the graphics filters. So here too, if you'll be using anything that requires features from OpenGL 2.1 or higher, you can probably drop PPC with a clear conscience.

 

I can't speak for any other PPC users, but really, the only thing I'd love to see before PPC's retired completely is a fix for games with TIA bugs or quirks, like Kool-Aid Man, so that they can run without being patched. I don't know if that's realistic, but if we have an emulator that can run the entire classic-era library without problems, then we'd be very well taken care of indeed.

 

BTW, how close is Stella to supporting some of the features used by folks at TASVideos and other tool-assisted speedrun sites? I'd love to see a "perfect" run of certain games, and am surprised that none of the TAS folks seem to have touched the Atari at all...

 

 

Thanks once again for all that you do!

[+stephena]

What version of OpenGL are you using?

 

I can see the logic here for dropping Win98 but not Win2k - Many of the OpenGL video cards have a single driver for either Win2k or WinXP. I think the reason newer emulators support XP and above is because the newer M$ compilers produce code that doesn't run under Win2k. Is that driving the change?

Right, I group 98 and 2000 together because they need an older version of Visual Studio (2005). Getting rid of one implies the other. Conversely, keeping 2000 means I may as well keep 98 too. But in general, getting rid of the separate build is the main issue. Also because it's all done in a VM, and I can't test it on real hardware anyway. The OpenGL thing is more for Win98.

 

EDIT: Forgot to mention, the basic OpenGL code in Stella uses OpenGL 1.x (maybe 1.5). The TV effects require OpenGL 2.0, but since they're being removed anyway, the requirement is still 1.x. I may have code to take advantage of 2.x features (like FBO/PBO), but it won't be absolutely required.