Stella 3.0 released

[+stephena]

Well, it's finally here. After several months of work (and several years of promising), there are major TIA improvements in the latest 3.0 release of Stella. Several debugger improvements were also added. Now for the bad news:

 

1) I didn't get time to add the revamped disassembly work or Blargg filtering I'm working on. It will have to wait until the 3.1 release. Sorry for those who are waiting for these features, but I'm tied up working on programming software for KrokCart and Harmony cart.

 

2) The minimum supported version of Windows is now Windows 2000. Support for Windows 95/98/ME has been discontinued. It's been over 10 years guys; it's time to move on. I had to make a choice between Windows 7 support and Win9x. It wasn't much of a choice, really.

 

Without further ado, here's the changelog:

 * Huge updates to the TIA emulation system.  Illegal HMOVEs are now
   handled correctly, resulting in improvements to many ROMs (thanks
   to Wilbert Pol for many ideas and code for these improvements).  All
   HMOVE emulation 'cheats' were removed; the emulation is now cycle-exact
   in this area.

 * Improved emulation of the Cosmic Ark 'starfield effect', also used in
   Stay Frosty; the emulation now looks very accurate.

 * Many improvements to the normal TIA rendering code, fixing problems
   when disabling certain graphical objects (certain objects were
   being misdrawn when others were enabled/disabled).

 * Improved TIA collision handling in the non-displayable area of the
   screen; this fixes problems in RAMRacer ROM.

 * Improved TIA redraw problems/graphical garbage when ROMs generate
   many more scanlines than a real TV would allow; this fixes problems
   in Q-Bert and the recent Playaround demo.

 * Added 'Fixed Debug Colors' option similar to the no$26k emulator.
   This allows each graphical object to be drawn in a fixed color,
   more clearly showing how the objects interact.  HMOVE blanks are
   also shown in a different color.  The TIA now emulates a 7-color
   register model, allowing even shared objects to show different
   colors.  This is toggled with the 'Alt Comma' key.

 * Related to 'Fixed Debug Colors', HMOVE blanks can now toggled during
   TIA display with the 'Alt-m' key.

 * Added rewind functionality to the debugger, where states are saved
   after each step/trace/scanline/frame advance.  Pressing 'Alt-r' or
   clicking the new rewind button will undo up to 100 previous
   operations.

 * Added 'electron beam indicator' to the debugger TIA output.  Basically,
   this is a visual pointer indicating the position of the electron gun
   when scanning the display.

 * Added ability to completely disable fullscreen mode, which fixes
   problems for some people where fullscreen mode was being entered
   even if it wasn't enabled.

 * Added '-joyallow4' commandline argument and associated UI item to
   allow all 4 directions to be pressed simultaneously on a joystick.

 * Improvements made to the ROM launcher: the backspace key now goes
   to the parent directory (this key can be remapped), and previously
   selected directories are now automatically selected.

 * Added support for 2IN1 bankswitching scheme, where two ROMs are
   present in one binary.  Currently supported are 2, 4, 8, and 16K
   ROMs.

 * Added bankswitch support for the 6K version of Starpath/Supercharger
   ROMS.  This allows the 6K version of Cubis to run.

 * Updated bankswitching schemes FASC and MB; they are now known as
   FA and F0, respectively.  This naming brings Stella in line with
   other emulators and programming utilities.

 * Fixed editing of cheats in the Cheat Dialog; the old cheat wasn't
   being removed.

 

As usual, Stella can be download from the Stella homepage. Please report all bugs in this thread or by email.

[+SpiceWare]

Nice, I like that the Stay Frosty ROM auto detected and turned on phosphor

 

The starfield effect is much better than before While there's more stars than there should be, the ones that aren't extra are exactly where they're supposed to be:

 

actual Atari

 

Stella

Edited September 11, 2009 by SpiceWare

[aftermac]

WOOO!!! That extra little line is gone from Midnight Magic!!

 

Now if my crashing issues go away...

 

As usual, thanks for all the work you put into Stella!

[+stephena]

Nice, I like that the Stay Frosty ROM auto detected and turned on phosphor

 

The starfield effect is much better than before While there's more stars than there should be, the ones that aren't extra are exactly where they're supposed to be:

 

actual Atari

 

Stella

Are you sure about this? I tested this on a KrokCart running on an SVideo-enhanced heavy-sixer, and the stars appeared as they do in Stella. In fact, my initial code had it look like your picture, but I modified it when I tested on the real thing. I'd hate to think that I've made changes that aren't actually happening on a real system. I'm going to do some testing on a normal, non-SVideo console now, to see what's going on.

[+SpiceWare]

The photo's what I see on my light-sixer. I have a heavy-sixer I can hook up to see if it's different than the light-sixer.

[Tom-Lynx]

Stephen...you are an Atari God and worthy of praise. Thank you for all your work and thank you for sharing it!

[+SpiceWare]

Interesting, must be some TIA differences between the heavy and light sixers.

 

