Stella 2.7.7 released

[+stephena]

OK, here's another bugfix release for the 2.7 series (also known as 'the release that never ends'). Changes are as follows:

 

  * Corrected emulation of CPU opcodes involving 'decimal' mode (ADC/RRA
and SBC/ISB).  Special thanks to SeaGtGruff and others on the Stella
mailing list for in-depth discussion and creation of test ROMs.

 * Fixed bug in F4SC bankswitching mode; writes to bankswitch addresses
weren't triggering a bank switch.

 * Changed internal sound frequency of Pitfall 2 from 15.75KHz to 20KHz,
as this sounds much more authentic when compared to a real cartridge.

 

As usual, the latest release of Stella can be downloaded here. Please report all bugs in this thread or directly by PM.

 

On a related note, I'm still working on the big stuff for the next major release. So don't worry, I haven't abandoned the TIA improvements, etc. But I've been distracted this week with writing a cross-platform application for programming the KrokCart. It's already working great in Linux, and I hope to add OSX support soon. So hopefully all you non-Windows users will soon have a nice GUI program to use with your KrokCart.

[Trebor]

* Changed internal sound frequency of Pitfall 2 from 15.75KHz to 20KHz,
as this sounds much more authentic when compared to a real cartridge.

 

WOO HOO! Indeed it does! Great update!

 

-Trebor

[+stephena]

* Changed internal sound frequency of Pitfall 2 from 15.75KHz to 20KHz,
as this sounds much more authentic when compared to a real cartridge.

 

WOO HOO! Indeed it does! Great update!

 

-Trebor

That's good to know, but why are you mad?

[Trebor]

That's good to know, but why are you mad?

 

LOL...I have no idea how that angry pic got in there...

 

Believe me - I'm anything but angry...Updating that Pitfall 2 sound inspired me to give the game a couple of plays for high score which I haven't done in awhile.

 

Thanks again...It sounds spot on to the real hardware now.

 

-Trebor

[Wickeycolumbus]

Thank you for fixing F4SC

[Keatah]

A quick two bugs to report. The paddle controller, when using a basic usb joypad, seems to stick a little at the farmost left and right positions in breakout and superbreakout. I have not tried other games yet.

 

And is there a way to increase/decrease mouse-paddle sensitivity?

[e1will]

I don't know if this is a Stella bug or my bug (I'm trying to write a homebrew), but I notice that going into debug mode and then returning to gameplay mode "eats" the sprite that was being displayed.

 

Since I'm new at this it's entirely possible (likely) I'm doing something wrong in the code, but it still seems odd that simply toggling debug mode on and off would change which objects are being displayed. It's almost as if entering debug mode is clearing my variables.

 

Here's how to reproduce this:

 

1. Run duck.bin (attached).

2. Player starts on a blue screen. Go down two screens (past a flashing duck on a red screen) to a yellow "Y" shaped screen.

3. There's a blue and white balloon sprite on the yellow screen. If you do nothing, the balloon remains on the screen indefinitely.

4. If you press the ` key to toggle debug mode, then press it again, the balloon disappears.

 

Any ideas what could be happening?

 

--Will

DUCK.BIN

[+stephena]

I don't know if this is a Stella bug or my bug (I'm trying to write a homebrew), but I notice that going into debug mode and then returning to gameplay mode "eats" the sprite that was being displayed.

 

Since I'm new at this it's entirely possible (likely) I'm doing something wrong in the code, but it still seems odd that simply toggling debug mode on and off would change which objects are being displayed. It's almost as if entering debug mode is clearing my variables.

 

Here's how to reproduce this:

 

1. Run duck.bin (attached).

2. Player starts on a blue screen. Go down two screens (past a flashing duck on a red screen) to a yellow "Y" shaped screen.

3. There's a blue and white balloon sprite on the yellow screen. If you do nothing, the balloon remains on the screen indefinitely.

4. If you press the ` key to toggle debug mode, then press it again, the balloon disappears.

 

Any ideas what could be happening?

 

--Will

Odd, I'll give you that. But I notice that if you enter the debugger and then immediately exit on the *first* screen (the blue one), when you get to the room you specify, the balloon isn't there at all. So something is changing before you even get to the room. I'm in the middle of something right now, so I can't do a full analysis; how are you drawing the balloon? Can you provide source code for that particular part??

[e1will]

Odd, I'll give you that. But I notice that if you enter the debugger and then immediately exit on the *first* screen (the blue one), when you get to the room you specify, the balloon isn't there at all. So something is changing before you even get to the room. I'm in the middle of something right now, so I can't do a full analysis; how are you drawing the balloon? Can you provide source code for that particular part??

 

Thanks. I'll PM you the source... I noticed another artifact that may shed some light on it. I have a "collapsing walls" room that works beautifully... unless you toggle the debugger:

 

1. Start on the blue screen. Go down three screens (past the duck, past the balloon) to a purple room with a shield in it.

2. Go left. The walls will collapse on you unless you escape to the left or right...

3. But if you toggle the debugger in the trap room, the playfield gets messed up until you leave and return.

 

Both the trap room playfield and the balloon location are stored in expanded memory (I'm trying to use the CBS RAM Plus 256-byte method... maybe it's not supported 100%?) and that memory seems to be zeroed out when entering the debugger.

 

The player location (room X/Y) is stored in normal memory and is not affected.

 

--Will

[+stephena]

Odd, I'll give you that. But I notice that if you enter the debugger and then immediately exit on the *first* screen (the blue one), when you get to the room you specify, the balloon isn't there at all. So something is changing before you even get to the room. I'm in the middle of something right now, so I can't do a full analysis; how are you drawing the balloon? Can you provide source code for that particular part??

 

Thanks. I'll PM you the source... I noticed another artifact that may shed some light on it. I have a "collapsing walls" room that works beautifully... unless you toggle the debugger:

 

1. Start on the blue screen. Go down three screens (past the duck, past the balloon) to a purple room with a shield in it.

2. Go left. The walls will collapse on you unless you escape to the left or right...

3. But if you toggle the debugger in the trap room, the playfield gets messed up until you leave and return.

 

Both the trap room playfield and the balloon location are stored in expanded memory (I'm trying to use the CBS RAM Plus 256-byte method... maybe it's not supported 100%?) and that memory seems to be zeroed out when entering the debugger.

 

The player location (room X/Y) is stored in normal memory and is not affected.

 

--Will

How much effort would it be to move one of those locations from expanded memory to normal memory? This would tell for sure if the expanded memory is a problem with the debugger, and if so, it would make it much easier for me to fix it.

[e1will]

How much effort would it be to move one of those locations from expanded memory to normal memory? This would tell for sure if the expanded memory is a problem with the debugger, and if so, it would make it much easier for me to fix it.

 

