Jump to content

Photo

Bring console to known state after reset?


6 replies to this topic

#1 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,404 posts
  • Location:Portland, Oregon

Posted Fri Jul 29, 2005 3:43 PM

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.

Attached File  ooze_reset_prob.bas   2.44KB   172 downloads

#2 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Fri Jul 29, 2005 3:46 PM

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.

Attached File  ooze_reset_prob.bas   2.44KB   172 downloads

View Post

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

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

#3 potatohead OFFLINE  

potatohead

    River Patroller

  • Topic Starter
  • 4,404 posts
  • Location:Portland, Oregon

Posted Fri Jul 29, 2005 3:51 PM

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.

Attached File  ooze_reset_prob.bas   2.44KB   172 downloads

View Post

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

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

View Post



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

#4 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Fri Jul 29, 2005 3:52 PM

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.

Attached File  ooze_reset_prob.bas   2.44KB   172 downloads

View Post

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
)

#5 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Fri Jul 29, 2005 3:53 PM

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.

Attached File  ooze_reset_prob.bas   2.44KB   172 downloads

View Post

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

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

View Post



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

View Post

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

#6 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Fri Jul 29, 2005 3:55 PM

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.

View Post

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

#7 potatohead OFFLINE  

potatohead

    River Patroller

  • Topic Starter
  • 4,404 posts
  • Location:Portland, Oregon

Posted Fri Jul 29, 2005 4:10 PM

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.

View Post

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

View Post


The brk opcode did the trick. --Thanks.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users