Reset the Game?

[First Spear]

What is the correct POKE (or set of POKEs) to make a game jump back to the main program's initialization/entry point? The equivalent of pushing the reset button on the console hardware?

 

I am using IntyBASIC of course, but if there are clues/ideas from Assembly gurus, I am open.

 

 

Thanks.

Edited November 13, 2017 by First Spear

[+intvnut]

Not really a poke, but an assembly one liner will do something similar to hitting reset.

 

.

ASM B $1000

[DZ-Jay]

Wouldn't it be better to just call your initialization routine?

 

Is there really a need to have the EXEC reinitialize the system, load it's state, and then hijack it again?

[+Tarzilla]

Wouldn't it be better to just call your initialization routine?

 

Is there really a need to have the EXEC reinitialize the system, load it's state, and then hijack it again?

I agree, design your game structure and flow properly and you should never have to "reset" your game as a feature (or use a GOTO ).

[+intvnut]

I also agree it's better to flow cleanly back to the title screen.

 

"Resetting" is useful if you're building a launcher to integrate multiple games that don't really know about each other. There isn't necessarily a clean way to hand off, so instead you just set up everything so that EXEC takes you to the other game, and GERRRRONIMOOOOOO!

[First Spear]

A little something I am playing with. I have an LTO Flash! and an Intellivision II that is modified with a quicker reset than usual. I want to see what my "game" will do when I play with reset via software.

 

OK, now back to work...

 

And thanks!

 

I also agree it's better to flow cleanly back to the title screen.

 

"Resetting" is useful if you're building a launcher to integrate multiple games that don't really know about each other. There isn't necessarily a clean way to hand off, so instead you just set up everything so that EXEC takes you to the other game, and GERRRRONIMOOOOOO!

Edited November 19, 2017 by First Spear

[DZ-Jay]

A little something I am playing with. I have an LTO Flash! and an Intellivision II that is modified with a quicker reset than usual. I want to see what my "game" will do when I play with reset via software.

 

OK, now back to work...

 

And thanks!

 

 

 

Ah, so you want to simulate pressing the RESET button in your game? There is no function for it, it's a hardware feature. You can simulate it using F+11 in the emulator.

 

-dZ.

[+intvnut]

Ah, so you want to simulate pressing the RESET button in your game? There is no function for it, it's a hardware feature. You can simulate it using F+11 in the emulator.

 

Of course, that won't work on....

 

an LTO Flash! and an Intellivision II that is modified with a quicker reset than usual.

 

 

[DZ-Jay]

 

Of course, that won't work on....

 

 

 

 

But... on an LTO Flash! they won't need to simulate it -- they can just hit the Refresh button on the console. What am I missing?

[+intvnut]

 

But... on an LTO Flash! they won't need to simulate it -- they can just hit the Refresh button on the console. What am I missing?

 

The part I quoted last time:

 

an Intellivision II that is modified with a quicker reset than usual.

 

I'm pretty sure he means "It powers off almost instantly when you push the button," which is the usual mod to make with an Intellivision II.

[DZ-Jay]

 

The part I quoted last time:

 

 

I'm pretty sure he means "It powers off almost instantly when you push the button," which is the usual mod to make with an Intellivision II.

 

OK then, I'm now absolutely sure I'm still missing something... In emulation, hitting F11 will simulate a hardware reset. It may not simulate the super-fast hardware reset of a modded Intellivision II, but how would software do that from the game program? Wouldn't he need to hack jzIntv to simulate the fast reset?

 

Either way, PEEKing and POKEing does not seem to be the way to simulate the situation that he wants.

 

-dZ.

[+intvnut]

 

OK then, I'm now absolutely sure I'm still missing something... In emulation, hitting F11 will simulate a hardware reset. It may not simulate the super-fast hardware reset of a modded Intellivision II, but how would software do that from the game program? Wouldn't he need to hack jzIntv to simulate the fast reset?

 

Either way, PEEKing and POKEing does not seem to be the way to simulate the situation that he wants.

 

*shrug* FirstSpear probably has a better idea of what exactly they're trying to test. Here's what I decoded:

• Wants to test on real hardware, not jzIntv. (Hence LTO Flash.)
• Wants to test "does game initialize properly after a RESET on real hardware."
  • They may just want to see their title screen sequence over and over.
