In computing, a resident monitor is a type of system software program that was used in many early computers from the 1950s to 1970s. It can be considered a precursor to the operating system.[1] The name is derived from a program which is always present in the computer's memory, thus being "resident".[2] Because memory was very limited on those systems, the resident monitor was often little more than a stub that would gain control at the end of a job and load a non-resident portion to perform required job cleanup and setup tasks.
On a general-use computer using punched card input, the resident monitor governed the machine before and after each job control card was executed, loaded and interpreted each control card, and acted as a job sequencer for batch processing operations.[3] The resident monitor could clear memory from the last used program (with the exception of itself), load programs, search for program data and maintain standard input-output routines in memory.[2]
Similar system software layers were typically in use in the early days of the later minicomputers and microcomputers before they gained the power to support full operating systems.[2]
Resident monitor functionality is present in many embedded systems, boot loaders, and various embedded command lines. The original functions present in all resident monitors are augmented with present-day functions dealing with boot time hardware, disks, ethernet, wireless controllers, etc. Typically, these functions are accessed using a serial terminal or a physical keyboard and display, if attached. Such a resident monitor is frequently called a debugger, boot loader, command-line interface (CLI), etc. The original meaning of serial-accessed or terminal-accessed resident monitor is not frequently used, although the functionality remained the same, and was augmented.
Typical functions of a resident monitor include examining and editing ram and/or ROM (including flash EEPROM) and sometimes special function registers, the ability to jump into code at a specified address, the ability to call code at a given address, the ability to fill an address range with a constant such as 0x00, and several others. More advanced functions include local disassembly to processor assembly language instructions, and even assembly and writing into flash memory from code typed by the operator. Also, code can be downloaded and uploaded from various sources, and some advanced monitors support a range of network protocols to do so as well as formatting and reading FAT and other filesystems, typically from flash memory on USB or CFcard buses.
For embedded processors, many "in-circuit debuggers" with software-only mode use resident monitor concepts and functions that are frequently accessed by a GUI IDE. They are not different from the traditionally serial line accessed resident monitor command lines, but users are not aware of this. At the latest, developers and advanced users will discover these low level embedded resident monitor functions when writing low level API code on a host to communicate with an embedded target for debugging and code test case running.
Several current microcontrollers have resident serial monitors or extended boot loaders available as options to be used by developers. Many are open source. Some examples are PAULMON2,[4] AVR DebugMonitor[5] and the Bamo128 Arduino boot loader and monitor.[6] In general, most current resident monitors for embedded computing can be compiled according to various memory constraints, from small and minimalistic, to large, filling up to 25% of the code space available on an AVR ATmega328 processor with 32 kilobytes of flash memory, for example.
In many cases resident monitors can be a step up from "printf debugging" and are very helpful when developing on a budget that does not allow a proper hardware in-circuit debugger (ICD) to be used.