Rutgers Physics Student Response System

The Lower Level Software

There are two kinds of lower level software involved in the operation of the Student Response System. At the lowest level is the program that runs on the system controller (called the boss). This program is burned into an EPROM and run by a clock without a CPU at all. The second part is the interrupt driver that runs on the PC. It is executed 18.2 times each second, and is responsible for bringing information between the arrays in PC memory and the RAM which is on the boss, and performing some preliminary digestion of this data before turning over to the higher level software on the PC.

Prom program for the Boss

The program that runs on the boss is extremely simple - it cycles through the same 793 steps continuously except when stopped by the PC. Each of these cycles handles one of the 48 columns in each row of seats, so the boss runs thorugh 48 of these cycles and then expects the PC to interrupt and transfer data. When the PC releases control, the cycling starts again.

The sequence of steps within each cycle begins by reading from the RAM, for each of the six substations, the state of the one LED on each of the eight subsubstations the substation controls, and latching this byte of information in a one byte memory on the substation. This takes 24 microsteps.

The next step, repeated 24 times, is to read the status of the four row lines from each subsubstation of each of the substations. Substation 0 and substation 3 are done simultaneously into the lower and upper nibble (4 bits) of the byte-wide RAM location, and similarly for the other substations. Reading each byte into RAM takes 4 microsteps, so at the end of this we are up to step 128.

The nex 640 microsteps do nothing at all - we are just giving the light a chance to shine. Then all the lights are turned off (24 more microsteps) and then finally the last step resets the counter, starting again at the beginning.

The output of this program is in the form of 6 bits of information at each step. Three of these control the write enable, chip enable and output enable lines of the RAM. Two more are the latch pulse for the substation register, and the multiplexer enable line. Finally the last bit, off except at the last microstep, is the reset pulse to the clock. If you want, you can look at the complete listing.

The low level PC software

The instructor interacts with the SRS system by means of an IBM-style PC. The program which runs on that PC needs to handle both the high-level activities of interaction with the instructor and recording of results, and the low-level activity of retrieving the student keystrokes and reponding by displaying the appropriate lights. The latter task is locked in time to the cycle of the SRS system itself (the boss), while the higher level activity should be flexible in function and therefore not deterministic in time.

The requirements of the lower-level interface are met by utilizing the clock interrupt which is a standard part of the DOS system. Every 55 milliseconds, the program is interrupted, and it is possible to insert an "interrupt function" before control returns to the higher level software. During this time, the data is transferred between the PC and the boss by the program readram. At its end, this program restarts the SRS boss for a new cycle. While this is happening, the data just read for each seat is digested into one nibble (four bits) of information. This allows for reporting any single keystroke, two combinations of keystrokes (which are not currently used, but may be if floating point answers are required in the future), and a report of no keystroke or invalid combination. This is then debounced, currently in a very simple fashion, with the results enterred into an array.

Currently the response to these keystrokes is determined by the higher level software, which writes the required light configuration into an array that readram transfers to the boss. It is planned to arrange this somewhat differently, to allow a response function setting the lights to be called as part of the interrupt. This will require isolating enough technical details so that a user can write a response function without learning excruciating details of the hardware. This has not yet been implemented.

Last revision: December 26, 1995
Please send comments to Joel Shapiro