+Philsan Posted July 21, 2011 Share Posted July 21, 2011 After 35 seconds, the bug appears like Charge_test.bin Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 21, 2011 Share Posted July 21, 2011 Yep the latest build also falls apart, you now get red playfield streaks down the screen then it eventually all turns blue. Fixing the stack pointer also did not help my EggVenture issues either. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 21, 2011 Share Posted July 21, 2011 Yep the latest build also falls apart, you now get red playfield streaks down the screen then it eventually all turns blue. Fixing the stack pointer also did not help my EggVenture issues either. Are you using a bb with a fix for the stack statement bug? I don't think there was a public release for it, though the fix is easy enough from batari's description. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 21, 2011 Share Posted July 21, 2011 (edited) The problem (I think) has a few causes. The first is that I still think the stack is imbalanced (not sure yet if it's bB or the game - jrok hasn't commented on his stack use) and the stack pointer (DF7) was not properly initialized in DPC_startup.asm (DF6 is set instead of DF7 - it's an easy fix.) Are you using a bb with a fix for the stack statement bug? I don't think there was a public release for it, though the fix is easy enough from batari's description. In DPCstartup.asm change: lda #<USERSTACK STA DF6LOW lda #(>USERSTACK) & $0F STA DF6HI To: lda #<USERSTACK STA DF7LOW lda #(>USERSTACK) & $0F STA DF7HI Edited July 21, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+batari Posted July 21, 2011 Share Posted July 21, 2011 After 35 seconds, the bug appears like Charge_test.bin The increased timing confirms that it's a stack issue - before it was set to zero and hit the playfield after 1505 frames. "stack 256" sets the pointer to $D7E which will hit the playfield after 2147 frames (35.8 seconds.) Now, I just need to figure out why it's adding one to the pointer every frame when the stack is otherwise unused. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 21, 2011 Share Posted July 21, 2011 In DPCstartup.asm change... That fixes the initialization, but the stack command itself needs to be fixed in statements.c too. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 21, 2011 Share Posted July 21, 2011 (edited) I don't have a statements.c file to look through, so this'll be done on your ends I suppose. [edit]n/m I found it Edited July 21, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+batari Posted July 21, 2011 Share Posted July 21, 2011 (edited) OK, I think I know the answer. If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise. Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!) So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed. Edited July 21, 2011 by batari clarification 1 Quote Link to comment Share on other sites More sharing options...
Legend Posted July 21, 2011 Share Posted July 21, 2011 Sweet! I was hoping this one would pick back up. Very fun. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 22, 2011 Share Posted July 22, 2011 OK, I think I know the answer. If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise. Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!) So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed. GASP! It's fixed, now all my EggVenture bugs on the Harmony cart are gone! Tis a fine day for feeling good. Thanks for looking into it batari! REALLY appreciate the support you give. I added temp1 = temp1 right after each bank declaration and it fixed it. Quote Link to comment Share on other sites More sharing options...
jrok Posted July 22, 2011 Author Share Posted July 22, 2011 OK, I think I know the answer. If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise. Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!) So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed. Thanks so much, Fred! Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 22, 2011 Share Posted July 22, 2011 OK, I think I know the answer. If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise. Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!) So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed. So what would have to be fixed in Stella to eliminate this bug? Quote Link to comment Share on other sites More sharing options...
+batari Posted July 22, 2011 Share Posted July 22, 2011 (edited) OK, I think I know the answer. If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise. Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!) So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed. So what would have to be fixed in Stella to eliminate this bug? All that needs to be done is any DPC+ write registers (0x28-0x80) need to be accessible with a "peek" method as well as the "poke". The value written for "peek" should be the last value on the data bus, which should typically be (address>>8 ). Looks like this is the only problem here (Stella does not have uninitialized fetchers as I previously assumed.) Edited July 22, 2011 by batari Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 22, 2011 Share Posted July 22, 2011 OK, I think I know the answer. If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise. Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!) So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed. So what would have to be fixed in Stella to eliminate this bug? All that needs to be done is any DPC+ write registers (0x28-0x80) need to be accessible with a "peek" method as well as the "poke". The value written for "peek" should be the last value on the data bus, which should typically be (address>>8 ). Looks like this is the only problem here (Stella does not have uninitialized fetchers as I previously assumed.) Can someone provide a minimal test ROM that clearly illustrates the difference in behaviour between Stella and Harmony, and a description of what is happening (in Stella) and what should happen (in Harmony)? Quote Link to comment Share on other sites More sharing options...
+batari Posted July 22, 2011 Share Posted July 22, 2011 Can someone provide a minimal test ROM that clearly illustrates the difference in behaviour between Stella and Harmony, and a description of what is happening (in Stella) and what should happen (in Harmony)? If you download the binary in post #50, if you let it run for 35 seconds in Harmony, you should see bars slowly fill the screen. Harmony is showing the "correct" behavior of this bug, and adding the code should make Stella match this behavior. Currently nothing at all happens in Stella. Will this work or do you need a better test ROM? Quote Link to comment Share on other sites More sharing options...
+stephena Posted July 22, 2011 Share Posted July 22, 2011 Can someone provide a minimal test ROM that clearly illustrates the difference in behaviour between Stella and Harmony, and a description of what is happening (in Stella) and what should happen (in Harmony)? If you download the binary in post #50, if you let it run for 35 seconds in Harmony, you should see bars slowly fill the screen. Harmony is showing the "correct" behavior of this bug, and adding the code should make Stella match this behavior. Currently nothing at all happens in Stella. Will this work or do you need a better test ROM? I'll try this first, to see if I can duplicate the behaviour. If not, I may need an explicit test ROM. EDIT: I'm unable to test on my Harmony cart right now, but with some code I just added to Stella, the ROM goes into the debugger starting that the ARM emulation has crashed, and generates a screen as attached. Is this what's supposed to happen? Quote Link to comment Share on other sites More sharing options...
jrok Posted July 24, 2011 Author Share Posted July 24, 2011 (edited) *Update* I've attached the latest build (and added it to the first post as well). Hopefully this version corrects the stack overflow bug for Harmony, as well as the bounce due to timing problems. For the stack overflow issue, I revised DPCstartup.asm to intialize the pointer, and added "temp1=temp1" after each bank declaration. I don't own a Harmony cart, so it would be great if someone could test this version to confirm. I've restructured my code to resolve my extra cycle problem. The program is drawing a stable 262 scanlines now, but if someone could confirm this on Harmony as well, that would be much appreciated. I incorporated a few minor gameplay changes. In addition to speed and aggression, enemies also cause more damage to your armor and castles with each hit as the game progresses. Next Steps: I'm going to try to alter the Soldier enemy-type to spawn in mobs of up to three copies. I guess the main obstacle is decrementing the number when the soldiers' x-position meets the screen's left edge. Decrementing using the sprite's virtual NUSIZ register at the right edge is fairly straightforward, but the left edge presents some challenges unless I use an additional byte of RAM. I'm thinking of incorporating a bit of Defender-style gameplay, where the dragons can occasionally kidnap someone from one of the castles, allowing you to rescue them by zapping the dragon and then catching the falling damsel for bonus point. I always loved the Galaga trick of allowing your ship to be captured, and then rescuing it for double-the-firepower, so I hope to incorporate something like that as well. ChargeDPC_3.bin Edited July 24, 2011 by jrok Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 24, 2011 Share Posted July 24, 2011 Can someone provide a minimal test ROM that clearly illustrates the difference in behaviour between Stella and Harmony, and a description of what is happening (in Stella) and what should happen (in Harmony)? If you download the binary in post #50, if you let it run for 35 seconds in Harmony, you should see bars slowly fill the screen. Harmony is showing the "correct" behavior of this bug, and adding the code should make Stella match this behavior. Currently nothing at all happens in Stella. Will this work or do you need a better test ROM? I'll try this first, to see if I can duplicate the behaviour. If not, I may need an explicit test ROM. EDIT: I'm unable to test on my Harmony cart right now, but with some code I just added to Stella, the ROM goes into the debugger starting that the ARM emulation has crashed, and generates a screen as attached. Is this what's supposed to happen? No, something like this should happen: http://www.youtube.com/watch?v=L8e5cSwWL08&feature=player_embedded Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 24, 2011 Share Posted July 24, 2011 (edited) ChargeDPC_3.bin Like Charge! Harmony Test 3, something appears for a millisecond, then a black screen. In fact, it doesn't work on emulator too... Edited July 24, 2011 by Philsan Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 24, 2011 Share Posted July 24, 2011 Works for me in Stella, Phil. Maybe try to download it again. The scanline count is looking really stable in emulation - hopefully I'll get a chance to try it out on Harmony later today. I'm looking forward to the upcoming features, jrok! Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 24, 2011 Share Posted July 24, 2011 Very strange... Dubugger mode starts and I get this message: Thumb ARM emulation fatal error: read16 (0000E2D4), abort - out of range Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 24, 2011 Share Posted July 24, 2011 Ok, I upgraded to the 3.4.1 stella and I now get the same error. Previously I was using the pre 3.4 beta, which didn't have the ARM exception feature. Strangely the previous Charge versions no longer exhibit the "curtain drop" bug with this version. Quote Link to comment Share on other sites More sharing options...
jrok Posted July 24, 2011 Author Share Posted July 24, 2011 Ok, I upgraded to the 3.4.1 stella and I now get the same error. Previously I was using the pre 3.4 beta, which didn't have the ARM exception feature. Strangely the previous Charge versions no longer exhibit the "curtain drop" bug with this version. The "curtain drop" was only happening with Harmony (Stella wasn't catching the stack error; I think stephana is working on emulating this now). I'm thinking now that something might have been wrong in my code in the previous version, actually. Either that or the file got corrupted again while I was copying it across my drives. If it's the former, I must have absentmindedly fixed it in my latest version this morning. I just tested this one on 3.4.1 and it's working (see attached.) New in this version: The color of the sky changes from wave to wave, progress into night, then to dawn again. Added "Wizard" boss enemy to 10th level. ChargeDPC_4.bin Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 24, 2011 Share Posted July 24, 2011 The "curtain drop" was only happening with Harmony (Stella wasn't catching the stack error; I think stephana is working on emulating this now). Oh yeah, thanks for setting me straight. I was up all night working and my little grey cells seem to have misfired. The new version is looking good! Quote Link to comment Share on other sites More sharing options...
jrok Posted July 24, 2011 Author Share Posted July 24, 2011 The "curtain drop" was only happening with Harmony (Stella wasn't catching the stack error; I think stephana is working on emulating this now). Oh yeah, thanks for setting me straight. I was up all night working and my little grey cells seem to have misfired. The new version is looking good! Thanks, man! Let me know how far you get. 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.