15 replies to this topic

[stephena]

This quick bugfix release fixes most of the bugs mentioned in the 3.4 release thread. I couldn't get to all of them though; still TODO is improve the tracking of mouse/paddle movement, and determine why left and right directions are working differently. Changes are as follows (note to Random Terrain, I'll no longer use code tags to show the changelog ):

Quote

* Re-enabled 'grabmouse' commandline argument and associated
functionality with the following changes:
- it is changed in the "Input Settings' UI, not in 'Video Settings'
- it only has meaning while in emulation mode
- it is enabled by default

* Fixed bug with emulation of paddles using the mouse most evident in
Warlords; movement was being filtered out if the mouse was moved too
fast. There's still more work required in this area, however.

* Fixed bug with analog axes on gamepad devices, whereby jittering in
these axes would override input from digital axis, hat or keyboard
input.

* Fixed bug when switching to the debugger and back again would
sometimes cause an extra mouse motion event (which would cause the
emulation to think the mouse was moved and move the player
accordingly).

* Tweaked bankswitch autodetection code for 4A50 bankswitching; several
more test ROMs are automatically detected.

* The 'saverom' debugger command now saves ROMs in your home
directory by default if you don't specify a valid path. This fixes
a bug whereby ROMs were saved in strange locations and couldn't later
be found.

* Fixed bug in automatically executing the debugger 'autoexec.stella'
file; any commands it contained weren't actually being executed.

* Zero-byte ROMs are no longer loaded and mis-detected as Supercharger
images.

As usual, Stella can be download from http://stella.sf.net. Please report all bugs in this thread or by email. I would suggest adding bugs to the Stella tracker, but it hasn't been working since AtariAge upgraded the forum software (Al, if you're listening, please fix the Stella tracker).

Barring any major problems with this latest version, this will be the last release in the 3.x series. If I continue development on Stella (which is likely at this point), the next release will be version 4.0, in which I'll be breaking compatibility slightly and moving to OpenGL as the default rendering system. So you have advance warning to upgrade your video card if necessary

[serj]

Thank you for the best and wonderful emulator atari 2600.
Can we hope to add in future releases the emulator to support these types of controllers as a light gun, Midlink Controller, Kid Vid Controller and CompuMate keyboard?

Please do not throw your emulator.

sorry for my english.

[stephena]

serj, on Sat Jun 11, 2011 7:16 PM, said:

Thank you for the best and wonderful emulator atari 2600.
Can we hope to add in future releases the emulator to support these types of controllers as a light gun, Midlink Controller, Kid Vid Controller and CompuMate keyboard?

Please do not throw your emulator.

sorry for my english.

Adding support for all remaining controllers is on the TODO list. It's always been my intention to do so, I just haven't found the time so far.

[Random Terrain]

stephena, on Sat Jun 11, 2011 6:56 PM, said:

. . . note to Random Terrain, I'll no longer use code tags to show the changelog . . .

Thanks.

[cd-w]

I don't think this is directly a Stella problem, but it is annoying nonetheless. I am using Debian linux and recently Stella has started to take around 5 seconds to load a ROM image. When I type "stella &" the directory listing screen comes up almost instantly, but after I select the ROM to load there is a lengthy delay. The only clue is the message "socket(): Address family not supported by protocol" printed on the console. I think this delay started with a recent libsdl update in Debian, but looking at the Changelogs I can't see anything suspicious (apart from possibly the stuff about pulse-audio?):

libsdl1.2 (1.2.14-6.4) unstable; urgency=low

  * Non-maintainer upload.
  * Build improvements from Guillem Jover that should really have gone 
    with the previous upload. Closes: #614332.
    + Line-wrap build-depends.
    + Use -any syntax for architecture-specific stuff.
    + Fix cross-compilation by using DEB_HOST_* variables.
    + Update or remove non-existing configure flags.
    + Forbid dlopening for X11.
  * Use --enable-debug with the debug keyword, not the noopt one.
  * Refactor configure options.
  * Disable NAS. We have PulseAudio now.
  * Pass --disable-loadso, just to be sure.

 -- Josselin Mouette <joss@debian.org>  Tue, 24 May 2011 22:51:57 +0200

