*start*
01700 00024 US 
Date: 3 March 1982 2:19 pm PST (Wednesday)
From: TonyWest.PA
Subject: Dandelion CS enhancements
To: Mott
cc: TonyWest

Tim:

It was suggested that I make Versatec aware that we (CSL) are planning to build two new bits of hardware which you might be interested in and should be aware of.  I am not sure if you are the right person to contact, but perhaps you could forward this message if not.

1. A new version of the Dandelion CPU with a 16K Writable control store.  The major purpose of this is to enable CEDAR to run on DLions.  This takes the current CP design and adds a 2-bit bank register.  Inter-bank jumps are arranged with appropriate microinstructions.  No other microcode changes are envisaged,  and the system will run all the standard microcode UNCHANGED (ie. on power-up, the bank register is reset to make the machine look like a 4K machine).  The microassembler and Burdock diagnostic tools will be upgraded accordingly.  Please join DLionCS^.pa if you are interested.

2. A cut-down version of the DLion CPU with tasking ripped out, interrupt support added, and engineered to fit on an Intel Multibus card.  The major purpose of this is to be able to build cheap Ethernet gateways (initially).  The intent is that one will be able to put together inexpensive Multibus hardware which runs MESA.  Please join Multibus^.pa if you are interested, as well as letting me know so I can pass your interest on.

Both of these things will happen rather shortly, with prototypes within 2 months (I think).

I still have it on my list of things to do to come down to Versatec to get an idea of what is going on in your organisation,  I hope that can happen soon.

Tony

*start*
00696 00024 US 
Date:  3-Mar-82 15:23:42 PST (Wednesday)
From: Israel.pa
Subject: Re: I am back again
In-reply-to: TonyWest's message of 3 March 1982 2:37 pm PST (Wednesday)
To: TonyWest

Tony,

Since we keep missing each other by phone, here's what the call was about.

I'm interested in the availability of Extended DLion Control Store.  SDD Advanced Develpment would like 4-8 units, to be used in advanced graphics and voice applications.  Do you have plans to build some of these?  What's the transfer cost estimate?  What about schedule?  Is there a commitment from somebody to upgrade the assembler and debugger?  How do I get on the list of recipients?

Thanks for your help,
Jay.
*start*
00615 00024 US 
Date: 27 Feb. 1982 10:15 am EST (Saturday)
From: DMurray.WBST
Subject: 16K microstore for the Dandelion
To: TonyWest.PA
cc: DMurray

Tony, I'm definitely interested in the DLion16K microstore for experimenting
with Mesa compatible print servers.   What else do you need to know.

Via grapevine, I thought you and Swinehart were working the Multi-bus scene
for EtherPhone.  16K MC store for DLion????   What else??

My group has been poking around with software and electronics for printing for
some time.  Believe you know Jim Baroody and perhaps have messaged a bit
with Henk Keesom.

Dan

*start*
02295 00024 US 
Date: 9 March 1982 4:29 pm PST (Tuesday)
From: AKTsang.pa
Subject: CP Drawings
To: TonyWest.PA
cc: Garner, Ogus, AKTsang

Tony:

Sorry for the late response.

The SW drawings in [Iris]<Workstation>LH>LionHead-N.dm are at the same level
as LionHead-G.dm in the same directory.   The p* drawings in LionHead-N.dm
are the latest PC version drawings for CPi.  LionHead-G.dm is the last SW
version of CPi available.

Based on your application, I think the best way to do is to start with the files in
[Iris]<AKTsang>CPii>CPii-D.dm.  These SW drawings are for CPii and they have
been updated to the same level as LionHead-N.dm, except the following:

1.	Control store is implemented with 4K x 4 chips (IMS1420) rather with 4K x
1 chips (i2147).  See pp.17-22.
 
2.	CPii SW uses a different scheme to terminate the control store address
lines than the one used in CPi SW.   Series terminating resistor values are
different.  (p.27)

3.	There is no output buffer for SU-Regs in CPii SW version (p.3).  The
74S241 buffers were added to CPi PC version to increase drive capability, not
really necessary for prototype.

4.	A HM7649 is used for IBProm in CPii SW to reduce chip count while two
F93453's are used in CPi PC version.  See p.43.  The contents of the two Prom
versions are the same.

5.	Front end of Ethernet is added to CPii SW.  See pp29-30.

6.	Board layout of CPii SW is different from CPi SW.  See p.91.

If you remove pp.29-30, then you have essentially the same logics as in
LionHead-N.dm.  To change the CS to 16K, just modify pp.17-22 & 27.

To implement 16K CS, I think using 16K x 1 chips may be easier than using 4K x
4 chips.  You can use the same layout as in LionHead-G.dm.  In that case, you
may want to review the way CPi SW terminates the  CS address lines.  Reference
LionHead54.sily in LionHead-G.dm and [Iris]<Workstation>LH>NetNIA.sil for
details.

The Sil fonts in Bob Garner's user.cm are the following : 

[SIL]
0: TimesRoman10
1: HELVETICA7B
2: TimesRoman8
3: Gates32
5: sil.lb5
6: sil.lb6
7: sil.lb7
8: CAS.lb8
9: sil.lb9
//%: sil.lb8  // library sh5 disabled
A: WSDict.Analyze
//U: DOIR  //  unnamed net insertion disabled   
//I: PINK
Y: 0  //place the status line at top

If you have any questions, feel free to call me.  Good luck.

Alan


*start*
01359 00024 US 
Date: 10 March 1982 10:47 am EST (Wednesday)
From: Damouth.WBST
Subject: Re: Project Plan for 16K DLion
In-reply-to: TonyWest.PA's message of 9 March 1982 3:24 pm PST (Tuesday)
To: TonyWest.PA
cc: Damouth, DMurray, Roetling, Baroody, Hamerly, Zack

WRC/ISL is very interested in obtaining 16k boards for existing and future
DLions.    Some of our near-term image processing, font development, and
printer ESS work is aimed at OPD and PSD, and software development for these
projects is best carried out on the DLions.  Microcode emulation of certain
portions of image processing/ raster processing algorithms will be necessary
during the development cycle.

(What is SDD's attitude?  Will they consider making the product version 16k at
some point in the future?)

We also would like to reduce or eliminate our dependence on Dolphins.  And we
would, of course, eventually like to be able to run Cedar - although I
understands the issues raised by this.

