Requesting help in improving TIA emulation in Stella

[SeaGtGruff]

I don't think we will have to go to gate-level emulation. You can abstract a lot of things without loosing correctness. The most important things is to emulate the various clocks correctly. This will be not very easy, but also no rocket science.

I think the emulation of the clocks can be simplified if it's assumed that a RESET PHI-0 signal has already occurred. What I've seen via my spreadsheet is that the PHI-0 clock can start up "out of step" on the very first scan line after powerup-- i.e., as if it's marching left-right-left when it should be marching right-left-right, to use an analogy. The two audio clocks can also be out of sync on the very first scan line due to the randonmess of the horizontal sync counter at powerup. And the initial state of the horizontal sync counter can be unrelated to the second state, since the two gates driven by H-PHI-1 and H-PHI-2 inside each bit of the LFSR have separate random values on powerup. When the first RESET PHI-0 signal occurs-- triggered by the horizontal sync counter being reset-- the PHI-0 clock is forced into the proper sync, which can result in one or two hi/lo phases being temporarily longer or shorter than usual-- like a soldier momentarily either prolonging his steps or quickening his steps to get into time with everyone else. Since the first RESET PHI-0 signal will (I think) occur no later than 227 color clocks after powerup (depending on the second state of the HSC), and since most games perform an initialization routine on powerup anyway, it's okay to assume that everything is already in proper sync at powerup.

 

I think the place where emulating the clocks as accurately as possible will be most critical will be with the audio clocks, along with emulating the frequency dividers and audio LFSRs accurately.

[Thomas Jentzsch]

...and since most games perform an initialization routine on powerup anyway, it's okay to assume that everything is already in proper sync at powerup.

I don't know what Stephen thinks about this, but IMO we should assume at least that. I am not prepared to put major effort into emulation, just to support new games/demos which may not initialize correctly or do other obscure and non-useful stuff. Those can be much easier be fixed by the game developer. Of course existing games and all valid tricks, which expand the capabilities of the TIA should be supported 100%.

 

E.g. Fatal Run does weird stuff with RSYNC for, as far as I know, no reason. Yet this should be supported. If some homebrewer should decide to do the same (and Fatal Run wouldn't exist), IMO this should not be supported.

 

I think the place where emulating the clocks as accurately as possible will be most critical will be with the audio clocks, along with emulating the frequency dividers and audio LFSRs accurately.

That's a task I will definitely leave for someone else.

[Alegend45]

I think that all behaviors that work on real hardware should work on Stella. Then, and only then will it be accurate.

[Thomas Jentzsch]

I think that all behaviors that work on real hardware should work on Stella. Then, and only then will it be accurate.

Go ahead, nobody will stop you.

[Omegamatrix]

Of course existing games and all valid tricks, which expand the capabilities of the TIA should be supported 100%.

I'm super stoked to think NUSIx updates might be made to work.

 

E.g. Fatal Run does weird stuff with RSYNC for, as far as I know, no reason.

 

If you look at the PAL rom it does a normal VSYNC with three lines of WSYNC inbetween. I can only guess that since this was a proto then RSYNC was an accident, or something was misunderstood. It clearly should have been a WSYNC.

[+stephena]

If you look at the PAL rom it does a normal VSYNC with three lines of WSYNC inbetween. I can only guess that since this was a proto then RSYNC was an accident, or something was misunderstood. It clearly should have been a WSYNC.

 

In any event, Extra Terrestrials needed that functionality, and it was released years before Fatal Run. So it fits Thomas's requirement of existing games using it.

[Joe Musashi]

Finally, I got the simulation for the player logic (sheet #3, without the missile) running. As before, this is a mixed gate-, register-transfer-level simulation. The horizontal positioning circuits (RES, HMOVE) are not included and it is assumed that the phase of the player counter is fixed over the whole image.

 

TIA component simulation and a kernel test are still in one program. It behaves like the NUSIZ test program in #63, i.e., it draws a number of quad-size players, where NUSIZ is changed mid-line. You can run the test with:

 

./TIASim [hpos]

 

where hpos is the pixel [0,159] at which NUSIZ is modified. The program will then render a single frame and output a 'screenshot' as TIASim.ppm.

 

So, now comes the moment of truth . What does it look like when it is run? With NUSIZ changed at 63 (default) I'm getting (TIASim left, NUSIZTest on real hardware right):

 

 

I checked on a big CRT TV and the ouput seems to be pixel exact. The only difference is the incomplete last line of the triangles on the right, but this is because GRP is set to 0 too early, this is not done in the simulation. When comparing with the major emulators it looks like only MESS handles a change of the scan counter frequency during scan out (images below are from MESS, javatari, z26, Stella, in that order).

 

 

When you look closely, you will see that there is a slight difference between MESS and TIASim: In MESS sometimes the fifth quad-size pixel (which crosses the change) is only 3 pixels wide. I double checked, and on a real machine it is 4 pixels.

 

On my 4 year old MacBook (2.93 GHz Core 2 Duo) the simulation runs at about 110 frames per second on a single core (262 lines). For all 5 objects this would probably be too slow for real-time. However, as said, there's room for optimization. For example, you could run the simulation only on lines where mid-size NUSIZ changes are detected and otherwise do an emulation.

 

Now the bad news. To make it work I had to cheat a tiny bit: As you all know, when drawing a quad- or double-size player there is a horizontal delay by one pixel compared to single-size players. When looking at the schematics, I cannot see why this is happening and also the simulation does not show it. I looked at some emulator sources, but everywhere the delay is hard-coded as a magic number.

 

Obviously, the delay happens because the count and start signals coming from the position counter are not in sync, but they are both derived from p-phi1, and p-phi2. I played around a little and found that the simulation reproduces the correct result when the clock feeding the position counter is inverted. I left this in the code for now, though I have no idea what could cause it.

 

I will now go back to DK programming for a while. When Thomas is ready with an initial refactoring I will try to mix the TIASim code with Stella.

TIASim.zip

[Omegamatrix]

Did you guys see this? Scott Stilphen put together a nice little page on TIA chips. I like that he has photographs of all the variants too! There is mention of a 2 or 3 sprite demo, depending on the TIA chip that Bradford Mott posted. However following the replies I could only find a rom that Eckhard made. There is quite a good discussion on the different TIA's there.

[Thomas Jentzsch]

Yup, I have bookmarked the site. After we have reimplemented the Stella TIA core, we could try to reproduce at least the most common differences. Probably most of the differences are just a CLK here and there.

 

Very few 7800 users have reported problems with the playfield in Thrust, most likely resulting from a 1 CLK delay difference.

[+stephena]

Did you guys see this? Scott Stilphen put together a nice little page on TIA chips. I like that he has photographs of all the variants too! There is mention of a 2 or 3 sprite demo, depending on the TIA chip that Bradford Mott posted. However following the replies I could only find a rom that Eckhard made. There is quite a good discussion on the different TIA's there.

 

I've personally seen the issue in PIC 6, and with several of the links mentioned there. In fact, one of them is a link back to AtariAge for the Stella 3.0 release, where #6 is discussed in detail On my console, the starfield in Cosmic Ark looks like the right-hand picture in PIC 6, and I actually released a version of Stella that duplicated it. But for most people, it looks like the left-hand picture, so I reverted it for the next release.

 

Long story short, I have code that does both (it's simply modifying how missiles are changed, and it's still in the codebase). But as I mentioned in the afore-mentioned thread, I didn't know which is the more correct approach.

 

EDIT: The link actually talks about Stay Frosty, but the same issues are happening in Cosmic Ark (for the same reasons).

[Keatah]

I've got a few TIA chips pre-dating the first grey-colored AMI variant. Don't know if that is useful info or not.

[dualcam]

Obviously, the delay happens because the count and start signals coming from the position counter are not in sync, but they are both derived from p-phi1, and p-phi2. I played around a little and found that the simulation reproduces the correct result when the clock feeding the position counter is inverted. I left this in the code for now, though I have no idea what could cause it.

 

Was noticing that the J/K flip-flops that the player P0 & P1 player serial graphics come out of are clocked by CLKP which is the invert of the CLK clock. Didn't know if you had noticed or if this is related.

 

Tom

[Joe Musashi]

Yes, according to schematic #1, CLKP is an inverse CLK, but MOTCK seems to be an inverted CLK signal, too. So all clocks going into the player logic should be in sync. Even if CLKP would be an inverted MOTCK, it would delay all player sizes, not only quad and double players.

[kaz321123]

I think Stella is my favorite emulator for Atari. I'm content if I just know how to run an emulator at all. I read this thread in awe since all the coding talk is WAY WAY over my head. I still find it facinating. The quest for 'perfect' emulation seems to be an awesome goal. My take is that different emulators approach 'perfection' from different angles. Nintendo emulators are often like this. One is good for 'perfect timing' but hog the resources, while another one is all about compatibility.

 

z26 has always felt like the quick and dirty emulator, just click and go...

 

Stella has a gigantic amount of options, so you can make the emulator do pretty much anything you want. So for the quest for 'perfection' I'd choose Stella. I also use the xbox port of stella. So if you stop developing for this, xbox emulation will suffer also. Having fun is also important, but consider this...when all the actual Atari 2600 hardware out there dies off (oxidation or whatever over the years), the only thing left will be emulators. Your work will be pivotal so that the technology is not 'forgotten'.

 

100 years from now when no actual Ataris work at all, your contribution will be all that's left of the very FIRST mainstream video game system. Isn't that the point of emulation ultimately...to preserve video games when hardware starts to fail?

 

I hope a little bit of this is encouraging

[+stephena]

Thanks for the support. I'm going to be sticking around for a while longer yet, since I've gotten some help from Thomas, Joe, and others mentioned above. I'm finishing up some debugger stuff for the next release, and then I plan to get back to the TIA stuff. I know I've said that before, but this time it's different since (a) I've got extra help, and (b) it's all starting to make more sense to me now.

[Keatah]

When I jam Stella I really believe my PC got downgraded into a 2600! Remarkable!

[Shannon]

Stella has a gigantic amount of options, so you can make the emulator do pretty much anything you want. So for the quest for 'perfection' I'd choose Stella. I also use the xbox port of stella.

 

The port of stella for the xbox is pretty old and not even based on the latest stella code. So it is unlikely any changes to Stella will make for an improvement on the 'ol xbox.

Edited April 20, 2013 by Shannon

[kaz321123]

@Shannon. Ya I guess I was using Z26. The stella version I have for xbox (classic) is version "2". I was trying to look for the date it was created-but couldn't figure it out (in the nfo file).

 

I remember using Stella alot on windows.

 

I attached the stella port I got here.

stella_xbox_v2.zip

[Shannon]

Thanks. Yeah the stella port is pretty old... it predates even x-ports Z26. I actually modified Z26 so that the sound is more accurate. So if you have the madmab edition you will have more accurate sound.

[Thomas Jentzsch]

Stephen, I've seen some very nice Stella commits over the last weeks. The next version already looks very promising, especially for developers!

 

Now I only have to find the mood and time to continue with my own task...

[DanOliver]

I can offer my C++ programming services if there was a decision to do some kind rewrite. I've been writing C++ professionally since there was C++. Any kind of Assembly is also OK. I don't know anything about emulating anything, no experience with Stella code, so I could only be a programmer being directed by someone or group. I can give 1 or 2 months full time and then part time maintenance. I have no idea how large the possible projects being discussed would take, but I can complete projects pretty fast. I don't mind taking a crack at something even if it fails if someone is willing to provide direction and answer questions along the way.

 

My interest is solely in an emulator for development. The backward compatibility with old games doesn't interest me, but I assume that would come along for free.

 

I've done projects like this before, working with an Electrical Engineer or other expert describing what's needed.

 

I don't think I'd be much help changing current code because it would take too long to come up to speed. But if you need eyes for code review I'd being willing.

 

What I'm reading in this thread, and I've read it a couple of times, sounds like some very interesting project ideas to me. I've seen the same type of discussions on other older projects. They create a lot of experience about what could be done better but have to deal with legacy code. It's a tough tradeoff. I'm always in favor of a complete rewrite and have done such projects many times.

 

Stella UI

One other thing I can offer is a better UI framework. I assume, and please correct me if I'm wrong, that the Stella UI looks the way it does because it's being drawn in a OpenGL, or maybe DirectDraw, window so you can't use standard Win32 controls and such?

 

I had the same issue many years ago when doing PC games and developed my own UI framework which can do a Windows, Mac or custom style UI that's as good or better than the OS. I only use basic OS calls to access whatever bitmap the system provides. I draw and manage windows, dialogs, buttons,scroll bars, menus, the works. I render any TrueType font to my own bitmap font structure with different anti aliasing effects. Uses UTF-8 (Unicode) and is has localization support. Allows for non-programmers to create pretty advanced skins including layout.

 

Notes on setting up Stella development for Windows XP.

I just setup the Stella project and built successfully and wanted to share what I learned. Went pretty smooth thanks to the Stella development page.

 

2010 Express requires Service Pack 3. Installing that on one computer caused it to not boot. System recovery fixed that, but I could not get SP3 to work on that computer.. I already had SP3 on another computer so used that.

 

The TortoiseSVN site requires a 4.5 Windows installer be installed for XP. I had no way to tell if I had it already or not so I installed that. The TortoiseSVN site has two download buttons for 32 and 64 bit versions. I clicked 32 bit and didn't notice a note on the next page saying the 32 bit file wasn't available and so it decided on its own to download the 64 bit version. The file you want is here, at least for some period of time:

http://sourceforge.n....0.msi/download

I found it searching around the file directory links below the down load button at SourceForge.

 

On the Stella development page, step 1 for "Compiling the source code:" shows several files named "Stella", the file you want is "Stella.sln". Double clicking it did not launch 2010 Express on my computer. But loading it from inside 2010 Express did work.

 

In step 4 if you first change the "Configuration:" drop down from "Active (Debug)" to "All Configurations" you save not having to do steps 5 & 6. Wish I had a dime for every time I forgot that...PITA.

 

Build failed right off with error MSB8008. To fix this right click "Solution Explorer -> Stella" and select "Properties". Same dialog in steps 3-6. Select "Configuration Properties" -> "General" and then in the right pane change "Platform Toolset" from v110 to v100. People using VC 2012 need v110.

Edited July 4, 2013 by DanOliver

[DanOliver]

Side note...tried to install Eclipse...won't install on XP because path names are too long. Checked their database and it's been a bug for more than 6 years.