*start*
01973 00024 US 
Date: 18 July 1981 2:54 pm PDT (Saturday)
From: Taft.PA
Subject: Dorado power-off trashes disk
To: Diebert
cc: DoradoCore^

Tim, I'd like you to investigate a problem I have seen several times, in which
loss of power in the Dorado while the disk is on-line causes the disk to be
trashed.  This can happen if a Dorado power supply fails (as happened on Roy
Levin's Dorado last week).  It can also happen if you turn off the right-hand lab
Dorado, whose disk has been jumpered to stay on all the time; I've observed this
to trash the disk on two separate occasions.  Invariably, cylinder zero is wiped
out.

Note that I am not talking about the power-failure handling in the disk drive
itself, since the drive remains on.  Rather, loss of power in the Dorado is
somehow commanding the drive to write.  It is easy to demonstrate that
something bad is happening; turning off the lab Dorado with the disk on almost
invariably causes a device check -- an indication of illegal commands being sent
to the drive.

It's my understanding that IOReset is supposed to be asserted when the power
supplies are out of spec; this should gate off all the select lines out to the disk. 
Additionally, there is a relevant comment on page 11 of the DiskEth drawings:
"The characteristics of the MC125 indicate that TtlRunOK' should be high
whenever +5V is ON and -5V is OFF."  This suggests that Roger at least thought
about the problem, though it is now clear that he did not completely solve it.

I consider this to be a serious problem.  I've become aware of it only recently,
because cylinder zero (the one usually clobbered) is not used for Alto emulation,
but is used by Pilot; trashing cylinder zero renders a Pilot volume unusable,
because there is not yet a Pilot scavenger capable of rebuilding the vital
information that is written there.  Dorado power supply failures are a common
enough occurrence to warrant a thorough investigation of this problem.
	Ed

*start*
02970 00024 US 
Date: 10 Aug. 1981 6:36 pm PDT (Monday)
From: Taft.PA
Subject: LF displays vs. Alto emulation mode
To: ABell, Deutsch, Masinter, Willie-Sue
cc: Fiala, Taft

The display microcode included with the Dorado Alto emulator (used with the
Lisp and Smalltalk microcode) does not presently provide a way of accessing all
of an LF display, but rather simulates an Alto-style picture centered in the LF
screen.

I'm prepared to make some provision for putting up a picture that fills an LF
display.  But I understand that something has already been done on the Dolphin;
I want to learn about this so I can determine whether it's general enough to be
used on the Dorado as well.

In the absence of any existing convention, I would propose doing something like
the following:

1. At initialization time, determine what type of monitor (Alto or LF) is actually
connected, and leave this information in a register.  (This is already done on the
Dorado.)

2. Provide a new instruction (in the Alto instruction set) that enables software to
determine the type of monitor.  I suggest that the instruction should return the
number of words per scan line (38 for an Alto monitor, 64 for an LF monitor). 
The Lisp and Smalltalk emulators can have their own instructions that do this, or
they can escape to Alto emulation mode to obtain the information.

3. Provide some way of enabling and disabling the extra left margin that is now
inserted in order to center the simulated Alto picture on the LF monitor.  There
are three alternatives:

  a) Static -- the presence of the extra left margin is a function of the microcode
itself.  That is, the display microcode loaded with the Lisp and Smalltalk
emulators would simply not have the extra left margin.  A consequence of this is
that when running vanilla Alto programs with the Lisp or Smalltalk microcode,
the Alto picture will be left-justified rather than centered on the LF monitor. 
(Most likely I would determine whether or not to include the extra left margin
by calling some new subroutine in the emulator-specific xTraps.mc module,
rather than by having different versions of the display microcode itself.)

  b) Dynamic -- the display microcode switches between strict Alto simulation
and wide-screen mode dynamically on the basis of information provided by the
software.  This could be invoked by a special bit in the DCB or something.  This
is relatively difficult, at least on the Dorado, because it involves reloading the
horizontal waveform Ram (which may cause the screen to glitch).

  c) Always operate in LF mode, and simply put up with the fact that the
simulated Alto picture is left-justified rather than centered.  Does anyone really
care?  I only bothered to center the picture on the Dorado so as to be consistent
with what was already being done on the Dolphin.

I'm inclined toward alternative (c).  In any event, the Dolphin and Dorado
should adopt the same conventions.

Comments?
	Ed

*start*
01076 00024 US 
Date: 10 AUG 1981 2017-PDT
From: ABELL.PA
Subject: LF displays ...
To:   Taft
cc:   ABell, Deutsch, Masinter, Willie-Sue, Fiala

I agree with your suggestions for the wide screen microcode.  I
have done very similar things for the Lisp ucode.  There is
a lot of interest in allowing Lisp to use wide screen Dorados
to their fullest extent.

I have 2 versions of ucode - one for narrow screens and one for wide.
Some people run the narrow version on wide screens but not
many and I don't think it is important.

I have a Lisp instruction that communicates the size in words
to Lisp.  This size is determined by ucode constant since I
have 2 versions of ucode.

I have choosen option c.  When running bravo on the Dorado
currently, It is more difficult due to the centered display
with white edges.  The scrollbar positions are harder to find.

I would like to see this mapped into the alto mesa ucode also.  I
would be happy to donate my ucode for that purpose.  It is a
bad idea to make the choice dynamic if that increase the size
of the ucode.

Alan
*start*
00964 00024 US 
Date: 11 Aug. 1981 10:04 am PDT (Tuesday)
From: Deutsch.PA
Subject: Re: LF displays vs. Alto emulation mode
In-reply-to: Taft's message of 10 Aug. 1981 6:36 pm PDT (Monday)
To: Taft
cc: ABell, Deutsch, Masinter, Willie-Sue, Fiala

A fairly simple way to keep centered screens under alternative (c) is to have
another microcode register that gives a value to be added to the "tab" field of the
DCB.  This would be initialized to zero for the small display and the appropriate
value for the wide display.  A new Emulator instruction would be required to
reset this value.  This would be a good solution on the Dorado; on the Dolphin,
which has much tighter microcode constraints, I suppose we can live with
left-justified pictures with Lisp and Smalltalk, i.e. alternative (a).  I don't like
(c), since if I'm running any of a large number of other programs I would like to
be able to boot the standard microcode and get a centered display.

*start*
01614 00024 US 
Date: 11 Aug. 1981 12:05 pm PDT (Tuesday)
From: Taft.PA
Subject: Re: LF displays vs. Alto emulation mode
In-reply-to: Deutsch's message of 11 Aug. 1981 10:04 am PDT (Tuesday)
To: Deutsch
cc: Taft, ABell, Masinter, Willie-Sue, Fiala

Your suggestion of a software-settable value to add to the "tab" field of the DCB
is straightforward.  But, as Alan pointed out, this will result in the borders being
background color (usually white) rather than black.  This may be objectionable
when running certain programs such as Bravo.

The reason the borders are now black in Alto emulation mode is that the
horizontal waveform Ram is loaded in such a way as to blank the borders. 
Reloading the Ram to blank or unblank the borders is straightforward on the
Dorado, but it may cause the display to glitch.  I don't know how bad the glitch
will be, so I will experiment.

Assuming this works OK, here is a tentative spec for a new Alto emulator
instruction for dealing with display width:

Opcode = 61032B

AC0 = -1 makes available the full width of the display, whatever that is.  (If an
	Alto-style monitor is connected, this has no effect.)
AC0 = 0 reverts to an Alto-size picture.

Returns the number of words per scan line (38 or 64) in AC0.

The precise effects of this instruction (e.g., Alto picture centered or left-justified,
borders blanked or not, etc.) are implementation-dependent.  I will try to do the
best I can in the Dorado implementation, but the Dolphin implementation need
not do exactly the same thing.

I will start implementing this unless someone has a counter-proposal.
	Ed

*start*
03507 00024 US 
Date: 11 Aug. 1981 4:38 pm PDT (Tuesday)
From: Fiala.PA
Subject: LF Monitors
To: Taft
cc: Deutsch, ABell, Masinter, Willie-Sue, Fiala

On the Dolphin, the decision to "allow" 64 words/line must be made when the
UTVFC's horizontal ram is initialized.  The code for this is all initialization,
overwritten by resident microcode after execution, and it has a size of about
60-octal microinstructions.  In order to "allow" either 38 words/line or 64
words/line operation, it would be necessary to either make this code resident and
reexecute it when changing line width or to initialize width to 64 words
once-and-for-all and then tab (i.e., add zero words) at the end or beginning of
each scanline.

Since the "standard" Alto microcode system has only about 240-octal unused
microinstructions, and a variant for Thacker has much less free space, and two
additional floating point opcodes are forthcoming, using 60-octal to reinitialize
the horizontal ram is undesirable.

Increasing the horizontal ram line width to 64 words and tabbing for programs
written for a 38-word scanline would add about 4 microseconds/scanline to the
computation required for the display task.  Since there is 1 scanline/28
microseconds, the display's share of the machine will increase from about 28% to
42%, slowing the emulator by 22%.  The display task can just barely service the
UTVFC with this requirement.

However, if the program running with 64-word wide scanlines follows the Pilot
convention, overhead is substantially less.  The Pilot convention requires every
scanline to start at an address that is a multiple of 20b and disallows all tabbing
at the beginning and end of each scanline.  With these restrictions, the Dolphin
microcode is able to handle each scanline in a worst case time that is actually
less than the worst for a 38-word scanline.

For these reasons, I do not think that it is reasonable to allow any variation in
line width in the standard microcode system.  In the Lisp/Smalltalk systems,
however, where it is expected that Lisp/Smalltalk will normally be running, and
where execution of Swat, FTP, Bravo, etc. is possible and must be allowed for but
is not expected to occur frequently, it might make sense to initialize for 64-word
wide scanlines and live with the 22% performance degradation of FTP, Bravo,
etc. by supplying extra zeroes at the end of each scanline.  This will left-justify
the image rather than centering (but this will be a good indication that the slow
Lisp or Smalltalk microcode is running rather than the faster standard Alto
microcode, so maybe this is a feature).

Note: the full display width would ALWAYS be available if this were done.  The
DCB format specifies the number of words being supplied and the display
microcode will truncate words beyond the width limit.  The opcode proposed by
Taft could be implemented in both the standard Alto microcode system and the
Lisp and Smalltalk systems, but for the Alto system it would return 38 for any
kind of monitor, while for Lisp and Smalltalk it would return 64 for LF monitors,
38 for CSL monitors--it would return information but do nothing in both cases.

I propose to go ahead and implement opcode 61032b according to Taft's spec as
follows:  For the standard Alto system, it will return 46b = 38d in AC0 regardless
of what kind of monitor is in use; AC0 will get loaded by a microinstruction in
the display overlay, so it will be possible to do something different for Lisp or
Smalltalk.

*start*
00769 00024 US 
Date: 11 Aug. 1981 5:46 pm PDT (Tuesday)
From: Taft.PA
Subject: Pilot microcode incompatibility
To: DoradoUsers^
Reply-To: Taft

I intend shortly to release a version of the Dorado Pilot microcode that will be
incompatible with versions of Pilot and Cedar released prior to July 20.  If you
have not already done so, you should update your Pilot boot files and Cedar
system by following Russ Atkinson's message of July 20.

The best way to see whether your Dorado's Pilot world has already been
converted is to check the date in the upper left corner of the CoPilot display.  If
it says "CoPilot 6.0 of July 19, 1981" then it is new enough.

If the microcode change will cause you insurmountable difficulties, please notify
me immediately.
	Ed

*start*
00951 00024 US 
Date: 16 Aug. 1981 1:21 am PDT (Sunday)
From: Taft.PA
Subject: Obscure DispY programming restriction
To: Pier
cc: Fiala, Taft

When loading the HRam, in general it is necessary to start by issuing a
LoadAddress (KeepHRam' = 0, LoadHRamAddr = 1) TWICE.  This is because
LoadHRamAddr takes effect only if DoradoHasHRam is ALREADY asserted when
the command is executed.  So the first command turns on DoradoHasHRam, and
the second one actually loads the address.

The only reason we never noticed this before is that DoradoHasHRam is usually
asserted already when we want to load the HRam, because an IOReset has been
done previously.  But my latest microcode loads the HRam on the fly when
switching dynamically between Alto emulation and full screen mode. 
(Unfortunately, it took me about 6 hours to figure out why I couldn't load the
HRam successfully a second time, though the same code had worked fine the
first time!)
	Ed

*start*
01038 00024 US 
Date: 17 Aug. 1981 7:52 pm PDT (Monday)
From: Taft.PA
Subject: Dorado Pilot microcode & boot files
To: DoradoUsers^, CedarUsers^
Reply-To: Taft

A new version of the Dorado Pilot microcode has been released.  Since Dorado
microcode is always booted from the Ethernet, you do not need to do anything to
begin using it.

As previously announced, this microcode is incompatible with Pilot boot files
created earlier than July 20, 1981.  (More precisely, older boot files work fine
with the new microcode, but programs that run on top of them and that use the
TrapSupport package, including Cedar and Reals, will stop working.)

If you have not already updated your Pilot boot files and Cedar system, you
should follow the procedure in Russ Atkinson's message of July 20.  The best
way to see whether your Dorado's Pilot world has already been converted is to
check the date in the upper left corner of the CoPilot display.  If it says "CoPilot
6.0 of July 19, 1981" (or some more recent date) then it is new enough.

*start*
00877 00024 US 
Date: 17 Aug. 1981 7:59 pm PDT (Monday)
From: Taft.PA
Subject: New AEmu
To: ABell, Deutsch, Masinter, Willie-Sue
cc: Fiala, Taft

I've completed the changes to permit switching an LF display between Alto
emulation mode and full screen mode, as described in my message of August 11.

You should reload the Dorado Lisp and Smalltalk emulators with the contents of
the latest version of [Ivy]<DoradoSource>AEmuDibs.dm.  You will need to edit
your xTraps.mc file to remove the definition for opcode 61032B, since that opcode
has been taken over for display mode switching.

There is also a new version of D1Lang.mc (incorporated in AltoEmuDefs.st) with
one change: the Data macro, used to assemble constants into IM, now accepts
9-bit values in all four bytes; formerly it accepted 9-bit values in Byt0 and Byt2
but only 8-bit values in Byt1 and Byt3.
	Ed

*start*
01607 00024 US 
Date: 20 Aug. 1981 1:01 pm PDT (Thursday)
Sender: Taft.PA
Subject: New baseboard code
From: McCreight, Taft
To: Sosinski, Yeary
cc: DoradoCore^

There is now new baseboard code (both microcomputer code and Dorado bootstrap
microcode) ready to be installed in all Dorados.  The changes are:

1) Boot microcode now understands about LF monitors.  This should fix the
problem of unreliable booting on Dorados with LF monitors.

2) Microcomputer reset (power on or front-panel boot) does NOT turn on the ECL
supplies or the disk, but rather immediately enters the "shut down" state (5
flashes of the green light).  However, if the Dorado is ALREADY on, the
front-panel boot initiates the complete bootstrap sequence, as before.

This new feature is defeated by the backpanel jumper that presently defeats
waiting for the disk to spin up.  That is, if the jumper is installed,
microcomputer reset initiates the full power-on and boot sequence as before.

3) Watchdog timer code is installed.  Of course, this is effective only on
baseboards that have been reworked to include the watchdog timer mod.

4) Power-down from the terminal requires 7 pushes of the boot button rather
than 4.

5) DoradoBaseRom.mb has been diddled so that it should no longer conflict with
Midas's symbols.

The new baseboard code is now installed on the "Sosinski DoradoProms" disk, and
has been backed up on Ivy.  New EProms should be installed in all Dorados as
time permits.  All 4 EProms on each baseboard need to be reprogrammed.  We
have already installed new EProms in Phoenix and Ticonderoga.

	Ed & Ed

*start*
01215 00024 US 
Date: 27 Aug. 1981 5:21 pm PDT (Thursday)
From: Taft.PA
Subject: Ethernet bug fixed
To: DoradoCore^
Reply-To: Taft