We would consider helping with the project, if there is any way that that is
practical from so far away.  We might also consider doing other DLion
enhancements that will be needed in the future.  (is anyone looking at a DLion
color display yet? - we're going to need one)

My guesses on timing and quantities:

units   	time

4		ASAP  (maybe stitchweld?)
6		Jan 83
10		July 83




*start*
01181 00024 US 
Date: 10-Mar-82  8:22:32 PST (Wednesday)
From: Israel.pa
Subject: Re: Project Plan for 16K DLion
In-reply-to: Your message of 9 March 1982 3:24 pm PST (Tuesday)
To: TonyWest
cc: Israel.pa, ALBrown.PA, Frandeen.PA, Ogus.pa

SDD Advanced Development is looking for 4 - 8 of the 16K control stores.  The intended use is to support investigations in processing scanned images and voice.  As a minumum, we'd like to get micro-code for floating point (anybody doing this that you know of?), for controlling digitized voice I/O, and for controlling gray-scale scanner I/O.  Other candidates for microcode are inner loops of image processing, voice compression, etc.

Is your design for the 16K control store dependent on any other changes to the standard Dandelion?  Your message hinted at larger main memory -- is there any dependency?

I was originally hoping to get four micro-store extensions by this April 15 and four more by July 1.  From your message, that schedule seems unattainable, but what schedule do you think is reasonable?  Also what do you think the transfer price will be, and what formalities do I go through to make it happen?

Jay.
8*923-4618
*start*
00811 00024 US 
Date: 10 March 1982 1:21 pm PST (Wednesday)
From: AKTsang.pa
Subject: Re: CP Drawings
In-reply-to: Your message of 9 March 1982 4:41 pm PST (Tuesday)
To: TonyWest
cc: AKTsang

Tony:

There is one more difference btwn SW and PC version of CP --  SW uses four
Am93S48's as CS parity generator while PC uses six 74S241's  (p.23).

You can find the parts lists for CP in [Iris]<Workstation>Doc>DLionParts.press. 
The parts list there is for 'pre-RevN' PC version.  To update it to RevN, add two
74S241's.  For SW purpose, you should replace two F93453's by one HM7649, and
six 74S280's by four Am93S48's.

You can certainly use Signetic 8X350, 256 x 8 RAM, for the SU-Reg, if it satisfies
the timing requirement for SU-Reg.  As far as I know, this part is not qualified
by Xerox yet.

Alan

*start*
00704 00024 US 
Date: 16 MAR 1982 2048-PST
From: MASINTER.PA
Subject: Our interest in 16K control stores
To:   TonyWest
cc:   Purcell, Masinter

We (the Interlisp-D group) are currently working on bringing Interlisp-D
up on the Dandelion. I think that the availability of 16K control
stores might have a major impact on our implementation strategy.
We are currently not counting on relying on the 16K control-store,
(we think it will "fit" in 4K) but performance could definitely
be enhanced with additional microstore. We would like to follow fairly
closely the development and production of these boards. If there
is any point now in participating in a "buy" of components, let us
know.

Larry
*start*
04428 00024 US 
Date: 26 March 1982 9:53 pm PST (Friday)
From: Garner.PA
Subject: DLion Bank switching
To: TonyWest, Purcell
cc: Frandeen, Sandman, Kaehler, Ingalls, Ogus, Garner


This message explains the code for bank switching  (the following message talks
about the hardware).  This is  PRELIMINARY.  What did I forget?

Example microcode for switching to a known bank will look something like:

		Bank _ n	{n= 0, 1, 2, 3}				,c1;
		Noop		{any instruction, incl. BRANCH}		,c2;
		GOTOABS[newBankAddr]					,c3;

Control will be in the new bank at location "newBankAddr" in c1 during the
next Emulator click.  If c2 specifies a branch or dispatch condition (such as
ZeroBr, LnDisp, or IBDisp), the destination in the new bank will be appropriately
modified  (no MASS help here!).

The "Bank_" must occur in c1.  The "Bank_" function can be either fY=0D (it is
not being used as "ClrIOPRq" like the DMR implies) or fZ=4 (currently unused). 
It should probably be fZ for Case (1) and fY for Case (2) (see below).

In terms of syntaxthis is more messythe "GOTOABS[newBankAddr]" can be
replaced by a "GOTO[newBankLabel]" if the "newBankLabel" is a label in the
current bank which has been "at'd" to the right place  (in this case, MASS might
get picky if c2 has some branches or dispatches).

Bank switching will not be possible for the IO code (i.e., non-Emulator code). 
All non-Emulator code will execute from one bank (number 3).  (Because of this,
the standard Mesa code initialization should be updated to include a Bank_3 if
it is to run on modified DLion's.)

In order for Breakpoints to work, some of the Kernel code will have to be placed
in each bank:  those instructions which execute before the bank switch can
occur.  (This amounts to 32 instructions for c1 breaks (K1Entry table, Kc#) and
4 instructions for c2 and c3 breaks (K2Entry, K3Entry, KBEntry and KBEntry+1)

Moreover, there must be error trap-catching code in each bank:  if this code
jumped to a common handler in bank 3, there would be 3 instructions required
in banks 0-2 (See ErrTrap, ErrTrap+1, & ErrTrap+2 in Refill.mc). 

Note that each bank can still support its own 256-way instruction dispatch tables.

There are several ways the 2-bit Bank register could be loaded:

(1)  from the NIA register (i.e.  the INIA field OR'd with conditions);
(2)  from the Y bus; or
(3)  from the X bus.

Case 3 is hereby ruled out because the X bus has too many loads on it already.
Case 1:

In Case (1), there is minimal instruction impact (one function field) if jumping
to a fixed bank.  However, it is expensive if jumping to an arbitrary bank (see
below).

For the above example, the statement at c2 would be placed by MASS at a
location whose address is 2 MOD 4  (as if c2 contained an "at[2, 4]").  If c1 were
loading a Link register or specified a branch or dispatch condtion, this could
conflict with the "Bank_".

The code for jumping to a random Bank is ugly:

		[] _ n, XDisp {or YDisp, or ZeroBr, ...},			,c3;

		Bank _ 0, DISP2[T]						,c1;

		Noop		{any instruction, incl. BRANCH}		,c2,at[0,4,T];
		Noop		{any instruction, incl. BRANCH}		,c2,at[1,4,T];
		Noop		{any instruction, incl. BRANCH}		,c2,at[2,4,T];
		Noop		{any instruction, incl. BRANCH}		,c2,at[3,4,T];

		GOTOABS[newBankAddr]					,c3;

Case 2:

In Case (2), the cost of jumping to a fixed bank is two function fields (fY and
fZ=Nibble).  It is easy to jump to an arbitrary bank if the bank number can be
computed or was precalculated in a register.  If not, its cost is the same as Case
(1) since a dispatch is required.

The code for jumping to an arbitrary bank with the bank number in a register:

		Bank _ RorUorQorRHregister				,c1;
		Noop		{any instruction, incl. BRANCH}		,c2;
		GOTOABS[newBankAddr]					,c3;

The "Bank_" function has the timing of "IOYOut_":  arithmetic is OK with U or
RH registers  (See "Figure 7.  Allowable X bus Operations" in the Hardware
Manual or DMR.)


Summary:

I prefer Case (2), loading the bank register from the Y bus.  Case (1) would
require a hairy update to MASS & Burdock.  In fact, MASS has already been
updated for Case (2):  I had Don Charnley do this a week before he left;
however, he put the "Bank_" in fZ=4 instead of fY=0D.   Footnote 2 in the
Hardware Manual is invalid (in the next version, I will write up the Bank stuff
in its own section).

The next message explains the required hardware updates....

Robert 



*start*
04761 00024 US 
Date: 27 March 1982 1:11 am PST (Saturday)
From: Garner.PA
Subject: DLion Bank Switch hardware
To: TonyWest
cc: AKTsang, Cucinitti, Kaehler, Purcell, ABell, Ogus, Thacker, Garner

Tony,

In order to update the CP hardware, you will need to do the following (What did
I forget? Steve, Roy:  see #4.  Any thoughts?):

1.  Choose a stichweld board type.  The change described below requires two new
16-pin chips and two termination resistors.  The current CP (on a normal
stichweld card) has a 14-pin spare position, a 20-pin platform of resistors, and, in
order to place one of the 2901's, 6 holes must be drilled in the board and 6 wires
added.  With some juggeling (and dispersal of the resistors), the two 16-pin chips
could be added where they're needed.

The alternative is to use the new, larger stichweld card which supports about 240
chips (I think).  See Jim Cucinitti for details (Route board descritor, etc.  He
might be able to loan you some for a while.)  I favor this alternative:  less hassel
and more flexiblilty for adding more parts.

2.  Update the CP stichweld schematics (called LionHead), which are currently
out of date (see Alan Tsang's message on this.  In general, they should look like
the most recent PC schematics (LionHead-N).  However, some of the clocks were
changed for version N, and this may not be appropriate for the SW).  If you use
the large stichweld card, you can use the standard two Proms (1024x4) for the IB
instead of the special one for the existing stichweld (512x8).   You can also
buffer the U-registers with S241's (per rev N). 

3.  Make the following changes to the schematics for bank switching:

a.  add another page (p.28 for SW, p.30 for PC) for bank switching junk. 

b.  Add a wire to the SwitchProm at i18 pin 12 (Q0) and name it "IOBank."  (I
will supply an updated Mesa program for the Prom.)  Rename the Prom to
"SwitchProm-RevX."

c.  Rename pin 10 of the S138 (fYNorm) on p.9 from ClrIOPRq' to Bank_'. 
Disconnect it from the backplane.

d.  Add an LS163 somewhere near the low 2 bits of the Y bus (and, secondarily,
WaitClk) and call it "Bank."   (The counter chip is being used because we can
both load and clear it (unlike many other registers).  Hopefully, it won't
count....) 

	Label wire from H2  Bank.a  {Actually any of the outputs will do}
	Label wire from H3  Bank.b
	Connect LD' to Bank_'
	Connect CK to WaitClk
	Connect CL' to IOPReset' (pin 117)
	Connect EP & ET to GND
	Connect B2 to Y.14
	Connect B3 to Y.15

e.  Add a 25S09 near the control store and termination resistors and call it
"NIA[a-b]."  (This is an example why numbering from the MSB is crazy:  when
bits are added to the high (the normal case), one must, in theory,  renumber 'em
all.)

	Label wire from Q2  NIA.a'  {Actually any of the outputs are OK}
	Label wire from Q3  NIA.b'
	Connect SB to IOBank
	Connect CK to WaitClk  {It may be possible to connect to AlwaysClk}
	Connect B2 & B3 to GND  {I decided to change the IO bank from 3 to 0 !}
	Connect D2 to Bank.a
	Connect D3 to Bank.b

f.  Connect NIA.a' and NIA.b' to 18 ohm (15 ohms for PC) series termination
resistors (see p. 27). 

4.  We have to decide on how to READ the Bank register.  We can either:

a. Steal two bits of the TC register that the IOP reads and most people (except for
diagnostics) never look at:  TC.0 and TC.1  (These are the high order pending
condition bits.  See p. 25 where they are read.).

b.  Extend the "ErrnIBnStkp" (CP status) register by connecting an S240 to the
high X-bus and connecting Bank.a and Bank.b to its inputs (we could also add
other status bits).  This upper-half of the ErrnIBnStkp register could be enabled
by one of the currently undecoded values fZ=9, 0A, or 0B (fZNorm) or we could
change the logic which zeros the upper half of the X-bus when ErrnIBnStkp is
normally read onto the bus  (I don't know how to do this so the circuits are fast
enough). 

c. Two 60-watt light bulbs (or LED's, or 4 different tones)!!! (I like this one......) 
More thoughts needed here.

5.  It will also be necessary to update the so-called NetNIA schematics and add
NetNIA.a' and NetNIA.b'.  The CP SW board is actually created with two wire
lists:  NetNIA.wl and LionHead.wl.  NetNIA.wl is applied first and connects the
address lines of the CS chips together in a known way (otherwise they would be
too large).  See Alan Tsang (he knows).

6. Change the rev level of the board to something like "X".  Alan Tsang has all
the command files needed to update the board and make life easier.

7.  Have Rosemary weld it and test it with Alan.  (Since the Bank register will
be reset at power on (w/ IOPReset), it should work with the normal diagnostics
and Mesa.)

Good luck and good night....

Robert
	



*start*
00614 00024 US 
Date: 29 March 1982 10:15 am PST (Monday)
From: AKTsang.pa
Subject: Re: DLion Bank Switch hardware
In-reply-to: Garner's message of 27 March 1982 1:11 am PST (Saturday)
To: Garner
cc: TonyWest, AKTsang

Bob:

You also designated fZNorm[4] as  "Bank_" in the Dandelion Hardware Manual. 
Are they the same or just an assignment change ?

Alan.

-------------------------------------------------------------------

c.  Rename pin 10 of the S138 (fYNorm) on p.9 from ClrIOPRq' to Bank_'. 
Disconnect it from the backplane.

-------------------------------------------------------------------


*start*
00286 00024 US 
Date: 29 March 1982 11:05 am PST (Monday)
From: Garner.PA
Subject: Re: DLion Bank Switch hardware
In-reply-to: AKTsang's message of 29 March 1982 10:15 am PST (Monday)
To: AKTsang
cc: Garner, TonyWest

Placing Bank_ on fY would be an assignment change.

Robert

*start*
01908 00024 US 
Date: 29 March 1982 11:51 am PST (Monday)
From: purcell.PA
Subject: Re: DLion Bank Switch hardware
In-reply-to: Garner's message of 27 March 1982 1:11 am PST (Saturday)
To: Garner
cc: TonyWest, AKTsang, Cucinitti, Kaehler, Purcell, ABell, Ogus, Thacker

My two cents concerning the alternative ways to read bank register:

4a. Steal two bits of the TC register that the IOP reads and most people (except for
diagnostics) never look at:  TC.0 and TC.1  (These are the high order pending
condition bits.  See p. 25 where they are read.).

4.b.  Extend the "ErrnIBnStkp" (CP status) register by connecting an S240 to the
high X-bus and connecting Bank.a and Bank.b to its inputs (we could also add
other status bits).  This upper-half of the ErrnIBnStkp register could be enabled
by one of the currently undecoded values fZ=9, 0A, or 0B (fZNorm) or we could
change the logic which zeros the upper half of the X-bus when ErrnIBnStkp is
normally read onto the bus  (I don't know how to do this so the circuits are fast
enough). 

4.c. Two 60-watt light bulbs (or LED's, or 4 different tones)!!! (I like this one......) 
More thoughts needed here.

Alternative 4.c. may be attractive but it needs a sensory input device to read the
lights or hear the tones.  Alternatives 4.a and 4.b make the bank bits available to
different processors: 4.a reads to the IOP and 4.b reads to the CP.  I think of the
bank bits as extensions to the program counter NIA, which can be read by the
IOP but not by the CP.  An instruction in the CP to read the bank bits can only
get one answer, namely the bank that the instruction is located in; it might as
well just generate the appropriate constant (assuming a flexible method of
instruction placement).  I think alternative 4.a is sensible and probably
minimizes hardware additions.  (I can't judge the importance of TC.0 and TC.1
for diagnostics).

Steve

*start*
00418 00024 US 
Date: 5 April 1982 4:28 pm PST (Monday)
From: Garner.PA
Subject: DLion CS change
To: TonyWest
cc: Garner

Tony,

Before I forget, the LS163, used as the bank register in the modified CP (ref
previoius message)  should be an LS161.  (The LS161 has an asynchronous clear.)

This is because WaitClock (the clock input of the LS163) is inhibited while
IOPReset' (the reset input) is true.

Robert

*start*
00666 00024 US 
Date: 18 Feb. 1982 8:37 pm PST (Thursday)
From: Garner.PA
Subject: page cross in MultiBus Cub CP
To: DDavies
cc: TonyWest, Garner

Dan,

I assume that your observation that a MAR_ pagecross can not be tolerated is a
consequence of the fact that the MultiBus memory access cannot be stopped once
started?  For memory reads, it doesn't matter, since the returned data can be
thrown away.  For writes, since we have to latch the address at the end of c1,
we can wait 'till then to see whether pagecross is true (and then start memory).

The alternative scheme of adding 8 more bits of U register would substantially
screw up the code.

Robert

*start*
00994 00024 US 
Date: 19 Feb. 1982 2:59 pm PST (Friday)
From: DDavies.PA
Subject: Re: page cross in MultiBus Cub CP
In-reply-to: Garner's message of 18 Feb. 1982 8:37 pm PST (Thursday)
To: Garner
cc: DDavies, TonyWest

Robert,

"I assume that your observation that a MAR_ pagecross can not be tolerated is a
consequence of the fact that the MultiBus memory access cannot be stopped once
started?"

I believe that is correct.  If you are willing to take the extra time necessary to
wait for c2 to finish before starting your MultiBus cycle, it should probably be
ok.  Will you allow variable device response times?  If so, will you have wait
states that last over cycles instead of clicks?

Note your memory cycle time will be on the order of 274 ns (c1+c2) + 50
(address and data setup) + 290 (ECC memory access time) + 65 (bus hold time) =
679 ns.  This assumes there is only one bus master so no time is needed for
arbitration.  This is 411/679 or about 60% of Dandelion speed.

Dan

*start*
14117 00024 US 
Date: 23 Feb. 1982 11:46 am PST (Tuesday)
From: Ingalls.PA
Subject: Mumble
To: TonyWest

Voila!

---------------------------

Date: 21 May 1981 3:48 pm PDT (Thursday)
From: Ingalls
Subject: Dandelion Smalltalk Feasibility
To: Adele, Deutsch, Robson, Krasner, McCall, Kaehler, Flegal, Merry
cc: Ingalls

Peter and I have been assembling a more complete picture of the suitablitiy of
Dandelion as a Smalltalk engine, and I thought it would be worth distributing
some interim results.

To begin with, no one is talking about increasing the 4K microcode space. 
Considering how far along the OPD release is, we should probably consider
extension of the microcode space to be out of the question.

Here are some rough figures for the size of various pieces of microcode:

Machine      Dorado      Dolphin      Dandelion
-----------------------------------------------------
BitBlt             270             256             450
Disk              280             290             180
Display           270             250             200
Ether             170             170             140
SlowIO             60              50              80
AltoEm           540             540             ---

These numbers are somewhat interesting - It doesn't appear that the Dandelion is
necessarily much worse in code density.  Peter had envisioned two causes: the
need to shuffle data because only 5 of the registers can be used for arithmetic,
and the mandatory use of 3 instructions to access memory.

The Dandelion suffers under two other burdens - no hardware assist for BitBlt
and no hardware assist for address mapping.  The former shows up in the larger
code for BitBlt, but Bob Garner said this figure includes a considerable trade of
space for speed.  With a resident system, or with LOOM, lack of mapping
hardware should not be a big problem (see * below, though).

Peter and I discussed a space-saving intermediate solution to our need for the
Alto emulator: just implement the parts we need.  This would allow us to avoid
wasting space on timers, the convert instruction and other sundries.

There are already Dandelions with 384K of main memory (stitchweld versions),
and I suspect that there will be general support for this before long (we need to
talk to a product planner).  I think the NCC demo used this configuration.  The
limit is really 768K.  (*) I am not sure what the addressing is like beyond 64K; 
I'll have to persue this with those in the know.

The bottom line at this point seems to be that it's not out of the question.  Peter
and/or I and/or anyone interested should take another run at benchmarking a
couple of pieces of the ST80 kernel and the Alto emulator to get a reliable
reading.


---------------------------

Date: 21 May 1981 4:51 pm PDT (Thursday)
From: Deutsch.PA
Subject: Re: Dandelion Smalltalk Feasibility
In-reply-to: Ingalls' message of 21 May 1981 3:48 pm PDT (Thursday)
To: Ingalls
cc: Adele, Deutsch, Robson, Krasner, McCall, Kaehler, Flegal, Merry

Memory addressing on the Dandelion does not suffer from any kind of 64K
limitation: in fact, all memory addresses are actually 24 bits.  There is an
arrangement whereby an 8-bit and a 16-bit register sort of get paired up and
function like a 24-bit base register, to which 16-bit offsets get added at the time
of the reference.  It's similar to the base register addressing on the Dolphin. 
When Larry returns my reference manual I can look at the code Garner and I
wrote and refresh my memory further.


---------------------------

Date: 22 May 1981 12:04 pm PDT (Friday)
From: Deutsch.PA
Subject: Manna from heaven, maybe
To: ingalls, Adele, Robson, Krasner, McCall, Kaehler, Flegal, Merry

---------------------------

Date: 21 May 1981 11:20 pm PDT (Thursday)
From: Garner.PA
Subject: A Large Dandelion Control Store?
To: Sandman, Johnsson, Frandeen, ABell, Deutsch
cc: Ogus, Belleville, Wick, Thacker, Charnley, DDavies, Olmstead, Murray,
 Cucinitti, Garner

The subject of a larger Dandelion control store has been surfacing again.  After
thinking about it a little more, I've realized that the control store can be enlarged
from 4K to 16K instructions at "only" the cost of 2 chips and minor changes to
MASS and Burdock.

If I produced such a board (as described below) and we updated MASS &
Burdock, would anyone utilize this capability (for uCode development,
SmallTalk, LISP?)??

The cheap, dirty, & quick scheme:  (Any proposal must meet these requirements,
as the current stichweld board is essentially full.  The most elegant way is to add
2 bits in all the appropriate places, but this is very expensive.)

Hardware details:  Replace the 4K chips with Intel's new 16K fast rams (i2167). 
Add a 2-bit Bank register (Am25S09) and a 2-bit extention to the CS-address
register (Am25S09).  Let fZ=4 be the control bit (or reclaim the parity bit) which
loads the Bank register from the same place the Link register gets its data from
(NIAX).  Load a "3" into the CS-address-extention register when IO uCode is
going to run (otherwise load the Bank register).

Software details:  Add a "Bank_n" phrase to MASS.  When this ocurrs before c2
of a click, the emulator will execute from Bank n in the next click.  Add the
code to Burdock which will write the Bank register (this is slightly tricky). 
Place the IO microcode in the highest bank.  (Currently the disk+display+
ethernet+ IOP+Kernel uCode is 236+196+173+69+112 = 786 uInst.)  Seperately
assemble the code for the 4 banks & write a Burdock command file which loads
each bank & initializes the bank register for the emulator start address.

Recall that the Dandelion allows multiple (12 of 'em) 256-way instruction
dispatch tables.

Isn't this fun??

--RG   



------------------------------------------------------------


---------------------------

Date: 13 Nov. 1981 9:27 am PST (Friday)
From: Ingalls.PA
Subject: Dandelion microstore
In-reply-to: Your message of 12 Nov. 1981 3:18 pm PST (Thursday)
To: Kaehler
cc: Ingalls, adele, deutsch, krasner, robson

About the 16K microstore - I WANT IT A LOT.

If it is the only thing that separates us from a Smalltalk with good performance
on widely available machines, then I think it is important.  Done this way, it is
so cheap that even if it's not in the standard product, anyone who wants to use
ST would be glad to pay the difference.

Dan Murray at Webster told me that his group wants it a lot and that he will
even chip in (heh, heh) resources if it would help.  Jerry Farmer at XEOS also
told me that they have plans for printer drivers which could use the Dandelion
if it had a bigger microstore.

It's a funny thing - the machines aren't even available to us yet, but I'm SURE
this is the right thing to do.  I think it will be worth it just in green stamps,
even if we don't turn out to need it for ST80 (and it will OBVIOUSLY let us
bring it up quicker, and help significantly in speed).

I'm also willing to bet that, politically, this is the best thing we could possibly do
for our access to Dandelions.  Remember our experience with CSL and the factor
of who contributed to Dorado development.

If there's anything I can do to help this along (sales pitch to Bob Garner, sales
pitch to Harold), please tell me.


---------------------------

Date: 17 Nov. 1981 8:13 pm PST (Tuesday)
From: Garner.PA
Subject: 16K micro store
To: Kaehler
cc: Ingalls, adele, deutsch, krasner, robson, Ogus, Purcell, Olmstead, Garner

Ted,

Here is about what must happen so that a 16K-control store Dandelion CP card
can be built and used:

1.  Order from Intel 50 pieces (i.e., 2 are spare) of the high speed 16Kx1 static
RAM, the i2167, at 70 nS access time.  50 pieces should be purchased for each CP
board to be built.  It may be wise to have 2 prototype boards in case one breaks
and .....

2.  Order from Moore Systems one (or more) stichweld cards.  I will supply their
address and board type later.  Rosemary Atkinson will actually stichweld the
board.

3.  Update MASS (the microcode assembler) to accept the "Bank_" fZ field
function.  This has been done, but not tested.  (I think it is unreasonable to ask
that MASS recognize a 16K address space, instead the MASS phrase,
"GOTOABS[number]" , where number < 4096, can be used to jump between
banks.  Branches and dispatches should work between banks)

4.  Update Burdock (the Alto-based debugger) to accept a Bank read/write
function.  This can be done without much difficulty.  (I think it is unreasonable
to ask that Burdock be changed to load the whole 16K address space.  Instead, a
burdock command file can be written which will seperately load each bank.)

5.  Update the CP schematics to include a Bank register and a 2-bit expansion to
the control store address reg.  (All non-emulator code would execute out of
Bank 3.)  I have not done this.  I also need to decide on a way to read the bank
register.  (What goes in must come out?)

6.  A "Bank_3" should be added to the standard Mesa init code.  I will ask that
this be done.

7.  A wide body Alto II is needed for Burdock.  A Dandelion-Alto umbilical box
(+cables) is also needed.  Either SDD (e.g., Ogus) has some, or Bill Bice in El
Segundo can supply you with one.

8.  If all goes well and PC boards are to be built, SDD & ED should be
approached on the logistics.  It would be fairly simple to update the current etch
CP card--the i2167 is 1-pin width longer than the current i2147.  Talk to Dick
Rush of SDD.

~robert   


---------------------------

Date:  4-Feb-82  9:43:15 PST (Thursday)
From: ALBrown.PA
Subject: Re: Dandelions
In-reply-to: Your message of 3 Feb. 1982 5:29 pm PST (Wednesday)
To: Ingalls
cc: ALBrown

Dan,

In Charles Irby's Advanced Development section in SDD we have several projects
under way that very likely need special microcode.  One such project concerns
the integration of scanned images into the Star environment.  An interactive
system dealing with gray-scale images needs (at least!) microcode support of
floating point and half-toning primitives.  Anyway, our thought is that if a run
of extended microstore DLions is to be built, we would probably like four of
them.  Also, there are folks at Webster who have similar needs and would very
likely want to join the party.

If there is more to know about this whole activity, perhaps who should arrange a
traditional (non-electronic) conversation.

Allen

---------------------------

Date: 4 Feb. 1982 2:41 pm PST (Thursday)
From: Ingalls.PA
Subject: Dandelion JumboStore
In-reply-to: Your message of 4-Feb-82  9:43:15 PST (Thursday)
To: ALBrown
cc: Ingalls, Adele, Garner

Thanks

Basically SCG (that's us) is putting up the parts and enthusiasm for 2 prototype
boards, and we have enlisted Bob Garner's essential help for the prototype
design, construction and changes to the microassembler.  His know-how is
crucial.  Ted Kaehler is monitoring the parts acquisition, and I judge the timing
to be fairly important since Bob will naturally find other things to do.  We are
expecting a couple of Dlions "any day".

I pushed this project from the beginning for ST, and later found out about Dan
Murray's interest in Webster, and Jerry Farmer at EOS also seemed interested if
Dlions become available to use in their printer products.  I'll remember that you
are potentially interested in four, and I suppose we should contact other
interested parties fairly soon so that a small production run can follow debugging
of the first boards in a timely manner.


---------------------------

Date: 5 Feb. 1982 9:24 am PST (Friday)
From: adele.PA
Subject: Re: Dandelion JumboStore
In-reply-to: Your message of 4 Feb. 1982 2:43 pm PST (Thursday)
To: Ingalls
cc: 

I read my mail backwards which turned out to be ideal!

We better sit down with Bob Garner very soon so that we are not getting him or
us into something bigger than desired and to make sure that Garner is still with
us on this.  Have you spoken with him recently?  I will chase Chris on the
Dlion status.


---------------------------

Date: 19 Feb. 1982 10:42 am PST (Friday)
From: Garner.PA
Subject: Big CS
To: Ogus
cc: Israel, ALBrown, Kaehler, Ingalls, Purcell, TonyWest, ABell, Mau

Roy,

There seems to be mounting interest in SDD for the big-microstore CP board.

As I have promised everyone who asks, I will update the CP schematics (I plan
to do this this weekend).  It's up to everyone else to have the boards made, order
the parts, and to convince someone to update MASS and Burdock (Although, I
will also write the Burdock overlay code and a command file for Burdock.)   The
process will be ameliorated if SDD officially supports the board. 

Currently, SCG (Smalltalk folks) and CSL (re: TonyWest) actively want the
board.  SCG has already ordered 16Kx1 rams from Intel. 

Robert

---------------------------

Date: 18-Feb-82 19:43:29 PST (Thursday)
From: Israel.pa
Subject: Expanded Micro-store
To: Garner
Reply-To: Israel.pa
cc: , Israel.pa

I understand you're going ahead with the design and construction of large
micro-store for Dandelions.  We (SDD Advanced Devt.) would like to obtain four
to eight of these.  How do we go about joining the customer list?  What's the
situation on assembler and debugger support of large micro-store?

There are other potential customers I know of, including image processing folks
in Webster, developers of CAD systems at Versatek, and printing folks in PARC. 
You probably know these already.  But if you don't, and if it will help to track
them down, let me know.

Jay.
------------------------------------------------------------


---------------------------

Date: 22-Feb-82  8:19:16 PST (Monday)
From: Israel.pa
Subject: Expanded Micro-store
To: Ingalls
Reply-To: Israel.pa

Dan,

According to Robert Garner, "SCG has already ordered 16Kx1 rams from Intel" for
expanded Dandelion micro-store.  We (SDD Advanced Development) need such a
device ourselves.  Are you managing the fabrication of a number of these?  How
can we get in on the build?  We're in the market for 4 to 8 units.

Thanks,
Jay.
------------------------------------------------------------

*start*
02101 00024 US 
Date: 7 June 1982 12:13 pm PDT (Monday)
From: Fiala.PA
Subject: Dolphin Dandelion Comparison
To: CSL^,ISL^
cc: Neely, Masinter, ABell, Fiala
Reply-To: Fiala

Ev Neely and I recently measured the performance of the Dolphin and the
Dandelion running the Trinity Pilot instruction set and this message describes
the results we got.

First, we made the test environment as identical as possible by erasing and
reloading the Pilot volumes immediately before testing, and we put 384k words of
storage on each machine.  The test consisted of four compilations, each repeated
three times in a row--we summed the elapsed time reported by the compiler for
the last of the three compilations to get the score of the machine.  We think that
both machines were largely compute bound during the final compilation, but we
didn't make sure of this.

The total times were as follows:
	Dolphin with 40 mHz crystal		164 seconds
	Dandelion					105 seconds

Initially, Ev ran this test on his 256k-word Dandelion with a Pilot volume that
had not been erased and reloaded for about five software releases during
Dandelion system test--elapsed time was 170 seconds.  Erasing and reloading his
volume reduced the time to 135 seconds.  Finally, adding 128k words of storage
reduced the time to 105 seconds.

If the Dolphin were equipped with a 50 mHz processor crystal, then its time
would be about 118 seconds.  According to Chuck Thacker, making a Dolphin
run with a 50 mHz crystal would require replacing 15 dips (the register memory)
with faster parts now available, possibly some other changes as well.

I do not think that microcode changes could substantially improve timing on the
Dolphin.  I do not know what possibilities exist for improving speed on the
Dandelion.  However, I have been told that the Dandelion display controller and
emulator compete for access to the first 256k words of storage, so it is possible
that, even though the Dandelion was probably compute bound during the
measurements we made, its speed would increase with additional storage, due to
less storage contention.

*start*
01264 00024 US 
Date: 8 June 1982 1:59 pm PDT (Tuesday)
From: TonyWest.PA
Subject: Re: Decision Date
In-reply-to: Your message of 2 June 1982 3:05 pm EDT (Wednesday)
To: DMurray.WBST
cc: TonyWest

About your question:

"Tony, when we last talked about the Dandelion 16K control store, you mentioned its fate was tied to CSL's decision on how to spend its 1982 capital.  What is the current status of this debate and the board."

The current position is that CSL has still not made any kind of "strategic" decisions involving the 1982 capital budget and Dandelions.  In fact, we have had the budget reduced somewhat, so I do not think that any great happenings related to Dandelions are going to happen in 1982.

What I surmise (emphasis on "surmise") might happen is that we will build and debug a couple of stitchwelded prototypes in 1982, maybe also have the pcb artwork done in 1982, and then produce a moderate number of 16K CP boards in 1Q83.

I emphasize that this is by no means definite.

If you wanted a small number of boards this year, however, we could maybe
a. give you the designs and you could stitchweld them, or
b. stitchweld them for you.

The prototpe board should be on my desk in about 6 weeks, when do you have to have boards? 

Tony
*start*
02390 00024 US 
Date: 7 July 1982 2:29 pm PDT (Wednesday)
From: TonyWest.PA
Subject: 16K Control Store for DLion
To: Levin, Rovner, Boggs, Murray, Sturgis, Taft
cc: TonyWest, Schroeder, Pier, Lampson, Garner

Here is a status report of my activities for your information:

I am now almost complete with the Dorado Auxiliary board
	-- the logic for Des encryption is complete
	-- I am now adding the Gifford Noise Generator (already designed)
	-- Stable Storage will wait until later (after the 16K Control Store work)

The next step is a design review, but, since I have been developing the design in consultation with the gurus anyway, I don't expect the review to turn up any startling things.  

I will stitchweld a prototype for debugging, and then debug the Dorado board in parallel with amending the existing Dandelion drawings for the 16K control store.  Debugging and design go well hand-in-hand since each acts as relief when you get frustrated with the other!

Actually, that is not such a big deal; the 16K chips are faster than the current 4K chips (so there are no speed problems) and the logic needed to add a 2-bit bank register is fairly simple.  The main work will be in figuring out the amendments the current opcode decoder needs to add the ability to generate the Bank Register Load signals, etc.

Since stitchweld turnaround is typically 1-3 days, I see no major problem in getting a board back fairly soon.  As I am hardly altering the basic design, I don't expect to encounter any major problems during debugging and, therefore, I hope to have a board running in August.  

Of course, I will be dependent on some help for some of this, in particular, I will need to have a way to write microcode (amended Mass) and load it (amended Burdock).  Hal seems to have Burdock well under control relative to this timescale, but I am not sure what state our plans for Mass is in (Howard?).

The next step is to integrate the Cedar microcode with a version of Cedar for the Dandelion.  I don't know Howard's projections of the amount of effort required for the microcode, nor am I sure how much work is required to implement the heads etc.  Presumably Roy/Ed know clearly how much work is required for the latter.

Therefore, we stand a fighting chance of getting a version of Cedar running on the new machine in 3Q82.

Comments, suggestions, and help welcomed.

Tony 
*start*
01303 00024 US 
Date: 7 July 1982 2:52 pm PDT (Wednesday)
From: Taft.PA
Subject: Re: 16K Control Store for DLion
In-reply-to: TonyWest's message of 7 July 1982 2:29 pm PDT (Wednesday)
To: TonyWest
cc: Levin, Rovner, Boggs, Murray, Sturgis, Taft, Schroeder, Pier, Lampson,
 Garner

Sounds very encouraging.

One additional piece of information to keep in mind: once Cedar is converted to
run on Trinity Pilot, it should run on Dandelions without any microcode support
at all, just very slowly.  Furthermore, microcode support for Cedar and floating
point need not all be done at once but can be added incrementally.  Therefore:

  (1) Neither the 16K control store nor the new microcode is in the critical path
to getting Cedar running on Dandelions;

  (2) The 16K control store is not in the critical path to getting SOME Cedar /
floating point microcode running on the Dandelion, though it seems pretty clear
that it won't be possible to fit ALL the new microcode into the existing 4K
control store.

The main things that are in the critical path to running Cedar on Dandelions are
Cedar 4.0 (getting rid of CoPilot) and the Trinity conversion, which I understand
we plan to do in that order.  I expect these are the main factors that will
determine how soon we have Cedar on Dandelions.
	Ed

*start*
01459 00024 US 
Date: 7 July 1982 5:05 pm PDT (Wednesday)
From: Levin.PA
Subject: Re: 16K Control Store for DLion
In-reply-to: Taft's message of 7 July 1982 2:52 pm PDT (Wednesday)
To: Taft, TonyWest
cc: Levin, Rovner, Boggs, Murray, Sturgis, Schroeder, Pier, Lampson, Garner

Let me restate the case slightly.  If we deem it important to get Cedar running on
a Dandelion before Cedar is converted to Trinity, all that is needed is a small
amount of microcode to implement the trapping mechanism.  There is sufficient
room in the control store to implement this microcode now.  Therefore, we could
run a Rubicon-based Cedar on the Dandelions that we have now, although it
would run slowly.

My present expectation is that we will have Cedar converted to Trinity early in
the fourth quarter and we will bring it up on the Dandelion then.  I also think it
likely that we will have enough Cedar and floating point microcode by then that
the system will run usefully on a Dandelion with a 16K control store.  If,
however, the conversion to Trinity is delayed, we may choose to bring up the
Rubicon-based Cedar instead, using the available microcode and requiring the
16K control store.  Therefore, the Trinity conversion should not be viewed as a
necessary predecessor to a useful Cedar system on Dandelions.  Tony's August
date for an operational board seems a good target; however, a significant delay
beyond August would probably start to pinch.

Roy

*start*
00984 00024 US 
Date: 4 Aug. 1982 1:55 pm PDT (Wednesday)
From: TonyWest.PA
Subject: Inmos Memories
To: AKTsang
cc: Ogus, TonyWest

Alan:

Inmos 1420 (4K by 4) Static RAMS come in at least 3 versions at the moment:
	-50 nS
	-55 nS
	-70 nS

Delivery in 100's - 4 weeks.

----------------------------------------------------------------------
Question: Are the 70nS parts fast enough?
They are quite a lot cheaper than the 55nS version, see below.
----------------------------------------------------------------------

			1-24		25-99		100-999
IMS 1420-55		$23.30		$21.50		$19.45
IMS 1420-70		$16.25		$15.00		$13.50

For a 16K control store of 48 chips, the price is:

IMS 1420-55		$933.60
IMS 1420-70		$648.00

For reference, there are 3 versions of IMS 1400 (16K by 1) available:

			1-24		25-99		100-999
IMS 1400-45		?		?		?
IMS 1400-55		21.65		20.00		18.00
IMS 1400-70		21.10		19.50		17.55

I find it interesting that the 1420's are cheaper for the 70 but not the 55!

Tony
*start*
00472 00024 US 
Date: 4 Aug. 1982 2:44 pm PDT (Wednesday)
From: Ogus.PA
Subject: Re: DLion Workstations and Cedar Graphics
In-reply-to: GCurry.ES's message of 4-Aug-82 14:33:21 PDT (Wednesday)
To: GCurry.ES
cc: TonyWest, Ogus, Shoch, Warnock

There are no current plans to incorporate a large control store into the 8000
products.  However, I'm working with Tony to help insure that should we decide
to do so, we can benefit from the work that he is doing.

Roy.

*start*
00751 00024 US 
Date: 4 Aug. 1982 2:27 pm PDT (Wednesday)
From: AKTsang.pa
Subject: Re: Inmos Memories
In-reply-to: TonyWest's message of 4 Aug. 1982 1:55 pm PDT (Wednesday)
To: TonyWest
cc: AKTsang, Ogus

Tony:

1.  What you should look at is the  Address Access Time, not Chip Enable
Access Time.  According to my data sheet, the tAA for IMS 1420-55  is  50 ns,
and this is the delay that I use for  sCPii.   For CPi, i2147 are used.  i2147 has a
tAA of 70 ns.  So, if IMS 1420-70 has tAA of <70 ns, you can use it to save some
money.

2.  Fujitsu also make compatible 4k x4 RAM, p/n are MB8168-55 and MB8168-70.

3.  Couple weeks ago, there was an article in Business Week on the health of
InMos Corp.  You may want to take a look.

~Alan.
*start*
00667 00024 US 
Date: 4 Aug. 1982 3:26 pm PDT (Wednesday)
From: TonyWest.PA
Subject: Re: (LONG) DLion Workstations and Cedar Graphics
In-reply-to: GCurry.ES's message of 4-Aug-82 14:33:21 PDT (Wednesday)
To: GCurry.ES
cc: Ogus, TonyWest

Your question:

"Does your collaboration with Roy Ogus mean that there are plans for considering the new board as a product board, or only that you are trying to preserve that option?"

is best answered by Roy Ogus.

My understanding is that we are both keeping our options open, but SDD has no intent to do anything of the kind at this time.  I am simply planning to make it easy should SDD change its mind later.

Tony
*start*
00650 00024 US 
Date:  6-Aug-82  9:08:05 PDT (Friday)
From: gcurry.es
Subject: OS5 Hardware list
To: Kimball.pa
cc: Ogus.pa, TonyWest.pa, gcurry.es

Ralph,

Tony West and Roy Ogus are working on a replacement DLion CP board which will admit optional extensions of microstore in 4K increments.

Some of the extensions to Star which are being considered or planned (e.g, Fax, Voice, Cedar Graphics, FORTRAN?) will require fast support for real arithmetic.  Unless we have the option for fast real arithmetic, many of these will be impossible.

I urge that this new CP board be made part of the OS5 hardware list with some priority.

Gael Curry
*start*
03556 00024 US 
Date:  9-Aug-82 13:41:03 PDT (Monday)
From: GCurry.ES
Subject: Re: Real Microcode "has to be there"
In-reply-to: Ayers.PA's message of 6-Aug-82 13:47:49 PDT (Friday)
To: Ayers.PA
cc: WindowsInterest^, Ogus.pa
Reply-To: GCurry.ES

I don't believe we should second-guess management on permissible DLion  hardware changes, and would like to try to enumerate some alternatives for fast real arithmetic support and guess at some of their consequences.

HARDWARE REALS SUPPORT - We must have HARDWARE reals support.  It was a mistake not to require this hardware on DLions.  Soon, all 68000-based machines (our main competition?) will have easy access to floating point coprocessor chips.  The question is whether we correct the mistake now or later; it is cheaper to correct it now.  Most arguments which can be made for microcoded reals support can also be made for implementing such in hardware.  One large advantage is we won't have to hack Cedar Graphics to make it fast enough.  

(REQUIRED) EXTENDED MICROSTORE - REQUIRE a larger microstore on all (including outstanding) workstations and implement reals support in microcode.  Hopefully microcoded reals support will be fast enough.  The disadvantage is the necessity for retrofitting.  The advantage is that all new Star software can assume a (faster) machine.  The larger microstore can be used for other purposes as well.  Many people believe that the microstore is already too small.

(OPTIONAL) EXTENDABLE MICROSTORE - Provide the option for a larger microstore (ala Tony West, Roy Ogus).  This option "satisfies" your criteria of not requiring a hardware upgrade to get from OSx to OSx+1.  The question is to what extent Star software can assume it has extended microstore.  If it assumes such for fundamental levels of support software (e.g., display software, TextBlt?), then the performance of workstations not equipped with large microstore may be unacceptable.  This may lead one to conclude that, for this reason, fundamental levels of support software should not assume large microstore; it may also be viewed as a graceful way of getting customers to REQUEST hardware mods, since the performance of their workstations will have degraded to an unacceptable point.  Presumably in this scheme, the least performance-critical microcode would go into the optional microstore banks (e.g., TextBlt?).

SWAP IN/OUT OF EXISTING MICROSTORE - The question here is whether the working set of the microcode isn't already too large to add real arithmetic for display support.  If real microcode is used for display, then it will presumably be very hot.  We don't want to play the 192K game again.

REPLACE SOMETHING (TEXTBLT) WITH REALS SUPPORT IN EXISTING MICROSTORE - The benefit of TextBlt has not been evaluated in a long time.  Last time we did so, there was 5/13 fold improvement in format/display of microcoded TextBlt over software textblt.  You recently said format/display took 0% of the elapsed time.  13 times 0 is 0.  We should re-evaluate what TextBlt buys us to see whether we could better use the microcode space.

NO FAST REALS SUPPORT - There is a slim chance that for minimal applications (no customer options), that reals-supported software levels would run fast enough without fast reals support. That is the best of all possible worlds (and it might hold for Cedar Graphics), but we need to experiment to find out.  If it is not the case, and no provision for one of the above options is made, then we may have the WORST of all possible worlds.  That is beca*start*
02810 00024 US 
Date: 12 Aug. 1982 11:57 am PDT (Thursday)
From: TonyWest.PA
Subject: 16K store for Dandelion
To: AKTsang.PA, Garner.PA, Thacker.PA, Ogus.PA, Boggs.PA
cc: TonyWest.PA, McCreight.PA, Schroeder.PA

Gentlemen:

As you know, I am working on the design of a version of the Dandelion which can take more writable control store (up to 16K).

By following Bob Garner's instructions, I have now:

	- upgraded Alan Tsang's CPii stitchweld design to CP Etch 4 (partially)
	- added bank-switching logic
	- changed to a new control store based on 4K by 4 IC's
	- adjusted the stitchweld layout to take it all.

I could only get 12K of control store to fit on a standard (older) stitchweld board, but 16K would fit easily on a PC version.  I will visit Alan Tsang to see if I ought to use the new denser stitchweld board.

I now face a choice:
	- call it quits, or
	- invest more time to upgrade the design further.

Possible reasons to call it quits are:
	- It's not clear that further effort is justifiable
	- I shouldn't perturb the design more than necessary - after all, it works!

Possible reasons to invest more time would be:
	- reduce the parts count and/or UMC
	- reduce the effort required to transfer the design back into ED
	- improve the manufacturability by ED
	- eliminate non-standard, or inactive parts (eg. Am25S09)
	
Improving performance is not possible, of course.

Two examples:

----------
Example 1:
----------

Either a. Use the existing design with slower 70nS CS RAMs and Schottky
	decoding after the instruction register.

Or	b. Move the decoding before the IR, use faster 55nS CS RAMs (maybe),
	and put in MMI PALs which both do the decoding and latch the outputs
	as part of IR.

The tradeoff I see here is:

	a. A load of random S00, S04, S10, S20, S86, and other simple STTL parts
	and ~$14 per CS RAM chip.

	b. Much less S logic, reduced parts count, some additional PALs and
	maybe $19 per CS RAM chip.  Are MMI PAL's ED-approved?

----------
Example 2:
----------

Either a. Continue to use Am 25S09 multiplexor/registers

Or	b. Use 74S374 Octal latches with tri-state outputs together with a flip-flop
	to hold the old multiplexor select signal.

The tradeoff I see here is 

	a. The Am 25S09 is Inactive, single-sourced, and has caused ED headaches
	because speed-selected versions have to be procured.

	b. The 74S374 is Standard, but needs a little redesign and a FF to use it.

I have little understanding of ED economics and other such considerations, so I would appreciate any input you might care to offer on this question.

In particular:

	- How much effort should I invest to make the board transferrable to ED?
	- Where do the heavy costs lie in the Standard Dandelion CP?
	- What kind of things does ED find expensive to build?
	
Tony
8*923-4476
*start*
00836 00024 US 
Date: 12 Aug. 1982 5:16 pm PDT (Thursday)
From: Garner.PA
Subject: Re: 16K store for Dandelion
In-reply-to: TonyWest's message of 12 Aug. 1982 11:57 am PDT (Thursday)
To: TonyWest
cc: AKTsang, Garner, Thacker, Ogus, Boggs, McCreight, Schroeder


Tony,

Who's going to debug the board?  Who's going to write the IOP code?

Did you update the SwitchProm?  How's the Bank register going to be read?


ED economics has a simple bottom line:  minimum UMC.  Thus, it is not clear
that replacing a few 10 cent ICs with a $10 PAL is a good idea.  Basically, the
largest cost in your board is the new RAM chips, so the cost of the board will be
mostly controlled by the market place..

More on ED economics:  PROMS are very expensive.  In the CP, there is $33
worth of (8) PROMS and $47 worth of random logic! 

Robert

*start*
00783 00024 US 
Date: 12 Aug. 1982 5:43 pm PDT (Thursday)
From: Thacker.PA
Subject: Re: 16K store for Dandelion
In-reply-to: TonyWest's message of 12 Aug. 1982 11:57 am PDT (Thursday)
To: TonyWest
cc: AKTsang, Garner, Thacker, Ogus, Boggs, McCreight, Schroeder

I would stop, perhaps after replacing the 25S09's.  These parts have some subtle
problems which (in some lots) have caused them to not meet their specs.  As for
your questions:

1) How much effort should I invest to make the board transferrable to ED?  None

2) Where do the heavy costs lie in the Standard Dandelion CP? Garner knows,
not I.

3) What kind of things does ED find expensive to build?  Everything, and no
matter what you do, they will find it necessary to redesign it before producing
it.

Chuck


*start*
01280 00024 US 
Date: 12 Aug. 1982 6:37 pm PDT (Thursday)
From: TonyWest.PA
Subject: Re: 16K store for Dandelion
In-reply-to: Garner's message of 12 Aug. 1982 5:16 pm PDT (Thursday)
To: Garner, Thacker
cc: TonyWest, AKTsang, Ogus, Boggs, Schroeder

Bob, Chuck,

I have heard innumerable rumours about ED UMC factors, but very little fact.  I filter the rumours with a large dose of salt; thanks for the facts!

I have decided not to invest ANY effort to make things nicer, even the 25S09's can stay the same (although I worked out a S374 scheme which appears to satisfy the setup&hold requirements, Bob).

Who's going to debug the board?			- me+whatever help I can find
Who's going to write the IOP code?		- me+Hal Murray or Fay&Co.?
Did you update the SwitchProm?			- not yet, see below
How's the Bank register going to be read?	- I stole TC.0 and TC.1

These decisions are subject to change, and are not supercritical anyway.  SDD is sounding quite benevolent with respect to helping out on this project at the moment.

Bob: In your message of 27th March, you said you might supply an updated Mesa program for the SwitchProm.  Is the offer still valid?  I have added IOBank to Q3 of the PROM as you suggested, (and the whole board is labelled Rev-P, by the way.)

Tony
*start*
00812 00024 US 
Date: 13 Aug. 1982 2:23 pm PDT (Friday)
From: TonyWest.PA
Subject: Dandelion Stitchweld Cards
To: Rosemary.PA
cc: Cucinitti.PA, Thacker.PA, TonyWest.PA

Rosemary:

Jim suggested I contact you to resolve the following question:

I am designing a board for the Dandelion and I would like to order stitchweld cards for two prototypes.

SDD told me that the standard Dolphin stitchweld cards suffer alignment problems when you insert them into Dandelions, and, since we have only got Dolphin cards in stock here in CSL, we will have to buy some of the modified Dandelion cards.  (Apparently the center cutout is different.)

Please could you let me know the part number and ordering information for the SDD/Dandelion boards and I will place an order for 2.

Thanks,

Tony West
(415)-494-4476
*start*
00625 00024 US 
Date: 16 Aug. 1982 10:23 am PDT (Monday)
From: TonyWest.PA
Subject: Dandelion Stitchweld Board Order
To: Overton
cc: TonyWest

Mike:

I think we should order one stitchweld board for CSL after all -- there now appears to be a second possible project in the offing.  I'll decide later if we should order more -- anyway, he's only got 1 in stock at the moment.

The ordering information is:

Part #:	596P53848

From:		Stitch Wire Systems Corporation
		2696 Lavery Court - Unit 20
		Newbury Park
		CA 91320

Telephone:	(805) 498-2266 (Floyd Penland)

Price:		1-10
		$659

Delivery:	off the shelf.

Tony

*start*
00674 00024 US 
Date: 16-Aug-82 12:22:32 PDT (Monday)
From: Ogus.pa
Subject: Re: 16K store for Dandelion
In-reply-to: TonyWest's message of 12 Aug. 1982 11:57 am PDT (Thursday)
To: TonyWest
cc: AKTsang, Garner, Thacker, Ogus, Boggs, McCreight, Schroeder

Tony,

A late comment on your original message:  I think you've made the right decision in not doing much further change.  The only change I would have recommended pursuing is the elimination of the 25S09s.  We probably should do this in the current CP in the future as well, since these parts are apparently quite problematic.

By the way, ED did no redesign on the Dandelion, and are now producing it.

Roy.
*start*
01838 00024 US 
Date: 25 Aug. 1982 12:26 pm PDT (Wednesday)
From: TonyWest.PA
Subject: Re: SCG and the 16K Dandilion store
In-reply-to: McCall's message of 24 Aug. 1982 10:22 am PDT (Tuesday)
To: McCall
cc: TonyWest, Kaehler, Adele, Deutsch, Ingalls

	"The latest rumor is that you have redesigned the 16K Dandelion store
	so that we now have $1.7K worth of the wrong chips."

True, I'm afraid.  The reason for this are that the chips are, indeed, rather expensive, so any engineering approach which permits you to only plug in the number of 4K banks you will actually need is most desirable if there is to be any hope that ED will take over manufacture of the board.  The 4K by 4 chips have just started rolling out in quantity, and they are second-sourced by Fujitsu.

You might ask purchasing to see if they can't return the devices for you in exchange for something else -- that sometimes works.  Larry Stewart may need some Hitachi CMOS Rams for his Etherphone project, so presumably the money could be adjusted by a transfer of some kind.

Meanwhile, I am keeping you folks in mind, though I'm not going to build more boards until I get the first one going right.  However, when that happens, I will send you a message with full instructions and a parts list, etc.

If you really want a stitchweld version, I'll be happy to orchestrate that for you, so you might start by ordering a Dandelion Stitchweld board for me to wire.

Note, DLion SW boards are infinitesimally different from a D0 stitchweld board, and SDD's experience shows that using a D0 board is definitely NOT recommended.

The ordering information is:

Part #:	596P53848

From:		Stitch Wire Systems Corporation
		2696 Lavery Court - Unit 20
		Newbury Park
		CA 91320

Telephone:	(805) 498-2266 (Floyd Penland)

Price:		1-10
		$659

Delivery:	~6 weeks

Tony
*start*
00914 00024 US 
Date: 27 Aug. 1982 1:32 pm PDT (Friday)
From: TonyWest.PA
Subject: Re: Dandelion Extender Cards
In-reply-to: Winfield's message of 27 Aug. 1982 9:53 am PDT (Friday)
To: Winfield
cc: TonyWest, Mass, Murray

Bill:

I had assumed that the Dolphin extender boards suffer from the same problem that the Dolphin Stitchweld cards suffer from when used for DLions, namely that the cut-out slot is slightly different (or the connectors are slightly different, whichever way you choose to look at it), and thus, when inserting a board, or an extender board, it is possible to misalign it and thus cause damage.


SDD said "We have found that you can use Dolphin stitchweld boards for the Dandelion", but they recommended strongly not doing so.

Is my model correct?  

I believe that, if something can possibly go wrong, it will, so investing in a couple of DLion Extenders would be worth it.

Tony

*start*
03512 00024 US 
Date: 27-Aug-82 15:50:42 PDT (Friday)
From: Cude.PA
Subject: Large Dandelion Memory Mod's
To: Boggs, Murray, TonyWest, Mitchell
cc: 

FYI

------------------------------
Date: 23-Feb-82 13:19:01 PST (Tuesday)
From: Cude.PA
Subject: Re: Mods to Dlion MSC
To: DMurray.WBST
cc: Wick, Cude.PA

Dan,

John asked me to send you the following:

This is a summary of the levels of compatibility of the various MCC and MSC boards.  The boards to be distinguished are the following:


MCC			- Memory Controller, 16K-RAM based, 64K words present
MSC			- Memory Storage, 16K-RAM based, 128K words present

MCC-X (Etch1)	-] Memory Controller, 64K-RAM based, 256K words present
MCC-X (Etch2)	-]

MSC-X		- Memory Storage, 64K-RAM based, 64K-512K words present


The valid combinations are as follows:


Combination		Total memory size (words)		Rework required
				

MCC + MSC			192K				none

MCC-X(E1)  alone		256K				none
MCC-X(E2)  alone		256K				none			

MCC-X(E1) + MSC		384K				MCC-X rework:
								  4 cuts, 27 jumpers
								  10 resistors removed

MCC-X(E2) + MSC		384K				MCC-X rework:
								  4 cuts, 5 jumpers
								  10 resistors removed

MCC-X(E1) + MSC-X	320K to 768K			MCC-X rework:
								  22 jumpers

MCC-X(E2) + MSC-X	320K to 768K			none			

		Rework of the Etch-1 MCC-X to support the MSC module.

Notes:
	This rework will render the MCC-X module incompatible with the MSC-X.
	This rework should not be applied to the MCC-X Etch 2 module.

1.  Address selection modification (Enables MSC using 16k RAMs):

	-  Cut trace  from E036 to edge pin via
	-  Cut trace  E136, component side, between edge pin via and via adjecent to c131 (-) via
	-  Cut trace  E037, component side, between edge pin via and via between c128 and u153, cut should be made adjecent to C131 (-) via
	-  Cut trace  E137, solder side, between edge pin via and via adjecent to pin 140
	-  Connect  u167.02 to E036, connection to the edge pin is made on the pin but must not extend more than .200" on to the pin
	-  Connect  u167.05  to via for E136
	-  Connect  u112.06 to via for E037
	-  Connect  u112.08 to via for E137
	-  Connect  u174.13 to u174.07

2.  Removal of termination resistors:

-  Remove  R77 (220ohm, 1/4w)
-  Remove  R78 (220ohm, 1/4w)
-  Remove  R79 (220ohm, 1/4w)
-  Remove  R80 (220ohm, 1/4w)
-  Remove  R81 (220ohm, 1/4w)
-  Remove  R82 (220ohm, 1/4w)
-  Remove  R83 (220ohm, 1/4w)
-  Remove  R84 (220ohm, 1/4w)
-  Remove  R85 (220ohm, 1/4w)
-  Remove  R86 (220ohm, 1/4w)


3.  Connect memory Input Data to Storage Card:

-  Connect  u150.02 to E096 (SDI.00z)
-  Connect  u150.05 to E196 (SDI.01z)
-  Connect  u150.06 to E095 (SDI.02z)
-  Connect  u150.09 to E195 (SDI.03z)
-  Connect  u150.12 to E094 (SDI.04z)
-  Connect  u150.15 to E194 (SDI.05z)
-  Connect  u150.16 to E093 (SDI.06z)
-  Connect  u150.19 to E193 (SDI.07z)
-  Connect  u162.02 to E092 (SDI.08z)
-  Connect  u162.05 to E192 (SDI.09z)
-  Connect  u162.06 to E091 (SDI.10z)
-  Connect  u162.09 to E191 (SDI.11z)
-  Connect  u162.12 to E089 (SDI.12z)
-  Connect  u162.15 to E189 (SDI.13z)
-  Connect  u162.16 to E088 (SDI.14z)
-  Connect  u162.19 to E188 (SDI.15z)
-  Connect  u111.05 to E087 (SDI.16z)
-  Connect  u126.05 to E187 (SDI.17z)
-  Connect  u127.05 to E086 (SDI.18z)
-  Connect  u128.05 to E186 (SDI.19z)
-  Connect  u129.06 to E085 (SDI.20z)
-  Connect  u130.06 to E185 (SDI.21z)


Roy Ogus, 11 Jan. 1982

----------------------------------------------------------------
*start*
01392 00024 US 
Date: 1 Sept. 1982 6:52 pm PDT (Wednesday)
From: TonyWest.PA
Subject: Dandelion with Extended CS
To: DLionCS^, Garner, Ogus, AKTsang, CSL^, Murray, Dalal
Reply-To: TonyWest.PA

The first stitchweld version of the Dandelion CP with extended control store facilities burst into life today and ran Pilot.

Debugging the prototype was done together with Hal Murray, who has been using a new version of Burdock running under Pilot on another Dandelion.  Credit for the debugging is mostly due to Hal's unstinting efforts and creative insight.

Although the first prototype has only 8K of Control Store, all the logic is there to drive more memory if I can find somewhere to put it.  I think it will be possible to fit another bank of 4K on a new stitchweld revision, making a total of 12K.  Were we to go to a PC design similar to the production Dandelion CP, the full 16K would fit.

The Control Store is made of 4K by 4 Static Rams, so it is incrementally expandable in 4K chunks.  The machine runs the standard diagnostics and boots in a default 4K mode, where all the microcode is loaded into bank 0.  (Ie, the Bank register is reset to 0 by the IOP by default).

Yet to test:  The bank register.  A new decode is implemented to allow microcode to load the bank register with a Bank_ instruction.  Hal is adding some new facilities to Burdock to test this logic.

Tony
*start*
01026 00024 US 
Date:  2-Sep-82  0:52:43 PDT (Thursday)
From: Murray.PA
Subject: Extracting error code from Sunlight
To: Garner
cc: TonyWest, Ogus, Fay, Frandeen, Fasnacht, Neely, Murray.PA

I'm asking you since Roy is on vacation...

Since Tony's new CP didn't work well enough to run the Kernel (U Regs were dead), we had a hard time finding out what Sunlight was trying to tell us.  I patched it to stuff the error code into IOPOData and wrote a hack to read it via the IOP Kernel.  For some reason, it didn't work.  We ended up using a logic analyzer.

I just tracked down the problem, but that uncovers a corner of the world that I don't understand.  The code in the IOP Kernel that reads a byte from the CP tests for a CPInIntReq rather than CPInWakeReq.  CPInIntReq is CPInEnabled latched by IOPOData_.  CPInEnabled is WakeMode.0 OR WakeMode.1 from IOP Control.  The bug in my patch to Sunlight was that I wasn't turning on WakeMode.

Can you explain what's going on here?  Why the asymetry between in and out?
*start*
04028 00024 US 
Date: 2 Sept. 1982 11:25 pm PDT (Thursday)
From: Garner.PA
Subject: Bank Register
To: Murray
cc: TonyWest, Boggs, Ogus, AKTsang, DDavies, ABell, Garner

Hal,

Currently store is written as follows (if my memory is correct.  See the DLion
hardware manual also):

(1)  the IOP raises IOPWait followed by SwTAddr.  IOPWait causes the CP to
enter the Kernel and SwTAddr causes the Nt and NIAX lines to be driven by the
IOP TPCHigh and IOP TPCLow registers (p. 24).  By doing this, Nt is set to 6,
thereby addressing TPC[6] which holds the intrabank store address. 

When the Switch Prom (p. 14) sees Nt=6 and Wait=TRUE, it sets Swc2=TRUE
which causes NIA (the store address reg) to be loaded from TPC[6], thereby
addressing the store location to be read or written.

(2)  In the case of writing, the IOP places the byte on the IOPData bus and
asserts CSWE.n'which is a register in the IOP's memory or IO address spaces.

(3)  When the IOP is done, it sets Nt back to 7 (Kernel) by writing the IOP
TPCHigh register.  This causes the store to read the "next" inst the Kernel
wanted to execute before it was rudely interrupted by Wait.  When Wait is
removed, this Kernel instruction will begin executing.   [Note:  The IOP doesn't
bother with this step if this is the first time the store is being written, as there
isn't yet a Kernel to return to & do main memory refreshes.] 

Recall that when Wait=TRUE no sensetive CP state is written (e.g., CS Parity
error).   Note that the IOPWait signal is synchronized on the IOP card.  This
IOPWait is then made synchronous to the c1-c2-c3 cycles on p.16 of the CP
schematics (i.e., Wait always comes up at the beginning of c1 and drops at the
end of c3).

The Switch Prom has an output called "IOBank" which when TRUE sets the
highest NIA (bank) bits to zero and when FALSE loads them from the Bank
register.  Basically, the bank NIA bits are loaded from the bank register either
when reading/writing store or when the CP is normally executing Emulator
instructions.  In all other cases, the IOBank (bank 0) is used when fetching
instructions.  (I realized while composing this message that the truth table for
the Switch Prom that I previously gave Tony is wrong.  See the next message!)


For loading a random bank of store, my model is:

(1) Burdock writes into the Kernel overlay the code necessary to write the Bank
register with the desired value.  When executed by the Kernel, the Bank register
is loaded, but since the Kernel is forced to execute out of the IOBank by the
Switch Prom, this will not effect the Kernel.  Thereafter, Burdock should insure
that control does not leave the Kernel.

(2)  The IOP comes along as discussed above to write or read the store.  The
Switch Prom again notices that Nt=6 and Wait=TRUE.  In this case,
IOBank=FALSE and thus the uppper NIA bits come from the Bank register,
thereby writing the appropriate bank of store.

(3)  As in step (3) above, the IOP sets Nt_7 and the Kernel gets its restart
address from TPC[7] and the highest NIA bits are set to IOBank.*  (see the
SwitchProm truth table)

(4)  When the time comes to start the loaded code, the Kernel overlay is written
with the usual code which loads the Bank register followed by a normal
ExitKernel command.  If the Emulator is going to run next, then it will execute
at a location dictated by the Bank register.  If an IO device, however, is slated to
run next, control will remain in the IOBank.

I hope this explains my scheme for how this all works.

Robert


P.S.  I'm gone on vacation next week.  I'm planning to be "in" tommorrow (I'll
probably be in SDD writing a DLion paper.  I'll come by if you're in).  I'll also
be in for a few hours on Tuesday morning.


* I just noticed a potential bug here:  Since the setting of Nt to 7 is
asynchronous to the CP, and this signal goes through a Prom, this could cause
Swc2 to accidentally get set to 0 for one cycle (or Swc2'=Swc2 or Swc3'=Swc3). 
No harm though, since Wait is still true.  


*start*
01441 00024 US 
Date: 3 Sept. 1982 12:31 am PDT (Friday)
From: Garner.PA
Subject: Switch Prom
To: TonyWest
cc: Murray, Ogus, AKTsang, DDavies, ABell, Garner

Tony,

Here is the new truth table for the SwitchProm.  Hopefully, this one is correct. 
It is ordered by c2, Wait, Ct & Nt.


Ct	Nt	Wait	c2	Switch	IOBank	comments

Emu	*	F	F	No		No		emu instrs from bank reg
~Emu	*	F	F	No		Yes		non-emu insts in iobank

Emu	*	T	F	No		No		display suspended click
IO	*	T	F	No		Yes		display suspended click
Kern	*	T	F	Yes		Yes		kernel resume address

6	*	*	*	Yes		No		write CS location


Emu	Emu	F	T	No		No		no task switch
Emu	Emu	T	T	Yes		No		emu restart after suspend
Emu	Kern	F	T	No		Yes		kern breakpoint entry
Emu	Kern	T	T	Yes		Yes		kern "mouse halt" entry
Emu	IO	*	T	Yes		Yes		task switch

IO	Emu	*	T	Yes		No		task switch
IOa	IOa	F	T	No		Yes		n.a.
IOa	IOa	T	T	Yes		Yes		n.a.
IOa	IOb	*	T	Yes		Yes		task switch.
IO	Kern	F	T	No		Yes		kern breakpoint entry
IO	Kern	T	T	Yes		Yes		kern "mouse halt" entry

Kern	Emu	*	T	Yes		No		task switch
Kern	IO	*	T	Yes		Yes		task switch
Kern	Kern	F	T	No		Yes		no task switch
Kern	Kern	T	T	Yes		Yes		kernel resume address


I think the code is something like (No=FALSE and Yes=TRUE):

Switch _ c2 and (Wait or (Ct#Nt and Nt#Kern))
	 or Ct=6 or (~c2 and Wait and Ct=Kern)
IOBank _ (c2 and Nt#Emu) or (~c2 and Ct#Emu and Ct#6);


Robert


P.S.  I should probably look at this one more time since its late...




*start*
01796 00024 US 
Date: 3 Sept. 1982 5:51 pm PDT (Friday)
From: Taft.PA
Subject: Cedar runs on Dandelion
To: CedarInterest^
Reply-To: Taft

... but you wouldn't want to start using it just yet.

The purpose of this exercise was to get Cedar working on a Dandelion without
any special microcode (just standard Rubicon Pilot microcode) so as to establish a
stable base for Dandelion Cedar microcode development being done by Howard
Sturgis.  That is, all of the Cedar opcodes (allocator, garbage collector, floating
point, etc.) trap to software.  Now the microcode can be developed and checked
out, one opcode (or less) at a time.

Running on a 256K Dandelion (in the alcove across from Linda's desk), Cedar's
performance is so bad as to make it unusable.  This Dandelion will soon be
upgraded to 768K, which should eliminate most thrashing (remember that Cedar
has not been tuned or packaged, and is using Rubicon rather than the denser
Trinity instruction set).  However, the user interface (Viewers and Cedar
Graphics) is so heavily dependent on floating point that it will still not be
particularly usable until a substantial portion of the floating point microcode has
been completed (Howard is working on that first).

There are also a few trivial Cedar changes that will be needed, such as an
alternative for the nonexistent middle mouse button (perhaps the Tajo-style
left+right combination).

Bringing up Cedar on a Dandelion was supposed to be easy, since everything it
depended on was already working.  However, it actually took over a week,
during which we found:

  -- 4 bugs in Cedar (all will be fixed in the Cedar 3.4 release)
  -- 3 bugs in the Rubicon Pilot microcode (one of which still exists in Trinity)

Many thanks to Howard Sturgis and Roy Levin for their help.
	Ed

*start*
01911 00024 US 
Date:  6-Sep-82 21:31:15 PDT (Monday)
From: Murray.PA
Subject: Burdock, second bank...
To: Fay, Frandeen, Neely, Fasnacht, Sturgis
cc: TonyWest, Boggs, Schroeder, Howard, Garlick, Garner, Taft, Sandman, Murray.PA

On Saturday, Tony and I managed to fire up a program that jumps back and forth between banks.

There is a hardware quirk (bug in prom?) that also writes things into bank 0 when you write them into bank 1.  Since they do get to bank 1, and writing into bank 0 doesn't smash bank 1, you can load things into both banks if you are careful about the order.  (The same quirk makes it confusing to read bank 1.)

I have Burdock fixed up to find/use the second bank.  It puts a copy of the Kernel into the second bank.  That's more than necessary, but it should work.

Note that switching banks (from Burcock) is a bit tricky.  The bank register is used for 2 things: task 0, and  reading and writing CS.  Burdock uses an overlay to write the bank register.  The trick is that Burdock can't execute out of the bank it can write into once the bank register is non 0, so you can't write into Burdock's overlay area to reset the bank register.  My solution was to plant two instructions in the overlay area.  The second one doesn't get executed, but is all ready to set the bank back to 0.  (Fortunately, it gets used before you can write anything into the overlay area so you can't accidently smash it.)  Due to the write in both banks quirk, I managed to do a lot of bank switching before I noticed this.

I have split Mesa.db into an Emulator and an IO section.  I have a command file that loads the Emulator into the second bank and IO into bank 0.  There is only one problem: it doesn't work.  I may need some help from somebody who knows what's going on during booting.

I have discovered is a krock with CP breakpoints.  Things seem to go off the deep end unreasonably often.
*start*
00415 00024 US 
Date:  9-Sep-82 17:16:14 PDT (Thursday)
From: Murray.PA
Subject: Re: Bank_
In-reply-to: Neely's message of 9-Sep-82 13:54:46 PDT (Thursday)
To: Neely
cc: Murray, Fay, Howard, Sturgis, TonyWest

Great/thanks.

Bank_ is only valid in c1.  It's FY=13 decimal, D hex.  (Note that this is a different slot from what Garner's latest hardware manual describes.)

Do you need to know anything else?
*start*
02461 00024 US 
Date: 10 Sept. 1982 5:46 pm PDT (Friday)
From: TonyWest.PA
Subject: Extended Dandelion CP
To: DLionCS^, Dalal, Ogus, AKTsang, Murray, Garner, Diebert, Boggs
Reply-To: TonyWest.PA

Here is the parts list for Revision R of the Dandelion CP with extended control store.

In this revision, I have eliminated random diagnostic facilities in order to to squeeze a further 4K of control store onto the board, bringing the total amount of store up to 12K words.  There is no hope at all for the full 16K unless I convert the design to use the higher density 240 IC Dandelion Stitchweld board (for which the Route characterisation is still a little suspect).  

However, I am not sure that this epsilon is worth the effort.  Writing Dandelion code is not the world's most wondrous task.  My hat off to those who do it.  What might make it worth it, however, is if the conversion would enable me to add a DES encryption chip.

This board will run all of the standard Dandelion microcode without any changes, and, when booted, comes up with the Bank Register initialised to 0 by default.

The PROMS used are the same as those used for the standard CP, except for the SwitchProm, which is programmed differently.

If you want to look at the drawings, they are stored on
	[Ivy]<TonyWest>sCPE>sCPE-R.press

Tony West
8*923 4476

-------------------------------------------------------------------------------
IC Type		Qty	Comments
-------------------------------------------------------------------------------
AMD etc.:
AM2901C		4	2901B's would probably be OK	
AM25S09		8
AM25S10		4
AM27S07		7
AM74S253		1

Fairchild:
F93422A		4	SU Register file
F93427		3	PROM: 256 by 4 
F93453		5	PROM: 1024 by 4 

Inmos:
IMS1420-55	12, 24, or 36		70nS might also work, I will see.  Install
					them in banks of 4K, 12 chips per bank.

TI etc.:
SN74LS139		1
SN74LS161		1
SN74LS240		6
SN74LS244		3
SN74LS25		8
SN74LS283		1
SN74LS32		3
SN74LS374		4
SN74S00		4
SN74S02		1
SN74S04		2
SN74S08		1
SN74S10		2
SN74S138		8
SN74S151		3
SN74S158		3
SN74S175		1
SN74S182		1
SN74S20		1
SN74S240		1
SN74S241		5
SN74S257		4
SN74S260		1
SN74S280		6
SN74S373		2
SN74S374		9
SN74S38		1
SN74S51		1
SN74S64		4
SN74S86		1

Beckman:
Resnet Chip		1	ResNet Chip, 1 KOhm pullups
	
Miscellaneous:
20-pin platforms	2	Holds various resistors
40-pin IC socket	1	For a 2901.  6 wires have to be added by hand.
DB 37 Female	1	Connector used for Logic Analyzer Debugging


Tony West
8*923 4476
*start*
02357 00024 US 
Subject: Extended Dandelion CP
To: DLionCS^

Here is the parts list for Revision R, hopefully the final stitchweld revision of the extended Dandelion CP.

In this revision, I have managed to squeeze a further 4K onto the board, bringing the total amount of store up to 12K words.  There is no hope at all for the full 16K unless we

	either	a) use the higher density Dandelion Stitchweld board, for which
		the design automation characterisation is a little suspect,

	or	b) produce the PC version on ED-format boards, as used for the
		standard Etch CP.  

However, I really don't think that this epsilon is worth the effort -- writing Dandelion code is not the world's most wondrous task.  My hat off to those who do it.

This board will run all of the standard Dandelion microcode without any changes, and, when booted, comes up with the Bank Register initialised to 0 by default.

The PROMS used are the same as those used for the standard CP, except for the SwitchProm, which is programmed differently.

If you want to look at the drawings, they are stored on
	[Ivy]<TonyWest>sCPE>sCPE-R.press

Tony West
8*923 4476

-------------------------------------------------------------------------------
IC Type		Qty	Cost	Comments
-------------------------------------------------------------------------------
AMD etc.:
AM2901C		4	x	2901B's would probably be OK	
AM25S09		8	x
AM25S10		4	x
AM27S07		7	x
AM74S253		1	x

Fairchild:
F93422A		4	x	SU Register file
F93427		3	x	PROM: 256 by 4 
F93453		5	x	PROM: 1024 by 4 

Inmos:
IMS1420-55	12, 24, or 36		70nS might also work, I will see.  Install
					them in banks of 4K, 12 chips per bank.

TI etc.:
SN74LS139		1	x
SN74LS161		1	x
SN74LS240		6	x
SN74LS244		3	x
SN74LS25		8	x
SN74LS283		1	x
SN74LS32		3	x
SN74LS374		4	x
SN74S00		4	x
SN74S02		1	x
SN74S04		2	x
SN74S08		1	x
SN74S10		2	x
SN74S138		8	x
SN74S151		3	x
SN74S158		3	x
SN74S175		1	x
SN74S182		1	x
SN74S20		1	x
SN74S240		1	x
SN74S241		5	x
SN74S257		4	x
SN74S260		1	x
SN74S280		6	x
SN74S373		2	x
SN74S374		9	x
SN74S38		1	x
SN74S51		1	x
SN74S64		4	x
SN74S86		1	x

Beckman:
Resnet Chip		1	x	ResNet Chip, 1 KOhm pullups
	
Miscellaneous:
20-pin platforms	2	x	Holds various resistors
40-pin IC socket	1	x	For a 2901.  6 wires have to be added by hand.
DB 37 Female	1	x	Connector used for Logic Analyzer Debugging


Tony West
8*923 4476
*start*
04525 00024 US 
Date: 13 Sept. 1982 2:10 pm PDT (Monday)
From: TonyWest.PA
Subject: Extended Dandelion CP
To: Dalal
cc: Redell, Ogus, TonyWest, Lynch, White, Linden, Murray, Shoch

Yogen,

Here is a description of the CP I have been working on.  I am interested to know if there is any interest in the DES Encryption facilities I am proposing for this board, so please feel free to forward it as you think appropriate.

Tony

-----------------------
Extended Dandelion CP
-----------------------

A new version of the Dandelion CP is being implemented in PARC-CSL.  A stitchweld prototype has been fabricated and debugged, and I am now considering the addition of DES Encryption facilities.

The board replaces the standard CP in Dandelions, and offers Extended Control Store for microcode.  CSL's primary purpose in doing this work was to extend the CP to permit the addition of:

	- IEEE Floating Point microcode (Cedar Graphics)
	- reference-counting and garbage-collection microcode
	- other miscellaneous microcode functions

which are needed for the efficient implementation of the Cedar programming environment on the Dandelion.

The standard CP design was modified by adding a (single) Bank Register and decoder to allow the control store to be expanded to a maximum of 16 KWords.  By using the latest 16 Kbit Static Rams for control store instead of the older 4 Kbit Rams used in the standard CP, the 16 KWord control store only uses the same number of memory chips as the older 4K control store.

Of the two types of 16 Kbit Static Rams which might have been used, namely 16K by 1 bit or 4K by 4 bit Rams, the 4K by 4 devices were chosen to permit part of the control store to be socketed.  Thus, that the engineer can expand the basic 4K by 48 bit control store to 8K, 12K, or (projected for the PC version) 16K in the field by adding "Control Store Expansion Kits" of 12 chips.  The Rams are fairly expensive ($15-$20 in 100-off), so the ability to save on control store when the full complement is not required is regarded as advantageous.  Each 4K bank costs between $150 to $240, depending on purchase quantity.

The extended control store is accessible only to the emulator, task 0.  When the emulator is running, the bank register is enabled, and microinstructions are fetched from whichever memory bank is selected by the bank register.  When any of the other tasks are running (IOP, Disk, Ethernet, Display, etc.) the bank register is disabled and the bank defaults to 0, the lowest 4K bank.  Traps and errors do NOT affect the bank register, so there are trap handlers in each 4K bank.

The Bank register is also enabled when task 6, the dummy task used by the IOP to read or write control store, is active.  The IOP loads the CP with some instructions which set the bank register to a new value, lets the CP execute them, thus switching banks, then stops the CP to load microcode into the new bank.

When the Extended CP is booted by the IOP, the Bank register is reset to 0, so that all of the standard microcode runs without any changes in the bottom 4K bank.  It is only if a new emulator is loaded which contains the "Bank_" instructions, that the extended memory becomes active.  Note that all of the standard Dandelion Diagnostics also run without change.

A new version of Burdock has been prepared to run under Pilot on the Dandelion by Hal Murray.  This new Burdock has additional features to debug, test, and load microcode into the extended control store.  A new Dandelion-Dandelion Debugger box designed by SDD (Murray/Ogus) is being used to debug the Extended CP prototype.  Hal has implemented new Burdock diagnostic tests to check out the new control store addressing paths.

I am now considering the addition of DES Encryption hardware to the CP.  The scenario I have in mind is that  the encryption chips (probably AmZ8068) will interface with the X bus and appear as registers in the CP register address space.  There could then be a number of emulator DesBlt instructions which will implement memory-to-memory encryption operations.  A DES task is not contemplated.

Again, these facilities could be socketed to permit a field-upgrade with a "DES Option Kit" to the extended CP at a later stage, when the appropriate software is ready to use it.  The encryption throughput of the Am Z8068 approaches 13MBits per second, and I expect that the emulator should be able to drive the chips at around 80% of their rated capacity.  Some work is required yet to refine these figures.

*start*
00851 00024 US 
Date: 14 Sept. 1982 5:39 pm PDT (Tuesday)
From: TonyWest.PA
Subject: SWii Stitchweld Board
To: Lin.ES
cc: AKTsang.PA, Ogus.PA, McCreight.PA, TonyWest.PA

Chung:

Alan Tsang told me that you had been working on the characterisation of the new higher-density Dandelion stitchweld board for use with Route.  Alan also mentioned that he had encountered a number of minor difficulties using the board.  Are you able to summarise the difficulties which have been observed using the board?

I am interested in using the board for a rather tightly-packed Dandelion Extended CP design, and I am prepared to fix or extend the characterisation as necessary.  Would you be willing to let me have the BCPL source of your characterisation, and, if so, could you send me a pointer to where you have it stored?

Tony West

PARC-CSL
8*923-4476
*start*
01023 00024 US 
Date: 20-Sep-82 11:55:37 PDT (Monday)
From: Linden.PA
Subject: Re: DES on Dandelion board
In-reply-to: TonyWest's message of 13 Sept. 1982 2:10 pm PDT (Monday)
To: TonyWest
cc: Dalal, Redell, Ogus, Lynch, White, Linden, Murray, Shoch

There is at least general interest in DES on an optional Dandelion board.  At this time OSD does not have specific plans for introducing encryption hardware in the product line; however, we are doing an Authentication Service that will be able to handle the key distribution that will be needed.  Initially the Authentication Service will just be used to avoid transmitting plaintext passwords on the network, but we hope to be able to add document encryption capabilities soon thereafter.  Redell may be able to say more about the state of planning.
 
I don't think the organization is going to predict specific marketing requirements for encryption very far in advance of the actual competitive need, so it will be very useful to have some advance work done.   
*start*
01703 00024 US 
Date: 20-Sep-82 23:32:47 PDT (Monday)
From: Murray.PA
Subject: IOP, Bank, Overlays..
To: Fay, Frandeen
cc: Fasnacht, Neely, Howard, Sturgis, TonyWest, Murray.PA

While I think of it....

One of these days, we will probably ask you to do whatever it takes to get the IOP to load microcode into the second bank during normal booting.  (It gets a bit expensive if you have to have a Burdock machine around to use the second bank.)  I assume the right thing to do is procrastinate until the grand plan for how Mass and such support multi banks gets worked out.

Loading code into extra banks turns out to be a bit tricky.  The basic complication is that you have to use an overlay to set the bank register, and once you have set it, you can't write the overlay to reset it.  I think I have it all worked out in Burdock so come see me when you get that far.

That brings up the topic of overlays.  I assume that the IOP uses a few for one reason or the other  In particular, there is probably one to stuff the germ into memory when it gets into the IOP from the floppy and/or another to get the microcode from memory inot the IOP so it can be loaded into CS.  (There is a BootKernel that looks like it is ready to support overlays.)  Does anybody have a list of who/where/why the IOP uses overlays and/or how to recreate them?  My guess is that there is an obscure binary file that has been handed down for generations that is used as part of the PROM building recipe.  (It took me a while to recreate Burdock.overlays.)  If you can find the sources, don't be surprised if they get rejected by the current Mass -- I had to make a few edits to get Burdock's overlays to compile again.
*start*
00869 00024 US 
Date: 17 Sept. 1982 10:20 am PDT (Friday)
From: Lin.ES
Subject: Re: SWii board
In-reply-to: TonyWest.PA's message of 15 Sept. 1982 3:02 pm PDT (Wednesday)
To: TonyWest.PA
cc: Lin, AKTsang.PA, Ogus.PA, Thacker.PA, McCreight.PA

Tony:

Your messages were read this morning.  I will try to look at your layout sheets
and work with you.

In the mean time, these files should help you understand what we are trying to
do:
	[ISIS]<EDSIL>SilRouteAid.dm
and	[ISIS]<EDSIL>SilRouteAid.press

The general template and bcpl programs (called RouteBoard.template and
BasicRouteBrd.bcpl) are included in the dump file above.  The more specific
template and bcpl program as used for Alan Tsang's board can be retrieved from

	[ISIS]<EDSIL>SwII.template
and	[ISIS]<LIN>SwIIx.bcpl

I hope this will help you getting acquainted with this version of route.

Chung

*start*
01684 00024 US 
Date: 21 Sept. 1982 4:49 pm PDT (Tuesday)
From: TonyWest.PA
Subject: Dandelion Extender boards
To: Ogus.PA, Haney.EOS
cc: Winfield.PA, Thacker.PA, TonyWest.PA, Purcell.PA, Garner.PA, Zdybel.PA, Bice.ES, Dawson.PA

Gentelmen:

I have been trying to discover a source from which I can obtain extender boards for Dandelions.  After following up a few pointers, I come to the following conclusions:

1. There is no official Xerox part number for a Dandelion Extender board yet (!)

2. Most of the boards built so far were made to order by ED - contact Roger Peltz, 8*823-7644.  When I asked him if ED were still prepared to make these boards, he said that they were.  Price around $600 in 1-off, delivery in about 6-8 weeks.

4. I also called Bill Bice in SDD, El Segundo, 8*823-7524.  SDD have now set up an arrangement with SDD in Dallas to get the boards made in Dallas - contact Jim Daughtee, 8*724-3353.

When I called Jim, he said that anyone could buy boards via an internal transfer, but he had to make them in batches of 50.  He has just completed a batch of 50, which are all committed, and says that he has received a letters of intent for 30 boards of the next batch.  The price is *around* $250, delivery also 6-8 weeks.

So far, the following groups have expressed interest in ordering boards from the next batch:

	Others:	unknown		-	30

	PARC:	CSL			-	3
			Bill Winfield	-	2 

	SDD:		Roy Ogus		-	5?


Question:

Does your organisation require any of these boards and are you able to commit a firm letter of intent for the order by 9/27/82?  

If so, please reply ASAP with details of quantity, etc., and I will send you further instructions.

Tony
*start*
00987 00024 US 
Date: 24 Sept. 1982 1:33 pm PDT (Friday)
From: TonyWest.PA
Subject: Dandelion Extenders
To: Bice.ES
cc: Ogus.PA, TonyWest

Bill:

I spoke to Jim Daughtee who said that I should let you know how many boards we are ordering.

Jim really wants to make the 50-off mark since this both simplifies his accounting as well as gaining us the substantial price discount for quantity.  I don't actually know what the state of affairs is between you and Jim, ie., how many boards you have signed up for, but perhaps you could let me know so that we can see how near he is to 50?

My idea is that if he is within a few boards, then Roy Ogus and I *might* be able to take up the slack.  We have both signed up for 4 boards.

My understanding of Jim's orders is:

	Field Engineering	(?)		30
	Bill Bice		(SDD)		x
	Roy Ogus		(SDD)		4
	Tony West		(PARC)	4
	Bill Winfield	(PARC)	2
	--------------------------------------
	TOTAL				40+x
	--------------------------------------

Tony
*start*
01203 00024 US 
Date: 27 Sept. 1982 3:32 pm PDT (Monday)
From: TonyWest.PA
Subject: Extenders, 27 Sept. 
To: TonyWest

Position on 27 Sept. 1982 3:31 pm PDT (Monday)

---------------------------

Date: 24 Sept. 1982 1:33 pm PDT (Friday)
From: TonyWest.PA
Subject: Dandelion Extenders
To: Bice.ES
cc: Ogus.PA, TonyWest

Bill:

I spoke to Jim Daughtee who said that I should let you know how many boards we are ordering.

Jim really wants to make the 50-off mark since this both simplifies his accounting as well as gaining us the substantial price discount for quantity.  I don't actually know what the state of affairs is between you and Jim, ie., how many boards you have signed up for, but perhaps you could let me know so that we can see how near he is to 50?

My idea is that if he is within a few boards, then Roy Ogus and I *might* be able to take up the slack.  We have both signed up for 4 boards.

My understanding of Jim's orders is:

	Field Engineering	(?)		30
	Bill Bice		(SDD)		x
	Roy Ogus		(SDD)		4
	Tony West		(PARC)	4
	Bill Winfield	(PARC)	2
	Terry Haney		(EOS)		3		*** new ***
	--------------------------------------
	TOTAL				43+x
	--------------------------------------

Tony
*start*
00508 00024 US 
Date: 29 Sept. 1982 4:43 pm PDT (Wednesday)
From: TonyWest.PA
Subject: Daughtee's boards
To: Ogus
cc: Bice.ES, TonyWest

If Daughtee is building Bice's 6 boards as part of the coming build, the position should be

	Field Engineering	(?)		30
	Bill Bice		(SDD)		6
	Roy Ogus		(SDD)		4
	Tony West		(PARC)	4
	Bill Winfield	(PARC)	2
	Terry Haney		(EOS)		3
	--------------------------------------
	TOTAL				49
	--------------------------------------

I will call Daughtee to find out.

Tony
*start*
00331 00024 US 
Date:  6-Oct-82 11:03:02 PDT (Wednesday)
From: Carlsen.PA
Subject: Dandelion Extender boards
To: TonyWest.PA
cc: , Carlsen

Sorry it's taken so long to respond to this request.

We would like to have 1 DLion extender board.I will respond to further instructions as soon as I hear  from you.

Thanks,
George
*start*
00253 00024 US 
Date:  6-Oct-82 14:17:22 PDT (Wednesday)
From: Carlsen.PA
Subject: Re: Dandelion Extender boards
In-reply-to: Your message of 6 Oct. 1982 12:00 pm PDT (Wednesday)
To: TonyWest

I'm responding for John Dawson at Versatec.

George
*start*
00384 00024 US 
Date: 6 Oct. 1982 2:38 pm PDT (Wednesday)
From: TonyWest.PA
Subject: Extenders 10/6
To: TonyWest.PA

	Field Engineering	(?)		30
	Bill Bice		(SDD)		6
	Roy Ogus		(SDD)		4
	Tony West		(PARC)	4
	Bill Winfield	(PARC)	2
	Terry Haney		(EOS)		3
	George Carlsen	(Versatec)	1
	--------------------------------------
	TOTAL				50
	--------------------------------------

*start*
01033 00024 US 
Date: 25 Oct. 1982 4:39 pm PDT (Monday)
From: TonyWest.PA
Subject: SilRouteAid and Route.run
To: TonyWest.PA

Subject: SilRouteAid and Route.run
To: Inouye.ES
cc: AKTsang, Ogus, Lin.ES, McCreight, TonyWest

Steve:

Since ED modified Route for use with the database/template stuff, McCreight has
made a number of improvements and repairs.  Is there any sense to the idea of
redoing the modifications starting from our latest version of Route so that we all
can converge on a single version?

How many changes have ED made -- do they represent a lot of work?
With respect to SilRouteAid, is the stuff you added to implement the /i option
nicely collected together in one procedure, or something?  Would putting that
into our Route be easy or difficult?

Since I have been having a lot of trouble getting at [ISIS]<EDSIL> because of
communications failures, I would favour an approach where we have a second
copy of the appropriate stuff here.

Tony
------------------------------------------------------------

*start*
00305 00024 US 
Date: 21 Oct. 1982 3:35 pm PDT (Thursday)
From: Lin.ES
Subject: SilRouteAid
To: TonyWest.PA
cc: Inouye.es, Ogus.PA, AKTsang.PA, Lin

A revised user document of SilRouteAid has been completed by it's author, Steve
Inouye.  Please retrieve it from [ISIS]<EDSIL>SilRouteAidRev.press

*start*
00529 00024 US 
Date: 25 Oct. 1982 4:38 pm PDT (Monday)
From: HANEY.EOS
Subject: Re: DLion Boards
In-reply-to: Your message of 25 Oct. 1982 1:25 pm PDT (Monday)
To: TonyWest.PA
cc: Haney

THANK YOU TONY,

IT SEEMS THAT XEOS HAS FUNNY ACCOUNT NUMBERS THAT DO NOT PLAY
IN ANYBODY REAL'S SYSTEM. I TALKED TO NORB ABOUT THIS AND HE
SAID THAT IT WAS OK FOR PARC TO BUY THEM AND SELL THEM TO US.


AGAIN THANKS FOR THE HELP.

PS. ARE THE LARGE CONTROL STORE BOARDS FOR DANDELION GOING TO
GO TO ETCH IN THE NEAR FUTURE.

TERRY

*start*
55411 00024 US 
Date: 26 Oct. 1982 11:23 am PDT (Tuesday)
From: TonyWest.PA
Subject: Route Differences
To: Inouye.es
cc: TonyWest, McCreight.pa

Steve:

I compared your route sources with those on [Indigo]<DoradoLogic>Route.dm

There are many differences:

1. Both versions of route have additional files which the other version doesn't have.  They are

ED Route			CSL Route

routeinitrb.bcpl		routeswapzone.bcpl
router.bcpl			routeheuristic.bcpl
router1.bcpl			routespantree.bcpl
routenet.bcpl			routecombin.bcpl
				routearclen.bcpl
				routenetswap.bcpl
				routenetres.bcpl
				routecomputeclusters.bcpl
				routesort.bcpl	
				routedosorted.bcpl
				routesperge.bcpl
				routelength.bcpl
				routeresist.bcpl
				routemultiwire.bcpl
				routepc.bcpl


There would appear to be a lot of stuff which has been added to CSL route.

2. The common source files have differences.  These are summarised below.  The ED version of a file is prefixed with ed.

3. routecorrect.bcpl probably differs also -- I didn't compare it.

4. I don't know what the right next step is -- perhaps ED might consider upgrading to CSL Route by reinserting the /i option stuff -- it seems pretty self-contiained.

5. I am on the verge of converting back to CSL Route and writing an old-fashioned board characterisation.  The template stuff just seems to get me into water an order of magnitude deeper than I am prepared to deal with right now.

Tony


Waterlily                          Version 1.6                             26-Oct-82 10:51:03 PDT


Differences between files route.bcpl and edroute.bcpl:

*******************************************************************
1/000) //route.bcpl
1/001) // Main driver module
1/002) // last modified by McCreight, October 30, 1981  2:58 PM
1/003) get "sysdefs.d"
**************************************
2/000) //route.bcpl
2/001) // Main driver module
2/002) // last modified by mcnair, October 5, 1979  6:32 PM, dated for our diagnostic version
2/003) // last modified by Taft, September 22, 1979  7:06 PM
2/004) // last modified by Inouye, to solve prob of wiring side on the bottom in conjunction with add-delete file October 16, 1980  4:22 PM
2/005) // last modified by Inouye to put in Sil-Route aid changes June 29, 1981  9:50 AM
2/006) // last modified by Inouye for gate array dip package August 6, 1981  11:24 AM
2/007) // last modified by Inouye for board rotation problem October 14, 1981  10:16 AM
2/008) get "sysdefs.d"
*******************************************************************
1/017) @OverlaySave
1/018) DeclareOverlayPresent
1/019) currOverlay
1/020) initCodeEnd
1/021) overlayCore
1/022) npBiggestOverlay
1/023) dsp
**************************************
2/022) initCodeEnd
2/023) overlayCore
2/024) dsp
*******************************************************************
1/030) swapZone = empty
1/031) currOverlay = empty
1/032) ]
**************************************
2/031) ]
*******************************************************************
1/035) routeVersion = "Route - October 30, 1981"
1/036) PutTemplate(dsp, "*n*n*n*n*n$S", routeVersion)
1/037) OnceOnlyInitCode(blv,params,cfa)
**************************************
2/034) routeVersion = "Route - October 14, 1981  ..has ED/CASD Sil Route Aid changes"
2/035) //  changes to allow bertter diagnostic features in checkout of board definition
2/036) PutTemplate(dsp, "*n*n*n$S", routeVersion)
2/037) OnceOnlyInitCode(blv,params,cfa)
*******************************************************************
1/042) PutTemplate(dsp, "$S ... finished", routeVersion)
1/043) finish
1/044) ]
1/045) and SwapIn(ent) be
1/046) [
1/047) if ent!1 eq #6000+lv OverlaySave then
1/048) [ // JSR@ OverlaySave means swapped-out special entry
1/049) let od = ent!2
1/050) DeclareOverlayPresent(od, UserReadOverlay(od))
1/051) ] 
1/052) ]
1/053) and UserReadOverlay(od) = valof
1/054) [
1/055) if currOverlay ne empty then
1/056) [
1/057) LockPendingCode()
1/058) test ReleaseOverlay(currOverlay, false)
1/059) ifnot CallSwat("Two overlays contending for overlay space")
**************************************
2/042) PutTemplate(dsp, "*n*n$S ... finished", routeVersion)
2/043) finish
2/044) ]
2/045) and UserReadOverlay(od) = valof
2/046) [
2/047) static [ oldOverlay = empty ]
2/048) if oldOverlay ne empty then
2/049) [
2/050) LockPendingCode()
2/051) test ReleaseOverlay(oldOverlay, false)
2/052) ifnot CallSwat("Two overlays contending for overlay space")
*******************************************************************
1/062) ReleaseOverlay(currOverlay, true)
1/063) currOverlay = empty
1/064) ]
1/065) ]
1/066) if swapZone ne empty &
1/067)   Usc(overlayCore+256*OverlayNpages(od), swapZone) ge 0
1/068)     then CallSwat("Overlay wants swapZone space")
1/069) ReadOverlay(OverlayFirstPn(od), overlayCore, OverlayNpages(od))
1/070) currOverlay = od
1/071) resultis overlayCore
**************************************
2/055) ReleaseOverlay(oldOverlay, true)
2/056) oldOverlay = empty
2/057) ]
2/058) ]
2/059) ReadOverlay(OverlayFirstPn(od), overlayCore, OverlayNpages(od))
2/060) oldOverlay = od
2/061) resultis overlayCore
*******************************************************************
1/075) static [ stackNeeds = 1000 ]
1/076) AddSpace(stackNeeds)	// leave for stack
**************************************
2/065) static [ stackNeeds = 1800 ]
2/066) AddSpace(stackNeeds)	// leave for stack
*******************************************************************
1/175) MapNamees(typeIcinst, MakeConnInstFile)
1/176) MakeOldBPFile()
1/177) MakeLoadingChart()
1/178) if doMultiWire then MultiWire()
1/179) if doPC then PC()
1/180) if doResistances then MakeResistanceFile()
1/181) Puts(ErFile, $*n); TruncateDiskStream(ErFile); Resets(ErFile)
**************************************
2/165) OutputBPFiles()
2/166) Puts(ErFile, $*n); TruncateDiskStream(ErFile); Resets(ErFile)
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:53:28 PDT


