A better boot sequence

[+DZ-Jay]

Writing games in Assembly Language I've come to base some common procedures in standard patterns devised by others in the community. One of these is the "bootstrap" sequence, where one sets up the Universal Data Block (a.k.a. "ROM header") and hijacks the EXEC initialization routine in order to start a custom game program.

 

In my own game and frameworks, I've used a pattern based on the macro library "CART.MAC" which, among other things, does a good job at setting up a reasonable bootstrap sequence and calling your game's main routine.

 

The basic pattern works like this:

• Set up a UDB with a pointer to the "Title" string data
• Set bit #7 of the UDB "Key Clicks" data structure, which causes the EXEC to call a special routine to fix the copyright notice. This special routine is expected to follow directly the "Title" string data, and is called right after drawing the initial "Mattel Electronics Presents..." title screen.
• Instead of fixing copyright in the special routine, hijack program flow by:
  • Resetting the stack pointer
  • Clearing all memory
  • Reset the interrupt vector to point to your own custom ISR
  • Perform any other custom system initialisation (e.g., seed the random number generator, draw a new title screen, etc.)
  • Branch to your "Main" program routine

Note that the idea is to wait for an opportune moment where the EXEC gives you a bit of control (i.e., the custom "copyright fix" routine), and then divorce your program completely from the EXEC by re-initialising the system state and never look back. Bye, bye, EXEC!

 

This is such a common "boilerplate" routine that most people nowadays either use CART.MAC, or copy+paste a very similar routine from tutorials, sample games, or other documents available to the community. Even IntyBASIC does this under the hood, within its "prologue" library.

 

This is all well and good, except for one little niggle that annoys me to no end: sometimes, when the conditions are right, you can see the original title screen briefly flicker as the system starts. Hit return multiple times and you can see it more clearly -- sometimes resulting in some sort of glitch that may even end up landing on the original title screen and getting stuck there.

 

I noticed this in Christmas Carol and I've noticed it in other programs, and it bugs me. Sure, it is a very minor thing, and you may not even notice it most of the time. But I do. And it annoys me.

 

However, I never really took the time to explore deeply what causes it and how to avoid it. I had an idea, but I just never really pay too much attention to it. (I guess it only bothered me while playing, and completely put it out of my mind when I go back to programming.)

 

However, I took all of five minutes this morning to confirm my theory and then I took another 30 seconds to devise a quick solution. I will share these with you, and hopefully it'll prove useful. I also would hope that Oscar considers applying it to IntyBASIC as well.

 

So what causes it? The origin of the problem is in what happens when the EXEC calls your "copyright fix" routine and you program decides to hijack control. The EXEC already drew the title screen and only expects your program to do a quick fix to the copyright line, and so it leaves the display enabled right before calling your routine.

 

That's it. At that point, it doesn't matter if you disable interrupts, the title screen has been drawn and it will be displayed. Worse, if you are trying to load GRAM or initialise MOBs at that point for a custom title screen, there is a chance that you may run out of VBLANK period which results in dropped STIC or GRAM writes.

 

So, how do we fix it? Easy, we take full and absolute control of the program flow, for real this time: when the EXEC calls our "copyright fix" routine assume you're still under its influence (the bastard already enabled the display without our consent!), so:

• Clear the screen as quickly as possible (get rid of the original title screen!) and set your screen mode and border colours as you wish.
• Set the interrupt vector to your "real" boot sequence (what you used to do during the "copyright fix" routine).
• Spin the CPU in an endless loop and wait for your new ISR to trigger.

At that point, you are now THE UNDISPUTED MASTER of the system: you can keep the display disabled and go through your initialisation routine, however long it may be, and have unfettered access to the STIC and GRAM until you decide to enable the display again.

 

Easy as pie, ain't it?

 

Now, you can hit the RESET button as many times as you'd like and you most likely will never see that pesky "Mattel Electronics Presents..." screen flicker, ever again. The most that will happen is that the screen will remain blank for a few frames, depending on the length of your initialisation routine.

 

That's not too bad. It's certainly better than flickering artefacts on your otherwise pristine and highly polished game.

 

-dZ.

Edited February 21, 2016 by DZ-Jay

[GroovyBee]

You could always put code in at $4800 and never ever go back to the EXEC.

[intvnut]

Yes, you definitely want to get stuff off the screen as quickly as possible. One note of caution: The STIC registers are still writeable when you arrive at the 'fixup' routine on NTSC Intellivision 1 and 2 units. They are not, however, on Sears units and PAL units, as I recall. So even if you set the display border and background color immediately in your boot code, you'll need to remember to do it again in your ISR.

 

You can intercept boot earlier, by putting your start code at $4800 or $7000. (Although, if you put it at $7000, you'll run into a conflict with the ECS.) If you do that, you'll need to fully initialize the STIC yourself. While it comes up fairly clean on jzIntv, there's no such guarantee on the hardware. The border, horiz/vert delay, MOB regs, etc. all could have strange values in there. I've even had the STIC come up in a mode where it's only displaying 18 cards/row instead of 20 (with a quite garbled and unusable display), but it rights itself once you clear all the STIC registers.

Edited February 21, 2016 by intvnut

[+DZ-Jay]

You can intercept boot earlier, by putting your start code at $4800 or $7000. (Although, if you put it at $7000, you'll run into a conflict with the ECS.) If you do that, you'll need to fully initialize the STIC yourself. While it comes up fairly clean on jzIntv, there's no such guarantee on the hardware. The border, horiz/vert delay, MOB regs, etc. all could have strange values in there. I've even had the STIC come up in a mode where it's only displaying 18 cards/row instead of 20 (with a quite garbled and unusable display), but it rights itself once you clear all the STIC registers.

 

I think this has been missed throughout all the copy+pasting of initialisation code. I believe that the original intention of patching after the title was to let the EXEC initialize the system; perhaps even to let it draw the default title screen (and modify it slightly afterwards).

 

However, if P-Machinery and IntyBASIC are doing their own initialisation anyway (which they do) and even drawing their own title screens, then what's the advantage? Perhaps it's just better to patch in at $4800 and avoid the hassle.

 

dZ.

Edited February 21, 2016 by DZ-Jay

[+DZ-Jay]

Thinking more about my last comment... is there any reason at all to patch after the title instead of at $4800 and be done with it?

 

-dZ.

[+nanochess]

What I can do is to move earlier the clear screen routine in my intybasic_prologue.asm currently it initializes all variables before clearing screen