The future of the Stella emulator

[+stephena]

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.

OpenGL 1.5 will be the minimum requirement. As I stated above, I may take advantage of 2.x features when available, but they won't be the baseline. The hardest thing with doing a PPC build is having the older version of Xcode work with OSX 10.7. As long as it keeps working, I can do a PPC release as I'm doing now, which is compatible back to Tiger.

 

Just to be clear, Stella doesn't depend on the version of OSX you're using; it's totally platform-independent. It depends on the Xcode development environment being available for newer versions of OSX.

[ScumSoft]

There seem to be some inconsistencies in the way Stella and the real Harmony cart handle the DPC+ arm header code.

 

Stella I think is said to use it's own DPC+ routines and does a pretty good job getting things done, but bring the same DPC+ game onto the harmony and things start falling apart.

 

Is there a way to have stella ignore it's own internal DPCplus.arm routines and instead read the ones inside the games rom?

This would make DPC+ developing much nicer for all the new games coming out, as we could track down issues much quicker.

[littleman jack]

I hope you keep Stella around. It is a hobby for you, so don't stress too much. It works great as it already is now, so any changes you make are just icing on the cake. I use it with Linux and it works beautifully.

[+batari]

There seem to be some inconsistencies in the way Stella and the real Harmony cart handle the DPC+ arm header code.

 

Stella I think is said to use it's own DPC+ routines and does a pretty good job getting things done, but bring the same DPC+ game onto the harmony and things start falling apart.

 

Is there a way to have stella ignore it's own internal DPCplus.arm routines and instead read the ones inside the games rom?

This would make DPC+ developing much nicer for all the new games coming out, as we could track down issues much quicker.

The Thumb emulation in Stella is very minimal - it is not cycle-accurate, has no concept of peripherals, the 6507's buses, or anything except a bit of shared RAM, and it runs separately from 6507 code.

 

The DPC+ code in Harmony is written in ARM assembly, which is significantly more complicated. Also, to run the actual bankswitch code would require cycle-accurate emulation that is intimately synced with, and runs parallel to the 6507/TIA, has proper hardware hooks to the 6507's buses, and emulates many of the chip's peripherals. Due to these difficulties, Stella and Harmony will need separate implementations of DPC+ for the indefinite future.

 

It might be a bit of a pain to have to change and build Stella every time I change DPC+ on Harmony, but it's far easier than the alternative for now.

[+thegoldenband]

This reminds me of an issue I bumped into, namely that this "phaser" demo of mine, which sounds great on Stella (including the current version), didn't really work out on real hardware.

 

If your researches can help explain that, I'd be very interested, as it's pretty much beyond my technical ability to sort out what's going on. I assume it's got something to do with either the starting state of the TIA, or timing issues.

Sorry to threadbump, but I was just reading about someone else's struggles with a different sound chip (FM on the SMS) and it got me thinking about my issue. SeaGtGruff, did you ever happen to look into this? Or did anyone else? It's still beyond my skills to suss out exactly what's happening, but the effect just doesn't sound the same on real hardware.

[+stephena]

It seems to be time to revisit this thread. Sorry if the following seems like a rant, but I need to vent ...

 

It looks like I may be retiring from this project soon. Real life issues and occasional illness seem to be catching up with me. However, the main reason is that certain parts of it just aren't fun anymore. It wears me down just looking at those parts.

 

I speak specifically about the TIA emulation, and the fact that I just can't wrap my head around it I've been on vacation for the past week, and looking at it almost the whole time. Not to mention that I keep coming back to it year after year, as the problems first surfaced in 2008 or so (but in reality, have been with the code all along). I just don't understand how it works. And since I didn't write it, it's very hard to trace.

 

I've repeatedly stated over the past few months that 3.8 wouldn't be released until the TIA issues are fixed for good. Thinking back, I've been saying this for years. I have messages from 2006 or so saying exactly the same thing. I put it off and work on other features, hoping to come back to it and fix it. But it's like this huge, gaping hole that won't be filled. I never figure it out, and I'm constantly stressed out by it.

 

To be completely honest, the TIA was never my main area of expertise, nor the area I wanted to concentrate on. I'd rather work on the debugger, as that's more related to my real life work. But I can't seem to move on until the TIA issues are fixed, so I'm stuck. So there's only option I can see; retire from the project. I don't want to keep adding new features and always know in the back of my mind that the ??%#$#$# TIA work still needs to be done. I can't move past it; it keeps coming back to haunt me. And taking a temporary break won't help, because the problem will still be there when I get back.

 

It's too bad we don't have other people working on the project, or that there was a TIA engine that could come from another emulator, or something. I don't know what to do.

 

Anyway, I'm extremely discouraged at this point. I appreciate all the feedback I've gotten, and the generous donations that have come my way, but unless I can see some way forward, I have to get out soon. I have many ideas on how to improve other parts of the code, particularly the debugger and the various types of more esoteric controllers. But at this point, I can't move forward with new features, and I can't move past this major stumbling block.

 

Release 3.8 will be coming soon, without the TIA improvements. And I'm afraid it will be the last release from me.

 

[akator]

Thank you for all of the great work you have put into Stella over the years. Many people, myself included, appreciate your efforts.

[Keatah]

Agreed! You've done a hella'job these last years. Made this into the premiere VCS emulator, fer'sure. And while we're sad to see you go; you must do what's right for you. We hope you can still be a part of the community.

 

Anyone picking up the baton from here is going to have proud ship to steer. So many things are nicely done. And from a user's perspective not a lot needs to be re-worked.

Edited February 21, 2013 by Keatah

[Keatah]

Many projects of this nature have more than one working on it. Perhaps a collaboration is in order; and you become the team leader? We'd need a TIA expert to start with, and perhaps this would allow you to work on the debugger part as you say that's your most favorite.

 

And yet many times a program is often considered complete by the author after a good number of years. There comes a time when "forcing" yourself to work on something just to do it, just to make a release, really takes the fun out of it. Whatever it may be.

 

I've found that in a lot of my "stuff" I no longer get my hands dirty as much. But rather enjoy mentoring others and taking the big picture approach. It'd be like sending Bill Gates back to the assembly line. He'd do pretty badly there and not be happy me thinks.

 

I see this happening across this community more frequently this past 7 months. Sales of personal collections has been at an all-time-high. Innovations in software coming at a slower pace. Unique mods less frequently. Everything is tending to become "fixed in place" and follows a "safe", a "canned" formula that doesn't stray from the tried & true path too much. And yet, when new things are tried they're so fucked up and impractical that they're little more than jokes. This is a disturbing trend and one I'd rather not see gather momentum. And yet it is a natural progression.

 

While we've not done an in-depth study of software longevity (or programmer demographics) or anything like that, my lady says that the typical best-in-class software is turning out to have a 10-14 year lifespan. After that point it seems complete and done, ready to bear the mature mark.

 

There will come a time when all of us play our last game, power up Missile Command for one final time. And then no more. Can this be avoided for this project?

Edited February 21, 2013 by Keatah

[+stephena]

Thanks for the support. I'm extremely ambivalent about leaving it at this point, since there's still so much I'd like to work on, and I have some great ideas that I would have liked to see completed. I just wish I could get past this major issue.

 

I don't know, maybe I just need an extended leave, without any pressures or a deadline. Not that I'm complaining that anyone is pushing; I'm my own worst enemy here, pushing myself when I don't need to. Perhaps it's just temporary burnout, or perhaps it really is time to walk away from it all.

 

I just hate leaving when I've made promises to implement new features. And more than that, I want to implement these new features. I'm not tired of the project as a whole, just with the one part that's (frankly) kicking my ass. Maybe if I could get some help from a fellow developer in fleshing out what needs to be done, it would make me able to continue.

 