Differences between files routea.bcpl and edroutea.bcpl:

*******************************************************************
1/000) //routea.bcpl
1/001) // Net-list file read-in phase
1/002) // last modified by E. McCreight, October 30, 1981  2:33 PM
1/003) get "route.defs"
**************************************
2/000) //routea.bcpl
2/001) // Net-list file read-in phase
2/002) // last modified by E. McCreight, May 11, 1979  6:30 PM
2/003) get "route.defs"
*******************************************************************
1/052) let net = DefineNamee(snv, typeNet, NewNet)
**************************************
2/052) // CallSwat("In ReadNetLine..Calling DefineNamee... snv is:",snv)
2/053) let net = DefineNamee(snv, typeNet, NewNet)
*******************************************************************
1/073) GetPin(ins, net, attributes,clusterNumber)
1/074) ]
**************************************
2/074) // CallSwat("back from defineNamee, going to GetPine, attributes are:",attributes)
2/075) GetPin(ins, net, attributes,clusterNumber)
2/076) // CallSwat("Back from getPin")
2/077) ]
*******************************************************************
1/134) net>>net.hasBeenRouted = false
**************************************
2/137) let sperge = Sperge(x,y)
2/138) if Usc(sperge, net>>net.minSperge) ls 0 then net>>net.minSperge = sperge
2/139) net>>net.hasBeenRouted = false
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:54:24 PDT