Sent you a PM with the new assembly. (For the benefit of anyone else reading: If I move the balloon location to zero page, the balloon does not disappear when I toggle the debugger; it only disappears when it's stored in extended RAM.)

 

--Will

[JL]

hi stephena,

 

thanks again for all the great work.

 

Question: The Starpath Supercharger game Dragonstomper , when played using Stella the objects always perform the same exact function; ex- the staff "heals"/increases strength. Is it possible to have the objects perform different "random" function's every time the game is played like on a real console?

 

I thought it might be my dumps but when I try them using z26 the cross becomes the object that "heals"/increases strength. So not random on z26 either, but the result is different so I do not think it is related to the dumps/bins . Personally I prefer the cross doing the healing as it makes the game more fun (or rather a bit easier).

 

Thanks,

JL

Edited May 30, 2009 by JL

[+stephena]

hi stephena,

 

thanks again for all the great work.

 

Question: The Starpath Supercharger game Dragonstomper , when played using Stella the objects always perform the same exact function; ex- the staff "heals"/increases strength. Is it possible to have the objects perform different "random" function's every time the game is played like on a real console?

 

I thought it might be my dumps but when I try them using z26 the cross becomes the object that "heals"/increases strength. So not random on z26 either, but the result is different so I do not think it is related to the dumps/bins . Personally I prefer the cross doing the healing as it makes the game more fun (or rather a bit easier).

 

Thanks,

JL

I'll take a look into it sometime early next week. Obviously something in the code that is supposed to be randomized isn't actually being done.

[+batari]

Speaking of Starpath titles, Survival Island intro screen has incorrect positioning of sprites. There are gaps where there shouldn't be. Try on z26 to compare.

[+stephena]

Speaking of Starpath titles, Survival Island intro screen has incorrect positioning of sprites. There are gaps where there shouldn't be. Try on z26 to compare.

Yes, this is fixed with the new TIA code, which is coming in version 3.0.

[+batari]

Speaking of Starpath titles, Survival Island intro screen has incorrect positioning of sprites. There are gaps where there shouldn't be. Try on z26 to compare.

Yes, this is fixed with the new TIA code, which is coming in version 3.0.

I have a request that may or may not involve the TIA code.

 

It seems that when a zero-page value below $80 is accessed in Stella and other emulators, bits 6 and 7 are returned if they correspond to collision register or controller inputs. For bits 0-5, or for addresses with bit 6 or 7 not driven, the value returned is equal to the address (which is the last value on the data bus.)

 

The problem is that this doesn't always work in practice. Maybe on most consoles, on most carts, it does. But the cases where it doesn't work are common enough that maybe this should be revisited, as it has led to cryptic bugs that were only found months or even years after a cart release, or have yet to be found.

 

What I am proposing is an option to place random values on otherwise undriven bits on TIA addresses. Doing so should make such bugs immediately apparent.

[+stephena]

It seems that when a zero-page value below $80 is accessed in Stella and other emulators, bits 6 and 7 are returned if they correspond to collision register or controller inputs. For bits 0-5, or for addresses with bit 6 or 7 not driven, the value returned is equal to the address (which is the last value on the data bus.)

 

The problem is that this doesn't always work in practice. Maybe on most consoles, on most carts, it does. But the cases where it doesn't work are common enough that maybe this should be revisited, as it has led to cryptic bugs that were only found months or even years after a cart release, or have yet to be found.

 

What I am proposing is an option to place random values on otherwise undriven bits on TIA addresses. Doing so should make such bugs immediately apparent.

If I understand you correctly, I think this option is already somewhat available. Eckhard added a commandline option called '-tiafloat'. The description from the manual is as follows:

Set unused TIA pins to be floating on a read/peek.

 

The following is pseudocode for what it does on a read:

if(pinsAreFloating)
 return value | (databus & 0x3f)
else
 return value | 0x3f

And the following is the actual code:

  .
 .  value is processed above
 .
 // On certain CMOS EPROM chips the unused TIA pins on a read are not
 // floating but pulled high. Programmers might want to check their
 // games for compatibility, so we make this optional. 
 value |= myFloatTIAOutputPins ? (mySystem->getDataBusState() & 0x3F) : 0x3F;

 return value;

 

How would you like this behaviour modified to be more realistic?

[+batari]

When programmers forget the # in an immediate load, for example, games will usually work on most consoles but occasionally fail on some consoles. Simply pulling up the values does not mimic this behavior. There should be an option to add a little randomness to values on D0-D5 and D6 or D7 if the address doesn't use them.

[+stephena]

When programmers forget the # in an immediate load, for example, games will usually work on most consoles but occasionally fail on some consoles. Simply pulling up the values does not mimic this behavior. There should be an option to add a little randomness to values on D0-D5 and D6 or D7 if the address doesn't use them.

OK, I'll add it to the TODO list for the TIA improvements.

[SeaGtGruff]

One thing I noticed the other week, although I haven't tried to research it to see which version it started happening in, or what the exact conditions are that cause it to happen (or rather, if it happens every time)...

 

But I was playing my BIN for the E.T. Book Cart, and I had apparently set the phosphor effect to "on" in the game properties. I wanted to turn the phosphor effect off-- not just the one time, but in the game properties-- so I hit TAB and turned the phosphor effect off. When I used the backslash \ key to restart the BIN, the sound was gone. Exiting the BIN and selecting it again from the menu would not restart the sound. The only way I could get the sound back again was to shut down Stella and then restart it.

 

I'll play around with some other BINs and see if this happens all the time, or if it was some kind of fluke.

 

Michael

[+stephena]

One thing I noticed the other week, although I haven't tried to research it to see which version it started happening in, or what the exact conditions are that cause it to happen (or rather, if it happens every time)...

 

But I was playing my BIN for the E.T. Book Cart, and I had apparently set the phosphor effect to "on" in the game properties. I wanted to turn the phosphor effect off-- not just the one time, but in the game properties-- so I hit TAB and turned the phosphor effect off. When I used the backslash \ key to restart the BIN, the sound was gone. Exiting the BIN and selecting it again from the menu would not restart the sound. The only way I could get the sound back again was to shut down Stella and then restart it.

 

I'll play around with some other BINs and see if this happens all the time, or if it was some kind of fluke.

 

Michael

When you exit one game and start another, does the sound work in each one? Can you try reloading the ROM with 'Control-r' instead of going through the command menu with '\'? Finally, do you have an ATI video card? There have been problems with ATI video cards and sound not working after the first ROM load (strange as it sounds that sound issues are related to the video card).

[SeaGtGruff]

When you exit one game and start another, does the sound work in each one? Can you try reloading the ROM with 'Control-r' instead of going through the command menu with '\'? Finally, do you have an ATI video card? There have been problems with ATI video cards and sound not working after the first ROM load (strange as it sounds that sound issues are related to the video card).

I started Pitfall II and everything was fine. Then I reloaded the ROM with Ctrl-R and the sound was gone. Yes, I have an ATI video card, so that must be it. I guess I never noticed this issue before because (believe it or not) I usually keep the volume turned all the way down!

 

Michael

[+stephena]

When you exit one game and start another, does the sound work in each one? Can you try reloading the ROM with 'Control-r' instead of going through the command menu with '\'? Finally, do you have an ATI video card? There have been problems with ATI video cards and sound not working after the first ROM load (strange as it sounds that sound issues are related to the video card).

I started Pitfall II and everything was fine. Then I reloaded the ROM with Ctrl-R and the sound was gone. Yes, I have an ATI video card, so that must be it. I guess I never noticed this issue before because (believe it or not) I usually keep the volume turned all the way down!

 

Michael

It's almost definitely a problem with Windows and ATI video drivers; the same hardware in Linux and OSX doesn't have the problem. I suspect it's a bug in the drivers, similar to the 'red screen' OpenGL issue that plagued me for a year or so. After some intense testing, it was determined to be a bug in the drivers that was reported years earlier, but never fixed. I'll try to find some time to look into it, but to be honest I'm not hopeful, as I don't have access to the driver source code. For now, Stella will have to be used as a 'single-launch' app - run a game, exit the emulator entirely, then start another.

[Tom-Lynx]

The problems I brought up last month seem to be isolated to the one PC I have with ATI video drivers. My NVIDIA machine works much better.

[SeaGtGruff]

For now, Stella will have to be used as a 'single-launch' app - run a game, exit the emulator entirely, then start another.

I don't have a problem with that. As I said, I usually have turned all the way down, anyway. It's just that I'd noticed it the other day, and thought I'd mention it in case it was an issue you weren't aware of yet.

 

Michael