*start*
00609 00024 US
Date: 2 Jan 1980 12:05 pm (Wednesday)
From: DIEBERT.PA
Subject: Factory recall of Dorado #3
To: DoradoUsers↑
cc: DIEBERT
Just a little note to tell you all of a factory recall of Dorado #3. This is to fix an
overheating problem caused by a defective dowatchit. The factory tells us that
this fix may take a while, and that a replacement Dorado will be provided as
soon as possible. (Tomorrow??)
Tim
Ps. The disk on the new Dorado will be the same as the old one. However users
should be cautious. Also please note that the replacement Dorado has a different
S/N when using MIDAS.
*start*
01639 00024 US
Date: 23 Jan 1980 9:54 am (Wednesday)
From: DIEBERT
Subject: Dorado Status
To: Ornstein
cc: DoradoCore↑
The following summarizes the status of all of our Dorados as of 5:15 pm Jan 22,
1980. I thought you would like to know.
S/N 6 in alcove
Running
needs;
IFU Ce to Cf rework
ProcL Cg to Ch rework (currently done with blue wire)
S/N 4 in alcove
Running
needs;
cooling fixes
ProcL Cg to Ch rework (has blue wire for task switch but not HOLD fix)
Has rev Bh IFU with blue wire fix
S/N 2 in lab
Running
needs;
Final cooling mechanical hardware (has prototype)
ProcL Cg to Ch rework (has blue wire for task switch but not HOLD fix)
Has rev Bh IFU with blue wire fix
S/N 3 in lab debug (mostly multiwire)
Runs Kinetic4 and Ethernet Test (BCPL) using non IFU microcode @ 33ns.
needs;
ProcL Cg to Ch rework (no blue wires at this time)
IFU rev Cf in debug it appears that there maybe some problem also on
MemD.
MemX (mw) needs debug. (now using a SW MemX)
Speed problems will be looked at as soon as IFU and mw MemX run MESA or
some other IFU based emulator.
In general, last weekend was a desaster to the debug of the multiwire Dorado.
The casualty list includes:
2 IFU's: 1 with a cold flow wire and 1 with a dead IFUM bit that the micro
diagnostics could not catch but MIDAS did.
1 DISKETHER with a bad CRC generator/checker on the Ether side.
1 dead Trident drive with a bad read amp/detector board.
All of these problems were finally fixed yesterday afternoon.
Questions or comments welcome
Tim
*start*
00334 00024 US
Date: 25 Jan 1980 11:53 am (Friday)
From: DIEBERT
Subject: Updated BuildStandards Memo
To: DoradoCore↑
A new version of the BuildStandards memo has been stored on IVY<DoradoDocs>.
This includes updates made by Ed Taft to include Multiwire rework and
generation of the resist files.
Tim
PS. Thanks Ed Taft
*start*
00913 00024 US
Date: 26 Jan 1980 7:23 pm PST (Saturday)
From: Taft
Subject: Overflow
To: Fiala
cc: DoradoCore↑, Taft
Upon careful investigation, I have concluded that Overflow' is the primary
branch condition and Overflow is the complementary branch condition. This is
correctly defined in the current D1Lang and in the current (Oct. 79) hardware
manual, but incorrectly defined in the version D1Lang included as an appendix
to the current (Feb. 79) Microassembler manual.
It is also incorrectly shown in the hardware drawings (ProcH and ContA). The
signal labelled Overflow' should in fact be labelled Overflow. The signal
labelled SignedCarry has the correct sign, though its name isn't very helpful;
perhaps it should be renamed dOverflow.
I get confused every time I think about Overflow, and I think it's important that
all the documentation be made consistent to avoid future confusion.
Ed
*start*
00562 00024 US
Date: 4 FEB 1980 0938-PST
From: MCDANIEL
Subject: there are new diagnostics
To: Dorado Core Group:
There is a new version of all the diagnostics; the "left hand" machine
in the lab has been updated. There are various additions to the ifu
diagnostic -- more patterns and an addressing test. The "restart" code,
after it re inits various values in postamble, begins execution in the
target diagnostic at a lable known as restartDiagnostic. This enables each
diagnostic to perform diagnostic-specific reinitialization.
gene
-------
*start*
00888 00024 US
Date: 14 Feb 1980 9:10 am (Thursday)
From: DIEBERT
Subject: Interium Multiwire Speed
To: Ornstein
cc: DoradoCore↑
For the time being, since we have not yet received all of the Multiwire boards to
build a machine, I would like to propose the following speed limitations.
1) The machine run @30 ns in it's closed state for 15 min. minimum running
MESA et al Any time longer than this is fine however T parity errors occur at
random and ST errors occur at random.
2) The machine be required to run @ 31 ns. for at least 24 hrs. running MESA et
al.
3) The machine be shipped to run @ 32 ns.
Complete microcode failure occurs @ 29 ns due to RBypass logic so running
faster is at this time is impossible.
Comments welcomed.
Tim
PS The machine has run for 2 days @ 32 ns & over night @ 31 ns. It has also
run @ 30ns for up to 4 hrs. and for as short as 20 min.
*start*
00331 00024 US
Date: 14 Feb 1980 3:07 pm (Thursday)
From: Ornstein
Subject: Re: Interium Multiwire Speed
In-reply-to: Your message of 14 Feb 1980 9:10 am (Thursday)
To: DIEBERT
cc: Ornstein, DoradoCore↑
Based on what I understand, that sounds realistic. Let's go with it unless we get
helpful other suggestions.
Severo
*start*
00700 00024 US
Date: 14 Feb 1980 3:27 pm (Thursday)
From: DIEBERT
Subject: AMP Visit & Problem Determination
To: DoradoCore↑, Haney
The AMP guy was here from Harrisburg today and looked at the problem with
thin boards not making good contact. The net result of that meeting was that we
are not getting the connectors clean enough to make good contact on the thin
boards. We have now been trained in the proper cleaning techneques and IF
everything stays clean we should not have anymore problems with thin boards.
Multiwire will be contacted soon to resolve a good method to prevent delivery of
thin boards in the future, so I do hope the connector thing is solved as best it
can.
Tim
*start*
01009 00024 US
Date: 18 Feb 1980 10:04 am PST (Monday)
From: Taft
Subject: Setting the Dorado speed
To: Ornstein, Diebert
cc: DoradoCore↑
We are now in the situation of having machines delivered to run at different
speeds: the stitchweld machines at 28 and the multiwire machines at 32. At the
moment, the machine speed is set by the command files that load the emulators,
and there is one set of command files for SW machines and another set for MW
machines. This is madness and will cause endless confusion.
I suggest either of the following solutions:
1. Run all machines at the same speed, i.e., 32.
2. Remove the setting of machine speed from the command files, and instead
leave that entirely up to the BaseBoard.
(1) has the virtue of simplicity. (2) is workable so long as BaseBoards aren't
switched around and we are willing to tolerate having different EProm programs
in different machines.
I advocate (1) but am willing to settle for (2). Comments or alternative proposals?
Ed
*start*
00763 00024 US
Date: 18 Feb 1980 10:45 am (Monday)
From: DIEBERT
Subject: Re: Setting the Dorado speed
In-reply-to: Your message of 18 Feb 1980 10:04 am PST (Monday)
To: Taft
cc: DoradoCore↑
Ed
Your comments are welcome. I don't really care if the machines are run at a
slower speed, or if there are 2 command files. For the moment the only place the
2 different command files exisit is on the MIDAS disk that is on the ALTO for
controlling #3 while in the lab. The overall command file structure for the
future is yet to be determined and input from all Dorado Core members is urged
and welcomed.
Tim
PS my own feeling is to run all machines at the same speed rather than your
baseboard clock set due to board swapping restrictions on baseboards.
*start*
00811 00024 US
Date: 18 Feb 1980 11:00 am (Monday)
From: DIEBERT.PA
Subject: PreRelease of Dorado #3 (Multiwire Proto)
To: DoradoUsers↑
I am pleased to announce the prerelease of Dorado #3 located in the Dorado lab
for use by users. This machine is in the final stages of debug and therefore may
not be as relable or as available as alcove machines, therefore use scheduling
should be on an as available basis rather than the conventional sign up sheet
method. It should also be noted that temporarily there are 3 new MENU selections
under the MIDAS selection RUNPROG that are for use only with #3. They are
MWMESA, MWLISP and MWSMALLTALK. Please use these command files
rather than the normal ones for the time being. Like with all Dorados please let
Herb, Charlie or me know of any problems.
Tim
*start*
00412 00024 US
Date: 18 Feb 1980 3:04 pm (Monday)
From: Ornstein
Subject: Re: Setting the Dorado speed
In-reply-to: Your message of 18 Feb 1980 10:45 am (Monday)
To: DIEBERT
cc: Taft, DoradoCore↑
I also vote for a common speed of 32ns. People are always permitted to speed at
their own risk and if they know they've got their mitts on a Ferrari and can
outrun Murphy, let them put it to the firewall.
*start*
00300 00024 US
Date: 18 Feb 1980 4:43 pm PST (Monday)
From: Boggs
Subject: Re: Setting the Dorado speed
In-reply-to: Taft's message of 18 Feb 1980 10:04 am PST (Monday)
To: Taft
cc: Ornstein, Diebert, DoradoCore↑
I vote for setting all machines at the slower speed (alternative 1)
/David
*start*
00531 00024 US
Date: 21 Feb 1980 9:44 am PST (Thursday)
From: Diebert
Subject: MIDAS Files for Dorado
To: Fiala
cc: DoradoCore↑
Ed
It appears that the proper way to handle Multiwire and Stichweld speed
incompatabilities is to run all of the machines at 32ns. Would you in the next
MIDAS release please update all of the command files that specify a machine
speed setting to set the speed to 32ns rather than the present 28ns. The files I
know of are LISP, MESA and SMALLTALK, although there may be others.
Thanks
Tim
*start*
00809 00024 US
Date: 25 Feb 1980 9:33 am PST (Monday)
From: Diebert.PA
Subject: The Dorado Shuffle
To: DoradoUsers↑
This is to inform all of you that we will be swapping a few Dorados around
today in hopes of putting some necessary modifications into Dorado #6
(currently in the alcove). The way this will work is as follows.
1. #6 will be moved from the alcove into the lab area for some cooling mods.
2. #2 will be moved from the lab into the alcove where #6 used to be.
3. #6 when the mods are complete will be reinstalled in the nursery this
afternoon, barring any disaster.
The entire operation should take only this morning. The users who signed up for
#6 today or tomorrow may have to retrieve thier files from thier backup source
when they use #2 as the disks are not the same.
Tim
*start*
00871 00024 US
Date: 25 Feb 1980 12:04 pm PST (Monday)
From: Taft.PA
Subject: New Midas command files & Mesa microcode
To: DoradoUsers↑
I've revised the Midas command files for the standard emulators (Mesa, Lisp,
Smalltalk) to set the clock to 32 ns, as required for the new MultiWire machines.
I've also released a new version of the Mesa microcode; it is the one that has
been called NewMesa for some time, and contains bug fixes and performance
improvements. This microcode is dumped in [Ivy]<Dorado>DMesa.dm, and
sources are in [Ivy]<DoradoSource>DMesaSources.dm and AEmuSources.dm.
I have updated the emulators on every Midas disk I could find. I've also created
a new command file, [Ivy]<Dorado>UpdateEmulators.cm, which updates all the
emulators by reloading them from the standard .dm files (DMesa.dm, XLisp.dm,
and DSEmu.dm) on [Ivy]<Dorado>.
Ed
*start*
00349 00024 US
Date: 17 Mar 1980 12:25 pm PST (Monday)
From: Diebert
Subject: DoradoBoard Revs
To: DoradoCore↑
There is a document on [IVY]<DoradoDrawings>RevStatus.press which describes
what I believe to be the current board rev info for your viewing. Please verify
the information present and report any errors to me.
Thanks Alot
Tim
*start*
00585 00024 US
Date: 30 March 1980 5:54 pm PST (Sunday)
From: Taft
Subject: BMux sex and VAHi unused bits
To: Diebert, Fiala
cc: DoradoCore↑
I don't know whether anyone cares at this late stage but...
(1) The backpanel BMux.xx signals are all low-true, despite the sex implied by
their names in drawings and backpanel lists. This had me really confused for a
while, as I was trying to determine:
(2) The unused bits of VAHi (bits 0:3) read out as ones, rather than zeroes as
you might expect. (This is more-or-less a consequence of (1).) This should be
documented.
Ed
*start*
01732 00024 US
Date: 30 March 1980 8:57 pm PST (Sunday)
From: Taft.PA
Subject: Mesa microcode
To: DoradoUsers↑
I have released a new version of the Dorado Mesa microcode, which includes the
following changes:
1. The Dorado now uses Alto-I clock format so as to be consistent with the D0.
Associated with this change is a new pre-release of OS 18, which may be
obtained from [Ivy]<Boggs>OS18>NewOS.boot (etc.) This change will only affect
programs that use the OS's Timer procedure, or otherwise make use of the low
bits of RCLK.
2. Page faults and stack errors now trap through the appropriate entries in SD
(sPageFault or sStackError) rather than causing the machine to halt. If you don't
install the necessary fault procedures in SD, page faults and stack errors will
turn into ControlFaults, but at least you will still land in the Mesa debugger.
3. The "MGO hack" is gone. This means that older versions of XMesa will no
longer be able to find more than 64K of memory. I'm informed that the correct
version to be running on Dorados nowadays is [Ivy]<XMesa>Temp>XMesa.image.
4. Midas's "Run-Program" menu now includes MESA and CEDAR. At the
moment, MESA and CEDAR are identical except for their default disk partitions
(MESA=1, CEDAR=4). I intend to keep MESA and CEDAR the same, until such
time as the Cedar system requires changes that are incompatible with regular
Mesa. (Please ignore NEWMESA, unless I tell you otherwise.)
I've updated all the Midas disks I could find, but if you ever suspect that you
have stumbled upon obsolete microcode, it's always acceptable to type
"@UpdateEmulators" to the Executive; this updates Mesa, Lisp, and Smalltalk
microcode from the official repository on Ivy.
Ed
*start*
01195 00024 US
Date: 4 April 1980 1:03 am PST (Friday)
From: Schmidt.PA
Subject: An Unhappy Dorado User
To: doradousers↑
Tonight, almost exactly at midnight, I was working on the Dorado near
Grapevine, Dorado number 3, (in Partition 1) when I got the message
"emergency exec" from the Alto Executive. Typing commands to the emergency
exec. didn't work, I always ended up in swat, so I tried to boot, with no luck.
I scavenged but was unable to reboot the system.
I booted over "NewOs" from the netexec and was able to boot the machine
that way.
Before this happened the machine indicated >2000 free disk pages, when
I rebooted after scavenging I had only 11.
I assume I had run out of disk space and the number on the screen >2000 was
wrong.
Most of the files on the disk were gone (Garbage.$ was huge).
I infer from this that the Partition 1 disk on Dorado 3 must be remade, and
people may have lost some files (I lost four hours work).
What went wrong? What should I have done to recover without losing so many
files?
(P.S. By the way, Dorado 2 is making loud noises that sound like a dog whining
every 3-5 minutes. I don't think this is normal... but it seems to work fine.).
*start*
00949 00024 US
Date: 4 April 1980 11:59 am PST (Friday)
From: Taft.PA
Subject: Re: An Unhappy Dorado User
In-reply-to: Schmidt's message of 4 April 1980 1:03 am PST (Friday)
To: Schmidt
cc: doradousers↑
Probably the 22K-byte limit on the size of SysDir was exceeded. The Scavenger
is known to go berserk when this happens. To avoid getting burned by this,
Dorado users should follow these guidelines:
(1) Run CleanDir periodically, to keep the directory compact and find out how
big it's getting.
(2) Don't ever depend on files surviving from one session to the next -- always
back them up on a file server.
(3) When SysDir gets close to the limit, delete files as needed, and then run
CleanDir. The only files that should be left in partition 1 are standard Alto
subsystems and Mesa system image and *Defs.bcd files. Courteous users delete
their personal files before leaving, but unfortunately there aren't many
courteous users.
*start*
01598 00024 US
Date: 4 April 1980 10:48 pm PST (Friday)
From: Taft
Subject: Dorado microcode self-loading
To: DoradoCore↑
The Dorado is now able to load and start arbitrary microcode, without
intervention by the BaseBoard. Only NewMesa and AEmu presently have this
capability, but I will see about getting it installed in all the emulators in the
near future.
In the process of implementing this, I discovered several previously
undocumented restrictions/bugs/"features", which I will now set forth:
(1) It seems you have to do an IFUReset for every IFUM word you load (i.e.,
every time you change BrkIns←).
(2) IFUMLH← or IFUMRH← must follow BrkIns← or InsSetOrEvent← by at least
two cycles.
(3) The IFUM parity is even, rather than odd as the hardware manual states.
I also discovered one surprising thing having to do with the memory system. IM
loads have to be executed with tasking off and with no possibility of Hold
occurring. In one place, I had IM←MD, but I had very carefully waited for Hold
by doing a ←MD in a previous microinstruction. Nevertheless, the machine
malfunctioned in a way that was very suggestive of the IM←MD being held, and
when I rearranged the code to eliminate use of this construct, the problem went
away. I was quite surprised, since I had earlier believed that a second or
subsequent ←MD could never cause Hold since the data is coming from the
task-specific MD register, which is known to be valid. I'm concerned that this
could cause restrictions or problems in other microprograms as well. Does anyone
understand why this is happening?
Ed
*start*
01180 00024 US
Date: 7 April 1980 12:34 pm PST (Monday)
From: Taft.PA
Subject: Extended DCBs
To: DoradoUsers↑
cc: Johnsson, Karlton, Frandeen, Maleson, Taft
Dorados and D0s have microcode that interprets an extended form of display
control blocks (DCBs). If bit 0 of word 3 is a one, the normal bit map pointer is
ignored and instead words 4 and 5 are interpreted as a long pointer to the bit
map.
In the next release of the Dorado microcode, the long pointer will be so
interpreted only if word 2 (the normal short bit map pointer) contains a "seal"
(password) whose value is 177423B. If the seal is not correct, the display
microcode will terminate DCB processing for the remainder of the current field.
The purpose of this change is to eliminate ugly effects, such as page faults from
the display task, that occur when DCB chains tail off into garbage and the
garbage happens to look like an extended DCB; this happens in a number of
programs that don't exit in a clean way (e.g., when you shift-swat from Bravo).
If you maintain programs that use the extended DCB feature, you should
immediately modify them to write the correct seal in all extended DCBs.
Ed
*start*
00438 00024 US
Date: 10 APR 1980 0957-PST
From: CLARK
Subject: backpanel error
To: Dorado Core Group:
Folks,
The signals FastD←Dbuf and Dbuf←' on the MemC and MemD boards appear
in each other's places in some backpanel pictures. Mike has a new
backpanel picture, which is probably already in your back pocket.
Once again: the two signals just got switched. It's only a naming
problem, not a connection problem.
Doug
-------
*start*
00571 00024 US
Date: 16 April 1980 11:21 am PST (Wednesday)
From: Diebert
Subject: Multiwire DskEth Rework Instructions
To: Haney
cc: DoradoCore↑
Terry
There is now a rework document on how to rework the Rev Cd DskEths to Rev
Ce. It lives on [IVY]<DoradoLogic>DskEth-Cd-to-Ce-mwRW.sil. It also lives as a
press file on [IVY]<DoradoDrawings>DskEth-Cd-to-Ce-mwRW.press.
Of General interest the ProcL rework instruction names have been changed to
get around a problem with EMPRESS as reported to me by Charlie. The format is
now the same as the DskEth.
Tim
*start*
00345 00024 US
Date: 17 April 1980 9:30 am PST (Thursday)
From: Diebert
Subject: Multiwire ProcL
To: Haney
cc: DoradoCore↑
Terry
After having checked the new plots vs the old I see no reason not to order the
whole lot of ProcL boards, rather than ordering a YTL run for them. So you
might just call MW and release the ProcL.
Tim
*start*
00836 00024 US
Date: 17 Apr 1980 2:13 pm (Thursday)
From: Sosinski
Subject: Mw-bluewire placement
To: Haney
cc: DoradoCore↑
Terry
In regard to our earlier conversation, we have found that having bluewires
changes on the back of unsocketed boards interfere with chip replacement.
Especially those wires that traverse a large number of chip locations. As you
can see this causes unnecessary hassle of removing bluewires for changing chips
that happen to be crossed.
So I request that you put the bluewires on the top of the board and connecting
them directly to chip legs. Hence, a bluewire need only be removed when a
directly involved chip is replaced.
I believe this will allow easier installation of bluewires as well as easier
maintenance of the boards. If you find otherwise, please let me know.
Thanks Charlie
*start*
01573 00024 US
Date: 17 April 1980 6:02 pm PST (Thursday)
From: Taft.PA
Subject: Mesa & soft-bootable microcode
To: DoradoUsers↑
I have released a new version of the Dorado Mesa microcode. Its main new
feature is that it is soft-bootable on a stand-alone Dorado, without the
intervention of Midas on the umbilical Alto. This capability requires the
presence of new BaseBoard EProms, which will be installed on all machines
within the next day or two.
A power-on boot or a three-button boot, with no keys pressed down, will cause
the Mesa emulator to be booted. A three-button boot with certain keys pressed
down will cause other emulators to be booted, as follows:
C = Cedar (same as Mesa except for the default disk partition)
L = Lisp
M = Mesa (same as all-keys-up boot)
S = Smalltalk
The Lisp and Smalltalk emulators have not yet been converted to soft-bootable
format, so at present this will work only for Mesa and Cedar. Work is in
progress to update Lisp and Smalltalk emulators.
If you want to load a particular emulator and then boot the NetExec rather than
the disk, holding down the mnemonic keys along with BS and quote might
require you to have a pet octopus. Therefore, the following alternate keys are
also defined:
"=" = Cedar
"[" = Lisp
"Return" = Mesa
"Shift" = Smalltalk
The Dorado can also load and start an arbitrary emulator from a file on its own
disk, if the emulator is in the new soft-bootable form. Obtain
[Ivy]<Dorado>LoadMB.run. Then, to load and start the microcode in file Foo.mb,
simply type "LoadMB Foo.mb".
*start*
00454 00024 US
Date: 22 April 1980 9:51 am PST (Tuesday)
From: Taft.PA
Subject: Dorado booting
To: DoradoUsers↑
cc: CSL↑
I have prepared a memo containing everything you ever wanted to know about
Dorado booting, along with many things you might not care about. If you are a
Dorado user, you should read section 1, "Operation". You might also be
interested in reading section 2, "How it works".
See [Ivy]<DoradoDocs>DoradoBooting.press.
Ed
*start*
00672 00024 US
Date: 23 April 1980 9:53 am PST (Wednesday)
From: Pier
Subject: "Power Down" and "Four Push" booting
To: DoradoCore↑
Fellow Dorado Hackers-
I have noticed this last week, on three separate occasions involving three
different people (you know who you are), that we are starting to confuse the
state Dorado is in after a four push boot and the powered down state. In
particular, people have started to unlatch and remove boards WITHOUT turning
off the AC breaker, I assume believing that a four boot does the job. It doesn't.
Please remember to kill all the power (the fans will stop) before messing with
boards.
Yours for less maintenance.
Ken
*start*
00472 00024 US
Date: 23 APR 1980 1434-PST
From: STONE
Subject: D-Machine Griffin
To: DORADOUSERS:
cc: Warnock
Griffin has been updated to conform to recent changes in the micro-code.
The new version is on [maxc]<stone>DGriffin.dm. The Griffin.image
in that file will also run on D0's.
If you already have Griffin.fonts, you only need the new Griffin.image
from DGriffin.dm.
Documentation is still HowToUseGriffin.press, on [Maxc]<Stone>.
Maureen
-------
*start*
01002 00024 US
Date: 24 APR 1980 1154-PST
From: MCDANIEL
Subject: [ivy]<dorado>DoradoMesaDisk.cm & other files
To: DORADOUSERS:
On [ivy]<dorado> you will find these files:
DoradoMesaDisk.cm
DoradoMesaImageFiles.cm
DoradoMesaUser.cm
DoradoMesaDisk.cm will create a new Mesa disk on a partiton. You can use
it after ERASEing a disk partition. It fetches & initializes files for
both mesa and ime.
DoradoMesaImageFiles.cm will "refresh" the mesa image files on a Dorado
(to be used if you think that an image file is clobbered).
DoradoMesaUer.cm (renamed user.cm on Dorado disks) defaults for the
standard Mesa programmer. NOTE: there is an additional entry,
[NonProgrammerBRAVO], in this user.cm. If you change [BRAVO]
into [MesaBRAVO] and change [NonProgrammerBRAVO] into [BRAVO]
followed by "bravo/i", you will have a standard text user.cm! If you
want to do text editing, please perform this switch rather than clobbering
user.cm.
Notify me of any problems.
Gene
-------
*start*
00492 00024 US
Date: 30 April 1980 2:18 pm PDT (Wednesday)
From: Sosinski
Subject: Good mwIFU
To: Haney, Ornstein
cc: Doradocore↑
With slight efforts of installing missing SIP and scrubbing the epoxy from the
connector pins, the YOT mwIFU board worked without a hitch. It runs the IFU
diagnostics at 28ns clock for several iterations ..... until something else fails.
Mesa in the form of Tachy and Laurel run at required clock.
The eventcounters worked as well.
Charlie & Herb
*start*
00433 00024 US
Date: 30 APR 1980 1654-PDT
From: MCDANIEL
Subject: [ivy]<Dorado>Mesa.DoradoDisk
To: DORADOUSERS:
[ivy]<Dorado>Mesa.DoradoDisk is a copy of a new Mesa disk for
the Dorado. You can use the new copydisk to initialize a Dorado disk
from this file. Those who wish may still use the command file,
[ivy]<Dorado>DoradoMesaDisk.cm to initialize a dorado disk. Both mechanisms
create the same disk.
Gene
-------
*start*
01617 00024 US
Date: 1 May 1980 4:28 pm PDT (Thursday)
From: Ornstein
Subject: Dorado Locations
To: DoradoCore↑, Taylor
cc: Ornstein
If anyone sees anything wrong with the following plan or spots some
improvement, please say so. Its purpose is to get us through the summer with
minimum use of Altos for Dorado controllers and to get all Dorados into the Maxc
room. We'll worry later about terminal switches, patch panels, etc.
The idea is to mount all our user Dorados (perhaps 5 or 6 by end of summer) in
double high racks in the MAIN Maxc room - just as 10 and 11 are now.
Monitors/Keyboards (except for the Color Dorado) would be (like 10 and 11) in
suitable spots on the 2nd floor. Both the color monitor and black/white terminal
for the color Dorado would be in the FRONT Maxc room. The single controlling
Midas Alto (controlling all the Maxc Room Dorados) would be in the MAIN Maxc
room along with the Dorados, but its terminal would be in the FRONT Maxc
room along with the color Dorado terminals. The idea is that the one Alto can
serve both for microcode development (we want the color machine's terminals
nearby for that) and for hardware debugging if a Dorado dies. (clearly the latter
takes precedence when it happens). It will probably be necessary to have a
second terminal for the Alto standing by in the MAIN Maxc room to which we
would switch the Alto when doing hardware debugging.
Once the color microcode stabilizes, we will move the color machine's terminals
to an appropriate spot on the second floor. (We're checking on the cable length
feasibility and costs).
Comments?
Severo
*start*
00767 00024 US
Date: 1 May 1980 5:11 pm PDT (Thursday)
From: Willie-Sue.PA
Subject: SmallTalk and Lisp
To: DoradoUsers↑
The long awaited day has arrived - all of the Dorado emulators are now
bootable over the ethernet.
Willie Sue
p.s. For Smalltalk users only:
There is an occasional problem running the new smalltalk microcode on the
Dorado in the nursery (#4). If the display turns into horizonal lines, the rest of
the machine seems to still be working. So try to quit out of smalltalk, using the
usual method, and then go to the midas alto and reboot. Or if you are brave, at
this point try to etherboot smalltalk again, by holding down S and pushing the
boot button three (3) times.
I will be around some tomorrow and then be gone for two weeks.
*start*
00224 00024 US
Date: 1 May 1980 6:21 pm PDT (Thursday)
From: Sosinski
Subject: mw IFU
To: Haney
cc: Doradocore↑
The YOT mwIFU is acceptable and can be released for production.
Thanks for a good effort.
Charlie
*start*
01176 00024 US
Date: 2 May 1980 3:51 pm PDT (Friday)
From: Sosinski
Subject: Dorado Board Testing Problems
To: Diebert
cc: Doradocore↑
After meeting with Terry at the EMS this morning, I am convinced that
a major problem exists with the testing of Dorado boards.
The major source of problems are unknown exceptions to the resist
files. For example, the latest ProcL rev level is Ci. The changes that
make ProcL revCi different from ProcL revCh are the addition of 18 100-ohm
resistors. But the resist file Rev Ci is totally unaware of these 18 resistors.
Each board seems to have its own set of unknowns that is not in the
resist files.
Its not surprising that a recently contracted technician from the same solar
system would have difficulty performing board tests.
I would like to solicit some engineering talent to clean up this mess by; (1)
generating a pseudo-wire list and resist file that reflect the board in the real
world; or less desirably (2) creating a list of exceptions for each board that could
be used in conjunction with testing; or (3) any other solution that would
increase the validity and reduce the time of testing.
Thanks
Charlie
*start*
00680 00024 US
Date: 7 MAY 1980 1054-PDT
From: MCDANIEL
Subject: [ivy]<dorado> mesa.doradodisk0, mesa.doradodisk1
To: DORADOUSERS:
Yesterday I placed on the ivy <dorado> directory two files necessary
to initialize properly a Dorado disk: [ivy]<dorado>mesa.doradodisk0,
mesa.doradodisk1.
Use copydisk and copy mesa.doradodisk0 onto dp0, mesa.doradodisk1 onto dp1.
Previously there was only one file.
Thanks to Rick Cattell for pointing out this error.
gene
ps., as before, the command file [ivy]<dorado>doradoMesaDisk.cm can be
used to generate a new disk, too. This method takes somewhat longer than
copydisk and fetches files individually via ftp.
g.
-------
*start*
01287 00024 US
Date: 8 May 1980 6:40 pm PDT (Thursday)
From: Taft
Subject: Dorado hardware notes
To: DoradoCore↑
A couple of items that may be of general interest:
(1) The function B← RWCPReg reads a register whose load clock is asynchronous
with the Dorado. Therefore, microcode must not do anything with RWCPReg
data that depends on its being stable -- such as running it through the ALU and
testing an ALU branch condition! You must load it into a register first (RM, T,
or Q), and it's a good idea to read it twice to make sure you get the same value
twice. (Thanks to Ed Fiala for tracking this down. Charlie: this was the cause
of the suspected "IM failure" in the lab machine.)
(2) The new baseboard microcomputer code, to be installed in all machines in the
near future, will set MIRDebug during a power-on or 3-button boot. This is to
enable one to find out exactly what went wrong when bootstrap or emulator
microcode dies with IM parity errors. This shouldn't interfere with normal
microcode debugging, since loading microcode with Midas resets MIRDebug
(assuming a RESET gets done, as is ordinarily the case). But you should keep it
in mind if you ever have occasion to debug microcode that was initially loaded
via a bootstrap rather than via Midas.
Ed
*start*
00370 00024 US
Date: 12 May 1980 9:56 am PDT (Monday)
From: Clark.PA
Subject: still another revision of Dorado paper
To: csl↑, doradousers↑
A revision of the Dorado memory system paper by Butler, Ken, and me is
available as [ivy]<clark>DoradoMemPaper.press. Slightly better than the last one
(April 1980), but not very different. 30 pages plus figures.
Doug
*start*
00755 00024 US
Date: 14 May 1980 4:13 pm PDT (Wednesday)
From: Clark.PA
Subject: Use of Dorado #1
To: doradousers↑
Folks,
Gene and I are planning a bunch of hardware performance measurements of the
Dorado. For reasons obvious and obscure, the only machine on which we can do
these is Number One (nearest the CSL coffee alcove). We would greatly
appreciate it if, when possible, you would sign up for some other machine before
signing up for #1. Of course you should feel free to sign up for #1 if the
others are committed, or if you have a reason, like ours, for preferring it. In
other words, the only effect this request is intended to have is to change what
Dorado you run on occasionally, NOT to reduce your access at all.
Thanks.
Doug
*start*
00329 00024 US
Date: 19 May 1980 10:08 am PDT (Monday)
From: Sosinski
Subject: mwDISPY
To: Haney, Ornstein
cc: Doradocore↑
The YOT mwDISPY works. That is, all parts presently implemented with 7-wire
alto type display. Unless anyone has any objections, the mwDISPY should be
released for production.
Thanks
Charlie
*start*
02636 00024 US
Date: 29 May 1980 8:04 pm PDT (Thursday)
From: Ornstein.PA
Subject: Dorado News Update
To: DoradoUsers↑
cc: Taylor, Ornstein
As most of you know, we are trying to update the proceedures for allocation of
Dorados to keep up with changing requirements. This, to put it mildly, is a
challenging job. What we have decided to try out as a first cut, is to increase
the maximum allowable period for sign-up from two hours to four hours. After
some of the proposals which have been noised about, the modesty of this move
will no doubt stun some of you. We may well take further steps later on, but
want to see if this will solve at least some of the problems.
Please don't sign up for more than you need and if you must leave the machine
for a period during your time, please leave a sign indicating your expected
return. It should be fair for other users to scoop up the remainder of your time
if you leave the machine unattended for more than say 15 minutes. In short -
good citizenship, please.
The night rules have never been terribly clear. Let us consider the
early night-time (say until mid-night) as "four-hour max. chunk" sign-up time.
The hours from mid-night until 8 AM are available for longer runs. A few
people have special problems which warrant special exceptions (e.g. Eric Schmidt
who drives down from Berkeley) and I will try to deal reasonably with unusual
circumstances (demos, important production runs, etc). If you can't fit the rules
and have a special problem, please come see me.
We still have to deal with the question of special partition assignments for those
for whom swapping environments is an unreasonable burden. I would like to
meet with those of you who are concerned about this issue next Tuesday at 1:30
PM in the CSL commons. We'll try to work out a reasonable plan.
As you have probably noticed, we now have four Dorados in the Maxc room
with terminals scattered about the CSL area. The Dorado in the Nursery
temporarily has no associated sign-up sheet because we expect that a variety of
hardware uses will occupy it quite heavily for the next few weeks. Feel free to
use it if it is unoccupied but be prepared to be pre-empted by the hardware
folks. In about two or three weeks it will move down to the Maxc room. Its
terminal, together with the color monitor and the terminal for the controlling
Alto, will all be located in the front Maxc room (to permit microcode
development). At that time it will become a fifth user machine.
Thank you all for your patience in these trying times,
Da Czar
------------------------------------------------------------
*start*
01108 00024 US
Date: 3 June 1980 2:10 pm PDT (Tuesday)
From: Ornstein.PA
Subject: Dorado Partition Assignments
To: DoradoUsers↑
cc: Ornstein
The results of our little meeting are wonderfully simple. Henceforth the
partitions on the user Dorados will be as follows:
Partition 1 Mesa V
Partition 2 Smalltalk
Partition 3 Lisp
Partition 4 Mesa VI
Partition 5 Individually controlled as follows:
Dorado in Alcove L-2 (near Ornstein) Russ Atkinson
Dorado in Alcove L-4 (near Guibas) Howard Sturgis
Dorado in Alcove L-9 (near Cattell) Rick Cattell
Dorado in Alcovette (near Diebert) Doug Wyatt
At present this is merely a convenience for the Data Base guys (Cattell et al)
and for Wyatt: they can, with a bit of trouble, work on any machine. Whereas
Atkinson is really pretty completely tied to the L-2 machine - and probably
Juniper will become similarly tied to L-4 in future. So please use Alcovette and
L-9 if there's a choice.
We will review all this as needs change and new machines arrive.
Trusting this finds you all in good health and spirits,
Your friendly -
Czar
*start*
00396 00024 US
Date: 5 June 1980 8:53 am PDT (Thursday)
From: Sosinski
Subject: mwMEMX
To: Haney, Henning, Ornstein
cc: Doradocore↑
I am NOW sure that the YOT mwMEMX board works and should be released for
production. This means that all the Dorado multiwire and PC boards have been
released for full production. If you are of a different opinion, please let it be
known.
Charlie
*start*
00603 00024 US
Date: 12 June 1980 11:50 am PDT (Thursday)
From: Clark
Subject: where my Dorado stuff has gone
To: doradocore↑
Folks,
Ken now has charge of the memory system paper; see him for copies or to give
comments.
Tim has my D board stuff and the Fast IO test board disk, notebook, & etc.
Model 0 D board notebook is in the Model 0 archives.
My timing diagrams can be found on
[ivy]<doradodocs>DougsTimingDiagrams.press and .dm (for sil sources).
Gene has copies of all our measurements, and related documents and notes.
Can anybody think of anything else? Speak now, or etc.
Doug
*start*
01779 00024 US
Date: 16 June 1980 4:54 pm PDT (Monday)
From: Taft
Subject: Proposed Dorado hardware change
To: DoradoCore↑
As some of you know, there is a problem with implementing the Mesa fault
handler on the Dorado while simultaneously making use of the instruction
forwarding feature. At present, the two feasible ways of handling faults are:
(1) Restart the opcode that suffered the fault, or
(2) Save and restore the entire state of the machine.
Solution (2) requires changes to Pilot and is somewhat problematical, since an
interrupted process's state includes machine-dependent components and thereby
violates the PrincOps. Solution (1) precludes the use of the instruction
forwarding feature, because when a fault happens, there is no way for the fault
handler to find out which entry point the current opcode was entered at, and
consequently no way to adjust the stack to its canonical state.
Ken and I have determined that, with a relatively modest hardware change (8
blue wires on ContA and 2 wires on ProcH), the Dorado could remember the
entry point for the current opcode in a 2-bit register. Successful execution of an
IFUJump would load this register from the IFU entry point number in JCN[3:4],
and PD← ALUFMEM would read it out on PD[6:7]. (Unfortunately, confining
the change entirely to ContA would require substantially more blue wires.)
Can anyone poke holes in this scheme? Are there any violent objections to it?
Within the next few weeks I hope to perform some measurements to determine
the actual performance improvement gained by using the instruction forwarding
feature; this information should help in deciding whether the performance
benefit is worth the trouble of installing the necessary hardware change in all
Dorados.
Ed
*start*
00483 00024 US
Date: 16 June 1980 5:45 pm PDT (Monday)
From: Pier
Subject: Re: Proposed Dorado hardware change
In-reply-to: Taft's message of 16 June 1980 4:54 pm PDT (Monday)
To: Taft
cc: DoradoCore↑
A small addendum for you nitty gritty freaks:
The two bits are sent from ContA to ProcH over the last two remaining edge pins
on the ProcH pointy side, pins 53 and 141. Has anyone made secret use of these
pins and not had the picture in front of the manual updated??
K
*start*
01681 00024 US
Date: 18 June 1980 12:32 pm PDT (Wednesday)
From: Kolling.PA
Subject: You, too, can have your Dorado files munched.....
To: DoradoUsers↑, CSL↑, Johnsson
cc: Kolling
Eric Schmidt sent out a message about this problem when he encountered it a
while back, but, as it did not raise my consciousness high enough to prevent my
falling into the same tarpit a few days ago, perhaps a reminder will be useful:
Although each Dorado partition has a "double Model 44" disk attached, attempts
to use all of this disk can result in a trashed directory and therefore trashed
files. The problem is that the Alto exec/operating system/scavenger does not
handle a directory greater than a certain size (I am told the limit is 23000 bytes,
but Juniper's directory was destroyed when CleanDir reported 19000 bytes in
use). The size of the directory is a function of the number of files and the
lengths of the filenames.
So, if you plan to keep a large number of files on a private partition, be very
careful about approaching this limit. Also, if you use a public partition, to be
on the safe side check the directory size from time to time (use CleanDir) as
other users may have created enough files to put you near the edge of the
abyss. Once the directory is trashed, I am told that judicious use of the
scavenger, deletes, etc., is believed to be able to restore a consistent state, but I
have not yet attempted to do this.
This is an unfortunate situation,, both because the directory is destroyed without
warning and because large systems that could otherwise live in toto on the
Dorado still have to swap to and from a file server to avoid this problem.
Karen
*start*
01046 00024 US
Date: 18 June 1980 1:18 pm PDT (Wednesday)
From: Schmidt.PA
Subject: Re: You, too, can have your Dorado files munched.....
In-reply-to: Kolling's message of 18 June 1980 12:32 pm PDT (Wednesday)
To: Kolling
cc: DoradoUsers↑, CSL↑, Johnsson
Another important point if you run the scavenger on a Dorado partition:
It will ask
Shall I pretend this is a Model 31?
The correct answer is NO (type the letter 'n') since in almost all cases the
partitions are simulated model 44's which are twice as big as the Model 31's. It
will then ask if it should do both disks (referring to both simulated Model 44
disks) and the correct answer is YES (type the letter 'y').
If you answer these incorrectly the scavenger will see a different-sized disk and
garbage collect almost all of your files (I found this out by trial and error).
It is still possible to configure a Dorado partition to be composed of smaller
simulated disks, but that just wastes space and all the public Dorado partitions
are Double Model 44's.
Eric
*start*
00731 00024 US
Date: 19 June 1980 11:52 am PDT (Thursday)
From: Taft
Subject: Obscure IFU restriction
To: DoradoCore↑, Masinter
I just ran into a very puzzling IFU-related problem that turned out to be due to
my misunderstanding the rules about consuming enough ←ID bytes of a 3-byte
opcode before exiting to the next opcode. The real rule is that you must have
consumed all bytes up to and including the alpha byte BEFORE the instruction
containing the IFUJump. It does not suffice to consume the alpha byte IN the
instruction that does the IFUJump!! Failure to observe this restriction results in
bogus IFU map fault dispatches (at least, it did for me).
Thanks to Ken and Gene for helping to track this down.
Ed
*start*
00554 00024 US
Date: 23 June 1980 2:24 pm PDT (Monday)
From: Sosinski
Subject: Dorado #4 Cache
To: McDaniel
cc: Doradocore↑
The cache has been reconfigured for 16 rows. This appears to have solved the
Mesa failure sequence of @IME -- open file --- local list --Zingo cache PE.
The cache can be reconfigured to 8 rows again in about 15 minutes with some
advanced notice. The cache configuration chips for 32 and 8 rows are now in
the lab.
I don't think the users should experience any problem with this 16 row cache
configuration.
Charlie
*start*
00578 00024 US
Date: 24 June 1980 2:51 pm PDT (Tuesday)
From: ornstein
Subject: Special Little Wire
To: DoradoCore↑
The new machine that is about to go downstairs from Mike's lab will have, in
addition to the special color-monitor wiring, a wakeup from the music board (in
topmost slot) to task 5 on the CntrlA board. The music board is pacified by
IOReset and is aroused only by careful Output to TIOA 2 with funny bit foo set
- the point being it shouldn't cause anybody any trouble. This is just to inform
you. Gene knows the scoop while I'm away.
Cheers
Severo
*start*
00362 00024 US
Date: 26 June 1980 2:26 pm PDT (Thursday)
From: Johnsson.PA
Subject: Executive 11 addendum
To: CSL-D0Users↑, DoradoUsers↑
An additional feature of Executive 11 is the Partition.~ command:
Partition.~ n sets the current disk partition to n and boots. If n is omitted or
zero the command reports the current partition number.
Richard
*start*
00430 00024 US
Date: 2 July 1980 12:16 pm PDT (Wednesday)
From: Pier
Subject: Dorado display documentation
To: DoradoCore↑
cc: Yeary, Pier
I have just submitted DoradoDisplayController.press to the CSL notebook directory
<CSL-Notebook-Entries>. This document contains a detailed description of the
controller and has microcode in the appendix.
Herb and Charlie: please get a copy and look it over before our class.
K
*start*
00305 00024 US
Date: 2 July 1980 12:37 pm PDT (Wednesday)
From: Deutsch.PA
Subject: New release of Micro
To: Micro↑
The 7-1-80 release of Micro, now on [Maxc]<Alto>, fixes a minor bug which
caused REPEAT statements to chew up free storage under some circumstances.
There are no other changes.
*start*
01639 00024 US
Date: 3 July 1980 6:00 pm PDT (Thursday)
From: Taft
Subject: IFU hardware bug
To: McDaniel, Ornstein, Sosinski, Yeary
cc: DoradoCore↑, Rovner
The flakey behavior of Willie Sue's ISpy/Cedar/Mesa 6 test turned out to be due
to a bug in the IFU. To prevent interrupts from occurring immediately after
XFER and certain other opcodes, a Reschedule request is deferred until after
execution of the next "successful" IFUJump, i.e., one that does not result in some
other trap such as NotReady. The bug is in the recognition of a "successful"
IFUJump -- it is simply computed incorrectly.
The fix (for Rev C IFU boards only) is as follows:
Break chip leg b22.5 (Exception)
Wire i16.3 - b22.5 - b52.8, creating a new net ExceptionDispatch
This new signal comes from the unused output of the MC231 at i16.3, which
presently generates ExceptionDispatch'. Interestingly, this chip seems to have
been added during the last throes of Event Counter debugging; apparently,
counting "successful IFUJumps" was a problem there also.
This fix is required for reliable operation of Mesa programs that use nested local
procedures; there is no way to microprogram around the bug. I have installed
the fix in Dorado #4 (IFU #106). Charlie and Herb, please install this fix in all
other Rev C IFUs (stitchweld and multiwire).
There is no straightforward equivalent fix to the Rev B IFUs, as far as I can tell.
But given the imminent demise of these boards (mid-July, according to a
message Severo sent me a month or so ago), we should not worry about them.
Are the replacement IFUs still coming along according to plan?
Ed
*start*
00799 00024 US
Date: 5 July 1980 10:31 am PDT (Saturday)
From: Deutsch.PA
Subject: Release of MicroD 9.6
To: Micro↑
MicroD 9.6 is now released on [Maxc]<Alto>, with the following changes:
- The error message for conflict between +1 (conditional or call) constraints gives
more information.
- DblCall now places correctly, although conditional Call still doesn't work.
- If a CSMap file is requested, it is produced even if placement fails, showing
those instructions which were placed successfully.
- If there are undefined symbols, MicroD tells you where the references to them
are.
- There is a new feature, not visible to users, which allows automatic placement
of most dispatch tables. The Micro constructs for using this feature are being
designed and will be announced separately.
*start*
00381 00024 US
Date: 7 July 1980 9:45 am PDT (Monday)
From: Pier
Subject: Re: IFU hardware bug
In-reply-to: Taft's message of 3 July 1980 6:00 pm PDT (Thursday)
To: Taft
cc: McDaniel, Ornstein, Sosinski, Yeary, DoradoCore↑, Rovner
Now, that's what I call debugging!! But, surely, nested local procedures are not
new to Mesa 6 (??). Why hasn't this reared up before??
K
*start*
00601 00024 US
Date: 7 July 1980 9:54 am PDT (Monday)
From: Deutsch.PA
Subject: New release of Micro
To: Micro↑
The new (7-7-80) release of Micro fixes a glitch which usually made 16-bit
listing mode not work. It also incorporates a new builtin: WHILE[expression,
statement] repeatedly processes the statement as long as evaluation of the
expression yields a non-zero value. The expression is evaluated first before
processing the statement, as one should expect. The BUILTIN number for WHILE
is BUILTIN[WHILE, 54]; this should be incorporated in D0Lang and D1Lang in
the near future.
*start*
00948 00024 US
Date: 8 July 1980 8:22 pm PDT (Tuesday)
From: Deutsch.PA
Subject: MicroD 9.7
To: Micro↑
This release of MicroD contains three changes:
1) A glitch introduced in 9.6, which caused all IM locations to be flagged with
"@" on the .DLS listing, was fixed.
2) A new global /E switch ("map of Every location") causes a file xxx.cschart to
be produced, which gives a map telling what file occupies each location in IM.
This file is identical to the one currently produced by SDD's CSChart program,
which can therefore be decommissioned.
3) A new global /H switch ("for Hardware debugging") produces a listing of IM
sorted by absolute location giving the file and symbolic address for each word.
This is useful when things are so thoroughly or subtly wrong that Midas is
unusable and a logic analyzer must be employed.
I do not intend to go through another release cycle of MicroD for at least two
months, aside from bug fixes.
*start*
00547 00024 US
Date: 10 July 1980 3:21 pm PDT (Thursday)
From: Suzuki.PA
Subject: Flaky Dorado 2
To: DoradoUsers↑
cc: Suzuki
Some Smalltalk and Lisp users on Dorado2 have been suffering from the problem
of not being able to boot the machine. The solution to this problem is as follows:
1. Call NetExec. First go to partition 2.(Either press down s and boot three times,
or type par 2 in Mesa partion.) Then press (bs)&' and boot.
2. Then call Scavenger.
If 2 does not work, then
3. Call NewOs from NetExec and Install Exec.
Nori
*start*
03184 00024 US
Date: 11 July 1980 3:22 pm PDT (Friday)
From: Taft.PA
Subject: Mesa microcode release
To: DoradoUsers↑
A new version of the Dorado Mesa microcode is released. It is supposed to be
entiely upward-compatible from the old microcode; if you discover any problems,
please let me know.
New features are as follows:
1. Process/monitor primitives are now implemented in microcode rather than
trapping to Nova code. This means that programs using these primitives should
run faster; also, it is now possible to use LONG POINTERs to monitored records or
condition variables.
2. Floating point opcodes are defined; however, at present these opcodes are not
implemented by microcode but rather trap to the software implementation.
3. Microcode to drive a color display is included; the interface is described in
[Ivy]<Pier>DoradoColor.press, and Joe Maleson has some Mesa procedures that
make use of it.
4. The Alto Emulator's VERS instruction has been extended to include an
indication of what emulator configuration is present running. If the
"engineering number" field in bits 0-3 contains 4 (for D0) or 5 (for Dorado), then
the "build number" field in bits 4-7 is taken over to indicate one of the
following:
0 Alto emulator only
1 Alto Mesa
2 PrincOps Mesa
3 Cedar Mesa
4 Lisp
5 Smalltalk 76
6 Smalltalk 78
Other emulators for both Dorado and D0 will incorporate this convention in the
near future.
The remainder of this message is of interest only to Dorado microprogrammers.
5. A new [Ivy]<DoradoSource>D1Lang.mc is released. In conjunction with the
recently released versions of Micro and MicroD, the following new features exist:
(a) Automatic placement of dispatch tables up to 20 (octal) long is now available
via the DISPTABLE placement macro, which must appear before or in the first
statement of the dispatch table.
DISPTABLE[LENGTH, MASK, VALUE];
begins a dispatch table consisting of the next LENGTH microinstructions in-line.
The first instruction is placed such that (its address AND MASK) = VALUE, and
subsequent instructions are placed consecutively. If MASK is omitted, it defaults
to (the next power of 2 >= LENGTH)-1; if VALUE is omitted, it defaults to zero.
Thus:
DISPTABLE[10];
starts a 10-instruction dispatch table beginning on a 10-instruction boundary;
DISPTABLE[4, 7, 4];
starts a 4-instruction dispatch table with the first instruction at 4 mod 10;
DISPTABLE[1, 1, 1];
forces the current instruction to be at an odd location. It is required that the
following be true: LENGTH <= 20, LENGTH+VALUE <= 20, MASK < 20, and
(VALUE AND MASK) = VALUE.
(b) The SCALL, DBLSCALL, and SCORETURN branch clauses have been
activated; in conjunction with the RETURN[branch condition] clause, this
enables subroutines to have skip and non-skip returns. See section 33.2 of the
Dorado Microassembler manual for details.
(c) A new stand-alone clause CNT-1 decrements the CNT register by executing
the CNT=0&-1 branch condition (as an FF) purely for its side-effect. The
successor instruction must be constrained by the programmer to lie at an odd
location, e.g., by DISPTABLE[1, 1, 1] appearing in that instruction.
*start*
00460 00024 US
Date: 20 July 1980 10:30 pm PDT (Sunday)
From: Deutsch.PA
Subject: Compiling Lisp into microcode on the MIT Lisp Machine
To: Micro↑, Lisp↑
On [Maxc]<Deutsch>mcdoc.txt you will find a preliminary writeup on a compiler
written at MIT which compiles a surprisingly large subset of Lisp into microcode
on their Lisp machine (which SSL now has two of). For more info, you might
want to contact the author, Richard Greenblatt (RG@MIT-AI).
*start*
00508 00024 US
Date: 21 July 1980 1:11 pm PDT (Monday)
From: Deutsch.PA
Subject: Release of MicroD 9.9
To: Micro↑
This release, now on <Alto>, improves a couple of particularly obscure error
messages. In particular:
1) On the D0, a cross-page jump with an incorrect or missing LoadPage will tell
you the location of the jump instruction.
2) When a group (on the D0, an entire page) of instructions can't be placed,
MicroD will attempt to identify a small cluster of instructions as the obstacle.
*start*
00210 00024 US
Date: 21 Aug. 1980 1:22 pm PDT (Thursday)
From: Sosinski.PA
Subject: Dorado#5
To: DoradoUsers↑
Dorado #5 is now back in service. Thanks for nine days of quiet perseverance.
Charlie
*start*
00536 00024 US
Date: 21 Aug. 1980 3:24 pm PDT (Thursday)
From: Willie-Sue.PA
Subject: new microcode
To: DoradoUsers↑
A bug in the mesa microcode that interacted adversely with a
non-feature in the dorado disk controller has been fixed. This caused Mesa6
disks to get trashed from time to time. Please be sure you (ether)boot new
mesa/cedar microcode when using a Dorado. If you have any trouble or witness
any anomolous behavior, get in touch with me directly, as well as sending a
report to DoradoSupport.
Willie-Sue
*start*
00299 00024 US
Date: 21 Aug. 1980 5:09 pm PDT (Thursday)
From: Pier.PA
Subject: Re: new microcode
In-reply-to: Willie-Sue's message of 21 Aug. 1980 3:24 pm PDT (Thursday)
To: DoradoUsers↑
New microcode hereby rescinded. Sorry for any inconvenience. Proceed as usual
until further notice.
*start*
00511 00024 US
Date: 26 Aug. 1980 4:22 pm PDT (Tuesday)
From: Taft.PA
Subject: Dorado Mesa microcode
To: DoradoUsers↑, "@[Ivy]<Cedarlib>Real>Users.dl"
A new version of the Dorado Mesa microcode is released. It fixes a bug that
caused occasional disk failures when running Mesa 6. It also incorporates
revised floating point microcode that is incompatible with the previous version.
Programs that use floating point must be re-bound with the just-released version
of [Ivy]<CedarLib>Real>Reals.bcd.
*start*
00265 00024 US
Date: 26 Aug. 1980 8:13 pm PDT (Tuesday)
From: Deutsch.PA
Subject: D*-compatible DDS
To: DoradoUsers↑, D0Users↑
cc: McJones
DDS 1.18.1 is now available on Maxc. It runs on Dorados and Dolphins as well as
on all known Alto configurations.
*start*
00392 00024 US
Date: 28 Aug. 1980 7:26 pm PDT (Thursday)
From: Taft
Subject: RestoreStkP
To: McDaniel
cc: DoradoCore↑
The latest Mesa microcode uses the RestoreStkP feature for the first time. On
Dorado #10, the low 4 bits of the SavStk register were not working at all. I
replaced the chip and then everything was fine. Apparently the diagnostics
don't test this register.
Ed
*start*
00990 00024 US
Date: 29 Aug. 1980 5:22 pm PDT (Friday)
From: Taft.PA
Subject: Mesa 6 vs. Rev B IFUs
To: DoradoUsers↑
This message is of interest to Mesa users only; Smalltalk and Lisp users are not
affected.
You may not be aware that two of the Dorados contain old (rev B) IFU boards
that are not quite compatible with the current (rev C) IFU boards. Certain Mesa
programs, particularly those that make heavy use of nested local procedures, do
not run reliably on machines containing rev B IFUs. It has been observed that
Mesa 6 (and Mesa 6 based systems such as Cedar) are most seriously affected by
this problem; in general, Mesa 5 programs seem to run ok. Smalltalk and Lisp
are definitely not sensitive to this problem.
Mesa 6 users are therefore advised to avoid using the machines containing the
rev B IFUs; currently, these are Dorados #2 and #10. As soon as enough new
IFU boards have been built, the rev B IFUs will be retired and this problem
thereby eliminated.
*start*
00518 00024 US
Date: 7 Sept. 1980 4:02 pm PDT (Sunday)
From: Taft.PA
Subject: Re: Mesa 6 vs. Rev B IFUs
In-reply-to: My message of 29 Aug. 1980 5:22 pm PDT (Friday)
To: DoradoUsers↑
I am informed that both of the Rev B IFU boards have been retired and replaced
by new Rev C IFUs. Therefore, my warning about unreliable operation of Mesa
6 programs on Dorados #2 and #10 is obsolete: all Dorados are now logically
identical. (Many thanks to Herb and Charlie for their Dorado board production
efforts.)
Ed
*start*
00357 00024 US
Date: 7 Sept. 1980 4:04 pm PDT (Sunday)
From: Taft
Subject: Rev B IFU compatibility
To: Sosinski, Yeary, Ornstein
cc: DoradoCore↑, Taft
Unless there are any objections, I propose to remove all Rev B IFU compatibility
from the standard emulator microcode. This will save some microcode space and
make Mesa run slightly faster.
Ed
*start*
00306 00024 US
Date: 8 Sept. 1980 6:20 pm PDT (Monday)
From: Ornstein
Subject: Re: Rev B IFU compatibility
In-reply-to: Taft's message of 7 Sept. 1980 4:04 pm PDT (Sunday)
To: Taft
cc: Sosinski, Yeary, Ornstein, DoradoCore↑
OK by me. I think Rev B IFU's should sink in the west like all oldies.
*start*
01367 00024 US
Date: 12 Sept. 1980 11:04 am PDT (Friday)
From: Rovner.PA
Subject: Dorado partitions
To: DoradoUsers↑
I have agreed to help Severo out a bit by keeping track of which CSL Dorado
partitions are used for what.
This is my current model of the situation; please respond to this message if it's
wrong (or if you have anything else to say about the assignment of Dorado
partitions):
Partition 1 on each Dorado is a Mesa5 partition.
Partition 2 on each Dorado is a Smalltalk partition.
Partition 3 on each Dorado is a Lisp partition.
Partition 4 on each Dorado is a Mesa6/Cedar partition.
Partition 5 on each Dorado is assigned to an individual or project, as per below.
There are currently 8 Dorados in service. Here's my current list of the
assignments of the partitions 5 (PLEASE CORRECT THIS IF IT'S WRONG):
Dorado#1 near Warnock's office <<unassigned>>
Dorado#2 Across from coffee room (Juniper)
Dorado#3 near Mitchell's office (Russ Atkinson...Cedar Compiler)
Dorado#4 in MAXC room <<unassigned>>
Dorado#5 near MBrown's office <<unassigned>>
Dorado#6 near Warnock's office <<unassigned>>
Dorado#10 Grapevine (Cedar Data Base)
Dorado#11 John and Jane alcove <<unassigned>>
Paul
*start*
00513 00024 US
Date: 12 SEP 1980 1120-PDT
From: MCDANIEL
Subject: new [ivy]<dorado> .cm files
To: Dorado users:
I've constructed a new version of [ivy]<dorado>DoradoMesauser.cm. This
file includes a change that provides [hardwareSIL] and [SIL] entries.
This allows people to switch back and forth between the two most common
uses of SIL.
There is a new file, [ivy]<Dorado>getDoradoMesafonts.cm. As its name suggests,
this command file fetches various .al files from [ivy]<altofonts>.
Gene
-------
*start*
00538 00024 US
Date: 14 Sept. 1980 5:45 pm PDT (Sunday)
From: schmidt
Subject: Dorado #1, very flakey
To: DoradoSupport
At 5:30 today (Sunday) I've been trying to reboot Dorado #1.
First I do a three-button boot, which lands me in partition 1,
then I type "par 4" which gets me to partition 4, then I do an "install" and
the screen turns allblack or mostly black when it is asking me
"Do you want the long installation dialog?"
Sometimes it fails on the "par 4" command also.
I've powered it down and put a sign on it.
Eric
*start*
00498 00024 US
Date: 15 Sept. 1980 9:49 am PDT (Monday)
From: Pier
Subject: Re: Dorado #1, very flakey
In-reply-to: schmidt's message of 14 Sept. 1980 5:45 pm PDT (Sunday)
To: schmidt
cc: DoradoSupport
Eric-
This is symptomatic of a clobbered track 0 on partition 4. Next time, boot the
NetExec and install a new OS by running NewOS from the NetExec. Also, if
other partitions seem to work OK (like #1), you almost surely have a bad disk
partition (clobbered OS or SysDir or ...).
Ken
*start*
01066 00024 US
Date: 18 Sept. 1980 9:11 am PDT (Thursday)
From: Rovner.PA
Subject: Dorado Partition 5 Assignments
To: DoradoUsers↑
Here are the current assignments of the partitions 5 on CSL Dorados.
We can easily renegotiate the situation if there is a need to do so - please feel
free to express such a need if you have one. I will serve as a coordinator for this
purpose.
There are currently 8 Dorados in service.
Dorado#1 near Warnock's office <<unassigned>>
Dorado#2 Across from coffee room (Juniper)
Dorado#3 near Mitchell's office (Atkinson/Satterthwaite...Cedar
Compiler)
Dorado#4 in MAXC room (Stone/Pier...Griffin)
Dorado#5 near MBrown's office (Eric Schmidt...Binder for Pilot)
Dorado#6 near Warnock's office (Lyle Ramshaw...BCPL stuff)
Dorado#10 Grapevine (Cedar Data Base)
Dorado#11 John and Jane alcove (Paul Rovner...Cedar RunTime)
Paul
*start*
00313 00024 US
Date: 18 Sept. 1980 8:19 pm PDT (Thursday)
From: Deutsch.PA
Subject: New release of Find
To: AltoUsers↑, D0Users↑, DoradoUsers↑
Mirabile dictu! The new release of the Find (file-searching) subsystem runs on
Dolphins and Dorados as well as Altos. There are no other (intended) changes.
*start*
01488 00024 US
Date: 22 Sept. 1980 1:37 pm PDT (Monday)
From: Ornstein
Subject: Trouble Reports
To: DoradoSupport
Here is a suggested Trouble Report form. I propose that, as soon as possible we
begin recording. That consists of having Herb/Charlie/anyone else who fixes a
problem - send a message using the following form.
Let's keep it small but adequate to answer the main question - which is: how
much technician time is needed to maintain a Dorado. I included a small amount
of stuff to help understand grossly what KIND of things go wrong - but I don't
want that to enlarge the form to the point of becoming a pain to the guys.
Comments please.
************************************************************
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: MO-DAY-YEAR
Time: HHMM
Reporter's Name: NAME
Machine ID: SERIALNUMBER
Location: ROOMorALCOVE
Hardware: YESNO
Microcode: YESNO
Software: YESNO
Misunderstanding: YESNO
Number of hours to get machine going: HRS.QRTRS
Number of hours spent later in fixing broken item(s): HRS.QRTRS
Total number of hours spent on problem: HRS.QRTRS
Broken component(s):
Board Type: TYPE
Disk: YESNO
Power supply: TYPE
Cable: TYPE
Other (specify): XXX
Was "help" needed: YESNO
Comments: XXXXXXX
************************************************************
*start*
01219 00024 US
Date: 26 Sept. 1980 10:59 am PDT (Friday)
From: Ornstein.PA
Subject: Dorado Memory Size
To: DoradoUsers↑
Earlier this year, when our budget got trimmed, we formulated a reduced plan
which called for only 15 Dorados this year (rather than the previously planned
20). Our plan also included cutting the memory size of these machines to 256K
words (until further influx of $ next year).
Until now we have been filling the machines with 512K each. We are now at the
point where we have used up almost all the available memory boards and will
have to start robbing existing machines of half their memory to make more
machines. Butler has already flamed about how bad this is and in fact we have
managed to save some money on other items so that we are now going ahead and
getting more memory boards. But it is likely that we will go through a period
when at least some machines are only 256K. When this happens we'll let you
know and will put signs on the cripples.
(There is, of course, the option of not doing this and instead having fewer
machines. I have assumed that so long as we retained some 512K machines,
turning some of them into two 256K machines was a good deal).
Cheers,
Severo
*start*
00275 00024 US
Date: 29 SEP 1980 1624-PDT
From: MCDANIEL
Subject: dorado1
To: doradosupport
The bevel around the display of Dorado 1 covers far too much of
the left margin and most of the bottom line.
How about shaving it so I can see the display?
Gene
------
*start*
00526 00024 US
Date: 1 Oct. 1980 9:42 am PDT (Wednesday)
From: Ornstein
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Since there have been no complaints about the suggested form, I assume you all
love it. Thus let us begin with the first of October (today) using that form for all
future trouble reports.
To use the form, just copy it (do a "New form" and replace it all with the form)
into the Laurel Send window, fill it in appropriately, and send it off.
Thanks, and let me know if this has problems,
S.
*start*
00580 00024 US
Date: 1 Oct. 1980 9:55 am PDT (Wednesday)
From: Pier
Subject: Dorado4 ancient problem
To: DoradoSupport
In case you didn't remember, #4 occasionally gets infinite HOLD when
attempting to set breakpoints in the Mesa debugger. The HOLD is manifest on
task 14B (disk) doing a Store, but remember that DBuf is not task specific so the
Store HOLD can come from any task screwing up a STORE. I don't know what
kind of HOLD occurs or what the pipe looks like. This is not a show stopper-
people have been living with it for months. Fix it at low priority.
Ken
*start*
00341 00024 US
Date: 5 Oct. 1980 1:59 pm PDT (Sunday)
From: Schmidt
Subject: Dorado #5 is down - power problem
To: DoradoSupport
cc: Taft
Dorado # 5 is failing to start with a 4-flash sequence. Ed Taft looked at it with
Midas and says it is probably a problem with the 5-volt power supply. Attempts
to restart it failed.
Eric
*start*
00696 00024 US
Date: 7 Oct. 1980 9:31 am PDT (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-6-80
Machine ID: #5
Hardware: yes
Number of hours to get machine going: 1.0 Hrs.
Total number of hours spent on problem: 1.0 Hrs.
Broken component(s): 16k Ram g23 (PCMSA #102)
Board Type: PCMSA
Power supply: -5v
Was "help" needed: NO
Comments: The -5v power supply was primary cause of the machine
failure. As a preventive maintenance precedure, the memory diagnostics are ran
and bad memory chips are replaced. This is normally done after the repair of
the primary failure.
*start*
00560 00024 US
Date: 7 Oct. 1980 9:48 am PDT (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-6-80
Machine ID: #6
Hardware: YES
Number of hours to get machine going: 0.25 HRS.
Number of hours spent later in fixing broken item(s): 0.50 HRS
Total number of hours spent on problem: 0.75 HRS
Broken component(s): S374, e9
Board Type: PCMSA #unknown
Was "help" needed: NO
Comments: The PCMSA board was the primary cause of machine failure.
*start*
01001 00024 US
Date: 7 Oct. 1980 10:08 am PDT (Tuesday)
From: Weyer
Subject: dorado problems
To: DoradoSupport
cc: Willie-Sue
I've had some problems with two dorados when trying to run Smalltalk programs
which took a long time (i.e. over night).
on the Dorado in Butler's office on Sunday night, the screen went white after a
few hours with light diagonal lines. Ira mentioned to me that he's had at least
one "BADOOP".
on the Grapevine Dorado (#10), last night it halted (Willie Sue knows more of
the details). I restarted things and this morning it was sitting in swat with the
error message
#Internal Trap at location 0Internal Trap at location 1Internal Trap at location 1
I've never seen that message before and don't know what it indicates. I'm
willing to try yet another machine tonight to see if it is a problem with Smalltalk
(and also to get my job done); I'd be willing to let it run overnight also on one
of these "problem" machines to try to duplicate the problem.
Steve
*start*
00394 00024 US
Date: 11 OCT 1980 1005-PDT
From: PIER
Subject: Dorado6
To: doradosupport
Found Dorado6 (Butler's office) unwilling to boot due to disk being off line.
When I lifted the disk cover, an unmistakeable whiff of burning phenolic
was detected, but did not continue. Machine booted and ran after cycling
the switch on the front of the disk. Keep an eye on this.
Ken
------
*start*
01289 00024 US
Date: 13 Oct. 1980 12:31 am PDT (Monday)
From: stewart.PA
Subject: Dorado names and numbers
To: DoradoUsers↑
cc: stewart
Here is a list of the current set of Dorados, their locations, and nearby phone
numbers. This way you can forward your phone before leaving your office!
The columns will line up if you print this in a fixed pitch font.
I will maintain this list if it seems useful. I'll keep it as
[Ivy]<Stewart>Dorado.list, a plain text file.
Dorado Address Name Location Phone
---------------------------------------------------------------
1 3# 33# L-9 (Grapevine alcove) 4492
(Near Birrel's Office)
2 3# 12# Dorado2 L-4 (Coffee alcove) 4467
3 3# 30# L-2 (Near Butler's office) 4409
4 3# 7# Dorado4 Maxc Room 4449
5 3# 36# L-8 (E. Schmidt's office) 4475
6 3# 10# NewChampion (Near Warnock's office) 4454
10 3# 35# L-9 (Grapevine Alcove) 4481
(Near Birrel's Office)
11 3# 34# Near Elevator (John&Jane) 4482
12 3#331# Butler's office 4448
*start*
00286 00024 US
Date: 14 Oct. 1980 5:45 pm PDT (Tuesday)
From: Pier
Subject: New pad
To: DoradoSupport
cc: Pier
I have (temporarily) installed a Summagraphics Bit Pad digitizing device on
#12 (Butler's office). I haven't tried it out yet. The Dorado still seems to work.
Ken
*start*
00627 00024 US
Date: 15 Oct. 1980 9:27 am PDT (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-10-80
Machine ID: #1
Hardware: yes
Number of hours to get machine going: 2.5 Hrs.
Total number of hours spent on problem: 3.5 Hrs.
Broken component(s): MemD #304, PCMSA #312 (replaced
j26)
Board Type: MemD, PCMSA
Was "help" needed: NO
Comments: Nearly an hour of repair time was spent on a flaky "Hospital
Alto". MemD #304 problem has not been reproduced in lab and may be related
to a connector-board problem.
*start*
00653 00024 US
Date: 15 Oct. 1980 9:47 am PDT (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-14-80
Machine ID: #4
Hardware: yes
Number of hours to get machine going: 1.0 Hrs.
Total number of hours spent on problem: 1.0 Hrs.
Broken component(s): Card cage fan, power supply
cage fan, MSA #42 (replaced c15), MemX #62.
Board Type: MSA
Power supply: n/a
Was "help" needed: NO
Comments: This time was primarily scheduled maintenance to change
defective fans and make a swag at the problem of infrequent occurrence of misc
holds.
*start*
00606 00024 US
Date: 15 Oct. 1980 10:00 am PDT (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-14-80
Machine ID: #1
Hardware: ??
Software: ??
Number of hours to get machine going: n/a.
Total number of hours spent on problem: 0.5 Hrs.
Broken component(s): unknown
Power supply:
Was "help" needed: NO
Comments: Unable to reproduced problems. The only apparent trouble was an
occasional appearance of a double slash in the mesa debugger.
*start*
00780 00024 US
Date: 16 Oct. 1980 2:10 pm PDT (Thursday)
From: Schmidt
Subject: Problems with the Grapevine Dorado (#10)
To: DoradoSupport
cc: Stewart
Both Larry Stewart and I have had problems running mesa programs in partition
4 on the Grapevine Dorado. I ran a program that normally runs for 3 hours and
once it got a stackerror in 1hour and 50 minutes, the second time it ran to
completion. Larry had a program whose state got clobbered after five hours, he
then ran it again and it ran to completion.
These errors are extremely low frequency, and may be due to the Mesa system or
our programs. I thought the Dorado maintainers would like to know of the
possibility of a hardware problem. We'll report anything more definitive when
we know it.
Eric Schmidt
*start*
00712 00024 US
Date: 17 Oct. 1980 1:57 pm PDT (Friday)
From: Taft.PA
Subject: Dorado power-off
To: DoradoUsers↑
cc: Murray
In an effort to conserve power and reduce heat dissipation, Dorados will now
turn themselves off after one hour of running DMT. This power-off is
equivalent to a manual 4-push boot. A powered-off Dorado will exhibit a black
screen; pressing the boot button (any number of times) will initiate a power-on
sequence that takes about 45 seconds.
The automatic power-off capability is now included in the Mesa and Cedar
microcode, and will be incorporated into Lisp and Smalltalk microcode in the near
future. The new Mesa microcode also implements the Checksum (MISC 7)
opcode.
*start*
00656 00024 US
Date: 20 Oct. 1980 11:39 am PDT (Monday)
From: Rovner.PA
Subject: Dorado Partition 1 might change its purpose in life
To: DoradoUsers↑
The demand for individual assignments of CSL Dorado partitions 5 exceeds the
supply (there are currently 9 of them). There is a move afoot to start assigning
CSL Dorado partitions 1 to individuals. Who among you still use partition1 (the
Mesa 5 partition)? How much of a hardship would it be if some CSL Dorados did
not have a public Mesa 5 partition? If NO CSL Dorado had a public Mesa 5
partition?
I'll gather responses through Wednesday, then propose a plan in a message to
you all.
Paul
*start*
00881 00024 US
Date: 20 OCT 1980 1304-PDT
From: CROWTHER.PA
Subject: Re: Dorado Partition 1 might change its purpose in life
To: Rovner, DoradoUsers↑
cc: CROWTHER
In response to the message sent 20 Oct. 1980 11:39 am PDT (Monday) from Rovner.PA
I use Partition 1
a) to run Beads
b) to run Maxwells Music stuff
I am trying to convert Beads (but there is a lot of stuff to convert, and the display interface is all different, so
it isn't easy to convert)
Maxwell is trying to convert Music (but not until after his forum).
And is there any particular benefit to moving a user off of a mesa 5
partition to a mesa 6 partition? you did not mention mesa 6. but I
think the problem would just reappear.
So - my response is that I do use Dorado occasionally (once a week)
and i would be pissed if there were a Dorado available and I could not
run.
Will
------
*start*
00385 00024 US
Date: 20 Oct. 1980 1:43 pm PDT (Monday)
From: birrell.PA
Subject: Re: Dorado Partition 1 might change its purpose in life
In-reply-to: Rovner's message of 20 Oct. 1980 11:39 am PDT (Monday)
To: Rovner
cc: DoradoUsers↑
Before you decide on this, we should consider where Cedar Pilot logical volumes
will live; that may be a better use for partition 1.
Andrew
*start*
00787 00024 US
Date: 21 Oct. 1980 10:55 am PDT (Tuesday)
From: Taft
Subject: Dorado microprogramming restriction
To: DoradoCore↑, Deutsch, Masinter
It has been observed that map operations (Map← and RMap←) will occasionally
put the memory system into a bad state if executed while a previous memory
reference (probably a store) is still in progress. The symptom is that all tasks
grind to a standstill with infinite MiscHold and DBufBusy. We don't understand
why this happens, but it has been observed on two machines, so it is probably a
design bug rather than a hardware failure.
In any event, this problem can be circumvented by issuing ←MD before or
concurrent with Map← or RMap←. This requirement is the same as the
documented one involving DummyRef← and Flush←.
Ed
*start*
00312 00024 US
Date: 21 Oct. 1980 3:57 pm PDT (Tuesday)
From: Willie-Sue.PA
Subject: Smalltalk microcode
To: DoradoUsers↑
There is new Smalltalk microcode that cures the problem of trying to
run Smalltalk right after powering-on a Dorado. This code also includes the
automatic power-off capability.
*start*
00237 00024 US
Date: 24 Oct. 1980 8:30 am PDT (Friday)
From: suzuki
Subject: disk down on dorado6
To: DoradoSupport
This morning Dorado6 did not power boot from the terminal. Tim found out that
the disk was powered off.
Nori
*start*
00304 00024 US
Date: 24 Oct. 1980 9:45 am PDT (Friday)
From: Suzuki
Subject: Power supply down on Dorado6
To: DoradoSupport
At about 9:30 this morning Dorado6, the one in front of Warnock's office, went
down completely. We opened the cabinet and found that light is flashing four
times.
Nori
*start*
01410 00024 US
Date: 24 Oct. 1980 6:37 pm PDT (Friday)
From: Taft
Subject: Another Dorado hardware bug bites the dust
To: Sosinski, Yeary, Overton, Diebert
cc: DoradoCore↑, Taft
A bug in the disk controller, which we found a while ago but decided wasn't
causing any trouble, was preventing a Dorado from running a second (T-300)
drive disk drive. The problem is that glitches are being cross-coupled into the
Ready' signal in the Trident bus cable. Ready' is connected to the clock input of
the flipflop that generates the SeekTagTW wakeup. The glitches are causing
spurious wakeups to be generated, which gets the microcode thoroughly
confused.
There are two things that need to be done:
(1) Investigate why these glitches are so big. They are being cross-coupled from
the Index signal, which also goes through the bus cable. I observed glitches
from ground up to +1v -- but putting a scope probe on the signal makes the disk
problems go away, so I suspect the glitches are going above threshold when you
aren't looking at them.
(2) Eliminate the wakeup-on-ready feature. It is intended to give a wakeup at
the end of a seek, but we don't need it and it doesn't work anyway (it's
presently implemented as wakeup-on-NOT-ready!) This modification may be
made by cutting leg 6 of the MC231 at e04. This should be done on all Dorados
as time permits, though there is no urgency to this.
Ed
*start*
00295 00024 US
Date: 27 Oct. 1980 11:51 am PST (Monday)
From: pier
Subject: Dorado6 failures
To: DoradoSupport
Dorado6 has intermittent failures. It usually freezes up in FTP. Must boot the
machine to get free. Also, freezes up during ether boots. Might be temperature
related??
Ken
*start*
00621 00024 US
Date: 27 Oct. 1980 4:01 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-22-80
Machine ID: #2
Hardware: yes
Software: no
Number of hours to get machine going: 0.25 Hrs.
Total number of hours spent on problem: 3.0 Hrs.
Broken component(s): unknown
Power supply:
Was "help" needed: NO
Comments: Repair is not complete. Estimate 2 additional hours for repair.
Encountered difficulties replacing skinny dip F100181, 5b42 om MemC
#305.
*start*
01030 00024 US
Date: 27 Oct. 1980 4:30 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-20-80
Machine ID: #12
Hardware: yes
Software: no
Number of hours to get machine going: 4.0 Hrs.
Total number of hours spent on problem: 12.0 Hrs.
Broken component(s): DispY #308, IFU #304, T-80
Power supply:
Was "help" needed: NO
Comments: Repair is not complete. Encountered severe problems replacing chip
d03. Apparently this area of DispY #308 was burned during manufacturing and
solder will no longer adhere to these pins. Have repaired 6 opens so far, have
deferred maintenance until a more opportune time. Also, IFU failing with
intermittent RAMPEDISPATCHERRS with IFU diagnostic. This IFU not failing in
lab. The T-80 will intermittently power down on its own. These preceding
problems appear to be caused by the toasty warm atmosphere of Butler's
office.
*start*
00550 00024 US
Date: 27 Oct. 1980 4:34 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-22-80
Machine ID: #6
Hardware: yes
Software: no
Number of hours to get machine going: 0.5 Hrs.
Total number of hours spent on problem: 0.5 Hrs.
Broken component(s): None
Power supply:
Was "help" needed: NO
Comments: Unable to communicate with ethernet. Reinserted transceiver in
tapblock.
*start*
00537 00024 US
Date: 27 Oct. 1980 4:39 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-24-80
Machine ID: #6
Hardware: yes
Software: no
Number of hours to get machine going: 1.0 Hrs.
Total number of hours spent on problem: 1.0 Hrs.
Broken component(s): None
Power supply: -2V power supply failure
Was "help" needed: NO
Comments: No output from -2V supply. Replaced.
*start*
00698 00024 US
Date: 27 Oct. 1980 4:56 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-24-80
Machine ID: #12
Hardware: yes
Software: no
Number of hours to get machine going: 8.0 Hrs.
Total number of hours spent on problem: 8.0 Hrs.
Broken component(s): Suspect 5V regulator in T-80.
Power supply:
Was "help" needed: NO
Comments: T-80 disk drive intermittently powers down. Determined 5V logic
power drops out. Problem comes and goes while tracing +5v thru drive. Best
guess --- replaced 5V regulator transistor Q1 on LD9.1.
*start*
00631 00024 US
Date: 27 Oct. 1980 5:07 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-20-80
Machine ID: #3
Hardware: yes
Software: no
Number of hours to get machine going: 0.5 Hrs.
Total number of hours spent on problem: 2.0 Hrs.
Broken component(s): -5v heat-sinking mounting screw
Power supply:
Was "help" needed: NO
Comments: Monitor oscillates wildly. Found -5v regulator in 7-wire interface
had failed because of improper heat-sinking mounting hardware.
*start*
00610 00024 US
Date: 29 Oct. 1980 3:43 pm PST (Wednesday)
From: Taft
Subject: Another Dorado microprogramming restriction!
To: DoradoCore↑, Deutsch, Masinter
The Wakeup[task] function must be executed with TaskingOff if it is possible
that the specified task might be waking up simultaneously for some other reason
(e.g., due to a wakeup request from an external device, or due to a Wakeup
issued by yet another task). Otherwise the control section will get horribly
confused and the machine will hang in the same task forever.
An acceptable sequence is:
TaskingOff;
Wakeup[task];
TaskingOn;
*start*
01243 00024 US
Date: 30 Oct. 1980 12:04 pm PST (Thursday)
From: Rovner.PA
Subject: The Latest on the Assignment of Dorado Partitions
To: DoradoUsers↑
There is no longer a critical shortage of personal Dorado partitions. We have
decided to leave Partition 1 alone for now. The tentative plan for the medium
term is to convert partition 1 to Mesa 6 when Mesa 6 is officially released, and
then use partition 4 for (!!) the Pilot partition, or for other personal partitions.
Here are the current assignments of the partitions 5 on CSL Dorados.
There are currently 9 Dorados in service.
Dorado#1 Grapevine (Larry Stewart...Signal processing)
Dorado#2 Across from coffee room (Juniper)
Dorado#3 near Mitchell's office (Atkinson...Cedar System)
Dorado#4 in MAXC room (Stone/Pier...Griffin)
Dorado#5 near MBrown's office (Eric Schmidt...Binder for Pilot)
Dorado#6 near Warnock's office (Ed Satterthwaite...Cedar compiler)
Dorado#10 Grapevine (Cedar Data Base)
Dorado#11 John and Jane alcove (Paul Rovner...Cedar RunTime)
Dorado#12 Nursery (Gene McDaniel...Dorado system work)
Paul
*start*
00220 00024 US
Date: 31 OCT 1980 1254-PST
From: STEWART
Subject: missing keyboard foot
To: DoradoSupport
cc: Stewart
#11 (john and Jane) is missing a keyboard foot, causing the kbd to rock.
-larry
-------
*start*
00940 00024 US
Date: 2 Nov. 1980 12:13 pm PST (Sunday)
From: Taft
Subject: Another Dorado disk controller bug
To: Sosinski, Yeary
cc: DoradoCore↑
I've discovered another hardware bug whose effect is to cause checking not to
work properly. That is, a header or label check error does not have the desired
effect of inhibiting writing of the data record. This could easily explain why
Dorado file systems seem more fragile than Alto file systems.
The fix is easy: wire d20.6 to d20.10 (ECLTrue). This is fairly urgent and should
be done to all Dorados at the earliest opportunity. (At the same time, the "not
ready wakeup" bug that I described last week should be fixed by cutting e04.6.)
I have made these changes on Dorado #2. These hardware changes, a number of
microcode changes, and an interim "fix" to the T-300 Selected' glitch have finally
enabled reliable operation of the T-300 in Alto Trident emulation mode.
Ed
*start*
00600 00024 US
Date: 2 Nov. 1980 6:29 pm PST (Sunday)
From: Pier
Subject: Sick Dorado6
To: DoradoSupport
#6 drops into swat or otherwise clobbers low core (at least on partition 4) every
five minutes or so. I can make it happen by running Griffin and doing some
vanilla things. It also stops during EtherNet transfers. When I powered it up on
Sunday, after installing the color display system, I had to boot it 4 times before it
would come up. This is not a new problem- I reported troubles last week. I think
the crash cart should be wheeled up and diagnostics run across the board.
Ken
*start*
01445 00024 US
Date: 3 Nov. 1980 7:59 pm PST (Monday)
From: Taft
Subject: Dorado disk subsectoring
To: DoradoCore↑
cc: Sturgis, Kolling, Taft
Well, when attempting to run the Dorado T-300 using Juniper (16-sector) disk
format, we discovered that it was incompatible with disks written in that format
by an Alto. Apparently Roger made an error in the calculations that led him to
choose 117 subsectors per revolution -- there is no value of subsectors per sector
that correctly yields Alto Trident 16-sector format!
For now, I have jumpered the T-300 drive to generate the 16-sector format
directly, and changed the microcode to select 1 subsector per sector. This stopgap
measure will permit Juniper development to proceed.
Eventually I will recalculate the constants used for the Dorado subsectoring
scheme. At that time, we will have to change the jumpers on all the Dorado
T-80 disks. After that, it is unlikely that the format presently used for Alto
Diablo emulation will be feasible (choosing the correct constants is a problem that
has three constraints and only two independent variables). Therefore, it will be
necessary to reformat all the Dorado disks after this change is made. But there
are already several other good reasons for changing the disk format. I will try to
make all the changes happen at the same time, so the disks need to be
reformatted only once.
Ed
p.s. to Butler: Howard's clock has started.
*start*
00843 00024 US
Date: 4 Nov. 1980 11:05 am PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 10-30-80
Machine ID: #5
Hardware: yes
Software: no
Number of hours to get machine going: 3.0 Hrs.
Total number of hours spent on problem: 3.0 Hrs.
Broken component(s): e18 (RAM) on ContB #313
Power supply:
Was "help" needed: NO
Comments: Repair is not complete. Three separate problems were encountered.
#1 CacheD errors at addresses 4000 and above, reseating of MemD board
corrected the problem. #2 Frequently picking IMRH parity bit, replaced e18 on
ContB #313. #3 Power sequencing fails 50% of the trys, replaced Basebd #92,
(complete repair expected to take an additional 2Hrs.)
*start*
01022 00024 US
Date: 4 Nov. 1980 11:32 am PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-3-80
Machine ID: #6
Hardware: yes
Software: yes
Number of hours to get machine going: 5.5 Hrs.
Total number of hours spent on problem: 5.5 Hrs.
Broken component(s): unknown
Power supply:
Was "help" needed: NO
Comments: Repair is not complete. Two hardware problems and a software bug
in Color Griffin were involved. #1 MDI PE's ocasionally caused booting to fail,
replaced MemD board #312. #2 Booting hangs frequently and lower memory
areas appear to be destroyed during or after booting, retapped the ethernet
connection. An additional hour will be needed to complete the repair of the
MemD board.
The Color Griffin bug developed when the 3rd pig was mapped and copied in
the pig picture causing an illegal address to be inserted in BR 20 for task 13.
*start*
02878 00024 US
Date: 4 Nov. 1980 4:33 pm PST (Tuesday)
From: Taft
Subject: Follow up: disk subsectoring
To: DoradoCore↑
cc: Sturgis, Kolling, Taft
After further investigation, I have determined that there is no reasonable
combination of subsector length and subsectors per sector that meets all the
constraints:
(1) conform to Alto TFS 9-sector format;
(2) conform to Alto Juniper 16-sector format;
(3) implement a usable 28-sector format (not necessarily the same as the one
presently used for Diablo emulation).
The problem is that the three required sector lengths have a greatest common
divisor that is very small: 9 times the unit of sector length selection in the disk
drive, where 1 unit is only 12 bit times. To use this, the controller would need
a much larger subsector counter than it actually has (8 bits as opposed to 4).
What IS feasible with the present subsectoring arrangement is a non-Alto
compatible 16-sector format. The Alto 16-sector format divides the disk into
exactly 16 sectors. The Dorado 16-sector format divides the disk into 16 and a
fraction sectors; the 16 full sectors are smaller than on the Alto, but still plenty
large enough for Juniper pages. The leftover fraction of a sector can simply be
ignored.
I initially thought that we could simply redefine the Alto 16-sector format so as
to be compatible with the Dorado's, and copy the (small number of) existing
Juniper disks onto freshly formatted packs. Unfortunately, it turns out that the
Alto cannot use the Dorado 16-sector format, because overflow of the 4-bit
hardware sector counter on the Alto Trident controller would result in the
leftover fraction of a sector appearing to have the same sector number as real
sector zero. I suppose this could be gotten around by some clever changes to the
Alto microcode, but this is more than the Alto microprogrammer (me) wants to
contemplate at the moment.
Therefore, I propose that we adopt the following strategy:
(1) Continue with the present Dorado subsectoring arrangements for emulation of
Alto Diablo and Alto TFS 9-sector formats. (By the way, the Dorado is not
exactly compatible with the 9-sector format, but it's "close enough"....)
(2) So long as Juniper runs on Altos, achieve Dorado compatibility with the Alto
16-sector format by jumpering the drive for 16 sectors and using a subsector
count of 1 in the Dorado controller. (This perpetuates the stopgap measure that I
have already instituted.)
(3) At such time as compatibility with Alto 16-sector format ceases to be
important, switch to the Dorado 16-and-a-fraction sector format, and convert all
the Juniper packs in existence at that time. (Juniper is the only system that uses
the 16-sector format.)
(4) Implement the Dorado subsector arrangement in the Dolphin Trident
controller, rather than trying to invent something better.
Comments?
Ed
*start*
00191 00024 US
Date: 5 NOV 1980 0326-PST
From: MCDANIEL
Subject: dorado6 doesn't boot
To: doradosupport
I've tried several times to boot dorado6 and it does not work
Gene
------
*start*
00155 00024 US
Date: 5 Nov. 1980 5:49 am PST (Wednesday)
From: Weyer
Subject: Dorado #4
To: DoradoSupport
help! I can't get #4 to start.
Steve
*start*
00432 00024 US
Date: 5 Nov. 1980 9:18 am PST (Wednesday)
From: Sturgis
Subject: Re: Follow up: disk subsectoring
In-reply-to: Taft's message of 4 Nov. 1980 4:33 pm PST (Tuesday)
To: Taft
cc: DoradoCore↑, Sturgis, Kolling
Given the constraints, that looks like a rational solution. It sure is going to be
painful copying all of those packs.
on point 4, I agree, because compatibility is a very important issue.
Howard.
*start*
01029 00024 US
Date: 5 Nov. 1980 11:58 am PST (Wednesday)
From: Sosinski.PA
Subject: Dorado Booting
To: McDaniels, Weyer
cc: DoradoUsers↑
The power sequencing of dorados is not fullproof, and the advertised keyboard
boot will not ALWAYS bring it back to life.
This source of the problem appears to occur on the powerdown sequence. When
200 amps of -5volt power comes thundering down, it occasionally spikes the
Baseboard microcomputer out of its programmed path. In this state, even a 32
button boot in 4/4 time will not help, unless its relieves personal frustration.
If the advertised booting procedure fails, the best recovery procedure is to locate
the hulk of the offending dorado and gently depress the little white button on
the front panel ONE TIME. Its the only white button there. If the dorado
doesn't boot within 60 seconds, send me a message and find another dorado.
We are pursuing this problem of power-sequencing robustness and expect a
satisfactory solution before the first snowfall.
Charlie
*start*
01637 00024 US
Date: 5 Nov. 1980 7:04 pm PST (Wednesday)
From: Taft
Subject: Dorado microcode release
To: DoradoUsers↑
A new version of the Alto Emulator and Mesa microcode is released. There are
some internal changes and some bugs fixed. The only external changes are:
(1) The Alto emulator has two new instructions: GetIn (61044B) and GenOut
(61045B). These transfer a word of data between AC0 and the General IO port,
for such purposes as controlling a Summagraphics tablet.
(2) The microcode has an alternate entry point that does a "soft start",
more-or-less the same as an Alto's "silent boot". That is, a program can load a
new microcode image and then continue running rather than booting. (See the
description of LoadMB, below.)
Lisp and Smalltalk emulators incorporating these changes will be released in the
near future.
The LoadMB program, [Ivy]<Dorado>LoadMB.run, has been changed in the
following ways:
(1) It can optionally produce a .BR-format file containing the microcode image,
which can then be loaded with BCPL programs. (Thanks to Peter Deutsch for
contributing this feature.)
(2) Support for the obsolete .SB-format files has been removed.
(3) When loading microcode for immediate execution, it defaults the entry point
to 1070B, the "soft start" entry point. Thus, LoadMB returns to the Executive
when it is finished, rather than booting. However, when loading microcode to
write into a file (.EB or .BR), LoadMB still defaults the entry point to 1076B, the
standard entry point for a complete boot.
LoadMB is documented in [Ivy]<DoradoDocs>DoradoBooting.press, which has
been updated.
*start*
00949 00024 US
Date: 6 Nov. 1980 2:54 pm PST (Thursday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-6-80
Machine ID: Dorado #12
Location: Nursery
Hardware: YES
Microcode: NO
Number of hours to get machine going: N/A
Number of hours spent later in fixing broken item(s): 0.5 Hrs
Total number of hours spent on problem: 7.5 Hrs
Broken component(s): Open link between IFU (C008) and ContA (C016) on the
connector side of backpanel.
Comments: Dorado #12 was operational but midas would not always be
able to read out the IFU mufflers and registers. Found that cycling through
Read-All-Dmux would correct the problem temporarily. After considerable time
found that the backpanel net CLKEnable'a was open between the IFU and
ContA. Since this signal was terminated on both ends it would not affect the
dorado while running.
*start*
00461 00024 US
Date: 6 NOV 1980 2322-PST
From: HALBERT
Subject: Dorado #6 is broken
To: DoradoSupport
At about 11:15pm, thursday, Dorado #6 died in a most ungracious way while
I was Smalltalking. It would not reboot, and the little white button
didn't work. I have posted a sign on it. Symptoms are narrow
vertical stripes of irregular width on the monitor, looking something like
a very tall and wide Universal Product Code. Foo.
--Dan
------
*start*
00708 00024 US
Date: 7 Nov. 1980 2:40 pm PST (Friday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-7-80
Machine ID: Dorado #6
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 0.5 Hrs.
Number of hours spent later in fixing broken item(s): 1.0 Hrs.
Total number of hours spent on problem: 1.5 Hrs.
Broken component(s): Replaced f4 on MemX #317.
Board Type: MemX
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: Zebra display caused by memory system failure. The lower
bits of MCR were not functioning.
*start*
00300 00024 US
Date: 9 NOV 1980 2005-PST
From: MCDANIEL
Subject: Dorado6 seems a bit Flaky
To: doradosupport
I powered it up and it died after about 5 minutes of running Bravo.
(Die = display went crazy. Presumably because the processor
halted for one reasone or another )
Gene
------
*start*
01901 00024 US
Date: 11 Nov. 1980 1:19 pm EST (Tuesday)
From: Lampson
Subject: Re: Dorado microprogramming restriction
In-reply-to: Taft's message of 21 Oct. 1980 10:55 am PDT (Tuesday)
To: Taft
cc: DoradoCore↑, Deutsch, Masinter
For those who have forgotten the problem:
---------------
Date: 21 Oct. 1980 10:55 am PDT (Tuesday)
From: Taft
Subject: Dorado microprogramming restriction
To: DoradoCore↑, Deutsch, Masinter
It has been observed that map operations (Map← and RMap←) will occasionally
put the memory system into a bad state if executed while a previous memory
reference (probably a store) is still in progress. The symptom is that all tasks
grind to a standstill with infinite MiscHold and DBufBusy. We don't understand
why this happens, but it has been observed on two machines, so it is probably a
design bug rather than a hardware failure.
In any event, this problem can be circumvented by issuing ←MD before or
concurrent with Map← or RMap←. This requirement is the same as the
documented one involving DummyRef← and Flush←.
---------------
It says in the manual (middle of p 51) that you have to do the ←MD before a
Map← as well as a DummyRef← or Flush←. The reason for this is hinted at in
the preceding paragraph (see also MemX p 10): whether a reference is a store is
remembered in the pipe, and if a later Map← comes along and clobbers this
information before Ec2State4 of the Store miss, it is forgotten and the DbufBusy
flag is never cleared. This leads to permanent MiscHold, and a good thing too,
because other pipe bits which are clobbered at the same time control the transport
into the cache, which is therefore also screwed up, but in a less obvious way
which results in bad data in the cache.
I don't understand what motivated the statement about documentation of the
restriction in Ed's message. The manual seems to treat the three cases equally.
*start*
00558 00024 US
Date: 11 Nov. 1980 1:15 pm PST (Tuesday)
From: Taft
Subject: Re: Dorado microprogramming restriction
In-reply-to: Lampson's message of 11 Nov. 1980 1:19 pm EST (Tuesday)
To: Lampson
cc: Taft, DoradoCore↑, Deutsch, Masinter
Hmmm, right you are. I would never have thought of looking in the section
entitled "the Pipe" rather than "the Map" for a restriction involving Map←. The
primary description of Map← mentions only the restriction on waiting for
MapBufBusy, which contributed to my oversight.
Thanks for the explanation.
Ed
*start*
01008 00024 US
Date: 11 Nov. 1980 2:12 pm PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-10-80
Time:
Reporter's Name:
Machine ID: Dorado #12
Location: Nursery
Hardware: YES
Microcode: NO
Software: NO
Number of hours to get machine going: 2.0 Hrs.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 2.0 Hrs.
Broken component(s):
Board Type:
Disk: YES
Power supply:
Cable:
Other (specify): Wall breaker underated
Was "help" needed: YES, needed electrician to replaced panel breaker.
Comments: Dorado wall breaker was only rated at 20 Amps instead of 30
Amps. This underated breaker would pop causing the dorado to power off in an
undignified manner resulting in disk power sequencing problems. Switching the
disk AC on-off switch appeared to resolve the disk problems.....for now.
*start*
01342 00024 US
Date: 11 Nov. 1980 3:19 pm PST (Tuesday)
From: Taft
Subject: Dorado disk format change
To: DoradoUsers↑
In about two weeks, I will be releasing a version of the Dorado microcode that
implements a disk format incompatible with the present one. This means that
when the new microcode is installed, all existing Dorado disks will have to be
copied (from a Dorado running old microcode to a Dorado running new
microcode.)
I will see that the standard microcode versions are promulgated and that the
normal disks installed in each Dorado are copied. However:
(1) If you have any private Dorado microcode, you will have to regenerate it to
incorporate the new disk microcode.
(2) If you have any private Dorado disk packs, you will have to copy them onto
newly-formatted packs.
If you think you might be affected by (1) or (2), and your name isn't Larry,
Peter, or Willie Sue, please send me a message.
In case you are interested, the changes are as follows:
(1) reserve cylinder 0 for volume directory and other stuff needed by Pilot;
(2) implement a 14-sector format for Alto partitions, potentially increasing the
size of each partition from 18,000 to 22,000 pages;
(3) eliminate the present 3:1 interleaving of pages and thereby increase the
transfer rate for sequential reads and writes of large blocks.
Ed
*start*
00653 00024 US
Date: 13 Nov. 1980 1:01 pm PST (Thursday)
From: Rovner
Subject: Some assignments of Dorado Partitions I to individuals
To: DoradoUsers↑, Sturgis
As of this Saturday morning (the day after tomorrow, 11/15/80), the following
assignments of Dorado partitions I to individuals will be in effect:
Partition 1 on Dorado#2 (Across from coffee room) is Howard's, for Juniper
work.
Partition 1 on Dorado#4 (Butler's office) is Alan Wells', for work on data type
inference.
Note that these partitions will probably be passworded, hence it will be necessary
for non-owners when three-booting these Dorado's to use C, S or L.
Paul
*start*
00277 00024 US
Date: 13 NOV 1980 1545-PST
From: FIALA
Subject: Holding with ←Md
To: Taft, Lampson
cc: Dorado Core Group:
I have scribbled in replications of the caveat into the hardware manual and
will edit them into the manual prior to the next release.
-------
*start*
00737 00024 US
Date: 14 Nov. 1980 4:00 pm PST (Friday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-14-80
Machine ID: Dorado #6
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 0.5 HRS
Number of hours spent later in fixing broken item(s): 1.5 HRS
Total number of hours spent on problem: 2.0 HRS
Broken component(s): Replaced i21 on DispY #310
Board Type: DispY
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: No
Comments: Color monitor images contain gaps and dislocated
components. Replaced Fifo address flip-flop in i21.
*start*
00186 00024 US
Date: 18 Nov. 1980 1:30 pm PST (Tuesday)
From: Robson
Subject: Sick Dorado
To: DoradoSupport
Dorado #1 seems to be having difficulty producing a display.
Dave
*start*
00561 00024 US
Date: 18 Nov. 1980 8:52 pm PST (Tuesday)
From: Schmidt
Subject: Problem running Mesa on Dorado #5
To: DoradoSupport
I've had problems running Mesa in Partition 4 on Dorado #5 all day today.
About every 5 or 10 minutes, a Mesa program I'm running, or the Debugger,
craps out and the screen goes gray-black with random stripes, etc. Often, but
not always, it is waiting for terminal input.
When I CopyDisk'd the partition to another dorado, all my stuff worked fine,
so it must be a hardware problem with this specific Dorado.
Eric
*start*
00249 00024 US
Date: 19 Nov. 1980 3:17 pm PST (Wednesday)
From: Willie-Sue
Subject: Smalltalk microcode
To: DoradoUsers↑
New version of smalltalk microcode; only change is to use the new disk
code; report any problems to <Willie-Sue>.
*start*
01574 00024 US
Date: 21 Nov. 1980 11:38 am PST (Friday)
From: Taft.PA
Subject: Dorado disk format change
To: DoradoUsers↑
I am scheduling the disk format change for Friday, November 28 (the day after
Thanksgiving). All Dorados will be unavailable between 2pm and 5pm on that
day, while new microcode is installed and all the Dorado disks are copied to the
new format.
The details of the format change were given in a message I sent on November
11. That message gave rise to a few questions, which the following paragraphs
are intended to answer.
First of all, the format change will be totally invisible to programs using
standard microcode and running on standard partitions. The new disk format has
the POTENTIAL to support 14 sectors per track, but existing (12-sector) partitions
will continue to work -- the potential two extra sectors simply won't be used.
In order to utilize the extra two sectors (and increase the size of the partition
from 18000 to 22000 pages), it will be necessary to erase the partition and rebuild
the file system from scratch. This is NOT what I will be doing next Friday.
Rebuilding the partitions will occur at some later time, after the software required
to support 14-sector partitions (OS, Scavenger, CopyDisk) has been released. This
software will, of course, continue to support 12-sector partitions as well.
In a separate message, I will contact those of you whom I know to have private
Dorado disks that must be copied or special microcode that needs to be
regenerated to incorporate the new disk microcode.
Ed
*start*
00335 00024 US
Date: 24 NOV 1980 1728-PST
From: KAEHLER
Subject: Dorado #1 (by grapevine) is dead
To: DoradoSupport
Dorado #1 is unable to power up its disk. It died spectacularly
from smalltalk. Please let me know when it is up again so that I
can rescue my files from the Smalltalk partition. ted Kaehler x4392
------
*start*
00698 00024 US
Date: 24 Nov. 1980 5:26 pm PST (Monday)
From: Rovner
Subject: Some more assignments of Dorado Partitions 1 to individuals
To: DoradoUsers↑
Partition 1 on Dorado#6 (Near John Warnock's office) is Nori's, for Cedar Data
Base work.
Partition 1 on Dorado#10 (near Grapevine) is a public partition, soon to be set
up by Mark Brown, for preparing Mesa programs that will run on Pilot.
BEWARE. It will contain mesa system files which will not work in a non-Pilot
world (the exec herald will make this clear).
Because there remain people who use Mesa5 on Dorados, I think it wise to NOT
assign any more partitions 1 to individuals, at least until more Dorados arrive.
Paul
*start*
00870 00024 US
Date: 28 Nov. 1980 6:34 pm PST (Friday)
From: Taft.PA
Subject: Dorado disk format change
To: DoradoUsers↑
The disks on all the public Dorados have been converted to the new disk format,
and new versions of the microcode have been released. For background
information, see my messages of November 11 and 21. Remember that private
Dorado disks and private versions of Dorado microcode need to be converted to
the new format before you can use them.
Certain users may be interested to know the following:
Partition 1 of Dorado 4 (Butler's office) had a couple of hard disk errors. The
bad error status was eliminated by the disk copying that took place during the
format conversion, but the data in those pages is suspect.
Dorado 7 (Warren's office) appeared not to have anything on partitions 2 and 3,
so I didn't try to reformat them.
Ed
*start*
00455 00024 US
Date: 29 Nov. 1980 4:45 pm PST (Saturday)
From: Taft.PA
Subject: Mesa 5 partition updated
To: DoradoUsers↑
Mesa 5 fans: I have updated and cleaned up the Mesa 5 partition and re-stored it
as [Ivy]<Dorado>Mesa5.bfs. When retrieving it, you should tell CopyDisk to
copy this (single) file to "bfs", NOT to "dp0" and "dp1".
This replaces the former [Ivy]<dorado>Mesa.DoradoDisk0 and Mesa.DoradoDisk1,
which have been deleted.
Ed
*start*
00517 00024 US
Date: 30 NOV 1980 2209-PST
From: MCDANIEL
Subject: Dorado 12 (in Nursery)
To: doradosupport
+12 powersuply appears Kaput: Midas reports +1 amps on the
12 volt supply, anyway. Actually, something is
funny since the Dorado will run the emulator ok, it just won't drive
the Trident (the green light will not come on). I assume this means
we use +12 for the Trident. Oh well.
Also, The display on 12 needs its "number" ie., the number "12" is
missing on the display housing.
Gene
------
*start*
00344 00024 US
Date: 30 NOV 1980 2344-PST
From: MCDANIEL
Subject: dorado 17 in Mike's lab
To: doradosupport
Broke on my while using Bravo. Sigh. I couldn't make any sense out
of it. It won't boot the emulator, even over the ethernet. Naturally,
MemA and Kernel both run (mema, one iteration; kernel, 75 iterations).
Gene
------
*start*
01095 00024 US
Date: 1 Dec. 1980 6:14 pm PST (Monday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-19-80
Time:
Machine ID: Dorado #6
Location:
Hardware: Not Likely
Microcode: Likely
Software: Possible
Misunderstanding:
Number of hours to get machine going: 0.0 Hrs.
Number of hours spent later in fixing broken item(s): None
Total number of hours spent on problem: 5.0 Hrs.
Broken component(s):
Board Type: N/A
Disk: N/A
Power supply: N/A
Cable:
Other (specify):
Was "help" needed: YES, HELP!
Comments: Griffin crashes while displaying certain test pictures. The
failure is caused by an uninitialized Base Register (value is usually 7777 000012)
used in a memory reference. It is apparent that the display "B" Channel had
illegally run since the pipe indicated that the subtask = 2.
Changed the DispY and DispM boards as well as the ProcL to no avail. Problem
has not been corrected. Microcode or software is suspected.
*start*
00235 00024 US
Date: 1 DEC 1980 2210-PST
From: KAEHLER
Subject: Dorado #6 (by Perlis)
To: DoradoSupport
The ethernet is amlost not working. It is running very very slowly. I am able to reproduce it. Ted Kaehler
------
*start*
00605 00024 US
Date: 2 Dec. 1980 9:50 am PST (Tuesday)
From: Pier.PA
Subject: Re: DORADO TROUBLE REPORT
In-reply-to: Sosinski's message of 1 Dec. 1980 6:14 pm PST (Monday)
To: Sosinski
cc: DoradoSupport
Ed Taft and I tried to investigate the Griffin problem on #6. We saw it several
times and, just as we broke out the drawings and listings, we could not make it
happen again. It looks exactly as if the BChannel was turned on (and made a
reference) by some phantom. We will look at it again the next time it is
convenient, we have the crash cart hooked to #6, and the problem resurfaces.
Ken
*start*
02431 00024 US
Date: 2 Dec. 1980 10:52 am PST (Tuesday)
From: Rovner
Subject: CSL Dorado partition assignments: current status
To: DoradoUsers↑
Here are the current assignments of CSL Dorado partitions 1 and 5.
There are currently 10 Dorados in service. All except #1 and #7 have 512K
words of memory. #1 and #7 have 256K.
Dorado#1 Grapevine 3#33#
Partition1: PUBLIC Mesa 5 partition
Partition5: Larry Stewart...Signal processing
Dorado#2 Across from coffee room 3#12#
Partition1: Howard Sturgis...Juniper
Partition5: Karen Kolling...Juniper
Dorado#3 near Mitchell's office 3#30#
Partition1: PUBLIC Mesa 5 partition
Partition5: Russ Atkinson...Cedar System
Dorado#4 Butler's office 3#7#
Partition1: Alan Wells...data type inference
Partition5: Ed Satterthwaite...Cedar compiler
Dorado#5 near MBrown's office 3#36#
Partition1: Gene McDaniel...Dorado system work
Partition5: Eric Schmidt...Cedar, system modelling
Dorado#6 near Warnock's office 3#10#
Partition1: Nori Suzuki...Cedar data base
Partition5: Maureen Stone/Ken Pier...Griffin
Dorado#7 Warren's office 3#37# (ENTERPRISE)
Partition1: PUBLIC Mesa 5 partition
Partition5: Warren Teitelman...Cedar user facilities
Dorado#10 Grapevine 3#35#
Partition1: PUBLIC Mesa6 for Pilot, with Pilot defs modules
Partition5: Mark Brown...Cedar data base
Dorado#11 John and Jane alcove (near Clover) 3#34#
Partition1: PUBLIC Mesa 5 partition
Partition5: Paul Rovner...Cedar RunTime
Dorado#12 Nursery 3#331#
Partition1: PUBLIC Mesa 5 partition (used by John Maxwell)
Partition5: Ed Taft...Dorado Pilot
Note that private partitions 1 may be passworded, hence it is necessary
for non-owners when three-booting these Dorado's to hold down C, S or L.
BEWARE. Partition 1 on Dorado#10 (near Grapevine) contains mesa system files
which will not work for a non-Pilot world (the exec herald makes this clear).
Paul
*start*
00740 00024 US
Date: 2 Dec. 1980 11:05 am PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-24-80
Time:
Reporter's Name:
Machine ID: Dorado #6
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 1.0 Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 1.0 Hrs.
Broken component(s):
Board Type:
Disk:
Power supply: -5 volt P/S failure
Cable:
Other (specify):
Was "help" needed: NO
Comments: The -5 Volts would drop out intermittently after 1 hour of
operation.
*start*
00714 00024 US
Date: 2 Dec. 1980 11:09 am PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-26-80
Time:
Reporter's Name:
Machine ID: Dorado #6
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 1.0 Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 1.0 Hrs.
Broken component(s):
Board Type:
Disk:
Power supply: -5 volt P/S failure
Cable:
Other (specify):
Was "help" needed: NO
Comments: The -5 Volts power supply output was zilch.
*start*
00843 00024 US
Date: 2 Dec. 1980 11:27 am PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 11-26-80
Time:
Reporter's Name:
Machine ID: Dorado #5
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 2.5 Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 2.5 Hrs.
Broken component(s): h11, a F415 ram.
Board Type: ContB #313
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: A certain Cedar program gets IMPE's. Diagnostics cannot
produce an error. Finally tracked problem down to a peculiarly sensitive ram on
the ContB board.
*start*
01090 00024 US
Date: 2 Dec. 1980 11:54 am PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-1-80
Time:
Reporter's Name:
Machine ID: Dorado #6
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 5.0. Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 5.0. Hrs.
Broken component(s):
Board Type:
Disk:
Power supply: -5v
Cable:
Other (specify):
Was "help" needed: Yes
Comments: The -5V ps failed for the third time. Investigated to find the
cause/causes. Thoroughly checked the dorado's AC wiring for poor connections.
Finally determined the 5 volt supply needed approximately 120VAC
to power up. Specs say the supplies should function with input AC from 103V
to 127V. Sent supply in for repair. Cannot find any hard evidence that dorado
6 is killing the 5V power supplies. Still suspicious though.
*start*
00819 00024 US
Date: 2 Dec. 1980 2:09 pm PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-1-80
Time:
Reporter's Name:
Machine ID: Dorado #12
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 2.0 Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 2.0 Hrs.
Broken component(s): Solid state relay K3 in T-80.
Board Type:
Disk: T-80 failure
Power supply:
Cable:
Other (specify):
Was "help" needed: No
Comments: Trident spindle motor will not turn. Found the start winding
voltage missing and solid state relay K3 open (LD 2.4).
*start*
01047 00024 US
Date: 2 Dec. 1980 3:19 pm PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-1-80
Time:
Reporter's Name:
Machine ID: Dorado #4
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 4.0 Hrs.
Number of hours spent later in fixing broken 2.0 Estimated Hrs.
item(s):
Total number of hours spent on problem: 6.0 Hrs.
Broken component(s):
Board Type: MSA #45
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: No
Comments: Intermittent programs halts. The only diagnostic error was a
non-descript halt in Chaos part of MemA. After changing MemD, then MemX,
and then MemC, the problem became uglier causing all or part of the last word
in the munch to be dropped. Finally found a sickly MSA board causing the
problems. Estimate 2 additional hours to repair MSA board.
*start*
01028 00024 US
Date: 2 Dec. 1980 3:50 pm PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-2-80
Time:
Reporter's Name:
Machine ID: Dorado #6
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 2.0 Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 2.0 Hrs.
Broken component(s):
Board Type:
Disk:
Power supply:
Cable:
Other (specify): Defective transceiver
Was "help" needed: No
Comments: Ethernet operates very S-L-O-W-L-Y. Tried a different
Dsketh board and the ethernet would not work at all. Changing the transceiver
made a remarkable improvement in performance. There also appears to be some
dark magic in this section of the ethernet causing communication with a close
neighbor to be less then dependable.
*start*
00822 00024 US
Date: 2 Dec. 1980 4:03 pm PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-2-80
Time:
Reporter's Name:
Machine ID: Dorado #11
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 1.0 Hrs.
Number of hours spent later in fixing broken
item(s):
Total number of hours spent on problem: 1.0 Hrs.
Broken component(s):
Board Type:
Disk:
Power supply:
Cable:
Other (specify): Possible connector problem
Was "help" needed: No
Comments: Won't Boot disk and failing with PE's from MDI.
Therapeutic reseating of the ProcL and Dsketh cured the problem.
*start*
00889 00024 US
Date: 2 Dec. 1980 4:23 pm PST (Tuesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-2-80
Time:
Reporter's Name:
Machine ID: Dorado #12
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 0.5 Hrs.
Number of hours spent later in fixing broken 1.5 Hrs Est. Hrs.
item(s):
Total number of hours spent on problem: 2.0 Hrs.
Broken component(s):
Board Type: ProcL #303
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: No
Comments: Rbase problem. Getting frequent failures in conjunction with
IFU jumps and tasking. Rbase becomes zero instead of its orginal value.
Estimate 1.5 Hrs. to repair the ProcL board.
*start*
00314 00024 US
Date: 2 DEC 1980 1837-PST
From: MCDANIEL
Subject: IMPE at IMX 2004 on Dorado 12 (in Nursery)
To: doradosupport
IMX 2004 SHOULD BE 17315,,074240
IMX 2004 WAS 17305,,74240
IMX 2004 DROPPED 10,,0
The failure is similar to one I experienced yesterday night,
too.
Pls fix!
Gene
------
*start*
00799 00024 US
Date: 3 Dec. 1980 10:06 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-3-80
Time:
Reporter's Name:
Machine ID: Dorado #12
Location: Nursery
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 0.5 Hrs.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 0.5 Hrs.
Broken component(s): F415 on ContB #307
Board Type: ContB
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: Reported IMPE's --- dropping LC.2. Replaced l16 on ContB
#307. Ran Midas and memory diagnostics without error.
*start*
00847 00024 US
Date: 3 DEC 1980 1553-PST
From: MCDANIEL
Subject: [ivy]<doradodocs>MicroSample.memo
To: Dorado users:
The file [ivy]<doradodocs>MicroSample.memo describes the Mesa interface to
the microcode Pc sampling feature in the Dorado. Briefly, the Dorado microcode
has the ability to keep emulator Pc histogram data (ie., the microcode Pc
for task 0, the "emulator task") by incrementing counters in memory.
MicroSample provides Mesa programmers with access to the
basic facility and various creature comforts that I've found valuable
in the course of my performance work on the Dorado.
MicroSample DOES NOT provide an analysis capability. Once
you get the raw data you must run some other program to find out
what is really going on. All these details are covered in the memo.
Comments & bug reports to me.
Gene
-------
*start*
00359 00024 US
Date: 3 Dec. 1980 4:52 pm PST (Wednesday)
From: Sosinski.PA
Subject: New Dorado
To: Doradousers↑
cc: CSL.PA
The Kitty Hawk has joined the fleet of Dorados and is on its shakedown cruise
with the Midway in the nursery.
It will remain here until the first of the year or when SDD's docking facilities
are completed.
The dorado crew
*start*
00218 00024 US
Date: 4 DEC 1980 1345-PST
From: PIER
Subject: MidWay Communications Outage
To: doradosupport
MidWay (#12, Nursery) cannot boot, connect to Maxc or Ivy. Apparent network failure.
Ken
------
*start*
00191 00024 US
Date: 5-Dec-80 20:31:37 PST
From: Taft.pa
Subject: Sick Dorado fan
To: DoradoSupport
The upper-left fan on Dorado #10 has failed and is making very sick noises.
Ed
*start*
00222 00024 US
Date: 8 DEC 1980 1346-PST
From: MCDANIEL
Subject: Midway Ethernet seems broken again
To: doradosupport
I cannot attach to maxc2 or ivy from Midway. EDP seems to have problems,
too.
Gene
------
*start*
01081 00024 US
Date: 8 Dec. 1980 2:10 pm PST (Monday)
From: Stewart.PA
Subject: Dorado names and numbers
To: DoradoUsers↑
Please send me corrections and new information, as it becomes available.
This list is kept on [Ivy]<Stewart>Dorado.list.
Dorado Address Name Location Phone Notes
----------------------------------------------------------------------------
1 3# 33# Saratoga L-9 (Grapevine) 4492 256K
(Near Birrel's Office)
2 3# 12# Yorktown L-4 (Coffee alcove) 4467 512K
3 3# 30# CoralSea L-2 (Near Butler's office) 4409 512K
4 3# 7# Princeton Maxc Room 4449 512K
Butler's office (terminal) 4448
5 3# 36# BunkerHill L-8 (E. Schmidt's office) 4475 512K
6 3# 10# Lexington (Near Warnock's office) 4454 512K
(color display)
7 Enterprise (Non-public machine)
10 3# 35# Hornet L-9 (Grapevine Alcove) 4481 512K
(Near Birrel's Office)
11 3# 34# Wasp Near Elevator (John&Jane) 4482 512K
12 3#331# Midway Nursery 4444 512K
16 Forestall (not in service) 256K
17 3#334# KittyHawk Nursery 4444 256K
*start*
00600 00024 US
Date: 10 Dec. 1980 8:30 am PST (Wednesday)
From: Boyce
Subject: Dorado #11 (wasp)
To: Doradosupport
cc: Boyce
Shortly after booting, the screen turned grey with diagonal white lines. I looked
around for someone who might know what was going on. EdTaft said that it had
halted. I could try rebooting; if that didn't work, send a message to you.
It didn't work. Furthermore, after attempting to reboot, I noticed that it smelled
"hot". I looked for the power switch and found it (or its apparent functional
equivalent)on the base in back. I turned it off.
jim boyce.
*start*
00515 00024 US
Date: 10 Dec. 1980 3:23 pm PST (Wednesday)
From: Weyer
Subject: flaky dorado
To: DoradoSupport
the machine in Bruce Nelson's office (not the music machine) doesn't run
Smalltalk.
if I triple S boot the machine, it puts me on partition 1, and typing doesn't work
(unless I single boot again). I tried "Partition 2" which put me in the Smalltalk
disk area, but resuming smalltalk boot files failed in Swat -- I assume the
microcode wasn't getting loaded. I tried this 2 or 3 times.
Steve
*start*
00364 00024 US
Date: 11 DEC 1980 1018-PST
From: MCDANIEL
Subject: Lexington's display
To: doradosupport
Sometimes Lexington won't boot: the display remains dark. multiple button
boots, power cycling and baseboard booting do not affect the situation.
I power cycled the display (as opposed to the Dorado) and the display came back to
life.
G
------
*start*
00466 00024 US
Date: 11 Dec. 1980 2:06 pm PST (Thursday)
From: Pier.PA
Subject: Re: Lexington's display
In-reply-to: MCDANIEL's message of 11 DEC 1980 1018-PST
To: MCDANIEL
cc: doradosupport
I noticed a similar phenomenon on KittyHawk. I guess there is a problem, either
with the 6502 system in the terminal or the tube itself. Those monitors, if they
get unhappya (bad sync for long enough), are known to lock up and only power
cycling brings them back.
*start*
00506 00024 US
Date: 11 Dec. 1980 8:32 pm PST (Thursday)
From: Taft.PA
Subject: Midway in flames
To: DoradoSupport
cc: Willie-Sue
The Midway Dorado (in the nursery) has an intermittent power problem. It runs
fine for a long time, and then suddenly the -5 and -2 turn off and the
baseboard reports "current power problem" (4 flashes). Pressing the white button
and power-cycling the machine do not help. But waiting a few minutes does
help. This happened 3 times in 3 hours this evening.
Ed
*start*
00386 00024 US
Date: 15 Dec. 1980 3:51 pm PST (Monday)
From: Willie-Sue.PA
Subject: Dorado microcode
To: DoradoUsers↑
cc: Taft, Rovner, Satterthwaite
Mesa and Cedar microcode for the Dorado now contains extra code to
support garbage collection for Cedar. To vanilla mesa users, this code should
seem no different. Please report any problems/anomolies to me.
Willie-Sue
*start*
00396 00024 US
Date: 17 DEC 1980 0015-PST
From: HALBERT
Subject: Smalltalk on #10
To: DoradoSupport
Dorado #10 (Hornet) wouldn't run Smalltalk this afternoon, even after
several attempts. Now, as of the time of this message, it won't even
3-button boot, but merely does a damped sine wave from top to bottom
(i.e. typical loss of sync). Seems like it's deteriorating. --Dan
------
*start*
00819 00024 US
Date: 18 Dec. 1980 1:04 pm PST (Thursday)
From: Rovner
Subject: A Dorado Pilot partition (!)
To: DoradoUsers↑
Dear fellow celebrants,
I'm gathering information again about Dorado usage, in preparation for deciding
how best to make Dorado Pilot available to users.
Do any of you use any of the public Mesa5 partitions (partition 1 on Dorados 1,
7, 11, and 12)? Which of these Dorados do you use most often for your Mesa5
work?
Who among you use the Lisp and Smalltalk partitions? How would you feel
about having public Lisp (Smalltalk) partitions on fewer of the CSL Dorados?
Please try to supply a value for N in the following:
My work would be effected adversely if there were fewer than N public
Lisp (Smalltalk) partitions?
your faithful Keeper of the Ferrous Oxide,
Paul
*start*
00406 00024 US
Date: 18 Dec. 1980 1:46 pm PST (Thursday)
From: Crowther.PA
Subject: Re: A Dorado Pilot partition (!)
In-reply-to: Rovner's message of 18 Dec. 1980 1:04 pm PST (Thursday)
To: Rovner
cc: DoradoUsers↑
I have nothing of mine in mesa 5.
I use John Maxwell's stuff, which is only in mesa 5, occasionally. Not very
much in the last few weeks.
I use no lisp or smalltalk stuff. (N=0)
*start*
00362 00024 US
Date: 19 Dec. 1980 10:46 am PST (Friday)
From: Sosinski.PA
Subject: New Dorado
To: Doradousers↑
cc: Overton, Orr
The Kitty Hawk is now in SDD waters in Building 96.
The Bon Homme Richard is now available for users on its shakedown before
heading to Park Place. It is now berthed in the nursery.
Seasons Greetings,
The Dorado Crew
*start*
01144 00024 US
Date: 20 Dec. 1980 12:15 am PST (Saturday)
From: Taft.PA
Subject: Dorado Pilot
To: CSL↑, DoradoUsers↑
cc: PilotImplementors↑
Pilot is now working well enough on the Dorado to be usable for Cedar/Cascade
development. There are a few rough edges, which I will smooth out after I
return from vacation. There is also no documentation yet. But I have given
Roy Levin sufficient information that he should be able to assist Dorado Pilot
users in my absence.
Partition 5 of Midway, the Dorado in the CSL "nursery", is hereby declared to be
a public Pilot/Cascade partition. To boot it, hold down "T" and press the boot
button 3 times. From there you are on your own. Setting up Pilot partitions on
other Dorados is straightforward, but is sufficiently different from the D0
procedure that you should consult Roy first.
Performance (on a 512K Dorado) is very nice, except for the very long
world-swap time which is still as bad as on the D0 and which I believe can be
improved easily.
I would like to publicly thank Roy Levin, Hal Murray, Forrest Howard, Paul
McJones, and Jim Frandeen for their valuable assistance.
*start*
00530 00024 US
Date: 22 Dec. 1980 9:23 am PST (Monday)
From: Diebert.PA
Subject: IFU-MwRev-Cg-s.exceptions
To: LMcCreight
cc: DoradoCore↑, Diebert
Lynn
The new exceptions file is on IVY in the usual place. I don't think I will update
the layout errors until next year sometime since they require doing a Document
Rev change and I know how much I don't like to do those things.
Let me know if you have any more problems with the board tester files or any
other Dorado engineering stuff.
Yours for a better Dorado
Tim
*start*
00837 00024 US
Date: 23 DEC 1980 0549-PST
Sender: STROLLO at PARC-MAXC
Subject: Dorados and FTP vs the net
From: STROLLO at PARC-MAXC
To: boggs
Cc: Strollo, doradosupport
Message-ID: <[PARC-MAXC]23-DEC-80 05:49:35.STROLLO>
Dave,
Evidence is mounting now that the problem is specific to Dorados and the
version of FTP which is on [IVY]<Cedar>Mesa6.bfs. It claims to be FTP of
Dec 16. It refuses to transfer certain specific large files via
the retrieve command from either MAXC, IVY, or even my Alto. However,
it is perfectly happy to load same file from a dump file! The particular
file giving me grief is on [MAXC]<Strollo>DMPC.BCD also on
[IVY]<MPCHIP>DMPC.BCD.
I bet it is software, but leave it to you to figure out. It fails for
sure on Dorado's 3 and 6 which I have been using extensively over the
past few days.
Ted
*start*
00550 00024 US
Date: 23 DEC 1980 0605-PST
Sender: STROLLO at PARC-MAXC
Subject: ftp conjecture #2
From: STROLLO at PARC-MAXC
To: boggs
Cc: Strollo, doradosupport
Message-ID: <[PARC-MAXC]23-DEC-80 06:05:28.STROLLO>
I think a bit or more is wiped in that FTP in the file I pointed you at.
Specifically it is healthy enough to retrieve [MAXC]<ALTO>FTP.RUN
which is happy as a clam to retrieve my files. Who should I report this to?
ie who is responsible for the bfs files on [IVY]. You just might
want to try this yourself to be sure.
Ted
*start*
00525 00024 US
Date: 23 Dec. 1980 10:37 am PST (Tuesday)
From: Pier.PA
Subject: Re: ftp conjecture #2
In-reply-to: STROLLO's message of 23 DEC 1980 0605-PST,
<[PARC-MAXC]23-DEC-80 06:05:28.STROLLO>
To: STROLLO
cc: boggs, doradosupport
Willie-Sue and I just happened to be near #6 last night when Herb and Charlie
were diagnosing this bug. We cleaned it up by fetching [MAXC]<Alto>FTP.run
and by running CLEANDIR. I think Ted is right about the clobbered FTP. I
think Doug Wyatt created [IVY]<Cedar>Mesa6.bfs.
Ken
*start*
00365 00024 US
Date: 23 DEC 1980 1210-PST
From: MCDANIEL
Subject: Lexington flaky when using Bravo
To: doradosupport
Lexington has grave problems when I get or put files from Bravo.
That act seems to sink Bravo -- One appears in SWAT with a variety of
different errors. Reinstalling Bravo and running the scavenger has
not helped.
Help!
Gene
------
*start*
00354 00024 US
Date: 23 DEC 1980 1311-PST
From: MCDANIEL
Subject: more on Lexington
To: doradosupport
Lyle Ramshaw says that the problem may be with the microcode:
I was using partition 5 (color griffin) and it loads its own microcode.
When I get a chance I'll try using different microcode on that partition to
see how Bravo works.
G
------
*start*
00445 00024 US
Date: 23 DEC 1980 1538-PST
From: MCDANIEL
Subject: avoid mesa.mb , cedar.mb inside [ivy]<dorado>Dmesa.dm
To: Dorado users:
If you need to reload the microcode from a file, avoid the currently released
versions of mesa that are stored on ivy. They do not work properly. I do not know
what version you get when you boot the mahine from the Ethernet. I'm sure
Ed Taft will fix things up when he returns.
Gene
-------
*start*
00648 00024 US
Date: 23 DEC 1980 2104-PST
Sender: STROLLO at PARC-MAXC
Subject: Problem with Partition 4 loaded from [ivy]<cedar>mesa6.bfs
From: STROLLO at PARC-MAXC
To: Doradousers↑
Cc: Strollo
Message-ID: <[PARC-MAXC]23-DEC-80 21:04:55.STROLLO>
If you reload a dorado partition 4 from above mentioned file, the
FTP is smashed in a very subtle way and the Mesa debugger is
smashed in a not so subtle way. The fix to FTP is to get the a
new copy from [MAXC]<ALTO> (yes FTP is healthy enough to FTP
itself). The debugger is fixed by typing "XDEBUG" to the exec.
Ed Taft will fix this up when he returns.
Merry Christmas,
Ted
*start*
00339 00024 US
Date: 24 DEC 1980 1617-PST
From: MCDANIEL
Subject: lexington display
To: doradosupport
The display on Lexington will not light up. The machine appears to boot ok, in
that the baseboard thinks the machine has booted. No amount of my power cycling
the display or Dorado seems to help the situation.
Gene
------
*start*
00372 00024 US
Date: 30 Dec. 1980 5:41 pm PST (Tuesday)
From: Taft.PA
Subject: Disk images moved
To: DoradoUsers↑
Reply-To: Taft
The CopyDisk image files Mesa5.bfs and Smalltalk14.bfs, formerly kept on
[Ivy]<Dorado>, have been moved to [Ivy]<BasicDisks>. These disk images are
usable on Dolphins as well as Dorados, so their former location was illogical.
Ed
*start*
00437 00024 US
Date: 30 Dec. 1980 5:55 pm PST (Tuesday)
From: Taft.PA
Subject: Dorado Pilot documentation
To: CedarAll↑, CascadeUsers↑, DoradoUsers↑
Reply-To: Taft
Documentation now exists for setting up and using Pilot on a Dorado. A revised
version of Roy Levin's memo, "Making your Dolphin run Pilot", is now entitled
"Setting up Pilot on a Dolphin or Dorado" and is available on
[Ivy]<CedarDocs>SettingUpPilot.press.
Ed
*start*
00967 00024 US
Date: 31 Dec. 1980 9:47 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-3-80
Time:
Reporter's Name:
Machine ID: MIDWAY #12
Location: Nursery
Hardware: NO
Microcode: NO
Software: NO
Misunderstanding: YES
Number of hours to get machine going: 2.0 HRS.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 2.5 HRS.
Broken component(s):
Board Type:
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: YES
Comments: Ethernet connection not always reliable. After substituting
hardware components, finally discovered another machine (D0) with same
ethernet address. Problem still persisted but less frequent. Traced problem again
to same D0 which also had Pilot installed with the duplicate ethernet address.
*start*
00844 00024 US
Date: 31 Dec. 1980 9:58 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-10-80
Time:
Reporter's Name:
Machine ID: WASP #11
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 1.5 HRS.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 1.5 HRS.
Broken component(s):
Board Type: MemD
Disk:
Power supply:
Cable:
Other (specify): Connector - poor contact
Was "help" needed: NO
Comments: Intermittent smalltalk failures. Diagnostics indicated
unreliable CacheD bit 14. Reseating MemD board corrected problem - an
apparent connector problem.
*start*
00857 00024 US
Date: 31 Dec. 1980 10:10 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-11-80
Time:
Reporter's Name:
Machine ID: KITTY HAWK #17
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 2.5 HRS.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 3.0 HRS.
Broken component(s):
Board Type: BaseBoard
Disk:
Power supply:
Cable:
Other (specify): Wrong Version of EPROMS
Was "help" needed: NO
Comments: Occasional booting problems. Finally determined machine
was powering down due to overtemperature. Somehow an old version of
Baseboard code was installed.
*start*
01031 00024 US
Date: 31 Dec. 1980 10:35 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-12-80
Time:
Reporter's Name:
Machine ID: LEXINGTON #6
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 2.5 HRS.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 3.0 HRS.
Broken component(s):
Board Type:
Disk:
Power supply: Replaced (2) Two -5 volt Power Supplies
Cable:
Other (specify):
Was "help" needed: NO
Comments: Another -5 volt power supply failure, 0 volts output. The
first replacement would not work. (Found it would work with 117 volt input but
not 115 volts.) The second replacement work normally.
Removed back cover and baffle to allow cooler operation and
no doubt increase -5 volt power supply life.
*start*
00602 00024 US
Date: 31 Dec. 1980 10:47 am PST (Wednesday)
From: Laaser
Subject: Kitty Hawk network communications difficulties
To: DoradoSupport
cc: Laaser
I'm having trouble running FTP and CopyDisk from Kitty Hawk (the SDD
Dorado.) Since both of these programs were working last week on the same files
that they are failing on now, I suspect the problem may related to the hardware
failure earlier this week. The only data I have been able to collect on these
problems is that EtherWatch claims the Dorado is putting out a large number of
bad packets when running these programs.
Bill
*start*
00810 00024 US
Date: 31 Dec. 1980 10:46 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-16-80
Time:
Reporter's Name:
Machine ID: KITTY HAWK #17
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 0.5 HRS.
Number of hours spent later in fixing broken item(s): 1.0 HRS.
Total number of hours spent on problem: 1.5 HRS.
Broken component(s): SIP g41
Board Type: DispY #309
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: Intermittent keyboard and booting failures. Traced problem
to intermittent configuration SIP g41 on DispY #309.
*start*
00934 00024 US
Date: 31 Dec. 1980 11:02 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-22-80
Time:
Reporter's Name:
Machine ID: LEXINGTON #6
Location:
Hardware: NO
Microcode: Likely
Software: Maybe
Misunderstanding:
Number of hours to get machine going: 2.0 HRS.
Number of hours spent later in fixing broken item(s):
Total number of hours spent on problem: 2.0 HRS.
Broken component(s):
Board Type:
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: YES
Comments: FTP fails to transfer certain specific large files with retrieve
command from MAXC or IVY. Problem occurred exclusively on partition 4
(Cedar) which apparently had a damaged FTP.run. After retrieving a new
FTP.run, files tranferred normally.
*start*
00838 00024 US
Date: 31 Dec. 1980 11:14 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-29-80
Time:
Reporter's Name:
Machine ID: LEXINGTON #6
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 2.0 HRS.
Number of hours spent later in fixing broken item(s): 1.5 HRS.
Total number of hours spent on problem: 3.5 HRS.
Broken component(s): open SIP i43
Board Type: MemX #304
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: Booting failures, getting PE's from ST. Traced to error
detection logic on MemX #304. Found open terminator i43 for STclk0'Ba.
*start*
01338 00024 US
Date: 31 Dec. 1980 11:38 am PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-29-80
Time:
Reporter's Name:
Machine ID: KITTY HAWK #17
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 5.0 HRS.
Number of hours spent later in fixing broken item(s): 3.5 HRS.
Total number of hours spent on problem: 8.5 HRS.
Broken component(s): -5 volt power supply, IFU #307 ContA connector
Board Type: IFU #307
Disk:
Power supply: -5 volt supply had 0 volts output
Cable:
Other (specify): Connector for ContA - poor contact.
Was "help" needed: NO
Comments: Air Conditioning shutdown during Christmas Holidays
caused Dorado to run in hot environment promoting multiple failures. Replaced
-5 volt supply. Booting still fails - IFU failure. Found PCFG problem -- fails to
increment - replaced d8 (F16). After reseating ContA, booting would work
ocasionally.
Getting MDI PE's when booting emulator from disk. Solved this problem with a
little magic -performed a more precise adjustment of the power supplies.
Expect more problems after failures of this nature. (HEAT KILLS)!!
*start*
00846 00024 US
Date: 31 Dec. 1980 1:51 pm PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-23-80
Time:
Reporter's Name:
Machine ID: BON HOMME RICHARD #20
Location:
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 1.0 HRS.
Number of hours spent later in fixing broken item(s): 1.5 HRS.
Total number of hours spent on problem: 2.5 HRS.
Broken component(s): Defective Prom h11
Board Type: MemX #308
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: MemA failure, found that words 2 & 3 of munches were
usually identical. Traced problems to faulty ST prom on MemX #308.
*start*
00868 00024 US
Date: 31 Dec. 1980 2:06 pm PST (Wednesday)
From: Sosinski
Subject: DORADO TROUBLE REPORT
To: DoradoSupport
Date: 12-31-80
Time:
Reporter's Name:
Machine ID: KITTY HAWK #17
Location: SDD BLDG 96
Hardware: YES
Microcode:
Software:
Misunderstanding:
Number of hours to get machine going: 1.0 HRS.
Number of hours spent later in fixing broken item(s): 1.5 HRS. (EST.)
Total number of hours spent on problem: 2.5 HRS.
Broken component(s):
Board Type: DskEth #
Disk:
Power supply:
Cable:
Other (specify):
Was "help" needed: NO
Comments: FTP and copy disk failures with some files. Replaced DskEth
#311. Problem not resolved to component as yet. Estimate 1.5 Hrs. to complete
repair.