Differences between files routeb.bcpl and edrouteb.bcpl:

*******************************************************************
1/000) //routeb.bcpl
1/001) // Output module
1/002) // last modified by E. McCreight, July 2, 1981  10:13 AM
1/003) get "route.defs"
**************************************
2/000) //routeb.bcpl
2/001) // Output module
2/002) // last modified by E. McCreight, May 11, 1979  6:25 PM
2/003) get "route.defs"
*******************************************************************
1/010) twPartNo
1/011) ]
**************************************
2/010) ]
*******************************************************************
1/049) twPartNo = 0
1/050) DoInSortOrder(typeNet, NameCompareFn,
**************************************
2/048) DoInSortOrder(typeNet, NameCompareFn,
*******************************************************************
1/199) let netName = vec 30
1/200) test net>>net.isPartialNet
1/201) ifso
1/202) [
1/203) ExpandTemplate(netName, "$S$D", FindNameesString(net),
1/204)   twPartNo)
1/205) twPartNo = twPartNo+1
1/206) ]
1/207) ifnot netName = FindNameesString(net)
1/208) PutTemplate(currentFile, "*n*n$S: <$D> ($D)", netName,
1/209)  netnum+baseNetNumber-1, net>>net.netlength)
**************************************
2/197) PutTemplate(currentFile, "*n*n$S: <$D> ($D)", FindNameesString(net),
2/198)  netnum+baseNetNumber-1, net>>net.netlength)
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:54:56 PDT


Differences between files routebackpanel.bcpl and edroutebackpanel.bcpl:

*******************************************************************
1/000) //routeBackPanel.bcpl
1/001) // Backpanel & Other auxiliary descriptive files module
1/002) // last modified by McCreight, June 25, 1981  10:02 AM
1/003) get "streams.d"
**************************************
2/000) //routeBackPanel.bcpl
2/001) // Backpanel & Other auxiliary descriptive files module
2/002) // last modified by Taft, September 16, 1979  8:20 PM
2/003) get "streams.d"
*******************************************************************
1/007) BPFile
1/008) ]
1/009) let MakeConnInstFile(icinst) be
1/010) [
**************************************
2/007) BPFile; doMultiWire=false
2/008) doResistances=false; conductance; resistanceFile
2/009) wiredPins; holesFile; holeSizes; holePlating; holeNet; currentHoleType
2/010) lastHoleType; pinsThisLine
2/011) ]
2/012) manifest [ plated = true; unplated = not plated ]
2/013) let OutputBPFiles() be
2/014) [
2/015) MapNamees(typeIcinst, MakeConnInstFile)
2/016) MakeOldBPFile()
2/017) MakeLoadingChart()
2/018) if doMultiWire then MultiWire()
2/019) if doResistances then MakeResistanceFile()
2/020) ]
2/021) and MakeConnInstFile(icinst) be
2/022) [
*******************************************************************
1/094) and TruncateAndClose(file) be
**************************************
2/106) 
2/107) and MultiWire() be
2/108) [
2/109) BPFile = GetFile(nlFileName, ".mw")
2/110) DoInSortOrder(typeNet, NetNumCompareFn, OutputMWNet)
2/111) FinishMWFile(BPFile)
2/112) let pinVecLen = (FindIndexFromCoord(-1,-1)+15)/16
2/113) wiredPins = Allocate(SilZone, pinVecLen)
2/114) Zero(wiredPins, pinVecLen)
2/115) MapNamees(typeIcinst, MarkUsedPins)
2/116) holesFile = GetFile(nlFileName, ".mh")
2/117) let hs = vec 20; holeSizes = hs
2/118) let hp = vec 20; holePlating = hp
2/119) let hn = vec 20; holeNet = hn
2/120) currentHoleType = 0
2/121) lastHoleType = 0
2/122) pinsThisLine = 0
2/123) DescribeHoles(PrintAHole)
2/124) Puts(holesFile, $*n)
2/125) FinishMWFile(holesFile)
2/126) Free(SilZone, wiredPins)
2/127) let indexFile = GetFile(nlFileName, ".mhi")
2/128) let netLine = vec 30
2/129) for i=1 to lastHoleType do
2/130)  PutTemplate(indexFile, "*nHole type $D: $D mils, $Splated$S",
2/131)   i, holeSizes!i, (holePlating!i? "","un"),
2/132)   (holeNet!i eq empty? "", ExpandTemplate(netLine, ", net = $S",
2/133)    FindNameesString(holeNet!i))))
2/134) PutTemplate(indexFile, "*n")
2/135) TruncateAndClose(indexFile)
2/136) ]
2/137) and NetNumCompareFn(n1, n2) = n2>>net.netnum-n1>>net.netnum
2/138) and OutputMWNet(net) be
2/139) [
2/140) static [ MWNetNum = 0 ]
2/141) let nodecount = 0
2/142) let pin = net>>net.pinList
2/143) while @pin ne mark do
2/144) [
2/145) pin = @pin
2/146) nodecount = nodecount+1
2/147) ]
2/148) if nodecount ls 2 then return
2/149) MWNetNum = MWNetNum+1
2/150) PutTemplate(BPFile, "$5D", MWNetNum)
2/151) let pinsThisLine = 0
2/152) let pin = net>>net.pinList
2/153) while @pin ne mark do
2/154) [
2/155) let x,y = nil,nil
2/156) GetPinCoord(0, pin, lv x, lv y)
2/157) if pinsThisLine ge 5 then
2/158) [
2/159) PutTemplate(BPFile, "*n$5D",  MWNetNum) // we re-iterate the net #
2/160) pinsThisLine = 0
2/161) ]
2/162) ComputeMWCoords(lv x, lv y, false)
2/163) PutTemplate(BPFile, "$S $5D $5D", (pinsThisLine gr 0? "   ",""),
2/164)  x, y)
2/165) pinsThisLine = pinsThisLine+1
2/166) pin = @pin
2/167) ]
2/168) PutTemplate(BPFile, "*n")
2/169) ]
2/170) and FinishMWFile(file) be
2/171) [
2/172) PutTemplate(file, "$5D*n", -1)
2/173) TruncateAndClose(file)
2/174) ]
2/175) and MarkUsedPins(icinst) be
2/176) [
2/177) let icclass = Icclass(icinst)
2/178) for i=1 to Npins(icinst) do if icinst>>icinst.pin^i ne empty %
2/179)  (not icclass>>icclass.isTraceWired) then
2/180) [
2/181) let x,y = nil,nil
2/182) GetPinCoord(icinst, i, lv x, lv y)
2/183) let index = FindIndexFromCoord(x, y)
2/184) SetBit(wiredPins, index, 1)
2/185) ]
2/186) ]
2/187) and PrintAHole(x, y, holeSize, isPlated, isMils, alwaysDrill; numargs na) be
2/188) [
2/189) static [ allPinsAreHoles = false; encodeTWNets = false ]
2/190) DefaultArgs(lv na, 3, true, false, false, false)
2/191) let icclass, pinNo = empty, 0
2/192) let index = FindIndexFromCoord(x, y, lv icclass, lv pinNo)
2/193) if allPinsAreHoles % alwaysDrill % index eq 0 %
2/194)  GetBit(wiredPins, index) ne 0 then
2/195) [
2/196) ComputeMWCoords(lv x, lv y, isMils)
2/197) let i=1
2/198) while i le lastHoleType &
2/199)  (holeSize ne holeSizes!i % isPlated ne holePlating!i %
2/200)   (encodeTWNets & (icclass ne holeNet!i))) do
2/201)   i=i+1
2/202) if i gr lastHoleType then
2/203) [
2/204) lastHoleType = i
2/205) holeSizes!i = holeSize
2/206) holePlating!i = isPlated
2/207) holeNet!i = encodeTWNets? icclass, empty
2/208) ]
2/209) if i ne currentHoleType % pinsThisLine ge 5 then
2/210) [
2/211) if pinsThisLine gr 0 then
2/212)  Puts(holesFile, $*n)
2/213) PutTemplate(holesFile, "$5D", i)
2/214) currentHoleType = i
2/215) pinsThisLine = 0
2/216) ]
2/217) PutTemplate(holesFile, "$S $5D $5D", (pinsThisLine gr 0? "   ",""),
2/218)  x, y)
2/219) pinsThisLine = pinsThisLine+1
2/220) ]
2/221) ]
2/222) and MultiWirePanic(x, y, z) be CallSwat("No board-specific multi-wire code")
2/223) 
2/224) and MakeResistanceFile() be
2/225) [
2/226) resistanceFile = GetFile(nlFileName, ".resist")
2/227) DoInSortOrder(typeIcinst,NameCompareFn,ScanICsNets)
2/228) TruncateAndClose(resistanceFile)
2/229) ]
2/230) and ScanICsNets(icinst) be
2/231) [
2/232) let icclass = Icclass(icinst)
2/233) if icclass>>icclass.isConnector %
2/234)   icclass>>icclass.isTraceWired then return
2/235) let icpkg = (icclass>>icclass.PinOffset eq DIP3Wide? "DIP3",
2/236) 	(icclass>>icclass.PinOffset eq SIP? "SIP", "OddPkg"))
2/237) PutTemplate(resistanceFile,
2/238)   "$S ($S, $D, $S) ",
2/239)   FindNameesString(icinst),
2/240)   icpkg, Npins(icinst),
2/241)   FindNameesString(icinst>>icinst.ictype))
2/242) for i=1 to Npins(icinst) do
2/243) [
2/244) NetResistance(icinst>>icinst.pin^i)
2/245) if i ne Npins(icinst) then Puts(resistanceFile,$,)
2/246) ]
2/247) Puts(resistanceFile, $*n)
2/248) ]
2/249) and NetResistance(pin) be
2/250) [
2/251) if pin eq empty then
2/252) [
2/253) Puts(resistanceFile, $$)
2/254) return
2/255) ]
2/256) let net = FindNet(pin)
2/257) if net eq dontCareNet then
2/258) [
2/259) Puts(resistanceFile, $?)
2/260) return
2/261) ]
2/262) conductance = 0	// in milliSiemens, infinity means short
2/263) if net>>net.isTraceWired then conductance = infinity
2/264) pin = net>>net.pinList
2/265) while @pin ne mark do
2/266) [
2/267) if conductance ne infinity then PinResistance(pin)
2/268) pin = @pin
2/269) ]
2/270) test conductance eq infinity
2/271) ifso Puts(resistanceFile, $0)
2/272) ifnot
2/273) [
2/274) test conductance eq 0
2/275) ifso Puts(resistanceFile, $$)
2/276) ifnot PutTemplate(resistanceFile,"$D",1000/conductance)
2/277) ]
2/278) ]
2/279) and PinResistance(pin) be
2/280) [
2/281) static [ Term100Ohms = empty]
2/282) if Term100Ohms eq empty then
2/283)   Term100Ohms = MustFindNamee("Term100/8/Term100",typeIctype)
2/284) let icinst = nil
2/285) FindIcinst(lv icinst, lv pin)
2/286) let icclass = Icclass(icinst)
2/287) let pinAttributes = (icclass>>icclass.PinAttributes)(icinst,pin)
2/288) if pinAttributes<<pinattributes.isTerminator then
2/289)   if icinst>>icinst.ictype eq Term100Ohms then
2/290)     conductance = conductance+10	// 100 ohms or 10 mS.
2/291) if icclass>>icclass.isConnector then
2/292)   conductance = conductance+10	// added termination at each connector
2/293) if icclass>>icclass.isTraceWired then
2/294)   conductance = infinity
2/295) ]
2/296) and TruncateAndClose(file) be
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:55:34 PDT


Differences between files routeboard.bcpl and edrouteboard.bcpl:

