87 replies to this topic

[stephena]

batari, on Fri Oct 30, 2009 12:31 PM, said:

I think I may have requested this before, but I would like to see an option to drive normally undriven bits randomly.

For example, if one does a read to $0F, Stella returns $0F. This might work on 90% of hardware but on some hardware, the state of most of the bits is not reliable. The TIA's read registers are only connected to 2 bits, and these bits are not driven for all addresses, so it would be nice if the undriven bits could be random.

This also happens when reading from the write areas of certain bankswitch schemes, except all 8 bits should be driven randomly. I'm not sure what Stella is doing in these cases, but it would be nice is there were an option to return completely random values.

The reason I want to see this is not all hardware is the same. Games have been released with these kinds of bugs and they end up failing on some types of hardware and on some systems, and it would be great if there were a way to exploit these bugs in emulation.

I haven't forgotten this item. In fact, I believe I put it in the TODO list. I have to look into using the tracker that Al set up for these TODO items, so people can see what's been requested, and which bugs have been reported (and the progress of fixing them). But I suspect that this will have to wait until December or so. And the next release of Stella will probably be late December as well.

[d-wilson]

Eckhard Stolberg, on Sun Sep 13, 2009 11:41 AM, said:

SpiceWare, on Sat Sep 12, 2009 2:38 PM, said:

stephena, on Fri Sep 11, 2009 6:21 PM, said:

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.

Does anybody know how many different versions of the TIA chip there are? Can somebody write a program that will tell you what version you have in your system?

[Random Terrain]

I was trying to record some videos of E.T. tonight using the latest version of Stella and I noticed that some of the zones were in the same place every time I restarted the game (hit the Esc key, then started the game again dozens of times). I haven't played E.T. that much during the last couple of Stella versions, so I don't know when the problem started. Is there some hidden setting I'm supposed to play with to make sure randomness is working properly? On a real Atari, a few zones will be in the same place sometimes, but not that many times in a row.


Update:

Could it be the ROM? I was using the one from the RomHunter collection:

E.T. - The Extra-Terrestrial (1982) (Atari, Jerome Domurat, Howard Scott Warshaw) (CX2674) ~.bin

I just thought to try the one I got from AtariAge and it's clearly more random every time I restart. Could there really be that much of a difference?



Update #2:

It can't be the RomHunter ROM. The same thing started happening to the AtariAge ROM too. It seemed to be more random the first few times, but then some of the same zones kept coming back, just like the other ROM.

Edited by Random Terrain, Thu Nov 26, 2009 5:01 AM.

[stephena]

Random Terrain, on Thu Nov 26, 2009 4:12 AM, said:

I was trying to record some videos of E.T. tonight using the latest version of Stella and I noticed that some of the zones were in the same place every time I restarted the game (hit the Esc key, then started the game again dozens of times). I haven't played E.T. that much during the last couple of Stella versions, so I don't know when the problem started. Is there some hidden setting I'm supposed to play with to make sure randomness is working properly? On a real Atari, a few zones will be in the same place sometimes, but not that many times in a row.

The randomness was tweaked in version 2.6.1, and again in 2.7. I suggest trying these older versions (and also one version back from that) to determine when the problems first started. It would really help me track down the problem if you could find the first version that caused this problem.

[Random Terrain]

stephena, on Thu Nov 26, 2009 6:47 AM, said:

The randomness was tweaked in version 2.6.1, and again in 2.7. I suggest trying these older versions (and also one version back from that) to determine when the problems first started. It would really help me track down the problem if you could find the first version that caused this problem.

OK, I'll try those after I get some sleep. Thought you might want to know that hitting F2 seems to create real Atari-like randomness. The problem only happens when completely starting over from the Stella menu.

Thanks.

[Random Terrain]

For anyone else who wants to play along, it seems the best spot to see the problem is here:



Hit the Esc key, start the E.T. game and hit the fire button, walk down to the next screen, then walk to the screen to the right (being careful to avoid the top and bottom areas so you won't fall in a well). Now walk to the middle of the screen and step to the left and to the right a little to see what zone symbols are shown at the top of the screen. Repeat the process around 5 to 10 times (be sure to hit the Esc key and go from there, don't use F2 to reset the game).


So far, all versions of Stella I have tried settled down to the same set of symbols in the area I marked in the image above. The two symbols are usually these:

 


That was until I got down to stella-2.4.1-win32.exe when it was mostly those two symbols, but these two symbols would appear once in a while:

 


I jumped down to stella-2.0.1-win32.exe to see if I could get past the problem, but it also seems to alternate between these two sets:

 

 


I guess this weird problem has been there for a fairly long time. As I said before, at least hitting F2 makes sure all of the zones are randomized, instead of just some of them.

[yuppicide]

I wouldn't at least mind seeing something like WolfMAME uses. It records user input into inp files. These are small files that can be played back and view a users gameplay. These are what they used when you want to get a MAME score verified on TwinGalaxies.

Random Terrain, on Tue Oct 20, 2009 1:30 PM, said:

Speaking of people contributing things, I hope somebody reading this who has the skill will contribute whatever is needed for Stella to make video recordings of gameplay, so we won't have to keep using things like CamStudio. Record straight from Stella without clogging up the computer with extra software that can make Stella slow down and speed up, ruining the video.

[stephena]

Random Terrain, on Fri Nov 27, 2009 4:51 AM, said:

For anyone else who wants to play along, it seems the best spot to see the problem is here:

et-map-log-area.png

Hit the Esc key, start the E.T. game and hit the fire button, walk down to the next screen, then walk to the screen to the right (being careful to avoid the top and bottom areas so you won't fall in a well). Now walk to the middle of the screen and step to the left and to the right a little to see what zone symbols are shown at the top of the screen. Repeat the process around 5 to 10 times (be sure to hit the Esc key and go from there, don't use F2 to reset the game).


So far, all versions of Stella I have tried settled down to the same set of symbols in the area I marked in the image above. The two symbols are usually these:

et7arrow7left.gif   et7arrow7right.gif


That was until I got down to stella-2.4.1-win32.exe when it was mostly those two symbols, but these two symbols would appear once in a while:

et7arrow7right.gif   et7find7phone7piece.gif


I jumped down to stella-2.0.1-win32.exe to see if I could get past the problem, but it also seems to alternate between these two sets:

et7arrow7left.gif   et7arrow7right.gif

et7arrow7right.gif   et7find7phone7piece.gif


I guess this weird problem has been there for a fairly long time. As I said before, at least hitting F2 makes sure all of the zones are randomized, instead of just some of them.

OK, this could be helpful. I try to find some time over the weekend to look into it further.

[stephena]

yuppicide, on Fri Nov 27, 2009 10:36 AM, said:

I wouldn't at least mind seeing something like WolfMAME uses. It records user input into inp files. These are small files that can be played back and view a users gameplay. These are what they used when you want to get a MAME score verified on TwinGalaxies.

Random Terrain, on Tue Oct 20, 2009 1:30 PM, said:

Speaking of people contributing things, I hope somebody reading this who has the skill will contribute whatever is needed for Stella to make video recordings of gameplay, so we won't have to keep using things like CamStudio. Record straight from Stella without clogging up the computer with extra software that can make Stella slow down and speed up, ruining the video.

There is already preliminary support in Stella for this, but it's currently disabled in the release versions. It's yet something else I have to finish, once I find some time ...

[Wickeycolumbus]

Something very strange happened to me as I was using the debugger... I don't have too many details about how it happened. First of all, I am using Stella 3.0 with OS X 10.4.11, with an ATI Radeon HD 2600 Pro. I believe I was incrementing the frame and switching in and out of debugger mode repeatedly. What happened is a bar of garbage appeared on the debugger screen, that would tend to follow the mouse:



After I quit Stella, garbage appeared all over the screen, and in other application windows (often changing garbage). Here is a screen shot:



I suppose it could be a bug in OS X itself.

[Omegamatrix]

Using the Alt-L switch, I noticed Maze Craze is listed as "PAL" under the auto-detection although it is 262 lines in stable state. Most certainly something to do with how it starts up, but I thought you should know.

[stephena]

Omegamatrix, on Sat Nov 28, 2009 1:13 AM, said:

Using the Alt-L switch, I noticed Maze Craze is listed as "PAL" under the auto-detection although it is 262 lines in stable state. Most certainly something to do with how it starts up, but I thought you should know.

Yes, I've noticed this in other ROMs. It's because of how the autodetection only looks at the first 60 frames or so to determine whether it's NTSC or PAL. Maze Craze does something weird at startup, which throws off the detection. There's actually already a bug report about it in the Stella tracker on this site.

BTW, this is a perfect time to point out the Stella tracker Anyone interested should take a look at the reported bugs and suggestions, and add comments (or new reports) where appropriate.

Finally, this relates directly to you Omegamatrix; I believe you're the person that loaned me a KrokCart. I sent an email indicating I'm finished with it, and would like to return it, but I never got any message back. Please respond by PM when you get a chance.

[stephena]

Wickeycolumbus, on Sat Nov 28, 2009 12:17 AM, said:

Something very strange happened to me as I was using the debugger... I don't have too many details about how it happened. First of all, I am using Stella 3.0 with OS X 10.4.11, with an ATI Radeon HD 2600 Pro. I believe I was incrementing the frame and switching in and out of debugger mode repeatedly. What happened is a bar of garbage appeared on the debugger screen, that would tend to follow the mouse:

Picture 3.png

After I quit Stella, garbage appeared all over the screen, and in other application windows (often changing garbage). Here is a screen shot:

Picture 4.png

I suppose it could be a bug in OS X itself.

This isn't the first time I've heard of graphical corruption in Stella for OSX, but it's still very rare. All the reports I've seen are users with ATI video hardware. I don't know if that's a common symptom, or just a fluke. In any event, tracking this down will be extremely difficult without further bug reports and testing, as it could be one (or a combination) of Stella, the SDL library, OpenGL drivers, or OSX itself (dependent on version).

Some people may have heard my previous announcement of getting an iMac for fulltime development on Stella. That idea had to be scrapped, and I'm going with a Macbook Pro instead. The good news is that this will be my work machine, so I'll be testing Stella in more detail in the coming months. Maybe that will iron out the bugs in the OSX port.

[stephena]

Random Terrain, on Fri Nov 27, 2009 4:51 AM, said:

For anyone else who wants to play along, it seems the best spot to see the problem is here:

et-map-log-area.png

Hit the Esc key, start the E.T. game and hit the fire button, walk down to the next screen, then walk to the screen to the right (being careful to avoid the top and bottom areas so you won't fall in a well). Now walk to the middle of the screen and step to the left and to the right a little to see what zone symbols are shown at the top of the screen. Repeat the process around 5 to 10 times (be sure to hit the Esc key and go from there, don't use F2 to reset the game).


So far, all versions of Stella I have tried settled down to the same set of symbols in the area I marked in the image above. The two symbols are usually these:

et7arrow7left.gif   et7arrow7right.gif


That was until I got down to stella-2.4.1-win32.exe when it was mostly those two symbols, but these two symbols would appear once in a while:

et7arrow7right.gif   et7find7phone7piece.gif


I jumped down to stella-2.0.1-win32.exe to see if I could get past the problem, but it also seems to alternate between these two sets:

et7arrow7left.gif   et7arrow7right.gif

et7arrow7right.gif   et7find7phone7piece.gif


I guess this weird problem has been there for a fairly long time. As I said before, at least hitting F2 makes sure all of the zones are randomized, instead of just some of them.

Are you sure that this isn't also happening on a real system? You know that F2 works in Stella, and that the Reset works similarly on the real thing. But have you tried physically turning the switch on and off for the real thing and see if it acts the same way as Stella? I'm not implying that there's nothing wrong with Stella; I just want to confirm this isn't the way a real console works before I spend any further time on it.

[Random Terrain]

stephena, on Sat Nov 28, 2009 9:14 AM, said:

Are you sure that this isn't also happening on a real system? You know that F2 works in Stella, and that the Reset works similarly on the real thing. But have you tried physically turning the switch on and off for the real thing and see if it acts the same way as Stella? I'm not implying that there's nothing wrong with Stella; I just want to confirm this isn't the way a real console works before I spend any further time on it.

