We are going to write a function for setting up the Video Interface for every valid possible combination. This will include "parsing" a constant value and conditionally branching to set the right configuration register values. Please see other references to understand the basics of each instruction, this tutorial is going to be about "abusing' these instruction.
In the Lessons (5+) we used a Macro to setup the Video and it took 4 parameters (width,height, status, origin) why do we want to replace this? While the code works and is easy to understand as a beginner, it's a little too flexible and doesn't validate it's parameters.
Most TV's are good at saying "I don't understand the signal so I'm going to go 'black' ". Unfortunately there is going to be one TV that is damaged by sending the wrong settings, so we really should be very careful. One of the easiest ways to validate parameters is to use the right variable type. For example there are only 2 resolutions for each TV format if we accept a height and width it's easy for the developer to choose a bad resolution. Instead we can have the resolution as a bit flag in the parameter and the risk of a bad resolution is gone. As soon as we start talking about bit flags, it's easy to see we don't need many actual bits to setup the video interface.
The bits we need are:
We will setup our parameter as follows [31..0] [msb .. lsb]
Planning the structure of this parameter constant will save us some parsing effort later so this is all worth it. Reserved bits will help in the readability of these constants.
The next thing to consider is how are we going to call it. If we write out the code to do this it becomes clearer what the code inside has to do.
li a0, ntsc_32bit_Inter_High jal video_init nopUsing a well named constant can make things clearer, compared to commented code. Also note it's easy to think that the 'li' instruction could be inserted into the delay slot, unfortunately the 'li' instruction is actually a psuedo instruction which becomes 2 instructions after assembly. An 'optimized' version could be created to split the parameter into an upper and lower 16 bits, and split the instructions for example:
lui a0, r0, ntsc_32bitjal video_initandi a0, a0, Inter_HighWhile it's easy to say this is one instruction faster, I would argue against it for the following reasons: