ECEn 425

Lab #3: Writing and Debugging ISRs


This lab must completed by each individual in the class. For this lab you will write the necessary code to allow a program running on the simulator to respond to interrupts. This requires writing code in both assembly and C for each individual interrupt that must be dealt with. (For each interrupt, the assembly code will run first, saving the context, and then calling the associated C function to respond to the interrupt.)

You are given a rather long-running program that we will consider to be the background task. While this program is running on the simulator, your ISRs must respond to any interrupts that occur, perform the specified actions, and (in cases where the specified actions do not include termination) return control to the main program without affecting its operation in any way (other than slowing it a bit).

With the exception of timer ticks, which the simulator generates automatically in its normal operation, the interrupts you must deal with are caused by pressing keys on the keyboard. Three specific interrupts may be generated in this way:

You will know when your ISRs work when you can press an arbitrarily long sequence of keys in rapid succession, generate the correct output for each in your interrupt handlers, and not have the program hang or crash. Because of the way the interrupt handlers are defined, this will very likely ensure that your ISRs also handle interrupt nesting correctly.


Read the document The 8086 Interrupt Mechanism before writing any code for this lab. A solid understanding of the interrupt mechanism can save you from a lot of unnecessary debugging in this lab and especially in future labs.


The background task is defined by the code in the file primes.c. This program computes and displays all primes in a particular range, but it takes quite a bit of time in the process. You are free to look through the source code, but you do not have to concern yourself with any of its implementation details since it does not share data with your ISRs.

You are to write ISRs for each of the following interrupts:

Interrupt Priority Generated manually by
Reset 0 Ctrl-R
Tick 1 Ctrl-T
Keyboard 2 Any other key

Here is the functionality required for each ISR or interrupt handler:

Here is an example of output with functional ISRs:
 2467 2473 2477 2503
 2521 2531 2539
 2543 2549 2551
 2557 2579 2591 2593 2609 2617 2621 2633 2647
 2659 2663 2671 2677 2683 2687 2689
 2693 2699 2707
 2711 2713 2719 2729 2731 2741 2749 2753
 2767 2777
 2789 2791 2797 2801 2803 2809 2819 2833 2837 2843
 2851 2857 2861
 2879 2887 2897 2903 2909 2917 2927
 2939 2953 2957
 2963 2969 2971
Some of the tick interrupts were generated automatically and others were generated manually. Obviously the keys '8', 'k', 'j', and 'd' were also pressed along the way. The special case handling for the 'd' key confirms that nested interrupts work. The interrupt handler (C code) for the 'd' keypress is running from the time that "DELAY KEY PRESSED" is output until "DELAY COMPLETE" is output. You will notice that it runs long enough to be interrupted twice by the timer tick. Note that every time an interrupt handler runs, control is returned to what was running before (either another interrupt handler or the background task) which simply resumes where it left off. This is how you can tell if your interrupt routines are working correctly.


In stress testing your code, the TA may revise the tick frequency and press any sequence of keys. Your code must support a tick frequency up to every 500 instructions, and it must work correctly when a key is held down or when any key sequence is typed in rapid succession. Well designed code will handle any sequence of interrupts. Your code must support nested interrupts correctly.

After verifying that your code works, the TA will examine your ISR code (assembly), your interrupt handler code (C), and your makefile. You are required to use a makefile for this lab.

You must also do the reading about the 8086 interrupt mechanism.


To pass off this lab, you must have done the reading about the interrupt mechanism. Then, you must demonstrate to a TA the correct operation of your ISRs. Since you must demonstrate working code to a TA, please consider their lab schedule well in advance.

New for Fall 2019: Submit a compressed tar file of your working code to Learning Suite. (A tar file is an archive file that can contain multiple other files.) If 425/labx is your working directory for this lab (that contains your ISR code, your interrupt handler code and your makefile), type the following in the 425 directory:

 tar -cvzf submission.tar.gz labx
and then upload the resulting compressed tar file (submission.tar.gz) to Learning Suite.

Important Notes, Hints, and Recommendations

Where do I start?

How do I organize my files?


Other Tips

Last updated 26 August 2019