Do you have any suggestions on how I can debug this delay? I just installed Stella 3.4.1 and the problem remains (I also tried deleting the .stella directory but that made no difference).

EDIT: It looks like the audio is the problem - I changed the void SoundSDL::open() function to a return; and the ROMs load near-instantly as before. I then added printfs around the SDL_OpenAudio command, and that is indeed the source of the delay (and the "socket(): Address family not supported by protocol" message).

EDIT2: OK, I did some Googling and found that typing "export SDL_AUDIODRIVER=alsa" before loading Stella solves the problem. I guess it is trying to use PulseAudio (which I don't have installed) or some other sound system before falling back to ALSA. I have added that command to my .bash_profile and now I am happy again!

Chris

[stephena]

cd-w, on Sun Jun 12, 2011 4:35 AM, said:

I don't think this is directly a Stella problem, but it is annoying nonetheless. I am using Debian linux and recently Stella has started to take around 5 seconds to load a ROM image. When I type "stella &" the directory listing screen comes up almost instantly, but after I select the ROM to load there is a lengthy delay. The only clue is the message "socket(): Address family not supported by protocol" printed on the console. I think this delay started with a recent libsdl update in Debian, but looking at the Changelogs I can't see anything suspicious (apart from possibly the stuff about pulse-audio?):

libsdl1.2 (1.2.14-6.4) unstable; urgency=low

  * Non-maintainer upload.
  * Build improvements from Guillem Jover that should really have gone 
    with the previous upload. Closes: #614332.
    + Line-wrap build-depends.
    + Use -any syntax for architecture-specific stuff.
    + Fix cross-compilation by using DEB_HOST_* variables.
    + Update or remove non-existing configure flags.
    + Forbid dlopening for X11.
  * Use --enable-debug with the debug keyword, not the noopt one.
  * Refactor configure options.
  * Disable NAS. We have PulseAudio now.
  * Pass --disable-loadso, just to be sure.

 -- Josselin Mouette <joss@debian.org>  Tue, 24 May 2011 22:51:57 +0200

Do you have any suggestions on how I can debug this delay? I just installed Stella 3.4.1 and the problem remains (I also tried deleting the .stella directory but that made no difference).

EDIT: It looks like the audio is the problem - I changed the void SoundSDL::open() function to a return; and the ROMs load near-instantly as before. I then added printfs around the SDL_OpenAudio command, and that is indeed the source of the delay (and the "socket(): Address family not supported by protocol" message).

EDIT2: OK, I did some Googling and found that typing "export SDL_AUDIODRIVER=alsa" before loading Stella solves the problem. I guess it is trying to use PulseAudio (which I don't have installed) or some other sound system before falling back to ALSA. I have added that command to my .bash_profile and now I am happy again!

Chris

You beat me to it. Yes, SDL will try several audio systems before reaching ALSA or OSS (DMA), and there can be delays in doing so. As a Linux user myself, I can say that audio is something of a mess, particularly with multiple sound servers in different environments. I just disable them all entirely, and use ALSA directly. I suspect there may be similar problems in moving to OpenGL and interactions with desktop effects (Compiz, etc). I tend to disable all that stuff too, but many people don't, so I'll have to cross that bridge when I come to it.

EDIT: I think this is important/annoying enough to add the Stella FAQ page. I'll get it added soon.

[SeaGtGruff]

Stephen, I see what's happening with the "Pole Position" bug (see http://www.atariage....ost__p__2301057), although I'm not sure why it's happening.

Basically, the position of the "drawing cursor" is off by +8 color clocks after writing to NUSIZ0 or NUSIZ1. I haven't checked carefully, but it looks like the bug might not happen if the screen position is negative after writing to NUSIZ0 or NUSIZ1-- that is, if they're updated during horizontal blank. Or maybe it is occurring, but in those cases it just so happened that adding 8 to the position still resulted in a negative value.

But if they're updated after horizontal blank ends-- not counting the extra 8 color clocks for a standard HMOVE (i.e., a "late reset horizontal blank")-- the cursor is displayed 8 color clocks past where it should. Since "Pole Position" is doing an HMOVE on every line, I'm guessing this might not occur if there's no HMOVE bar-- maybe there's a flag or something that causes 8 color clocks to be added to the cursor's position only when the HMOVE bar is present?

Oddly enough, the cursor readjusts itself to the correct position after the next instruction (if it isn't another write to NUSIZ0 or NUSIZ1).

I've taken some screenshots to show what I mean. I hope this information helps you debug whatever's causing the behavior.

Michael



This screenshot shows the cursor at screen position 4-- or "pixel position 4" as shown in the debugger. This is where it should be.



This is just an enlargement of the same picture. I added yellow pixels to the left of the cursor to make it easier to see its position (4, shown in yellow).



This shows where the error occurs. The debugger says the cursor should be at pixel position 4, but it's actually at position 12. As such, it's already drawn missile 0, so the missile doesn't get resized when it should-- the first half is rendered at the smallest size, and the second half is rendered at the quadruple size.



This is an enlargement of the previous screenshot.



This is after the instruction following the NUSIZ0 instruction. Note that the cursor is back to its correct position again-- pixel position 16.



This is the enlargement to show that the cursor is indeed at pixel position 16.



This is another place where it occurs, this time after a NUSIZ1 instruction. The debugger says the pixel position is 49, but the cursor is shown at pixel position 57.



The enlargement to show that the cursor's actually at pixel position 57.



One last screenshot. The debugger says pixel position 31,



but the cursor's actually at pixel position 39.

Sorry, I didn't notice that the next instruction was another NUSIZ, otherwise I would have stepped one more time to see what happened.

[SeaGtGruff]

I decided to download the source for 3.4.1 and see if I could spot anything. That's a joke, because my C skills are all but nonexistent (on a scale of 1 to 10, they're 0.1). But I did see this, which makes me think it might not have anything to do with HMOVE after all:

    case NUSIZ0:  // Number-size of player-missle 0
    {
      // TODO - 08-11-2009: determine correct delay instead of always
      // using '8'.
      myNUSIZ0 = value;
      mySuppressP0 = 0;
      break;
    }

    case NUSIZ1:  // Number-size of player-missle 1
    {
      // TODO - 08-11-2009: determine correct delay instead of always
      // using '8'.
      myNUSIZ1 = value;
      mySuppressP1 = 0;
      break;
    }

I'm thinking "determine the correct delay instead of always using '8'" suggests that changes to NUSIZx are being delayed by 8 pixels, and this delay is causing the issue in question. As far as I know, changing NUSIZx should have an immediate effect, but I'll have to test on my heavy-sixer to be sure. I always assumed it was immediate, and I don't remember hearing any different.

My ability to read schematics is about on a par with my ability to read C code, but from the schematics it looks to me like changing NUSIZx should have a immediate effect. Of course, I could be wrong about that.

I'll see if I can work up some test BINs later to try on my heavy-sixer.

Michael

[stephena]

SeaGtGruff, on Mon Jun 13, 2011 2:10 AM, said:

I decided to download the source for 3.4.1 and see if I could spot anything. That's a joke, because my C skills are all but nonexistent (on a scale of 1 to 10, they're 0.1). But I did see this, which makes me think it might not have anything to do with HMOVE after all:

    case NUSIZ0:  // Number-size of player-missle 0
    {
      // TODO - 08-11-2009: determine correct delay instead of always
      // using '8'.
      myNUSIZ0 = value;
      mySuppressP0 = 0;
      break;
    }

    case NUSIZ1:  // Number-size of player-missle 1
    {
      // TODO - 08-11-2009: determine correct delay instead of always
      // using '8'.
      myNUSIZ1 = value;
      mySuppressP1 = 0;
      break;
    }

I'm thinking "determine the correct delay instead of always using '8'" suggests that changes to NUSIZx are being delayed by 8 pixels, and this delay is causing the issue in question. As far as I know, changing NUSIZx should have an immediate effect, but I'll have to test on my heavy-sixer to be sure. I always assumed it was immediate, and I don't remember hearing any different.

My ability to read schematics is about on a par with my ability to read C code, but from the schematics it looks to me like changing NUSIZx should have a immediate effect. Of course, I could be wrong about that.

I'll see if I can work up some test BINs later to try on my heavy-sixer.

Michael

There's a bit more to it than that, and some other code needs to be fixed too. But creating test ROMs would be great, and it really speeds up finding and fixing any issues. BTW, the behaviour you're seeing is also causing problems in other ROMs (like Meltdown), so I suspect that once it's dealt with, several more ROMs will start working correctly.

EDIT: Here's a somewhat complicated explanation of what Stella is doing.

1) The change to NUSIZx is being done immediately, in that the variables myNusiz0 and myNusiz1 are having a value written to them.

2) At the beginning of every TIA write operation (aka, TIA::poke), the frame is updated to the current colour clock by making use of a 'delay'. You can see this on lines 1264 - 1277.

3) The TIA write is using a static lookup table to figure out the delay, and for writes to NUSIZx it is always 8. This is the source of the strange comment you've indicated above.

4) Obviously this static table can't be used. Sometimes the frame needs to be updated, and sometimes it doesn't (and sometimes the amount is variable). This is the part that needs to be fixed.

So in summary, it's obvious why the behaviour is occurring: the frame is updated before the NUSIZx value is written, and hence only taking effect on the next instruction. The real issue is figuring out the logic under which this frame advance should and shouldn't occur. And this is where your test ROMs may help.

[sandmountainslim]

Is she compatible with Windows 2000? I'm still runnin Stoneage Style on this machine.
Wp

[Random Terrain]

Does anyone know how we can keep a game running while doing something else? If I hit Tab or Esc or the debugger button, that stops the game. But I want the game to keep running while I do other things.


Thanks.

Edited by Random Terrain, Fri Sep 30, 2011 8:16 PM.

[Random Terrain]

Random Terrain, on Fri Sep 30, 2011 8:12 PM, said:

Does anyone know how we can keep a game running while doing something else? If I hit Tab or Esc or the debugger button, that stops the game. But I want the game to keep running while I do other things.

I have the answer:

http://www.atariage....34#entry2382334

If you uncheck "Grab Mouse in Emulation Mode," you can do other things while the game runs.

[sandmountainslim]

I am FINALLY away from Win2000 and running "Ubuntu" on this new machine Stella works GREAT on it. Best emulator in the world.
Wp

[stephena]

sandmountainslim, on Sun Oct 23, 2011 6:55 AM, said:

I am FINALLY away from Win2000 and running "Ubuntu" on this new machine Stella works GREAT on it. Best emulator in the world.
Wp

Good to hear that Stella works well in Linux for you. Linux is my main development system (along with OSX) and what I personally use, so it gets first attention.

As for moving from Win2K, that's also good, since the next major release of Stella (4.0) will drop support for Win98 and 2K.

[Legend]

Quote

As for moving from Win2K, that's also good, since the next major release of Stella (4.0) will drop support for Win98 and 2K.

I use win 2k

Edited by Legend, Thu Oct 27, 2011 2:31 AM.

[stephena]

Legend, on Thu Oct 27, 2011 2:31 AM, said:

Quote

As for moving from Win2K, that's also good, since the next major release of Stella (4.0) will drop support for Win98 and 2K.

I use win 2k

This isn't written in stone yet. Or more like it is for 4.0, but I may do several more releases in the 3.x series first. Eventually, Stella will be moving to SDL 2.0 (currently using SDL 1.2), and that is probably the point to move to a 4.0 release, since SDL 2.0 probably won't ever be available on older OS's.