I thought I should do that when I noticed the problem, but I forgot to check.

I just tried two different E.T. cartridges on a real Atari 2600. Starting around the 3rd time and giving the same result 10 times or so after that, it settles down to the following two symbols:

 

So nothing is wrong with Stella in this case, it's just giving a slightly different result than a real Atari 2600. This wasn't a complete waste of time. At least we know that we should hit the reset switch before playing the first round of E.T. whether we're using a real Atari 2600 or Stella.

[Omegamatrix]

stephena, on Sat Nov 28, 2009 8:44 AM, said:

Omegamatrix, on Sat Nov 28, 2009 1:13 AM, said:

Using the Alt-L switch, I noticed Maze Craze is listed as "PAL" under the auto-detection although it is 262 lines in stable state. Most certainly something to do with how it starts up, but I thought you should know.

Yes, I've noticed this in other ROMs. It's because of how the autodetection only looks at the first 60 frames or so to determine whether it's NTSC or PAL. Maze Craze does something weird at startup, which throws off the detection. There's actually already a bug report about it in the Stella tracker on this site.

BTW, this is a perfect time to point out the Stella tracker Anyone interested should take a look at the reported bugs and suggestions, and add comments (or new reports) where appropriate.

Finally, this relates directly to you Omegamatrix; I believe you're the person that loaned me a KrokCart. I sent an email indicating I'm finished with it, and would like to return it, but I never got any message back. Please respond by PM when you get a chance.

I replied a couple of weeks ago. I just checked my messages and it is there. Can you check again? It should be part of the conversation.


I've been having problems with getting messages as well. I asked Al to look at this, but haven't heard from him in a few weeks.

[almightytodd]

Hey Stephena,

I just wanted to chime in with a big THANK YOU for all of your hard work on this. I'm a programmer/analyst by profession, but I wouldn't even know where to start in taking up a project like this. I see by the notes in your profile that you started just wanting to be involved in maintaining the Linux side of things, but you've ended up supporting upgrades for all systems. Your work has resulted in my ability to enjoy the classic games of my youth on my computer, as well as to try out the awesome growing assortment of home brews and hacks.

I have no criticisms and no requests. I just want to give you my thanks.

THANK YOU !!! THANK YOU !!! THANK YOU !!!

[stephena]

Random Terrain, on Sat Nov 28, 2009 11:32 AM, said:

So nothing is wrong with Stella in this case, it's just giving a slightly different result than a real Atari 2600. This wasn't a complete waste of time. At least we know that we should hit the reset switch before playing the first round of E.T. whether we're using a real Atari 2600 or Stella.

OK, so I'll leave this issue for now. I'll keep in mind for future testing, in case I need to work on the randomness again.

[stephena]

Omegamatrix, on Sat Nov 28, 2009 12:12 PM, said:

I replied a couple of weeks ago. I just checked my messages and it is there. Can you check again? It should be part of the conversation.

I've been having problems with getting messages as well. I asked Al to look at this, but haven't heard from him in a few weeks.

I don't see it. Please try sending a new message, or alternatively, sending it to my sourceforge account directly (stephena@users.sourceforge.net).

[stephena]

almightytodd, on Sat Nov 28, 2009 12:35 PM, said:

Hey Stephena,

I just wanted to chime in with a big THANK YOU for all of your hard work on this. I'm a programmer/analyst by profession, but I wouldn't even know where to start in taking up a project like this. I see by the notes in your profile that you started just wanting to be involved in maintaining the Linux side of things, but you've ended up supporting upgrades for all systems. Your work has resulted in my ability to enjoy the classic games of my youth on my computer, as well as to try out the awesome growing assortment of home brews and hacks.

I have no criticisms and no requests. I just want to give you my thanks.

THANK YOU !!! THANK YOU !!! THANK YOU !!!

Always good to hear from people who appreciate my work, especially when they're from the software field and understand exactly how much work is really involved. I must admit that my contributions aren't totally altruistic, though. I obtained one of my first real jobs based on Stella One thing is for sure; working on cross-platform code forces you to see all the warts of each different operating system. It makes you look at the 'platform wars' in a different way when you realize all systems are, as the saying goes, 'same crap, different pile'!

[Omegamatrix]

Stephena, I just sent you a PM (partially to test my messenger). Please let me know if you recieve it.

[e1will]

Is Stella 3.0 handling the AtariVox EEPROM emulation differently than 2.8.x did?

I can't seem to get 3.0 to either read the existing atarivox_eeprom.dat file or create a new one, and running games that worked fine under 2.8.4 (e.g. Man Goes Down) no longer save or load under 3.0.

--Will

[stephena]

e1will, on Thu Dec 3, 2009 7:04 PM, said:

Is Stella 3.0 handling the AtariVox EEPROM emulation differently than 2.8.x did?

I can't seem to get 3.0 to either read the existing atarivox_eeprom.dat file or create a new one, and running games that worked fine under 2.8.4 (e.g. Man Goes Down) no longer save or load under 3.0.

--Will

Nothing AVox-related was touched for the 3.0 release. About the only thing that's changed in the past few releases (for Windows) are the locations of the various files that Stella uses. This includes the atarivox_eeprom.dat file. From the manual:

The location of the EEPROM files are configurable through the '-eepromdir' commandline argument and within the application itself.  If the path for these files hasn't been set, the default location will depend on the version of Stella, as follows:

Windows
   %APPDATA%\Stella\atarivox_eeprom.dat and %APPDATA%\Stella\savekey_eeprom.dat
                   OR
   _BASEDIR_\atarivox_eeprom.dat and _BASEDIR_\savekey_eeprom.dat<br>
    (if a file named 'basedir.txt' exists in the application directory containing the full pathname for _BASEDIR_)

Note that these EEPROM files will be created when necessary, and initialized as a real EEPROM would be (containing all $FF).  The files can be manually deleted, which is very useful in testing cases where a ROM is accessing the EEPROM for the first time.

Maybe the new locations have something to do with it??

Of course, the specific ROM must actually use the AVox device (ie, it must have the controller type set to AtariVox, either in its properties or manually from the commandline). Otherwise, a EEPROM dat file will never be created.

Edited by stephena, Fri Dec 4, 2009 11:35 AM.

[e1will]

stephena, on Fri Dec 4, 2009 11:33 AM, said:

Maybe the new locations have something to do with it??

Of course, the specific ROM must actually use the AVox device (ie, it must have the controller type set to AtariVox, either in its properties or manually from the commandline). Otherwise, a EEPROM dat file will never be created.

I've tried specifying different locations for EEPROM path, including these:
~\Application Data\Stella\
C:\Stella\

...and I get the same results each time. I know it's not a Windows permissions issue, since Stella has no problem with the "Save ROM" feature in the debugger with ROMs in the same directory as what's specified in the EEPROM path.

This behavior is consistent with other games I've tried that have AtariVox functionality (e.g. Juno First says "SAVEKEY CARD NOT FOUND!" when I start it in the emulator.)

Anything else I might try? Am I correct in understanding that Stella should create C:\Stella\atarivox_eeprom.dat if stella.ini shows "eepromdir = C:\Stella\" and I start a game like Juno First?

--Will

EDIT: Nevermind! The problem was the P1 controller type. Apparently it had reverted to Joystick somehow. Changing it back to AtariVox fixed the problem. Thanks for the reminder to check that setting.

Edited by e1will, Fri Dec 4, 2009 12:05 PM.

[Buzbard]

I decided to make a sort of composite image for the 32-in-1 cart that would show all 32 screen shots in one, so I loaded up the screen shots in Photoshop, put them together and saved the .png file to my stella/screenshots folder.

When I stared Stella to see if it worked, it didn't. The image was trashed, not the file itself, it's just that Stella can't display it.
I saved it first as a non-interlaced png then I tried the interlaced png, still didn't work.
So, I copied the image to MSPaint and saved, and it worked.

I've attached all the files so you can check 'em out.
I'm using Photoshop CS2 v9.0.2 if that helps.

Attached Files

•  snaps.zip   376.79K   73 downloads

Edited by Buzbard, Tue Dec 22, 2009 4:47 PM.