Service Manuals, User Guides, Schematic Diagrams or docs for : xerox mesa 4.0_1978 listing Mesa_4_Microcode Mesa.mu_Sep78
<< Back | HomeMost service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.
Image preview - the first page of the document
>> Download Mesa.mu_Sep78 documenatation <<
Text preview - extract from the document
Mesa.mu 2-Sep-78 17:21:54 Page 1
t
, ,
0 _________________________________________________________________
M E SAM I C ROC 0 D E
Version 34
,
0 ______ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ____________ ,
t
; Mesa.Mu - Instruction fetch and general subroutines
; Last modified by Levin - August 1, 1978 11:27 AM
;Completely rewritten by Roy Levin, Sept-Oct. 1977
;Modified by Johnsson; July 25, 1977 10:20 AM
;First version assembl~d 5 June 1976.
;Developed from Lampson's MESA.U of 21 March 1976.
;-----------------------------------------------------------------
; GLOBAL CONVENTIONS AND ASSUMPTIONS
;-----------------------------------------------------------------
1) Stack representation:
stkp=O a) stack is empty
sktp a 10 =) stack is full
The validity checking that determines if the stack pointer is
within this range is somewhat perfunctory. The approach taken is
to include specific checks only where there absence would not lead
to some catastrophic error. Hence, the stack is not checked for
underflow, since allowing it to become negative will cause a disaster
on the next stack dispatch.
2) Notation:
Instruction labels correspond to opcodes in the obvious way. Suffixes
of A and B (capitalized) refer to alignment in memory. 'A' is intended
to suggest the right-hand byte of a memory word; 'B' is intended to
suggest the left-hand byte. Labels terminating in a lower-case letter
generally name local branch points within a particular group of
opcodes. (Exception: subroutine names.) Labels terminating in 'x' generally
exist only to satisfy alignment requirements imposed by various dispatches
(most commonly IR~ and BIA in instruction fetch).
3) Tasking:
Every effort has been made to ensure that a 'TASK' appears approximately
every 12 instructions. Occasionally, this has not been possible,
but (it is hoped that) violations occur only in infrequently executed
code segments.
4) New symbols:
In a few cases, the definitions of the standard Alto package
(ALTOCONSTS23.MU) have not been quite suitable to the needs of this
microcode. Rather than change the standard package, we have defined
new symbols (with names beginning with 'm') that are to be used instead
of their standard counterparts. All such definitions appear together in
Mesab.Mu.
5) Subroutine returns:
Normally, subroutine returns using IDISP require one to deal with
(the nuisance of) the dispatch caused by loading IR. Happily, however,
no such dispatch occurs for 'msrO' and 'sr1' (the relevant bits
are 0). To cut down on alignment restrictions, some subroutines
assume they are called with only one of two returns and can
therefore ignore the possibility of a pending IR~ dispatch.
Such subroutines are clearly noted in the comments.
6) Frame pointer registers (lp and gp):
These registers normally (i.e. except during Xfer) contain the
addresses of local 2 and global 1, respectively. This optimizes accesses
in such bytecodes as LL3 and SG2, which would otherwise require another cycle.
,
0 ______ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___________ _
; Get definitions for ALTO and MESA
,
0 ______ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___________ _
HMesab.mu;
Mesa.mu 2-Sep-78 17:21:54 Page 2
;-----------------------------------------------------------------
; Location-specific Definitions
._----------------------------------------------------------------
,
There is a fundamental difficulty ;n the selection of addresses that are known and
used outside the Mesa emulator. The problem arises in trying to select a single set of
addresses that can be used regardless of the Alto's control memory configuration. In
effect, this cannot be done. If an Alto has only a RAM (in addition, of course, to its
basic ROM, ROMO) , then the problem does not arise. However, suppose the Alto has both a
RAM and a second ROM, ROM1. Th,n, when it is necessary to move from a control memory to
one of the other two, the choice is conditioned on (1) the memory from which the transfer
is occurring, and (2) bit 1 of the target address. Since we expect that, in most cases, an
Alto running Mesa will have the Mesa emulator in ROM1, the externally-known addresses have
been chosen to work in that case. They will also work, without alteration, on an Alto that
has no ROM1. However, if it is necessary to run Mesa on an Alto with ROM1 and it is desired
to use a Mesa emulator residing in the RAM (say, for debugging purposes), then the address
values in the RAM version must be altered. This implies changes in both the RAM code itself
and the Nova code that invokes the RAM (via the Nova JMPRAM instruction). Details
concerning the necessary changes for re-assembly appear with the definitions below.
%l,1777,O,nextBa; forced to location 0 to save a word in JRAM
------------------------------------------------------------------
,
Emulator Entry Point Definitions
These addresses are known by the Nova code that interfaces to the emulator and by
RAM code executing with the Mesa emulator in ROM1. They have been chosen so that
both such "users" can use the same value. Precisely, this means that bit 1 (the
400 bit) must be set in the address. In a RAM version of the Mesa emulator intended
to execute on an Alto with a second ROM, bit 1 must be zero.
------------------------------------------------------------------
,
%l,1777,420,Mgo; Normal entry to Mesa Emulator - load state
of process specified by ACO.
%l,1777,400,next,nextA; Return to 'next' to continue in current Mesa
process after Nova or RAM execution.
$Minterpret $L004400,O,O; Documentation refers to 'next' this way.
%l,177/,776,DSTrl,Mstopc; Return addresses for 'Savestate'. By
standard convention, 'Mstopc' must be at 777.
Mesa.mu 2-Sep-78 17:21:54 Page 3
._----------------------------------------------------------------
◦ Jabse Service Manual Search 2026 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo