Our next topic is going to be interrupt-driven IO. This is probably the most complicated topic we cover all semester, because its action is so counter-intuitive to most people. We're going to cover it in two steps: first, we'll describe a very special case (the hardware RESET), and then we'll go on to the general case of interrupts.
When you start up the HC11, or you press the RESET button, how does
the hardware know where your program starts? Of course, we told it in
the end statement; but as we know the assembly code is
all long gone. So... what actually gets loaded into the EEPROM to
tell the HC11 where the program starts when we do a REST?
The answer is on page 167 (section 5.3.4) of the Reference Manual. It says,
As reset is released, the CPU program counter is loaded with the reset vector that points to the first instruction in the user's program. Depending on the cause of reset and the mode of operation the reset vector may be fetched from any of six possible locations. In older Motorola MCUs, there was only one reset vector at $FFFE,FFFF.
OK, let's figure out what this means. As we continue to read the section, we find that in the normal case (which the table on page 168 calls "POR or -RESET pin"), the "normal mode vector" is at $FFFE,FFFF.
What this means is that, as part of the normal startup sequence,
two bytes are taken starting at address $FFFE and loaded into the PC.
And the machine starts executing from there. It turns out the
contents of $fffe,ffff are controlled by the last line of the S19
file; the assembler finds out what to put there from the
end line of the assembly code
When we first started using the HC11 in this course, the version of
the assembler we used didn't support the end statement.
As a result, we still have quite a few (obsolete) examples running
around with .asm files that end with
org RESET * now generate code at $fffe fdb start
This says more explicitly how the RESET vector is set up.