Strange Color Problem with Stella

[+stephena]

You could also have an issue with your console - a leaking MOSFET in the TIA could cause INPT0-3 to rise faster than other consoles.

I'm thinking this is the issue. Whenever I use the Harmony for the first time (after an extended break), as soon as I power on, the menu 'cycles' as if one of the joystick directions is being pressed. If I rotate the joystick about all axis, turn off the system and turn it on again, it seems to go away. It's almost as if the Harmony is detecting a paddle or something because of the D7 bit being on (when it shouldn't be for a joystick). I've had issues in the past with the Cosmic Ark starfield effect too. In a previous release, I tweaked the TIA emulation to display what I was seeing, when it wasn't what anyone else was getting. The next release reversed this modification. I think my console is somewhat borked. Kind of irritating, really, as it seems I can't use it as test system anymore.

 

While this is something that might be emulated, some of the other ideas in this thread may not be consistent among hardware. As stated, different consoles will give different values when reading undriven bits. Also, different hardware will as well (Harmony will always read D6 as 1, for instance) and some EPROMs tend to pull several bits to 1.

True, but the behaviour we're having problems with is D7, which isn't an undriven bit.

[+stephena]

While this is something that might be emulated, some of the other ideas in this thread may not be consistent among hardware. As stated, different consoles will give different values when reading undriven bits. Also, different hardware will as well (Harmony will always read D6 as 1, for instance) and some EPROMs tend to pull several bits to 1.

Now this gets to the heart of what I was wondering earlier in the thread, although I may not have expressed it as such. If the intention was for the sprites to be white, then is it better to try to "fix" the emulation so it gives white invaders instead of pink invaders-- even though the results might vary on different consoles, and possibly also depending on which kind of cart is used to publish the game-- or is it better to fix the game so it always gives the intended color, despite the type of cart used and the console it's played on? I mean, if it's really a bug (zero-page load error) in the program, then I think it's better to correct the program.

 

Michael

Absolutely, an error in a ROM should be fixed by the programmer before it is released. But from my POV, the emulation must be correct in accurately producing the error. Otherwise, the developer has no idea it exists. In this particular case, the results from Stella are definitely in error. Only bits D5 to D0 are undriven, so only those should take on the last value on the databus (or alternatively, a random value if you use 'tiadriven' commandline argument). In no case should it ever override D7 or D6 in TIA reads where those bits are valid. And this was an error on my part, as I forgot to mask the return value by 0x3F (or 0x7F). The other problem is my console, which seems to have some TIA issues.

 

Overall, I'm content that this issue is now fixed. The code has been updated in Stella, and I now need to look for another TIA chip for my console. Anyone willing to donate one?

[+batari]

While this is something that might be emulated, some of the other ideas in this thread may not be consistent among hardware. As stated, different consoles will give different values when reading undriven bits. Also, different hardware will as well (Harmony will always read D6 as 1, for instance) and some EPROMs tend to pull several bits to 1.

True, but the behaviour we're having problems with is D7, which isn't an undriven bit.

D7 on INPT0-INPT3 is not driven high but instead goes to a high impedance state, so it's possible that certain consoles or EPROMs could affect this behavior, especially those that seem to pull values high.

[SeaGtGruff]

if it's really a bug (zero-page load error) in the program, then I think it's better to correct the program.

 

Michael

Absolutely, an error in a ROM should be fixed by the programmer before it is released. But from my POV, the emulation must be correct in accurately producing the error. Otherwise, the developer has no idea it exists. In this particular case, the results from Stella are definitely in error. Only bits D5 to D0 are undriven, so only those should take on the last value on the databus (or alternatively, a random value if you use 'tiadriven' commandline argument). In no case should it ever override D7 or D6 in TIA reads where those bits are valid. And this was an error on my part, as I forgot to mask the return value by 0x3F (or 0x7F).

But see, I don't know if that's the "real" solution. Yes, it produces the white color that's seen on (most?) real consoles-- although (if I understand correctly) maybe not on all consoles or on all cartridge types. So yes, you want Stella to emulate the way a real console would behave. Except in this case, how does that let the programmer know there's an error in what he's doing? The only way this particular programming error was discovered was because Stella 3.0 and 3.1 did *not* produce the white color that was intended, therefore in this case I think it was a *good* thing that Stella didn't reproduce the actual behavior. True, the zero-page load error could have been found with the utility that batari wrote a while back, but maybe it would be nice to have some kind of toggle option for this in Stella? One setting would replicate the behavior (most commonly) seen on a real console and cart, while the other setting would return some other value when a zero-page load error is encountered-- like producing a return value that cycles through all 255 possible values each time the load is executed (i.e., first time it's 0, second time it's 1, third time it's 2, etc.). A single unchanging return value might not call attention to the error, because it might just happen to be the "expected" return value (like a white color). But it would be pretty hard to miss that there's a bug somewhere if the invaders were flashing through the rainbow of all possible colors.

 

Also, if the actual results of a zero-page load error can conceivably vary depending on the console, the type of cart used, or (as I believe supercat once suggested) the room temperature, day of the week, phase of the Moon, etc.-- then how should you emulate that? In other emulators-- for example, Atari 800 emulators-- there are settings to specify the type of machine (400, 800, 600XL, 800XL, 65XE, 130XE, etc.), the version of the operating system, and so on. There do seem to be a few cases where the type of console can make a difference with Atari 2600 games. For example, the number of cycles (or partial cycles) that it takes to update a playfield register can vary slightly-- (if I remember correctly) it's two-thirds of a cycle on most consoles, but is a whole cycle on others (made in Taiwan? Gemini clones? I forget). And I think I've read posts that suggested the starfield effect can vary a bit on different consoles (but I'm not sure about that). So maybe it would eventually be useful to add a setting in Stella to let you pick a particular console (or cartridge type, etc.), so programmers could accurately emulate the known quirks of a particular console (or cartridge type)? That may not be very feasible right now, but it would be helpful to programmers if they could test how their WIPs will look/act on different consoles/carts/etc. Of course, first we'd need to make a good list of what any such quirks are.

 

Michael

Edited August 19, 2010 by SeaGtGruff

[Omegamatrix]

Space Invaders is loading $4E, but a look at the TIA memory map just says that the register is undefined. It's not connected to any of the inputs or collision registers. So are bits 7 and 6 undriven for it, and all the other registers that are completely undefined for reads?

 

 

What is happening with an eprom that may or may not make it drive some bits?

 

 

 

 

 

There do seem to be a few cases where the type of console can make a difference with Atari 2600 games. For example, the number of cycles (or partial cycles) that it takes to update a playfield register can vary slightly-- (if I remember correctly) it's two-thirds of a cycle on most consoles, but is a whole cycle on others (made in Taiwan? Gemini clones? I forget).

 

I don't know about the playfield on a Gemini, but I did want to pipe in here that I have one of the late Taiwanese Atari Jr's which have a slower TIA. I read about it on the Stella Mailing list archives when I was trying to figure out why my Jr wasn't displaying my program correctly. Eckhard replied to someone about the score digits being messed up in Thunderground on their Jr, and the serial number on their Jr close to mine. Here is Thundeground on my Jr (left pic), and on a 4 switch woody (right pic).

 

[SeaGtGruff]

I don't know about the playfield on a Gemini, but I did want to pipe in here that I have one of the late Taiwanese Atari Jr's which have a slower TIA. I read about it on the Stella Mailing list archives when I was trying to figure out why my Jr wasn't displaying my program correctly. Eckhard replied to someone about the score digits being messed up in Thunderground on their Jr, and the serial number on their Jr close to mine. Here is Thundeground on my Jr (left pic), and on a 4 switch woody (right pic).

Thank you! What we ought to do is start a separate topic in the 2600 programming forum for posting about these kinds of quirks-- maybe a pinned topic-- so we can assemble a comprehensive and easy-to-find list of known quirks, maybe create some test programs, and document the behavior observed on different machines as best we can.

 

Michael

[Omegamatrix]

Thank you! What we ought to do is start a separate topic in the 2600 programming forum for posting about these kinds of quirks-- maybe a pinned topic-- so we can assemble a comprehensive and easy-to-find list of known quirks, maybe create some test programs, and document the behavior observed on different machines as best we can.

 

I agree 100% Michael. I've wanted to do a mass testing of illegal opcodes for example. This would require more than me and you though. We need many people to test many consoles. How about a thread where all the testing is done, and then the pinned thread basically has the results by console type plus the particular test programs we found to expose quirks?

 

 

It'd be nice too to get serial numbers for quirky consoles, and then we might be able to say all Jr's between Sn XX and XX are known to have a crappy TIA, etc... and here is a test rom to see! Then you can load the test rom on your Harmony and fire it up and it'll say "You Suck!!" while the screen goes red. Just kidding about the red screen part.

 

 

 

I'd be glad to help with what I can on this, but over the next 2 weeks I got to write a big report for school. After that no problem. If more people chime in then maybe we can get some good ideas on what we should test for first. I know Thomas said something about some 7800's update the playfield a little later then they should. It would be nice to find which ones they are, and if the timing can be determined that would be even better.

[Omegamatrix]

Here is the first test rom. It'll endlessly scroll and print the values in RIOT ram. Reset will quickly bring you back to register $FF. Speed for moving to the next digit can only be done in the assembly file and recompiling.

 

 

I'm using SWCHB as a counter, so unless Stephena gives you a demo version like he did for me this rom won't work in Stella as is. On real hardware it should work no problem. I'll test it a bit tonight on real hardware, and much more so tomorrow.

 

 

TestRiotRam.zip

 

 

It's kind of cool only using 1 byte (actually 7 bits) of ram too!

[Nukey Shay]

Since the topic concerns invalid addresses, I'd suggest using

 

lda #$1F

.loop

lsr

bne .loop

 

...instead of those $2E's. The leftover cycle can be thrown into one of the other lines if it's important.

[Omegamatrix]

Wow, am I ever getting some nutty results with this!!!

 

 

Okay, I got 6 consoles going now. I forgot and then remembered that I have a ColecoVision with and Atari 2600 expansion model. As soon as I pulled it out I tested all the SWCHB and SWCHA roms I wrote, and they all passed. Then I tried my new rom that checks the initial state of RIOT ram. This test was done with a Krok cart in single image mode.

 

 

Guess what? All zeros for every location on the ColecoVision. I tried lots of things to make this fail. First I tried playing a different cartridge before hand. No dice, still all zeros. Then I tried frying the console with and without the Krok cart in. Still no dice. I'm thinking unless something else is happening, the ColecoVision is clearing the ram at power-up. I have no evidence to back that up.

 

 

Next I tried my Funvision clone. It was all zeros too and I thought I was on the track to something. Then I noticed it would jump to #$20 at $8E and $8D for some reason. I tried the same things to make this fail, but I still got #$20 at these 2 locations. This console is completely undocumented. I only know of one other Sly person that owns a NTSC one like mine.

 

 

Okay then I tried my 4 switch woody. I found it was random values at all locations. However, when I powered it on/off more of those locations would turn from some random value to $00. It seemed if I fried it a few times it went to all zeros. So at this point I think everything is sort of good because it is tending towards zeros like the other consoles. Even though it really is different, at least the trend is going towards something.

 

 

Then I tried my Jr. I found that no matter what I fried it as, and no matter what game I played before hand, I get the same values. Now I only have looked at the first few registers because it's so late, but it really looks like it's hardcoded with the same values. I see #$40 at $FF, followed by $05 at $FE, and so on. Tomorrow I'll document it.

 

 

Finally I tried my two 7800's. I found that yes they did have the hard coded values as expected, but the $FF values at the end of the file were different. Now I have made both of my 7800's into dumpers, so I think that the different bytes are probably just the new bios put in. They seem to be the same between both 7800's. I'm sure glad Nukey picked different values from these to detect a 7800 though!

 

 

Speaking of 7800 detection, Batari if you are reading this there seems to be a bit of tumbleweed blowing through the Harmony thread about 7800 detection. It kind of worries me that no one is responding.

 

 

What a horribly long post! I got to do some more testing tomorrow, especially mapping out the fixed values in my Jr and seeing if the 4 switch woody is retaining values from the previous game.

[Omegamatrix]

Since the topic concerns invalid addresses, I'd suggest using

 

lda #$1F

.loop

lsr

bne .loop

 

...instead of those $2E's. The leftover cycle can be thrown into one of the other lines if it's important.

I see what you`re saying Nukey, but that new rom is just for reading the RIOT ram and not the invalid addresses.

[+stephena]

But see, I don't know if that's the "real" solution. Yes, it produces the white color that's seen on (most?) real consoles-- although (if I understand correctly) maybe not on all consoles or on all cartridge types. So yes, you want Stella to emulate the way a real console would behave. Except in this case, how does that let the programmer know there's an error in what he's doing? The only way this particular programming error was discovered was because Stella 3.0 and 3.1 did *not* produce the white color that was intended, therefore in this case I think it was a *good* thing that Stella didn't reproduce the actual behavior. True, the zero-page load error could have been found with the utility that batari wrote a while back, but maybe it would be nice to have some kind of toggle option for this in Stella? One setting would replicate the behavior (most commonly) seen on a real console and cart, while the other setting would return some other value when a zero-page load error is encountered-- like producing a return value that cycles through all 255 possible values each time the load is executed (i.e., first time it's 0, second time it's 1, third time it's 2, etc.). A single unchanging return value might not call attention to the error, because it might just happen to be the "expected" return value (like a white color). But it would be pretty hard to miss that there's a bug somewhere if the invaders were flashing through the rainbow of all possible colors.

There's already an option for that; the commandline argument 'tiadriven', which will introduce randomness into undriven pins. And it does do exactly what you suggest - show a rainbow of colours. Granted, this is a commandline argument and can't be activated from the UI (yet), but it is there. It was added on the request of Batari for exactly the reasons you explain. However, I'm concerned with the default behaviour of Stella as it relates to most consoles. IMO, the default should be to act as a real system, and not immediately point out bugs in programming. There are (or eventually will be) options available for the developer to test correctness, but it shouldn't be activated by default.

[+stephena]

Here is the first test rom. It'll endlessly scroll and print the values in RIOT ram. Reset will quickly bring you back to register $FF. Speed for moving to the next digit can only be done in the assembly file and recompiling.

I'll test on a real system when I get home. Thanks for the ROM, BTW.

 

I'm using SWCHB as a counter, so unless Stephena gives you a demo version like he did for me this rom won't work in Stella as is. On real hardware it should work no problem. I'll test it a bit tonight on real hardware, and much more so tomorrow.

You can forward the email with the link if you like. I can't compile another build that way, as I've changed some code and some other things are currently not complete yet.

[+stephena]

Wow, am I ever getting some nutty results with this!!!

Snipped useful results ...

 

OK, so it seems that at least half of your test systems either start or eventually settle down to all zeroes. Now the question is, what's the best default to use for Stella? Right now it randomizes all RAM, even SC RAM (if applicable). It would be very easy to add an option to selectively randomize RAM. But what should the default be? Should randomization default to off (like other emulators and half your test cases) or on (like Stella works now)? I'm leaning to off, since it fixes several ROMs that work in other emulators and on a real system (or mine, at least).

[+batari]

What is happening with an eprom that may or may not make it drive some bits?

I don't know, but this behavior has been observed with certain CMOS EPROMs. They pull values up strong enough to return $3F consistently for many of the zero page addresses.

[SeaGtGruff]

maybe it would be nice to have some kind of toggle option for this in Stella? One setting would replicate the behavior (most commonly) seen on a real console and cart, while the other setting would return some other value when a zero-page load error is encountered-- like producing a return value that cycles through all 255 possible values each time the load is executed (i.e., first time it's 0, second time it's 1, third time it's 2, etc.). A single unchanging return value might not call attention to the error, because it might just happen to be the "expected" return value (like a white color). But it would be pretty hard to miss that there's a bug somewhere if the invaders were flashing through the rainbow of all possible colors.

There's already an option for that; the commandline argument 'tiadriven', which will introduce randomness into undriven pins. And it does do exactly what you suggest - show a rainbow of colours. Granted, this is a commandline argument and can't be activated from the UI (yet), but it is there. It was added on the request of Batari for exactly the reasons you explain. However, I'm concerned with the default behaviour of Stella as it relates to most consoles. IMO, the default should be to act as a real system, and not immediately point out bugs in programming. There are (or eventually will be) options available for the developer to test correctness, but it shouldn't be activated by default.

I didn't realize there was already an option for it, so I'm glad you told me! I agree, the default should be for Stella to emulate a standard 2600 as accurately/precisely as possible. Anything other than that should require a command-line switch, configuration variable, or some such.

 

Michael

[Omegamatrix]

I'm leaning to off, since it fixes several ROMs that work in other emulators and on a real system (or mine, at least).

 

 

Which roms? How would these roms work on a 7800 or a Harmony cart with the RIOT ram is always fixed?

 

 

As for a default, I'm strongly leaning towards randomization. The 7800's are excluded from the sample data because their start-up values are always fixed. The Colecovision is it's own beast... I'd be much more interested in what a Gemini does. The rare Funvision clone can't compare with the 30 million or so legit 2600 consoles sold, so really should it count? I mean their is only 2 NTSC ones accounted for.

 

 

IMHO the default should be derived mostly from what is happening on first party consoles. I tested my Jr some more today, and found that some registers do change. It is a tough SOB though. On the other hand my 4 switch starts trending to 0's very quickly. It should be noted that none are starting as zero's though (unless you are frying the 4 switch woody with no cart in it for a long time). There is quite a bit of other data in there pardon the pun.

 

 

 

I got to write some more programs and do some more tests. Stephena, you should try the rom on your console to see what it does. Even though yours is defective see what it does. Try starting with a game before, etc... Anyhow I got some good ideas of stuff to try, and I'll let you know of the results.

[+stephena]

I'm leaning to off, since it fixes several ROMs that work in other emulators and on a real system (or mine, at least).

 

 

Which roms? How would these roms work on a 7800 or a Harmony cart with the RIOT ram is always fixed?

 

 

As for a default, I'm strongly leaning towards randomization. The 7800's are excluded from the sample data because their start-up values are always fixed. The Colecovision is it's own beast... I'd be much more interested in what a Gemini does. The rare Funvision clone can't compare with the 30 million or so legit 2600 consoles sold, so really should it count? I mean their is only 2 NTSC ones accounted for.

 

 

IMHO the default should be derived mostly from what is happening on first party consoles. I tested my Jr some more today, and found that some registers do change. It is a tough SOB though. On the other hand my 4 switch starts trending to 0's very quickly. It should be noted that none are starting as zero's though (unless you are frying the 4 switch woody with no cart in it for a long time). There is quite a bit of other data in there pardon the pun.

 

 

 

I got to write some more programs and do some more tests. Stephena, you should try the rom on your console to see what it does. Even though yours is defective see what it does. Try starting with a game before, etc... Anyhow I got some good ideas of stuff to try, and I'll let you know of the results.

I'm about to do the 3.2 release, and I did go with randomization as the default. But I also added a commandline argument (ramrandom) which can be used to turn it off, and default to zeroing RAM instead.

 

Thanks for all your test ROMs, and continued testing. Anything we find after this will have to be in a point release, as I want to get 3.2 out the door (the last release was in April).

 

EDIT: OK, I just did the 3.2 release, which fixes the issue in question. Omega, please use version 3.2 in any test ROMs you create, since new code was added after the last test build I sent you.

[sandmountainslim]

Color problem definately fixed!

 

Thanks for the work!

 

Wp

[SeaGtGruff]

I don't know about the playfield on a Gemini, but I did want to pipe in here that I have one of the late Taiwanese Atari Jr's which have a slower TIA. I read about it on the Stella Mailing list archives when I was trying to figure out why my Jr wasn't displaying my program correctly. Eckhard replied to someone about the score digits being messed up in Thunderground on their Jr, and the serial number on their Jr close to mine.

When you say "a slower TIA," do you mean the oscillator rate, or something else? I'll have to start digging through the stella archives to see what Eckhard said.