PCDDCProg.mesa
Copyright Ó 1988 by Xerox Corporation. All rights reserved.
Created by Jean Gastinel, December 4, 1987 3:27:45 pm PST
Hoel, May 1, 1988 12:34:27 pm PDT
Hoel, April 8, 1988 8:05:21 pm PDT
This module changes the Atom which contains the program to send the Data
DIRECTORY
Atom, BitOps; 
PCDDCProg: CEDAR PROGRAM
IMPORTS Atom, BitOps
EXPORTS
~ BEGIN
Service Types
QWord: TYPE = ARRAY [0 .. 2) OF CARD;
Service Procs
Q: PROC [c: QWord] RETURNS [rc: REF ANY] = {rc ← NEW[QWord ← c]};
C: PROC [c: CARD] RETURNS [rc: REF ANY] = {rc ← NEW[CARD ← LOOPHOLE[c]]};
B: PROC [c: CARDINAL] RETURNS [rc: REF ANY] = {rc ← NEW[CARDINAL ← c]};
AdDBus: PROC [bd,hyb,Int,ci,pth: CARDINAL 𡤀] RETURNS [ad: CARDINAL 𡤀] ~ {
Address in the DBus is :
<BoardNum:4><HybridNum:4><InterfaceNum:3><ChipNum:2><PathNum:3>
<ChipNum>=0 is for BIC
ad ← BitOps.WShift[bd,12]+BitOps.WShift[hyb,8];
ad ← ad+BitOps.WShift[Int,5]+BitOps.WShift[ci,3]+pth;
};
IdCte: PROC [t,v:CARDINAL] RETURNS [id:CARDINAL] ~ {
The structure of the Identificator is "0101 cccc ccrr rrrr"
cccccc is the Type, rrrrrr is the Version
id ← 5000H + BitOps.WShift[t,6] + v;
};
The Program Starts Here
Atom.PutProp[$PCEmul, $PKList, LIST[
$Init, -- initialize D Bus signals
$ResetOn,
Arbiter, BICs, and DynaBus Exerciser
These chips' DBus register initialization requirements need not be met in this simulation, because these chips are modelled to have plausible default values for these registers. (Right?)
Memory Controller
LIST[$SendDBusAddress, B[AdDBus[bd:1, hyb:4, Int:0, ci:1,pth:0]]], -- chipID
LIST[$ReadDBusAndCheck, C[IdCte[t:6, v:0]], B[16]],
LIST[$SendDBusAddress, B[AdDBus[bd:1,hyb:4,Int:0,ci:1,pth:1]]], -- devID
LIST[$SendDBusData, C[1], B[10]], -- devID = 1
LIST[$SendDBusAddress, B[AdDBus[bd:1,hyb:4,Int:0,ci:1,pth:0]]], -- chipID
Display Controller
LIST[$SendDBusAddress, B[AdDBus[bd:0, hyb:2, Int:0, ci:1, pth:0]]], -- chipID
LIST[$ReadDBusAndCheck, C[IdCte[t:8, v:0]], B[16]],
LIST[$SendDBusAddress, B[AdDBus[bd:0, hyb:2, Int:0, ci:1, pth:1]]], -- devID
LIST[$SendDBusData, C[2], B[10]], -- devID = 2
LIST[$SendDBusAddress, B[AdDBus[bd:0, hyb:2, Int:0, ci:1, pth:2]]], -- params
LIST[$SendDBusData, C[ 5], B[ 5]], -- intAction.reason
LIST[$SendDBusData, C[ 0], B[ 1]], -- intAction.broadcast
LIST[$SendDBusData, C[ 0], B[10]], -- intAction.intDevID
LIST[$SendDBusData, C[7FH], B[ 7]], -- criticalMask
LIST[$SendDBusData, C[ 2], B[ 3]], -- maxOARHP
LIST[$SendDBusData, C[ 2], B[ 3]], -- maxOARLP
LIST[$SendDBusData, C[ 3], B[ 5]], -- maxORBR
LIST[$SendDBusAddress, B[AdDBus[bd:0, hyb:2, Int:0, ci:1, pth:4]]], -- unused
  -- avoid harmful effects of DShiftCK glitch; 5-1-88.
$ResetOff,  -- after this, the D Bus is no longer used.
$Nop,
LIST[$Jump,$Nop],
]];
END.
Notes:
1. For specification of DBus physical address of DDC for this simulation, see:
[Dragon]<Dragon7.0>SS>GenFullBDDBus0Impl.mesa.
2. For specification of the DevID's of the chips used for this simulation, see:
***** (Jean says memCtl=0, dynExerciser=1, DDC=2, ....)
4-22-88: (Jean now says dynExerciser=0, memCtl=1, DDC=2, ....)
3. For more information on what the atoms in the program list do, see:
[Dragon]<Dragon7.0>SS>PCEmulImpl.mesa.
4. The parameters are the way they are because:
 intAction.reason: arbitrary choice; coordinate with [5].
 intAction.broadcast: arbitrary choice; coordinate with [5].
 intAction.DevID: see [2].
 criticalMask: to get to low priority ASAP.
 maxOARHP:  infinity (not testing this limit).
 maxOARLP:  infinity (not testing this limit).
 maxORBR:  infinity(not testing this limit).
5. For specification of the DynaBus transactions used to test DDC in this simulation, see:
[Dragon]<Dragon7.0>SSDDC>DynDDCProg.mesa.
6. This file is stored as a part of:
[Dragon]<Dragon7.0>Top>SSDDC.df
---------------------
Change Log
4-24-88: Changed MemCtl devID to 1, dynExerciser devID to 0, per Jean.
4-24-88: Uncommented the last line of MemCtl initialization, which sets the DBus path to 0, hoping to avoid lots of X's in the Rosemary mumble viewer.
5-1-88: bug fix: intDeviceID=0 (DynEx), not 2 (DDC).