1. more stars than my light-sixer, but not as many as Stella
   
2. none of the stars are 2 pixels wide
   
3. a couple of the stars blink when the Atari is first powered on, but then become stable
   

 

 

My HDTV doesn't sync to the Atari so I tested on my emergency TV (5" B&W with radio, flashlight, ect). Of course the TV doesn't help much during hurricane season anymore, there aren't any battery operated HD tuners.

[+stephena]

Interesting, must be some TIA differences between the heavy and light sixers.

 

1. more stars than my light-sixer, but not as many as Stella
   
2. none of the stars are 2 pixels wide
   
3. a couple of the stars blink when the Atari is first powered on, but then become stable
   

 

 

My HDTV doesn't sync to the Atari so I tested on my emergency TV (5" B&W with radio, flashlight, ect). Of course the TV doesn't help much during hurricane season anymore, there aren't any battery operated HD tuners.

I also got this picture in my various experiments. You'll notice that the only difference between this picture and Stella is that some pixels are stretched to be 4 pixels wide, with the third one blanked. There's code in Stella specifically to do this. If I turn it off, I get exactly what you have here.

 

I'm still trying to track down a connector for the TV/Computer switchbox to the RF leads so I can hook up my Vader. And I don't know if it'll look any better on the HDTV I have either. All testing was done on a JVC TM-130SU SVideo monitor with a KrokCart and Svideo board (from Longhorn Engineer).

[+stephena]

I just turned off the code I mentioned in the above post, and this is what I get:

 

Now I just need to figure out why I'm seeing the weird '4 pixel width with 3rd one blanked' pattern.

[+SpiceWare]

That looks like a perfect match to my heavy-sixer. My heavy-sixer is connected via RF. My light-sixer has one of Chris Wilkson's CyberTech S-Video boards.

[+stephena]

That looks like a perfect match to my heavy-sixer. My heavy-sixer is connected via RF. My light-sixer has one of Chris Wilkson's CyberTech S-Video boards.

And this is with the tweaks removed:

So it looks like I can emulate all the different versions. The problem is, which one is correct? And more importantly, why did I get the weird pattern on my Svideo setup??

[Omegamatrix]

I was hoping Meltdown would emulate correctly now, but it still appears corrupted. I've never looked at the code to see what tricks it is using, but I know others have.

[+stephena]

I was hoping Meltdown would emulate correctly now, but it still appears corrupted. I've never looked at the code to see what tricks it is using, but I know others have.

It's because of writes being done to NUSIZx while drawing is already in progress. This is noted in the TODO as one of the major things to fix for 3.1. Originally, I thought that the only TIA area that Stella was deficient was HMOVE handling. So that was the priority for 3.0. Late in the release cycle, I noticed that NUSIZx writes weren't always properly emulated either, but it was too late to do the research to fix this and have a September release. Notice that I also had to delay the disassembly and CRT emulation updates. Don't worry, the fixes are coming for the 3.1 release. Besides, if you've been following Stella development for the past several years, you'll notice that the .1 releases typically contain more than .0 do

 

