Stella 3.1 released

[Envisaged0ne]

Okie, an update to my previus problem...I downloaded the .ZIP version and extracted it in one of the same places I had extracted the .EXE installer. And for some reason I was able to assign the buttons without any problems. Dunno why the .EXE was causing me so much trouble, but at least it's working now.

[+stephena]

Thanks for all of the hard work you do on this project! This probably isn't the right forum, but I know that you did some work on the Harmony Cart. Should the improvements that you make be included in future Harmony releases? (when applicable, that is. Issues that aren't OS specific.) OR is that another animal completely? Just wondering, because I tend to play with the Harmony Cart and my CC2 more than with Stella. (or any emulator for that matter. Stella is the one emulator that I do use if I am using one)

Yes, I still work on the HarmonyCart programming software (ie, the interface you see when you load BIOS images onto the cart). The HarmonyCart includes bankswitch autodetection code from Stella, so as new schemes are added to Stella or the autodetection is improved, it will be added to HarmonyCart as well. Also on the (far) horizon is ARM emulation in Stella, so it can basically 'emulate' the Harmony entirely.

 

Again, you have done a great service. The improvements that you have made since the early days are incredible. Thank you again!

 

Buck

While I haven't done this alone (in the past), I am proud of the most recent changes in the past few releases. Stella is starting to stabilize as it's getting much more testing and feedback now. So while the new features are nice, the 'polish' is what I'm most proud of. We're not completely there yet, but I'm working on it ...

[+stephena]

Okie, an update to my previus problem...I downloaded the .ZIP version and extracted it in one of the same places I had extracted the .EXE installer. And for some reason I was able to assign the buttons without any problems. Dunno why the .EXE was causing me so much trouble, but at least it's working now.

Good to hear that the problem is solved, but I have absolutely no idea why it would cause a problem. The files in the EXE are exactly the same as the ones in the ZIP. In fact, both archives are created by the same script file at the same time, to lessen any potential problems. One thing I will point out is that when upgrading, you should always completely replace the old version. That means not just copying over the Stella.exe and using an old SDL.dll. The files aren't mix-and-match; you need either all the old files or all the new ones.

[Buzbard]

While I haven't done this alone (in the past), I am proud of the most recent changes in the past few releases. Stella is starting to stabilize as it's getting much more testing and feedback now. So while the new features are nice, the 'polish' is what I'm most proud of. We're not completely there yet, but I'm working on it ...

 

You should be proud! Stella has become (IMO) the emulator that others strive to be like. We all owe you a great deal of thanks for your hard work on this great project.

 

Here's an idea I had recently for a new feature.

Some of the 'Atari' releases, and maybe some others, had a game variation grid in their manuals. I thought it would be cool to have something like that in Stella also. Here's a mock-up screenshot to better explain the idea.

Edited May 2, 2010 by Buzbard

[+stephena]

OK, Stella 3.1.2 was just released, which updates the DPC+ bankswitching scheme to support 32K ROMs with ARM code (note that the ARM code is ignored for now). A few other fixes were added as well (you can look at the 3.1.2 release thread for more info). This version can be downloaded from the links in the original post. Again, please report any bugs directly in this thread (or by email).

[HuckleCat]

This really is a fantastic emulator, and in my opinion is easily the best of the 2600 emus. Thank you, big time, for your efforts. The only problem I am having with it is getting my USB gamepad to work right with it.

 

I am running Windows 7, 32-bit, and am using an Xbox 360 pad. Stella will see the controller fine, it will just be insanely sensitive, to the point where using the controller makes things unplayable. The menus will even go haywire, as if the analog sticks are being used when they are not. The controller works fine with all my other emus, (Kega, BSNES, MAME, AppleWin, Nestopia), and even works fine with PCAE.

 

But, honestly, your emu blows PCAE out of the water. I'd much rather use Stella.

 

Any tips or suggestions?

[+stephena]

This really is a fantastic emulator, and in my opinion is easily the best of the 2600 emus. Thank you, big time, for your efforts. The only problem I am having with it is getting my USB gamepad to work right with it.

 

I am running Windows 7, 32-bit, and am using an Xbox 360 pad. Stella will see the controller fine, it will just be insanely sensitive, to the point where using the controller makes things unplayable. The menus will even go haywire, as if the analog sticks are being used when they are not. The controller works fine with all my other emus, (Kega, BSNES, MAME, AppleWin, Nestopia), and even works fine with PCAE.

 