As I said, I'm really on the fence here. One moment I say I'm retiring, and the next I'm ready to continue working. Long story short: I want to continue, but not if I can't fix the remaining issues. It's been put off for too long, and if I can't do it, then the project should go to someone who can.

 

Thanks again for the words of support.

[Keatah]

These aren't merely words of support. They are exactly how it is.

 

In projects like this I simply compartmentalize the situation. Why not ENJOY working on the parts you're familiar with and WANT to work on anyways? And work on it at a slower more leisurely pace? I'm *still* tweaking a certain XP install I did from 2004, every now and then I find some new app or learn something new about how something works. But long ago it ceased to become about optimizing and "building-up" a killer system; but rather an organic thing that's taken on a life of its own and continues to grow over time.

 

While it's highly doubtful the CPU will ever be replaced with one that executes modern instructions, or that the graphics board will perform like a Haswell; The software environment is constantly evolving and continually up to date. And I continue to perform productive work now more than ever.

 

I've given up on making it go faster, naturally! But I'm quite ready to make the transition into something new when the time is right. Knowing the existing graphics and CPU has numbered days ahead doesn't stop me from updating the software or methodically maintaining the environment.

 

Separate out (in yo'head) anything and everything to do with TIA. Put it aside as one module. It's not your code to begin with - you said.. Polish up and add to everything surrounding it. And when the time comes the thorn of TIA stuff will resolve itself in a way you never expected. Be ready for it!

[Mirage]

What Keatah said. Make it known far and wide that you're looking for a TIA expert to take over that component. Then until that day comes, forget about it. Work on the other parts. If you don't quit, the rest of it gets better even though the TIA doesn't. If you do quit, the rest does NOT get better, and the TIA still doesn't! So, what difference does it make if you keep working, but don't work on the TIA? It doesn't. Set it aside. Keep plugging away and don't let the TIA woes stress you out -- at all.

 

Stella is way too good to give up on.

Edited February 21, 2013 by Mirage

[Gorfy]

As a regular user of Stella, I know that it works great. I'm very much appreciative of being able to try out various games I wouldn't be able to try otherwise. It enables me to play consistently in the 2600 High Score Club, which is a favorite hobby of mine. I want to thank you again for all the blood, sweat, and tears you've put into it over time. Also, I would like to caution you about being a perfectionist and having an exaggerated sense of responsibility regarding Stella. Take care of yourself first, whether that means getting a collaborator or just walking away from it.

[Thomas Jentzsch]

Stephen, all you need is someone who "wraps his head" around the TIA emulation and does the job for you. I think, before you completely abandon Stella, there should be people out there, who are able and willing to help.

 

Without promising anything, but I would be one of them.

[cd-w]

I really hope you will reconsider. It would be a real shame to see this fantastic emulator go stale. Stella is one of the main reasons that I find 2600 home-brew development enjoyable, thanks to the excellent debugger. I have often thought about coding for the 7800, but the lack of a proper emulator that works on Linux always puts me off (I have always hoped that you might extend Stella with 7800 support at some point). There would be far less 2600 home-brews if it were not for Stella.

 

I think the TIA emulation is already around 99% accurate? The only issues that I'm aware of are mid-line NUSIZx changes and some minor RESPx differences? Are there any other issues that need to be addressed? If the current implementation is difficult to understand, perhaps it would be more enjoyable to try a reimplementation, e.g. a gate-level simulation of the schematic?

 

Chris

[+Nathan Strum]

Just to add my voice to the chorus - I hope you'll find a way to continue to enjoy working on Stella. Just working on something out of a sense of obligation is a drag, especially when it seems like you can't get anywhere with it. So I hope you can find a happy medium, but more importantly, some extra help for the project. A single person working alone is what ultimately resulted in the death of MacMAME. I was really sorry to see that go away, but also really disheartened to see the programmer get so burned out carrying the load by himself that it had to get to that point.

 

If I had one suggestion, it would be that if you do walk away, don't completely close the door. Leave it open a crack, so if you do want to return, for whatever reason, you can. An indefinite leave, but not necessarily a permanent one.

 

Whatever way you go with it - I just want to say thanks for all your hard work on Stella. Programming is beyond me, so I really don't know what it takes to do it, but I have incredible respect for people who have that ability. I use Stella all the time - both for fun and for working on homebrews (that didn't come out quite right... but you get the idea ).