*******************************************************************
1/000) //routeboard.bcpl
1/001) // Setup for board-specific data structures.
1/002) // last modified by E. McCreight, June 23, 1981  6:45 PM
1/003) get "route.defs"
**************************************
2/000) //routeboard.bcpl
2/001) // Setup for board-specific data structures.
2/002) // last modified by R. McNair  , April 30, 1979  7:03 PM..still good  October 5, 1979  8:16 PM 
2/003) // last modified by E. McCreight, January 26, 1979  12:35 AM
2/004) // last modified by S. Inouye for Sil/route aid...major changes, June 10, 1981  8:57 AM
2/005) // last modified by Inouye for gate array dip July 31, 1981  12:06 PM
2/006) get "route.defs"
*******************************************************************
1/010) biv
1/011) DeclareInitialNets // to be filled in later with the real thing
**************************************
2/013) DeclareInitialNets // to be filled in later with the real thing
*******************************************************************
1/017) ComputePCCoords
1/018) DescribeHoles
1/019) OtherPCHoles
1/020) SetupMoreICClasses
1/021) AddDecouplingCaps
1/022) ]
1/023) let SetupBoard() be
1/024) [
1/025) DefineNeededNames()
**************************************
2/019) DescribeHoles
2/020) AddDecouplingCaps
2/021) ]
2/022) static
2/023) [  //SIL-Route aid stuff
2/024) NumPinRows
2/025) NumPinCols
2/026) PinCols
2/027) ICPins
2/028) GndPins
2/029) VEEPins
2/030) VCCPins
2/031) VDDPins
2/032) DipDesc
2/033) DipColVec
2/034) NumDipRows
2/035) NumDipCols
2/036) Conns
2/037) Econns
2/038) Cconns
2/039) ]
2/040) manifest
2/041) [
2/042) MaxXcheck=168
2/043) Xinc=4
2/044) Yinc=4
2/045) MaxYcheck=96
2/046) MinXcheck=0
2/047) MinYcheck=0
2/048) ]
2/049) let SetupBoard(filename) be
2/050) [
2/051) let file = OpenFile(filename, ksTypeReadWrite, wordItem, 0,
2/052)  0, 0, SilZone)
2/053) DeclareAvailableNames()
2/054) ReadBoardCode(file); Closes(file)
2/055) if InitializeRB then
2/056) [ //if board created with sil-route aid, initialize database
2/057) let slen=filename>>str.length
2/058) filename>>str.char^(slen-1)=$r
2/059) filename>>str.char^(slen)=$b
2/060) let file=OpenFile(filename,ksTypeReadOnly,charItem,0,0,0,SilZone)
2/061) if file eq 0 then CallSmartSwat("Cannot open $S file for route board initialization",filename)
2/062) InitRouteBrd(file)
2/063) Closes(file)
2/064) ]
2/065) DefineNeededNames()
*******************************************************************
1/033) for x=0 to 700 do for y = 0 to 700 do
1/034) [
1/035) let fclass,fpin = 0,0
1/036) let index = FindIndexFromCoord(x, y, lv fclass, lv fpin)
1/037) if index ne 0 then
**************************************
2/073) WeAre(7)
2/074) for x=MinXcheck to MaxXcheck by Xinc do for y = MinYcheck to MaxYcheck by Yinc do
2/075) [
2/076) let fclass,fpin = 0,0
2/077) let index = FindIndexFromCoord(x, y, lv fclass, lv fpin)
2/078) WeAre(x/40)
2/079) if index ne 0 then
*******************************************************************
1/041) for lx = 0 to 700 do for ly = 0 to 700 do
1/042)  if FindIndexFromCoord(lx, ly) eq index then
1/043) [
1/044) CallSmartSwat("Duplicate pin index $D, pins are {$D,$D} and {$D,$D}.",
1/045)   index, lx, ly, x, y)
1/046) break
1/047) ]
**************************************
2/083) for lx = MinXcheck to MaxXcheck by Xinc do for ly = MinYcheck to MaxYcheck by Yinc do
2/084) [
2/085) WeAre(x/40)
2/086)  if FindIndexFromCoord(lx, ly) eq index & not (x eq lx & y eq ly) then
2/087) 	[
2/088) //SetupBoard:Dupli...text changed..mcnair
2/089) CallSmartSwat("SetupBoard:Duplicate pin index $D, pins are {$D,$D} and {$D,$D}.",
2/090)   index, lx, ly, x, y)
2/091) break
2/092) 	]
2/093) if  not checkBoard then break  // allow going out of this mode by flag 
2/094) ]
*******************************************************************
1/054)  CallSmartSwat("Board routines disagree on $S$D.",
1/055)   FindNameesString(fclass),fpin)
1/056) ]
1/057) ]
1/058) ]
**************************************
2/101) CallSmartSwat("SetupBoard:Board routines disagree on $S$D, FIFC at {$D,$D}...Class at {$D,$D}",
2/102)   FindNameesString(fclass),fpin,x,y,px,py)
2/103)   ]//SetupBoard:Board ro...text changed..mcnair
2/104) ]
2/105) if  not checkBoard then break  // allow going out of this mode by flag reset..mcnair
2/106) ]
*******************************************************************
1/064) DeclareName("DefaultArgs", lv DefaultArgs)
**************************************
2/112) DeclareName("ErFile", lv ErFile)  // for board diagnostics to ErFile w/ PutTemplate..mcnair
2/113) DeclareName("CommentsFile", lv CommentsFile)  // diagnostics to CommentsFile..mcnair
2/114) DeclareName("checkBoard", lv checkBoard)  // for knowing cases when files are not open..mcnair
2/115) DeclareName("WeAre", lv WeAre)  // for board diagnostics use of cursor..mcnair
2/116) DeclareName("DefaultArgs", lv DefaultArgs)
*******************************************************************
1/089) ComputeMWCoords = MultiWirePanic	// for multi-wire
1/090) DeclareName("ComputeMWCoords", lv ComputeMWCoords)
**************************************
2/141) //sil-route aid stuff
2/142) DeclareName("NumPinRows",lv NumPinRows)
2/143) DeclareName("NumPinCols",lv NumPinCols)
2/144) DeclareName("PinCols",lv PinCols)
2/145) DeclareName("ICPins",lv ICPins)
2/146) DeclareName("GndPins",lv GndPins)
2/147) DeclareName("VEEPins",lv VEEPins)
2/148) DeclareName("VCCPins",lv VCCPins)
2/149) DeclareName("VDDPins",lv VDDPins)
2/150) DeclareName("DipDesc",lv DipDesc)
2/151) DeclareName("DipColVec",lv DipColVec)
2/152) DeclareName("NumDipRows",lv NumDipRows)
2/153) DeclareName("NumDipCols",lv NumDipCols)
2/154) DeclareName("Conns",lv Conns)
2/155) DeclareName("Econns",lv Econns)
2/156) DeclareName("Cconns",lv Cconns)
2/157) DeclareName("GetBit",lv GetBit)
2/158) ComputeMWCoords = MultiWirePanic	// copy values
2/159) DeclareName("ComputeMWCoords", lv ComputeMWCoords)
*******************************************************************
1/093) ComputePCCoords = PCPanic // for automatic PC
1/094) DeclareName("ComputePCCoords", lv ComputePCCoords)
1/095) OtherPCHoles = PCPanic
1/096) DeclareName("OtherPCHoles", lv OtherPCHoles)
1/097) SetupMoreICClasses = Noop
1/098) DeclareName("SetupMoreICClasses", lv SetupMoreICClasses)
1/099) AddDecouplingCaps = NoAddedCaps
**************************************
2/162) AddDecouplingCaps = NoAddedCaps
*******************************************************************
1/107) biv = DeclareName("boardInterfaceVersion", 0)
1/108) ]
**************************************
2/170) ]
*******************************************************************
1/119) and ReadBoardCode(filename) be
1/120) [
**************************************
2/181) and ReadBoardCode(file) be
2/182) [
*******************************************************************
1/129) let file = OpenFile(filename, ksTypeReadWrite, wordItem, 0,
1/130)  0, 0, SilZone)
1/131) until Endofs(file) do
**************************************
2/191) let biv = DeclareName("boardInterfaceVersion", 0)
2/192) until Endofs(file) do
*******************************************************************
1/187) SetupMoreICClasses() // do that file's version
1/188) SetupMoreICClasses = Noop 
1/189) ]
1/190) Closes(file)
1/191) ]
1/192) and GetPair(file) = valof
**************************************
2/248) ]
2/249) ]
2/250) and GetPair(file) = valof
*******************************************************************
1/227) CallSmartSwat("*nBoard routines disagree on $S$D.",
1/228)  FindNameesString(TWclass),pin)
1/229) ]
1/230) ]
**************************************
2/285) CallSmartSwat("BuildTWNet:Board routines disagree on $S$D...FIFC at $D, pin at {$D,$D}.",
2/286)  FindNameesString(TWclass),pin,fpin,x,y)
2/287) if  not checkBoard then break  // allow going out of this mode by flag reset..mcnair
2/288) ]//BuildTWNet:Board ro...text changed..mcnair
2/289) ]
*******************************************************************
1/276) SetupICclass("M", printUsedList, DIP3Wide, NullAttributes,
**************************************
2/335) SetupICclass("J12W", printUsedList, DIP12Wide, NullAttributes, Noop, 84)
2/336) SetupICclass("M", printUsedList, DIP3Wide, NullAttributes,
*******************************************************************
1/290) icclass>>icclass.nPotentialPins = -1 // not a terminator class
1/291) resultis icclass
**************************************
2/350) resultis icclass
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:56:03 PDT


Differences between files routec.bcpl and edroutec.bcpl:

*******************************************************************
1/000) //routec.bcpl
1/001) // Resident route-related utility module.
1/002) // last modified by McCreight, October 30, 1981  2:33 PM
1/003) get "route.defs"
1/004) static [ char ]
1/005) let NewICInst(icinst, ictype) be
**************************************
2/000) //routec.bcpl
2/001) // Resident route-related utility module.
2/002) // last modified by Taft, September 22, 1979  7:32 PM
2/003) get "route.defs"
2/004) static [ char; maxitems; nitems; itemHeap; CompareFn; greatestFinishedItem ]
2/005) let NewICInst(icinst, ictype) be
*******************************************************************
1/013) ]
**************************************
2/013) net>>net.minSperge = -1
2/014) ]
****************************************************************************
1/084) and ManhattanDistFn(X1, Y1, X2, Y2) = valof
**************************************
2/085) and DoInSortOrder(type, CFn, Action) be
2/086) [
2/087) nitems = 0
2/088) MapNamees(type, Count)
2/089) maxitems = nitems
2/090) let biggestBlockLen = nil
2/091) itemHeap = Allocate(SilZone, nitems+1, lv biggestBlockLen)
2/092) if itemHeap eq empty then
2/093) [
2/094) if biggestBlockLen ls 100 then
2/095)   CallSwat("Sort block too small")
2/096) itemHeap = Allocate(SilZone, biggestBlockLen)
2/097) maxitems = biggestBlockLen-1
2/098) ]
2/099) CompareFn = CFn
2/100) greatestFinishedItem = empty
2/101) [
2/102) itemHeap!0 = 0
2/103) MapNamees(type, NextBatchToHeap)
2/104) let itemsInHeap = itemHeap!0
2/105) for i=itemsInHeap to 2 by -1 do
2/106)   itemHeap!i = PullFromHeap(itemHeap, CompleteCompare)
2/107) for i=1 to itemsInHeap do Action(itemHeap!i)
2/108) greatestFinishedItem = itemHeap!itemsInHeap
2/109) nitems = nitems-itemsInHeap
2/110) ] repeatuntil nitems eq 0
2/111) Free(SilZone, itemHeap)
2/112) ]
2/113) and Count(namee) be nitems = nitems+1
2/114) and NextBatchToHeap(namee) be
2/115) [
2/116) if greatestFinishedItem ne empty &
2/117)   CompleteCompare(namee, greatestFinishedItem) le 0 then return
2/118) if itemHeap!0 ge maxitems then // get largest next time around
2/119) [
2/120) if CompleteCompare(namee, itemHeap!1) ge 0 then return
2/121) PullFromHeap(itemHeap, CompleteCompare)
2/122) ]
2/123) AddToHeap(itemHeap, namee, CompleteCompare)
2/124) ]
2/125) and CompleteCompare(x, y) = valof
2/126) [
2/127) let c = CompareFn(x, y)
2/128) resultis (c ne 0)? c, (x eq y? 0, (x gr y? 1, -1))
2/129) ]
2/130) and NameCompareFn(namee1, namee2) = StComp(FindNameesString(namee1),
2/131)  FindNameesString(namee2))
2/132) and ManhattanDistFn(X1, Y1, X2, Y2) = valof
*******************************************************************
1/111) and DoInSortOrder(type, CFn, Action) be
1/112) [
1/113) SwapIn(CFn)
1/114) SwapIn(Action)
1/115) SwapDoInSortOrder(type, CFn, Action)
1/116) ]
1/117) and Count(namee) be nitems = nitems+1
1/118) and NameCompareFn(namee1, namee2) = StComp(FindNameesString(namee1),
1/119)  FindNameesString(namee2))
1/120) and NoAddedCaps() be
**************************************
2/159) and NoAddedCaps() be
*******************************************************************
**************************************
2/162) and ComputeClusters(clusterBaseVec, net) be
2/163) [
2/164) 	SetBlock(lv (clusterBaseVec!1), infinity, clusterBaseVec!0)
2/165) 	clusterBaseVec!0 = 1
2/166) 	clusterBaseVec!1 = 1
2/167) 	let cluster = net>>net.clusterList
2/168) 	while cluster ne empty do
2/169) 	[
2/170) 		AddToHeap(clusterBaseVec, cluster>>cluster.index+1, Usc)
2/171) 		cluster = cluster>>cluster.next
2/172) 	]
2/173) 	let itemsInCluster = clusterBaseVec!0
2/174) 	for i=itemsInCluster to 2 by -1 do
2/175)       clusterBaseVec!i = PullFromHeap(clusterBaseVec, Usc)
2/176)     clusterBaseVec!0 = itemsInCluster
2/177) ]
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:58:44 PDT


Differences between files routeic.bcpl and edrouteic.bcpl:

*******************************************************************
1/003) get "route.defs"
**************************************
2/003) // last modified by S. Inouye for gate array July 31, 1981  12:19 PM
2/004) get "route.defs"
*******************************************************************
1/031) and SIP(icinst, pinNo, pv, ph) = valof
**************************************
2/032) and DIP12Wide(icinst, pinNo, pv, ph) = valof
2/033) [  //gate array dip
2/034) let npins = Npins(icinst)
2/035) if pinNo le 0 % pinNo gr npins then resultis illegal
2/036) if pinNo le 20 then
2/037) [
2/038) @ph=0
2/039) @pv=(pinNo-1)*4
2/040) if pinNo ge 11 then @pv=@pv+4
2/041) resultis relative
2/042) ]
2/043) if pinNo ge 65 then
2/044) [
2/045) @ph=48
2/046) @pv=(pinNo-65)*4
2/047) if pinNo ge 75 then @pv=@pv+4
2/048) resultis relative
2/049) ]
2/050) //do middle pin columns
2/051) let ColNo=(pinNo-21)/11
2/052) let RowNo=(pinNo-21) rem 11
2/053) switchon ColNo into
2/054) [
2/055) case 0:	[ @ph=12; endcase ]
2/056) case 1:	[ @ph=18; endcase ]
2/057) case 2:	[ @ph=30; endcase ]
2/058) case 3:	[ @ph=36; endcase ]
2/059) ]
2/060) @pv=0
2/061) if RowNo ge 5 then [ @pv=60; RowNo=RowNo-5 ]
2/062) @pv=@pv+(RowNo*4)
2/063) resultis relative
2/064) ]
2/065) and SIP(icinst, pinNo, pv, ph) = valof
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:59:23 PDT


Differences between files routeinit.bcpl and edrouteinit.bcpl:

*******************************************************************
1/000) //routeinit.bcpl
1/001) // Initialization and driver module
1/002) // last modified by McCreight, September 15, 1982  11:31 AM
1/003) //    to initialize the complete random table, so we'll get identically the
1/004) //    same results on successive identical runs.
1/005) get "sysdefs.d"
**************************************
2/000) //routeinit.bcpl
2/001) // Initialization and driver module
2/002) // last modified by Taft, September 22, 1979  7:11 PM
2/003) // last modified by Inouye for sil/route aid June 9, 1981  10:11 AM
2/004) get "sysdefs.d"
*******************************************************************
1/015) UNPACKDT // in CTime.br
1/016) CONVUDT
1/017) OverlayScan
**************************************
2/014) OverlayScan
*******************************************************************
1/020) LookupEntries
1/021) LoadRam
**************************************
2/017) LookUpEntries
2/018) LoadRam
*******************************************************************
1/029) npBiggestOverlay
1/030) ]
**************************************
2/026) ]
*******************************************************************
1/037) nlFileName = empty
1/038) board = empty
1/039) rev = empty
1/040) time = empty
1/041) pctext = empty
1/042) boardLocation = empty
1/043) wlNewFileName = empty
**************************************
2/033) InitializeRB=false
2/034) nlFileName = empty
2/035) boardLocation = empty
2/036) boardCodeFileName = empty
2/037) wlNewFileName = empty
*******************************************************************
1/061) randomTable
1/062) randomIndex
1/063) randomTrailer
1/064) ]
**************************************
2/055) ]
*******************************************************************
1/085) AddDynamicEntry(lv MakeConnInstFile) // in RouteBackpanel
1/086) AddDynamicEntry(lv MultiWirePanic)
1/087) AddDynamicEntry(lv PCPanic)
1/088) AddDynamicEntry(lv RouteEarlyNets) // in RouteNet
**************************************
2/076) AddDynamicEntry(lv MultiWirePanic) // in RouteBackpanel
2/077) AddDynamicEntry(lv RouteEarlyNets) // in RouteNet
*******************************************************************
1/097) ReadTime(lv time)
1/098) charTab = Allocate(SilZone, 256)
**************************************
2/086) charTab = Allocate(SilZone, 256)
*******************************************************************
1/131) case $B:
**************************************
2/119) case $I:
2/120) case $i:
2/121) InitializeRB = true
2/122) endcase
2/123) case $B:
*******************************************************************
1/139) case $P:
1/140) case $p:
1/141) if doPC then PCPrototype = true
1/142) doPC = true
1/143) endcase
1/144) default:
**************************************
2/131) default:
*******************************************************************
1/150) if LoadRam(RamImage) eq 0 then InitBcplRuntime() // fire up microcode
1/151) SetupSpace()
1/152) DeclareAvailableNames() // for dynamic loader
1/153) let nlFileCount = 0
**************************************
2/137) DefaultString(lv boardCodeFileName, "routemlb.br")
2/138) let nlFileCount = 0
*******************************************************************
1/176) dontCareNet = DefineNamee("Whatever", typeNet, NewNet)
**************************************
2/161) if LoadRam(RamImage) eq 0 then InitBcplRuntime() // fire up microcode
2/162) SetupSpace()
2/163) dontCareNet = DefineNamee("Whatever", typeNet, NewNet)
*******************************************************************
1/180) SetupBoard() // assuming dynamic loader has loaded board characterization,
1/181)  //plug edge connectors and trace-wired nets into data structures
1/182) SetupMoreICClasses() // in the board file
1/183) if whereTW then PrintTWPins()
**************************************
2/167) SetupBoard(boardCodeFileName)
2/168)  // read in board code and plug into statics, then
2/169)  //plug edge connectors and trace-wired nets into data structures
2/170) if whereTW then PrintTWPins()
*******************************************************************
1/218) if doPC then
1/219) [
1/220) NeedFile(nlFileName, ".apc")
1/221) ]
1/222) if doResistances then
**************************************
2/205) if doResistances then
*******************************************************************
1/234) InitRandom()
1/235) ]
**************************************
2/217) ]
*******************************************************************
1/319) ReadBoardCode(string)
1/320) endcase
**************************************
2/301) DefaultString(lv boardCodeFileName, string)
2/302) endcase
*******************************************************************
1/330) case $I:
1/331) case $i:
1/332) DefaultString(lv board, string)
1/333) endcase
1/334) case $R:
1/335) case $r:
1/336) DefaultString(lv rev, string)
1/337) endcase
1/338) case $P:
1/339) case $p:
1/340) [
1/341) let file = OpenFile(string, ksTypeReadOnly, charItem, 0,
1/342)   0, 0, SilZone)
1/343) let length = 0
1/344) until Endofs(file) do [ Gets(file); length = length+1]
1/345) pctext = Allocate(SilZone, (length rshift 1)+1)
1/346) pctext>>string.length = length
1/347) Resets(file)
1/348) length = 0
1/349) until Endofs(file) do
1/350) [
1/351) length = length+1
1/352) pctext>>string.char^length = Gets(file)
1/353) ]
1/354) Closes(file)
1/355) ]
1/356) endcase
1/357) default:
**************************************
2/312) default:
*******************************************************************
1/417) LookupEntries(q, names, dvs, kfCount, true)
1/418) Closes(q)
**************************************
2/372) LookUpEntries(q, names, dvs, kfCount, true)
2/373) Closes(q)
*******************************************************************
1/458) and ReadTime(ps) be
1/459) [
1/460) let uv = vec 7
1/461) UNPACKDT(0, uv)
1/462) @ps = Allocate(SilZone, 12) // for date and time
1/463) CONVUDT(@ps, uv)
1/464) ]
1/465) and InitRandom() be
1/466) 	[
1/467) randomTable = Allocate(objectZone, degree+1)
1/468) for i=0 to degree do randomTable!i = #101011
1/469) randomIndex = 0
1/470) randomTrailer = degree-midPower
1/471) for i=1 to 2000 do Random(1)
1/472) ]
**************************************
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 10:59:53 PDT


Differences between files routemisc.bcpl and edroutemisc.bcpl:

*******************************************************************
1/003) // last modified by McCreight, June 15, 1981  3:47 PM
1/004) get "route.defs"
1/005) let ReadICType(str) = valof
**************************************
2/003) // last modified by Taft, September 22, 1979  8:50 PM
2/004) get "route.defs"
2/005) external [ Wns ]
2/006) let ReadICType(str) = valof
*******************************************************************
1/015) ictype>>ictype.icclass = DefineNamee(family, typeIcclass, Shucks)
1/016) ]
**************************************
2/016) ictype>>ictype.icclass = DefineNamee(family, typeIcclass, CallSwat)
2/017) ]
*******************************************************************
1/147) for pinNo=1 to Npins(ictype) do
**************************************
2/148) // let returntwo=false
2/149) // if Npins(ictype) eq 64 then
2/150) // [
2/151) // for pinNo=1 to Npins(ictype) do
2/152) // [
2/153) // let x,y = nil,nil
2/154) // unless BoardPinCoord(boardloc, ictype, pinNo, lv x, lv y) do loop
2/155) // Remark("*nPin number $D at ($D,$D)",pinNo,x,y)
2/156) // ]
2/157) // ]
2/158) for pinNo=1 to Npins(ictype) do
*******************************************************************
1/151) if FindIndexFromCoord(x,y) eq 0 then resultis 2
1/152) if x ls minx then minx = x
**************************************
2/162) if FindIndexFromCoord(x,y) eq 0 then 
2/163) [  //report the offending pin and location
2/164) // Wss(ErFile,"*nPin number: ")
2/165) // Wns(ErFile,pinNo)
2/166) // Wss(ErFile,"*sat the following coordinates does not have a ic pad: ")
2/167) // Wss(ErFile,"*nx coor: ")
2/168) // Wns(ErFile,x)
2/169) // Wss(ErFile,"*s y coor: ")
2/170) // Wns(ErFile,y)
2/171) // returntwo=true
2/172) resultis 2
2/173) ]
2/174) if x ls minx then minx = x
*******************************************************************
1/157) let spMin = Sperge(minx,miny)
**************************************
2/179) // if returntwo eq true then resultis 2
2/180) let spMin = Sperge(minx,miny)
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 11:00:24 PDT


Differences between files routeneighbor.bcpl and edrouteneighbor.bcpl:

*******************************************************************
1/000) //	RouteNeighbor.bcpl
1/001) // Code for nearest neighbor searching, and area coverage.
1/002) //	last modified by E. McCreight, May 1, 1979  9:03 PM
**************************************
2/000) //	RouteNeighbor.bcpl
2/001) // Code for sorting, nearest neighbor, searching, and area coverage.
2/002) //	last modified by E. McCreight, May 1, 1979  9:03 PM
*******************************************************************
1/117) and Unsperge(sperge, fine, px, py) be
**************************************
2/117) 
2/118) //----------------------------------------------------------------
2/119) //	B i n a r y   S e a r c h   R o u t i n e
2/120) //----------------------------------------------------------------
2/121) and BinSearch(value, minIn, minOut, CompareWithIndex) = valof
2/122) [ // returns the index of the first argument to CompareWithIndex
2/123) // between minIn and minOut that is greater than or equal to
2/124) // value. Assumes CompareWithIndex(value, minOut)<0; never
2/125) // checks this. Assumes if i<j then for all values of x,
2/126) // CompareWithIndex(x, i)>=CompareWithIndex(x, j).
2/127) while minIn ls minOut do
2/128) [
2/129) let mid = (minIn+minOut) rshift 1 // never =minOut
2/130) let c = CompareWithIndex(value, mid)
2/131) test c gr 0
2/132) ifso	minIn = mid+1
2/133) ifnot	test c ls 0
2/134) ifso	minOut = mid
2/135) ifnot	resultis mid
2/136) ]
2/137) resultis minIn
2/138) ]
2/139) 
2/140) //----------------------------------------------------------------
2/141) //	H e a p   R o u t i n e s
2/142) //----------------------------------------------------------------
2/143) and AddToHeap(heap, item, Compare) be
2/144) [
2/145) let sonPtr = heap!0+1
2/146) heap!0 = sonPtr
2/147) let fatherPtr = sonPtr rshift 1
2/148) while fatherPtr gr 0 & Compare(heap!fatherPtr, item) ls 0 do
2/149) [
2/150) heap!sonPtr = heap!fatherPtr
2/151) sonPtr = fatherPtr
2/152) fatherPtr = fatherPtr rshift 1
2/153) ]
2/154) heap!sonPtr = item
2/155) ]
2/156) and PullFromHeap(heap, Compare) = valof
2/157) [
2/158) if heap!0 le 0 then CallSwat("Pull from empty heap")
2/159) let result = heap!1
2/160) let testItem = heap!(heap!0)
2/161) heap!0 = heap!0-1
2/162) let fatherPtr = 1
2/163) let sonPtr = 2
2/164) while sonPtr le heap!0 do
2/165) [
2/166) if sonPtr ls heap!0 &
2/167)   Compare(heap!(sonPtr+1), heap!sonPtr) gr 0 then
2/168)     sonPtr = sonPtr+1
2/169) if Compare(testItem, heap!sonPtr) ge 0 then break
2/170) heap!fatherPtr = heap!sonPtr
2/171) fatherPtr = sonPtr
2/172) sonPtr = fatherPtr+fatherPtr
2/173) ]
2/174) heap!fatherPtr = testItem
2/175) resultis result
2/176) ]
2/177) //----------------------------------------------------------------
2/178) //	S o r t   R o u t i n e
2/179) //----------------------------------------------------------------
2/180) and Sort(heap, Compare) be
2/181) [
2/182) let len = heap!0
2/183) heap!0 = 0
2/184) for i=1 to len do AddToHeap(heap, heap!i, Compare)
2/185) for i=len to 2 by -1 do heap!i = PullFromHeap(heap, Compare)
2/186) heap!0 = len
2/187) ]
2/188) 
2/189) //----------------------------------------------------------------
2/190) //	C o - o r d i n a t e   S p e r g i n g   O p e r a t i o n s
2/191) //----------------------------------------------------------------
2/192) and Sperge(x, y, pFine; numargs na) = valof
2/193) [
2/194) if na gr 2 then @pFine = (x&3 lshift 2)+(y&3)
2/195) resultis (Spread(x rshift 2) lshift 1)+Spread(y rshift 2)
2/196) ]
2/197) and Spread(x) = valof
2/198) [ // x must be < #400
2/199) let x1 = ((x&#360) lshift 4)+(x&#17)
2/200) let x2 = ((x1&#6014) lshift 2)+(x1&#1403)
2/201) resultis ((x2&#21042) lshift 1)+(x2&#10421)
2/202) ]
2/203) and Unsperge(sperge, fine, px, py) be
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 11:01:25 PDT


Differences between files routesyms.bcpl and edroutesyms.bcpl:

*******************************************************************
1/000) //routesyms.bcpl
1/001) // Symbol table, storage allocation, and string utility module.
1/002) // last modified by McCreight, July 2, 1981  10:19 AM
1/003) get "route.defs"
**************************************
2/000) //routesyms.bcpl
2/001) // Symbol table, storage allocation, and string utility module.
2/002) // last modified by Taft, July 11, 1979  9:11 PM
2/003) get "route.defs"
*******************************************************************
1/038) let DefineNamee(str, type, Init, extraLength, duplicate; numargs na) = valof
1/039) [ //returns pointer to namee. Verifies new record if type<0. If duplicate
1/040) // is present and not false, then a new record is created even if it
1/041) // duplicates an existing (str, type) pair.
1/042) let realtype = type ls 0? -type, type
**************************************
2/038) let DefineNamee(str, type, Init, extraLength; numargs na) = valof
2/039) [ //returns pointer to namee. Guarantees new record if type<0.
2/040) let realtype = type ls 0? -type, type
*******************************************************************
1/059) if namee eq 0 % (na ge 5 & duplicate ne false) then
1/060) [
**************************************
2/057) if namee eq 0 then
2/058) [
*******************************************************************
1/066) if (na gr 2)&(Init ne 0) then Init(namee)
**************************************
2/064) if (na gr 2)&(Init ne 0) & (Init eq CallSwat) then CallSwat("In DefineNamee...Could't fine name:",str)
2/065) if (na gr 2)&(Init ne 0) then Init(namee)
*******************************************************************
1/121) if type ls 0 then CallSwat("namee already defined")
1/122) resultis namee
**************************************
2/120) let ptr=lv name>>name.nameString
2/121) if type ls 0 then CallSwat("namee already defined: ",ptr)
2/122) resultis namee
*******************************************************************
1/304) and CopyString(source, dest) be
1/305) [
1/306) for i=1 to source>>string.length do dest>>string.char^i = source>>string.char^i
1/307) dest>>string.length = source>>string.length
1/308) ]
1/309) and OffsetLegal(x, modulus, min, max) = valof
**************************************
2/304) and OffsetLegal(x, modulus, min, max) = valof
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 11:02:00 PDT


Differences between files routeterm.bcpl and edrouteterm.bcpl:

*******************************************************************
1/000) //routeterm.bcpl
1/001) // Ecl termination module
1/002) // last modified by E. McCreight, March 28, 1980  5:23 PM
1/003) get "route.defs"
**************************************
2/000) //routeterm.bcpl
2/001) // Ecl termination module
2/002) // last modified by E. McCreight, February 9, 1979  2:17 AM
2/003) get "route.defs"
*******************************************************************
1/175) unless icclass>>icclass.nPotentialPins ge 0 do return // not really terminator
1/176) // the data in icclass.permutation is interpreted as follows:
**************************************
2/175) unless icclass>>icclass.nPotentialPins gr 0 do return // not really terminator
2/176) // the data in icclass.permutation is interpreted as follows:
*******************************************************************
1/214) unless icclass>>icclass.nPotentialPins ge 0 do return
1/215) if icclass>>icclass.permutation ne 0 then Free(SilZone, icclass>>icclass.permutation)
**************************************
2/214) unless icclass>>icclass.nPotentialPins gr 0 do return
2/215) if icclass>>icclass.permutation ne 0 then Free(SilZone, icclass>>icclass.permutation)
*******************************************************************
1/223) unless termClass>>icclass.nPotentialPins ge 0 do CallSwat()
1/224) let perm = termClass>>icclass.permutation
**************************************
2/223) unless termClass>>icclass.nPotentialPins gr 0 do CallSwat()
2/224) let perm = termClass>>icclass.permutation
*******************************************************************

End of differences seen.

Waterlily                          Version 1.6                             26-Oct-82 11:02:25 PDT


Differences between files routetwassign.bcpl and edroutetwassign.bcpl:

*******************************************************************
1/000) //routetwassign.bcpl
1/001) // Trace-wired net assignment module.
1/002) // last modified by E. McCreight, October 30, 1981  2:35 PM
1/003) get "route.defs"
1/004) static [ currentTWNet; currentTWNetName ]
1/005) let AssignTWNet(net) be
**************************************
2/000) //routetwassign.bcpl
2/001) // Trace-wired net assignment module.
2/002) // last modified by E. McCreight, November 10, 1978  12:22 AM
2/003) get "route.defs"
2/004) static [ currentTWNet ]
2/005) let AssignTWNet(net) be
*******************************************************************
1/011) let CompareSperges(i, j) = TWspergevec!i-TWspergevec!j
**************************************
2/011) let pin = net>>net.pinList
2/012) if @pin eq mark then return // empty net
2/013) let CompareSperges(i, j) = TWspergevec!i-TWspergevec!j
*******************************************************************
1/014) currentTWNetName = FindNameesName(net)
1/015) let netString = FindNameesString(net)
**************************************
2/016) let netString = FindNameesString(net)
*******************************************************************
1/019) let partnetString = vec 20
1/020) let pin = net>>net.pinList
1/021) if @pin eq mark then
1/022) [
1/023) let hasPart = false
1/024) for i=1 to orignpins do
1/025)   if TryFindingNamee(
1/026)     ExpandTemplate(partnetString, "$S$D", netname, i),
1/027)    typeNet) ne empty then hasPart = true
1/028) if not hasPart then return // empty net
1/029) ]
1/030) NewSwapZone(2*orignpins+100)
1/031) let icinst = DefineNamee(netString, typeIcinst, 0, orignpins-1)
**************************************
2/020) let icinst = DefineNamee(netString, typeIcinst, 0, orignpins-1)
*******************************************************************
1/034) TWperm = Allocate(swapZone, orignpins+1)
1/035) TWspergevec = Allocate(swapZone, orignpins+1)
1/036) let nelements = 0
**************************************
2/023) TWperm = Allocate(SilZone, orignpins+1)
2/024) TWspergevec = Allocate(SilZone, orignpins+1)
2/025) let partnetString = vec 20
2/026) let nelements = 0
*******************************************************************
1/040) WeAre(doingTraces)
1/041) let pinCut = GetBit(cutPins, i) ne 0
1/042) (icclass>>icclass.PinOffset)(icinst, i, lv x, lv y, lv pinInfo)
1/043) let partnet = TryFindingNamee(ExpandTemplate(partnetString,
1/044)  "$S$D", netname, i), typeNet)
1/045) if partnet ne empty then test pinCut
**************************************
2/030) let partnet = TryFindingNamee(ExpandTemplate(partnetString,
2/031)  "$S$D", netname, i), typeNet)
2/032) let pinCut = GetBit(cutPins, i) ne 0
2/033) (icclass>>icclass.PinOffset)(icinst, i, lv x, lv y, lv pinInfo)
2/034) if partnet ne empty then test pinCut
*******************************************************************
1/051) [ // Move the pin list from the net to the TW pin
1/052) icinst>>icinst.pin^i = partnet>>net.pinList
1/053) partnet>>net.pinList = netMark
1/054) ]
1/055) unless pinCut%((not doMultiWire)&(not doPC)&
1/056)   pinInfo<<info.usedForDecoupling) do
1/057) [
**************************************
2/040) [ // mark the net as a partition of a trace-wired net, and add the TW pin
2/041) let ppin = lv partnet>>net.pinList
2/042) while @@ppin ne mark do ppin = @ppin
2/043) @ppin = lv icinst>>icinst.pin^i
2/044) icinst>>icinst.pin^i = netMark
2/045) ]
2/046) unless pinCut%((not doMultiWire)&pinInfo<<info.usedForDecoupling) do
2/047) [
*******************************************************************
1/067) [ // assign each pin to the closest TW pin
1/068) WeAre(doingTraces)
**************************************
2/057) [
2/058) WeAre(doingTraces)
*******************************************************************
1/071) let curPin = pin
1/072) pin = @pin
1/073) let nearest = TWperm!FindNearest(x, y, nelements, TWFindSperge)
1/074) @curPin = (icinst>>icinst.pin^nearest eq empty)? netMark,
1/075)   icinst>>icinst.pin^nearest
1/076) icinst>>icinst.pin^nearest = curPin
1/077) ]
1/078) net>>net.pinList = netMark
1/079) Free(swapZone, TWperm)
1/080) Free(swapZone, TWspergevec)
1/081) for i=1 to orignpins do
1/082) [
1/083) if icinst>>icinst.pin^i ne empty then
1/084) [
1/085) WeAre(doingTraces)
1/086) let hasOtherPin, hasTWPin = false,false
1/087) let TWx,TWy = nil,nil
1/088) GetPinCoord(0, lv icinst>>icinst.pin^i, lv TWx, lv TWy)
1/089) let pin = icinst>>icinst.pin^i
1/090) while @pin ne mark do
1/091) [
1/092) GetPinCoord(0, pin, lv x, lv y)
1/093) test (TWx eq x) & (TWy eq y)
1/094) ifso hasTWPin = true // by another preferred name
1/095) ifnot hasOtherPin = true
1/096) pin = @pin
1/097) ]
1/098) if hasOtherPin then
1/099) [
1/100) let partNet = TryFindingNamee(
1/101)   ExpandTemplate(partnetString,
1/102)  "$S$D", netname, i), typeNet)
1/103) if partNet eq empty then
1/104) [
1/105) partNet = DefineNamee(ExpandTemplate(
1/106)   partnetString, "$S-", netname),
1/107)   typeNet, NewPartNet, 0, true)
1/108) partNet>>net.isPartialNet = true
1/109) ]
1/110) partNet>>net.pinList
1/111)   = hasTWPin?
1/112)     icinst>>icinst.pin^i, lv icinst>>icinst.pin^i
1/113) ]
1/114) ]
1/115) swapZone = empty
1/116) ]
1/117) ]
**************************************
2/061) let nearestIndex = FindNearest(x, y, nelements, TWFindSperge)
2/062) let curPin = pin
2/063) pin = @pin
2/064) test Sperge(x, y) eq TWFindSperge(nearestIndex)
2/065) ifso
2/066) [ // the two pins are the same...
2/067) @curPin = netMark
2/068) ]
2/069) ifnot
2/070) [ // the two pins are not the same...
2/071) let nearest = TWperm!nearestIndex
2/072) if icinst>>icinst.pin^nearest eq empty then
2/073) [
2/074) let partnet = DefineNamee(ExpandTemplate(partnetString, "$S$D",
2/075)  netname,nearest), typeNet, NewPartNet)
2/076) icinst>>icinst.pin^nearest = partnet>>net.pinList
2/077) partnet>>net.pinList = lv icinst>>icinst.pin^nearest
2/078) ]
2/079) @curPin = icinst>>icinst.pin^nearest
2/080) icinst>>icinst.pin^nearest = curPin
2/081) ]
2/082) ]
2/083) net>>net.pinList = netMark
2/084) Free(SilZone, TWperm)
2/085) Free(SilZone, TWspergevec)
2/086) ]
*******************************************************************
1/120) net>>net.pinList = lv currentTWNetName>>name.mark
1/121) ]
**************************************
2/089) NewNet(net)
2/090) net>>net.pinList = lv FindNameesName(net)>>name.mark
2/091) ]
*******************************************************************

End of differences seen.
*start*
02928 00024 US 
Date: 27 Oct. 1982 12:05 pm PDT (Wednesday)
From: McCreight.PA
Subject: Changes in Route over the past three years
To: Inouye.ES
cc: TonyWest, McCreight

Steve:

Tony has asked that I send you a message describing the general nature of the
changes to PARC's Route over the past three years (since ED's version branched
off from PARC's).  Besides the usual bug fixes, there have been two sizeable
changes in Route since that time.

The first major addition is the support of PC fabrication.  Route now produces
tapes that can be processed by an automated PC routing service bureau called
Automated Systems, Inc., located in the charming village of El Segundo,
California.  They charge $10,000 per (Dorado-sized) board and work at the speed
of summer lightning.  The next few hundred Dorados will be produced in PC
from ASI filmwork and drill tapes.  This mostly only required a new output
module.

Now for a bit of background on the second major change.  In MultiWire, as in
stitch-weld, there are considerable economic and logistical advantages in using
the same basic power/ground layers for all ten different Dorado board types. 
Unfortunately, in MultiWire there is no operation analogous to cutting a
stitch-weld pin loose from its committed power net.  To accommodate the wide
variation of chip technologies and shapes that are used on Dorado boards, we
designed a new format Dorado board on which most of the committed wiring was
limited to bypass capacitor legs.  The power wiring on these new format Dorado
boards largely consists of 0.1" routed wire segments to nearby bypass capacitor
holes.  This meant in turn that Route had to understand bypass capacitor
placement and wiring, resulting in a major increase in the number of units
placed on the board.  We ran out of memory trying to re-work MultiWire Dorado
boards, which led to the second major change.

The second major change involves storage efficiency.  Our Dorado board, with
its 288 DIP's, 144 SIP's, and about 300 bypass cap's, may well be the most complex
board on which anybody is trying to use Route.  It barely fits in an Alto. 
Shortly after your Route departed from ours, we underwent a major
re-modularization, and re-arrangement of overlays, to reduce the amount of
program storage needed.  We changed details of various data structures (notably
the trace-wired nets) to pack them more tightly.

We also converted at least one part of the wire router from recursive to iterative
with an explicit stack to reduce storage demands.  The practical implication of
this last change is that we can accommodate large nets over which the designer
(using !1, !2, etc.) has exercised close control of routing order, and you cannot. 
Tony ran headfirst into that difference.

To the best of my memory, those two changes are the only major differences
between PARC Route as it was when ED kidnapped it and PARC Route as it is
today.

Ed

*start*
00565 00024 US 
Date: 27 Oct. 1982 2:43 pm PDT (Wednesday)
From: Inouye.ES
Subject: Re: Changes in Route over the past three years
In-reply-to: McCreight.PA's message of 27 Oct. 1982 12:05 pm PDT (Wednesday)
To: McCreight.PA
cc: Inouye, TonyWest.PA, Ramchandani

Ed,

Thanks for the info on Parc's Route.  Is this version of Route stable enough so
that if we decide to try to integrate our changes we won't run into a whole
bunch of problems?  Also, has there been any changes in the way Route
handles the board descriptions and ifso, what kinds?

-Steve-

*start*
00572 00024 US 
Date: 27 Oct. 1982 6:05 pm PDT (Wednesday)
From: McCreight.PA
Subject: Re: Changes in Route over the past three years
In-reply-to: Inouye.ES's message of 27 Oct. 1982 2:43 pm PDT (Wednesday)
To: Inouye.ES
cc: McCreight, TonyWest, Ramchandani.ES

Since I have no reason to work on it now, I suppose our Route is about as stable
as any piece of software can be.  Route handles board descriptions exactly as
before except that there are some new board-specific procedures that need not be
defined except if the board is to be PC'd or MultiWired.

Ed

*start*
00780 00024 US 
Date: 29-Oct-82 11:36:20 PDT (Friday)
From: JBinkley.PA
Subject: Re: FY/FZ decode czar ?
In-reply-to: DDavies' message of 29 Oct. 1982 10:51 am PDT (Friday)
To: Murray.PA
cc: JBinkley, Ogus, TonyWest, DDavies, Garner, Boggs, Fay, Fasnacht, Neely, Howard, Sandman, Johnsson, Thompson, NDSmith, Diebert, Gasbarro, Murray.PA

"We should all try to keep FZNorm 4, 9, A, and B unused so that a future
addition/extension has room to get implemented on all 3 macines."

"Unfortunately, constraints that look reasonable on
paper sometimes mean extra chips....."

We are use FZNorm 4 as "DelAddrData", FZNorm 9 as "LRot12", FZNorm A as "LRot8", and FZNorm B as "LRot4".  Unfortunately, changing means EXTRA CHIPS, so we can't comply with those constraints.  

/joe
*start*
02968 00024 US 
Date:  1-Nov-82 21:29:02 PST (Monday)
From: Murray.PA
Subject: Re: Meeting: Microcode support for 16k Control Store
In-reply-to: Neely's message of 1-Nov-82 16:30:22 PST (Monday)
To: Neely, Fay
cc: Murray, Ogus, Fasnacht, Sturgis, TonyWest

I think there are 4 problem areas.  The first is Mass and such, the second is the booting sequence, the third is Burdock, and the 4th is getting interesting microcode going.

I think the Mass problems are simple to understand.  They may be nasty to implement.  Basically, Mass needs to write out fb files with PCs bigger than 12 bits.  There is no trouble with the file format.  As a strawman, I propose a Setbank command along the line of SetTask.  If anybody wants to get fancy, Mass could know about Bank_, and follow branching across banks.  I doubt if all that hair would be worth the effort.

The only new part of booting is how to get the microcode loaded into banks other than 0.  The trick is to load a Bank_ instruction into the Kernel's overlay area, and then execute it.  Unfortunately, that leaves you in a hole since there is no way to undo that operation -- you can't write in the overlay area anymore since writing will go into the shadow overlay area of the other bank.  Burdock puts a Bank_0 in the overlay area, and a Bank_n at location FFF, and then does a SetTpc[7] to FFF.  This whole mess may get a lot cleaner/simpler if we add a set bank command to the kernel.  I'll look into it.

I think we can actually load extra banks without changing the EPROMs.  It may be a bit tricky, for example we might have to load the IOP with the extra bank loader, then load the extra banks, and then load the IOP with Domino.

I also have the recipe for finding out how many banks exist.  You have to load the kernel first (so you can ask it to set the bank register) and then you write/read control store until something doesn't read back right.

There is also a bit of trickery when setting the emulators TPC.  Basically, you have to save the high (bank bits) until you are ready to go because you might smash them while using the bank register to write microcode into high banks.

Burdock is not a problem.  It already has krocked up support for banks.  As soon as Mass gives me reasonable TPCs, I'll remove my krockery.  (If you are interested, the krockery is to add a SetBank operation.  After that, loading microcode and symbols load things into the current bank by relocating everything by the contents of the current bank register.)

I have not done a lot of thinking about how to get interesting microcode going.  A while ago, I had the DLion emulator running in Bank 1.  I did this by splitting the DLion microcode into 2 parts: the emulator and the io.  It all just assembled.  After that, A bit of handwaving with Burdock was all that was needed to make it work.  Note that this is a hack as it all depends upon no traps from the wrong bank.

What else should we cover before Thur?
*start*
00856 00024 US 
Date:  3-Nov-82 12:33:35 PST (Wednesday)
From: Neely.pa
Subject: Re: Meeting: Microcode support for 16k Control Store
In-reply-to: Sturgis' message of 3 Nov. 1982 11:31 am PST (Wednesday)
To: Sturgis
cc: Fay, Murray, Neely, Ogus, Fasnacht, TonyWest

"If we assemble several separate assemblies, how do we build systems that can
jump from one bank to another?"

The classic approach is to use a reserved predefined array of addresses.


"How about calling subroutines implemented in the first bank?"

Unless the link registers have bank info(Do they?), one would have to have a predefined set of subroutines that could be called from other banks and establish some kind of protocall for handling that. What would be a good protocall?

PS. Answers to questions, even parathelical questions, gratefully accepted from any reader.

ev. 
*start*
03171 00024 US 
Date: 4 Nov. 1982 10:08 am PST (Thursday)
From: Sturgis.PA
Subject: Cedar D-Lion microcode
To: Rovner, MBrown, Levin, Mitchell, Taft, Fiala, TonyWest
cc: Crowther, Sturgis

It is time to report on the status of the microcode.

1) I have written a draft of all of the Floating point instructions that are
implemented on the Dorado.  For the statistically inclined, I used about 600 micro
instructions.  I suspect that an easy re-write would gain about 20% in space, and
perhaps the same in time.  More changes would be required to obtain the time
improvement, than required to obtain the space improvement.

2) I have tested the major operations to a considerable level of detail.  These
include Multiply, Add, Subtract, and Divide.  The sort of issues remaining for
these instructions are typified by the following example.

Consider an operation that produces an unrounded result with an exponent too
small to represent, but which when rounded rounds up to a representable value. 
My microcode produces the representable result, while the Mesa software
implementation produces an underflow.  I believe the Dorado implementation also
produces an underflow.  The Ieee standard allows for either result, at the
implementors option.  Of course, we should be consistent.

There are a number of other examples of differences between my microcode, the
Mesa software implementation, and the Dorado microcode, all occuring at a
similar level of detail.  Of course, at some point we should become consistent, but
I propose that that should be later.

3) I have tested Compare and RoundToLongInteger, but have since modified their
code.  I have written, but not yet tested, Fix/Round to
LongInteger/Cardinal/Integer.  These six instructions use common code, modified
from my original RoundToLongInteger, and should be straight forward to debug.
Perhaps 2 days.  I have not yet tested Float and Scale, but these are trivial, and
should take no more than a day each.

4) I have tested the sticky register operation.  This works, subject to the
condition that there are a number of cases in which I set the bit where other of
our implementatins do not, and conversely.  The same level of detail as described
above.

5) I have more or less burnt my bridges, and can best proceed when we get a
working 8K control store.

6) An issue that must be solved (hopefully by SDD) before we can usefully run
this microcode:  We need a way to boot microcode into upper banks of the control
store.  At present, we load the upper banks by using a crock in Burdock, but
this won't be available for standalone D-Lions.  There is a meeting across the
street this afternoon to begin addressing this issue.

7)  When we get a D-Lion with large main memory, large control store, and
large disk we should run cedar with no extra microcode, and with floating point
microcode.  While running it, we should measure it with the spy.  This will tell
us: a) which Cedar instructions must be converted first, and b) will allow us to
predict the final speed, before the Cedar micro-instructions are implemented.
Thus, we should be able to predict that final speed in a few weeks.

Howard

*start*
00643 00024 US 
Date: 4 Nov. 1982 10:33 am PST (Thursday)
From: TonyWest.PA
Subject: Extenders 10/25/82
To: TonyWest.PA

			Org		Qty	Phone		Bgt	A/c

Field Engineering	?		30

Bill Bice		SDD		6	8*823-7524		???	???
Roy Ogus		SDD		4	8*923-4687		745	???
Tony West		PARC		7	8*923-4476		050	702	
Bill Winfield	PARC		2	8*923-4375		021	702
George Carlsen	Versatec	1	(408) 773-9090	xxx	xxx
----------------------------------------------------------------------------
TOTAL				50
----------------------------------------------------------------------------

Of the 7 boards for Tony West, some go to the following
Terry Haney		EOS		3	8*844-2328

*start*
01013 00024 US 
Date:  4-Nov-82 12:17:07 PST (Thursday)
From: Murray.PA
Subject: Re: Meeting: Microcode support for 16k Control Store
In-reply-to: Neely's message of 4-Nov-82  9:09:17 PST (Thursday)
To: Neely
cc: Murray, Fay, Ogus, Fasnacht, Sturgis, TonyWest

Until you want to do something with a bank other than 0 (like run in it, or load microcode into it), the machine acts just like a normal one.  It even runs the diagnostics.  (There actually is a difference, but the diagnostics don't stumble into it.)

The bank register affects two things: the address for reading and writing microcode, and the address for fetching the next instruction when the emulator task is running.

If you want to load microcode into the second bank, you have to set the bank register to 1.  The only way to do this, it to execute an instruction with a Bank_ in it.  The easy way to do that is to load the CP Kernel, and ask the Kernel to do it for you.

There is a stripped down version of the Kernel used for booting.
*start*
00576 00024 US 
Date: 9 Nov. 1982 7:15 pm PST (Tuesday)
From: Garner.PA
Subject: Re: Dandelion CPE Rev-S
In-reply-to: Your message of 9 Nov. 1982 5:53 pm PST (Tuesday)
To: TonyWest
cc: Garner

Tony,

I don't understand why you can't use the 70nS parts since the current Dandelion
uses them.

Can't one put the 2-bit-bank-register-to-4-bit-bank-select (2:4) decoder before a
clock edge (i.e., register input), not after?

If the chip select time is 5-10 nS faster than the address access time, there should
be no problem on the other side of the clock either?

Robert

*start*
00538 00024 US 
Date: 9 Nov. 1982 11:10 pm PST (Tuesday)
From: Thacker.PA
Subject: Re: Dandelion CPE Rev-S
In-reply-to: Your message of 9 Nov. 1982 5:53 pm PST (Tuesday)
To: TonyWest

Congratulations on getting it done.  I wouldn't worry too much about the cost of
the Rams.  The cheap ones are 14, the expensive are 20.  Delta = 6, times 50 per
system = 300.  If we build 10, this is 3K.  Not worth spending the test time and
sleepless nights.  If SDD wants many of the things, let them test the slow parts if
they care.

Chuck

*start*
02244 00024 US 
Date: 16 Nov. 1982 2:06 pm PST (Tuesday)
From: Sturgis.PA
Subject: D-lion Cedar
To: Levin
cc: Fay, Howard, Taft, Murray, TonyWest, Rovner, Mitchell, Sturgis

This message is to summarize my understandings about the software changes
required to run Cedar usefully on a D-Lion.  These understandings derive from
this mornings discussions with Chuck Fay, Forest Howard, Roy Levin, and Jim
Mitchell.

We have decided to wait until Cedar is based on the Minaret (or equivalent)
version of Pilot before running Cedar usefully on D-Lions.  We expect this to
occur in the first half of 1983, possibly the first quarter.

These software changes are required by the following hardware changes:



1) Large control store to hold the larger microcode

In order to use the large control store, (other than for simple testing through
Burdock), we need to be able to boot microcode into the extra banks.  This
requires a change in the bootable microcode file format, and the loader of that
microcode.  SDD will provide the required changes in MakeDLionMicroBoot and
the IOP code (8085).  These changes will be made in the Minaret versions of the
software, and will be available first quarter 1983.

In addition,  SDD will provide the necessary changes in Mass (adding the Macro:
"bank _").

The Alto version of Mass will not be updated.  The multibank loading features
of the microcode support will not be retrofitted to the Rubicon version of Pilot.


2) Large (Quantum) disks.

There are a number of software changes required to support the Quantum disks. 
SDD has made these changes in the Minaret version of the software.  They
involve changes to InitialMicroCode, the  DiskHead in Pilot, and some parts of
Othello (Scavenger, and Formatter at least).


3) Large Central memory.

I don't believe that there are any software changes needed.






It is my understanding that Cedar will be moving to the Minaret (or equivalent)
version of Pilot early next year, so that there would be little benefit to be gained
by retrofitting these changes into our current Rubicon version.

For the short term, we will put an SA4000 on the debuggee d-lion so as to
increase the disk size sufficiently for Cedar performance testing.


Howard





*start*
01136 00024 US 
Date: 17 Nov. 1982 6:17 pm PST (Wednesday)
From: Levin.PA
Subject: Re: D-lion Cedar
In-reply-to: Sturgis' message of 16 Nov. 1982 2:06 pm PST (Tuesday)
To: Sturgis
cc: Levin, Taft, Murray, TonyWest, Rovner, Mitchell

Is your analysis intended to suggest that there is no point in further work on the
Cedar microcode until after the support for booting into the large microstore is
available?  I certainly hope not.  I can certainly imagine other strategies for
getting the microstore loaded that don't require us to wait for SDD's Minaret stuff
and the implied conversion to Trinity. I also don't see any reason to wait for the
Quantum disk support that will appear in Minaret.  We can manage just fine in
the Rubicon and Trinity worlds by connecting SA4000s to our 2 (3?) Dandelions. 
If necessary, we can borrow these disks from Dolphins, since a Dandelion
running Cedar should dominate the Dolphin anyway.

Therefore, I claim that the real issue is the absence of the Cedar microcode
itself.  I believe all these other problems can be resolved much more quickly
than the Cedar microcode can be written.

Roy

*start*
01168 00024 US 
Date: 17 NOV 1982 1828-PST
From: DAWSON.PA
Subject: 16 K CRAM boards
To:   TonyWest
cc:   Dawson, Oestreicher


Tony,

As we discussed on the phone today, Versatec would like to use 16 K CRAM boards
in its Dandelion-based products.  From a distribution, servicing, etc. point
of view, we would prefer to use boards made and distributed by OPD; however,
if OPD doesn't make the 16 K CRAM changes, we would like to explore using boards
made by CSL.  There would certainly be repair, service, diagnostic etc. issues
which could be dealt with more easily if OPD manufactured the board.  In any case,
we would like to get two 16 K CRAM boards from your first etch lot, which we
understand will be assembled and tested sometime in early 1983.  We would also
be happy to pay up front for both (I assume the per-board price is <= $3K stuffed
and tested.)

You mentioned that you might talk to Versatec Systems Department about using
their CAD system to lay out the board; they would make the final decision about
use of their CAD system; however, we would certainly urge them to help you out.

Let us know if there is any other way we can help,

	John
*start*
01147 00024 US 
Date: 17 Nov. 1982 8:09 pm PST (Wednesday)
From: Sturgis.PA
Subject: Re: D-lion Cedar
In-reply-to: Levin's message of 17 Nov. 1982 6:17 pm PST (Wednesday)
To: Levin
cc: Sturgis, Taft, Murray, TonyWest, Rovner, Mitchell

I did not intend to suggest any slow done in work on the microcode, mearly that
we were not going to invest any effort in running the Quantum disk in
Rubicon.  I did conclude that we would not be able to use the results in personal
D-Lions until we were in the Minaret world.  

As of this afternoon we have a D-lion with an SA4000, a large control store, and
a large main memory. It is my debuggee.  The floating point microcode is
happily running in it.  I am hoping that we can try booting Cedar on that
machine to see how fast cedar runs when there is no swapping problem, and
soon (next week?, after Thanksgiving?) test Cedar with the floating point code
turned on.

Remember that there is also a problem booting into the large control store, which
will not be solved in any D-Lion system until early next year.  Hence for the
moment, the only way to run the microcode is through Burdock.

Howard

*start*
00841 00024 US 
Date: 16-Nov-82 17:22:12 PST (Tuesday)
From: Fay.pa
Subject: Re: D-lion Cedar
In-reply-to: Sturgis' message of 16 Nov. 1982 2:06 pm PST (Tuesday)
To: Sturgis
cc: Levin, Fay, Howard, Taft, Murray, TonyWest, Rovner, Mitchell

Howard,

Let me clarify one point made in your message:

The Minaret release of Pilot microcode and heads will not include 16K control store booting support.  The reason is that Minaret is now in system test, so its content was fixed long ago.  We plan to include 16K control store booting support in Klamath, the next full release of Pilot.  Klamath is tentatively scheduled to enter system test in June 1983 and be released in September 1983.  I'm hoping to have something usable for you sometime in the first quarter of 1983, with the official version arriving later with Klamath.

--Chuck
*start*
01137 00024 US 
Date: 28-Nov-82 17:08:21 PST (Sunday)
From: Murray.PA
Subject: Function decodes for DES chip
To: TonyWest
cc: Sturgis, Neely, Fasnacht, Fay, Diebert, Murray.PA

More handwaving...

Consider using only one function decode and the cycle number, like the way the mem bit is used to control memory.  In c1, it could load the command/status flags.  In c2, it could load the data-for-DES buffer, in c3, it could read the data-from-DES buffer.

I have not thought about this much, but....  We decided that the hardware would do the appropiate buffering so that the microcode didn't have to worry about the detailed timings on the chip.  My guess is that the easiest way to do this is with a prom.  A slightly bigger prom makes the previous suggestion reasonable.  Another state bit probably makes it reasonable to clock things every 2 cycles rather than 3...

You might talk to Tim to see what he has done for the Dicentra Misc board.  I know there is a Prom in there.  I can show you the way Boggs used proms in the Dicentra to generate a half speed clock (or slower if waiting for memory).  It really worked out nice.
*start*
01354 00024 US 
Date:  8-Dec-82 21:53:10 PST (Wednesday)
From: Murray.PA
Subject: FlapURegs.mc
To: TonyWest
cc: Sturgis, Murray.PA

There is a copy on Debugger.  It seems to do what I asked it to do, but that may not be enough.  I looked at the signals a bit, and didn't see anything wrong.  It uses AltUAddr.  That may be a problem.  Just select "FlapURegs" and poke LoadRaw.

Look at the code.  It activates various strange/unused signals so you have something to sync a scope on.  Stack_ is at the start of the write pass.  _StackP (actually _ErrIbStack or such) is at the start of the read pass.  Each pass compliments the data word which is initialized to 0.  IBPtr_0/1 is used to indicate good/bad read compares.  I forget which -- look at the code.

It's interesting to note that this test doesn't detect addressing errors.  After thinking about it for a few minutes, I rearranged the code.  There isn't a read pass and a write pass any more.  It reads one slot, checks for the right value, and then does the write for the next pass.  This should catch addressing errors.  Unfortunately, it didn't seem to wiggle the signal I expected.  Either I/we don't understand the problem, or there is a bug in my code.

Howard can probably make minor tweaks to the program if that seems appropiate.
Use "Mass FlapURegs/o FlapURegs" to recompile it.
*start*
04681 00024 US 
Date: 14 Dec. 1982 4:12 pm PST (Tuesday)
From: TonyWest.PA
Subject: Dandelion Pseudocode for Encryption
To: Murray, Sturgis
cc: TonyWest, Schroeder, Birrell

Here is some example pseudocode for doing a CBC encryption operation.

Note that the inner loop is almost certainly incorrect.  I will check up exactly
how much pipelining you have before you write the inner loop code.

NB: After writing using MAS, you must allow 6 clocks to go by before doing
anything else!  Perhaps 6 is one too many -- it depends on the exact
implementation of the Y-bus input latch and Cycle logic.

SelectRegister	means MAS is activated
WriteDataByte	means MDS is activated

; First reset the chip to a known state
	SelectRegister(CommandRegister);
	WriteDataByte(x'00');			Software Reset
	Delay(6);					wait for 6 clicks = 6 DES Clocks!

; Now set the mode to do a dual-port encryption, master=clear, slave-cipher
	SelectRegister(ModeRegister);
	WriteDataByte(x'16');			CBC Encrypt mode.
	Delay(6);					wait for 6 clicks!

; Load the Initialization Vector for CBC encryption
	SelectRegister(CommandRegister);
	WriteDataByte(x'85');			Load Clear IVE
	Delay(6);					wait for 6 clicks!

	SelectRegister(InputRegister);
	WriteDataByte(IVByte[0]);
	WriteDataByte(IVByte[1]);
	WriteDataByte(IVByte[2]);
	WriteDataByte(IVByte[3]);
	WriteDataByte(IVByte[4]);
	WriteDataByte(IVByte[5]);
	WriteDataByte(IVByte[6]);
	WriteDataByte(IVByte[7]);

; Load the Encryption key
	SelectRegister(CommandRegister);
	WriteDataByte(x'11');			Load Clear E Key
	Delay(6);					wait for 6 clicks!

	SelectRegister(InputRegister);
	WriteDataByte(EKeyByte[0]);
	WriteDataByte(EKeyByte[1]);
	WriteDataByte(EKeyByte[2]);
	WriteDataByte(EKeyByte[3]);
	WriteDataByte(EKeyByte[4]);
	WriteDataByte(EKeyByte[5]);
	WriteDataByte(EKeyByte[6]);
	WriteDataByte(EKeyByte[7]);

