Initial revision

13 files changed, 1596 insertions, 0 deletions

diff --git a/doc/supplements/m68k/MVME136_TIMES b/doc/supplements/m68k/MVME136_TIMES
new file mode 100644
index 0000000000..3faa666049
--- /dev/null
+++ b/doc/supplements/m68k/MVME136_TIMES
@@ -0,0 +1,244 @@
+#
+#  M68020/MVME136 Timing and Size Information
+#
+
+#
+#  CPU Model Information
+#
+RTEMS_CPU_MODEL MC68020
+#
+#  Interrupt Latency
+#
+#  NOTE:  In general, the text says it is hand-calculated to be
+#         RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
+#         Mhz and this was last calculated for Release 
+#         RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
+#
+RTEMS_MAXIMUM_DISABLE_PERIOD TBD
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1
+#
+#  Context Switch Times
+#
+RTEMS_NO_FP_CONTEXTS 35
+RTEMS_RESTORE_1ST_FP_TASK 39
+RTEMS_SAVE_INIT_RESTORE_INIT 66
+RTEMS_SAVE_IDLE_RESTORE_INIT 66
+RTEMS_SAVE_IDLE_RESTORE_IDLE 68
+#
+#  Task Manager Times
+#
+RTEMS_TASK_CREATE_ONLY 148
+RTEMS_TASK_IDENT_ONLY 350
+RTEMS_TASK_START_ONLY 76
+RTEMS_TASK_RESTART_CALLING_TASK 95
+RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
+RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
+RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
+RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
+RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
+RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
+RTEMS_TASK_DELETE_CALLING_TASK 170
+RTEMS_TASK_DELETE_SUSPENDED_TASK 138
+RTEMS_TASK_DELETE_BLOCKED_TASK 143
+RTEMS_TASK_DELETE_READY_TASK 144
+RTEMS_TASK_SUSPEND_CALLING_TASK 71
+RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
+RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
+RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
+RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
+RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
+RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
+RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
+RTEMS_TASK_MODE_NO_RESCHEDULE 16
+RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
+RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
+RTEMS_TASK_GET_NOTE_ONLY 33
+RTEMS_TASK_SET_NOTE_ONLY 33
+RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
+RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
+RTEMS_TASK_WAKE_WHEN_ONLY 117
+#
+#  Interrupt Manager
+#
+RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
+RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
+RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
+RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
+RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
+RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
+#
+#  Clock Manager
+#
+RTEMS_CLOCK_SET_ONLY 86
+RTEMS_CLOCK_GET_ONLY 1
+RTEMS_CLOCK_TICK_ONLY 17
+#
+#  Timer Manager
+#
+RTEMS_TIMER_CREATE_ONLY 28
+RTEMS_TIMER_IDENT_ONLY 343
+RTEMS_TIMER_DELETE_INACTIVE 43
+RTEMS_TIMER_DELETE_ACTIVE 47
+RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
+RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
+RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
+RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
+RTEMS_TIMER_RESET_INACTIVE 54
+RTEMS_TIMER_RESET_ACTIVE 58
+RTEMS_TIMER_CANCEL_INACTIVE 31
+RTEMS_TIMER_CANCEL_ACTIVE 34
+#
+#  Semaphore Manager
+#
+RTEMS_SEMAPHORE_CREATE_ONLY 60
+RTEMS_SEMAPHORE_IDENT_ONLY 367
+RTEMS_SEMAPHORE_DELETE_ONLY 58
+RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
+RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
+RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
+RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
+RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
+RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
+#
+#  Message Manager
+#
+RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
+RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
+RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
+RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
+RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
+RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
+RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
+RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
+RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
+RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
+RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
+RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
+RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
+RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
+RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
+RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
+RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
+#
+#  Event Manager
+#
+RTEMS_EVENT_SEND_NO_TASK_READIED 24
+RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
+RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
+RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
+RTEMS_EVENT_RECEIVE_AVAILABLE 28
+RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
+RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
+#
+#  Signal Manager
+#
+RTEMS_SIGNAL_CATCH_ONLY 15
+RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
+RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
+RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
+RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
+#
+#  Partition Manager
+#
+RTEMS_PARTITION_CREATE_ONLY 70
+RTEMS_PARTITION_IDENT_ONLY 341
+RTEMS_PARTITION_DELETE_ONLY 42
+RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
+RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
+RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
+#
+#  Region Manager
+#
+RTEMS_REGION_CREATE_ONLY 63
+RTEMS_REGION_IDENT_ONLY 348
+RTEMS_REGION_DELETE_ONLY 39
+RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
+RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
+RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
+RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
+RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
+RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
+#
+#  Dual-Ported Memory Manager
+#
+RTEMS_PORT_CREATE_ONLY 35
+RTEMS_PORT_IDENT_ONLY 340
+RTEMS_PORT_DELETE_ONLY 39
+RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
+RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
+#
+#  IO Manager
+#
+RTEMS_IO_INITIALIZE_ONLY 4
+RTEMS_IO_OPEN_ONLY 2
+RTEMS_IO_CLOSE_ONLY 1
+RTEMS_IO_READ_ONLY 2
+RTEMS_IO_WRITE_ONLY 3
+RTEMS_IO_CONTROL_ONLY 2
+#
+#  Rate Monotonic Manager
+#
+RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
+RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
+RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
+RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
+RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
+RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
+RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
+RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
+#
+#  Size Information
+#
+#
+#  xxx alloted for numbers
+#
+RTEMS_DATA_SPACE 723
+RTEMS_MINIMUM_CONFIGURATION 18,980
+RTEMS_MAXIMUM_CONFIGURATION 36,438
+#  x,xxx alloted for numbers
+RTEMS_CORE_CODE_SIZE 12,674
+RTEMS_INITIALIZATION_CODE_SIZE 970
+RTEMS_TASK_CODE_SIZE 3,562
+RTEMS_INTERRUPT_CODE_SIZE 54
+RTEMS_CLOCK_CODE_SIZE 334
+RTEMS_TIMER_CODE_SIZE 1,110
+RTEMS_SEMAPHORE_CODE_SIZE 1,632
+RTEMS_MESSAGE_CODE_SIZE 1,754
+RTEMS_EVENT_CODE_SIZE 1,000
+RTEMS_SIGNAL_CODE_SIZE 418
+RTEMS_PARTITION_CODE_SIZE 1,164
+RTEMS_REGION_CODE_SIZE 1,494
+RTEMS_DPMEM_CODE_SIZE 724
+RTEMS_IO_CODE_SIZE 686
+RTEMS_FATAL_ERROR_CODE_SIZE 24
+RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
+RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
+#  xxx alloted for numbers
+RTEMS_TIMER_CODE_OPTSIZE 184
+RTEMS_SEMAPHORE_CODE_OPTSIZE 172
+RTEMS_MESSAGE_CODE_OPTSIZE 288
+RTEMS_EVENT_CODE_OPTSIZE 56
+RTEMS_SIGNAL_CODE_OPTSIZE 56
+RTEMS_PARTITION_CODE_OPTSIZE 132
+RTEMS_REGION_CODE_OPTSIZE 160
+RTEMS_DPMEM_CODE_OPTSIZE 132
+RTEMS_IO_CODE_OPTSIZE 0
+RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
+RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
+#  xxx alloted for numbers
+RTEMS_BYTES_PER_TASK 400
+RTEMS_BYTES_PER_TIMER 68
+RTEMS_BYTES_PER_SEMAPHORE 124
+RTEMS_BYTES_PER_MESSAGE_QUEUE 148
+RTEMS_BYTES_PER_REGION 144
+RTEMS_BYTES_PER_PARTITION 56
+RTEMS_BYTES_PER_PORT 36
+RTEMS_BYTES_PER_PERIOD 36
+RTEMS_BYTES_PER_EXTENSION 64
+RTEMS_BYTES_PER_FP_TASK 332
+RTEMS_BYTES_PER_NODE 48
+RTEMS_BYTES_PER_GLOBAL_OBJECT 20
+RTEMS_BYTES_PER_PROXY 124
+#  x,xxx alloted for numbers
+RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/m68k/Makefile b/doc/supplements/m68k/Makefile
new file mode 100644
index 0000000000..94a56dcf99
--- /dev/null
+++ b/doc/supplements/m68k/Makefile
@@ -0,0 +1,87 @@
+#
+#  COPYRIGHT (c) 1996.
+#  On-Line Applications Research Corporation (OAR).
+#  All rights reserved.
+#
+
+include ../Make.config
+
+PROJECT=m68k
+REPLACE=../tools/word-replace
+
+all:  
+
+COMMON_FILES=../common/cpright.texi ../common/setup.texi \
+  ../common/timing.texi
+
+FILES= $(PROJECT).texi \
+  bsp.texi callconv.texi cpumodel.texi cputable.texi fatalerr.texi \
+  intr.texi memmodel.texi preface.texi timetbl.texi timedata.texi wksheets.texi 
+
+all:
+
+info: c_m68k
+	cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL)
+
+c_m68k: $(FILES)
+	$(MAKEINFO) $(PROJECT).texi
+
+vinfo: info
+	$(INFO) -f c_m68k
+
+dvi: $(PROJECT).dvi
+ps: $(PROJECT).ps
+	
+$(PROJECT).ps: $(PROJECT).dvi
+	dvips -o $(PROJECT).ps $(PROJECT).dvi
+	cp $(PROJECT).ps $(PS_INSTALL)
+
+dv: dvi
+	$(XDVI) $(PROJECT).dvi
+
+view: ps
+	$(GHOSTVIEW) $(PROJECT).ps
+
+$(PROJECT).dvi: $(FILES)
+	$(TEXI2DVI) $(PROJECT).texi
+
+replace: timedata.texi
+
+intr.texi: intr.t MVME136_TIMES
+	${REPLACE} -p MVME136_TIMES intr.t
+	mv intr.t.fixed intr.texi
+
+timetbl.t: ../common/timetbl.t
+	sed -e 's/TIMETABLE_NEXT_LINK/Command and Variable Index/' \
+            <../common/timetbl.t >timetbl.t
+
+timetbl.texi: timetbl.t MVME136_TIMES
+	${REPLACE} -p MVME136_TIMES timetbl.t
+	mv timetbl.t.fixed timetbl.texi
+
+timedata.texi: timedata.t MVME136_TIMES
+	${REPLACE} -p MVME136_TIMES timedata.t
+	mv timedata.t.fixed timedata.texi
+
+wksheets.t: ../common/wksheets.t
+	sed -e 's/WORKSHEETS_PREVIOUS_LINK/Processor Dependent Information Table CPU Dependent Information Table/' \
+            -e 's/WORKSHEETS_NEXT_LINK/MC68020 Timing Data/' \
+            <../common/wksheets.t >wksheets.t
+
+wksheets.texi: wksheets.t MVME136_TIMES
+	${REPLACE} -p MVME136_TIMES wksheets.t
+	mv wksheets.t.fixed wksheets.texi
+
+html: $(FILES)
+	-mkdir $(WWW_INSTALL)/c_m68k
+	$(TEXI2WWW) $(TEXI2WWW_ARGS) -dir $(WWW_INSTALL)/c_$(PROJECT) \
+ 	    $(PROJECT).texi
+
+clean:
+	rm -f *.o $(PROG) *.txt core 
+	rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE)
+	rm -f $(PROJECT) $(PROJECT)-*
+	rm -f c_m68k c_m68k-*
+	rm -f timedata.texi timetbl.texi intr.texi wksheets.texi
+	rm -f timetbl.t wksheets.t
+	rm -f *.fixed _*
diff --git a/doc/supplements/m68k/bsp.t b/doc/supplements/m68k/bsp.t
new file mode 100644
index 0000000000..60c889c495
--- /dev/null
+++ b/doc/supplements/m68k/bsp.t
@@ -0,0 +1,110 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top
+@end ifinfo
+@chapter Board Support Packages
+@ifinfo
+@menu
+* Board Support Packages Introduction::
+* Board Support Packages System Reset::
+* Board Support Packages Processor Initialization::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages
+@end ifinfo
+@section Introduction
+
+An RTEMS Board Support Package (BSP) must be designed
+to support a particular processor and target board combination.
+This chapter presents a discussion of MC68020 specific BSP
+issues.   For more information on developing a BSP, refer to the
+chapter titled Board Support Packages in the RTEMS C
+Applications User's Guide.
+
+@ifinfo
+@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages
+@end ifinfo
+@section System Reset
+
+An RTEMS based application is initiated or
+re-initiated when the MC68020 processor is reset.  When the
+MC68020 is reset, the processor performs the following actions:
+
+@itemize @bullet
+@item The tracing bits of the status register are cleared to
+disable tracing.
+
+@item The supervisor interrupt state is entered by setting the
+supervisor (S) bit and clearing the master/interrupt (M) bit of
+the status register.
+
+@item The interrupt mask of the status register is set to
+level 7 to effectively disable all maskable interrupts.
+
+@item The vector base register (VBR) is set to zero.
+
+@item The cache control register (CACR) is set to zero to
+disable and freeze the processor cache.
+
+@item The interrupt stack pointer (ISP) is set to the value
+stored at vector 0 (bytes 0-3) of the exception vector table
+(EVT).
+
+@item The program counter (PC) is set to the value stored at
+vector 1 (bytes 4-7) of the EVT.
+
+@item The processor begins execution at the address stored in
+the PC.
+@end itemize
+
+@ifinfo
+@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
+@end ifinfo
+@section Processor Initialization
+
+The address of the application's initialization code
+should be stored in the first vector of the EVT which will allow
+the immediate vectoring to the application code.  If the
+application requires that the VBR be some value besides zero,
+then it should be set to the required value at this point.  All
+tasks share the same MC68020's VBR value.  Because interrupts
+are enabled automatically by RTEMS as part of the initialize
+executive directive, the VBR MUST be set before this directive
+is invoked to insure correct interrupt vectoring.  If processor
+caching is to be utilized, then it should be enabled during the
+reset application initialization code.
+
+In addition to the requirements described in the
+Board Support Packages chapter of the C Applications User's
+Manual for the reset code which is executed before the call to
+initialize executive, the MC68020 version has the following
+specific requirements:
+
+@itemize @bullet
+@item Must leave the S bit of the status register set so that
+the MC68020 remains in the supervisor state.
+
+@item Must set the M bit of the status register to remove the
+MC68020 from the interrupt state.
+
+@item Must set the master stack pointer (MSP) such that a
+minimum stack size of MINIMUM_STACK_SIZE bytes is provided for
+the initialize executive directive.
+
+@item Must initialize the MC68020's vector table.
+@end itemize
+
+Note that the BSP is not responsible for allocating
+or installing the interrupt stack.  RTEMS does this
+automatically as part of initialization.  If the BSP does not
+install an interrupt stack and -- for whatever reason -- an
+interrupt occurs before initialize_executive is invoked, then
+the results are unpredictable.
+
diff --git a/doc/supplements/m68k/callconv.t b/doc/supplements/m68k/callconv.t
new file mode 100644
index 0000000000..2bcc2188fa
--- /dev/null
+++ b/doc/supplements/m68k/callconv.t
@@ -0,0 +1,121 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Extend Byte to Long Instruction, Top
+@end ifinfo
+@chapter Calling Conventions
+@ifinfo
+@menu
+* Calling Conventions Introduction::
+* Calling Conventions Processor Background::
+* Calling Conventions Calling Mechanism::
+* Calling Conventions Register Usage::
+* Calling Conventions Parameter Passing::
+* Calling Conventions User-Provided Routines::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions
+@end ifinfo
+@section Introduction
+
+Each high-level language compiler generates
+subroutine entry and exit code based upon a set of rules known
+as the compiler's calling convention.   These rules address the
+following issues:
+
+@itemize @bullet
+@item register preservation and usage
+@item parameter passing
+@item call and return mechanism
+@end itemize
+
+A compiler's calling convention is of importance when
+interfacing to subroutines written in another language either
+assembly or high-level.  Even when the high-level language and
+target processor are the same, different compilers may use
+different calling conventions.  As a result, calling conventions
+are both processor and compiler dependent.
+
+@ifinfo
+@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions
+@end ifinfo
+@section Processor Background
+
+The MC68xxx architecture supports a simple yet
+effective call and return mechanism.  A subroutine is invoked
+via the branch to subroutine (bsr) or the jump to subroutine
+(jsr) instructions.  These instructions push the return address
+on the current stack.  The return from subroutine (rts)
+instruction pops the return address off the current stack and
+transfers control to that instruction.  It is is important to
+note that the MC68xxx call and return mechanism does not
+automatically save or restore any registers.  It is the
+responsibility of the high-level language compiler to define the
+register preservation and usage convention.
+
+@ifinfo
+@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions
+@end ifinfo
+@section Calling Mechanism
+
+All RTEMS directives are invoked using either a bsr
+or jsr instruction and return to the user application via the
+rts instruction.
+
+@ifinfo
+@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
+@end ifinfo
+@section Register Usage
+
+As discussed above, the bsr and jsr instructions do
+not automatically save any registers.  RTEMS uses the registers
+D0, D1, A0, and A1 as scratch registers.  These registers are
+not preserved by RTEMS directives therefore, the contents of
+these registers should not be assumed upon return from any RTEMS
+directive.
+
+@ifinfo
+@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
+@end ifinfo
+@section Parameter Passing
+
+RTEMS assumes that arguments are placed on the
+current stack before the directive is invoked via the bsr or jsr
+instruction.  The first argument is assumed to be closest to the
+return address on the stack.  This means that the first argument
+of the C calling sequence is pushed last.  The following
+pseudo-code illustrates the typical sequence used to call a
+RTEMS directive with three (3) arguments:
+
+@example
+@group
+push third argument
+push second argument
+push first argument
+invoke directive
+remove arguments from the stack
+@end group
+@end example
+
+The arguments to RTEMS are typically pushed onto the
+stack using a move instruction with a pre-decremented stack
+pointer as the destination.  These arguments must be removed
+from the stack after control is returned to the caller.  This
+removal is typically accomplished by adding the size of the
+argument list in bytes to the current stack pointer.
+
+@ifinfo
+@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions
+@end ifinfo
+@section User-Provided Routines
+
+All user-provided routines invoked by RTEMS, such as
+user extensions, device drivers, and MPCI routines, must also
+adhere to these calling conventions.
+
diff --git a/doc/supplements/m68k/cpumodel.t b/doc/supplements/m68k/cpumodel.t
new file mode 100644
index 0000000000..becfcf123d
--- /dev/null
+++ b/doc/supplements/m68k/cpumodel.t
@@ -0,0 +1,128 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top
+@end ifinfo
+@chapter CPU Model Dependent Features
+@ifinfo
+@menu
+* CPU Model Dependent Features Introduction::
+* CPU Model Dependent Features CPU Model Name::
+* CPU Model Dependent Features Floating Point Unit::
+* CPU Model Dependent Features BFFFO Instruction::
+* CPU Model Dependent Features Vector Base Register::
+* CPU Model Dependent Features Separate Stacks::
+* CPU Model Dependent Features Pre-Indexing Address Mode::
+* CPU Model Dependent Features Extend Byte to Long Instruction::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features, CPU Model Dependent Features
+@end ifinfo
+@section Introduction
+
+Microprocessors are generally classified into
+families with a variety of CPU models or implementations within
+that family.  Within a processor family, there is a high level
+of binary compatibility.  This family may be based on either an
+architectural specification or on maintaining compatibility with
+a popular processor.  Recent microprocessor families such as the
+SPARC or PA-RISC are based on an architectural specification
+which is independent or any particular CPU model or
+implementation.  Older families such as the M68xxx and the iX86
+evolved as the manufacturer strived to produce higher
+performance processor models which maintained binary
+compatibility with older models.
+
+RTEMS takes advantage of the similarity of the
+various models within a CPU family.  Although the models do vary
+in significant ways, the high level of compatibility makes it
+possible to share the bulk of the CPU dependent executive code
+across the entire family.  Each processor family supported by
+RTEMS has a list of features which vary between CPU models
+within a family.  For example, the most common model dependent
+feature regardless of CPU family is the presence or absence of a
+floating point unit or coprocessor.  When defining the list of
+features present on a particular CPU model, one simply notes
+that floating point hardware is or is not present and defines a
+single constant appropriately.  Conditional compilation is
+utilized to include the appropriate source code for this CPU
+model's feature set.  It is important to note that this means
+that RTEMS is thus compiled using the appropriate feature set
+and compilation flags optimal for this CPU model used.  The
+alternative would be to generate a binary which would execute on
+all family members using only the features which were always
+present.
+
+This chapter presents the set of features which vary
+across SPARC implementations and are of importance to RTEMS.
+The set of CPU model feature macros are defined in the file
+c/src/exec/score/cpu/m68k/m68k.h based upon the particular CPU
+model defined on the compilation command line.
+
+@ifinfo
+@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Introduction, CPU Model Dependent Features
+@end ifinfo
+@section CPU Model Name
+
+The macro CPU_MODEL_NAME is a string which designates
+the name of this CPU model.  For example, for the MC68020
+processor, this macro is set to the string "mc68020".
+
+@ifinfo
+@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features
+@end ifinfo
+@section Floating Point Unit
+
+The macro M68K_HAS_FPU is set to 1 to indicate that
+this CPU model has a hardware floating point unit and 0
+otherwise.  It does not matter whether the hardware floating
+point support is incorporated on-chip or is an external
+coprocessor.
+
+@ifinfo
+@node CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features
+@end ifinfo
+@section BFFFO Instruction
+
+The macro M68K_HAS_BFFFO is set to 1 to indicate that
+this CPU model has the bfffo instruction.
+
+@ifinfo
+@node CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features
+@end ifinfo
+@section Vector Base Register
+
+The macro M68K_HAS_VBR is set to 1 to indicate that
+this CPU model has a vector base register (vbr).
+
+@ifinfo
+@node CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features
+@end ifinfo
+@section Separate Stacks
+
+The macro M68K_HAS_SEPARATE_STACKS is set to 1 to
+indicate that this CPU model has separate interrupt, user, and
+supervisor mode stacks.
+
+@ifinfo
+@node CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features Extend Byte to Long Instruction, CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features
+@end ifinfo
+@section Pre-Indexing Address Mode
+
+The macro M68K_HAS_PREINDEXING is set to 1 to indicate that
+this CPU model has the pre-indexing address mode.
+
+@ifinfo
+@node CPU Model Dependent Features Extend Byte to Long Instruction, Calling Conventions, CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features
+@end ifinfo
+@section Extend Byte to Long Instruction
+ 
+The macro M68K_HAS_EXTB_L is set to 1 to indicate that this CPU model 
+has the extb.l instruction.  This instruction is supposed to be available
+in all models based on the cpu32 core as well as mc68020 and up models.
diff --git a/doc/supplements/m68k/cputable.t b/doc/supplements/m68k/cputable.t
new file mode 100644
index 0000000000..0119084d32
--- /dev/null
+++ b/doc/supplements/m68k/cputable.t
@@ -0,0 +1,118 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top
+@end ifinfo
+@chapter  Processor Dependent Information Table
+@ifinfo
+@menu
+* Processor Dependent Information Table Introduction::
+* Processor Dependent Information Table CPU Dependent Information Table::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table
+@end ifinfo
+@section Introduction
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table.  This table is not required for all
+processors supported by RTEMS.  This chapter describes the
+contents, if any, for a particular processor type.
+
+@ifinfo
+@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table
+@end ifinfo
+@section CPU Dependent Information Table
+
+The MC68xxx version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the MC68xxx.  This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP.  The C structure definition is given
+here:
+
+@example
+@group
+struct cpu_configuration_table @{
+  void       (*pretasking_hook)( void );
+  void       (*predriver_hook)( void );
+  void       (*postdriver_hook)( void );
+  void       (*idle_task)( void );
+  boolean      do_zero_of_workspace;
+  unsigned32   interrupt_stack_size;
+  unsigned32   extra_mpci_receive_server_stack;
+  void *     (*stack_allocate_hook)( unsigned32 );
+  void       (*stack_free_hook)( void* );
+  /* end of fields required on all CPUs */
+
+  m68k_isr    *interrupt_vector_table;
+@};
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the
+user provided routine which is invoked once RTEMS initialization
+is complete but before interrupts and tasking are enabled.  This
+field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine which is invoked with tasking enabled immediately before
+the MPCI and device drivers are initialized. RTEMS
+initialization is complete, interrupts and tasking are enabled,
+but no device drivers are initialized.  This field may be NULL to
+indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine which is invoked with tasking enabled immediately after
+the MPCI and device drivers are initialized. RTEMS
+initialization is complete, interrupts and tasking are enabled,
+and the device drivers are initialized.  This field may be NULL
+to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task.  If
+this field is not NULL, then the RTEMS default IDLE task is not
+used.  This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization.  If set to
+TRUE, the Workspace is zeroed.  Otherwise, it is not.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes.  This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes.  The MPCI receive server may invoke nearly all directives and 
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates 
+memory for task stacks.  If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees 
+memory for task stacks.  If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item interrupt_vector_table
+is the base address of the CPU's Exception Vector Table.
+
+@end table
diff --git a/doc/supplements/m68k/fatalerr.t b/doc/supplements/m68k/fatalerr.t
new file mode 100644
index 0000000000..5b94c7a9c9
--- /dev/null
+++ b/doc/supplements/m68k/fatalerr.t
@@ -0,0 +1,44 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top
+@end ifinfo
+@chapter Default Fatal Error Processing
+@ifinfo
+@menu
+* Default Fatal Error Processing Introduction::
+* Default Fatal Error Processing Default Fatal Error Handler Operations::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing
+@end ifinfo
+@section Introduction
+
+Upon detection of a fatal error by either the
+application or RTEMS the fatal error manager is invoked.  The
+fatal error manager will invoke the user-supplied fatal error
+handlers.  If no user-supplied handlers are configured,  the
+RTEMS provided default fatal error handler is invoked.  If the
+user-supplied fatal error handlers return to the executive the
+default fatal error handler is then invoked.  This chapter
+describes the precise operations of the default fatal error
+handler.
+
+@ifinfo
+@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing
+@end ifinfo
+@section Default Fatal Error Handler Operations
+
+The default fatal error handler which is invoked by
+the fatal_error_occurred directive when there is no user handler
+configured or the user handler returns control to RTEMS.  The
+default fatal error handler disables processor interrupts to
+level 7, places the error code in D0, and executes a stop
+instruction to simulate a halt processor instruction.
+
diff --git a/doc/supplements/m68k/intr_NOTIMES.t b/doc/supplements/m68k/intr_NOTIMES.t
new file mode 100644
index 0000000000..07e51b0116
--- /dev/null
+++ b/doc/supplements/m68k/intr_NOTIMES.t
@@ -0,0 +1,230 @@
+@c
+@c
+@c  Interrupt Stack Frame Picture
+@c
+
+@ifinfo
+@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
+@end ifinfo
+@chapter Interrupt Processing
+@ifinfo
+@menu
+* Interrupt Processing Introduction::
+* Interrupt Processing Vectoring of an Interrupt Handler::
+* Interrupt Processing Interrupt Levels::
+* Interrupt Processing Disabling of Interrupts by RTEMS::
+* Interrupt Processing Interrupt Stack::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node Interrupt Processing Introduction, Interrupt Processing Vectoring of an Interrupt Handler, Interrupt Processing, Interrupt Processing
+@end ifinfo
+@section Introduction
+
+Different types of processors respond to the
+occurrence of an interrupt in its own unique fashion. In
+addition, each processor type provides a control mechanism to
+allow for the proper handling of an interrupt.  The processor
+dependent response to the interrupt modifies the current
+execution state and results in a change in the execution stream.
+Most processors require that an interrupt handler utilize some
+special control mechanisms to return to the normal processing
+stream.  Although RTEMS hides many of the processor dependent
+details of interrupt processing, it is important to understand
+how the RTEMS interrupt manager is mapped onto the processor's
+unique architecture. Discussed in this chapter are the MC68xxx's
+interrupt response and control mechanisms as they pertain to
+RTEMS.
+
+@ifinfo
+@node Interrupt Processing Vectoring of an Interrupt Handler, Models Without Separate Interrupt Stacks, Interrupt Processing Introduction, Interrupt Processing
+@end ifinfo
+@section Vectoring of an Interrupt Handler
+@ifinfo
+@menu
+* Models Without Separate Interrupt Stacks::
+* Models With Separate Interrupt Stacks::
+@end menu
+@end ifinfo
+
+Depending on whether or not the particular CPU
+supports a separate interrupt stack, the MC68xxx family has two
+different interrupt handling models.
+
+@ifinfo
+@node Models Without Separate Interrupt Stacks, Models With Separate Interrupt Stacks, Interrupt Processing Vectoring of an Interrupt Handler, Interrupt Processing Vectoring of an Interrupt Handler
+@end ifinfo
+@subsection Models Without Separate Interrupt Stacks
+
+Upon receipt of an interrupt the MC68xxx family
+members without separate interrupt stacks automatically perform
+the following actions:
+
+@itemize @bullet
+@item To Be Written
+@end itemize
+
+@ifinfo
+@node Models With Separate Interrupt Stacks, Interrupt Processing Interrupt Levels, Models Without Separate Interrupt Stacks, Interrupt Processing Vectoring of an Interrupt Handler
+@end ifinfo
+@subsection Models With Separate Interrupt Stacks
+
+Upon receipt of an interrupt the MC68xxx family
+members with separate interrupt stacks automatically perform the
+following actions:
+
+@itemize @bullet
+@item saves the current status register (SR),
+
+@item clears the master/interrupt (M) bit of the SR to
+indicate the switch from master state to interrupt state,
+
+@item sets the privilege mode to supervisor,
+
+@item suppresses tracing,
+
+@item sets the interrupt mask level equal to the level of the
+interrupt being serviced,
+
+@item pushes an interrupt stack frame (ISF), which includes
+the program counter (PC), the status register (SR), and the
+format/exception vector offset (FVO) word, onto the supervisor
+and interrupt stacks,
+
+@item switches the current stack to the interrupt stack and
+vectors to an interrupt service routine (ISR).  If the ISR was
+installed with the interrupt_catch directive, then the RTEMS
+interrupt handler will begin execution.  The RTEMS interrupt
+handler saves all registers which are not preserved according to
+the calling conventions and invokes the application's ISR.
+@end itemize
+
+A nested interrupt is processed similarly by these
+CPU models with the exception that only a single ISF is placed
+on the interrupt stack and the current stack need not be
+switched.
+
+The FVO word in the Interrupt Stack Frame is examined
+by RTEMS to determine when an outer most interrupt is being
+exited. Since the FVO is used by RTEMS for this purpose, the
+user application code MUST NOT modify this field.
+
+The following shows the Interrupt Stack Frame for
+MC68xxx CPU models with separate interrupt stacks:
+
+@ifset use-ascii
+@example
+@group
+               +----------------------+
+               |    Status Register   | 0x0
+               +----------------------+    
+               | Program Counter High | 0x2
+               +----------------------+    
+               | Program Counter Low  | 0x4
+               +----------------------+    
+               | Format/Vector Offset | 0x6
+               +----------------------+    
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\strut\vrule#&
+\hbox to 2.00in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 0.50in{\enskip\hfil#\hfil}
+\cr
+\multispan{3}\hrulefill\cr
+& Status Register && 0x0\cr
+\multispan{3}\hrulefill\cr
+& Program Counter High && 0x2\cr
+\multispan{3}\hrulefill\cr
+& Program Counter Low && 0x4\cr
+\multispan{3}\hrulefill\cr
+& Format/Vector Offset && 0x6\cr
+\multispan{3}\hrulefill\cr
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=2 WIDTH="40%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD>
+    <TD ALIGN=center>0x0</TD></TR>
+<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD>
+    <TD ALIGN=center>0x2</TD></TR>
+<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD>
+    <TD ALIGN=center>0x4</TD></TR>
+<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD>
+    <TD ALIGN=center>0x6</TD></TR>
+  </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+@ifinfo
+@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Models With Separate Interrupt Stacks, Interrupt Processing
+@end ifinfo
+@section Interrupt Levels
+
+Eight levels (0-7) of interrupt priorities are
+supported by MC68xxx family members with level seven (7) being
+the highest priority.  Level zero (0) indicates that interrupts
+are fully enabled.  Interrupt requests for interrupts with
+priorities less than or equal to the current interrupt mask
+level are ignored.
+
+Although RTEMS supports 256 interrupt levels, the
+MC68xxx family only supports eight.  RTEMS interrupt levels 0
+through 7 directly correspond to MC68xxx interrupt levels.  All
+other RTEMS interrupt levels are undefined and their behavior is
+unpredictable.
+
+@ifinfo
+@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
+@end ifinfo
+@section Disabling of Interrupts by RTEMS
+
+During the execution of directive calls, critical
+sections of code may be executed.  When these sections are
+encountered, RTEMS disables interrupts to level seven (7) before
+the execution of this section and restores them to the previous
+level upon completion of the section.  RTEMS has been optimized
+to insure that interrupts are disabled for less than 
+RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz MC68020 with 
+zero wait states.  These numbers will vary based the 
+number of wait states and processor speed present on the target board.
+[NOTE:  The maximum period with interrupts disabled is hand calculated.  This
+calculation was last performed for Release 
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+Non-maskable interrupts (NMI) cannot be disabled, and
+ISRs which execute at this level MUST NEVER issue RTEMS system
+calls.  If a directive is invoked, unpredictable results may
+occur due to the inability of RTEMS to protect its critical
+sections.  However, ISRs that make no system calls may safely
+execute as non-maskable interrupts.
+
+@ifinfo
+@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
+@end ifinfo
+@section Interrupt Stack
+
+RTEMS allocates the interrupt stack from the
+Workspace Area.  The amount of memory allocated for the
+interrupt stack is determined by the interrupt_stack_size field
+in the CPU Configuration Table.  During the initialization
+process, RTEMS will install its interrupt stack.
+
+The MC68xxx port of RTEMS supports a software managed
+dedicated interrupt stack on those CPU models which do not
+support a separate interrupt stack in hardware.
+
+
diff --git a/doc/supplements/m68k/m68k.texi b/doc/supplements/m68k/m68k.texi
new file mode 100644
index 0000000000..157dabb594
--- /dev/null
+++ b/doc/supplements/m68k/m68k.texi
@@ -0,0 +1,118 @@
+\input ../texinfo/texinfo   @c -*-texinfo-*-
+@c %**start of header
+@setfilename c_m68k
+@syncodeindex vr fn
+@synindex ky cp
+@paragraphindent 0
+@c @smallbook
+@c %**end of header
+
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@c
+@c   Master file for the Motorola MC68xxx C Applications Supplement
+@c
+
+@include ../common/setup.texi
+
+@ignore
+@ifinfo
+@format
+START-INFO-DIR-ENTRY
+* RTEMS Motorola MC68xxx C Applications Supplement (m68k):
+END-INFO-DIR-ENTRY
+@end format
+@end ifinfo
+@end ignore
+
+@c
+@c  Title Page Stuff
+@c
+
+@set edition 4.0.0a
+@set update-date 25 April 1997
+@set update-month April 1997
+
+@c
+@c  I don't really like having a short title page.  --joel
+@c
+@c @shorttitlepage RTEMS Motorola MC68xxx C Applications Supplement 
+
+@setchapternewpage odd
+@settitle RTEMS Motorola MC68xxx C Applications Supplement 
+@titlepage
+@finalout
+
+@title RTEMS Motorola MC68xxx C Supplement 
+@subtitle Edition @value{edition}, for RTEMS 4.0.0
+@sp 1
+@subtitle @value{update-month}
+@author On-Line Applications Research Corporation
+@page
+
+@include ../common/cpright.texi
+@end titlepage
+
+@c  This prevents a black box from being printed on "overflow" lines.
+@c  The alternative is to rework a sentence to avoid this problem.
+
+@include preface.texi
+@include cpumodel.texi
+@include callconv.texi
+@include memmodel.texi
+@include intr.texi
+@include fatalerr.texi
+@include bsp.texi
+@include cputable.texi
+@include wksheets.texi
+@include ../common/timing.texi
+@include timedata.texi
+@ifinfo
+@node Top, Preface, (dir), (dir)
+@top c_m68k
+
+This is the online version of the RTEMS Motorola MC68xxx C 
+Applications Supplement.
+
+@menu
+* Preface::
+* CPU Model Dependent Features::
+* Calling Conventions::
+* Memory Model::
+* Interrupt Processing::
+* Default Fatal Error Processing::
+* Board Support Packages::
+* Processor Dependent Information Table::
+* Memory Requirements::
+* Timing Specification::
+* MC68020 Timing Data::
+* Command and Variable Index::
+* Concept Index::
+@end menu
+
+@end ifinfo
+@c 
+@c 
+@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
+@c
+
+@node Command and Variable Index, Concept Index, MC68020 Timing Data Rate Monotonic Manager, Top
+@unnumbered Command and Variable Index
+
+There are currently no Command and Variable Index entries.
+
+@c @printindex fn
+
+@node Concept Index, , Command and Variable Index, Top
+@unnumbered Concept Index
+
+There are currently no Concept Index entries.
+@c @printindex cp
+
+@c @contents
+@bye
+
diff --git a/doc/supplements/m68k/memmodel.t b/doc/supplements/m68k/memmodel.t
new file mode 100644
index 0000000000..91ccf8010d
--- /dev/null
+++ b/doc/supplements/m68k/memmodel.t
@@ -0,0 +1,52 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top
+@end ifinfo
+@chapter Memory Model
+@ifinfo
+@menu
+* Memory Model Introduction::
+* Memory Model Flat Memory Model::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model
+@end ifinfo
+@section Introduction
+
+A processor may support any combination of memory
+models ranging from pure physical addressing to complex demand
+paged virtual memory systems.  RTEMS supports a flat memory
+model which ranges contiguously over the processor's allowable
+address space.  RTEMS does not support segmentation or virtual
+memory of any kind.  The appropriate memory model for RTEMS
+provided by the targeted processor and related characteristics
+of that model are described in this chapter.
+
+@ifinfo
+@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model
+@end ifinfo
+@section Flat Memory Model
+
+The MC68xxx family supports a flat 32-bit address
+space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
+gigabytes).  Each address is represented by a 32-bit value and
+is byte addressable.  The address may be used to reference a
+single byte, word (2-bytes), or long word (4 bytes).  Memory
+accesses within this address space are performed in big endian
+fashion by the processors in this family.
+
+Some of the MC68xxx family members such as the
+MC68020, MC68030, and MC68040 support virtual memory and
+segmentation.  The MC68020 requires external hardware support
+such as the MC68851 Paged Memory Management Unit coprocessor
+which is typically used to perform address translations for
+these systems.  RTEMS does not support virtual memory or
+segmentation on any of the MC68xxx family members.
+
diff --git a/doc/supplements/m68k/preface.texi b/doc/supplements/m68k/preface.texi
new file mode 100644
index 0000000000..e42754c347
--- /dev/null
+++ b/doc/supplements/m68k/preface.texi
@@ -0,0 +1,58 @@
+@c
+@c  COPYRIGHT (c) 1988-1996.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+
+@ifinfo
+@node Preface, CPU Model Dependent Features, Top, Top
+@end ifinfo
+@unnumbered Preface
+
+The Real Time Executive for Multiprocessor Systems (RTEMS)
+is designed to be portable across multiple processor
+architectures.  However, the nature of real-time systems makes
+it essential that the application designer understand certain
+processor dependent implementation details.  These processor
+dependencies include calling convention, board support package
+issues, interrupt processing, exact RTEMS memory requirements,
+performance data, header files, and the assembly language
+interface to the executive.
+
+This document discusses the Motorola MC68xxx
+architecture dependencies in this port of RTEMS.  The MC68xxx
+family has a wide variety of CPU models within it.  The part
+numbers for these models are generally divided into MC680xx and
+MC683xx.  The MC680xx models are more general purpose processors
+with no integrated peripherals.  The MC683xx models, on the
+other hand, are more specialized and have a variety of
+peripherals on chip including sophisticated timers and serial
+communications controllers.
+
+It is highly recommended that the Motorola MC68xxx
+RTEMS application developer obtain and become familiar with the
+documentation for the processor being used as well as the
+documentation for the family as a whole.
+
+@subheading Architecture Documents
+
+For information on the Motorola MC68xxx architecture,
+refer to the following documents available from Motorola
+(@file{http//www.moto.com/}):
+
+@itemize @bullet
+@item @cite{M68000 Family Reference, Motorola, FR68K/D}.
+@end itemize
+
+@subheading MODEL SPECIFIC DOCUMENTS
+
+For information on specific processor models and
+their associated coprocessors, refer to the following documents:
+
+@itemize  @bullet
+@item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}.
+
+@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's
+Manual, Motorola, MC68881UM/AD}.
+@end itemize
+
diff --git a/doc/supplements/m68k/timeMVME136.t b/doc/supplements/m68k/timeMVME136.t
new file mode 100644
index 0000000000..fe99c38fef
--- /dev/null
+++ b/doc/supplements/m68k/timeMVME136.t
@@ -0,0 +1,143 @@
+
+@include ../common/timemac.texi
+@tex
+\global\advance \smallskipamount by -4pt
+@end tex
+
+@ifinfo
+@node MC68020 Timing Data, MC68020 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
+@end ifinfo
+@chapter MC68020 Timing Data
+@ifinfo
+@menu
+* MC68020 Timing Data Introduction::
+* MC68020 Timing Data Hardware Platform::
+* MC68020 Timing Data Interrupt Latency::
+* MC68020 Timing Data Context Switch::
+* MC68020 Timing Data Directive Times::
+* MC68020 Timing Data Task Manager::
+* MC68020 Timing Data Interrupt Manager::
+* MC68020 Timing Data Clock Manager::
+* MC68020 Timing Data Timer Manager::
+* MC68020 Timing Data Semaphore Manager::
+* MC68020 Timing Data Message Manager::
+* MC68020 Timing Data Event Manager::
+* MC68020 Timing Data Signal Manager::
+* MC68020 Timing Data Partition Manager::
+* MC68020 Timing Data Region Manager::
+* MC68020 Timing Data Dual-Ported Memory Manager::
+* MC68020 Timing Data I/O Manager::
+* MC68020 Timing Data Rate Monotonic Manager::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node MC68020 Timing Data Introduction, MC68020 Timing Data Hardware Platform, MC68020 Timing Data, MC68020 Timing Data
+@end ifinfo
+@section Introduction
+
+The timing data for the MC68020 version of RTEMS is
+provided along with the target dependent aspects concerning the
+gathering of the timing data.  The hardware platform used to
+gather the times is described to give the reader a better
+understanding of each directive time provided.  Also, provided
+is a description of the interrupt latency and the context switch
+times as they pertain to the MC68020 version of RTEMS.
+
+@ifinfo
+@node MC68020 Timing Data Hardware Platform, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Introduction, MC68020 Timing Data
+@end ifinfo
+@section Hardware Platform
+
+All times reported except for the maximum period
+interrupts are disabled by RTEMS were measured using a Motorola
+MVME135 CPU board.  The MVME135 is a 20Mhz board with one wait
+state dynamic memory and a MC68881 numeric coprocessor.  The
+Zilog 8036 countdown timer on this board was used to measure
+elapsed time with a one-half microsecond resolution.  All
+sources of hardware interrupts were disabled, although the
+interrupt level of the MC68020 allows all interrupts.
+
+The maximum period interrupts are disabled was
+measured by summing the number of CPU cycles required by each
+assembly language instruction executed while interrupts were
+disabled.  The worst case times of the MC68020 microprocessor
+were used for each instruction.  Zero wait state memory was
+assumed.  The total CPU cycles executed with interrupts
+disabled, including the instructions to disable and enable
+interrupts, was divided by 20 to simulate a 20Mhz MC68020.  It
+should be noted that the worst case instruction times for the
+MC68020 assume that the internal cache is disabled and that no
+instructions overlap.
+
+@ifinfo
+@node MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Context Switch, MC68020 Timing Data Hardware Platform, MC68020 Timing Data
+@end ifinfo
+@section Interrupt Latency
+
+The maximum period with interrupts disabled within
+RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD 
+microseconds including the instructions
+which disable and re-enable interrupts.  The time required for
+the MC68020 to vector an interrupt and for the RTEMS entry
+overhead before invoking the user's interrupt handler are a
+total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 
+microseconds.  These combine to yield a worst case
+interrupt latency of less than 
+RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 
+microseconds at 20Mhz.  [NOTE:  The maximum period with interrupts
+disabled was last determined for Release 
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+It should be noted again that the maximum period with
+interrupts disabled within RTEMS is hand-timed and based upon
+worst case (i.e. CPU cache disabled and no instruction overlap)
+times for a 20Mhz MC68020.  The interrupt vector and entry
+overhead time was generated on an MVME135 benchmark platform
+using the Multiprocessing Communications registers to generate
+as the interrupt source.
+
+@ifinfo
+@node MC68020 Timing Data Context Switch, MC68020 Timing Data Directive Times, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data
+@end ifinfo
+@section Context Switch
+
+The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
+microseconds on the MVME135 benchmark platform when no floating
+point context is saved or restored.  Additional execution time
+is required when a TASK_SWITCH user extension is configured.
+The use of the TASK_SWITCH extension is application dependent.
+Thus, its execution time is not considered part of the raw
+context switch time.
+
+Since RTEMS was designed specifically for embedded
+missile applications which are floating point intensive, the
+executive is optimized to avoid unnecessarily saving and
+restoring the state of the numeric coprocessor.  The state of
+the numeric coprocessor is only saved when an FLOATING_POINT
+task is dispatched and that task was not the last task to
+utilize the coprocessor.  In a system with only one
+FLOATING_POINT task, the state of the numeric coprocessor will
+never be saved or restored.  When the first FLOATING_POINT task
+is dispatched, RTEMS does not need to save the current state of
+the numeric coprocessor.
+
+The exact amount of time required to save and restore
+floating point context is dependent on whether an MC68881 or
+MC68882 is being used as well as the state of the numeric
+coprocessor.  These numeric coprocessors define three operating
+states: initialized, idle, and busy.  RTEMS places the
+coprocessor in the initialized state when a task is started or
+restarted.  Once the task has utilized the coprocessor, it is in
+the idle state when floating point instructions are not
+executing and the busy state when floating point instructions
+are executing.  The state of the coprocessor is task specific.
+
+The following table summarizes the context switch
+times for the MVME135 benchmark platform:
+
+@include timetbl.texi
+
+@tex
+\global\advance \smallskipamount by 4pt
+@end tex
diff --git a/doc/supplements/m68k/timedata.t b/doc/supplements/m68k/timedata.t
new file mode 100644
index 0000000000..fe99c38fef
--- /dev/null
+++ b/doc/supplements/m68k/timedata.t
@@ -0,0 +1,143 @@
+
+@include ../common/timemac.texi
+@tex
+\global\advance \smallskipamount by -4pt
+@end tex
+
+@ifinfo
+@node MC68020 Timing Data, MC68020 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
+@end ifinfo
+@chapter MC68020 Timing Data
+@ifinfo
+@menu
+* MC68020 Timing Data Introduction::
+* MC68020 Timing Data Hardware Platform::
+* MC68020 Timing Data Interrupt Latency::
+* MC68020 Timing Data Context Switch::
+* MC68020 Timing Data Directive Times::
+* MC68020 Timing Data Task Manager::
+* MC68020 Timing Data Interrupt Manager::
+* MC68020 Timing Data Clock Manager::
+* MC68020 Timing Data Timer Manager::
+* MC68020 Timing Data Semaphore Manager::
+* MC68020 Timing Data Message Manager::
+* MC68020 Timing Data Event Manager::
+* MC68020 Timing Data Signal Manager::
+* MC68020 Timing Data Partition Manager::
+* MC68020 Timing Data Region Manager::
+* MC68020 Timing Data Dual-Ported Memory Manager::
+* MC68020 Timing Data I/O Manager::
+* MC68020 Timing Data Rate Monotonic Manager::
+@end menu
+@end ifinfo
+
+@ifinfo
+@node MC68020 Timing Data Introduction, MC68020 Timing Data Hardware Platform, MC68020 Timing Data, MC68020 Timing Data
+@end ifinfo
+@section Introduction
+
+The timing data for the MC68020 version of RTEMS is
+provided along with the target dependent aspects concerning the
+gathering of the timing data.  The hardware platform used to
+gather the times is described to give the reader a better
+understanding of each directive time provided.  Also, provided
+is a description of the interrupt latency and the context switch
+times as they pertain to the MC68020 version of RTEMS.
+
+@ifinfo
+@node MC68020 Timing Data Hardware Platform, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Introduction, MC68020 Timing Data
+@end ifinfo
+@section Hardware Platform
+
+All times reported except for the maximum period
+interrupts are disabled by RTEMS were measured using a Motorola
+MVME135 CPU board.  The MVME135 is a 20Mhz board with one wait
+state dynamic memory and a MC68881 numeric coprocessor.  The
+Zilog 8036 countdown timer on this board was used to measure
+elapsed time with a one-half microsecond resolution.  All
+sources of hardware interrupts were disabled, although the
+interrupt level of the MC68020 allows all interrupts.
+
+The maximum period interrupts are disabled was
+measured by summing the number of CPU cycles required by each
+assembly language instruction executed while interrupts were
+disabled.  The worst case times of the MC68020 microprocessor
+were used for each instruction.  Zero wait state memory was
+assumed.  The total CPU cycles executed with interrupts
+disabled, including the instructions to disable and enable
+interrupts, was divided by 20 to simulate a 20Mhz MC68020.  It
+should be noted that the worst case instruction times for the
+MC68020 assume that the internal cache is disabled and that no
+instructions overlap.
+
+@ifinfo
+@node MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Context Switch, MC68020 Timing Data Hardware Platform, MC68020 Timing Data
+@end ifinfo
+@section Interrupt Latency
+
+The maximum period with interrupts disabled within
+RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD 
+microseconds including the instructions
+which disable and re-enable interrupts.  The time required for
+the MC68020 to vector an interrupt and for the RTEMS entry
+overhead before invoking the user's interrupt handler are a
+total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 
+microseconds.  These combine to yield a worst case
+interrupt latency of less than 
+RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 
+microseconds at 20Mhz.  [NOTE:  The maximum period with interrupts
+disabled was last determined for Release 
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+It should be noted again that the maximum period with
+interrupts disabled within RTEMS is hand-timed and based upon
+worst case (i.e. CPU cache disabled and no instruction overlap)
+times for a 20Mhz MC68020.  The interrupt vector and entry
+overhead time was generated on an MVME135 benchmark platform
+using the Multiprocessing Communications registers to generate
+as the interrupt source.
+
+@ifinfo
+@node MC68020 Timing Data Context Switch, MC68020 Timing Data Directive Times, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data
+@end ifinfo
+@section Context Switch
+
+The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
+microseconds on the MVME135 benchmark platform when no floating
+point context is saved or restored.  Additional execution time
+is required when a TASK_SWITCH user extension is configured.
+The use of the TASK_SWITCH extension is application dependent.
+Thus, its execution time is not considered part of the raw
+context switch time.
+
+Since RTEMS was designed specifically for embedded
+missile applications which are floating point intensive, the
+executive is optimized to avoid unnecessarily saving and
+restoring the state of the numeric coprocessor.  The state of
+the numeric coprocessor is only saved when an FLOATING_POINT
+task is dispatched and that task was not the last task to
+utilize the coprocessor.  In a system with only one
+FLOATING_POINT task, the state of the numeric coprocessor will
+never be saved or restored.  When the first FLOATING_POINT task
+is dispatched, RTEMS does not need to save the current state of
+the numeric coprocessor.
+
+The exact amount of time required to save and restore
+floating point context is dependent on whether an MC68881 or
+MC68882 is being used as well as the state of the numeric
+coprocessor.  These numeric coprocessors define three operating
+states: initialized, idle, and busy.  RTEMS places the
+coprocessor in the initialized state when a task is started or
+restarted.  Once the task has utilized the coprocessor, it is in
+the idle state when floating point instructions are not
+executing and the busy state when floating point instructions
+are executing.  The state of the coprocessor is task specific.
+
+The following table summarizes the context switch
+times for the MVME135 benchmark platform:
+
+@include timetbl.texi
+
+@tex
+\global\advance \smallskipamount by 4pt
+@end tex