Bring console to known state after reset?

[potatohead]

Ok, I've been working on my reset bug this morning. Just setting all the vars is not enough to insure the game runs like it does after a power on. The various things I've tried just don't seem to handle all the conditions that can come up on reset. Got some great looking bug screens though!

 

Any good init ideas. If I was on the 8bitter, I would just jump to the reset vector and let things take care of themselves. Is a similar thing possible on the 2600, or is there a better / standard way to do this? (maybe just a nice chunk of inline asm?)

 

The problem i'm having is mid game resets leave things in a goofy state about half the time.

 

I suppose this becomes a feature request too. We should have a console reset command that basically starts the program over again as if it were the first time.

 

The attached code shows the problem pretty well.

 

ooze_reset_prob.bas

[+batari]

Ok, I've been working on my reset bug this morning.  Just setting all the vars is not enough to insure the game runs like it does after a power on.  The various things I've tried just don't seem to handle all the conditions that can come up on reset.  Got some great looking bug screens though!

 

Any good init ideas.  If I was on the 8bitter, I would just jump to the reset vector and let things take care of themselves.  Is a similar thing possible on the 2600, or is there a better / standard way to do this?  (maybe just a nice chunk of inline asm?)

 

The problem i'm having is mid game resets leave things in a goofy state about half the time.

 

I suppose this becomes a feature request too.  We should have a console reset command that basically starts the program over again as if it were the first time.

 

The attached code shows the problem pretty well.

 

ooze_reset_prob.bas

901069[/snapback]

It seems that jumping to the reset vector should work just fine.

 

Doing "goto start" in your program should basically do just that.

[potatohead]

Ok, I've been working on my reset bug this morning.  Just setting all the vars is not enough to insure the game runs like it does after a power on.  The various things I've tried just don't seem to handle all the conditions that can come up on reset.  Got some great looking bug screens though!

 

Any good init ideas.  If I was on the 8bitter, I would just jump to the reset vector and let things take care of themselves.  Is a similar thing possible on the 2600, or is there a better / standard way to do this?  (maybe just a nice chunk of inline asm?)

 

The problem i'm having is mid game resets leave things in a goofy state about half the time.

 

I suppose this becomes a feature request too.  We should have a console reset command that basically starts the program over again as if it were the first time.

 

The attached code shows the problem pretty well.

 

ooze_reset_prob.bas

901069[/snapback]

It seems that jumping to the reset vector should work just fine.

 

Doing "goto start" in your program should basically do just that.

901071[/snapback]

 

 

I'm assuming you put a label at the beginning and goto that right? That does not seem to work the same as a cold start does.

 

(Digging for reset vector address in archives.)

[vdub_bobby]

Ok, I've been working on my reset bug this morning.  Just setting all the vars is not enough to insure the game runs like it does after a power on.  The various things I've tried just don't seem to handle all the conditions that can come up on reset.  Got some great looking bug screens though!

 

Any good init ideas.  If I was on the 8bitter, I would just jump to the reset vector and let things take care of themselves.  Is a similar thing possible on the 2600, or is there a better / standard way to do this?  (maybe just a nice chunk of inline asm?)

 

The problem i'm having is mid game resets leave things in a goofy state about half the time.

 

I suppose this becomes a feature request too.  We should have a console reset command that basically starts the program over again as if it were the first time.

 

The attached code shows the problem pretty well.

 

ooze_reset_prob.bas

901069[/snapback]

Well, if you really want it to act like it does upon powerup, you can just do this:

   asm
  brk
end

Assuming the break vector is pointing the same place as the reset vector. Which I think it is.

 

It's kind of a kludgy thing to do, though. I usually use the 'brk' command to find bugs. (E.g.,

   lda Variable
  bne NoBrk
 ;---Variable should never be zero!  If it is, something has gone horribly wrong!
  brk
NoBrk

)

[+batari]

Ok, I've been working on my reset bug this morning.  Just setting all the vars is not enough to insure the game runs like it does after a power on.  The various things I've tried just don't seem to handle all the conditions that can come up on reset.  Got some great looking bug screens though!

 

Any good init ideas.  If I was on the 8bitter, I would just jump to the reset vector and let things take care of themselves.  Is a similar thing possible on the 2600, or is there a better / standard way to do this?  (maybe just a nice chunk of inline asm?)

 

The problem i'm having is mid game resets leave things in a goofy state about half the time.

 

I suppose this becomes a feature request too.  We should have a console reset command that basically starts the program over again as if it were the first time.

 

The attached code shows the problem pretty well.

 

ooze_reset_prob.bas

901069[/snapback]

It seems that jumping to the reset vector should work just fine.

 

Doing "goto start" in your program should basically do just that.

901071[/snapback]

 

 

I'm assuming you put a label at the beginning and goto that right? That does not seem to work the same as a cold start does.

 

(Digging for reset vector address in archives.)

901075[/snapback]

No, "start" is already defined as a label for a clean start, which is where the reset vector jumps to.

[+batari]

Well, if you really want it to act like it does upon powerup, you can just do this:

   asm
  brk
end

Assuming the break vector is pointing the same place as the reset vector.  Which I think it is.

901076[/snapback]

Yes, it is, and should work the same as "goto start" will. This will save a couple of bytes as well.

[potatohead]

Well, if you really want it to act like it does upon powerup, you can just do this:

   asm
  brk
end

Assuming the break vector is pointing the same place as the reset vector.  Which I think it is.

901076[/snapback]

Yes, it is, and should work the same as "goto start" will. This will save a couple of bytes as well.

901079[/snapback]

 

The brk opcode did the trick. --Thanks.