Zapple Monitor

Last updated
Zapple Monitor
Developer Roger Amidon, Technical Design Labs [1]
Initial release1976;48 years ago (1976)
Preceded byApple Monitor
Official website www.zapple.net

The Zapple Monitor was a firmware-based product developed by Roger Amidon [1] at Technical Design Laboratories (also known as TDL). TDL was based in Princeton, New Jersey, USA in the 1970s and early 1980s. [2]

The Zapple monitor was a primitive operating system which could be expanded and used as a Basic Input/Output Services (BIOS) 8080- and Z80-based computers. Much of the functionality of Zapple would find its way into applications like 'Debug' in MS-DOS.

Zapple commands would allow a user to examine and modify memory, I/O, execute software (Goto or Call) and had a variety of other commands. The program required little in the way of then-expensive read-only memory (ROM) or RAM. An experienced user could use Zapple to test and debug code, verify hardware function, test memory, and so on.

A typical command line would start with a letter such as 'X' (examine memory) followed by a hexadecimal word (the memory address  01AB) and [enter] or [space]. After this sequence the content of the memory location would be shown [FF] and the user could enter a hexadecimal byte [00] to replace the contents of the address, or hit [space] or [enter] to move to the next address [01AB]. An experienced user could enter a small program in this manner, entering machine language from memory.

Because of the simple structure of the program, consisting of a vector table (one for each letter) and a small number of subroutines, and because the source code was readily available, adding or modifying Zapple was straightforward. The dominant operating system of the era, CP/M, required the computer manufacturer or hobbyist to develop hardware specific BIOS. Many users tested their BIOS subroutines using Zapple to verify, for example, a floppy disk track seek command, or read sector command, etc., was functioning correctly by extending Zapple to accommodate these operations in the hardware environment.

The general structure of Zapple lives on in the code of many older programmers working on embedded systems as it provides a simple mechanism to test the hardware before moving to more advanced user interfaces.

Related Research Articles

<span class="mw-page-title-main">BIOS</span> Firmware for hardware initialization and OS runtime services

In computing, BIOS is firmware used to provide runtime services for operating systems and programs and to perform hardware initialization during the booting process. The BIOS firmware comes pre-installed on an IBM PC or IBM PC compatible's system board and exists in some UEFI-based systems to maintain compatibility with operating systems that do not support UEFI native operation. The name originates from the Basic Input/Output System used in the CP/M operating system in 1975. The BIOS originally proprietary to the IBM PC has been reverse engineered by some companies looking to create compatible systems. The interface of that original system serves as a de facto standard.

<span class="mw-page-title-main">Booting</span> Process of starting a computer

In computing, booting is the process of starting a computer as initiated via hardware such as a button on the computer or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system.

<span class="mw-page-title-main">Debugger</span> Computer program used to test and debug other programs

A debugger or debugging tool is a computer program used to test and debug other programs. The main use of a debugger is to run the target program under controlled conditions that permit the programmer to track its execution and monitor changes in computer resources that may indicate malfunctioning code. Typical debugging facilities include the ability to run or halt the target program at specific points, display the contents of memory, CPU registers or storage devices, and modify memory or register contents in order to enter selected test data that might be a cause of faulty program execution.

<span class="mw-page-title-main">KIM-1</span> Single-board computer produced by MOS Technology

The KIM-1, short for Keyboard Input Monitor, is a small 6502-based single-board computer developed and produced by MOS Technology, Inc. and launched in 1976. It was very successful in that period, due to its low price and easy-access expandability.

<span class="mw-page-title-main">PEEK and POKE</span> Commands in some high-level programming languages

In computing, PEEK and POKE are commands used in some high-level programming languages for accessing the contents of a specific memory cell referenced by its memory address. PEEK gets the byte located at the specified memory address. POKE sets the memory byte at the specified address. These commands originated with machine code monitors such as the DECsystem-10 monitor; these commands are particularly associated with the BASIC programming language, though some other languages such as Pascal and COMAL also have these commands. These commands are comparable in their roles to pointers in the C language and some other programming languages.

KERNAL is Commodore's name for the ROM-resident operating system core in its 8-bit home computers; from the original PET of 1977, followed by the extended but related versions used in its successors: the VIC-20, Commodore 64, Plus/4, Commodore 16, and Commodore 128.

<span class="mw-page-title-main">Machine code monitor</span> Software that was popular during the home computer era of the 1970s and 1980s

A machine code monitor is software that allows a user to enter commands to view and change 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, and include absolute-address code assembly and disassembly capabilities.

The Macintosh Toolbox implements many of the high-level features of the Classic Mac OS, including a set of application programming interfaces for software development on the platform. The Toolbox consists of a number of "managers," software components such as QuickDraw, responsible for drawing onscreen graphics, and the Menu Manager, which maintain data structures describing the menu bar. As the original Macintosh was designed without virtual memory or memory protection, it was important to classify code according to when it should be loaded into memory or kept on disk, and how it should be accessed. The Toolbox consists of subroutines essential enough to be permanently kept in memory and accessible by a two-byte machine instruction; however it excludes core "kernel" functionality such as memory management and the file system. Note that the Toolbox does not draw the menu onscreen: menus were designed to have a customizable appearance, so the drawing code was stored in a resource, which could be on a disk.