EDIT: I also wanted to add that this is a typical point-oh release from a software development POV. Many changes are not visible to the end user, but there has been great upheaval in the underlying code. Large parts of the TIA have been rewritten/removed, and I'm now finally beginning to understand how the code works, and how the real system works. That, more than anything else, is what's been delaying the TIA rework in the past. Until I came up to speed on this, no progress could be done (since I'm the only person working on the code). I'm more comfortable with the underlying code now, so big changes can start to happen much quicker.

Edited September 12, 2009 by stephena

[+SpiceWare]

That looks like a perfect match to my heavy-sixer. My heavy-sixer is connected via RF. My light-sixer has one of Chris Wilkson's CyberTech S-Video boards.

And this is with the tweaks removed:

So it looks like I can emulate all the different versions.

That's pretty close, though it appears that Stella shifted all the 2 pixel missiles to the right by 1 pixel.

 

 

The problem is, which one is correct? And more importantly, why did I get the weird pattern on my Svideo setup??

Don't know the answer to either of those, and it wouldn't surprise me if the Jr. and 7800 had different results. Probably wouldn't hurt to get some others to take photos of Stay Frosty and post it with which Atari it was on.

Edited September 12, 2009 by SpiceWare

[cd-w]

Don't know the answer to either of those, and it wouldn't surprise me if the Jr. and 7800 had different results. Probably wouldn't hurt to get some others to take photos of Stay Frosty and post it with which Atari it was on.

 

1. PAL 4 switcher:
   
   
2. PAL Jr. - this one has the weird TIA chip:
   
   

 

Chris

Edited September 12, 2009 by cd-w

[+SpiceWare]

The PAL 4 switch looks like my NTSC light-sixer. The PAL Jr. w/weird TIA has the same star pattern, just no double-pixel stars.

[Eckhard Stolberg]

The problem is, which one is correct? And more importantly, why did I get the weird pattern on my Svideo setup??

Don't know the answer to either of those, and it wouldn't surprise me if the Jr. and 7800 had different results. Probably wouldn't hurt to get some others to take photos of Stay Frosty and post it with which Atari it was on.

As you probably know, the position counters for all the objects get advanced once every colour clock during the active part of the screen. Horizontal motion works by advancing those counters once every four colour clocks during the inactive part of the screen until the HMOVE counter matches the value in the HMxxx register for an object. The trick in the starfield effect is to change the HMxxx value just in time so that it never matches with the HMOVE counter and therefore the object's position counter will keep getting extra clock pulses.

 

On the TIA77 the extra HMOVE pulses will simply overlap with the normal clock pulses that advance the position counters and therefore have no effect during the active part of the line (That's different on the TIA89, but that's a different subject.) The problem is that the same clock pulses are also used to advance the counters in the display circuit of the movable objects. And there the two different clock pulses happening at almost the same time might cause some side effects due to some race conditions. The visual consequences of these side effects might differ due to the chip revision, the age of the TIA, the temperature etc. That's why you are getting different starfields on different VCSs.

 

IIRC the by far most common starfield pattern I have found is like this: The missile gets shiftet 17 pixels to the left in each scanline. When the missile is supposed to be displayed over the first pixel of a PF block, it gets extended one pixel to the left. So the missile is two pixels wide and connects two PF blocks. In the next line where the missile would be displayed at the last pixel of a PF block, it doesn't get displayed at all.

 

What happens when you use wider missiles or the player or the ball still needs to be researched. Also what happens when you trigger a HMOVE in the active part of the scanline when there are still objects to be displayed in that part of the line also needs researching. Just mentioning it so you know that you'll still have lots more fun until you can consider Stella's TIA emulation to be perfect.

[Luc]

Just a quick question if you don't mind: would it be possible to have a "disable sprite collisions" toggle like the Atari 8-bit emulator or is that not possible? I think it would be awesome...

[+stephena]

IIRC the by far most common starfield pattern I have found is like this: The missile gets shiftet 17 pixels to the left in each scanline. When the missile is supposed to be displayed over the first pixel of a PF block, it gets extended one pixel to the left. So the missile is two pixels wide and connects two PF blocks. In the next line where the missile would be displayed at the last pixel of a PF block, it doesn't get displayed at all.

I'm probably going to revert to this for the next release, as it's the most common. I have no desire (at this point in time) to consider various revisions of the TIA chip; it's hard enough getting the correct functionality of one of them. I still don't know what's going on with my Svideo-enhanced system, but I now think the pattern I'm seeing is being influenced by the Svideo mod (from Longhorn Engineer).

 

What happens when you use wider missiles or the player or the ball still needs to be researched. Also what happens when you trigger a HMOVE in the active part of the scanline when there are still objects to be displayed in that part of the line also needs researching. Just mentioning it so you know that you'll still have lots more fun until you can consider Stella's TIA emulation to be perfect.

I consider the TIA emulation to be still far from perfect. IMO, there were three big deficiencies: HMOVE handling, NUSIZx writes during display, and TIA 'confusion' causing the starfield effect. The first is hopefully taken care of in 3.0, and it fixed dozens of ROMs. Every single error I've seen from bug reports and my own testing is because of the last two. I basically understand the problems; I just need to find time to do more research and actually create code to fix them.

[+stephena]

Just a quick question if you don't mind: would it be possible to have a "disable sprite collisions" toggle like the Atari 8-bit emulator or is that not possible? I think it would be awesome...

You can of course disable the sprites themselves, which will disable collisions. But then you don't see the sprites anymore! Being able to disable the sprites and still see them doesn't sound too hard, now that I've rearranged the code to make it much easier to follow. I'll consider this for a future release.

[Luc]

Just a quick question if you don't mind: would it be possible to have a "disable sprite collisions" toggle like the Atari 8-bit emulator or is that not possible? I think it would be awesome...

You can of course disable the sprites themselves, which will disable collisions. But then you don't see the sprites anymore! Being able to disable the sprites and still see them doesn't sound too hard, now that I've rearranged the code to make it much easier to follow. I'll consider this for a future release.

 

Thank you! Really looking forward to this.

[Nukey Shay]

I don't see why it should be difficult....collisions work via reads, writes can still keep their function.

Keep in mind that many games do not use the method at all.

[+stephena]

I don't see why it should be difficult....collisions work via reads, writes can still keep their function.

Keep in mind that many games do not use the method at all.

Yes, that's exactly what I was thinking; just modify what is returned when the collision registers are read. As for the second part, if a game doesn't use the registers for collisions, then this option will have no effect.

[+stephena]

I've decided to revert the starfield effect code as described by Eckhard above. Here's a snapshot:

 

Also, I just completed the collision disable code. These improvements will be in the next release.

[Omegamatrix]

Just wanted to say that the rewind button and electron beam indicator are the best thing ever. Would it be possible to make the rewind button work after the debugger is triggered by a break? That would be awesome.