But, honestly, your emu blows PCAE out of the water. I'd much rather use Stella.

 

Any tips or suggestions?

As you say, I believe it's related to the analog axes on your device. There's already been a report of analog issues when remapping events; I'd say this issue is related (or basically the same thing). I have no suggestions for now, as it's not something that can be fixed on your end. I'll have to track down a gamepad that acts the same way, and try to figure out exactly what's goign on. Hopefully, I can come up with something for the next release.

 

Can an XBox 360 pad be connected directly to a computer, or do you need some sort of adapter?

 

Does anyone want to donate such a device?? Hint, hint

[HuckleCat]

If you get one of the corded X360 pads, they're already USB, just plug it in and WinXP/Vista/7 will see it and add drivers.

 

stdout reports it as such:

 

Joystick devices found:

0: XBOX 360 For Windows (Controller) with 5 axes, 1 hats, 0 balls, 10 buttons

 

 

The cordless one requires some sort of adapter that costs way too much. I'd donate my corded one, but it's the only one I have. =( They're like 20 bucks new on Amazon, and probably much cheaper on Ebay, since 360 players prefer the cordless one.

[+stephena]

If you get one of the corded X360 pads, they're already USB, just plug it in and WinXP/Vista/7 will see it and add drivers.

 

stdout reports it as such:

 

Joystick devices found:

0: XBOX 360 For Windows (Controller) with 5 axes, 1 hats, 0 balls, 10 buttons

 

 

The cordless one requires some sort of adapter that costs way too much. I'd donate my corded one, but it's the only one I have. =( They're like 20 bucks new on Amazon, and probably much cheaper on Ebay, since 360 players prefer the cordless one.

So just to confirm, the corded one is what you have which is causing problems? Could you provide a link to the item on Amazon, so I can see exactly the model I should be looking for (it's a waste of money on my end if I don't get exactly the one that's causing problems).

 

Also, we should probably move this to email, since I may need more info from you, extra testing, etc. Send me a PM through AtariAge and we'll talk about this further.

[KevinMos3]

I'm not sure exactly how to describe this, but I've had a problem with controllers since I first started using Stella, (back when it was still at 3.0), up till now with version 3.1.2.

 

It's not my particular controller, because I've used 4 different ones with the same result, (a digital Propad 8, and 3 digital-analog combos -- one by Thrustmaster, one by GameElements, and one by Logitech). The only combo controller that works right is the Logitech because you can turn off the analog part. If the D-Pad is seen as a "Hat", the control wants to see only one direction at a time making moving up/down while moving left/right impossible. However, this isn't the issue I'm posting about.

 

The issue I'm referring to is hard to explain because it happens so fast I'm never quite sure what I'm doing that triggers it. I see it all the time when I play Double Dragon because of the way I move around with a lot of diagonals and direction changes. I can be going in a direction (maybe up or down) and then try to move Left or Right and the character will just stand in place, but the walking animation will still happen, (like the player character is just walking in place). When this happens I can continue to hold in the given direction all I want and the character will just stand there "place walking." If I then press Up or Down in addition to Left or Right, the character will move Up or Down, but still not Left or Right. When this happens, I have to move in the opposite direction of what I'm trying to go (Left or Right), and then I can continue to play as normal until this happens again. This is not a problem with the game because it does not do this on other emulators or on real hardware. It does this whether I'm using the digital controller or the Logitech combo with analog mode turned off.

 

I hope that wasn't too confusing. I wish I could make a video of when it happens, but I don't have software for that.

[johnny_boy]

Yup, can confirm the analog over-sensitivity too on my end. It's been this way ever since I got my wired Xbox 360 controller last year. Plugged either under Mac OS X or Windows, it does the same thing. Still definitely playable, but may render one bonkers if trying to set custom button layout. I manage somewhat fine with the defaults, but sometimes wish I could set the d-pad, for games like Pac-Man.

 

BTW, 360 controller is very much recommended for PC gaming. I believe it's the best one on the market right now. Only criticism I could think of would be the weird d-pad. Logitech pads have always given my friends and I trouble in the past. Shoddy build quality.

[+stephena]

This analog sensitivity issue has already been reported on the Stella tracker, and is now the number one bug I'm working on (it's been marked at level 5 priority). I've had some success in duplicating this bug, but I'm waiting to get an XBox controller myself so I can see exactly what's going on. Combined with "real life things", progress has been somewhat slow. However, I expect to have a fix for the next release. In fact, fixing this is what will make the next release happen (version 3.2).

[johnny_boy]

Take all the time you need. I'm just grateful that there even exist such a good and well-supported 2600 emulator.

[+Random Terrain]

• * Added emulation of the "Sega Genesis" controller, with two buttons that are directly supported on a real system.
  

Does anyone know how to make this work with this program:

 

http://www.atariage.com/forums/topic/158596-2-button-games-in-bb-using-sega-genesis-pads-with-the-2600/

 

Seems like I've pressed every key on the keyboard and every button on my USB controller, but the second button doesn't work. Is there some hidden setting I'm supposed to play with? And yes, I looked at this page but it didn't help:

 

http://stella.sourceforge.net/docs/index.html

[+stephena]

• * Added emulation of the "Sega Genesis" controller, with two buttons that are directly supported on a real system.
  

Does anyone know how to make this work with this program:

 

http://www.atariage.com/forums/topic/158596-2-button-games-in-bb-using-sega-genesis-pads-with-the-2600/

 

Seems like I've pressed every key on the keyboard and every button on my USB controller, but the second button doesn't work. Is there some hidden setting I'm supposed to play with? And yes, I looked at this page but it didn't help:

 

http://stella.sourceforge.net/docs/index.html

You have to use the 'Genesis' controller with this ROM. To do so, go to Options -> Game Properties -> Controller, and set 'P0 Controller' to 'Sega Genesis'. Click OK, and then restart the ROM. The first button is tied to the normal joystick button, so it will be the Space key, left Control, or whatever you have that mapped to. The second button is tied to the BoosterGrip 'booster' button, which by default is the '5' key. This can be remapped if you like.

[+Random Terrain]

You have to use the 'Genesis' controller with this ROM. To do so, go to Options -> Game Properties -> Controller, and set 'P0 Controller' to 'Sega Genesis'. Click OK, and then restart the ROM. The first button is tied to the normal joystick button, so it will be the Space key, left Control, or whatever you have that mapped to. The second button is tied to the BoosterGrip 'booster' button, which by default is the '5' key. This can be remapped if you like.

Thanks. It's working great now. I was looking under Input Settings and forgot all about Game Properties.

[+stephena]

You have to use the 'Genesis' controller with this ROM. To do so, go to Options -> Game Properties -> Controller, and set 'P0 Controller' to 'Sega Genesis'. Click OK, and then restart the ROM. The first button is tied to the normal joystick button, so it will be the Space key, left Control, or whatever you have that mapped to. The second button is tied to the BoosterGrip 'booster' button, which by default is the '5' key. This can be remapped if you like.

Thanks. It's working great now. I was looking under Input Settings and forgot all about Game Properties.

Yep, the Input Settings are for remapping events (system-wide), but the Game Properties are for setting things specific to a particular ROM.

[+stephena]

I think I've fixed the analog sensitivity issues within the UI in Stella, at least with the Logitech Dual Action pad that I have. However, I'd like people to test this new code. Send me a PM if you'd like to give the new code a try.

[+batari]

I've found a few bugs in Stella, and I don't know when they appeared or if they've been reported already or not. I will list them in no particular order:

• runto in the debugger no longer works (Stella hangs or crashes no matter the argument)
  
• You can no longer switch banks from the debugger using "bank" from the console or changing the bank number from the bank number text box
  
• 3x video mode doesn't work, nor does software rendering (both crash Stella, but could be my hardware)
  
• Disassembly sometimes shows no instructions at all in "Automatic" mode even when many legitimate instructions exist
  
• Debugger "exec" command sometimes crashes Stella (can't repeat right now)
  
• VBLANK bit 6 to latch joystick buttons doesn't work
  

That's all for now...

[SeaGtGruff]

I've found a few bugs in Stella, and I don't know when they appeared or if they've been reported already or not. I will list them in no particular order:

• runto in the debugger no longer works (Stella hangs or crashes no matter the argument)
  
• You can no longer switch banks from the debugger using "bank" from the console or changing the bank number from the bank number text box
  
• 3x video mode doesn't work, nor does software rendering (both crash Stella, but could be my hardware)
  
• Disassembly sometimes shows no instructions at all in "Automatic" mode even when many legitimate instructions exist
  
• Debugger "exec" command sometimes crashes Stella (can't repeat right now)
  
• VBLANK bit 6 to latch joystick buttons doesn't work
  

That's all for now...

3x video mode and software rendering both work for me, so it might be your hardware.

 

I think the disassembly problem stems from the way the algorithm works, since the same issue occurs in Distella, and Stella's disassembly routines are based on Distella (right?). As I understand it, the disassembly starts from wherever the RESET vector points, and proceeds from there. If any JMPs or JSRs or branches are found, disassembly can proceed from those target addresses, too. But from what I've seen in trying to disassemble ROMs with DIS6502 by manually using the same kind of approach, where it tends to have difficulty is if there are indirect JMPs. There might be other problem situations, as well. But if the algorithm could be improved to look for indirect JMPs and try to determine what their target addresses can be, it should go a long way toward improving disassembly.

 

Michael

[+batari]

I've found a few bugs in Stella, and I don't know when they appeared or if they've been reported already or not. I will list them in no particular order:

• runto in the debugger no longer works (Stella hangs or crashes no matter the argument)
  
• You can no longer switch banks from the debugger using "bank" from the console or changing the bank number from the bank number text box
  
• 3x video mode doesn't work, nor does software rendering (both crash Stella, but could be my hardware)
  
• Disassembly sometimes shows no instructions at all in "Automatic" mode even when many legitimate instructions exist
  
• Debugger "exec" command sometimes crashes Stella (can't repeat right now)
  
• VBLANK bit 6 to latch joystick buttons doesn't work
  

That's all for now...

3x video mode and software rendering both work for me, so it might be your hardware.

 

I think the disassembly problem stems from the way the algorithm works, since the same issue occurs in Distella, and Stella's disassembly routines are based on Distella (right?). As I understand it, the disassembly starts from wherever the RESET vector points, and proceeds from there. If any JMPs or JSRs or branches are found, disassembly can proceed from those target addresses, too. But from what I've seen in trying to disassemble ROMs with DIS6502 by manually using the same kind of approach, where it tends to have difficulty is if there are indirect JMPs. There might be other problem situations, as well. But if the algorithm could be improved to look for indirect JMPs and try to determine what their target addresses can be, it should go a long way toward improving disassembly.

 

Michael

3x is certainly something with my hardware, but it was working in an earlier version.

 

As for the disassembly, the last game I loaded into Stella had 4095 bytes of data with a single RTS in the middle, in a bank that was full of code. I suspect the cause is the bank was not assembled at $F000-$FFFF but rather $D000-$DFFF or something, so possibly it got confused. Whether it's Distella or not, it's still a bug, IMO. Assembling to something other than $F000-$FFFF is very common on bankswitched games so perhaps some heuristics could be done to guess the address range of the bank.

[SeaGtGruff]

As for the disassembly, the last game I loaded into Stella had 4095 bytes of data with a single RTS in the middle, in a bank that was full of code. I suspect the cause is the bank was not assembled at $F000-$FFFF but rather $D000-$DFFF or something, so possibly it got confused. Whether it's Distella or not, it's still a bug, IMO. Assembling to something other than $F000-$FFFF is very common on bankswitched games so perhaps some heuristics could be done to guess the address range of the bank.

Yeah, I can see where bankswitching might interfere with the algorithm. I wonder if the logic could be improved to try to identify the starting address that was used for each bank, based on the JMP and JSR addresses in each bank? That should help. But the algorithm would need to take the bankswitching method into account, since not all methods switch the entire 4K at once. Methods where you have multiple 2K slices that can be switched into different areas could be a real bugger, although presumably any given slice would always be switched into the same area, otherwise there would be problems with the JMP and JSR addresses-- but then again, they might be jumping into the other 2K area, so that could still be a bugger.

 

A more generic approach might be to just start disassembling at the first byte of a bank, and see if the disassembly contains valid code. Even if it starts out with what looks like valid code, it would need to remain valid until reaching a JMP or RTS or absolute combination of branches (e.g., a BNE followed by a BEQ, or something like that). If the disassembly degenerates into gibberish before reaching a "terminal" point, then it would be safe to say that either the starting address was wrong, or it's some kind of data.

 

Maybe the programming community should try to write up some kind of pseudocode to outline the steps for disassembling an unknown ROM? Beginning with the address pointed to by the RESET vector (and possibly also the BRK vector) is an obvious starting point, as well as any addresses targeted by JMPs, JSRs, and branches. As for bankswitched games, trying to determine the ORG/RORG addresses of each bank would be helpful. Trying to identify the target addresses of indirect JMPs should also help. A list of data starting addresses could be created by checking the targets of LDAs, LDXs, and LDYs. And any non-disassembled sections that don't coincide with data starting addresses could be tentatively disassembled to see whether or not they devolve into gibberish before reaching some kind of terminal point. If we can come up with a list of steps, maybe it would help with creating a better algorithm?

 

Michael

[+stephena]

I've found a few bugs in Stella, and I don't know when they appeared or if they've been reported already or not. I will list them in no particular order:

• runto in the debugger no longer works (Stella hangs or crashes no matter the argument)
  
• You can no longer switch banks from the debugger using "bank" from the console or changing the bank number from the bank number text box
  
• 3x video mode doesn't work, nor does software rendering (both crash Stella, but could be my hardware)
  
• Disassembly sometimes shows no instructions at all in "Automatic" mode even when many legitimate instructions exist
  
• Debugger "exec" command sometimes crashes Stella (can't repeat right now)
  
• VBLANK bit 6 to latch joystick buttons doesn't work
  

That's all for now...

As suggested by SeaGtGruff, the bank command no longer working is a side effect of switching the disassembly to Distella. I can look into adding that functionality again, but the reason I removed it was to fix a non-trivial bug. I can't remember what it was right now, but as I said, I'll look into it.

 

If disassembly doesn't show anything at all, obviously that is a bug. Please provide a test ROM.

 

Can you provide a test case where 'exec' and/or 'runto' cause a crash or hangup?

 

Please explain in more detail about the VBLANK thing, preferably with a ROM and use case.

 

As for the video problem, that could be anything. Please provide all related info on your system, such as OS, video card, desktop resolution, etc. As well, make sure you're using the most up-to-date version of your video card drivers? I'm particularly suspicious about this problem, since I haven't changed anything video-related in the past few versions of Stella. Can you try several versions back, and determine when the problem first started?

 

You may notice that all my responses are based on use cases. Basically, while reporting a bug is good, explaining how to duplicate it (with a test ROM, if necessary) is much more useful to me.

[+stephena]

A more generic approach might be to just start disassembling at the first byte of a bank, and see if the disassembly contains valid code. Even if it starts out with what looks like valid code, it would need to remain valid until reaching a JMP or RTS or absolute combination of branches (e.g., a BNE followed by a BEQ, or something like that). If the disassembly degenerates into gibberish before reaching a "terminal" point, then it would be safe to say that either the starting address was wrong, or it's some kind of data.

Stella actually does do this. Upon starting the emulation, if disassembles from the reset vector of the startup bank. Then, on each bank change, it tries to disassemble from the last valid address that was used the last time this bank was entered. If that works, fine, if not, it disassembles from the current PC. At each re-disassembly, it remembers the start address that worked for the next pass.

 

Now, that's the way that Stella 'talks' to Distella. However, there could be a bug in how Distella interprets these 'commands'. It could be that it doesn't like to disassemble starting from certain addresses. It worked for me in all my testing, but that doesn't mean it's completely working.

 

Maybe the programming community should try to write up some kind of pseudocode to outline the steps for disassembling an unknown ROM? Beginning with the address pointed to by the RESET vector (and possibly also the BRK vector) is an obvious starting point, as well as any addresses targeted by JMPs, JSRs, and branches. As for bankswitched games, trying to determine the ORG/RORG addresses of each bank would be helpful. Trying to identify the target addresses of indirect JMPs should also help. A list of data starting addresses could be created by checking the targets of LDAs, LDXs, and LDYs. And any non-disassembled sections that don't coincide with data starting addresses could be tentatively disassembled to see whether or not they devolve into gibberish before reaching some kind of terminal point. If we can come up with a list of steps, maybe it would help with creating a better algorithm?

A better algorithm would definitely be helpful, or at least better testing of the one that exists now. In porting Distella to Stella, I found and fixed several bugs and problems with how it's designed. More work is definitely required here, such as disassembling from ZP RAM and cart address space at the same time. Distella was never designed to do dynamic disassembly (understandable, since it's a static analysis tool).

[+batari]

I've found a few bugs in Stella, and I don't know when they appeared or if they've been reported already or not. I will list them in no particular order:

• runto in the debugger no longer works (Stella hangs or crashes no matter the argument)
  
• You can no longer switch banks from the debugger using "bank" from the console or changing the bank number from the bank number text box
  
• 3x video mode doesn't work, nor does software rendering (both crash Stella, but could be my hardware)
  
• Disassembly sometimes shows no instructions at all in "Automatic" mode even when many legitimate instructions exist
  
• Debugger "exec" command sometimes crashes Stella (can't repeat right now)
  
• VBLANK bit 6 to latch joystick buttons doesn't work
  

That's all for now...

As suggested by SeaGtGruff, the bank command no longer working is a side effect of switching the disassembly to Distella. I can look into adding that functionality again, but the reason I removed it was to fix a non-trivial bug. I can't remember what it was right now, but as I said, I'll look into it.

This is important, I think as changing the bank and typing reset is vital to testing startup state in all banks as some real hardware can start in any bank. Even if it's limited or buggy I'd rather have it back.

If disassembly doesn't show anything at all, obviously that is a bug. Please provide a test ROM.

 

Can you provide a test case where 'exec' and/or 'runto' cause a crash or hangup?

They are working now, but if I find a case, I'll let you know.

Please explain in more detail about the VBLANK thing, preferably with a ROM and use case.

From the Stella Programmer's Guide:

 

12.2 Latched Input Ports (INPT4, INPT5)

 

These two ports have latches that are both enabled by writing a "1" or disabled by writing a "0" to D6 of VBLANK. When disabled the microprocessor reads the logic level of the port directly. When enabled, the latch is set for logic one and remains that way until its port goes LO. When the port goes LO the latch goes LO and remains that way regardless of what the port does. The trigger buttons of the joystick controllers connect to these ports.

 

This is causing a bug in this version of Superbug. I inadvertantly set D6 of VBLANK and detected a button press and release to start the game. Real hardware never detects a release (correctly) while Stella incorrectly detects it. Binary is available here: http://www.atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=167330

 

As for the video problem, that could be anything. Please provide all related info on your system, such as OS, video card, desktop resolution, etc. As well, make sure you're using the most up-to-date version of your video card drivers? I'm particularly suspicious about this problem, since I haven't changed anything video-related in the past few versions of Stella. Can you try several versions back, and determine when the problem first started?

 

You may notice that all my responses are based on use cases. Basically, while reporting a bug is good, explaining how to duplicate it (with a test ROM, if necessary) is much more useful to me.

The video problem is with my old Mac, and it's the same one that had problems before with OpenGL if you remember. I believe it has an ATI Mobility Radeon 9200 with 32MB of video RAM. Resolution is 1024x768. I can go back and see if I can figure out when this bug appeared, as I've been able to use 3x before.

 

A more generic approach might be to just start disassembling at the first byte of a bank, and see if the disassembly contains valid code. Even if it starts out with what looks like valid code, it would need to remain valid until reaching a JMP or RTS or absolute combination of branches (e.g., a BNE followed by a BEQ, or something like that). If the disassembly degenerates into gibberish before reaching a "terminal" point, then it would be safe to say that either the starting address was wrong, or it's some kind of data.

Stella actually does do this. Upon starting the emulation, if disassembles from the reset vector of the startup bank. Then, on each bank change, it tries to disassemble from the last valid address that was used the last time this bank was entered. If that works, fine, if not, it disassembles from the current PC. At each re-disassembly, it remembers the start address that worked for the next pass.

 

Now, that's the way that Stella 'talks' to Distella. However, there could be a bug in how Distella interprets these 'commands'. It could be that it doesn't like to disassemble starting from certain addresses. It worked for me in all my testing, but that doesn't mean it's completely working.

Looking further, disassembly doesn't work when the current PC doesn't match the address range the bank was assembled to. If you need a test case, any bankswitched bB program will do this upon entering a new bank. Things get better once the PC changes by a JMP or JSR (or in bB's case, the first RTS) and it does seem to get better after a while but there is definitely some warm-up time, and when re-entering a bank, things seem to go back to square one. You can use the attached game demo above to see this (do a breakif {_bank == 1} to see.)

 

As for disassembling "from the last valid address that was used the last time this bank was entered," this is not good. All bankswitches among banks with different address ranges will result in error and the PC will not be in the correct range until the first jump. For example, an F8 game may be assembled with $D000-$DFFF in bank 0 and $F000-$FFFF in bank 1. Bankswitching will almost always have the wrong address range upon entry - for example, bank 0 encounters a LDA $1FF9 and bank 1 is entered with PC=$Dxxx.

 

Perhaps the best solution here is to remember the address range of the bank just before it was last exited. Also, to mitigate warm-up issues, I'd use the reset vector as a guide first and never the first PC. Sometimes the reset vectors may be wrong but they won't always be wrong like the first PC will in some games.