BIOS implementations provide interrupts that can be invoked by operating systems and application programs to use the facilities of the firmware on IBM PC compatible computers. Traditionally, BIOS calls are mainly used by DOS programs and some other software such as boot loaders. BIOS runs in the real address mode of the x86 CPU, so programs that call BIOS either must also run in real mode or must switch from protected mode to real mode before calling BIOS and then switching back again. For this reason, modern operating systems that use the CPU in Protected mode or Long mode generally do not use the BIOS interrupt calls to support system functions, although they use the BIOS interrupt calls to probe and initialize hardware during booting. Real mode has the 1MB memory limitation, modern boot loaders use the unreal mode or protected mode to access up to 4GB memory.

<span class="mw-page-title-main">Power-on self-test</span> Process performed by firmware or software routines

A power-on self-test (POST) is a process performed by firmware or software routines immediately after a computer or other digital electronic device is powered on.

Atari Assembler Editor is a ROM cartridge-based development system released by Atari, Inc. in 1981. It is used to edit, assemble, and debug 6502 programs for Atari 8-bit computers without the need for additional tools. It was programmed by Kathleen O'Brien of Shepardson Microsystems, the company which wrote Atari BASIC, and Assembler Editor shares many design concepts with that language implementation.

<span class="mw-page-title-main">Tangerine Microtan 65</span>

The Tangerine Microtan 65 was a 6502-based single board microcomputer, first sold in 1979, that could be expanded into, what was for its day, a comprehensive and powerful system. The design became the basis for what later became the Oric Atmos and later computers. Those later machines have similar keyboard addressing and tape I/O as the Microtan 65. The Microtan 65 has a hardware single step function that can be used for debugging software in both ROM and RAM. The computer was available as ready-built boards or as kits consisting of board and components requiring soldering together.

Intel hexadecimal object file format, Intel hex format or Intellec Hex is a file format that conveys binary information in ASCII text form, making it possible to store on non-binary media such as paper tape, punch cards, etc., to display on text terminals or be printed on line-oriented printers. The format is commonly used for programming microcontrollers, EPROMs, and other types of programmable logic devices and hardware emulators. In a typical application, a compiler or assembler converts a program's source code to machine code and outputs it into a object or executable file in hexadecimal format. In some applications, the Intel hex format is also used as a container format holding packets of stream data. Common file extensions used for the resulting files are .HEX or .H86. The HEX file is then read by a programmer to write the machine code into a PROM or is transferred to the target system for loading and execution. There are various tools to convert files between hexadecimal and binary format, and vice versa.

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. The name is derived from a program which is always present in the computer's memory, thus being resident. 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.

<span class="mw-page-title-main">Front panel</span>

A front panel was used on early electronic computers to display and allow the alteration of the state of the machine's internal registers and memory. The front panel usually consisted of arrays of indicator lamps, digit and symbol displays, toggle switches, dials, and push buttons mounted on a sheet metal face plate. In early machines, CRTs might also be present. Prior to the development of CRT system consoles, many computers such as the IBM 1620 had console typewriters.

MSX-DOS is a discontinued disk operating system developed by Microsoft's Japan subsidiary for the 8-bit home computer standard MSX, and is a cross between MS-DOS v1.25 and CP/M-80 v2.2.

Technical Design Labs (TDL) was an early producer of personal computers founded in 1976 by Carl Galletti and Roger Amidon. TDL was based in Princeton, New Jersey, USA in the 1970s and early 1980s.

<span class="mw-page-title-main">Emulator</span> System allowing a device to imitate another

In computing, an emulator is hardware or software that enables one computer system to behave like another computer system. An emulator typically enables the host system to run software or use peripheral devices designed for the guest system. Emulation refers to the ability of a computer program in an electronic device to emulate another program or device.

<span class="mw-page-title-main">Driver Verifier</span> Windows driver troubleshooter

Driver Verifier is a tool included in Microsoft Windows that replaces the default operating system subroutines with ones that are specifically developed to catch device driver bugs. Once enabled, it monitors and stresses drivers to detect illegal function calls or actions that may be causing system corruption. It acts within the kernel mode and can target specific device drivers for continual checking or make driver verifier functionality multithreaded, so that several device drivers can be stressed at the same time. It can simulate certain conditions such as low memory, I/O verification, pool tracking, IRQL checking, deadlock detection, DMA checks, IRP logging, etc. The verifier works by forcing drivers to work with minimal resources, making potential errors that might happen only rarely in a working system manifest immediately. Typically fatal system errors are generated by the stressed drivers in the test environment, producing core dumps that can be analysed and debugged immediately; without stressing, intermittent faults would occur in the field, without proper troubleshooting facilities or personnel.

Each time Intel launched a new microprocessor, they simultaneously provided a system development kit (SDK) allowing engineers, university students, and others to familiarise themselves with the new processor's concepts and features. The SDK single-board computers allowed the user to enter object code from a keyboard or upload it through a communication port, and then test run the code. The SDK boards provided a system monitor ROM to operate the keyboard and other interfaces. Kits varied in their specific features but generally offered optional memory and interface configurations, a serial terminal link, audio cassette storage, and EPROM program memory. Intel's Intellec development system could download code to the SDK boards.

References

  1. 1 2 "Bio" (PDF). p. 3. Technical Design Labs, Princeton, NJ, Partner / Founder, April 1976 – August 1979, Products Produced: "Zapple" Debug & I/O handler software for S-100 bus, "SMB" – S-100 based I/O board, with Zapple Software in ROM
  2. Advertisement: XITAN Alpha 1 and Alpha 2 from Technical Design Labs, Published 1977, From Volume 1 Issue 1 of ROM Magazine.