; If we are going to check for Key Parity Errors, we will do so here!

; Start the encryption -- set the pipeline going -- write first block
	SelectRegister(CommandRegister);
	WriteDataByte(41);				Start Encryption
	Delay(6);					wait for 6 clicks!

	SelectRegister(InputRegister);
	WriteDataByte(ClearByte[0]);
	WriteDataByte(ClearByte[1]);
	WriteDataByte(ClearByte[2]);
	WriteDataByte(ClearByte[3]);
	WriteDataByte(ClearByte[4]);
	WriteDataByte(ClearByte[5]);
	WriteDataByte(ClearByte[6]);
	WriteDataByte(ClearByte[7]);

; Loop writing and reading data blocks

; Note that the code has to check for the case where there are only
; 1, 2, or three blocks, and special-case them if necessary

FOR i=Something to SomeOtherThing DO
{
-- NB: Perhaps we can interleave reading and writing blocks

	WriteDataByte(ClearByte[8]);
	WriteDataByte(ClearByte[9]);
	WriteDataByte(ClearByte[10]);
	WriteDataByte(ClearByte[11]);
	WriteDataByte(ClearByte[12]);
	WriteDataByte(ClearByte[13]);
	WriteDataByte(ClearByte[14]);
	WriteDataByte(ClearByte[15]);

	ReadDataByte(EncryptedByte[0]);	means use SDS
	ReadDataByte(EncryptedByte[1]);
	ReadDataByte(EncryptedByte[2]);
	ReadDataByte(EncryptedByte[3]);
	ReadDataByte(EncryptedByte[4]);
	ReadDataByte(EncryptedByte[5]);
	ReadDataByte(EncryptedByte[6]);
	ReadDataByte(EncryptedByte[7]);

	Delay(a little bit -- I'll calculate how long);
};

; Read out the last pipelined block

	ReadDataByte(EncryptedByte[n-7]);
	ReadDataByte(EncryptedByte[n-6]);
	ReadDataByte(EncryptedByte[n-5]);
	ReadDataByte(EncryptedByte[n-4]);
	ReadDataByte(EncryptedByte[n-3]);
	ReadDataByte(EncryptedByte[n-2]);
	ReadDataByte(EncryptedByte[n-1]);
	ReadDataByte(EncryptedByte[n]);

; That's it, fill in the IOCB or something and return
	jmp to fetch

---
There are different constants for various other functions:

Constants you might want to write into the MODE register:
NB: Mode register bit 4 (from right) specifies encryption or decryption

x'14'	DualPort, Master=Clear, Slave=Cipher, ECB Encryption
x'00'	DualPort, Master=Cipher, Slave=Clear, ECB Decryption
x'16'	DualPort, Master=Clear, Slave=Cipher, CBC Encryption
x'02'	DualPort, Master=Cipher, Slave=Clear, CBC Decryption

Constants you might want to write into the COMMAND register:

x'11'	Load Clear E Key through Master Port
x'12'	Load Clear D Key through Master Port
x'85'	Load Clear IVE through Master Port
x'84'	Load Clear IVD through Master Port
x'41'	Start Encryption -- coerce mode register bit 4 to 1 => encryption
x'40'	Start Decryption -- coerce mode register bit 4 to 0 => decryption
x'C0'	Start -- use the current setting of mode register bit 4
x'E0'	Stop -- stuff a spanner in the works (NB: use a wrench in USA)
x'00'	Software Reset

There are other commands, but they are to do with the use of the master key or
the auxiliary port, both of which we shun.
*start*
00221 00024 US 
Date: 14 Dec. 1982 4:22 pm PST (Tuesday)
From: TonyWest.PA
Subject: Des register addresses
To: Murray, Sturgis
cc: TonyWest

Input Regisrter	=	x'00'
Command Register	=	x'02'
Mode Register	=	x'06'

*start*
00828 00024 US 
Date: 8 Dec. 1982 10:03 pm PST (Wednesday)
From: Clark.PA
Subject: Re: Dandelion CPE cost
To: TonyWest
cc: Clark, Henning


Tony,

I've taken so long to reply that I'm forwarding your message below.
I'm sorry.

The cost per board depends on the quantity.
The cost of tooling up depends on the board.

John Henning can help you with both
ballpark and real costs.

How many can we build for you?

				Larry


---------------------------

Date: 16 Nov. 1982 2:22 pm PST (Tuesday)
From: TonyWest.PA
Subject: Dandelion CPE cost
To: Clark

Larry:

I have been asked what the cost of the Dandelion Etch extended CP would be?
How do I go about answering that question -- how do I go about finding out
realistic costs for the chips, board, etc?

Tony
------------------------------------------------------------

*start*
00519 00024 US 
Date: 4 Jan. 1983 10:41 am PST (Tuesday)
From: TonyWest.PA
Subject: Re: Please may I borrow...
In-reply-to: Hallgren's message of 4 Jan. 1983 10:33 am PST (Tuesday)
To: Hallgren
cc: TonyWest, Quan

Clark:

We have ordered Extenders from SDD Dallas (some of which are destined for you guys), but they haven't arrived yet.  I will find out what the delivery is and let you know.

Meanwhile, should you need the extender back, please let me know and I will deliver it -- I haven't forgotten!

Tony
*start*
01046 00024 US 
Date: 4 Jan. 1983 6:16 pm PST (Tuesday)
From: TonyWest.PA
Subject: 16K Dandelion CP
To: DLionCS^
Reply-To: TonyWest.PA

The time is approaching where PARC-CSL will build the first batch of PC-Etch Dandelion CP boards with 16K of control store and DES Encryption.

There are a number of organisations who are interested in acquiring these boards, and they have been asking me for a cost estimate so that they can budget the money.  However, in order to figure out the price, I have to guess a quantity.  So far, the following organisations have expressed an interest in buying boards:

	PARC/CSL			(Boggs)
	PARC/CIS/Interlisp		(Masinter)
	PARC/SCG/Smalltalk 	(Zdybel)
	Versatec			(Dawson)
	SDD/AD			(Israel)
	WRC/ISL			(Damouth)
	WRC/?			(DMurray)
	EOS				(Haney)		?

If there is any other organisation not on the above list interested in buying boards from the first build, please send me a message ASAP so I can complete the quantity estimate and fix a price.

The first build will be in late Febuary/early March.  
Tony
*start*
00224 00024 US 
Date: 4 Jan. 1983 6:26 pm PST (Tuesday)
From: Pier.PA
Subject: Re: 16K Dandelion CP
In-reply-to: Your message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: TonyWest
cc: Pier

Add PARC/ISL, at two boards.

*start*
01774 00024 US 
Date:  4-Jan-83 18:31:22 PST (Tuesday)
From: GCurry.ES
Subject: 16K Dandelion CP
To: Ayers.pa
cc: GCurry.es, Israel.pa, TonyWest.pa

Bob,

I think this falls under the charter of our (new) area in AD.  I think we should acquire several of these with an eye to experimenting with microcodization of different parts of Star (and establishing cost/benefit correspondences).  In an earlier message, Tony West indicated that the price of fully populating this board was about $900 (that's just to populate it) with fully-to-spec fast RAM chips and about $600 with probably-to-spec chips.

I in particular am interested in this.

Gael 

------------------------------
Date: 4 Jan. 1983 6:16 pm PST (Tuesday)
From: TonyWest.PA
Subject: 16K Dandelion CP
To: DLionCS^
Reply-To: TonyWest.PA

The time is approaching where PARC-CSL will build the first batch of PC-Etch Dandelion CP boards with 16K of control store and DES Encryption.

There are a number of organisations who are interested in acquiring these boards, and they have been asking me for a cost estimate so that they can budget the money.  However, in order to figure out the price, I have to guess a quantity.  So far, the following organisations have expressed an interest in buying boards:

	PARC/CSL			(Boggs)
	PARC/CIS/Interlisp		(Masinter)
	PARC/SCG/Smalltalk 	(Zdybel)
	Versatec			(Dawson)
	SDD/AD			(Israel)
	WRC/ISL			(Damouth)
	WRC/?			(DMurray)
	EOS				(Haney)		?

If there is any other organisation not on the above list interested in buying boards from the first build, please send me a message ASAP so I can complete the quantity estimate and fix a price.

The first build will be in late Febuary/early March.  
Tony

----------------------------------------------------------------
*start*
00933 00024 US 
Date: 4 Jan. 1983 6:54 pm PST (Tuesday)
From: Sturgis.PA
Subject: 16K Dandelion CP
To: TonyWest.PA
cc: Sturgis

With respect to building CP boards, are you aware of these guys?

howard

---------------------------

Date: 4 Jan. 1983 12:59 pm EST (Tuesday)
From: Knox.wbst
Subject: DLion Microcode
To: Sturgis.PA
cc: Knox

Howard,

I understand from Allen Brown that you are developing floating point microcode
for the DLion.  We would also like to develop some specialized microcode for the
DLion.  Would you be able to answer the following questions for us?

What parts of the standard microcode set can be removed to make room for the
microcode to be tested?

What and where is the official set of microcode for Pilot 8.0?

Can the microcode be assembled on a DLion, i.e. is there a Mass.bcd that runs on
a DLion?

Thanks for your help,

Keith

------------------------------------------------------------

*start*
00625 00024 US 
Date: 4 Jan. 1983 10:13 pm PST (Tuesday)
From: Clark.PA
Subject: Re: 16K Dandelion CP
In-reply-to: Your message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: Boggs, Mitchell, Murray, Sosinski, TonyWest, Yeary
cc: Henning, Vest, Clark


Before we arrange for a high quantity build
I think we should do a small prototype run of 12 (+/- 10).

There are some unaswered questions for higher quantities
like who will debug them? Is the garage going to build enough
to justify training some one in the garage?

Does the first build get anounced, start, or deliver
in late Febuary/early March.  

				Larry Clark

*start*
00637 00024 US 
Date: 5 Jan. 1983 8:56 am EST (Wednesday)
From: Damouth.Wbst
Subject: Re: 16K Dandelion CP
In-reply-to: TonyWest.PA's message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: TonyWest.PA
cc: Damouth, DMurray

Tony, to help us generate a realistic estimate can you  say more about your own
planning assumptions - in particular:

How far into the future should we plan?  Are you trying to meet all 1983 PARC
needs with one build, or will a 2nd build follow fairly quickly?  What is the
probability that the 1st build will eventually have to be extensively reworked or
discarded to be compatible with future builds?

/Dave

*start*
00677 00024 US 
Date: 5 Jan. 1983 11:39 am EST (Wednesday)
From: DMurray.wbst
Subject: Re: 16K Dandelion CP
In-reply-to: Damouth's message of 5 Jan. 1983 8:56 am EST (Wednesday)
To: TonyWest.PA
cc: Damouth, DMurray

Tony, thanks for your message regarding a build of 16K Dandelion CP's.  As I
am part of WRC/ISL (Damouth) my order will be included there although I may
do the actual paperwork.

One technical question.  I've received a hint that the board relies on a fast ram
chip (or other) that has a questionable supplier.  The import seems to be that
there may be problems with replacements, future builds, etc.  

Is any of this near true or just tales?  

Dan 

*start*
00600 00024 US 
Date: 5 Jan. 1983 1:54 pm EST (Wednesday)
From: Bespalko.WBST
Subject: Re: DLion 16K control store
In-reply-to: Your message of 5 Jan. 1983 8:57 am PST (Wednesday)
To: TonyWest.PA
cc: Bespalko, Ellis

Ginn & Co. is in the process of replacing it's Alto population with Dandelions
running Mesa and Interlisp.  Potentially over the next year or so we will want
between 25 and perhaps as many as 50 16K Rams.   In the build you are talking
about please assume we will want 3.  If another build is not scheduled before
midyear we will want some quanity (maybe 5-10) more.

Steve

*start*
00317 00024 US 
Date: 5 Jan. 1983 1:37 pm PST (Wednesday)
From: Resnick.ES
Subject: Re: 16K Dlion Control Memory
In-reply-to: TonyWest.PAs message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: TonyWest.PA
cc: Resnick

Tony;
Are these the Control boards with 16K RAMs that have been replaced by 64K
RAMS?
	Richard

*start*
00455 00024 US 
Date:  5-Jan-83 14:05:19 PST (Wednesday)
From: Zdybel.PA
Subject: Re: 16K Dandelion CP
In-reply-to: Your message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: TonyWest
cc: Zdybel.PA

I just spoke with Adele about the quantity of extended CP's we'll
be needing.  We will want three altogether.  I have all the parts
(except for a board) for one of these.  That means we will need
in addition three boards and two suits of parts.

Frank

*start*
00747 00024 US 
Date: 5 Jan. 1983 3:35 pm PST (Wednesday)
From: JWhite.PA
Subject: 16K DLion CP
To: TonyWest
cc: , JWhite

Tony,
    
     Rick Barth forwarded a copy of your message regrading the quantity of
DLion CP Boards to construct in the first build.  That, in turn, reminded me that
I was to have confirmed, with a message, a conversation we had a few months
ago regarding ICL interest in "wide-bodied" DLions.  ICL has four DLions ( one
in place, three coming after modification by EES to expand main memory to 512k
and the disk to 40Mb) and would like to purchase new CP boards for all of them.

So, please include  PARC/ICL (JWhite) in your figuring and include me or the
DLionCS^ distribution list.

Thanks.

John White (ICL)

*start*
00823 00024 US 
Date: 6 Jan. 1983 11:15 am PST (Thursday)
From: TonyWest.PA
Subject: 16K Dandelion CP
To: Taylor, Mitchell, Boggs, Clark
cc: TonyWest

After sending out the survey message, the current status of the answers is:

Organisation			min.	max.	Person		Phone

Fairly sure:
PARC/CSL			7	10	Boggs.PA		4421
PARC/ISL			2	2	Pier.PA		4861
PARC/ICL			4	4	JWhite.PA		4507
PARC/CIS/Interlisp		1	5	Masinter.PA		4365
PARC/SCG/Smalltalk	3	3	Zdybel.PA		4358
Versatec			9	11	Dawson.PA		(408) 773-1747

Not sure:
SDD/AD			4	8	Israel.PA		4618
WRC/ISL			4	10	Damouth.WBST	8*222-3186/3172
WRC/?			3	50!	Besalko.WBST	8*222-?
EOS				x	x	Haney.EOS		8*844-2328

Total				37	103

It seems a VERY good idea to start with a small build of 5-10, say, to make sure that they work properly!  Megalomaina can follow in good time.

Tony
*start*
03618 00024 US 
Date: 6 Jan. 1983 3:35 pm PST (Thursday)
From: Garner.PA
Subject: Re: DLion memory
In-reply-to: Purcell's message of 5 Jan. 1983 11:32 pm PST (Wednesday)
To: Purcell
cc: Garner, Murray, Boggs, Ogus, TonyWest, Masinter

Steve,

I spoke with Tony today, and he indicated that the extended CS CP card has not
yet gone in for PC artwork, so we have the option of doing something now.

Since it appears that any alteration to the flags can be handled exclusively by
microcode, nothing has to be done in this area (such as adding an AND gate and
a new branch bit). 

So the discussion revolves around the YH bits.  Per a discussoin I had with Hal
last night, there are several options.  Hal and David have opted for a scheme
where the microcode can set a mode bit which changes the number of upper YH
bits sent to the memory (and there's something about being related to the CS
bank number also....).  Thus, the Dicentra will always have the capability of
running existing DLion code.

For the DLion, as you pointed out, "former flag bits become real address bits and
are carried in RH."  No problem, except that, obviously, the code which
currently looks at the flag bits must be changed to expect the new format.  (My
previous observation was that the current code may store flag bits in upper RH
bits which are then branched on much later.  Things are even worse if the
current code stores NON-Map-flag bits there.....)

Now, the Bank=0 (=DisplayBank) signal, which is generated on the CP card, is
used to disable the system clock (WaitClock) whenever the code tries to access
the display bank (low 64K) but the display controller is actually reading from it. 
If we didn't connect more YH bits (i.e., the next two, YH.2 and YH.3) up to this
gate, then two things would happen:  (1)  the Emulator would be slowed down
by 40% whenever it read/wrote locations from the 3 new effective "display
banks" (which would come to 3/16, or ~20% of the total memory space); (2) 
device code would be excluded from those sections of memory.

One may also want to be able to connect up all 8 bits of YH, which allows the
use of special code which knows about "hyperspace."  This is one of the
possible modes in the Dicentra, I beleive.  (Note that Smalltalk wouldn't use the
Map, and so would be able to use all 24 bits as a real address...)

I see two possibilities:  (1) Tony suggested that one use jumpers to connect up
the upper YH bits.  (2)  Have a mode bit setable my code which would
conditionally connect them up.  Both approaches would be implementable from a
circuit delay perspective (it turns out that this path is one of the most critical
time paths in the DLion).  In case (2), change the S51 to an S64 and use an S00
or some multiplexer to hook up the YH bits.  In case (1), one could add another
S260 (and, as a side benefit, use the other haft to reclaim the LS32+S02 gates
used to generate WriteIB).

One mode bit is not enough to distinquish the two cases of looking at YH[2-3] or
also looking at YH[0-3], hyperspace.  We would need to be able to read the mode
bit(s).  Mode bits would be most flexible, since the code could elect to use the
extra one, two, or hyperspace YH bits at will (and self-protection). 
Manufacturing people may not like the jumpers (but that may not matter in this
case..)

I guess a key question on hyperspace is whether the code would ever mix
hyperspace references together with normal references.  If it did, this would
imply the need for one or two mode bits (two if the existing code must also
work.)

Are there any other possibilities?

Robert 


*start*
00540 00024 US 
Date: 7 Jan. 1983 12:26 pm PST (Friday)
From: TonyWest.PA
Subject: Bank Select on 16K CP
To: Garner
cc: Boggs, TonyWest

Bob:

w.r.t. your point about trying to bring out the bank select signals for the four 4K banks earlier so that I can use 70nS Rams instead of 55nS Rams:

I am using an Am25S09 to drive the bank select signals.  I checked these devices and the latch comes after the multiplexor internally, not before.  Thus, there would seem to be little point in changing this.

Have I missed something?

Tony
*start*
00356 00024 US 
Date: 7 Jan. 1983 1:16 pm PST (Friday)
From: TonyWest.PA
Subject: Using IMS 1420-70 for 16K CP
To: Garner
cc: Boggs, Clark, TonyWest

For the IMS1420-70 parts
	Tacs=	70 nS
	Taa=	65 nS

So, as far as I can see, there seems to be very little doubt that the IMS1420-70's would work fine in the 16K CP board.  What do you think?

Tony

*start*
00402 00024 US 
Date:  8-Jan-83 13:55:15 PST (Saturday)
From: Murray.PA
Subject: Re: DLion memory
In-reply-to: Garner's message of 6 Jan. 1983 3:35 pm PST (Thursday)
To: Garner
cc: Purcell, Murray, Boggs, Ogus, TonyWest, Masinter

Unless you are going to rewrite the disk diagnostics and all that sort of stuff, the machine must default (at boot time) to something that runs normal Mesa/Pilot.
*start*
00422 00024 US 
Date: 5 Jan. 1983 4:22 pm PST (Wednesday)
From: Vest.PA
Subject: Re: 16K Dandelion CP
In-reply-to: Clark's message of 4 Jan. 1983 10:13 pm PST (Tuesday)
To: Clark
cc: Boggs, Mitchell, Murray, Sosinski, TonyWest, Yeary, Henning, Vest

I think that we should forget about the prototype run, order the boards needed
and get people from the EMS trained to debug the 16K Dandelion CP boards.

Frank




*start*
00705 00024 US 
Date: 11 Jan. 1983 3:54 pm PST (Tuesday)
From: Krasner.PA
Subject: D'lion 16K ustore
To: tonyWest
cc: ingalls, deutsch, zdybel, Krasner

Tony,

I have a couple quick questions about the 16K store for dandelions:

1)  Since the d'lion IFU branches to a 256 fixed locations, and given the 4-bank
scheme for the 16K store, I infer that you could run with up to 4 different
instruction sets, each occupying those 256 locations in a different bank.  In
particular, we would be able to use the IFU for both Smalltalk and Mesa.  Am I
correct?

2)  I heard that the current board will only fit 12K.  Is this true or just an old
version, rumors of which have not died down?

Thanks,
glenn

*start*
01068 00024 US 
Date: 12 Jan. 1983 10:14 am PST (Wednesday)
From: TonyWest.PA
Subject: Re: D'lion 16K ustore
In-reply-to: Krasner's message of 11 Jan. 1983 3:54 pm PST (Tuesday)
To: Krasner
cc: tonyWest, ingalls, deutsch, zdybel

1. Since the d'lion IFU branches to a 256 fixed locations, and given the 4-bank
scheme for the 16K store, I infer that you could run with up to 4 different
instruction sets, each occupying those 256 locations in a different bank.  In
particular, we would be able to use the IFU for both Smalltalk and Mesa.  Am I
correct?

	- Yes, but remember, there is only 1 bank register, so only the emulator task can use it.  Furthermore, the bank is not coerced to 0 upon traps etc, so you have to have fault handlers, etc. in each bank.

2. 2)  I heard that the current board will only fit 12K.  Is this true or just an old
version, rumors of which have not died down?

	- False.  The Rev-S, -T, and, soon, the -U boards all can carry 16K.
	The -U board also carries DES Encryption hardware, addressable via
	a couple of fZ decodes.

Tony
*start*
00702 00024 US 
Date: 6 Jan. 1983 3:11 pm PST (Thursday)
From: Resnick.ES
Subject: Re: 16K Dlion Control Memory
In-reply-to: Your message of 6 Jan. 1983 11:06 am PST (Thursday)
To: TonyWest.PA
cc: Resnick

Tony;
I realized my mistake right after I sent the message. These boards would then be
for unique systems which need beefed-up micro code, right? If thats so, we
should be talking to the various section managers and seeing if they have need
for these boards.

If it sounds to you that I've got this whole thing mixed, please give me a call
and straighten me out. There may be some people in ED who can use these
boards and I would like to help them out if I can.
	Richard     8*823 9885

*start*
01032 00024 US 
Date:  6-Jan-83 19:43:21 PST (Thursday)
From: Fay.pa
Subject: Queries from Webster
To: Murray, Neely, Ogus, TonyWest
cc: Fay.pa

You may receive queries from two Xerox people in Webster about DLion-based microcode tools and/or 16K control store DLions.  Keith <Knox.wbst> and Mitch <Lichtenberg.wbst> are starting to develop DLion microcode to display and manipulate scanned images (such as Ais files) on the DLion display.  They are interested in using DLion-based microcode tools and the 16K DLion.

After warning them that our new microcode tools and umbilical are still being debugged and are not part of our public releases, I have invited them to use them.  I recounted the standard dogma about how we don't promise to support their use of this unreleased hardware and software.  I gave them pointers to the various tools on the Minaret archive directory, as well as your names as persons to contact about your specialties (Burdock, microcode tools, umbilicals, and 16K DLions, respectively).

--Chuck
*start*
00512 00024 US 
Date: 11 Jan. 1983 11:08 am EST (Tuesday)
From: Damouth.Wbst
Subject: Re: 16K Dandelion CP
In-reply-to: TonyWest.PA's message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: TonyWest.PA
cc: Damouth, ISLAdmin^

The first-build requirements for WRC/ISL (including DMurray, who is part of
ISL) is 15 units.  This could change by plus or minus five units depending on
the answers to the questions in my message of January 5.  We would probably
also want 15 to 20 units from a second build.


/Dave

*start*
00401 00024 US 
Date: 14 Jan. 1983 6:56 pm PST (Friday)
From: Clark.PA
Subject: Re: Using IMS 1420-70 for 16K CP
In-reply-to: TonyWest's message of 7 Jan. 1983 1:16 pm PST (Friday)
To: TonyWest
cc: Boggs, Henning, Thomson, Clark

Tony,

My current information is that the IMS1420-70
is a single source part.  That could be trouble someday.
Do you know if there is a second source?

				Larry

*start*
00418 00024 US 
Date: 14 Jan. 1983 7:22 pm PST (Friday)
From: TonyWest.PA
Subject: Re: Using IMS 1420-70 for 16K CP
In-reply-to: Clark's message of 14 Jan. 1983 6:56 pm PST (Friday)
To: Clark
cc: TonyWest, Boggs, Henning, Thomson

I think that, for the IMS1420-70nS parts, you can substiture Fujitsu MB8168-70.
I don't know what the availability of these devices is.

Fujitsu mane a -55nS version also.

Tony

*start*
00279 00024 US 
Date: 15 Jan. 1983 5:19 pm PST (Saturday)
From: TonyWest.PA
Subject: Dandelion boards
To: McKinley
cc: Mitchell, TonyWest

Grady:

Did you have any luck tracking down the current state of the order for Dandelion extender boards from SDD in Dallas?

Tony

*start*
01137 00024 US 
Date: 17 Jan. 1983 6:04 pm PST (Monday)
From: TonyWest.PA
Subject: Quality pays off!
To: Quan, RRicci
cc: Boggs, Murray, Thacker, TonyWest

Dick/Becky:

just a note to say that the care and attention you take welding boards REALLY pays off big.  I got back the sCPE-V board today, plugged the IC's back in, turned on the power, and it worked perfectly first time!

As far as I am concerned, this is nothing short of FANTASTIC!  The loose wire bit seems to help a lot, then, and you should definitely continue to wire fairly loosely.

Question:

How long does it take to strip a board of the complexity of the CPE card?  I have an sCPE-S prototype, and, I think that, by the time you have reworked it from S to T to U to V and then to W (soon), you might have gotten there much quicker by stripping and rewiring from scratch (after ohming out the board and resoldering the power connections).

If the answer to this question is a smallish time (say, up to 1 day), then I will send the board over tomorrow for Becky to eviscerate, and she can be doing that whilst I test out the new stuff on the -V revision.

Tony
*start*
00709 00024 US 
Date: 17-Jan-83 20:28:26 PST (Monday)
From: Murray.PA
Subject: Mass for Sierra
To: Neely
cc: TonyWest, Fay, Murray.PA

How are things going?

Tony's got a version of the CP with a DES chip in it, so we need a few more Fz decodes before we can test it.  Will you have something ready it a day or so, or do I work from my version.  One complication is that I fatfingered it and deleted a few of my files.  I don't know if they had any interesting edits.

Specs (in case you are all ready to go):

	FzNorm = 9 => DESCtl _ Ybus, c1
	FzNorm = 9 => DES _ Ybus, c2 or c3
	FzNorm = A => Xbu _ _DES (any cycle)

Tony: Is this right?  In particular, is it still c1 that loads the control flags?
*start*
00416 00024 US 
Date: 18-Jan-83 10:22:08 PST (Tuesday)
From: ALBrown.PA
Subject: Re: 16K Dandelion CP
In-reply-to: Your message of 4 Jan. 1983 6:16 pm PST (Tuesday)
To: TonyWest
cc: ALBrown.PA, DaveSmith.PA

Tony,

SDD Advanced Development would like to order four (4) of the PC-etch DLion CP boards with 16K of control store and DES encryption.  How much are they, and what's the ordering procedure?

Allen
*start*
00367 00024 US 
Date: 18 Jan. 1983 10:40 am PST (Tuesday)
From: TonyWest.PA
Subject: Re: Mass for Sierra
In-reply-to: Murray's message of 17-Jan-83 20:28:26 PST (Monday)
To: Murray
cc: Neely, TonyWest, Fay

Yes, 
	FzNorm = 9 => DESCtl _ Ybus, c1
	FzNorm = 9 => DES _ Ybus, c2 or c3
	FzNorm = A => Xbus _DES (any cycle)

is correct.

Ready when you are.

Tony
*start*
01033 00024 US 
Date: 21-Jan-83 20:34:54 PST (Friday)
From: Neely.pa
Subject: Sierra Mass & MakeDLionMicroBoot
To: Murray, TonyWest
cc: Fay, Neely.pa

For a very short time Sierra Mass and MakeDLionMicroBoot (with sources) are on:

    [Idun]<microcodetoolsdlion>sierra>
    
Monday I'll be moving them to [Idun]<microcodetoolsdlion> 
and <microcodetoolsdlion>sierra> will be deleted.

I did NOT get the DES stuff in yet.    
	FzNorm = 9 => DESCtl _ Ybus, c1
	FzNorm = 9 => DES _ Ybus, c2 or c3
	FzNorm = A => Xbus _DES (any cycle)
I'll do that Monday unless you beat me to it.  If you put it in this weekend please save it on [Idun]<microcodetoolsdlion>sierra> and let me know.  

If you add the DES stuff or need to fix bugs, [Idun]<microcodetoolsdlion>sierra>
has four procedures that will help you. 

They are: BuildMass.cm FetchMass.cm PurgeMass.cm SaveMass.cm. They are set up for
Sierra and Save stuff on [Idun]<microcodetoolsdlion>sierra>.  The password for 
[Idun]<microcodetoolsdlion> is DANDY

Have Fun,    /ev. 	
*start*
01470 00024 US 
Date: 20 Jan. 1983 10:15 am PST (Thursday)
From: Winfield.PA
Subject: re: 16K Dandelion CP
To: TonyWest.PA
cc: Winfield

Tony,

I am also interested in buying a couple of the 16K Dandelion CP boards.  Who
will be coordinating this effort?  Can you make inform them of my interest in
acquiring some of these boards?  

Thanks,

	Bill

---------------------------
Date: 4 Jan. 1983 6:16 pm PST (Tuesday)
From: TonyWest.PA
Subject: 16K Dandelion CP
To: DLionCS^
Reply-To: TonyWest.PA

The time is approaching where PARC-CSL will build the first batch of PC-Etch
Dandelion CP boards with 16K of control store and DES Encryption.

There are a number of organisations who are interested in acquiring these
boards, and they have been asking me for a cost estimate so that they can
budget the money.  However, in order to figure out the price, I have to guess a
quantity.  So far, the following organisations have expressed an interest in
buying boards:

	PARC/CSL			(Boggs)
	PARC/CIS/Interlisp		(Masinter)
	PARC/SCG/Smalltalk 	(Zdybel)
	Versatec			(Dawson)
	SDD/AD			(Israel)
	WRC/ISL			(Damouth)
	WRC/?			(DMurray)
	EOS				(Haney)		?

If there is any other organisation not on the above list interested in buying
boards from the first build, please send me a message ASAP so I can complete the
quantity estimate and fix a price.

The first build will be in late Febuary/early March.  
Tony
------------------------------------------------------------

*start*
01214 00024 US 
Date: 23-Jan-83  0:55:18 PST (Sunday)
From: Murray.PA
Subject: DES: Horrible bug or obscure feature
To: Birrell, Schroeder
cc: TonyWest, Murray.PA

I grabbed a copy of the DES stuff on Cedar in order to test Tony's hardware and/or my microcode.  It seemed reasonable to try the software version first to make sure I knew what was going on.

After getting it to compile on my (Sierra) machine, I pushed go, and stumbled into a Tajo bug; TYY.Create simply makes a black hole.  (Isn't system testing fun.)  So I turned it into a tool.  (That stuff gets more exercise.) 

After flushing out a handful of my bugs, I still had problems with the CBC mode.  I finally tracked it down to what is either an undocumented feature, or a nasty bug that I'm surprised you never stumbled into.  The input data is getting smashed.

From DESFace:
--	to[0] _ Encrypt[from[0] XOR seed^]
--	to[i] = Encrypt[from[i] XOR to[i-1]]
  
Observed implementation:
--	to[0] _ Encrypt[from[0] _ from[0] XOR seed^]
--	to[i] = Encrypt[from[i] _ from[i] XOR to[i-1]]

I patched my version of DESSoft to copy over the input clump into a temporary variable, and my program has stopped complaining.

Is this really a feature?

*start*
01731 00024 US 
Date: 23-Jan-83  1:12:28 PST (Sunday)
From: Murray.PA
Subject: Re: Sierra Mass & MakeDLionMicroBoot
In-reply-to: Neely's message of 21-Jan-83 20:34:54 PST (Friday)
To: Neely
cc: Murray, TonyWest, Fay

Thanks.  That's just what I needed.

MakeDLionMicroBoot got a NIL fault trying to make a copy of the switches.  I flushed your CopyString, and called String.CopyToNewString.  I also changed String.EquivalentStrings to String.Equivalent (the new prefered form) while I was there.  I noticed that you had Runtime commented out.  If you put an "IF FALSE THEN" in front of the place where you do the CallDebugger, then you don't have to edit the DIRECTORY/IMPORTS area.  The new version is out there.

I had a few troubles getting the tables fixed.  The main one was that there wasn't any spare space, so I changed TmAssembler, and recompiled the whole world.  While I was at it, I left a few spare slots.

The other problem I'm having is that I don't understand _Foo.  It seems to require an entry via the IO table rather than the macro table.  (I forget the exact names.)  It sure looks like an entry in the main macro table should work.  It has all the options that seem reasonable.  LRotx gets entered this way, but when I tried _DES, it kept acting like it didn't know there was anything on the Xbus.  After a few attempts, I put the entry into the IO table.

As part of the struggle, I changed DES_ to DESMP_ and _DES to _DESSP.  Do you think Mass could sort things out if I didn't make that change?

I also moved Bank_ from FZ 4 to FY 13.  BEWARE: The chart in Garner's book is out of date!

I have NOT stored my changes to Mass on MicrocodeToolsDLion.  The sources are backed up on [Idun]<Murray>DES>.
*start*
00336 00024 US 
Date: 23-Jan-83 23:31:45 PST (Sunday)
From: Murray.PA
Subject: Timings
To: TonyWest
cc: Murray.PA

I put a scope on MFLG and SFLG.  It's a bit rough to sync cleanly, but I ignored that.  Triggering on the falling edge of MFLG, it's 23 clocks (9.5 microseconds) until SFLG falls.  That seems to mesh with 5 + 18.
*start*
02264 00024 US 
Date: 24 Jan. 1983 4:33 pm PST (Monday)
From: TonyWest.PA
Subject: Board template etc. for Dandelion board
To: AKTsang.PA, Boggs.PA
cc: Lin.ES, Ogus.PA, TonyWest.PA, Inouye.ES, McCreight.PA

Dave:	you should keep this message.  I have also filed it under
	[Indigo]<Dandelion>CPE>Boards>ReadThisMessage.txt

Alan:	here is a directory listing of [Indigo]<Dandelion>CPE>Boards

------
BuildRb.run
	Inouye.ES's program to turn templates into .rb files

BasicRouteBoard.template
	 Copy this into foo.template and edit it to describe your new board foo. 
When you have done that, run BuildRb on foo.template to generate the foo.rb
file.  BuildRb will also give you some numbers which you should write down
for the next step.  foo.rb is the compressed pin/column table which ED's route
program pre-loads when you specify the Route /i switch.  NB: CSL's route does
NOT support the /i switch or the use of templates at all! 

BasicRouteBoard.bcpl
	Copy this into foo.bcpl, then edit foo.bcpl and fill in the italic fields with
the numbers BuildRb told you in the previous step.  Compile foo.bcpl using to
generate the foo.br file

------
Now for the actual versions of these files I currently use for the Dandelion CPE:

SwBoardType2.template
	This is the template I edited to describe the high-density board I actually
use for the CP project.  There is currently only one type of connector template
known, a Cannon DB-37 D-Type.  You might consider adding others as well,
perhaps.  Note that I have also changed where you can put 40-pin chips.  See
	[Indigo]<Dandelion>CPE>Drawings>sCPE01.sil for examples.

SwBoardType2.bcpl
	This is the edited characterisation for the H-D board.

SwBoardType2.rb
	This is the compressed pin/column table for the H-D board.

SwBoardType2.br
	This is the compiled characterisation for the H-D board.

SwBoardType2Grid.sil
	This is a coordinate description drawing for the H-D board.

SwBoardType2Layout.sil
	This is a more-accurate placement drawing for the H-D board.  

------
SwBoardType1Grid.sil		These files are for the older, low-density board
SwBoardType1Layout.sil		These files are for the older, low-density board
------

If you have questions, mail me at TonyWest.PA and I will be here next week.

Tony

*start*
01083 00024 US 
Date: 24 Jan. 1983 5:56 pm PST (Monday)
From: TonyWest.PA
Subject: Dandelion CP Tutorial - Postponed
To: Garage^, Sosinski
cc: Ogus, AKTsang, Garner, Murray, Boggs, Taylor, Schroeder, Overton, Yeary,
 Thacker, McCreight, TonyWest
Reply-To: TonyWest

Folks, 

I would like to defer the tutorial class until later into next week than we had
originally agreed, say, Thursday 3rd (?).  This will allow me time to complete
the documentation I had hoped to get to you by today.

Meanwhile, everyone interested print out and make copies of the following
documents:

1. The complete hardware manual for the standard Dandelion (in 3 parts)
	[Indigo]<Dandelion>CPE>Docs>DLionManual1.press
	[Indigo]<Dandelion>CPE>Docs>DLionManual2.press
	[Indigo]<Dandelion>CPE>Docs>DLionManual3.press

2. The logic diagrams for my CP board
	[Indigo]<Dandelion>CPE>Archive>sCPE-W.press

I will add two more documents before I finally discorporate:
	- How the 16K CP differs from the standard CP
	- How to debug a 16K Dandelion CP

That'll be when I get back, early next week.

CU, Tony
*start*
01928 00024 US 
Date: 24 Jan. 1983 6:25 pm PST (Monday)
From: TonyWest.PA
Subject: Extended CP - DES works!
To: CSL^, DLionCS^
cc: Ogus, Redell, Linden, Printis, AlBrown, Fay, Fasnacht
Reply-To: TonyWest

Announcing the addition of DES encryption logic to the extended Dandelion CP.
The logic diagrams are stored on [Indigo]<Dandelion>CPE>Archive>sCPE-W.press

By adding 3 new opcodes, 

	WriteDesAddress[RegisterAddress];
	WriteDesData[Byte];
	Byte _ ReadDesData[];

and writing a rather nice tool running under Sierra to do the rest in software,
Hal Murray has managed to test out the logic and encrypt the standard test
patterns supplied by the National Bureau of Standards.  This is only an interim
approach.

Hal is now working on full-speed DesBlt microcode, which will support the
Cedar DesFace at a more reasonable speed.  The theoretical maximum throughput
for the Dandelion (assuming that the emulator can keep the chip busy, which is
unlikely), will be somewhere between 4 and 8 MBits/second.  Measurements will
tell....

Note, the DES logic was designed to be an option -- you can leave out the 9 (or
so) chips is you haven't thought of a use for Des yet.  

My plans:

I will be away for the rest of this week, returning on 1/31/83 to conclude my
part in this project.  The project will then (probably) be handed over to David
Boggs, who will shepherd the board through PC production.

Early Warning:

If you have questions about this board which you would like to ask me, please
send them to me in a message sometime before next week, and I will answer
them.  Your last chance will be Friday 4th February, when I will turn into a
pumpkin.

Before I leave, however, I intend to supplement the standard CP documentation
with two extra memos:
	- How the 16K CP differs from the standard CP
	- How to debug a 16K CP 

Before I leave, I will send out a message summarising the state of the PC plans.

CU,
	Tony
*start*
01238 00024 US 
Date: 24-Jan-83 20:59:17 PST (Monday)
From: Murray.PA
Subject: DES fun and games
To: TonyWest
cc: Diebert, Boggs, Taft, Birrell, Murray.PA

I think I just uncovered why things suddenly started working last night.  I stumbled into this while trying to get some new microcode working....

I think the microcode and head were correct for a long time, but somehow, things had gotten out of sync.  Notice that if the output buffer ever gets an unexpected byte in it, things will stay out of sync if the microcode/head read/write the correct number of bytes.  zPushing the boot button (rather than just fetching a new head and rebooting the volume, or even reloading the microcode) is needed to get rid of the extra byte.

I just finished patching the DESCtl microcode to discard the byte if one was there, but that seems stupit.  I'll move it to the head and leave the microcode interface clean.  I do a software reset of the chip on each call, so there is a reasonable place to discard the byte.

Unfortunately, either way will light the error light in the normal case.  Maybe we should invent some way for the software to explicitly request a hardware reset, for example, strobe MAS with a funny bit set on the Ybus.
*start*
02126 00024 US 
Date: 25-Jan-83  2:42:49 PST (Tuesday)
From: Murray.PA
Subject: DLion DES Microcode
To: TonyWest, Sturgis, Rovner, Schroeder, Birrell, Levin, Taft
cc: Diebert, Boggs, Garner, Johnsson, Sandman, Sweet, Fay, Neely, Murray.PA

7 micro instructions is enough to provide 3 ESC opcodes that implement a simple byte-at-a-time interface.  Tony and I used this to debug the hardware and software.  My test program ran at 0.25 megabits/sec, but I didn't try much to tune it up.

My next attempt added 2 more opcodes to read/write 8 byte blocks.  That used 50 microinstructions and runs at 1.64 megabits/sec.

When I looked at a code listing, I discovered that the Compiler doesn't like to store 4 word records.  So I changed the 4 word clumps to 2 words, and modified the head to do a pair of operations for each block.  The microcode shrank to 30 microinstructions and it runs at 1.68 megabits/second.

Then I unrolled the inner loop by a factor of 4.  (That's as far as RLDILP and WLDILP will reach.)  Now it's running at 2.06 megabits/sec.  That's 2 milliseconds/page.  Actually I measured it at 2.4 with overhead and whatever.  (20% overhead seems high, but I didn't investigate where it's going.)

If somebody writes the full-blast microcode, the inner loop should go at 8 megabits/sec.  (1/4 millisecond per page.)  That's assuming that we can keep the DES chip busy.  Since we are driving it by counting clicks, things will actually be slower by whatever fraction of the CPU is used by the display and friends.

I counted clicks, but I could only account for 56 out of 75.  That leaves 25% of the CPU used by the display task, keyboard process, and ....  That seems reasonable to me, but I have not timed things like that in ages.  Does anybody have any up to date numbers?  I'm using Tajo 10.0d.

I'm quite confident that the hardware is working the way we expect it to, but I can't demonstrate that it will work correctly at full speed.  Unless somebody is really worried that it won't work or we can't make it go fast enough and/or has some go-faster ideas that are easy to try, I'm going to stop now.
*start*
01248 00024 US 
Date: 26-Jan-83 22:29:57 PST (Wednesday)
From: Murray.PA
Subject: How big is the DES chip pipeline
To: TonyWest, Diebert
cc: Sturgis, Murray.PA

I have always been thinking that the chip could only hold 2 blocks.  I'm thinking about how to make the loop structure for BLT (and friends) work for DESBLT.  One of the complications is getting the timing to work out right.  The idea is to prime the pipe, and then store a word and read a word in the inner loop.  Note that this transfers words rather than blocks.

At first glance, this won't work right because you have to wait for the first block to get crunched before you can extract the first work.  But now that I think about it, while I was looking at MFLG and SFLG on the scope the other day, I don't think I ever saw MFLG delay for other than the 5 or 6 clock pause right after I fed it the last byte of a block.

I think what this means is that there is actually room for 3 blocks in the pipe; one in the input buffer, one in the cruncher, and one in the output buffer.

If so, I can prime things with 2 blocks, and then use the normal BLT loop to fetch/store a word at a time, without having to wait for the first block to migrate through the cruncher.  Make sense?
*start*
02205 00024 US 
Date: 2 Feb. 1983 11:53 am PST (Wednesday)
From: TonyWest.PA
Subject: Dandelion Prom Instructions
To: Boggs.PA
cc: Murray.PA, Schroeder.PA, Schmidt.PA, TonyWest.PA

Dave:

KEEP THIS MESSAGE!

I have prepared an Alto disk with all the Prom information on for the 16K CP
board.  All the Proms are standard, except for the SwitchProm, which is RevR in
my board.  Also, in the CPE, there are two additional proms for the optional DES
stuff.

NOTES:

1. I use the SDD/Mesa prom blowing software, not the BCPL software.

2. Type "Bringover /a [Indigo]<Dandelion>CPE>DfFiles>Proms.df" to make sure
that you have the latest tools, prom sources, and prom data files.  I have
carefully constructed this df file so that it manages all the things that you need
either to alter or to blow any of the CPE proms.  All the files are described in
Proms.df, including a number of useful .cm files.

3. If you change anything, you absolutely MUST type "smodel proms.df"
afterwards to make sure that the changes are flushed back onto Indigo and the
proms.df file is kept up-to-date.  If you don't do this, all hell will break loose.  If
you forget, don't dare call me up!  YOU HAVE BEEN WARNED!  (This is about
the only way in which you can screw up with the Alto df software.  Ask Eric
Schmidt for a quick tutorial -- it's really worth it).

4. [Indigo]<Dandelion> has connect password "WILDFLOWER", for protection.

5. After booting and bringing over the latest files, the way you blow a prom is
to type "blow" to the Alto exec.  This loads mesa, blow.image, and SmallAltoTajo,
and starts up the prom tool.  Fill in the PROM: field with the prom type, eg.
F93427, etc. (see prom.specs file), then fill in the filename in the Prom file: field,
eg. DesMpProm-RevB.  No filename extensions are necessary.  Then push BLOW!
and stand clear.  You will be prompted to load the proms, etc.

6. This is the standard SDD prom stuff.  Should you run into trouble, call Clark
Hallgren in SDD, or speak to Roy Ogus -- they live and breathe this stuff.

7. There is also further documentation out on [Iris]<Workstation>*prom*press --
you might retrieve that and read it if you need to.

KEEP THIS MESSAGE!

Tony

*start*
01415 00024 US 
Date: 2 Feb. 1983 3:20 pm PST (Wednesday)
From: TonyWest.PA
Subject: Dandelion CPE Tutorial - Friday at 10.00 am
To: Garage^, Sosinski, DBrown, Winfield
cc: Murray, Boggs, Taylor, Schroeder, Overton, Yeary, Thacker, McCreight,
 Ogus, AKTsang, TonyWest, Ornstein
Reply-To: TonyWest

Folks, 

I would like us to get together in the ISL conference room on Friday morning at
10.00 am so that I can pass on to you a little hardware information and
experience with the Extended CP for the Dandelion.

Note that the purpose of this meeting is NOT to describe the standard CP, but the
extended version which CSL has been working on.  The meeting is intended for
those who will be associated with building and maintaining these boards, rather
than with those who will use them.

The main reason for holding it up here instead of the Garage is that we can
wonder over to some machines already set up here and play with the debugging
tools which I have been using to debug these boards.

Should this time present problems for you, please send me a message and I will
attempte to reschedule for the only other possibility, Friday afternoon at 14.00.

Meanwhile, I have nearly completed the documentation.  I will have available
some copies of

	- DLion Hardware Manual
	- the logic diagrams
	- my CSL Notebook entry about the Extended CP card
	- past mail relating to the design, etc.

CU Friday,
	Tony
*start*
04326 00024 US 
Date: 2 Feb. 1983 4:32 pm PST (Wednesday)
From: TonyWest.PA
Subject: SDD and Dandelion Extender Boards
To: McKinley
cc: Shoch, JWeaver, Wick, Mao, Ogus, NDSmith, Mitchell, Murray, Pake,
 Spencer, Spinrad, Taylor, Bice.ES, Peltz.ES, Winfield, Carlsen, Haney.EOS, Clark,
 TonyWest

Grady:

On September 21 1982, I attempted to find an organisation in Xerox which could
supply Dandelion Extender boards to order.  My enquiries yielded these facts:

	1. There was no official Xerox part number for these boards
	2. They had to be built to special order by one of two main sources
	3. The sources are Roger Peltz of ED or Jim Daughetee of SDD Dallas.  

Since the SDD price was MUCH less than the ED price, I decided to follow up
with SDD.

I contacted Daughetee who gave me three items of information:

	1. He did not have the budget to bankroll the production of a batch of
	these boards up-front and then collect later.

	2. He had no boards in stock, but he had already got orders from Field
	Engineering for 30 boards.

	3. He needed to make this up to 50 before he could cause a batch to be
	made for a reasonable price.

I also contacted Bill Bice of SDD/ES, who informed me

	4. Daughetee owed him 6 boards as the result of an earlier deal.

I then invested a considerable amount of time in scratching around the
corporation to collect together the remaining 14 orders so that Daughetee could go
ahead and make a batch of 50.

The final position, on October 25 1982, was:

Boards for which Daughetee already had orders or was committed to build:
			Org		Qty	Phone		Bgt	A/c
Field Engineering	?		30
Bill Bice		SDD		6	8*823-7524		???	???
TOTAL				36

Additional orders I found:
			Org		Qty	Phone		Bgt	A/c
Roy Ogus		SDD		4	8*923-4687		745	???
Terry Haney		EOS		3	?			???	???
Tony West		PARC		4	8*923-4476		050	702	
Bill Winfield	PARC		2	8*923-4375		021	702
George Carlsen	Versatec	1	(408) 773-9090	???	???
TOTAL				14
----------------------------------------------------------------------------
GRAND TOTAL			50, Daughetee's minimum build quantity
----------------------------------------------------------------------------

To make life simple for SDD, CSL submitted an order for 14 Dandelion extender
boards to Jim Daughetee in SDD Dallas in early November 1982.  We did this to
avoid confusing SDD with a blizzard of separate internal transfers and budget
centers.

Since then, I have heard nothing from Daughetee on the status of this order. 
Repeated attempts by PARC purchasing to determine the status of affairs have
met with very little response.  I have sent endless messages to him through
Grapevine, US Mail, etc, and find him impossible to reach.  If anyone else is
enjoying the same kind of experience, then I would say this is indicative of a
more serious situation which will have widespread implications for OSD.


I have a number of comments:

	1. I find it rather amazing that there is no standard Xerox part number or
	procedure for ordering these extender boards, which, of course will be
	needed in growing numbers by maintenance centers within the
	Corporation.

	2. I find it puzzling that SDD cannot provide Daughetee with sufficient
	budget to buffer the production of one batch of 50 boards, thus enabling
	SDD to maintain a stock of these boards and to supply them ex stock.

	3. Further, I find it stupefying that one of the only two sources of these
	boards should be so unresponsive in the face of our extensive attempts to
	smooth over their lack of manufacturing budget and to follow up to
	determine the status of our order.

	4. This is not the only occasion on which we in PARC have had
	difficulty ordering equipment from SDD in Dallas.  There is a serious
	communication and/or procedural problem here, and, if customers find
	ordering things only a fraction as difficult as we, who supposedly "know"
	the procedures, then this problem must be considered major.

Grady:  Have you had any better luck than I in sorting out what Daughetee in
SDD Dallas is doing or not doing about these Dandelion extender boards?

My last day will be Friday, so if you have any remaining problems, let's get
together before then, and I will transfer to you any remaining information you
may need to complete or cancel this business, which has wasted a large amount
of my time.

Tony
*start*
00740 00024 US 
Date:  2-Feb-83 17:26:16 PST (Wednesday)
From: Ogus.pa
Subject: Re: SDD and Dandelion Extender Boards
In-reply-to: TonyWest's message of 2 Feb. 1983 4:32 pm PST (Wednesday)
To: TonyWest
cc: Bice.ES, Mau, Ogus

Tony,

A important word of clarification:  Jim Daughetee does not work for SDD.  He works for OPD/Manufacturing, which is in a totally separate division from Office Systems Division, not to say SDD.  There is no way to "order . . equipment from SDD in Dallas".  You have been dealing with a totally separate organization from us, of which we (SDD) have no control.  I totally sympathize with your frustration, however.

(It would make sense for you clarify the above to your previous distribution.)

Roy. 
*start*
01264 00024 US 
Date: 2 Feb. 1983 5:53 pm PST (Wednesday)
From: TonyWest.PA
Subject: Correction and apologies
To: McKinley, Shoch, JWeaver, Wick, Mau, Ogus, NDSmith, Mitchell, Murray,
 Pake, Spencer, Spinrad, Taylor, Bice.ES, Peltz.ES, Winfield, Carlsen, Haney.EOS,
 Clark, TonyWest
 

Apologies for the error.  The issue remains the same, however, there must be a
better solution to the problem of how to order test equipment for Dandelions.

Tony
---------------------------

Date:  2-Feb-83 17:26:16 PST (Wednesday)
From: Ogus.pa
Subject: Re: SDD and Dandelion Extender Boards
In-reply-to: TonyWest's message of 2 Feb. 1983 4:32 pm PST (Wednesday)
To: TonyWest
cc: Bice.ES, Mau, Ogus

Tony,

A important word of clarification:  Jim Daughetee does not work for SDD.  He
works for OPD/Manufacturing, which is in a totally separate division from
Office Systems Division, not to say SDD.  There is no way to "order . . equipment
from SDD in Dallas".  You have been dealing with a totally separate organization
from us, of which we (SDD) have no control.  I totally sympathize with your
frustration, however.

(It would make sense for you clarify the above to your previous distribution.)

Roy. 
------------------------------------------------------------

*start*
04647 00024 US 
Date: 2 Feb. 1983 11:25 pm PST (Wednesday)
From: Clark.PA
Subject: Dandelion Extender Boards
To: Henning
cc: TonyWest, Clark

John,

I'm about to suggest we toss this ball to you.
Watch this space for my next message.

				Larry

---------------------------

Date: 2 Feb. 1983 4:32 pm PST (Wednesday)
From: TonyWest.PA
Subject: SDD and Dandelion Extender Boards
To: McKinley
cc: Shoch, JWeaver, Wick, Mao, Ogus, NDSmith, Mitchell, Murray, Pake,
 Spencer, Spinrad, Taylor, Bice.ES, Peltz.ES, Winfield, Carlsen, Haney.EOS,
Clark,
 TonyWest

Grady:

On September 21 1982, I attempted to find an organisation in Xerox which could
supply Dandelion Extender boards to order.  My enquiries yielded these facts:

	1. There was no official Xerox part number for these boards
	2. They had to be built to special order by one of two main sources
	3. The sources are Roger Peltz of ED or Jim Daughetee of SDD Dallas.  

Since the SDD price was MUCH less than the ED price, I decided to follow up
with SDD.

I contacted Daughetee who gave me three items of information:

	1. He did not have the budget to bankroll the production of a batch of
	these boards up-front and then collect later.

	2. He had no boards in stock, but he had already got orders from Field
	Engineering for 30 boards.

	3. He needed to make this up to 50 before he could cause a batch to be
	made for a reasonable price.

I also contacted Bill Bice of SDD/ES, who informed me

	4. Daughetee owed him 6 boards as the result of an earlier deal.

I then invested a considerable amount of time in scratching around the
corporation to collect together the remaining 14 orders so that Daughetee could go
ahead and make a batch of 50.

The final position, on October 25 1982, was:

Boards for which Daughetee already had orders or was committed to build:
			Org		Qty	Phone		Bgt	A/c
Field Engineering	?		30
Bill Bice		SDD		6	8*823-7524		???	???
TOTAL				36

Additional orders I found:
			Org		Qty	Phone		Bgt	A/c
Roy Ogus		SDD		4	8*923-4687		745	???
Terry Haney		EOS		3	?			???	???
Tony West		PARC		4	8*923-4476		050	702	
Bill Winfield	PARC		2	8*923-4375		021	702
George Carlsen	Versatec	1	(408) 773-9090	???	???
TOTAL				14
----------------------------------------------------------------------------
GRAND TOTAL			50, Daughetee's minimum build quantity
----------------------------------------------------------------------------

To make life simple for SDD, CSL submitted an order for 14 Dandelion extender
boards to Jim Daughetee in SDD Dallas in early November 1982.  We did this to
avoid confusing SDD with a blizzard of separate internal transfers and budget
centers.

Since then, I have heard nothing from Daughetee on the status of this order. 
Repeated attempts by PARC purchasing to determine the status of affairs have
met with very little response.  I have sent endless messages to him through
Grapevine, US Mail, etc, and find him impossible to reach.  If anyone else is
enjoying the same kind of experience, then I would say this is indicative of a
more serious situation which will have widespread implications for OSD.


I have a number of comments:

	1. I find it rather amazing that there is no standard Xerox part number or
	procedure for ordering these extender boards, which, of course will be
	needed in growing numbers by maintenance centers within the
	Corporation.

	2. I find it puzzling that SDD cannot provide Daughetee with sufficient
	budget to buffer the production of one batch of 50 boards, thus enabling
	SDD to maintain a stock of these boards and to supply them ex stock.

	3. Further, I find it stupefying that one of the only two sources of these
	boards should be so unresponsive in the face of our extensive attempts to
	smooth over their lack of manufacturing budget and to follow up to
	determine the status of our order.

	4. This is not the only occasion on which we in PARC have had
	difficulty ordering equipment from SDD in Dallas.  There is a serious
	communication and/or procedural problem here, and, if customers find
	ordering things only a fraction as difficult as we, who supposedly "know"
	the procedures, then this problem must be considered major.

Grady:  Have you had any better luck than I in sorting out what Daughetee in
SDD Dallas is doing or not doing about these Dandelion extender boards?

My last day will be Friday, so if you have any remaining problems, let's get
together before then, and I will transfer to you any remaining information you
may need to complete or cancel this business, which has wasted a large amount
of my time.

Tony
------------------------------------------------------------

*start*
00686 00024 US 
Date: 2 Feb. 1983 11:32 pm PST (Wednesday)
From: Clark.PA
Subject: Re: SDD and Dandelion Extender Boards
In-reply-to: TonyWest's message of 2 Feb. 1983 4:32 pm PST (Wednesday)
To: TonyWest
cc: McKinley, Mitchell, Murray, Taylor, Henning, Clark

Tony,

I suggest we cancel our order
and build them ourselves in the Garage.
We will be needing them soon.

The Garage will attempt to scout up filmwork or bare boards or
simply have new artwork made locally (with a ground plane),
find or make drawings for the iron work,
buy the parts and assemble them.
We will then sell them to anyone with money up front
and maybe even make enough to pay for our own.

				Larry

*start*
00234 00024 US 
Date: 3 Feb. 1983 8:23 am PST (Thursday)
From: Henning.PA
Subject: Extender Cards
To: TonyWest
cc: Clark, Henning

Tony,
	What was the SDD price and what was the ED price for the Extender
Cards?

John Henning

*start*
01732 00024 US 
Date: 3 Feb. 1983 10:40 am PST (Thursday)
From: TonyWest.PA
Subject: Re: SDD and Dandelion Extender Boards
In-reply-to: Clark's message of 2 Feb. 1983 11:32 pm PST (Wednesday)
To: Clark, Henning
cc: TonyWest, McKinley, Mitchell, Murray, Taylor

I think the idea of the Garage making these is WONDERFUL!

The PC side of it is trivial -- the ironwork not quite so simple, but still OK.
I have borrowed a board from Dick Quan which you are welcome to look at.

By the way, Roy Ogus of SDD is most supportive of us in this problem -- he
would also be your first customer.  Roy can give you the full, dirty story!

About seeing if you can find the artwork, talk to Roger Peltz or ED, Bill Bice of
SDD/ES, and (if you can dredge up the necessary energy) Daughetee of OPD
Manufacturing in Dallas.  However, if you started from scratch, it would not
take very long to make up the film.

CSL could well do the Corp. a great service by providing a quality source of
these boards.  Since anyone buying a CPE from you may well want an extender,
it makes a lot of sense.  There is also the possibility of CSL making some small
bucks on the side, too.  The situation IS very confused about these things, and
SDD may very well PREFER to deal with us than OPD in Dallas.

As soon as you feel sure about this, please tell Grady to cancel my order -- I
have spoken to him about this possibility and instructed him to hang about until
he hears from you.  Needless to say, now that I have fired off the broadside, the
sooner he hears from you, the better -- OPD might feel spurred into action.

The OPD price was $300 each, the ED price nearer $600.  I ordered 14 (only some
of which were for us - see the salvo message).

Tony
*start*
00742 00024 US 
Date: 3 Feb. 1983 10:45 am PST (Thursday)
From: TonyWest.PA
Subject: Your Dandelion Extender board
To: Quan
cc: Sosinski, Overton, Murray, Hallgren, TonyWest, Clark

Dick:

As you know, CSL borrowed a DLion Extender off you last year whilst we were
ordering some.  We haven't forgotten about it.

Our attempts to order some from OPD manufacturing in Dallas were disastrous, so
we still don't have any yet.  CSL is considering the idea of making these
extender boards in the Garage -- in which case the problem might go away soon.

As before, any time you want it back, ask Charlie Sosinski, and it will be
returned.  However, if you don't need it, we sure would appreciate it if you
wouldn't foreclose just yet!

Tony