Around lunchtime today, three Dorados halted with "PE from Input by task 7"
(the Ethernet input task).  This seemed like too much of a coincidence to be
caused by anything besides a design bug in the Ethernet controller, provoked by
some peculiar sequence of events on the wire that all three Dorados saw
simultaneously.

David and I investigated, and sure enough.  We found a bug that could cause
the data to change while parity is being computed over it.  Why we've never
seen this before is a complete mystery; as far as we can tell, it should occur
whenever packets arrive spaced very close together in time.

Anyway, it's possible to fix this by changing one of the PRom programs in the
Ethernet controller.  So that is what we have done.  The new PRom program is
backed up on [Ivy]<DoradoLogic>DoradoProms.run and
<DoradoSource>DoradoProms.dm.

Chip h11 is the one that needs to be reprogrammed.  We have blown new h11
chips for Ticonderoga and for the Dorado in Mike's lab; and there is another new
h11 chip on the top of the PRom blower cabinet for you to copy.
	Ed

*start*
00753 00024 US 
Date:  8 SEP 1981 1450-PDT
From: MCDANIEL.PA
Subject: [ivy]<doradologic>doradoproms.run
To:   sosinski, ornstein
cc:   taft, mcdaniel

There is a new version of the DoradoProms program on Ivy which generates
command files for the Prologue prom blower rather than the "blue box".

This should enable the construction of new proms rather than simply copying old 
ones.

Charlie, Herb or someone must take responsibility for verifying that the new 
command files generate the correct proms!  Do this by running the new version of
DoradoProms and then making a new set of proms.  Then compare the new set with
an old set.  They should be the same (except, perhaps, for the fixed Ethernet
prom -- ask Taft or Boggs about this).

Gene
*start*
00885 00024 US 
Date: 17 Sept. 1981 1:24 pm PDT (Thursday)
From: Fiala.PA
Subject: Dorado Hardware Manual Release
To: DoradoUsers^
cc: Fiala
Reply-To: Fiala

A new release of the Dorado Hardware Manual is available.  It includes a major
revision to the display controller chapter, medium revisions to the disk and
instruction fetch unit chapters, and minor revisions elsewhere.  Thanks are due
to Ed Taft for his work on the Display and Disk chapters.

Kathi Anderson has agreed to make two-sided copies for people who request them
from her before 25 September.  If you want to print your own copy, it is stored
as three files on [Ivy]<DoradoDocs> DoradoManual-A.press,
DoradoManual-B.press, and DoradoManual-Figs.press.  However, the manual is
about 180 pages so you probably will want to get your copies through Kathi.

Please report any needed changes in the manual to me.

*start*
00801 00024 US 
Date: 21 Sept. 1981 3:36 pm PDT (Monday)
From: Willie-Sue.PA
Subject: drastic Cedar microcode change
To: DoradoUsers^, CedarUsers^
Reply-To: Willie-Sue

	Wednesday morning, I am going to release Dorado microcode for a new
version of Cedar, which will be released soon.  This microcode is incompatible
with the current release of Cedar, so both versions of microcode will be available
for your booting pleasure.

BE WARNED: using T and triple booting your Dorado will get you the OLD
(current) microcode; using C will get you the NEW code.

If you happen to use incompatible microcode and software, you'll end up in
CoPilot, with an uncaught signal from RTRefCountsImpl (if you had the sources
it would say WrongMicrocodeVersion and print out a couple numbers).

  Willie-Sue 

*start*
00365 00024 US 
Date: 23 Sept. 1981 6:19 pm PDT (Wednesday)
From: Taft.PA
Subject: Dorado microcode
To: Willie-Sue, Rovner
cc: Taft

I've released new microcode (both Pilot and Cedar) that I believe handles stack
overflow traps properly in all cases.

Willie Sue: I changed AEmuSources as well as DMesaSources, so you should load
new versions of both.
	Ed

*start*
02159 00024 US 
Date: 24 Sept. 1981 3:53 pm PDT (Thursday)
From: Taft.PA
Subject: Dorado booting; memory expansion
To: DoradoUsers^
Reply-To: Taft

1. A number of Dorados exhibit the problem that a 3-push boot sometimes loads
the wrong microcode (i.e., microcode not corresponding to the key you hold
down).  This problem began occurring when LF monitors were installed on
Dorados.  The problem has been solved, but the solution requires installing new
boot EProms on all machines.  Progress on this has been slow due to other
competition for Herb and Charlie's time (e.g., item 2 below), but should be
complete within another week or two.

If you absolutely cannot boot the microcode you want, but you can get to your
Alto partition, then invoke the NetExec and type "LoadMicrocode filename",
where "filename" is one of the following:

	DoradoMesa.eb	Alto Mesa (no-keys boot)
	DoradoSmalltalk.eb	Smalltalk-76 (S boot)
	DoradoLisp		Lisp (L boot)
	DoradoPilot		standard Pilot (T boot)
	DoradoCedar		Cedar Pilot (C boot)

2. The technicians are in the process of upgrading all Dorado memories from
512K to a megaword.  This has to be done right away for various complicated
reasons (mostly administrative and budgetary), even though it is inconvenient
for some Pilot users.

Specifically, when the amount of memory on your machine changes (or any
other hardware change is made, e.g., a change in its Ethernet address), then you
must re-boot your Pilot volume (and your CoCoPilot volume, if you have one). 
That is, use Othello (or the Tajo/CoPilot BootFrom menu) to boot first CoCoPilot
and then CoPilot (i.e., repeat step 9 of the "Setting up Pilot" procedure).

Furthermore (and this is the bad news), when the amount of real memory
increases, then re-booting CoPilot consumes more disk space on your CoPilot
volume.  The change from 512K to a megaword of memory costs 4000 pages on
CoPilot, and also 4000 pages on CoCoPilot if you have one.

Users of personal Dorados will be warned when their machines are about to be
upgraded; you may want to consider reconfiguring your Pilot logical volume
structure (e.g., to eliminate CoCoPilot) at that time.

*start*
00884 00024 US 
Date: 4 Oct. 1981 11:50 am PDT (Sunday)
From: Taft.PA
Subject: SetClock
To: DoradoUsers^
Reply-To: Taft

I've released a program that exercises the Dorado's ability to set its own system
clock rate.  If the hardware is flakey, and it can't be repaired for a while, it's
sometimes a useful expedient to slow it down to make it run reliably.

Obtain [Ivy]<Dorado>SetClock.bcd, which is an Alto/Mesa program, and type

	> SetClock nn

