e1will Posted June 2, 2009 Share Posted June 2, 2009 One other thing: occasionally (somewhere between every 10th and 20th time), Stella will spontaneously go into "Full-screen" mode when a game is selected. Unfortunately for me my video drivers do not support full-screen mode so I get a blue screen of death whenever it does this. It would be nice to either track down and fix the cause of the occasional switch to full-screen mode or provide some configuration option of disabling Full-screen mode entirely for those of us with crappy video drivers. --Will Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 4, 2009 Author Share Posted June 4, 2009 One other thing: occasionally (somewhere between every 10th and 20th time), Stella will spontaneously go into "Full-screen" mode when a game is selected. Unfortunately for me my video drivers do not support full-screen mode so I get a blue screen of death whenever it does this. It would be nice to either track down and fix the cause of the occasional switch to full-screen mode or provide some configuration option of disabling Full-screen mode entirely for those of us with crappy video drivers. --Will I've never heard of this issue before. If you never go to fullscreen mode manually, I can't see how Stella would just change its internal settings and do it anyway. I'm thinking this is a problem with your drivers, and that even if I did add the option, it might still happen (ie, the switch is happening because the drivers sporadically go to fullscreen mode, not because Stella tells it to). In any event, I'll look into adding this, if for no other reason than to narrow down what's causing the problem. On a different note, the FASC extended RAM issues you reported have now been fixed. And you're also able to edit all RAM directly in the debugger RAM area. These changes will be included in the next release, which I hope to do sometime next week. Quote Link to comment Share on other sites More sharing options...
e1will Posted June 4, 2009 Share Posted June 4, 2009 I've never heard of this issue before. If you never go to fullscreen mode manually, I can't see how Stella would just change its internal settings and do it anyway. I'm thinking this is a problem with your drivers, and that even if I did add the option, it might still happen (ie, the switch is happening because the drivers sporadically go to fullscreen mode, not because Stella tells it to). In any event, I'll look into adding this, if for no other reason than to narrow down what's causing the problem. On a different note, the FASC extended RAM issues you reported have now been fixed. And you're also able to edit all RAM directly in the debugger RAM area. These changes will be included in the next release, which I hope to do sometime next week. Thanks (on both counts). I agree, there is definitely a problem with my video drivers (HP laptop running Windows XP) because other apps that try to full-screen also generate a blue screen. However, I've also noticed this sporadic full-screening of Stella on my other PC (a Dell running Vista). It doesn't particularly bother me on the Dell since the Dell does support full screen mode and it's simple enough to turn the full-screen back off after it enables itself. --Will Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 5, 2009 Author Share Posted June 5, 2009 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 Hmm, I just looked at the code for this bankswitching scheme, and it seems to be properly randomizing all the RAM locations. So I would need to further examine how the actual ROM is 'randomizing' the functionality. It might help if you could provide a state file for just after you pick up such an item, as I don't have time to play the game until it occurs. Furthermore, a commented disassembly of the ROM would be nice, but I suppose no such thing exists. Also, can we confirm that a real console does randomize this? Have you personally played the game on a real console several times, and noticed that the behaviour is different on different occasions?? Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted June 5, 2009 Share Posted June 5, 2009 Hmm, I just looked at the code for this bankswitching scheme, and it seems to be properly randomizing all the RAM locations. So I would need to further examine how the actual ROM is 'randomizing' the functionality. It might help if you could provide a state file for just after you pick up such an item, as I don't have time to play the game until it occurs. Furthermore, a commented disassembly of the ROM would be nice, but I suppose no such thing exists. Also, can we confirm that a real console does randomize this? Have you personally played the game on a real console several times, and noticed that the behaviour is different on different occasions?? When the SC returns from the BIOS, the accumulator contains a random value (a fast running loading counter). I suppose Dragonstomper uses this value to initialize it's random number generator. In the Stella version of the SC BIOS the accumulator contains the bankswitching value EORed with the high and low byte of the startup address for the new load instead. This value is always the same for any given load. You could have the loading routine patch a random value into an address of the SC BIOS ROM and do an LDA from this address before returning from the BIOS in order to fix this problem. Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 8, 2009 Author Share Posted June 8, 2009 When the SC returns from the BIOS, the accumulator contains a random value (a fast running loading counter). I suppose Dragonstomper uses this value to initialize it's random number generator. In the Stella version of the SC BIOS the accumulator contains the bankswitching value EORed with the high and low byte of the startup address for the new load instead. This value is always the same for any given load. You could have the loading routine patch a random value into an address of the SC BIOS ROM and do an LDA from this address before returning from the BIOS in order to fix this problem. I'm just wondering, are you getting this info from an analysis of the ROM itself, or from the Stella source code (I believe you contributed portions of the Supercharger code)? if it's the latter, where in the code do you figure this out? I see an array representing the Supercharger BIOS, but I don't know where those values come from or how they're used. What you're saying basically makes sense. but I don't see where the code is doing what you say it's doing. Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted June 8, 2009 Share Posted June 8, 2009 I'm just wondering, are you getting this info from an analysis of the ROM itself, or from the Stella source code (I believe you contributed portions of the Supercharger code)? if it's the latter, where in the code do you figure this out? I see an array representing the Supercharger BIOS, but I don't know where those values come from or how they're used. What you're saying basically makes sense. but I don't see where the code is doing what you say it's doing. The ASM source code for the Stella version of the SC BIOS and a tool to convert the binary to the array you mentioned is in the /src/emucore/misc/ folder. scrom.asm is written for the DASM assembler. Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 8, 2009 Author Share Posted June 8, 2009 I'm just wondering, are you getting this info from an analysis of the ROM itself, or from the Stella source code (I believe you contributed portions of the Supercharger code)? if it's the latter, where in the code do you figure this out? I see an array representing the Supercharger BIOS, but I don't know where those values come from or how they're used. What you're saying basically makes sense. but I don't see where the code is doing what you say it's doing. The ASM source code for the Stella version of the SC BIOS and a tool to convert the binary to the array you mentioned is in the /src/emucore/misc/ folder. scrom.asm is written for the DASM assembler. Right, there it is The codebase is so large, and many parts of it so old (some go back 10 years or so), that I'm still finding stuff I didn't know existed. I'll look into fixing this issue for 2.8.1, as I'm about to do a 2.8 release soon. Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 9, 2009 Author Share Posted June 9, 2009 When the SC returns from the BIOS, the accumulator contains a random value (a fast running loading counter). I suppose Dragonstomper uses this value to initialize it's random number generator. In the Stella version of the SC BIOS the accumulator contains the bankswitching value EORed with the high and low byte of the startup address for the new load instead. This value is always the same for any given load. You could have the loading routine patch a random value into an address of the SC BIOS ROM and do an LDA from this address before returning from the BIOS in order to fix this problem. OK, I just fixed this issue as you described. The SC ROM is patched with a random value, so assuming this is the issue in Dragonstomper, that should fix it. One question; what values should X and Y have? Currently, they're set to $FF and $00, but should they be random as well? Also, now that I understand how the SC BIOS works, I can add an option to completely disable the SC loading bars. Previously, I was only able to speed up the loading, but now I can completely skip the bars altogether. Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted June 9, 2009 Share Posted June 9, 2009 OK, I just fixed this issue as you described. The SC ROM is patched with a random value, so assuming this is the issue in Dragonstomper, that should fix it. One question; what values should X and Y have? Currently, they're set to $FF and $00, but should they be random as well? Also, now that I understand how the SC BIOS works, I can add an option to completely disable the SC loading bars. Previously, I was only able to speed up the loading, but now I can completely skip the bars altogether. The values for X and Y are correct. But while you are at it you might also want to check if the object positions and colours are set correctly when leaving the SC-BIOS. Some loads, like the evaluation screen in Escape from the Mindmaster rely on the this. Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 9, 2009 Author Share Posted June 9, 2009 But while you are at it you might also want to check if the object positions and colours are set correctly when leaving the SC-BIOS. Some loads, like the evaluation screen in Escape from the Mindmaster rely on the this. I'll have to push this to the next point release, as I'm about to release version 2.8. How would I know if the values are set correctly? What would I be comparing them to?? Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 9, 2009 Author Share Posted June 9, 2009 Stella 2.8 has been released, which addresses a number of issues mentioned in this thread. Please move all discussion to the 2.8 release thread. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.