• Can't actually press RESET button, so will instead implement a "reset myself" kludge within the game itself.

You won't be able to simulate the asynchrony of hitting the actual reset button. But, you can at least ask EXEC to restart you. It may be sufficient for testing that hardware does the same as jzIntv for certain sequences.

 

One downside of jumping to $1000 is that it won't send a reset pulse to the Intellivoice. So, you could end up junking up that. I wonder if I should add a "reset me" button to LTO Flash itself.

[+freewheel]

One downside of jumping to $1000 is that it won't send a reset pulse to the Intellivoice. So, you could end up junking up that. I wonder if I should add a "reset me" button to LTO Flash itself.

 

It kinda does. The Intellivoice finishes whatever phrase/phoneme it's on, but it does stop it from continuing. Not sure if there are other side effects here.

[DZ-Jay]

 

One downside of jumping to $1000 is that it won't send a reset pulse to the Intellivoice. So, you could end up junking up that. I wonder if I should add a "reset me" button to LTO Flash itself.

 

Could it be mitigated by calling the INIT function before jumping to $1000? I still think that resetting the game cleanly by calling a proper initializer is the best way to go, but in a pinch, calling IV_INIT should work, no? I guess, this can be encapsulated as a macro (or user-defined function) in IntyBASIC.

 

-dZ.

[+intvnut]

I should remind everyone what we discovered with Crazybus: On real hardware, calling VOICE INIT repeatedly eventually crashes the Intellivoice in a way that is only recoverable with a true hardware reset. Writing $400 to $81 is supposed to reset the Intellivoice, but it only resets the SPB640 buffer chip. The only way to get a reset to the SP0256 is for ~MSYNC to go low.

 

You can see this if you follow ~MSYNC in the schematic.

 

jzIntv doesn't accurately model this. If you write $400 to $81 in jzIntv, it does a fuller reset than the real hardware would do.

[DZ-Jay]

I should remind everyone what we discovered with Crazybus: On real hardware, calling VOICE INIT repeatedly eventually crashes the Intellivoice in a way that is only recoverable with a true hardware reset. Writing $400 to $81 is supposed to reset the Intellivoice, but it only resets the SPB640 buffer chip. The only way to get a reset to the SP0256 is for ~MSYNC to go low.

 

You can see this if you follow ~MSYNC in the schematic.

intellivoice_schematic.jpg

 

jzIntv doesn't accurately model this. If you write $400 to $81 in jzIntv, it does a fuller reset than the real hardware would do.

 

Thanks for the information, I wasn't aware of that.

 

-dZ.

[+freewheel]

I'd just like to say that I'm thrilled that Crazybus was used for.. you know... an actual purpose. I'm going to begin my lucrative career writing hardware-wrecking code anytime now.

[DZ-Jay]

I should remind everyone what we discovered with Crazybus: On real hardware, calling VOICE INIT repeatedly eventually crashes the Intellivoice in a way that is only recoverable with a true hardware reset. Writing $400 to $81 is supposed to reset the Intellivoice, but it only resets the SPB640 buffer chip. The only way to get a reset to the SP0256 is for ~MSYNC to go low.

 

 

By the way, Joe, is there a recommended "best practice" when resetting a voice-enabled game in software to avoid crashes on the hardware? Perhaps there isn't a fool-proof way, but is there at least some way to mitigate the issue?

 

-dZ.

[+intvnut]

I would recommend calling VOICE INIT exactly once at the start of your program, and never again, since it's not safe to call it when the Intellivoice is speaking. I honestly believe IV_INIT (what VOICE INIT calls) should be called automatically by IntyBASIC under the hood before reaching the first line of your program.

 

VOICE INIT at best should just let the current phoneme finish, and empty the queue. (This is not what it currently does.) I should add an IV_HUSH to my Intellivoice driver to do that.

 

I'll try to work up a proposed patch to intybasic_prologue.asm / intybasic_epilogue.asm and post them later.

 

 

EDIT: If you're going to reset your game by branching to $1000, you'll end up calling VOICE INIT again even with this strategy. If you don't take care to ensure the Intellivoice is quiet before branching to $1000, you could end up crashing the Intellivoice. As discussed previously, an actual hardware reset will be necessary at that point. I consider branching to $1000 to be a hack, FWIW.

Edited February 1, 2018 by intvnut