where nn is the desired new clock interval in nanoseconds.  The normal rate is
32; slowing it to 35 will usually do the trick (if anything will).  Of course, you
can also attempt to run the machine faster, though all bets are off if you do
(most Dorados won't run faster than 30).

Note that a 3-push boot will reset the clock to 32 if it is previously running
faster than that, but will leave the clock alone if it is slower.

*start*
01087 00024 US 
Date: 16 Oct. 1981 5:58 pm PDT (Friday)
From: Taft.PA
Subject: New AEmu & Mesa
To: Willie-Sue, Deutsch, Masinter
cc: Maxwell, Taft

I've released new Dorado Alto emulator and Alto/Mesa microcode with two bugs
fixed:

1. The AEmu Reschedule trap microcode didn't reset RBase, so if any opcode
(say, one of the extensions for Smalltalk) specified a different RBase for the IFU
dispatch, bad things would happen.  (This was discovered by Peter.)

2. Page fault handling in the Alto/Mesa emulator sometimes stored an incorrect
PC, making it hard to figure out what code caused the fault.  (Discovered by
John.)

I got sick of struggling to get the Alto/Mesa microcode to place whenever I made
tiny changes.  (It's slightly over 7700B microinstructions, which is where
MicroD's warranty runs out.)  So I ripped out the Alto Cedar support microcode,
since the Alto Cedar system (Russ assures me) is thoroughly defunct.  (Just in
case I was wrong about this, I saved the old microcode as
[Indigo]<Dorado>AltoCedar.mb and [Indigo]<DoradoSource>AltoCedarSources.dm.)
	Ed

*start*
01069 00024 US 
Date: 20 Nov. 1981 11:32 am PST (Friday)
From: Taft.PA
Subject: Dorado booting
To: DoradoUsers^
Reply-To: Taft

I've been asked to remind everyone what to do if your Dorado won't boot.

Booting is controlled by a microcomputer on the Dorado's baseboard.  The
microcomputer senses the boot button; so if the microcomputer is not running
properly, the Dorado won't boot, and there is nothing you can do from the
terminal to correct this.

To get the microcomputer back to life, you must go to the Dorado itself and press
its reset button, which is the white button on the Dorado's front panel.  Then
you must go back to the terminal and try booting again.  If this doesn't work
then the Dorado is really broken -- call a repairman.

We hope the problem with the microcomputer going dead will be eliminated by
installation of a "watchdog timer" that notices that the microcomputer is
unhealthy and, effectively, presses its reset button automatically.  The watchdog
timer mod is being installed on all Dorados, but progress on this has been slow.

*start*
00687 00024 US 
From: Halbert.pa
Date:  4-Dec-81 19:39:55 PST
Subject: Netexec loadMicrocode
To: Willie-Sue

It would be a little more convenient if the loadMicrocode netexec command
did not try to boot the appropriate partition after loading the microcode.
I usually use the command because the partition I want is not available,
so trying to boot that partition is useless (in particular, I am talking
about missing Smalltalk/Lisp parititions). If the netexec stayed present,
or rebooted itself, then I could switch to a different partition
and reboot.

This is pretty low priority. Consider it a suggestion.
If you're not the right person, can you forward this? Thanks.
--Dan
*start*
00721 00024 US 
Date: 8 Dec. 1981 11:42 am PST (Tuesday)
From: Taft.PA
Subject: Re: Netexec loadMicrocode
In-reply-to: Halbert's message of 4-Dec-81 19:39:55 PST
To: Halbert
cc: Willie-Sue, Taft

The action of booting the partition after loading the microcode is a function of
the microcode, not of the NetExec.  That is, when the microcode is started at its
standard entry point, it does a complete machine reset and boots the partition.

The microcode has an alternate entry point that performs the "soft" (non-booting)
startup; the address of this entry point is wired into the LoadMB program, but
the NetExec doesn't know about it.  I suppose this could be added to the NetExec;
I'll ask Boggs about it.
	Ed

*start*
02591 00024 US 
Date: 6 Jan. 1982 11:45 am PST (Wednesday)
From: Ornstein.PA
Subject: Re: Dorado power-off trashes disk
To: McCreight, Thacker, Diebert, Taft
cc: Ornstein

Ed Taft tells me that Tim has, in fact, done some work on this problem and it
sounds like the trouble is pretty well identified. The dificulty seems to be that
the same +5 volt line from the Dorado is used in the disk drives for two quite
different purposes:

	1. to tell the drive whether it should turn on or off, and

	2. to provide the terminators for the logic lines from the Dorado
	with their pullup voltage [we assume this was done that way, rather
	than using the drive's own +5, in order to be able to shut off
	the end (terminated) drive in a chain of drives without screwing up
	the termination of the lines for the other drives]

The trouble with this arrangement is that if the Dorado's +5 shuts down
unexpectedly, the logic lines (which tell the drive such things as whether to
write or not) sag as the drive is being told to shut off - with the obvious threat
to the disk. We clearly should fix this - not just in the lab machines but all of
them.

One way would be to carry two separate lines along the daisy chain to the
drives. One of the lines would be the (present) Dorado's +5 for drive turn on/off
purpose. The other would be a separate +5 line for terminator powering. It would
be made up by ORing all the drives' +5 supplies appropriately isolated with
diodes. (The drives presumably carefully keep their own lives clean as their
power supplies die). That solution sounds nasty, requiring another line to be
added to the daisy chain.

Taft suggests what seems to me like a better solution wherein each drive derives
its terminator-power by ORing together the present Dorado +5 line with its own
internal +5. That way when the Dorado drops its +5 accidentally, the drive
would use its own +5 to hold up the logic signals as the drive put itself
carefully to sleep.

If everyone agrees that this latter is the right solution, then I suggest that Ed
McCreight should supervise Herb/Charlie trying it out and when Ed is satisfied,
we should issue a change notice to the Garage and Jeffers, and arrange for Herb
and Charlie to make the appropriate fix to all CSL and SDD drives.

There may be troubles with this solution I don't see (for instance, is it OK for us
to screw with the drives to this extent without jeopardizing warranty, etc. etc.).
If life ain't so simple, then at least the two Ed's, Tim, and I should probably get
together to discuss what to do. 

Comments?

Severo        
*start*
01594 00024 US 
Date: 7 Jan. 1982 1:11 pm PST (Thursday)
From: Taft.PA
Subject: Disk microcode/hardware change
To: DoradoCore^
cc: Deutsch, Masinter, Maxwell, Taft
Reply-To: Taft

I will shortly be making a change to the Dorado disk microcode (both Alto and
Pilot versions) to deselect the disk drive when no activity is in progress.  This
should reduce the probability that the disk gets trashed when the Dorado loses
power (power outage or power supply failure).  It will also eliminate the problem
that causes the Read-Only switch to be ineffective (the drive senses the state of
the switch only while it is deselected).

This microcode will depend on a hardware change -- a new PROM on the
DskEth board.  It's impractical to change the PROMs on all machines
simultaneously.  However, fortunately it's possible for the microcode to determine
whether an old or new PROM is installed and to operate accordingly.

During the next few days, I will be checking out the change on a machine in
the Dorado lab.  Once this is done, I will release new Alto, Mesa, Pilot, and
Cedar microcode that operates with both old and new PROMs.  At that time, it
will be necessary for maintainers of other microcode (Smalltalk, Lisp, and special
systems such as Music) to immediately release new versions containing the
updated disk microcode.

After that, installation of new PROMs in all machines can proceed.  Once the
PROM retrofit is completed, I will change the disk microcode again to eliminate
compatibility with old PROMs, as the compatibility microcode will be moderately
costly in space.
	Ed

*start*
00823 00024 US 
Date: 21 Jan. 1982 1:53 pm PST (Thursday)
From: Taft.PA
Subject: Dorado microcode release
To: Deutsch, Masinter, Maxwell, Willie-Sue
cc: DoradoCore^, Taft

I've made the microcode change described in my message of January 7, and I've
released new versions of the Alto, Mesa, Pilot, and Cedar microcode.  Other
emulators now need to be reloaded with the latest AEmu microcode, from
[Indigo]<Dorado>AEmuDibs.dm.  The emulators I'm aware of are Lisp,
Smalltalk-76, Smalltalk-80, and Music.

The new microcode runs on machines with or without the disk controller
hardware change.  Modification of disk controllers cannot begin until all
emulators have been converted to the new disk microcode.  Please notify me
when the emulators you are responsible for have been converted and released. 
Thanks.
	Ed

*start*
00695 00024 US 
Date: 22 Jan. 1982 9:07 am PST (Friday)
From: Taft.PA
Subject: New DL DoradoMicroprogrammers^.pa
To: DoradoMicroprogrammers^.pa
cc: DoradoUsers^.pa, Taft
Reply-To: Taft

A new distribution list DoradoMicroprogrammers^.pa exists to collect together all
people who write Dorado microcode.  Future notifications of things such as new
releases of D1Lang, AEmu microcode, newly-discovered programming
restrictions, etc., will be sent to this list and nowhere else.

The initial members are: Deutsch.pa, Kaehler.pa, Krasner.pa, Masinter.pa,
McDaniel.pa, Pier.pa, Taft.pa, Willie-Sue.pa.  If you would like to be added, send
a message to Owners-DoradoMicroprogrammers^.pa.
	Ed

*start*
01641 00024 US 
Date: 28 Jan. 1982 11:48 am PST (Thursday)
From: ornstein.PA
Subject: Dorado Disk Troubles
To: CSL^, ISL^
Reply-To: ornstein

The Pilot disk world is far from perfect and Herb and Charlie have no useful
tools for dealing with disk troubles that occur within Pilot. The only thing they
can do is to certify that the DRIVE itself works properly (by running Diax with
a test pack) but within Pilot they have no way of addressing problems that occur
with your particular PACK.

Pack troubles differ from other hardware problems in that packs are expected to
have occasional bad spots. Various software and hardware mechanisms are
supposed to avoid or cope with such spots. The trouble is that the present
pack-initialization blemish-detection-and-avoidance mechanisms are inadequate
and furthermore the drives' built in error-detection/correction mechanism is not
presently used. All of this will presumably improve over coming months as SDD
reissues Pilot, but in the meantime if you have troubles that relate to your
individual pack, you can't expect much help from our maintenance guys. They
don't even have a way to read a problematical file repeatedly. So about all you
can do is back up, try again, and hope that either the error won't recur or you'll
perturb things so as to move away from the trouble spot.

Ed Taft argues that it doesn't make sense for us to try to provide test facilities in
the Pilot world because we can expect that once proper blemish avoidance and
error correction mechanisms are in place along with improved scavanging, the
Pilot disk troubles can be expected to go way down.    

Severo

*start*
00775 00024 US 
Date: 5 Feb. 1982 12:35 pm PST (Friday)
From: Taft.PA
Subject: Time to install the new disk PROMs
To: Sosinski, Yeary
cc: DoradoCore^
Reply-To: Taft

All the emulators have now been converted over to the new disk microcode.  So
it's time to go ahead and begin installing new PROMs on all DskEth boards.

The PROM name is DiskUnits, its type is 74S288, and its location is h05.  The
"Sosinski DoradoProms" disk has the new DoradoProms program, which has also
been backed up on [Indigo]<DoradoLogic>.

Be sure to update the emulator .mb files on all Midas disks as you come across
them, since the old microcode will not work on machines with the new PROMs. 
The best way to do this is to retrieve [Indigo]<Dorado>UpdateEmulators.cm and
execute it.
	Ed

*start*
00647 00024 US 
Date: 10 Feb. 1982 4:53 pm PST (Wednesday)
From: Taft.PA
Subject: Memory zeroing opcodes
To: Willie-Sue
cc: Rovner, Taft

I've implemented and briefly tested the new opcodes.  Please obtain new versions
of the following, from [Ivy]<Taft>

	DMesaDefs.mc
	DMesaMiscDisp.mc
	DMesaMiscOps.mc

Unfortunately, there was a bug in the MISC dispatching macros in DMesaDefs
(affecting opcodes in the range 100-177, of which we didn't have any before); so
you will have to reassemble everything.

The new opcodes are included in Alto Mesa (why not?) as well as Pilot Mesa, so
please release new versions of both when you finish.
	Ed

*start*
01285 00024 US 
Date: 18 Feb. 1982 5:46 pm PST (Thursday)
From: Taft.PA
Subject: Dorado Cedar/Pilot microcode
To: DoradoUsers^
Reply-To: Taft

There has been a small change in the assignment of keys to microcode files.  A
3-push boot with the "C" key depressed loads the released version (currently 2.3)
of the Cedar microcode, as before.  However, a 3-push boot with "T" depressed
loads CedarTest.eb, which is a pre-release version associated with the
forthcoming Cedar 2.4 release.

Formerly, "T" was advertised to select vanilla (non-Cedar) Pilot microcode.  In
fact, the Cedar microcode is upward-compatible from vanilla Pilot, and it's
usually been the case that "C" and "T" select the same microcode.  This state of
affairs is now being formalized.

So the new procedure is: use "C" to boot Pilot, whether you are using Cedar or
vanilla Pilot.  Use "T" only if you are testing pre-release Cedar software.

The microcode boot file names known to the MesaNetExec and such are:

"C" = DoradoPilot.eb -- released Cedar/Pilot microcode.  (DoradoPilot.eb is the
default microcode loaded by the MesaNetExec; hence the choice of name.)

"T" = DoradoTest.eb -- pre-release Cedar/Pilot microcode.  (Specify this to
SetVersions if you are testing pre-release Cedar software.)

	Ed

*start*
00802 00024 US 
Date: 18 Feb. 1982 5:55 pm PST (Thursday)
From: Taft.PA
Subject: Microcode organization change
To: Willie-Sue
cc: Taft

There is now only one Pilot microcode file instead of two; it's called Cedar.mb,
and it's assembled by CedarMesaMake.cm and loaded by CedarMesa.cm. 
DMesaRelease releases both Alto and Cedar versions, and CedarOnlyRelease.cm
releases only the Cedar version, as before.

Note that Cedar.mb is converted into DoradoPilot.eb (not DoradoCedar.eb); this is
because DoradoPilot.eb is the default name compiled into the MesaNetExec.

There is a new command file, CedarTestRelease.cm, which takes the current
Cedar microcode and releases it to Test sub-directories on [Indigo]<Dorado> and
<DoradoSource>.  Also it makes DoradoTest.eb and stores it on Twinkle.

	Ed

*start*
00674 00024 US 
Date: 23 Feb. 1982 11:26 am PST (Tuesday)
From: Taft.PA
Subject: Re: Dorado microcode
In-reply-to: Your message of 23-Feb-82 10:49:06 PST (Tuesday)
To: DaveSmith
cc: Taft

Obtain the following files onto an Alto volume on your Dorado:

	[Ivy]<Taft>60hz>Cedar60hz.mb
	[Indigo]<Dorado>LoadMB.run

To start up this microcode and boot your Pilot world, type:

	> LoadMB Cedar60hz.mb

The field rate can straightforwardly be adjusted in units of about 0.1 hz.  Finer
adjustment than this is also possible but is much more difficult, because it
requires varying the horizontal line rate and a bunch of other parameters that
interact with each other.

	Ed

*start*
01474 00024 US 
Date: 26 Feb. 1982 3:09 pm PST (Friday)
From: Taft.PA
Subject: Booting Alto partitions
To: DoradoUsers^
Reply-To: Taft

In the past, each of the Alto-related emulators (Alto/Mesa, Lisp, and Smalltalk)
has selected its own "default" Dorado disk partition when initially booted.  This
was done as a convenience; there is not really any connection between emulators
and disk partitions, and any emulator can be run on any Alto partition.

This arrangement has resulted in confusing problems on some Dorados, where
not all the Alto partitions are present because of encroachment by Pilot. 
Therefore, a new and more uniform arrangement is being instituted.

All Alto-related emulators will initially select partition 4.  However, by holding
down a digit key in the range 1 to 5 while booting, you may select any desired
partition.  For example, to boot the Smalltalk microcode and select partition 3,
hold down "S" and "3" while triple-booting.

As before, a single-push boot with no keys depressed will not change partitions,
but a 3-push boot with no keys depressed will revert to partition 4.

This new convention is now present in the Alto/Mesa microcode, and will be
installed in the Lisp and Smalltalk microcode soon.

(Fine print for old-time Alto hackers: as a side-effect of this change, I have
abolished the "boot keys" feature that permits selecting a boot file from an
arbitrary disk address by holding down the proper combination of keys.)

*start*
00534 00024 US 
Date: 26 Feb. 1982 3:12 pm PST (Friday)
From: Taft.PA
Subject: New AEmu microcode
To: DoradoMicroprogrammers^
Reply-To: Taft

I've released a new version of the Alto Emulator microcode that supports the new
booting conventions, described in an accompanying message.  Please reload your
Alto-based emulators with the latest version of the .dib files from
[Indigo]<DoradoSource>AEmuDibs.dm.  Note that you may delete the
InitDefaultDisk subroutine from your version of ATraps.mc, as it is no longer
called.
	Ed

*start*
01060 00024 US 
Date: 10 March 1982 12:22 pm PST (Wednesday)
From: Taft.PA
Subject: Dorado microcode release
To: DoradoUsers^, CedarUsers^
Reply-To: Taft

Now that Cedar 2.3 and earlier versions have been retired, I have also removed
the microcode that accompanied them.  The microcode loaded by a 3-push boot
with "C" depressed (DoradoPilot.eb) now runs with Cedar 2.4 and newer
versions.  (I believe there are no microcode changes accompanying the
forthcoming Cedar 2.5 release.)

There is also one new feature, present in both Alto/Mesa and Cedar microcode:
an opcode for changing the display field rate.  This may be used to change the
field rate of an LF (wide-screen) display from its normal 77 hz to 60 hz, which
is helpful when you are making video tapes.

The Mesa interface to this opcode is [Indigo]<Dorado>DisplayExtras.mesa and
.bcd.  There is also an Alto Emulator opcode, 61046B, which accepts the new
field rate in AC0 and returns the old one in AC0.  On an LF display, a value of
11B selects the normal 77 hz, and 213B selects 60 hz.

*start*
01065 00024 US 
Date: 11 March 1982 11:39 am PST (Thursday)
From: Taft.PA
Subject: Mesa map operations
To: McDaniel, Wilhelm
cc: Taft

I came up with a better way to deal with this problem.  I've changed the
map-reading operations so that they return "Vacant" for any map entry whose
real page number is greater than 7777B.  This will stop the Mesa system's initial
memory scan at 1 megaword so that it will not disturb the map beyond that
point.

I've released this as the standard Alto/Mesa microcode, so I invite you to give it
a try.

By the way, do you know about the opcode that returns the amount of real
memory present?  Its definition is:

  GetMemConfig: PROCEDURE RETURNS [realPages, virtualBanks: CARDINAL] =
    MACHINE CODE { Mopcodes.zMISC, 251B };

realPages is the actual number of pages of real memory present.  In Alto/Mesa
the real memory can be assumed to be mapped contiguously at the bottom of the
virtual memory.  (This opcode is defined only on the Dorado, so you must first
determine what type of machine you are running on.)
	Ed

*start*
00845 00024 US 
Date: 29 March 1982 6:48 pm PST (Monday)
From: Pier.PA
Subject: Dorado Color
To: Ornstein, Taft, Sosinski, Yeary
cc:  Pier

Here is a summary, as of tonite, of the color status AFTER the color display
microcode is modified:

1. Any color Dorado can run up to 8 bits/pixel on a 525 line display. This covers
Chipmonk, Griffin, Color Lisp, and most other applications. Multiwire boards get
a muffler jumper added to identify themselves.

2. Color Dorados with stitchweld or PC boards can run 24 bits/point color on a
525 line display.  The only application for this is imaging work in ISL at the
present time.

3. An experiment is in progress to modify the Y board to drive a thousand line
display.  IF successful, stitchweld boards may be used to drive a 1000 square
monitor up to 8 bits/point.  This is research.

Ken  

*start*
00979 00024 US 
Date: 30 March 1982 10:27 am PST (Tuesday)
From: ornstein.PA
Subject: DispY Board - Microcode Fix
To: Pier, Taft
cc: ornstein

I talked to Butler and he says sure, do it. Would you please send an explanatory
message to me, the techs and the Garage (Frank Vest) and other concerned folks,
documenting what you're doing; in particular what sorts of uses require what
sorts of Y boards - as I understand it, it's:

	1. A fully modified Y board - e.g. stitchweld rev ? or (I hope - Ken please
	verify this) a PC one - for full (24 bits per point) color

	2. A slightly modified one (e.g. a rev ? MW DispY) - (to say to the
	muffler - I'm a "baddie", it's OK to use me for black/white or regular 8
	bits per point color but not for 24 bits per point color)

I assume it's the case that until all the bad MW boards have the fix that reports
their "badness" to the muffler, they run the (tiny) risk of being mistakenly used
for full color application. 

Severo 
*start*
01203 00024 US 
Date: 30 March 1982 3:18 pm PST (Tuesday)
From: ornstein.PA
Subject: Dorado Documentation Problem
To: Thacker
cc: ornstein, McCreight, Taft

Herb just came in with the following instance of the sort of thing that scares me:
an inconsistency between the formal documentation and how it should be.

In a message dated 2 Nov, 1980, Ed Taft described an important fix to the DskEth
board. This change is not reflected in what we believe are the latest drawings
(rev Cf of DskEth). (I think McCreight is presently trying to figure out whether
the PC's are correct or not - probably not). 

Taft's msg. went to Herb and Charlie with copy to DoradoCore^.  I believe Tim
had responsibility for the drawings at that point (certainly was on Dorado core^),
although I don't remember whether he had moved to the Garage by then - I
don't think so.

S.

Can we make a date to talk to Gill tomorrow sometime - so I can try to
understand better just what you think the job consists of. A recent Stanford
graduate doesn't fit what I think is needed; maybe San Jose State. But far better,
someone with a few years experience under his belt. Might Ron Ryder have
somebody itching to move north?  

*start*
01708 00024 US 
Date: 30 March 1982 4:02 pm PST (Tuesday)
From: Taft.PA
Subject: Re: Dorado Documentation Problem
In-reply-to: ornstein's message of 30 March 1982 3:18 pm PST (Tuesday)
To: ornstein
cc: Thacker, McCreight, Taft

FYI: Tim's memo on current rev levels, which I was telling you about, is
[Indigo]<DoradoLogic>RevStatus.memo.  It was most recently updated last July, so
it is recent enough to have included the DskEth changes, but it doesn't.

The other design changes I can remember that we've introduced in the past year
and which are probably not documented are:

1. Addition of a wire on DispY to accomodate a backpanel jumper to select the
type of monitor (Alto or LF).

2. A change in what legs are cut on a configuration SIP on DispY that controls
DWT wakeup latency.

3. Ken's DispY change to make color work without causing spurious B channel
wakeups.

Also, I originated some other changes on the ProcL and IFU boards (two changes
each, if I recall correctly) during 1980 or perhaps late 1979; these were to fix
some bugs relating to instruction dispatching that made Mesa run unreliably.  As
far as I can tell, these changes DID make it into the documentation, and even
into recent builds of multiwire boards.

Finally, there have been occasional changes to the contents of PROMs (there are
two on the DskEth board that have changed in the past year).  The current truth
about the PROMs is always embodied in [Indigo]<DoradoLogic>DoradoProms.run. 
If the garage people always retrieve a fresh copy of this and use it to blow
PROMs under program control, then everything is fine; but if (as I suspect) they
make PROMs by copying existing ones, then things are not so good.
	Ed

*start*
01581 00024 US 
Date: 31 March 1982 11:55 am PST (Wednesday)
From: Pier.PA
Subject: Re: DispY Board - Microcode Fix
In-reply-to: ornstein's message of 30 March 1982 10:27 am PST (Tuesday)
To: ornstein
cc: Pier, Taft, Sosinski, Vest, Wyatt

To summarize the color board situation:

We have three kinds of DispY boards, say SW, MW and PC. The "current" rev
level is Ck.  SW boards can be upgraded to Ck.  PC boards are at level Cj. MW
boards are at level Cg. A board must be at rev level greater than Ci to run both
A and B channels at the same time. So:
	1. Boards at level Cg will be tagged with a muffler input (muffler address
3107 on the DispY board) declaring them to be a rev less than Cj.  Microcode and
Pilot color display drivers will not allow both channels to be active
simultaneously if this bit is set.  This still allows Chipmonk, Griffin, Color Lisp,
the plotting associated with Thyme, etc. to run.
	2. The consequences of attempting to run channels simultaneously on a
low rev level board are annoying but not dangerous.  In fact, it might even
appear to work serendipitously; hard to say right now.
	3. Color Dorados requiring "full color" capability will need DispY rev Cj or
greater installed. Lexington and Saratoga are the current machines using full
color.

I truely hope this is clear.  Regarding the Ck revision for stitchweld boards: I am
experimenting with the board at this level to see if it is feasible to run 1000 line
color.  This should not impact any of the above; it is impractical to upgrade
either PC or MW boards to higher rev levels.

*start*
00529 00024 US 
Date: 1 April 1982 12:52 pm PST (Thursday)
From: Taft.PA
Subject: Dorado microcode release
To: Maxwell, Pier, Wyatt
cc: Willie-Sue, Taft

I've released new Alto and Cedar microcode with the following changes:

(1) I fixed a bug in Xfer traps (found by inspection; I don't know whether or not
Xfer traps will now work).

(2) The color display microcode now ignores spurious word task wakeups for
inactive channels.  This should make it possible to use the "bad" DispY boards
for single-channel color.
	Ed

*start*
00754 00024 US 
Date: 20 May 1982 1:20 pm PDT (Thursday)
From: Taft.PA
Subject: Dorado microcode release
To: DoradoUsers^, CedarUsers^
Reply-To: Taft

New versions of the Dorado microcode for Alto/Mesa and Cedar have been
released.  The only functional change is addition of a VERSION opcode,
presently documented in [Ivy]<Taft>MicrocodeVersion.mesa.  (A forthcoming
release of Dolphin microcode also implements this opcode.)  Additionally, XFER
Traps now conform to the PrincOps in that they deliver a trap parameter of zero
during LFCs.

A modest re-interpretation of the PrincOps has made possible a 10% speedup of
the most common cases of XFER (EFC, RET) in the Cedar microcode.  This
should result in an overall improvement of 3 to 4%.
	Ed

*start*
01014 00024 US 
Date: 20 May 1982 1:30 pm PDT (Thursday)
From: Taft.PA
Subject: Disk init glitch fixed (maybe)
To: Petit
cc: D'Alfonso, Vest, Yeary, Sosinski, Clark, McCreight, Taft

I have changed the disk initialization in the version of Dorado microcode I have
just released.  Assuming we diagnosed the problem correctly, it should now be
possible to power-up your Dorado normally, i.e., the disk wait defeating jumper
removed.  Please give it a try and let me know.

(The new microcode will also clear Device Check if it occurs during a boot.)

As it turned out, this change didn't require changing the microcode in the
BaseBoard EProms after all.  But I didn't realize that until I had rebuilt the
EProm microcode and incorporated several other pending changes as well.  Since
those changes (and some changes in Ed McCreight's microcomputer code) are
desirable, I would still like to have all the BaseBoard EProms changed.  The new
code is not quite ready yet; I'll let everyone know when it is.
	Ed

*start*
00505 00024 US 
Date: 8 June 1982 11:40 am PDT (Tuesday)
From: Taft.PA
Subject: Disk PROM warning
To: DoradoCore^
Reply-To: Taft

It's my understanding that the new DiskUnits PROM (h05 on the DskEth board,
blown on or after 5 Feb. 1982) has been installed in all Dorados.  In the next
microcode release, I intend to abolish support for the old PROMs.  If anyone
suspects that old PROMs still exist anywhere (e.g., in SDD machines or spare
boards or whatever), please take appropriate action.
	Ed

*start*
04640 00024 US 
Date: 11 June 1982 11:36 am PDT (Friday)
From: Taft.PA
Subject: Proposed Dorado disk format change
To: DoradoCore^, DoradoMicroprogrammers^, CedarImplementors^
Reply-To: Taft

I am proposing to make a major incompatible change in the format of Dorado
Trident disks.  I don't expect to start work on this in the immediate future; but I
thought it might be a good idea to bring it out in the open for comment or
discussion.

My proposal is to adopt the format used on Dandelions that have Trident disks. 
There are several reasons for this:

1. We gain the ability to move disk packs (containing Pilot file systems) between
Dorados and Dandelions.  If CSL makes a heavy investment in Dandelions next
year, as is currently being considered, then it's likely that we will build
Dandelion-based Alpine servers; and it will be advantageous to be able to
interchange packs between Dandelion and Dorado servers.

2. The Dandelion's format is superior to the Dorado's in two ways.  First, the
Dandelion achieves 30 sectors per track.  The Dorado gets 29 1/3.  The leftover
1/3 sector is of course useless, and in fact the 29th sector is also quite difficult to
access; consequently we are currently using only 28 sectors per track.  Adopting
the Dandelion's format therefore results in a 7% increase in effective capacity. 
Second, the Dandelion uses a conventional addressing hierarchy (sectors, heads,
cylinders), whereas the Dorado uses an oddball one (sectors, cylinders, heads)
for compatibility with the format used for Alto emulation (more on Alto
emulation later).  Adopting the Dandelion format results in an increase of
roughly 25% in effective transfer rate for sequential transfers, since fewer seeks
are required.

Changing the Dorado's format requires that the following be done:

1. Modify the Alto Emulator and Pilot disk microcode.  The changes aren't very
extensive; but the tighter packing of sectors means that the microcode has less
time between sectors to clean up at the end of one and get ready for the next
one; this may require some reorganization.

2. Make a one-wire hardware modification to each DskEth board (this changes
the value of the sync byte that the controller recognizes during reads).

3. Change the sector size jumpers in each disk drive to generate 30 sectors per
revolution (or some multiple; I haven't completely thought this through yet).

4. Change the Pilot Disk Head software to conform to the new addressing
hierarchy.

The effects on Alto emulation are as follows:

1. No change will visible to standard Alto software that treats each partition of
the disk as a "double model 44".  There will still be 5 partitions (some of which
may be preempted by Pilot); though they are laid out differently on the disk,
the difference is invisible to Alto software.  I do NOT propose to make available
the additional disk capacity in Alto emulation mode (e.g., adding a 15th sector to
our "14-sector double model 44").

2. Emulating the Alto Trident subsystem on the Dorado will require changing the
sector size jumpers in the drive, whereas currently the sector size can be
changed directly from microcode (using the subsector count mechanism).  It was
providing this capability that resulted in our current oddball 29 1/3 sector
format.  I don't see this change causing any problems.  First of all, nobody has
used the Alto Trident emulation for at least a year.  Second, even when they
did, it was always on a separate disk drive rather than the Dorado's regular
system drive, so setting the sector jumpers differently for that drive was not an
inconvenience.  And finally, the most important anticipated application of this
capability, running Juniper on Dorados, is no longer under consideration.

Conversion to the new format requires careful planning, since it involves both
hardware and microcode modifications.  That is, during the transition, modified
Dorados will have to run new microcode while unmodified ones continue to run
the old.  Additionally, there will have to be two versions of all Pilot-based
software (i.e., boot files for Cedar, Othello, CoPilot, etc.)

Converting disk packs will require different handling for Alto and Pilot
volumes.  Alto volumes may be copied from an unmodified Dorado to a modified
one using CopyDisk over the Ethernet.  Since there is no Pilot CopyDisk, Pilot
volumes will have to be rebuilt from scratch; but this should be straightforward
since most people are already following the Cedar release and DFFiles procedures
to keep themselves completely backed up.

If there's anything I've missed, I'd appreciate being told about it.
	Ed

*start*
11113 00024 US 
Date: 21 June 1982 10:46 am PDT (Monday)
From: Taft.PA
Subject: Dorado booting
To: DoradoCore^, DoradoMicroprogrammers^, CedarImplementors^
Reply-To: Taft

I've completed implementation of a Dorado disk boot loader for microcode, so a
Dorado can now boot-load microcode from either disk or Ethernet, much as the
Dolphin has been able to do all along.

This opens up a lot of new possibilities.  People can now install the microcode
they desire to have booted by default, rather than the default always being the
Alto/Mesa emulator.  Conversion to incompatible instruction sets (e.g., Trinity
Pilot) is made easier, without people having to remember the right key to press
for any given Dorado.  And of course there is the ability for a Dorado to boot
itself without benefit of an Ethernet or a boot server, though there is a down
side to this which I will get to shortly.

There are many different possible ways of configuring the microcode on a
Dorado's disk.  Rather than trying to decide which are the most useful, I've just
gone ahead and implemented all of them, in the hope that people will experiment
and determine which is the best for them.  So please read carefully and send me
any suggestions or comments you care to make.


1. Microcode booting organization and mechanisms

There are two places on the disk where you may install microcode.  One is called
the "Initial" region, which is a special region of the disk reserved for microcode. 
(This region is already reserved on present-day Dorado disks; no changes to disk
format are required.)  The other is called the "Pilot microcode" or "soft microcode"
file, which is a more-or-less ordinary Pilot file which may reside in any Pilot
volume.  (There can actually be one of these in each Pilot volume; but the
booting logic pays attention only to the one that has been declared to be the
"physical volume Pilot microcode".)

The booting algorithm is as follows.  When you cold-boot the Dorado (power-on
or 3-push boot), if you are holding down one of "M", "L", "S", "C", or "T", then
microcode is booted from the Ethernet; the microcode is selected by the key ("M"
= Alto/Mesa, "L" = Lisp, etc.)  If you are not holding down any of these keys,
and Dorado microcode is present in the Initial region of the disk, and the disk is
on-line, then that Initial microcode is loaded and executed; what happens after
that depends on what Initial microcode is installed.  If the attempt to boot
microcode from the disk fails, the Alto/Mesa emulator is booted from the
Ethernet.

Now, the most straightforward thing to do is simply to install on the Initial
region of the disk the emulator which you usually want to run (DoradoMesa.eb,
DoradoCedar.eb, DoradoLisp.eb, DoradoSmalltalk.eb).  However, this gives up
considerable flexibility.

There exists a special microprogram specifically intended to be installed on the
Initial region of the disk.  It comes in several variations:

DoradoInitialDisk.eb:  loads and starts the installed Pilot microcode (as described
above).

DoradoInitialMesa.eb:  if the "P" key is pressed down, loads and starts the
installed Pilot microcode; otherwise loads and starts the Alto/Mesa emulator.  That
is, DoradoInitialMesa.eb consists essentially of DoradoInitialDisk.eb and
DoradoMesa.eb pasted together into a single file which is installed on the Initial
region of the disk.

DoradoInitialSmalltalk.eb, DoradoInitialLisp.eb, DoradoInitialCedar.eb:  the same as
DoradoInitialMesa.eb except for the emulator that is loaded if "P" is not pressed
down.  These four pieces of Initial microcode permit you to choose dynamically
between a single Alto-based emulator and a single Pilot or Cedar-based emulator,
both of which are installed on the disk.

DoradoInitialEtherMesa.eb:  if the "P" key is pressed down, loads and starts the
installed Pilot microcode; otherwise boots the Alto/Mesa emulator from the
Ethernet.

DoradoInitialEtherSmalltalk.eb, DoradoInitialEtherLisp.eb,
DoradoInitialEtherCedar.eb:  the same as DoradoInitialEtherMesa.eb except for the
emulator that is loaded if "P" is not pressed down.  These four pieces of Initial
microcode permit you to select a specific emulator to be booted by default, while
continuing to get it from the Ethernet where it is most likely to be up-to-date.

Now, from my point of view as microcode maintainer, there is much to be said
for having standard emulators always be booted from the Ethernet.  It means that
I can fix bugs and make upward-compatible improvements, and all users will
obtained the improved version next time they boot, without their having to take
any explicit action to install new microcode on their disk.  So I would prefer that
people who are using standard released versions of software arrange always to
boot their microcode from the Ethernet, by installing one of the last four
microcode files on the Initial region of their disks.  On the other hand, people
who are developing new versions of software that require incompatible microcode
should install the required microcode on their disks.


2. Microcode installation

The Othello program is used to install both Initial and Pilot microcode on your
disk (just the same as on Dolphins).  I have reinstated the "Initial microcode
fetch" and "Pilot microcode fetch" commands in a new version of
OthelloDorado.boot, which will be released as part of Cedar 3.2.

Note that Othello is used to install Initial microcode even if you don't have a
Pilot or Cedar file system on your disk.

I've modified the "Describe physical volumes" command to display the name and
creation date of any Initial or Pilot microcode that it discovers on the disk.  (This
will also work on Dolphins as soon as I can arrange to have the required
information added to the Dolphin microcode files.)


3. Microcode construction

A new version of the program that creates Dorado microcode (.eb) files is released
as [Indigo]<Dorado>LoadMB.run.  It is upward-compatible from the previous
version.  It puts into the output .eb file the identification information required
by Othello's "Describe physical volumes" command.

Additionally, it can construct a .eb file that consists of several microprograms
pasted together.  This is how composite microcode boot files such as
DoradoInitialMesa.eb are built.  The command line for DoradoInitialMesa.eb is:

  > LoadMB/e DoradoInitialMesa.eb/o InitialSelect.mb 406/s Mesa.mb 1076/s

where 406 is the starting address for InitialSelect.mb and 1076 is the starting
address for Mesa.mb.

When DoradoInitialMesa.eb is boot-loaded, both of the constituent microprograms
are read into main memory, but only the first one is loaded into the Dorado's
control store and started (at its starting address).  When it is started, it is passed a
pointer to the second microprogram, which still resides in main memory.  If it
wants to, it can load that microcode by passing the pointer to LoadRam.


4. Semantics of TemporaryBooting.BootButton

Calling TemporaryBooting.BootButton[] has the same effect as a 3-push boot. 
Until now, a 3-push boot (with no keys held down) has always booted the
Alto/Mesa microcode; so clients (e.g., the Cedar boot menu) have come to think
of BootButton as "booting the Alto volume".

Now things are no longer so simple.  If Initial microcode is installed on the disk,
calling BootButton will load that microcode; and the result will depend on what
microcode that is.

Under the principle that a program should be able to invoke any facility that the
human user can, I've provided a means whereby a program can specify what
BootButton is to do.  That is, it can specify either that the installed disk
microcode is to be booted or that a specific microprogram be booted from the
Ethernet.  (It can select ANY Ether-bootable microcode, not just the ones
corresponding to the "M", "L", "S", "C", and "T" keys.)

I haven't worked out precisely what the interface to this will look like. 
TemporaryBooting.BootButton is actually specified to take a "switches" argument;
but this is not presently implemented on any machine (I'm not exactly sure what
it would do anyway).  Probably the easiest thing to do is to create a new
SpecialTemporaryBooting interface that exports a BootButton[BootFileNumber]
procedure, and also exports some variables with the boot file numbers for specific
standard emulators (Alto/Mesa, Smalltalk, etc.)

Whatever gets done along these lines for the Dorado must also be done for the
Dolphin in order for it to be of much use.  I will negotiate with Fiala on this.


5. Release schedule

These booting mechanisms require a new set of EPROMs to be programmed and
installed on the BaseBoard of each Dorado.  Ed McCreight also has some changes
he wants to make to the EPROM code.  It seems sensible to change both his code
and mine at the same time.  Therefore, I will wait until after he returns from
vacation (~July 5) before having the new EPROMs installed.  In the meantime, I
have installed new boot microcode in my Dorado and will exercise it myself for
the next couple of weeks.

Even after the new EPROMs are installed in any given Dorado, no change in
booting behavior will occur until Initial microcode has been installed on that
Dorado's disk.

The new Othello is ready and will be released with Cedar 3.2.  It is
upward-compatible from the old Othello.

New versions of the Alto/Mesa and Cedar microcode will be released soon, as
will the Alto emulator that is used as the base for the Smalltalk and Lisp
systems.  These are all upward-compatible from the current microcode except in
one respect.  The Alto emulator has a special "soft start" entry point.  An Alto
program which loads new microcode and specifies this entry point will continue
execution at the instruction following the call to LoadRam rather than
reinitializing memory and re-booting the Alto OS from the disk.

This works only if the old and new microcode are "similar enough", i.e., share
the same conventions for use of registers.  In this case, the old and new
microcode are not sufficiently similar, so the "soft start" entry point will not
work.  This will be inconvenient for users who load microcode directly using the
LoadMB program, since the default starting address is the "soft start" entry
point.  It will also cause problems for programs that have Dorado microcode
bound into them which they load during initialization (I believe Smalltalk-80
does this).

Therefore, to minimize inconvenience, I would like to coordinate a release of all
standard emulators simultaneously.  I'd like the implementors to tell me how soon
it would be convenient for them to do this so I can set up an exact schedule; I'll
then send out details of how to construct the new microcode.  This release is
independent of the release of the new boot microcode and Othello, and can occur
either before or after.

Note: I previously sent around a message describing a proposed Dorado disk
format change.  This change is NOT included in this release.  Although it is
quite desirable, I don't think it's especially urgent, so I intend to defer it for a
while.

	Ed

*start*
00517 00024 US 
Date: 21 June 1982 11:25 am PDT (Monday)
From: Pier.PA
Subject: Dorado EPROM reminder
To: McCreight
cc: Taft, Sosinski, Yeary, Pier

REMINDER:

In the new BaseBoard EPROMs, please change the default clock setting to match
the one used by Midas when the clock is set to 32 nsec.  The more accurate
figure of merit is 31.7 nsec.  Midas and the boot microprocessor currently differ
by "one" in the clock load value.  This will solve a problem with cursor flicker
on color Dorados.  Thanks.

Ken

*start*
00726 00024 US 
Date: 21 June 1982 1:59 pm PDT (Monday)
From: Kaehler.PA
Subject: Re: Dorado booting
In-reply-to: Your message of 21 June 1982 10:46 am PDT (Monday)
To: Taft
cc: Kaehler, DEUTSCH, Krasner

Ed,    How do your changes effect what happens upon one- and two-button
boots?
	Smalltalk-80 very much needs the "soft-start" feature, because diferent
versions of the system have different microcode.  Please be more specific on what
I have to do to make the LoadMB and LoadRam work.  (Maybe we should keep
our own old versions).
	If you send out a general message, you might remind the listeners that
"Smalltalk" microcode is Smalltalk-76, and that Smalltalk-80 is the system most
people are now using.

		Ted.

*start*
01324 00024 US 
Date: 21 June 1982 2:34 pm PDT (Monday)
From: Taft.PA
Subject: Re: Dorado booting
In-reply-to: Kaehler's message of 21 June 1982 1:59 pm PDT (Monday)
To: Kaehler
cc: Taft, DEUTSCH, Krasner

One- and two-button boots are unaffected by the change.

The "soft start" feature is still implemented; it's just that it won't work if the
microcode currently running has an old-vintage Alto emulator and the microcode
being loaded has a new-vintage Alto emulator, or vice versa.  This is why I
want to release new versions of everything at the same time.  Once everything
is converted over to new-vintage Alto emulators, the "soft start" feature will
work as well as before.  (And I don't intend to change the Alto emulator register
conventions again without good reason.)

To switch between old and new worlds using LoadMB, you must go through a
full Alto boot, i.e.,

	> LoadMB xxxxx.mb 1076/s

If you are currently running an old-vintage Alto emulator and you want to run
a program that calls LoadRam to load a new-vintage Alto emulator, you must
first load some new-vintage Alto emulator (not necessarily the same one) using
the above LoadMB command.  The same is required when going in the other
direction (e.g., to run an old Smalltalk .run file after the new-vintage microcode
has been released).
	Ed

*start*
04316 00024 US 
Date: 22 June 1982 12:06 pm PDT (Tuesday)
From: Taft.PA
Subject: New microcode construction
To: DoradoMicroprogrammers^
Reply-To: Taft

I have stored all the new microcode on the release directories, but have not
released the new .eb files to boot servers.  I propose to do the latter at the end of
the day next Monday, June 28.  Please prepare to release new versions of your
microcode at the same time.

I am still working on revising the "Dorado Booting" documentation; I expect to be
done later this week, and will send a general announcement at that time.  If
people have to take explicit actions to obtain or install new versions of the things
you release, please send an annoucement to your users before next Monday
evening.

To rebuild your microcode, please obtain the latest versions of:

	[Indigo]<DoradoSource>AEmuDibs.dm
	[Indigo]<DoradoSource>InitialSelect.mb    (I'll explain this below)
	[Indigo]<Dorado>LoadMB.run

You must then reassemble all your microcode, as a number of register definitions
got shuffled around.  You will first need to edit your version of ATraps.mc to
eliminate the definition of opcode 61027B, as the new Alto Emulator has used it
for the DisplayFieldRate opcode (formerly 61046B; I moved it at Ed Fiala's
request, because he is implementing it on the Dolphin and it is inconvenient for
him to define opcodes greater than 61037B).

You build the Ether-bootable (.eb) microcode file for your emulator in the old
way, i.e.,

  > LoadMB/e DoradoXXX.eb/o XXX.mb 1076/s

This is the version to install on boot servers.  Additionally, you should now
build a second .eb file consisting of InitialSelect.mb followed by your emulator:

  > LoadMB/e DoradoInitialXXX.eb/o InitialSelect.mb 406/s XXX.mb 1076/s

This is a file which people may install on the Initial region of their disks if they
want to (see my previous message); it boots the installed Pilot microcode if "P" is
held down, else loads XXX.mb from the same file.

Please store these .eb files on some file server and tell me where they are.  I am
constructing a .df file describing all the components of all Dorado microcode, by
means of which a consistent snapshot will be made at every Cedar release. 

(Note that the file DoradoInitialEtherXXX.eb, also described in my previous
message, does not actually contain XXX.mb and therefore need not be rebuilt
when new versions of XXX are released.  I will produce and maintain these
files.)

There is a new version of D1Lang.mc, which is preassembled into the
AltoEmuDefs.st which you use.  The only change is addition of a "StackNoUfl_"
destination which writes the stack without underflow checking; this is the only
way to write Stack addresses 0 mod 100B, in the unlikely situation you should
ever want to do so (it was needed by the new Bootstrap microcode).

My previous message was apparently not clear enough about what has happened
to the "soft start" feature.  The following message may be helpful.

-------------------
Date: 21 June 1982 2:34 pm PDT (Monday)
From: Taft.PA
Subject: Re: Dorado booting
In-reply-to: Kaehler's message of 21 June 1982 1:59 pm PDT (Monday)
To: Kaehler
cc: Taft, DEUTSCH, Krasner

One- and two-button boots are unaffected by the change.

The "soft start" feature is still implemented; it's just that it won't work if the
microcode currently running has an old-vintage Alto emulator and the microcode
being loaded has a new-vintage Alto emulator, or vice versa.  This is why I
want to release new versions of everything at the same time.  Once everything
is converted over to new-vintage Alto emulators, the "soft start" feature will
work as well as before.  (And I don't intend to change the Alto emulator register
conventions again without good reason.)

To switch between old and new worlds using LoadMB, you must go through a
full Alto boot, i.e.,

	> LoadMB xxxxx.mb 1076/s

If you are currently running an old-vintage Alto emulator and you want to run
a program that calls LoadRam to load a new-vintage Alto emulator, you must
first load some new-vintage Alto emulator (not necessarily the same one) using
the above LoadMB command.  The same is required when going in the other
direction (e.g., to run an old Smalltalk .run file after the new-vintage microcode
has been released).
	Ed
-------------------
*start*
01173 00024 US 
Date: 22 June 1982 3:17 pm EDT (Tuesday)
From: Axelrod.WBST
Subject: Dorado RINN Article Solicited
To: DoradoCore^.pa
cc: NewsLetter, Allen, Axelrod
Reply-To: Axelrod

Folks
It is my perception that the development and installations of Dorados have
matured to a point that you now might be willing to talk about it.  I know that
there is a lot of interest in the network community, and I wonder if one of you
might be willing to take the time to write a short article for the Research InterNet
Newsletter.  The Summer issue is scheduled for mid-July.

The article should be relatively brief (300-500 words) and relatively
non-technical.  It might address such questions as 	
	What is its architecture?
	What is unique or unusual about it?
	How does it relate to the Alto/Dolphin/DLion lineage?
	Who has it?
	What is it being used for?
	What is its future?
	or anything else you can think of.

The article would be by-lined with the author's name.  Perhaps there is an
existing document that can be digested.

I hope someone can find the time to do this.  I think the information would be
very valuable and would be much appreciated.

Thanks
   Art

*start*
00321 00024 US 
Date: 23 June 1982 5:19 pm PDT (Wednesday)
From: Taft.PA
Subject: Dorado booting documentation
To: DoradoCore^, DoradoMicroprogrammers^, CedarImplementors^
Reply-To: Taft

The "Dorado Booting" memo has been revised to reflect the new conventions; see
[Indigo]<DoradoDocs>DoradoBooting.press.
	Ed

*start*
01228 00024 US 
Date: 24 June 1982 4:34 pm PDT (Thursday)
From: Kaehler.PA
Subject: Re: New microcode construction
In-reply-to: Your message of 22 June 1982 12:06 pm PDT (Tuesday)
To: Taft
cc: Kaehler, Krasner, Deutsch, Masinter

Ed,
	Please do not release the new .eb files to the boot servers until I have
tested my response to the new conventions.   I will try to be ready by next
Monday, but I may not make it.  Please don't release the new files until Larry
Masinter tell you that we have tested our systems.

	There are many old versions of Smalltalk-80 being used.  With the
change, users will have to run LoadMB with old microcode and then execute the
normal Smalltalk.run (containing a loadMB of the real microcode).  I will create a
command file to do LoadMB of old code, and tell all Smalltalk-80 users to fetch it
to run old systems.

	I will also release a new Smalltalk-80 interpreter using the new
conventions.

	I still don't completely understand the implications of the upsoming
microcode change.  How is "LoadMB oldmicrocode.mb" able to get back to the old
coventions?  If the loader in page 63 has been changed, how is it able to load
and start the old microcode?  I'll come and talk to you.
		Ted.

*start*
01665 00024 US 
Date: 24 June 1982 5:04 pm PDT (Thursday)
From: Taft.PA
Subject: Re: New microcode construction
In-reply-to: Kaehler's message of 24 June 1982 4:34 pm PDT (Thursday)
To: Kaehler
cc: Taft, Krasner, Deutsch, Masinter

Very well, I'll wait until I hear from you before I make the release.  I'm not in
any terrible rush.

The incompatibility has nothing to do with changes in the microcode loader
(LoadRam), but is rather a result of the microcode being loaded being "too
different" from the microcode that is currently running.  The "soft start" feature
that allows the current emulator to "continue" executing the same
macroinstructions while running new microcode depends on the old and new
microcode sharing the same conventions for representing the state of the
emulator (R registers, base registers, etc.)  In general, any change to
RegisterDefs.mc introduces an incompatibility that makes the "soft start" no
longer work.

However, it is always possible to load and start any microcode at its "boot" entry
point (the label InitMap in all Alto-based emulators), because when started in
this way, the new microcode completely reinitializes its state in a way that does
not depend on what was running before.

How is "LoadMB oldmicrocode.mb" able to get back to the old coventions?  It
isn't; you have to say "LoadMB oldmicrocode.mb 1076/s", which starts
oldmicrocode at InitMap.
	Ed

p.s. The LoadRam microcode actually HAS changed, but in an upward-compatible
way: LoadRam is now able to load data into RM as well as IM and IFUM. 
However, it will not be possible to use this feature until new EPROMs have been
installed in every Dorado.

*start*
00701 00024 US 
Date: 24 June 1982 5:16 pm PDT (Thursday)
From: Taft.PA
Subject: New macros
To: DoradoMicroprogrammers^
Reply-To: Taft

I forgot to mention one thing in my previous message: new macros for
conveniently extracting the high or low byte from a full-word constant.

HighByte[x] and LowByte[x] take an existing full-word integer (defined by Set),
constant (defined by MC), or list of up to 9 integers and/or constants to be added
together, extract the high or low byte, and return the result as a constant that
may be used in an instruction without further qualification.  For example:

	Set[funnyConstant, 123456];

	T_ HighByte[funnyConstant];
	T_ T OR (LowByte[funnyConstant]);

*start*
02219 00024 US 
Date: 25 June 1982 5:53 pm PDT (Friday)
From: Kaehler.PA
Subject: New Smalltalk-80 Microcode for Dorados
To: Smalltalk80Users^
cc: Taft
Reply-To: Kaehler

The way in which all Dorados boot themselves is changing.  Ed Taft will be
sending a message out about this.  Here is how the new conventions effect
Smalltalk-80 users.

If you only use Dolphins, ignore this message.

Sometime in the next few days, I will send another message saying, "UPDATE
PARTITIONS NOW."  When that message comes, you must do the following
before Smalltalk-80 will run again on your Dorado.

1.  Every Smalltalk partition MUST have its command files updated.  To do this
type @newSt80<cr>.  Do a three-botton boot after fetching the new command
files.  The symptom that the update has not been done is an abrupt crash from
Smalltalk into raw bits.  The update only has to be done once on each partition. 
To verify that the update has been done, type old*<tab>.  If the files oldSnap.cm
and oldST80.cm are there, you are safe.

2.  (Having done 1.)  If you want to run a Smalltalk with a version date from
Apr15 to the present, everything works exactly as it used to.  Start Smalltalk as
you normally would, and all will be well.  (The safe versions are those with
VM3, namely Jun24, May12, May3, and Apr15).

3.  If you want to run a Smalltalk with a version date before Apr15, you now
must use a different command file to start it.  Type @oldSnap to resume
snapshot.im, @oldST80 to start a clean system, or @RunOldST80@ xxxx.im for
your own image file.  In addition, hold down a number key while the command
file is executing.  If you are on partition 2, hold down 2 just after you type
@oldSnap<cr> and until Smalltalk come up.  (Like the Dolphin, the microcode is
being loaded separately from the image.  Between the two, a boot occurs.  The
number key tells what partition to start on after the boot).  (The old versions are
those that use VM2 or VM1, namely Apr6, Mar19 and earlier).

Smalltalk76, Lisp, and Mesa get their microcode off the Ethernet, and will work
as usual.

I will send a message, write on the whiteboard in SCG, and come around to the
Dorados at the magic moment to update partitions.
		Ted.

*start*
00529 00024 US 
Date: 27 June 1982 2:46 pm PDT (Sunday)
From: Masinter.PA
Subject: Re: New microcode construction
In-reply-to: Your message of 22 June 1982 12:06 pm PDT (Tuesday)
To: Taft
cc: Masinter

I have prepared a new microcode to be released along with the others. It is
currently stored on [phylum]<LispCore>ConBrio>Dorado(Initial)Lisp.EB. However,
the standard "release" directory is [phylum]<Lisp>Current>, and the files will be
moved from <LispCore>ConBrio> to <Lisp>Current> sometime Monday afternoon.

Larry
*start*
01317 00024 US 
Date: 27 June 1982 3:50 pm PDT (Sunday)
From: Taft.PA
Subject: New Dorado microcode
To: DoradoUsers^
Reply-To: Taft

There will shortly be a coordinated release of all standard Dorado emulator
microcode (Mesa, Cedar, Lisp, Smalltalk-76, and Smalltalk-80).  Currently this
release is scheduled for the end of the day Monday, June 28; however, there is
some likelihood that this will be delayed.

If you use the standard versions of Mesa, Cedar, Lisp, or Smalltalk-76 microcode
(obtained by holding down the initial letter key while 3-push booting), you
need not take any special action.  If you use Smalltalk-80, you must follow the
procedure given in Ted Kaehler's recent message to Smalltalk80Users^.  If you
have a special microcode (.mb) file which you load using LoadMB, you must get
that microcode reassembled.

This release is in preparation for a forthcoming major revision in the booting
mechanisms which will enable, among other things, booting microcode from the
disk as well as from the Ethernet.  The change will require new boot EPROMs to
be installed in each Dorado; this conversion will not begin for a while (at least a
couple of weeks).  In the meantime, if you are interested, you may preview the
revised "Dorado Booting" memo, file [Indigo]<DoradoDocs>DoradoBooting.press.

*start*
01158 00024 US 
Date: 7 July 1982 1:01 pm PDT (Wednesday)
From: Taft.PA
Subject: Re: Microcode sizes
In-reply-to: Levin's message of 7 July 1982 11:58 am PDT (Wednesday)
To: Levin
cc: Taft, Fiala

Emulator				2592
  Process			309
  Xfer				211 (see note 1)
  BitBlt			293
  TextBlt			(not implemented)
  Floating Point		300
  Cedar			840 (2)
  everything else		718 (3)
Disk					297 (4)
Ethernet				128 (4)
Display				303 (4, 5)
Other I/O				250 (4, 6)
everything else			361 (7)

unused CRAM space		86

Total				4096


Notes:

(1) Includes Xfer-related opcodes such as LLKB, DESCB, etc.

(2) This is relatively low-quality code, so this figure is not a good measure of
the cost of the Cedar opcodes relative to everything else.  From past experience, I
estimate that a reduction of at least 50% is possible in the size of this microcode.

(3) Includes fault handler, multiply/divide subroutines, and a few special
Dorado-dependent opcodes.

(4) Includes initialization.

(5) Includes LF display microcode and some stuff shared with color display.

(6) Includes color display microcode.

(7) Mostly booting, memory initialization, LoadRam, etc.

*start*
00450 00024 US 
Date: 7 July 1982 4:35 pm PDT (Wednesday)
From: Taft.PA
Subject: Re: Dorado RINN Article Solicited
In-reply-to: Axelrod.WBST's message of 22 June 1982 3:17 pm EDT (Tuesday)
To: Axelrod.WBST
cc: NewsLetter.WBST, Allen.WBST, Taft

My submission is now done and is stored as [Ivy]<Taft>DoradoHighlight.bravo. 
The tentative title is "Dorado Highlight", but you are welcome to give the article
a different title if you want.
	Ed

*start*
00983 00024 US 
Date: 2 Aug. 1982 10:16 am PDT (Monday)
From: VEST.PA
Subject: Re: Dorado UnBug disk
In-reply-to: Your message of 27 July 1982 9:30 am PDT (Tuesday)
To: Taft
cc: VEST, Clark, D'alfonso, McDaniel, McCreight

	I also noticed that the Dorado Unbug disk was in terriable condition. I
corrected the problems you mentioned last January and I also have changed all
of the Midas command files to make the running of the Diagnostics much easier
and less confusing. I have also added a Midas command to run all of the  Micro
Diagnostics with one menu selection.
	I don't think that keeping a copy of the Disk on file is the right way to
do business, a command file is less costly for space and easier to update.
	I received considerable resistance from some people about changing over
to the unbug disk that we are using for check-out at the Model shop. 
	Could we get together sometime and try to come up with a standard
unbug disk that everybody will use?? 

Frank 

*start*
00493 00024 US 
Date: 30 Aug. 1982 10:56 am PDT (Monday)
From: vest.PA
Subject: Re: Dorado UnBug disk
In-reply-to: Your message of 18 Aug. 1982 6:58 pm PDT (Wednesday)
To: Taft
cc: VEST

The command file that will build a disk that we use at the Model shop is located
at [Phylum]<Vest>Doradomidasdisk.cm. The big difference in this disk is that the
Midas command files are changed to run to the end of the diagnostic instead of
typing in (BEGIN;G)  to start every diagnostic.


Frank

*start*
02217 00024 US 
Date: 10 Sept. 1982 5:52 pm PDT (Friday)
From: Taft.PA
Subject: Outcome of Phillips monitor investigation
To: Sosinski, Yeary, Overton, Clark, Henning, Vest, Winfield, Ornstein, Pier
cc: Cude, JKennedy, Garner, McCreight, Fiala, Taft, DoradoSupport

Ed McCreight and I (with help from Herb and Charlie) investigated the problem
that turned up when hooking the new Phillips monitors to Dorados and
Dolphins.  The picture was shifted a substantial amount to the left, and could be
centered only by turning the horizontal centering adjustment all the way to one
end and by fiddling with the horizontal frequency adjustment.

There turned out to be two causes of the problem:

1. The Dorado/Dolphin horizontal sync waveform was not quite the same as the
Dandelion's.

2. The monitors we received were not at the same rev level as the ones used on
Dandelions; one component was different, and that had a substantial effect.

The solution:

1. Ed Fiala and I will shortly release new versions of microcode.  The display
controllers will be programmed to produce a horizontal waveform identical to that
used on Dandelions.  Fortunately, the Ball Brothers monitors appear not to be
affected noticeably by the change in waveform, so they should not need to be
readjusted.

(Detail: Dorados with DispM boards will need to have new horizontal PROMs
blown.  I will consult with Ken Pier on this.)

2. All Phillips monitors should be inspected to ensure that R215 is a 33K resistor;
if not, the resistor should be replaced and the monitor readjusted.  With the
correct resistor and the new microcode, you can expect that moving the
horizontal position and horizontal frequency controls to factory settings will
produce a centered picture.

For completeness, here is the new horizontal waveform for Dolphins and
Dorados, specified in terms of bit times.  (Note that these are slightly different
from the Dandelion, because the Dorado and Dolphin use a 50 MHz bit clock
whereas the Dandelion uses 51 MHz.)

1024 bits (20.48 us) visible
26 bits (0.52 us) blank (right border)
360 bits (7.20 us) sync+blank
30 bits (0.60 us) blank (left border)

1440 bits (28.80 us) total, for a line rate of 34.72 KHz.

	Ed

*start*
00887 00024 US 
Date: 11 Sept. 1982 1:48 pm PDT (Saturday)
From: Taft.PA
Subject: Dorado microcode release
To: DoradoUsers^
Reply-To: Taft

A new version of the Dorado Alto/Mesa and Cedar microcode has been released. 
Since Dorado microcode is usually loaded from Ethernet boot servers, you need
not do anything to install this new version.

The only change is that the signals sent from the Dorado to control the display
are slightly different.  This will have no noticeable effect on most displays. 
However, on certain new displays (manufactured by Phillips rather than Ball
Brothers), this will cause the picture to shift substantially to the right.

If this has happened to your display, a technician can re-center the picture by
changing one component in the display and making an adjustment.  (If your
technician doesn't know how to do this, ask him to contact me.)

	Ed

*start*
00305 00024 US 
Date: 11 Sept. 1982 1:49 pm PDT (Saturday)
From: Taft.PA
Subject: New AEmu
To: DoradoMicroprogrammers^
Reply-To: Taft

At your earliest convenience, please load up and release new versions of all
emulators to incorporate the latest [Indigo]<DoradoSource>AEmuDibs.dm.  Thanks.
	Ed

*start*
00614 00024 US 
Date: 11 Sept. 1982 4:49 pm PDT (Saturday)
From: Taft.PA
Subject: New DispM PROMs
To: Sosinski, Yeary
cc: DoradoCore^, Taft
Reply-To: Taft

I've modified the PROM programs for the LF horizontal waveform PROMs on
DispM (positions b20 and a16), and stored new versions of
[Indigo]<DoradoLogic>DoradoProms.run and <DoradoSource>DoradoProms.dm. 
Please retrofit all existing DispM boards with new PROMs as time permits, and
make sure all future DispM boards get new PROMs.

The DispM board in "Reprisal" now has a new set of PROMs; and I blew an extra
pair which I left on your workbench.
	Ed

*start*
01697 00024 US 
Date: 28 Sept. 1982 3:24 pm PDT (Tuesday)
From: Taft.PA
Subject: New BaseBoard EPROMs
To: DoradoCore^
cc: Kolling
Reply-to: McCreight, Taft

Ed McCreight and I have completed developing a new set of EPROMs for Dorado
BaseBoards.  Herb and Charlie will be installing new EPROMs in Ed McCreight's,
Karen Kolling's, and my Dorados for a week's test.  Assuming no problems turn
up, new EPROMs should then be installed in all Dorados, both present and
future.

The new EPROM definition is contained in [Indigo]<Dorado>DoradoBaseRom.mb;
and the command file to blow the EPROMs is DoradoBaseRom-Blow.cm, which is
loaded from [Indigo]<Dorado>DoradoBaseRom.dm.  All 4 EPROMs on each
BaseBoard must be reprogrammed.

The changes from the old EPROMs are as follows.

Microcomputer code:

1. Power-on sets the Dorado's clock to the exact same value as Midas uses when
it is told "SetClk 32"; the value is actually 31.7 ns.

2. Presence of the debugging jumper disables the Dorado from being able to
power itself off under program control (e.g., DMT), and also disables the
watch-dog timer when the microcomputer crashes in certain ways (so you can
look at the entrails using Midas).

3. The "alarm-clock" feature now actually works.

4. The "fast flash syndrome" bug is fixed (caused by the 6502 powering up in
BCD instead of binary mode).  I think some other bugs were fixed, too, but I
don't remember what they were.


Boot microcode:

The Dorado can now boot microcode from the disk as well as from the Ethernet,
if microcode has been installed on the disk (a feature added to Othello a couple
of months ago).  Complete details are in [Indigo]<DoradoDocs>DoradoBooting.press.

	Ed

*start*
01250 00024 US 
Date: 1 Oct. 1982 5:01 pm PDT (Friday)
Sender: Raim.EOS
Subject: 1100 Family of Scientific Information Processors
To: AllEOS^.eos, AllPA^.pa, AllWBST^.wbst, AllES^.es
From: Raim.eos
Reply-To: Raim.eos

The 1100 Program has announced the 1100 Family of Scientific Information
Processors: the 1100, 1108 (Dandelion), and 1132 (Dorado); and the availability of
two major software products: Interlisp-D and Smalltalk-80.  The following
salesmen are qualified to respond to customer inquiries.  


Mike Moran		Southwest, Midwest U.S.	Moran.eos
			[except Schlumberger in	XEOS
			Houston, Texas]		300 N. Halstead St.
							Pasadena, CA. 91107
							Intelnet: 8-844-2002
							(213) 351-2351 X2002

Dennis Ryan	Northwest U.S., Canada	(Dennis Ryan)EOSMail.eos
							Xerox Corp.
							2444 Moorpark Ave.
							Suite 300
							San Jose, CA. 95129
							Intelnet: none
							(408) 977-1250

Ed McGoldrick	Northeast U.S.		(Ed McGoldrick)EOSMail.eos
							XEOS
							105 Froehlich Farm Bl.
							Woodbury, NY 11797
							Intelnet: 8-329-1205
							(516) 349-4205

Paul Gallo		Wash. D.C, Southeast U.S.	(Paul Gallo)EOSMail.eos
							XEOS
							1616 N. Fort Myer Dr.
							Arlington, VA 22209
							Intelnet: 8-444-6544



*start*
00625 00024 US 
Date: 4 Oct. 1982 9:31 am PDT (Monday)
From: Taft.PA
Subject: BaseBoard EPROMs
To: DoradoCore^
Reply-To: Taft

The new BaseBoard EPROMs seem to be running ok in the three or four
machines in which we have been testing them.  Therefore, please go ahead and
retrofit them to all remaining Dorados, and see that future Dorados get new
EPROMs also.

The new EPROM definition is contained in [Indigo]<Dorado>DoradoBaseRom.mb;
and the command file to blow the EPROMs is DoradoBaseRom-Blow.cm, which is
loaded from [Indigo]<Dorado>DoradoBaseRom.dm.  All 4 EPROMs on each
BaseBoard must be reprogrammed.
	Ed

*start*
05016 00024 US 
Date: 4 Oct. 1982 10:07 am PDT (Monday)
From: Taft.PA
Subject: Dorado booting
To: DoradoUsers^
Reply-To: Taft

The technicians are now in the process of installing new BaseBoard EPROMs in
all Dorados.  These EPROMs contain, among other things, software and microcode
which control how a Dorado behaves when it is booted.  The major new feature
is that a Dorado is now able to boot-load microcode from either disk or Ethernet,
whereas formerly only Ethernet booting was possible.

Complete documentation on Dorado booting may be found in
[Indigo]<DoradoDocs>DoradoBooting.press.  The following excerpt is everything
that most users should need to know.

When you cold-boot a Dorado (power-on or 3-push boot), if you are holding
down one of the M, L, S, C, or T keys, then microcode is booted from the
Ethernet; the microcode is selected by the key (M = Alto/Mesa, L = Lisp, S =
Smalltalk-76, C = Cedar, T = Test.)  If you are not holding down any of these
keys, and Dorado microcode is present in the Initial region of the disk, and the
disk is on-line, then that Initial microcode is loaded and executed; what happens
after that depends on what Initial microcode is installed.  If the attempt to boot
microcode from the disk fails, the Alto/Mesa emulator is booted from the
Ethernet.

There are two places on a Dorado's disk where you may install microcode.  One
is called the Initial region, which is a special region of the disk reserved for
microcode.  The other is called the Pilot microcode or soft microcode file, which
is a more-or-less ordinary Pilot file which may reside in any Pilot volume.  (If
you don't have a Pilot file system on your disk then you cannot install Pilot
microcode.)

The Initial microcode is what is initially loaded and started when you boot
microcode from the disk, as described above.  You can choose from among many
different pieces of microcode to install on the Initial region of your Dorado's
disk.  The most useful ones are the following.

-- DoradoCedar.eb, DoradoLisp.eb, DoradoMesa.eb, DoradoSmalltalk.eb: these are
identical to the corresponding microcode booted from the Ethernet.

-- DoradoInitialCedar.eb, DoradoInitialLisp.eb, DoradoInitialMesa.eb,
DoradoInitialSmalltalk.eb: each of these is a combination of a Pilot disk microcode
boot loader and a copy of a particular emulator.  If booted with the P key
depressed, it invokes the installed Pilot microcode file; otherwise it starts the
emulator microcode that was part of the Initial file itself.

-- DoradoInitialEtherCedar.eb, DoradoInitialEtherLisp.eb,
DoradoInitialEtherMesa.eb, DoradoInitialEtherSmalltalk.eb.  Each of these is a
combination of a Pilot disk microcode boot loader and an Ethernet microcode boot
loader configured to boot a particular emulator.  If booted with the P key
depressed, it invokes the installed Pilot microcode file; otherwise it boots the
appropriate microcode from an Ethernet boot server.

If you normally use only standard, released versions of emulators, you are
advised to install only one of the last group of microcode files on the Initial
region of your disk.  That way, you are guaranteed always to get the most
up-to-date version of microcode from a boot server, and you need not install new
versions on your disk every time the microcode's maintainer fixes a bug or makes
an upward-compatible improvement.  (For Cedar users: the Cedar installation
procedure sets things up this way automatically.)

On the other hand, if you are running non-standard or pre-release versions of
software that require incompatible microcode, you will find it convenient to
install that microcode on your disk.  Disk booting of emulator microcode should
also prove useful during transitions between incompatible versions of microcode.

All microcode is kept on [Indigo]<Dorado>, and is copied to [Indigo]<Cedar>Top>
during each Cedar release.  Both Initial and Pilot microcode are installed using
the Othello utility program.  Note that even though Othello is a Pilot program, it
can be used to install any Initial microcode, even if you don't have a Pilot file
system on your disk; of course, you do have to have a Pilot file system in order
to install Pilot microcode.

The following is a sample dialogue for installing Initial and Pilot microcode:

[Get into the Alto NetExec somehow]

> MesaNetExec

[Wait a few seconds for Ether booting]

> Switches: n	[do this only if you don't have a Pilot file system]
> OthelloDorado

[Wait a few seconds for Ether booting]

Othello 7.0 of 17-Jun-82 17:34:02
> Login
User: xxxxxx
Password: xxxxxx
> Open Indigo
Indigo Parc IFS 1.36L, File Server of May 17, 1982
> Directory Dorado
> Initial Microcode Fetch
Drive name: RD0
File name: DoradoInitialMesa.eb
Are you sure? Yes
Fetching...done

[Do the following only if you are installing Pilot microcode]

> Pilot Microcode Fetch
Logical volume name: Othello
Pilot microcode file name: DoradoCedar.eb
Fetching...installing...done
Shall I use this for the physical volume? Yes

*start*
01480 00024 US 
Date: 14 Oct. 1982 9:12 am PDT (Thursday)
From: Taft.PA
Subject: Dorado disk diagnostic needed
To: DoradoCore^, CedarImplementors^
Reply-To: Taft

As you know, we have no Dorado disk diagnostic software which operates in the
Pilot/Cedar world; all our disk debugging is still done using the Alto disk
diagnostic.  This is often not very productive, since the Alto diagnostic cannot
deal with Pilot disk format, and the errors reported by the Alto diagnostic aren't
particularly meaningful in terms of the Dorado hardware.  As we continue to
disengage from the Alto world (and people convert their Dorados completely to
Pilot), the need for a good Pilot-based disk diagnostic will increase.

SDD has developed a comprehensive set of disk diagnostics for the Dandelion. 
Particularly noteworthy is a program called EI-Trident.  Among its capabilities
are the following:

  -- thorough testing of new disks (along the lines of BFSTest Certify);
  -- non-destructive testing of an already-formatted disk;
  -- destructive testing of a single cylinder reserved for that purpose.

I propose that we look into adapting this program for the Dorado.  There are some
machine-dependent portions of the diagnostic which will have to be modified;
but the bulk of the program is machine-independent and uses standard Pilot
interfaces such as PilotDiskFace.

As my plate is rather full at the moment, I wonder whether anyone else is
interested in looking into this.
	Ed

*start*
00575 00024 US 
Date: 15 Oct. 1982 10:58 am PDT (Friday)
From: TonyWest.PA
Subject: Re: Dorado disk diagnostic needed
In-reply-to: Your message of 14 Oct. 1982 9:12 am PDT (Thursday)
To: Taft
cc: Boggs

Ed:

It seems to me that I would be a natural choice for this job, particularly if we go ahead on our Dicentra disk plans.  However, as you know, I am not a Pilot guru (yet), and so I will probably need some hand-holding.  However, I will probably need similar help anyway to get the Dicentra business off the ground.

I will come and chat to you about it.

Tony

*start*
00815 00024 US 
Date: 9 Dec. 1982 3:49 pm PST (Thursday)
From: Krasner.PA
Subject: Bitblt bug
To: taft
cc: deutsch, Krasner

Ed,

I think there is a bug in your (therefore our) bitblt code.  The symptom is that
sometimes the last line of a bitblt is not done.

The cause, I think is:  If you get to BBVerticalLoop before the last line (VCount
= 0), and you just overflowed BBDst at the end of AdvanceSrcDst, 

then
	you go to BBDoneOrOverflow, where Vcount is tested.  It is now -1, so
you go to BitBltDone, and do not do the last line.

My fix (simple, but costs one instr) is to change from:

BBVerticalLoop: 
	VCount _ (VCount)-1, Branch[BBDoneOrOverflow, ALU<0, R<0];

to:

BBVerticalLoop: 
	VCount, Branch[BBDoneOrOverflow, ALU<0, R<0];
	VCount _ (VCount)-1;

Is this really a bug and the fix?

glenn

*start*
00616 00024 US 
Date: 10 Dec. 1982 9:51 am PST (Friday)
From: Taft.PA
Subject: Re: Bitblt bug
In-reply-to: Krasner's message of 9 Dec. 1982 3:49 pm PST (Thursday)
To: Krasner
cc: taft, deutsch

Right you are.  A better fix, which does not cost one cycle during the main loop,
is to change the instruction at BBDoneOrOverflow from:

	VCount, Branch[BitBltDone, R<0];
to:
	PD_ (VCount)+1;
	Branch[BitBltDone, ALU<0];

Since you have your own version of AltoBitBlt, why don't you go ahead and try
this.  I'll put it into the regular AltoBitBlt when I get a chance.
	Ed

p.s. PilotBitBlt may have the same bug.

*start*
01129 00024 US 
Date: 10 Feb. 1983 4:14 pm PST (Thursday)
From: Taft.PA
Subject: Dorado default partition
To: DoradoUsers^
Reply-To: Taft

The Dorado booting conventions will shortly be changed so that, in Alto
emulation mode, the default disk partition will be 5 instead of 4.  That is, a
power-on or 3-push boot with no keys pressed down will boot the Alto operating
system from partition 5 instead of partition 4.

(It will continue to be the case that a 1-push no-keys boot does not change
partitions; and a specific partition can be selected by holding down a digit key
from 1 to 5.)

This change will be made in approximately two weeks, at the time of the next
Cedar release.  When the time comes, another announcement will be made.  At
that time, you may find it convenient to move your Alto partitions around using
CopyDisk.

The reason for this change is to accomodate Cedar users who wish to keep only a
single Alto partition and devote the other four partitions' worth of space to
Cedar.  Having the Cedar region divided into two parts by the Alto volume on
partition 4 has been an operational inconvenience.

*start*
00343 00024 US 
Date: 10 Feb. 1983 4:17 pm PST (Thursday)
From: Taft.PA
Subject: New AEmu
To: DoradoMicroprogrammers^
Reply-To: Taft

The Alto Emulator containing the change to the default disk partition has been
released to [Indigo]<DoradoSource>AEmuDibs.cm.  There are no other changes. 
(The only changed file is AltoEmu.dib.)
	Ed

*start*
01130 00024 US 
Date: 25 Feb. 1983 1:43 pm PST (Friday)
From: Taft.PA
Subject: New AEmu microcode
To: DoradoMicroprogrammers^
Reply-To: Taft.PA

I've stored another new version of the Alto Emulator microcode as [Indigo]<DoradoSource>AEmuDibs.dm.  In addition to the change I announced previously (moving the default Alto volume to partition 5), there are two new changes:

1. The display borders are now white instead of black.  This is to eliminate the "display burn" syndrome, and also to eliminate the sharp black edges which many people found unaesthetic.  In fact, I moved the black edges slightly outside the full LF-mode picture, so on a properly-adjusted display they should be entirely hidden by the bezel.  (The net-bootable CRTTest program has been upgraded to show a full-screen picture; the corners of the pattern should just touch the insides of the round corners of the bezel.)

2. The BitBlt bug discovered by Glenn Krasner a couple of months ago has been fixed.

The new microcode will be released to boot servers at the time of the next Cedar release, which is currently scheduled for next Friday.

	Ed

*start*
00606 00024 US 
Date: 26 FEB 83 07:08 PST
From: MASINTER.PA
Subject: Dorado microcode
To:   Taft
cc:   Masinter

Just to let you know that I haven't imported your recent sources,
since they don't affect Lisp. Lisp now loads microcode at startup,
and so the default-partition and narrow-screen-mode don't affect
it (in fact, I think I can get back some space by not including
the booting microcode-- it is like using overlays).

I've also converted to using Pilot BITBLT. I would like to
be kept informed if you make any changes to Pilot BITBLT or
floating point so that I can track changes.

Larry
*start*
01738 00024 US 
Date: Tue, 15 Mar 83 12:55 PST
From: Taft.PA
Subject: Forthcoming new Dorado microcode
To: DoradoUsers^
Reply-To: Taft.PA

New versions of the Alto/Mesa and Cedar microcode will be released at the time of the forthcoming Cedar 4.0 release, currently planned for either late today or some time tomorrow.

The most noticeable change is that the borders on the display screen are white instead of black.  This is to eliminate the sharp black edges which many people found unaesthetic and which caused a permanent "burn" to appear on the screen in Alto emulation mode.  (In a future version, the pattern appearing in the borders will be programmable, just as on the Dandelion.)

There still exist black edges, but they now lie considerably outside the visible area of the picture.  On a properly-adjusted display, the edges should be entirely hidden by the bezel surrounding the screen.  The net-bootable CRTTest program has been upgraded to show a full-screen picture; the corners of the CRTTest pattern should just touch the insides of the round corners of the bezel.  If you see either dark edges or a bright band (brighter than the background white) near one edge, your display needs to be adjusted.

The former "Dorado booting" memo has been revised and split into two parts.  The first part, "operation", contains things most users need to know, and the second part, "implementation", gives the details of how it works.  The two parts are, respectively,

	[Indigo]<DoradoDocs>DoradoBooting.press
	[Indigo]<DoradoDocs>DoradoBootingImpl.press

Since Dorado booting is complicated and the number of possible variations and configuration options is large, I recommend that all Dorado users read the first document.

*start*
00350 00024 US 
Date: 21 March 1983 1:58 pm PST (Monday)
From: Vest.PA
Subject: IFU Complex 
To: Doradocore^
cc: Vest

IFU Complex will fail if we unbreak after done and continue. This is happening
on all of our Dorados at the Garage.

The failure occurs after 1 minute and 6 seconds, with a OpIfad22Err.

Has anybody else seem this?

Frank

*start*
00885 00024 US 
Date: Sun, 3 Apr 83 14:19 PST
From: Taft.PA
Subject: DoradoCedar microcode
To: CedarUsers^
Reply-To: Taft.PA

A new version of DoradoCedar microcode will shortly be released to boot servers, and will thereby become the standard microcode loaded by a "C" triple-boot.

This microcode does NOT work with Cedar versions earlier than 4.0.  Anyone who has not yet converted to 4.0 is advised to do so forthwith.  (This microcode was deliberately omitted from the 4.0 release precisely in order to prevent confusion during the transition.)

In this version, runtime type discrimination operations such as NARROW and WITH REF ANY SELECT are substantially faster.

People who care to may install [Indigo]<PreCedar>Top>DoradoCedar.eb on their Othello volume using the Pilot Microcode Fetch command.  This will cause the new microcode to be loaded by a "P" triple-boot.

*start*
00462 00024 US 
Date: 26 April 1983 4:42 pm PDT (Tuesday)
From: krasner.pa
Subject: Re: Dorado display border
In-reply-to: Taft's message of Mon, 25 Apr 83 16:05 PDT
To: Taft
cc: krasner, kaehler

Ed,

Please tell me which constants must change and to what.  There is strong
opinion among Smalltalk-80 users that the borders should be black.  (There is
even stronger opinion that they should not have to eventually get used to
anything.)

Thanks,
glenn

*start*
01658 00024 US 
Date: Thu, 9 Jun 83 19:05 PDT
From: Taft.PA
Subject: DispM PROMs and microcode
To: Vest
cc: Taft

I've prepared new PROM programs and microcode to enable terminals connected to DispM boards to have the same white borders as those connected to DispY boards.  Details:

[Io]<DoradoLogic>DoradoProms.run contains the new PROM definitions.  Both of the LFPROM chips need to be reprogrammed.

[Indigo]<Dorado>Test> (notice the special sub-directory) contains the following files:
	DoradoInitialMesa.eb -- to be installed as the "Initial" microcode
	DoradoCedar.eb -- to be installed as the "Pilot" microcode

Users who have done this should use "P" to boot Cedar rather than "C".  Note that I haven't released anything to boot servers.

The consequence of running old microcode on a machine with new PROMs is that the picture is shoved against the black border on the right, with an excessively large white border on the left.

The consequence of running new microcode on a machine with old PROMs would be that the left edge of the picture is obscured by the black border on the left, and an equal amount of white border appears on the right.

The correct appearance, of course, is that there is an equal amount of white on both sides (24 pixels, to be exact).  Use CRTTest or Cedar to judge whether things came out right.

I have not tested anything, so it might not work.  (But I tried to be careful.)

I will be away all next week, but back the week of the 20th.  Please let me know if it works so that I can ask the maintainers of the Lisp and Smalltalk microcode to prepare new versions using this display microcode.

Good luck.
	Ed

*start*
02124 00024 US 
Date: Wed, 22 Jun 83 10:26 PDT
From: Taft.PA
Subject: Revised microcode
To: DoradoMicroprogrammers^
cc: DoradoCore^, Taft
Reply-To: Taft.PA

A couple of months ago, the display microcode was modified to make the borders white rather than black.  Among other things, this required changing the horizontal blanking waveform.  On Dorados without color displays, the horizontal waveforms are programmable, so doing this was no problem.  However, on Dorados with color displays, the horizontal waveforms for the LF monitor are fixed by some PROMs.

We are now ready to begin changing those PROMs.  There is a new version of the display microcode that goes along with the new PROMs.  The plan is that as machines are converted to new PROMs, the new microcode will be installed on those machines' disks.  Once all machines have been converted, the new microcode will be released to boot servers and become the standard version.

To prepare for this, all Dorado emulators need to be loaded with the new display microcode.  These versions should then be made available to people whose Dorados have been converted to the new PROMs, but not "officially" released until all affected Dorados have been converted.

Note again that this change affects only machines with color displays; on other machines, the behavior of old and new microcode is identical.  The consequence of running old microcode on a machine with new PROMs is that the picture is shoved against the black border on the right, with an excessively large white border on the left.  The consequence of running new microcode on a machine with old PROMs is that the left edge of the picture is obscured by the black border on the left, and an equal amount of white border appears on the right.  The correct appearance, of course, is that there is an equal amount of white on both sides (24 pixels, to be exact).  You can use CRTTest to judge whether things came out right.

The new version of the Alto Emulator microcode is in [Indigo]<DoradoSource>Test>AEmuDibs.dm -- note the nonstandard sub-directory. Please let me know when you are ready.

	Ed

*start*
01742 00024 US 
Date: Tue, 28 Jun 83 17:07 PDT
From: Fiala.PA
Subject: Dorado Midas release
To: DoradoCore^.pa
cc: Fiala
Reply-To: Fiala.PA

I have made a fairly substantial revision to the Dorado Midas manual stored on [Indigo]<DoradoDocs>DoradoMidas.press.  A large section appended to the manual details methods used to read and write all registers and memories in the machine.  This information was requested by the lab technicians to help with Dorado debugging.

In addition, the sections on the DMux simulator and on command files have been substantially revised.

I have also dumped a new Dorado Midas onto [Indigo]<Dorado>DoradoMidasRun.dm.  Before loading this Midas onto an old Midas disk, you should delete the following files:
	Base.midas, Control.midas, Proc.midas, Ifud.midas, mmc.midas, mmd.midas,
	mmx.midas dsketh.midas dsp.midas.
These command files, formerly part of the Midas release, have now been absorbed into Special.midas, so you won't need them.  Then load the FTP dump file and execute midas/i.

Bugs in the command file code have been fixed and error reporting on command file errors has been beefed up substantially; I now think the command file code is solid, so please report any problems which you have with it.  You can now run "Test" from a command file, which was impossible previously.

In addition, some simulator bugs have been fixed; however, the simulator is still imperfect.  Also, a subaction inside "HWChk" called "Read-All-DMux" has been extensively revised.

Please report any bugs that you find.

Note: I looked at the "DoradoCore" distribution list, and there was no one outside PA in the list.  Someone please forward this message to the people who are trying to sell Dorados outside.

*start*
01150 00024 US 
Date: Thu, 30 Jun 83 12:21 PDT
From: Vest.PA
Subject: Dsk/Eth Problem
To: Boggs
cc: Taft, Dalfonso, Henning, Clark, Vest

I am sending this to you because you are listed at the sustaining engineer for the Dsk/Eth board, and Taft is the backup.

We have been having problems with the Fairchild 10016 chips (high failure rates). They were a single source chip.  Reciently the Motorola 10H016 became a second source.  We tried ~50 samples in random places in the Dorado and approved them for build IV.

In preparation for the next build, I replaced all of the Fairchild 100016 chips in my Dorado with Motorola 10H016 chips. (about 170 chips) 

All of the chips worked perfectly running all of the test programs and operating systems except for location B-10 on the Dsk/Eth board.

On page 19 of the Dsk/Eth sil drawings you can find the problem chip. I added a little delay to the clock pin and the chip seems to work ok.

We could use the Fairchild 10016 chips in this one place (a time bomb).
But, we would prefer to use the Motorola 10H016 chips everywhere for build IV.
What can we do to fix this one problem place? 

Frank

*start*
00442 00024 US 
Date: Fri, 8 Jul 83 16:51 PDT
From: Vest.PA
Subject: Dsk/Eth 10H016 fix
To: McCreight
cc: Taft, Boggs, Henning, Dalfonso, Vest

I added the 100 ohm terminator resistor to the clock circuit as you suggested and everything works ok now.

I installed the "fix" to the other two Dorados, and the problem with the 10H016 chips seems to be ok now.

The wire is from d15.3 to d48.3, do we want to make this an ECO?

Frank



*start*
00878 00024 US 
Date: Fri, 8 Jul 83 17:44 PDT
From: Taft.PA
Subject: Re: Dsk/Eth 10H016 fix
In-reply-to: "Vest's message of Fri, 8 Jul 83 16:51 PDT"
To: Vest
cc: McCreight, Taft, Boggs, Henning, Dalfonso

I suggest that consideration be given to retrofitting this change to all PC DskEth boards, not just new ones.  This will prevent problems that might arise if a 10H016 were used to replace a F100016 during maintenance.

I just checked the DskEth wire list for multiwire and stitchweld boards to see whether the source termination is already there.  It isn't.  So we should consider retrofitting these as well.

Perhaps a good strategy is to check every DskEth board that visits the Dorado lab or the garage and install the mod if not already present.  This avoids the need to muck with apparently working boards.

I will leave it to you to do the right thing.

	Ed

*start*
01466 00024 US 
Date: Tue, 12 Jul 83 15:56 PDT
From: Taft.PA
Subject: Turn off unused Dorados
To: DoradoUsers^
Reply-To: Taft.PA

A number of Dorados are regularly being left on during nights and weekends when they aren't being used.  This is a substantial waste of electricity.  The power consumption of a Dorado is approximately 2.5 kilowatts; and the heat produced by a Dorado is a substantial load on the air conditioning as well.

At the end of each day, or whenever you expect the Dorado will be unused for more than an hour, please turn it off.  There are at least two ways to do this:

-- Get into the Alto Executive and issue the Quit command.  This will run the DMT program, which shuts off power automatically after one hour.

-- From Cedar, boot Othello by clicking the Boot and Othello buttons in the top menu, and then type the command "Power off" to Othello.

(There are other methods as well, but explaining all of them would make this message unreasonably long.)

When a Dorado is off, pushing the boot button on the keyboard will turn it back on.  The machine will boot after approximately one minute rather than the normal few seconds.

In a future version of Cedar we expect there will be some provision for turning off idle Dorados automatically.  There are some difficulties with this, since it is not entirely clear what it means for all of Cedar to be "idle".  In the meantime, please cooperate by turning off idle Dorados manually.

*start*
01806 00024 US 
Date: Wed, 13 Jul 83 15:11 PDT
From: Taft.PA
Subject: Dorado microcode release
To: DoradoUsers^.pa
Reply-To: Taft.PA

New versions of all Dorado microcode will be released early tomorrow (Thursday).  The changes will affect only those Dorados that have color displays.  If the Dorado you use does NOT have a color display then you do not need to read the rest of this message.

Early tomorrow morning, a hardware change will be installed in all Dorados at PARC that have color displays.  The change affects the left and right borders of the LF (black-and-white) display.  There is new microcode that goes along with this hardware change.

The net-bootable microcode for Cedar, Alto/Mesa, and Smalltalk-78 will be updated as soon as the hardware changes have been completed.  If you use one of these systems and boot microcode from the net (as most users do), you need not take any special action to convert to the new microcode.

If you use Smalltalk-80, you should update to the new microcode by typing the command:

	> @GetInterp

to the Alto Executive.

The procedure for obtaining new Interlisp-D microcode will be announced in a later message to LispUsers^.pa.

The consequence of running old microcode on a machine with new PROMs is that the picture is shoved against the black border on the right, with an excessively large white border on the left.  The consequence of running new microcode on a machine with old PROMs is that the left edge of the picture is obscured by the black border on the left, and an equal amount of white border appears on the right.  The correct appearance, of course, is that there is an equal amount of white on both sides (24 pixels, to be exact).  Use CRTTest or any program that uses the full display to judge whether things came out right.


*start*
00778 00024 US 
Date: Sun, 4 Sep 83 18:14 PDT
From: Taft.PA
Subject: Obscure debugging restriction
To: DoradoMicroprogrammers^.pa
Reply-To: Taft.PA

Add this to the list of places where you can't plant breakpoints and expect to continue safely:

If the last instruction of an opcode combines a Store_ with an IFUJump, do not try to plant a breakpoint on that instruction or single-step through it.  If you do so, under some conditions (I don't know exactly what they are) the IFU somehow picks up two bytes of garbage, causing a bad dispatch or other malfunction several opcodes later when the garbage reaches the end of the IFU pipeline.

I have no evidence that combining Store_ and IFUJump causes any trouble during normal execution, only when single-stepping.

	Ed

*start*
01755 00024 US 
Date: Thu, 22 Sep 83 17:18 PDT
From: Taft.PA
Subject: New Dorado microcode
To: Cedar5Implementors^, AlpineImplementors^, VoiceProject^, Pier
cc: Taft
Reply-To: Taft.PA

I have prepared a new version of the Dorado Cedar microcode containing the following changes:

1. New reference counting operations for Cedar 5.0 are implemented.  (However, Cedar 4.4 continues to work with this microcode.)

2. The map microcode (for ASSOC, SETF, and GETF) was rewritten in an attempt to minimize wakeup latency for high-speed color displays.  Though this did not solve the problem I was attempting to fix, I have decided to retain the new map microcode anyway, since it is smaller and cleaner.  There should not be any functional changes from the previous microcode.

3. A bug in the disk microcode was fixed that caused an unnecessary restore to be done when switching between drives in a multi-drive system.  The Alpine and Voice servers should have this microcode installed at the next convenient time.

4. Microcode to run the Stable Storage board is included.

To install this microcode, use Othello's "Pilot microcode fetch" command to retrieve [Indigo]<PreCedar>Top>DoradoCedar.eb onto the Othello volume.  Then:

  a) If your disk is currently set up to boot Cedar microcode by default, use the "Initial microcode fetch" command to retrieve [Indigo]<Cedar>Top>DoradoInitialDisk.eb (note: NOT PreCedar).  Thereafter, your Dorado will boot the new microcode by default (do not hold down the "C" key).

  b) Otherwise (i.e., you boot Alto microcode by default), use the "P" key rather than the "C" key when booting Cedar.

I will appreciate Cedar 5 implementors running this microcode so as to expose any bugs I may have introduced.

	Ed

*start*
02909 00024 US 
Date: Thu, 27 Oct 83 18:33 PDT
From: Taft.PA
Subject: Flush_
To: Lampson
cc: Fiala, Pier, Taft

I recently rewrote the Dorado map microcode to tighten it up and spend less time with tasking off.  The new microcode turned out to have a problem that caused a page's dirty bit occasionally to be lost.  By trial-and-error, I determined that the dirty bit was being lost in the GetF opcode, which reads the map without changing it.  That is, the entry would read out clean when it was in fact dirty (presumably because the dirty flag hadn't successfully propagated from the cache to the map); and the page replacement algorithm would go ahead and re-use the page without writing it out.

The microcode that does not work simply flushes the page and immediately reads the map.  The sequence of instructions is approximately:

	Temp2_ A0, T_ MD;
	Temp1_ A0, Cnt_ 17S;
	Temp1_ Flush_ Temp1, Carry20, Branch[., Cnt#0&-1];
	PD_ (RMap_ Temp2)-1;
	PD_ PRef, Branch[., ALU<0];	* wait for MapBufBusy

followed by reading the Pipe.

The microcode that does work flushes the page twice, first with tasking on and then with tasking off, then reads the map with tasking still off.  The sequence is as follows:

	Temp2_ A0, T_ MD;
	Temp1_ A0, Cnt_ 17S;
	Temp1_ Flush_ Temp1, Carry20, Branch[., Cnt#0&-1];
	Temp1_ A0, Cnt_ 17S;
	TaskingOff;
	Temp1_ Flush_ Temp1, Carry20, Branch[., Cnt#0&-1];
	RMap_ Temp2;
	PD_ (Temp2)-1, TaskingOn;
	PD_ PRef, Branch[., ALU<0];	* wait for MapBufBusy

followed by reading the Pipe.

The double flush and tasking off is required for operations that write the map, since they must be made atomic with respect to I/O device activity.  (The first flush, with tasking on, is done to get rid of all the dirty victims, which take much longer to flush than clean victims.)  However, for GetF, concurrent I/O activity is not an issue.  All that is necessary is to ensure that any flags that were set (in map or cache) prior to the start of the GetF are reliably captured in the result.  It is the software's responsibility to deal correctly with concurrent I/O activity if any is possible (which I believe it is not in the case under consideration).

I have been over this with Ed Fiala and Ken Pier, neither of whom understands Flush_ very well.  We are especially puzzled when we look at the Dorado memory paper and see that Flush_ gives rise to two map cycles, one of which is called FlushFetch which neither Ed nor Ken ever heard of.

I have two conjectures which you might consider; perhaps you have other ideas about what is going on:

  (1) When the RMap_ is executed, the last Flush_ might not yet have completed.  That is, the map cycle for RMap_ might precede the map cycle for Flush_ in which the cache flags are written into the map.

  (2) Flush_ doesn't work reliably due to some bug, and the bug is circumvented by doing the flush twice.

What do you think?

	Ed

*start*
00656 00024 US 
Date: Fri, 28 Oct 83 09:41 PDT
From: Fiala.PA
Subject: Flush_ and Map_
To: Lampson
cc: Pier, Taft, Fiala

One of the documented restrictions on Map_ is that a Store_ must not still be in progress when the Map_ starts.  After rereading the Dorado HW Manual sections on this several times, my feeling was that this refers to a Store_ by the emulator only.  However, when you check into what made Taft's GetF opcode fail, you might wish to investigate the possibility that a Store_ by some other task immediately before the Map_ is not allowed.

I seem to recall a problem like this several years ago, but I can't recall the details.

*start*
01207 00024 US 
Date: Wed, 26 Oct 83 12:48 PDT
From: Taft.PA
Subject: Dorado microcode once again
To: Cedar5Implementors^, AlpineImplementors^
Reply-To: Taft.PA

I have released yet another new version of Dorado microcode in an attempt to fix the "disk label check" problem.  I have some confidence that I've really fixed it this time; but extensive testing is require to make sure.  Therefore, please again install the new microcode on your Dorado.  If you still see "disk label check", or your machine halts, please notify me right away.

The procedure is the same as before:

1. Use Othello's "Pilot microcode fetch" command to retrieve the file [Indigo]<PreCedar>Top>DoradoCedar.eb onto the Othello volume.  To the question "Shall I use this for the physical volume?", answer "Y".

2. Boot the new microcode by a 3-push boot with "P" pressed down.

3. IF YOU WERE ALREADY RUNNING the PreCedar microcode, use Othello's "Scavenge" command to scavenge your Client volume (this takes about 10 minutes).  Then Boot Client and re-make your checkpoint.  This is very important, because the old PreCedar microcode may already have messed up your file system in ways that haven't been detected yet.

	Ed
*start*
00713 00024 US 
Date: Tue, 29 Nov 83 17:17 PST
From: Taft.PA
Subject: New Dorado microcode
To: Cedar5Implementors^
Reply-To: Taft.PA

This version fixes an obscure bug in the ALLOCATE opcode: if it was asked to allocate a block of exactly 1076B words, it would occasionally cause an address fault. There are no other changes.

The procedure is as usual:

1. Use Othello's "Pilot microcode fetch" command to retrieve the file [Indigo]<PreCedar>Top>DoradoCedar.eb onto the Othello volume.  To the question "Shall I use this for the physical volume?", answer "Y".

2. Boot the new microcode by a 3-push boot with "P" pressed down.

There is no need to reinstall the debugger or re-make the checkpoint.

	Ed

*start*
00864 00024 US 
Date:  6 Dec 83 13:34:16 PST
From: vanLeunen.pa
Subject: Re: New Dorado microcode
In-reply-to: "Your message of Tue, 29 Nov 83 17:17 PST"
To: Taft
Cc: vanLeunen

Groan -- would you believe I've been so busy editing memos to management that only yesterday did I get around to installing the new microcode?  And what if I had tried during that time to allocate a block of exactly 1076B words?  Honestly, it's getting to be hard to get any work done around this place ...

Anyway, I thought you might want to keep around the following piece of boilerplate for future microcode-release messages:

1.  Boot Othello

2.  Open Indigo

3.  Pilot RD0:Othello <PreCedar>Top>DoradoCedar.eb

4.  Y     (This is in response to the question "Shall I use this for the physical volume?")

5.  Boot the new microcode by a 3-push boot with "P" pressed down.
*start*
01270 00024 US 
Date: Mon, 16 Jan 84 13:03 PST
From: Evans.pasa
Subject: Host Number
To: Taft.pa
cc: Evans

Thanks for the info the other day.  I now have it so that the following sequence will get the number into the Dorado.  I would like your opinion as to any microcode problems this method may have. 

1.	Write to the Ethernet control reg (say a do nothing of all zeros) to reset the counter to the start of the host number.

2.	Read the status six times and the six bytes of the host number (in a prom) are read in the upper byte of the status word.  Each read of status increments the prom address at the end of the read. TIOA for the status and the control reg are the same.

I think that the seventh byte should be a checksum for the microcode just to catch errors as the parity for each byte is not from a prom.

In looking around for what to fill up the space on the board with--if there is time later-- Dave Rumph (Dale Green's group) suggested floating point.  AMD has a new fast chip that will be out near the end of the year and there are the Weitec chips used on the DLion.  Do you know where I might find the current microcode FP speed to get an idea as to whether this may be worth doing?  What are your thoughts on the subject?

Thanks,
Bill 

*start*
03567 00024 US 
Date: Tue, 17 Jan 84 15:33 PST
From: Taft.PA
Subject: Re: Host Number
In-reply-to: "Your message of Mon, 16 Jan 84 13:03 PST"
To: Evans.pasa
cc: Taft

Your proposal for reading the Ethernet address sounds fine.

There's no question that adding floating point hardware would speed up real arithmetic considerably. Commercially available chips can do most floating point operations in considerably less than a microsecond. The time require to load the operands and read the result should not add more than half a microsecond (for 32-bit values). In comparison, the current microcoded instructions have the following execution times on the Dorado: add: 3.1 microseconds, multiply: 5.9, divide: 9.4.

The main thing to worry about in designing a floating point unit as a Dorado I/O device (as opposed to something integrated into the processor) is to accomplish the communication with the minimum possible number of microinstructions. I suggest something along the lines of the following scheme.

The device responds to a group of TIOA values, one for each operation (add, subtract, multiply, etc.). The two 32-bit operands are arranged as a block of 4 16-bit registers with an automatically-incremented address register. Doing an Output to any of the device's TIOA values causes the current register to load from the I/O bus and the address register to increment. When the last register has been loaded, the operation selected by the TIOA value is started, and the result appears in another 32-bit register. Two successive Input operations then read the two halves of this register, and the device is reset in readiness for the next operation.

With this organization, the microcode for, say, the floating add instruction looks like this:

	T_ xx; * TIOA value selecting Floating Add
	TIOA_ T;
	Output_ Stack&-1;
	Output_ Stack&-1;
	Output_ Stack&-1;
	Output_ Stack; * This causes the operation to start
	... wait long enough for operation to complete ...
	Stack&+1_ Input;
	Stack_ Input, NextOpcode;

This requires 8 microinstructions or 0.5 microseconds in addition to the time required for the floating point operation to occur. Note that the operation time has to be precisely predictable so that the correct number of no-ops can be inserted. Having to poll a completion flag or something could add considerably to the total overhead. (Alternatively, you might explore using the IOHold mechanism to automatically delay the first Input instruction until the result is ready. Nobody has ever used IOHold before, so I don't know how tricky this would be.)

Needless to say, it is important that the hardware be organized to accept the argument words and produce the result words in the correct order! This requires close consultation with the designers of the language system you are trying to optimize for.

This arrangement could be extended to accomodate 64-bit numbers, though I don't think any of our programming languages are prepared to take advantage of them.

Note that I have been assuming that the operands are provided by the processor and the results returned to it for each operation. Obviously, an arrangement involving on-board "floating point accumulators" could significantly reduce overhead, since computations requiring multiple floating point operations could be chained together without communicating intermediate results to and from the processor. However, integrating this into Mesa would be quite difficult, and I suspect our other languages would have equal difficulty in taking advantage of such an arrangement.

	Ed

*start*
00965 00024 US 
Date: Wed, 1 Feb 84 09:02 PST
From: Evans.pasa
Subject: Tasks & TIOA
To: Taft.pa
cc: Evans

Ed,

You consulted a list of assigned tasks that day in your office--where might I find a copy of that list?  I plan on puting the board at 10b and 12b as they differ by one bit.   The DskEth board required that the Ether tasks be even odd to make the IOAttention correct thus it is a simple logic change to move the bit which determines the task.  Its not clear that I want to understand that page of logic any more than to do that.

Also where is there a list of assigned TIOA's?  I need to assign 8 to this board.

Based on your comments I added tasking to the DES.  It will not drive it at max speed as there is no input FIFO (needs one more holding reg. to get max speed) but at least the microcode would be simple if it is used.  I used the "lower wakeup on TIOA=me" type given in the hardware manual as it takes little logic.

Thanks,
Bill 

*start*
00521 00024 US 
Date: Wed, 1 Feb 84 09:38 PST
From: Taft.PA
Subject: Re: Tasks & TIOA
In-reply-to: "Your message of Wed, 1 Feb 84 09:02 PST"
To: Evans.pasa
cc: Taft

The assigned task numbers and TIOAs are listed on pp. 85-86 of the Dorado Hardware Manual. I suggest you insert a platform with four jumpers between the Next bus receivers and the XOR gates. This will make it possible to change the task assignments to any pair differing by one bit simply by changing the jumpers and/or the task number SIP.

	Ed