potatohead Posted July 29, 2005 Share Posted July 29, 2005 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 Quote Link to comment Share on other sites More sharing options...
+batari Posted July 29, 2005 Share Posted July 29, 2005 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. Quote Link to comment Share on other sites More sharing options...
potatohead Posted July 29, 2005 Author Share Posted July 29, 2005 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.) Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted July 29, 2005 Share Posted July 29, 2005 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 ) Quote Link to comment Share on other sites More sharing options...
+batari Posted July 29, 2005 Share Posted July 29, 2005 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 29, 2005 Share Posted July 29, 2005 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. Quote Link to comment Share on other sites More sharing options...
potatohead Posted July 29, 2005 Author Share Posted July 29, 2005 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.