Introduction
This document is the official specification of the AGAMA extensions to the Sega Mark III Architecture (SM3A).
I.1 About this Document
The purpose of this specification is to define the
AGAMA Extensions to the
Sega Mark III Architecture (SM3A). The
specification extends the traditional SM3A by defining features useful for
software debug. These features include the addition of a special debug
register file, as well as the definition a new operating mode allowing debug
code to monitor normal program execution. A mechanism for external debuggers
to control machine operation and extract internal machine state is also
defined.
This specification is not intended to be a reference for the SM3A. Some prerequisite knowledge of the Sega Mark III, Master System, and Game Gear hardware is assumed. Instead, this specification defines the enhancements made to the SM3A for the purposes of improving the software debug capabilities. A bibliography of references regarding all aspects of the Sega Mark III Architecture can be found at the end of this document.
Binary (Base 2) numbers are represented using the WLA-DX format of the "%"
symbol follwed by a string of binary digits (0 and 1). An example of a valid
binary number representation is: %11100110.
The Sega Mark III Architecture (SM3A) is based on
the Zilog Z80 microprocessor. This microprocessor is a
little-endian machine, meaning that bytes
of a word are numbered starting from the least-significant byte. As a
result, the SM3A and AGAMA extensions are also
little-endian. The least-significant byte in a word will always be stored to
memory first, at the lower address, followed by the most-significant byte at
the higher address.
Diagrams of data structures in memory will have lower memory addresses
towards the bottom of the page, with higher addresses growing towards the top
of the page.
where:
For example:
In this example, LOOP1 is a label, LD is the mnemonic identifier for the
opcode, HL is the destination operand, and STARTVALUE is the source operand.
Note, though, that this specification deviates slightly from Z80 assembly language with regard to the accumulator (the "A" register). In Z80 assembly
language, certain arithmetic instructions use an implied accumulator operand;
the accumulator is not explicitly specified in the instruction. For example,
the instruction:
Version 0.00.03a: (April 2, 2004) Updated to include new Power-On Configuration bit for SMS1-type bus. This new POC bit is implemented in
MesaDX Version 0.03a
Version 0.00.03: (March 13, 2004) Updated to document AGAMA extensions as
implemented in MesaDX Version 0.03 and the Kokin DLL.
Version 0.00.01: Added AGAMA Extensions documentation.
Version 0.00.00: Initial version.
Super Majik Spiral Crew, Jon, and Richard Talbot-Watkins: Their documents
describing the technical details of the Sega Master System and Sega Game Gear
are the foundations of the public's current understanding of these systems.
Andrew Lindsay: Designer of the MK1. His help with the SMS memory system
and ROM storage was invaluable. With this information I was able to design and
build the SMSARCH, a SMS cartridge backup unit.
James McKay: Provided me with my first glimpse of the SMS memory
architecture. Also, for providing miscellaneous information in a (publically
released) e-mail converstation with "Neon Spiral Injector."
Bock (or Zoop or Omar Cornut): Bock has been a strong presence in the
SMS/GG emulation community. His contributions have on many occasions inspired
my own efforts. Additionally, his founding and continuous support of S8-Dev has
been a great service to all of us still interested in software development for
Sega 8-bit systems.
Maxim: Maxim has made numerous contributions to the world of Sega 8-bit
emulation including utilities, demo programs, and technical documents. Maxim
is an active member of the S8-Dev forum and can always be depended on to step
up and answer the difficult technical questions. Maxim also wrote an
outstanding document covering the TI SN76489 sound chip.
Charles MacDonald: Charles' unending work documenting the minutae of the
various Video Display Processors used in various SM3A implementations has been
invaluable during the development of MesaDX. Charles has also written many
test programs and has on several occasions been kind enough to test demo
programs on a real SMS.
Martin Konrad: Martin Konrad is the brains behind the SDSC Debug Console.
He is also the author of an outstanding SMS debugging emulator, eSMS. eSMS is
the first emulator to include an SDSC Debug Console. Hopefully, MesaDX will
be the second.
Heliophobe: Heliophobe has made many technical contributions to Sega
8-bit emulation including demos and a SMS emulator for the Dreamcast: SMEG.
Heliophobe has also provided feedback and suggestions for improving MesaDX,
many of which have been implemented in MesaDX version 0.03.
S8-Dev: All the members of S8-Dev deserve to be thanked, not only for
their continuous interest in Sega 8-bit development, but also for perhaps being
the only people in the world who might be interested in using an emulator
like MesaDX
Quinntesson (Jeff Quinn, my brother, author of the Genesis/SegaCD/32X
emulator AGES): His understanding and interest in the more technical aspects of emulation
have greatly increased my own understanding of emulation. Our long
conversations about all things emulation-related have proved to be invaluable
during the (long) development of MesaDX.
In 1985 Sega released the Mark III game
console in Japan. Later, in 1986, Sega released a similar machine, the
Sega Master System. Finally, in 1991,
Sega released a portable version called the
Game Gear. Each of these machines has a
slightly different hardware configuration (the Game Gear, for example, has
built-in screen), but all three share a similar architecture from the
programmer's perspective, (i.e., software will run without modification or can
be easily ported between implementations). For this reason, this specification
considers all three machines to be slightly different implementations of the
Sega Mark III Architecture or SM3A. (Sega also
released a few game consoles and home computers prior to the Mark III, but
these systems are not considered to be part of the SM3A for the purposes of
this specification.)
The SM3A is based around
Zilog's 8-bit Z80 microprocessor. The system
contains 8 KBytes of RAM and typically uses
ROM cartridges for additional storage.
The ROM cartridges generally employ a paging mechanism that effectively
increases addressable memory beyond the Z80's normal 64KByte limitation. The
architecture also includes a sprite-based
Video Display Processor (VDP) derived from Texas
Instrument's TMS9918/9928 processor and a
Programmable Sound Generator (PSG) derived from the
Texas Instrument's SN76489. The Mark III and Sega Master System implementations
include two
Peripheral Ports used for connecting
devices such as joysticks or light-guns to the system. The Game Gear contains
only one peripheral port, with the system's built-in four-direction,
two-button controller permanently connected. The video, sound, and peripheral
port services are all accessible to software through system
Input/Output (I/O) Ports.
In the following sections some of the main components of the Sega Mark III
architecture are discussed. For this discussion, it is assumed that the reader
has a basic familiarity with Sega Mark III, Master System, or Game Gear
hardware from the programmer's perspective. (Please see the
bibliography at the end of this document for a list
of references pertaining to each of these systems.) Also, although the
components in the architecture are discussed as stand-alone devices, it should
be remembered that in the various implementations of the SM3A these components
might have been combined into a single chip to ease board design and reduce
manufacturing costs.
Furthermore, some of the devices (notably, the portions of the memory system)
were implemented in external ROM cartridges and therefore have a variety of
designs and implementations. For this specification, though, it is helpful to
consider these components as separate logical devices defined by their
functions, as opposed to the actual physical devices (ICs) that were used in
the different SM3A implementations.
A discussion of the specifics of the AGAMA extensions to the SM3A will begin in
Chapter 2.
Please see the
Bibliography for a list of references regarding
the Z80 microprocessor.
Please see the
Bibliography for a list of references regarding
the SM3A memory system.
Please see the
Bibliography for a list of references regarding
SM3A video devices.
Please see the
Bibliography for a list of references regarding
SM3A audio devices.
Please see the
Bibliography for a list of references regarding
the SM3A peripheral port services.
This specification defines extensions to the Sega Mark III
Architecture (SM3A). These extensions come in the form of three basic
enhancements to the SM3A:
There are several key elements of the diagram worth noting:
All the devices shown in Figure 2.a are
AGAMA Devices. These devices include
an AGAMA Extension Register file and include all the functionality required to support
Monitor Mode. Each of the
devices is discussed in more detail below:
Although 256 registers are available in each device, only 240 of them can be used for device-specific functions. The first 16 AXRs are pre-defined and have
the same purpose in every AGAMA Device. At the minimum, each AGAMA device must
implement these 16 AXRs. They are described below.
Events are one of the most important aspects of the AGAMA extensions to the
Sega Mark III Architecture (SM3A). Events and
event handling make both breakpoints and monitor mode possible. This section
covers how events work and how to specify handling mechanisms for events.
The current AGAMA Specification supports three different mechanisms for
handling events: SUSPEND, MONITOR MODE and SHUTDOWN.
If SUSPEND is specified for an event and the event triggers, the
emulator will suspend execution, allowing the user to investigate the
exact circumstance and instruction where the event triggered.
If MONITOR MODE is specified for an event and the event triggers, the
emulator devices will enter Monitor Mode
which give software access to all the debug features of each device allowing
software to handle the event using handling code separate from the application
code. If both MONITOR MODE and SUSPEND are set the system
will suspend emulation immediately after entering
Monitor Mode. If SHUTDOWN is
specified for an event and the event triggers (and no other handling flags are
set), the emulator devices will all enter Shutdown mode. Once the system is in
shutdown the only way to get out is to perform a Power-On (Hard-Reset).
Shutdown should be considered a "last resort" for event handling.
Programming the event handling mechanism for an event is accomplished via a
device's Event Handling Code Register (EHCR) and EVent Handling Flags Register
(EHFR). First, write the 8-bit event code for the desired event into the EHCR
(use the device's AXR view for this). Once the write is committed the EHFR will
be updated to reflect that event's current handling flags. To set the
event handling mechanism, simply set the bits corresonding to the desired
mechanism. See the sections on Event Handling Code Register
(EHCR) and Event Handling Flags Register (EHFR) for
more information about these registers.
There are three kinds of events currently defined in the AGAMA specification:
compulsory events,
protection events, and
breakpoint events. Each of these
events behaves slightly differently and affects the way the system resumes.
Compulsory events always trigger. They cannot be silenced (via the
COMPATIBLESILENT or MONITORSILENT flags in the EHFR). Generally
a compulsory events indicate errors that the system cannot resolve on its own.
The user will usually have to manually re-configure some portion of the
system to prevent a compulsory event from triggering. An example of a
compulsory event is the processor's INVALID_INSTR event that gets triggered
whenever the processor encounters an unknown (or unsupported) opcode.
Compulsory events have their SHUTDOWN flags set by default, so if
no other handling mechanism is specified, the system will simply enter shutdown
when a compulsory event triggers.
Protection events are the second kind of event. Protection events are
generally used to prohibit certain actions, like data writes. When a
protection event triggers it indicates that an illegal action was attempted.
The event triggers to allow the user to respond to or investigate the action
before any machine state is altered or corrupted. One example of a protection
event is in the SRAM device which allows various types of protection to be
applied to RAM. Unlike compulsory events, protection events can be silenced.
However, the action that triggers the event is still prohibited. For example,
if memory writes to RAM are protected, and the event is silenced, a write
transaction will still occur, but the SRAM device will simply throw out the
write data leaving memory unchanged. Protection events also have their
SHUTDOWN flags set by default, so if no other handling mechanism is
specified, the system will simply enter shutdown when a protection event
triggers.
The third and final type of event is a breakpoint event. Breakpoint events are
similar to protection events except that a silenced breakpoint event allows
the action to proceed. Furthermore, the silence flags for breakpoint events
are automatically set when the event triggers. This allows the user
to investigate the cause of the breakpoint but then easily resume execution
without having to worry about the breakpoint triggering again. It is the
PROC's responsibility to issue a CLEARSILENTFLAGS system message
after each instruction if any device has any of its event silent flags set.
This way a breakpoint is silenced for only one instruction will still allowing
multiple breakpoints to trigger on a single instruction. Also, unlike
compulsory and protection events, breakpoint events do not have their
SHUTDOWN flags set. If no handling mechanism for a breakpoint event
is specified the event is simply ignored.
Please see the Kokin User's Manual for
information about specific device events.
[To be completed]
The bibliography is still under construction. Please see the
Technical Documents section of S8-Dev for
a list of technical documents concerning the Sega Mark III, Sega
Master System and Sega Game Gear game consoles.
I.2 Document Conventions
This document uses a specific notation for hexadecimal and binary numbers,
symbolic representation of instructions, and data-structure formats.
Familiarity with this notation is essential to understanding this
specification.
I.2.1 Hexadecimal and Binary Numbers
Hexadecimal (Base 16) numbers are represented using the
WLA-DX format of the "$" symbol followed by a
string of hexadecimal digits (1-9 and A-F). The hexadecimal digits 'A' through
'F' will always be upper-case. An example of a valid hexadecimal number
representation is: $C0FF.
I.2.2 Bit and Byte Order
Bits are numbered starting from right to left, (i.e., least-significant to
most-significant.) All bytes consist of eight bits: 0 through 7.I.2.3 Reserved Bits
In certain register layout descriptions, various bits will be marked as
AGAMA Reserved. These bits are reserved for future expansion of the
AGAMA specification, and all reserved bits are implicitly RESET (0). Software
should never attempt to SET these bits (to 1). Generally, if the modification
of a read-only or reserved bit is attempted an error will occur and the
entire write to the register will be discarded. Access to registers with
reserved bits should follow the guidelines below:
I.2.4 Instruction Operands
The main processor used in the
Sega Mark III Architecture (SM3A) is the Zilog Z80
microprocessor. Therefore, the symbolic representation of instructions is
taken directly from Z80 assembly language. The format is shown below:
When two operands are present, the right operand is the source and the left
is the destination.LOOP1: LD HL, STARTVALUE
AND B implies the accumulator is both a source
and a destination. In contrast, the assembly language used in this
specification always specifies the accumulator. The same instruction
is written as: AND A, B in this specification. The object codes
for these instructions are identical, just the instruction notation differs.
I.3 Revision History
Version 0.00.04: (September 23, 2006) Updated for MesaDX Version 0.04 release.
I.4 Acknowledgements
The AGAMA Specification could not have existed without the help of numerous people.
Chapter 1: Introduction to the Sega Mark III Architecture
1.1 Overview of the Z80 Microprocessor
This section still needs to be completed.
1.2 Overview of the SM3A Memory System
This section still needs to be completed.
1.3 Overview of SM3A Video
This section still needs to be completed.
1.4 Overview of SM3A Audio
This section still needs to be completed.
1.5 Overview of SM3A Peripherals
This section still needs to be completed.
Chapter 2: Overview of the AGAMA Extensions to the SM3A
Each of these enhancements is discussed in further detail in later parts of the
specification. Before that, though, it is helpful to understand the basic
AGAMA system architecture. Figure 2.a below shows a high-level illustration of
the system.
Figure 2.a: The AGAMA Machine System Architecture
Each of the boxes in the diagram above represents a distinct logical device.
These devices are all AGAMA Devices and
contain an AGAMA Extension Register file and implement all the functionality
required to support Monitor Mode. AGAMA Devices, in general, are
discussed in more detail in Chapter 3: AGAMA Devices.
The External Debugger (EXTD) device is covered in its own chapter,
Chapter 5: The External Debugger Device.
Chapter 3: AGAMA Devices
3.1 AGAMA Extension Register (AXR) Files
Each AGAMA Device includes a 256-entry 16-bit AGAMA Extension Register (AXR)
file. The AXRs contain device configuration and status information. Both
software and external debuggers can access the AXRs to change device behavior
or to collect device status.
Table 3.1.a: The Pre-Defined AGAMA Extension Registers
AGAMA Extension Register (AXR)
Register Name
AXR00
Device ID Register (DIR)
AXR01
Power-On Configuration Register (POCR)
AXR02
Device Model Register (DMR)
AXR03
Device Version Register (DVR)
AXR04
Device Status Register (DSR)
AXR05
AGAMA Reserved
AXR06
AGAMA Reserved
AXR07
AGAMA Reserved
AXR08
Event Handling Code Register (EHCR)
AXR09
Event Handling Flags Register (EHFR)
AXR0A
Event Monitor Vector Register (EMVR)
AXR0B
AGAMA Reserved
AXR0C
Device Event Code Register (DECR)
AXR0D
Device Event Address Register (DEAR)
AXR0E
Device Event Data Register (DEDR)
AXR0F
Device Event Flags Register (DEFR)
3.1.1 [AXR00] Device ID Register (DIR)
The Device ID Register contains the 4-bit Device ID for a device. The Device
ID is assigned on Power-On and is used to address devices during certain types
of bus transactions, such as AXR reads and writes. In the current AGAMA
specification, the Device IDs are fixed. However, future versions may change
Device ID assignments, so the DIR is the only accurate way to determine a
device's ID.
Table 3.1.1.a: Bit Fields of the Device ID Register (DIR)
DIR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 AGAMA Reserved
Byte 0 AGAMA Reserved
Device ID[3:0]
Access:
READ-ONLY
Bit Fields:
The 4-bit Device ID for the device.
These bits are reserved for future expansion.
3.1.2 [AXR01] Power-On Configuration Register (POCR)
The Power-On Configuration Register contains the initial configuration
settings of a device. The bits in the POCR are generic and do not
necessarily apply to all devices. Each device samples the same Power-On
Configuration settings and saves them in the POCR, but those settings that
do not apply to the device are ignored.
Table 3.1.2.a: Bit Fields of the Power-On Configuration Register (POCR)
POCR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 POST Code AGAMA
Reserved Monitor Mode Suspended
Byte 0 GG Mode Export Region AGAMA
Reserved SMS1 Bus AGAMA Reserved
Boot Device
Access:
READ-ONLY
Bit Fields:
A 4-bit code indicating the result of the
Power-On Self Test (POST) for the device.
A zero value indicates the device passed POST. A non-zero value
indicates a failure. The failure code is specific to each device.
If this bit is set, the device powered-on in
Monitor Mode. Otherwise,
the device powered-on in
Compatible Mode.
If this bit is set, the device powered-on
suspended. If not set, the device
powered-on resumed and execution
began immediately.
If this bit is set, the device powered-on in
Game Gear (GG) Mode. Otherwise,
the device powered-on in
Master System (SMS) Mode.
If this bit is set, the device powered-on as an
Export Region machine. Otherwise, the
device powered-on as a
Japan Region machine.
If this bit is set, the device will be configured for a SMS1-type bus.
An SMS1-type bus indefinitely retains the last data value driven
on the bus. In the case of a bus transaction where no devices respond,
the data returned is the last data value that appeared on the bus.
Usually, this data value is the last byte of the most-recently fetched
instruction. If the SMS1 Bus power-on configuration bit is not set,
the device is configured for a SMS2/GG-type bus. A SMS2/GG-type bus
does not retain the last driven data value, and will simply return $FF
if no data is driven on the bus.
A 2-bit identifier indicating which memory device is initially
mapped into the processor address space. Table 3.1.2.b shows the
encodings for the Boot Device bits.
These bits are reserved for future expansion.
Table 3.1.2.b: Boot Device Encodings for the Power-On Configuration
Register (POCR)
Region Encoding Region
0y00 Boot ROM (BROM) Device
0y01 Sega Card (CARD) Device
0y10 External Device 0 (EXT0). Device connected to SMS
Cartridge Port.
0y11 External Device 1 (EXT1). Device connected to SMS
Expansion Port.
3.1.3 [AXR02] Device Model Register (DMR)
The Device Model Register contains the device's model number. This number can
be used to indicate compatibility with the Sega 315-XXXX series chips or can be
used to differentiate similar devices with slightly different feature sets.
Table 3.1.3.a: Bit Fields of the Device Model Register (DMR)
DMR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Model Number
Byte 0 Model Number
Access:
READ-ONLY
Bit Fields:
The device's model number.
3.1.4 [AXR03] Device Version Register (DVR)
The Device Version Register specifies the implementation version of the device.
The value in this register can be used by Monitor Software to determine which
features the current device implementation supports.
Table 3.1.4.a: Bit Fields of the Device Version Register (DVR)
DVR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Major Version
Byte 0 Minor Version
Access:
READ-ONLY
Bit Fields:
The major version number of the device implementation.
The minor version number of the device implementation.
3.1.5 [AXR04] Device Status Register (DSR)
The Device Status Register contains general information about the device's
current state.
Table 3.1.5.a: Bit Fields of the Device Status Register (DSR)
DSR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Compatible Silent Set Monitor Silent Set
Device Specific Device Enabled
Shutdown Monitor Mode Suspended
Byte 0 Device Specific
Access:
READ-ONLY
Bit Fields:
A COMPATBILESILENT flag is set if one of the device's EHFR
registers. If this bit is set and the device is in
Compatible Mode when it
receives a CLEARSILENTFLAGS message then the
COMPATIBLESILENT and MONITORSILENT flags in all of the
EHFR registers are reset. See the Event Handling
Flags Register (EHFR) section for more information about the
SILENT flags.
A MONITORSILENT flag is set if one of the device's EHFR
registers. If this bit is set and the device is in
Monitor Mode when it receives a
CLEARSILENTFLAGS message then the MONITORSILENT flags in
all of the EHFR registers are reset. See the Event
Handling Flags Register (EHFR) section for more information about
the SILENT flags.
The device is enabled and will respond to bus transactions such as
memory and port accesses. If the device is disabled it will
only respond to SYSMESSAGE transactions.
The device has entered Shutdown.
The device will no longer respond to bus transactions, other than
SYSMESSAGE transactions. Shutdown is usually the
result of an unrecoverable system error. A Power-On (Hard-Reset) is
required to bring the device and the rest of the system out of shutdown.
The device is operating in Monitor
Mode. Monitor mode allows software to have more control over debug
functionality of the device. Monitor mode is non-reentrant.
The device has suspended. The device
will still respond to bus traffic, but will not perform any "active"
processing such as executing instructions (in the case of a processor)
or refreshing the video display (in the case of the VDP).
The functions of these bits are specific to the device.
3.1.6 [AXR08] Event Handling Code Register (EHCR)
The Event Handling Code Register is used to control the data appearing in the
Event Handling Flags Register (EHFR). Each AGAMA Device
may define up to 256 Event Codes. Each of
these 256 events has a 16-bit flag value associated with it indicating how
to handle the event when it occurs. Together, the EHCR and EHFR control the access to these flags for a specific event. The event flags in the EHFR
correspond to the event code in the EHCR. Writing a new event code to the
EHCR will update the EHFR with that event's flags which can then be modified
via the EHFR.
Table 3.1.6.a: Bit Fields of the Event Handling Code Register (EHCR)
EHCR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 AGAMA Reserved
Byte 0 Event Code Index
Access:
READ/WRITE
Bit Fields:
The Event Code indicates which event the flags in the Event Handling
Flags Register (EHFR) correspond to.
These bits are reserved for future expansion.
3.1.7 [AXR09] Event Handling Flags Register (EHFR)
The Event Handling Flags Register is a window into the 256-entry event flags
table. Each AGAMA Device may define up to 256
Event Codes. Each of these 256 events has
a 16-bit flag value associated with it indicating how to handle the event
when it occurs. Together, the EHCR and EHFR control the access to these flags
for a specific event. The event flags in the EHFR correspond to the event code
in the EHCR. Writing a new event code to the EHCR will update the EHFR with
that event's flags which can then be modified via the EHFR.
Table 3.1.7.a: Bit Fields of the Event Handling Flags Register (EHFR)
EHFR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Compatible Silent Monitor Silent
AGAMA Reserved Shutdown Monitor Mode Suspend
Byte 0 AGAMA Reserved
Access:
READ/WRITE
Bit Fields:
If this bit is set, then the event (whose code is specified in the EHCR)
will be silenced (and will not trigger) the next time it occurs while
the device is in
Compatible Mode. (Note:
Compulsory Events, cannot be silenced.
Please see the section on Events and Event Handling
for more information about the different types of device events.)
This bit is used as a flag for events so that they only trigger once
during the execution of an instruction. When the device receives a
CLEARSILENTFLAGS message while in Compatible Mode, this bit
(along with the Monitor Silent bit) is cleared for all 256 events.
If the device is in Monitor Mode, this bit is not affected by a
CLEARSILENTFLAGS message.
If this bit is set, then the event (whose code is specified in the EHCR)
will be silenced (and will not trigger) the next time it occurs while
the device is in Monitor Mode.
(Note: Compulsory Events, cannot be
silenced. Please see the section on Events and Event
Handling for more information about the different types of device
events.) This bit is used as a flag for events so that they only
trigger once during the execution of an instruction. When the device
receives a CLEARSILENTFLAGS message while in Monitor Mode, this
bit is cleared for all 256 events.
Setting this bit indicates that the system should enter
Shutdown mode when the event triggers.
This flag is only examined if no other event handling flag is set
(such as Monitor Mode or Suspend described below).
Shutdown mode is used when an error or event occurs and no error
recovery is possible. For example, if the processor encounters an
unknown opcode the system may enter shutdown if no other event handling
is specified. For Events and
Event Handling for more information about shutdown and the
different types of device events.
Setting this bit indicates that the system should enter
Monitor Mode when the event
triggers.
Setting this bit indicates that the system should
suspend execution when the event
triggers.
These bits are reserved for future expansion.
3.1.8 [AXR0A] Event Monitor Vector Register (EMVR)
The Event Monitor Vector Register (EMVR) contains the address of the device's
Monitor Mode handler. When a device event triggers and the Monitor
Mode event flag is set, the device will request that the system enter
Monitor Mode and program flow will jump to the address specified in this
register.
Table 3.1.8.a: Bit Fields of the Event Monitor Vector Register (EMVR)
EMVR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Monitor Vector Address[15:8]
Byte 0 Monitor Vector Address[7:0]
Access:
READ/WRITE
Bit Fields:
The address of the device's Monitor Mode handler.
3.1.9 [AXR0C] Device Event Code Register (DECR)
The Device Event Code Register (DECR) contains the 8-bit event code of the
last event that triggered. This register will retain its value until another
event is triggered. Silenced events do not trigger and will not update this
register. Other information about the last triggered event can be found in the
Device Event Address Register (DEAR),
Device Event Data Register (DEDR), and
Device Event Flags Register (DEFR),
Table 3.1.9.a: Bit Fields of the Device Event Code Register (DECR)
DECR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Reserved
Byte 0 Event Code
Access:
READ-ONLY
Bit Fields:
The 8-bit event code for the last triggered event.
3.1.10 [AXR0D] Device Event Address Register (DEAR)
The Device Event Address Register (DEAR) contains the 16-bit address (or 8-bit
port) specific to the last event that triggered. For example, if a memory
write event triggered, then this register will contain the address the data
was to be written to. This register will retain its value until another event
is triggered. Silenced events do not trigger and will not update this
register. Other information about the last triggered event can be found in the
Device Event Code Register (DECR),
Device Event Data Register (DEDR), and
Device Event Flags Register (DEFR),
Table 3.1.10.a: Bit Fields of the Device Event Address Register (DEAR)
DEAR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Event-specific Address[15:8]
Byte 0 Event-specific Address[7:0]
Access:
READ-ONLY
Bit Fields:
A 16-bit address (or 8-bit port) specific to the event that triggered.
For example, if a memory write event was triggered then this register
will contain the address the data was to be written to. This register
retains its value until another event is triggered.
3.1.11 [AXR0E] Device Event Data Register (DEDR)
The Device Event Data Register (DEDR) contains data specific to the last event
that triggered. For example, if a memory write event triggered, then this
register will contain the write data. This register will retain its value
until another event is triggered. Silenced events do not trigger and will not
update this register. Other information about the last triggered event can be
found in the
Device Event Code Register (DECR),
Device Event Address Register (DEAR), and
Device Event Flags Register (DEFR),
Table 3.1.11.a: Bit Fields of the Device Event Data Register (DEDR)
DEDR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Event-specific Data[15:8]
Byte 0 Event-specific Data[7:0]
Access:
READ-ONLY
Bit Fields:
16-bits of data specific to the event that triggered. For example, if a
memory write event was triggered then this register will contain the
write data. This register retains its value until another event is
triggered.
3.1.12 [AXR0F] Device Event Flags Register (DEFR)
The Device Event Flags Register (DEFR) contains a copy of the
Event Handling Flags Register (EHFR) for the event that
triggered. This register will retain its value until another event
is triggered. Silenced events do not trigger and will not update this
register. Other information about the last triggered event can be found in the
Device Event Code Register (DECR),
Device Event Address Register (DEAR), and
Device Event Data Register (DEDR),
Table 3.1.12.a: Bit Fields of the Device Event Flags Register (DEFR)
EHFR Bit 7 Bit 6
Bit 5 Bit 4 Bit 3
Bit 2 Bit 1 Bit 0
Byte 1 Compatible Silent Monitor Silent
AGAMA Reserved Shutdown Monitor Mode Suspend
Byte 0 AGAMA Reserved
Access:
READ-ONLY
Bit Fields:
The Compatible Silent flag is set for the triggered event.
The next time this event occurs while the device is in Compatible Mode
the event will be silenced and will not trigger. See the section on
the Event Handling Flag Register (EHFR) for more
information about this bit.
The Monitor Silent flag is set for the triggered event.
The next time this event occurs while the device is in Monitor Mode
the event will be silenced and will not trigger. See the section on
the Event Handling Flag Register (EHFR) for more
information about this bit.
The Shutdown flag is set for the triggered event, indicating
that one possible mechanism for handling the event was to enter
Shutdown mode. See the section on
the Event Handling Flag Register (EHFR) for more
information about this bit.
The Monitor Mode flag is set for the triggered event, indicating
that one possible mechanism for handling the event was to enter
Monitor Mode. See the section on
the Event Handling Flag Register (EHFR) for more
information about this bit.
The Suspend flag is set for the triggered event, indicating
that one possible mechanism for handling the event was to
suspend execution. See the section on
the Event Handling Flag Register (EHFR) for more
information about this bit.
These bits are reserved for future expansion.
3.2 Events and Event Handling
Monitor Mode is still being developed.
Monitor Mode has been partially implemented in MesaDX, but the functionality
is compiled out of the release versions. It is necessary to develop the
Monitor Mode specification alongside an implementation so that fatal
design errors can be immediately detected. Once Monitor Mode has been fully
developed and tested in MesaDX, this chapter will contain a detailed
description of Monitor Mode functionality.
Chapter 4: Monitor Mode
The External Debugg Device is an AGAMA Device and is the interface between the
emulator and the external world. The EXTD is used to control emulation
and is used to extract data from the machine.
Chapter 5: The External Debugger Device
Glossary
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Bibliography