Jump to content
potatohead

Bring console to known state after reset?

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
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

)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

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