[Joe Musashi]

If the current implementation is difficult to understand, perhaps it would be more enjoyable to try a reimplementation, e.g. a gate-level simulation of the schematic?

 

That's an interesting idea. Even if a simulation of the whole TIA turns out to be too costly, doing it just for some parts (like the RES logic) may be possible. I think some MAME drivers do a simulation of discrete logic, there may already be some reusable code.

 

Anyway, it would be great to have a list of the known TIA bugs (ideally with reproducers). Just looked at http://stella.sourceforge.net/todo.php , but it does not list specific TIA problems.

[Thomas Jentzsch]

I am not sure if Stephen is prepared to do a full rewrite of the emulation core. It is obvious that at in the past he has preferred to improve the used and developer interfaces, support new bank switching scheme, overhaul the emulation presentation... And there he has delivered tremendous results.

 

So if we discuss those options, it should be clear that this should be done as a collaborative task and just not another big point of Stephens big to-do list. Because that might kill his motivation completely. Correct, Stephen?

 

Else I would prefer focusing on the known issues of the existing core and go for them first.

Edited February 21, 2013 by Thomas Jentzsch

[Omegamatrix]

If you ever need any test roms for the cause, you just have to ask Stephena! We want to see this through too (I've been wanting to play Meltdown for years).

 

 

Quite honestly, you're the one that knows Stella inside and out, so to begin maybe start a more technical thread of how the emulator core actually works for RESxx and NUSxx, how it implements those decisions and in what files, what are the pitfalls, and how you think it should work. That should start the gears turning at least.

[+Gemintronic]

I've hinted at these features to Stephen before but I thought I'd drop them here for posterity.

 

* Attach and use real SaveKey for homebrew testing. Also, using real SaveKey could be handy for saving your games/hi-score between PC and real 2600.

 

* iOS (iPad/iPhone) wrapper. For a cut of the sales on the iTunes store a single game Stella could be used. Stephen inserts your game - you provide your developers license to sign the wrapper and upload. You donate profits to Stellas maintenance

[+stephena]

I think Gorfy sums up my main issues at this point when he says " I would like to caution you about being a perfectionist and having an exaggerated sense of responsibility regarding Stella." It's true that I tend to concentrate on perfecting things, sometimes a little too much. It's probably an OCD thing, which is actually quite common in software developers. I'd be lying if I said that it didn't help me in my career, but I'd also be lying if I said that it hasn't been a double-edged sword that's cut as often as it's helped.

 

I don't mean to turn this into a thread on psychology, but I tend to be a goal-oriented person. I want to start something, finish it, then move on to the next thing. Now I don't mind revisiting parts of the code that have bugs; on the contrary, fixing something and improving it is what programming is all about. But when you work on a component, never fully fix it, drop it for a while, and then come back to it (and repeat ad nauseum), eventually it gets really annoying. At this point I want the issue fixed not just for the improvement in the project, but more-so that I don't have to think about it anymore. I just want it done. And I can't compartmentalize it, because it's been there for years, it's a fundamental aspect of the software, and it keeps popping back up.

 

I just want to make it clear that I'm not complaining about the quality of the code, or about the developers who've worked on it. It's an issue with my understanding of it; the problem is mine.

 

As for suggestions on completely rewriting it, I don't think (at least I hope) that it would be necessary. And in any event, that would make the problem even worse, in that it would suck even more of my time. I prefer to work on something already done, chip away at it and improve it, etc.

 

I think Thomas shares my view that it's better to work with what we have. Hell, someone experienced with this area could probably look at it and get it working in a week. If that happens, don't worry, I won't be offended or feel inadequate. I'd just be happy to have it fixed so I can concentrate on other things.

 

Anyway, I will be doing a 3.8 release, since it's already ready to go in a week or so. And I've already committed to debugger improvements for 3.9. After that, I don't know. It will really depend on the help I get, and whether the TIA issues can be resolved for good. I really hope I can continue.

 

To cd-w: the main issues at this point are indeed NUSIZx changes after drawing has already started, and associated RESPx changes. But there's a little more to it than that behind the scenes.

 

To theloon: Attaching and using a real SaveKey (and AtariVox) is already supported since 3.6 or so.

[Thomas Jentzsch]

To cd-w: the main issues at this point are indeed NUSIZx changes after drawing has already started, and associated RESPx changes. But there's a little more to it than that behind the scenes.

Maybe its time to add a TIA-todo list to SourceForge and/or to start a dedicated thread about them. The advantage with AA would be, that we can easier exchange screen shots, test files etc.

 

But a central bug list would be helpful too. If not at SourceForge, we could use the bug tracker here on AA (if that still exists, Albert should know).

[+stephena]

Maybe its time to add a TIA-todo list to SourceForge and/or to start a dedicated thread about them. The advantage with AA would be, that we can easier exchange screen shots, test files etc.

 

The TIA TODO list on Sourceforge is quite short since nobody else was working on it, I didn't feel the need to elaborate. Starting a thread here would probably be better.

 

But a central bug list would be helpful too. If not at SourceForge, we could use the bug tracker here on AA (if that still exists, Albert should know).

 

There was a bug tracker here that served exactly that purpose. But it has disappeared with recent updates to the forum software. I've contacted Al several times about either reviving the option or getting back the data it contained (to add elsewhere), but no answers so far.

 

I have no issue with starting a new thread about it. Do you think it belongs in the Emulation forum or elsewhere? And I will make it clear that I'm looking for more hands-on help, involving looking at the current code (C++) and helping to understand how it works. I can explain quite a bit of it, and the main functionality is restricted to perhaps 500 lines or so, so it's not a huge undertaking for someone who knows C/C++.

[Thomas Jentzsch]

There was a bug tracker here that served exactly that purpose. But it has disappeared with recent updates to the forum software. I've contacted Al several times about either reviving the option or getting back the data it contained (to add elsewhere), but no answers so far.

It was useful, but IIRC Albert had to manually maintain settings (versions, status etc.). Probably it became too much work for him.

 

I have no issue with starting a new thread about it. Do you think it belongs in the Emulation forum or elsewhere?

I think that would be perfect. If you are unsure, post a reference e.g. in the 2600 forum.

 

And I will make it clear that I'm looking for more hands-on help, involving looking at the current code (C++) and helping to understand how it works. I can explain quite a bit of it, and the main functionality is restricted to perhaps 500 lines or so, so it's not a huge undertaking for someone who knows C/C++.

That's my hope too.

 

At the beginning you should also describe how to setup a development environment for Stella.

 

BTW: Does any test framework exist for Stella? If not, I am sure there are people around who know some tools we could use. Without it might become a bit risky to touch the unknown code. The alternative would be tedious, repeated manual regression testing.

[dualcam]

I think the first step is getting a bug list of TIA issues. While I'm not a TIA expert, I have messed around a bit with the Stella code and have a general idea of what is going in the Stella code. Have also done a couple emulators from scratch of 6502 based hardware before. Certainly willing to have a crack at this, but don't know if or what I could help with without a list of what needs to be done. Important will be test case ROM examples and descriptions of the issues.

 

I find the idea of a gate level emulation of the TIA particularly intriguing, and I think it would be possible (and if I dare say, not exceptionally difficult), but I wonder if the TIA circuit schematics floating around are 100% accurate.

 

But if it's just a few issues, then I think just patch up what is already there.

 

Tom