Jump to content
jrok

Charge!

Recommended Posts

After 35 seconds, the bug appears like Charge_test.bin

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by ScumSoft

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

In DPCstartup.asm change...

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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
clarification
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

post-1512-0-99159100-1311394038_thumb.png

Share this post


Link to post
Share on other sites

*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 by jrok

Share this post


Link to post
Share on other sites

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?

post-1512-0-99159100-1311394038_thumb.png

No, something like this should happen:

http://www.youtube.com/watch?v=L8e5cSwWL08&feature=player_embedded

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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! :thumbsup:

Share this post


Link to post
Share on other sites

Very strange...

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...