184 replies to this topic

[Philsan]

After 35 seconds, the bug appears like Charge_test.bin

[ScumSoft]

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.

[RevEng]

ScumSoft, on Thu Jul 21, 2011 3:59 PM, said:

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.

[ScumSoft]

batari, on Thu Jul 21, 2011 2:14 PM, said:

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.)

RevEng, on Thu Jul 21, 2011 4:14 PM, said:

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 by ScumSoft, Thu Jul 21, 2011 4:36 PM.

[batari]

Philsan, on Thu Jul 21, 2011 3:59 PM, said:

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.

[RevEng]

ScumSoft, on Thu Jul 21, 2011 4:36 PM, said:

In DPCstartup.asm change...

That fixes the initialization, but the stack command itself needs to be fixed in statements.c too.

[ScumSoft]

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 by ScumSoft, Thu Jul 21, 2011 5:56 PM.

[batari]

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 by batari, Thu Jul 21, 2011 5:17 PM.
clarification

[Legend]

Sweet! I was hoping this one would pick back up. Very fun.

[ScumSoft]

batari, on Thu Jul 21, 2011 5:12 PM, said:

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.

[jrok]

batari, on Thu Jul 21, 2011 5:12 PM, said:

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!

[stephena]

batari, on Thu Jul 21, 2011 5:12 PM, said:

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?

[batari]

stephena, on Thu Jul 21, 2011 6:44 PM, said:

batari, on Thu Jul 21, 2011 5:12 PM, said:

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 by batari, Thu Jul 21, 2011 7:41 PM.

[stephena]

batari, on Thu Jul 21, 2011 7:41 PM, said:

stephena, on Thu Jul 21, 2011 6:44 PM, said:

batari, on Thu Jul 21, 2011 5:12 PM, said:

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)?

[batari]

stephena, on Fri Jul 22, 2011 3:55 AM, said:

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?

[stephena]

batari, on Fri Jul 22, 2011 12:31 PM, said:

stephena, on Fri Jul 22, 2011 3:55 AM, said:

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?

[jrok]

*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   32K   35 downloads

Edited by jrok, Sat Jul 23, 2011 6:13 PM.

[Philsan]

stephena, on Fri Jul 22, 2011 2:58 PM, said:

batari, on Fri Jul 22, 2011 12:31 PM, said:

stephena, on Fri Jul 22, 2011 3:55 AM, said:

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:

[Philsan]

jrok, on Sat Jul 23, 2011 6:08 PM, said:

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 by Philsan, Sun Jul 24, 2011 2:36 AM.

[RevEng]

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!

[Philsan]

Very strange...

Dubugger mode starts and I get this message: Thumb ARM emulation fatal error: read16 (0000E2D4), abort - out of range

[RevEng]

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.

[jrok]

RevEng, on Sun Jul 24, 2011 10:46 AM, said:

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   32K   33 downloads

[RevEng]

jrok, on Sun Jul 24, 2011 11:02 AM, said:

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!

[jrok]

RevEng, on Sun Jul 24, 2011 12:01 PM, said:

jrok, on Sun Jul 24, 2011 11:02 AM, said:

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.