imported>Sardonism: Reverted 1 edit by 2402:800:62B2:C218:992A:B113:687:758C (talk) to last revision by Bumm13

2025-06-02T10:33:55Z

Reverted 1 edit by 2402:800:62B2:C218:992A:B113:687:758C (talk) to last revision by Bumm13

New page

{{Short description|Software that was popular during the home computer era of the 1970s and 1980s}}
[[File:W65C816S Machine Code Monitor.jpeg|thumb|Machine code monitor in a [[WDC 65C816|W65C816S]] [[single-board computer]], displaying [[disassembler|code disassembly]], as well as processor register and memory dumps]]
[[File:Apple II Monitor.png|thumb|right|280px|[[Apple II]] [[MOS Technology 6502|6502]] machine code monitor]]
A '''machine code monitor''' ({{aka}} [[machine language]] monitor) is [[software]] that allows a user to enter commands to view and change [[memory address|memory locations]] on a [[computer]], with options to load and save memory contents from/to [[secondary storage]]. Some full-featured machine code monitors provide detailed control ("single-stepping") of the execution of machine language programs (much like a [[debugger]]), and include absolute-address [[Assembly language#Assembler|code assembly]] and [[disassembler|disassembly]] capabilities.

Motorola published the [[MIKBUG]] ROM monitor for the 6800 in 1973 and the BUFFALO ROM monitor for the [[Motorola 68HC11|68HC11]].

Machine code monitors became popular during the [[home computer]] era of the 1970s and 1980s and were sometimes available as resident [[firmware]] in some computers (e.g., the built-in monitors in the [[Commodore 128]], [[Zenith Z-89|Heathkit H89]] and Zenith laptops). Often, computer manufacturers rely on their ROM-resident monitors to permit users to reconfigure their computers following installation of upgrade hardware, such as expanded main memory, additional disk drives, or different video displays.

It was not unheard of to perform all of one's programming in a monitor in lieu of a full-fledged symbolic assembler. Even after full-featured assemblers became readily available, a machine code monitor was indispensable for [[debugging]] programs. The usual technique was to set break points in the code undergoing testing (e.g., with a [[BRK]] instruction in [[MOS Technology 6502|6502]] assembly language<ref>{{cite book|title=Microprocessors and Microcomputers: Hardware and Software|author=R.J. Tocci & L.P. Laskowski|publisher=Prentice-Hall|date=1979|isbn=9780135813225|page=[https://archive.org/details/microprocessorsm00tocc/page/379 379]|url-access=registration|url=https://archive.org/details/microprocessorsm00tocc/page/379}}</ref><ref>{{cite book|title=6502 Assembly Language Programming|author=L.A. Leventhal|publisher=Osborne/McGraw-Hill|date=1986|isbn=9780078812163}}</ref><ref>{{cite book|title=Apple II in the Laboratory|author=A.F. Kuckes & B.G. Thompson|publisher=UP Archive|date=1987|isbn=9780521321983|page=93}}</ref>) and start the program. When the [[microprocessor]] encountered a break point, the test program would be [[interrupt|interrupted]] and control would be transferred to the machine code monitor. Typically, this would trigger a [[processor register|register dump]] and then the monitor would await programmer input. Activities at this point might include examining memory contents, [[patch (computing)|patching code]] and/or perhaps altering the processor registers prior to restarting the test program.

In most systems where higher-level languages are employed, [[debugger]]s are used to present a more abstract and friendly view of what is happening within a program. However, the use of machine code monitors persists, especially in the area of [[Hacker culture#Home computing enthusiasts|hobby-built computers]].{{Cn|date=August 2023}}

== References ==
<references />

[[Category:Memory management software|*]]
[[Category:Microcomputer software]]

Machine code monitor - Revision history

imported>Sardonism: Reverted 1 edit by 2402:800:62B2:C218:992A:B113:687:758C (talk) to last revision by Bumm13