This message describes changes between the current Alto-compatible Dolphinmicrocode release (version 46) and the previous release (version 33).This microcode is sometimes referred to as "AMesa" below. As usual thevarious files involved in this release are version coordinated--all haveversion number 46 on the three Ivy directories where I put them. For thisreason you should note the version to avoid possible confusion later.Files related to this release are as follows:InitialAlto.Eb!46install on your disk with OthelloAlto.Eb!46for Ethernet boot serversAMesaSources.Dm!46sourcesMPCodes.Press!46interpretation of AMesa maintenancepanel codesMurrayMPCodes.Pressinterpretation of Initial and othermaintenance panel codesAMesaRelease.Press!46copy of this messageVersion 46 fixes all operational bugs known to me, so report any problems thatyou have with it. If version 46 doesn't work for some reason, version 28/29 isstored on [Ivy]NewInitialAltoCSL.Eb!28 and on LFKB>NewInitialAltoLF.Eb!29(NOTE: version 33 fixed several problems in version 28/29 but also introducedtwo bugs, so it seemed on the whole less useful that version 28/29; hence dropback to version 28/29 if 46 doesn't work).Changes are as follows:1) Some changes have been made in maintenance panel codes. At startup amicroprogram called Initial runs first; it has maintenance panel codesdocumented in MurrayMPCodes.Press. The MP code 104 is displayed for about0.4 seconds when Initial is finished and AMesa has commenced; after thatMPCodes are interpreted as discussed in [Ivy]MPCodes.Press!46.2) The initialization problem which caused the display horizontal controlto be screwed up just after you powered on your Dolphin is believed fixed.3) A problem in version 33 or later Ethernet control microcode whichcaused occasional MP code 120 to 122 failures is fixed. A problem inversion 33 or later disk control microcode is believed fixed.4) The above microcode release will run on any of the three display/keyboardconfigurations--you do not need separate microcode versions for LF andCSL keyboards as you did before.5) Storage is now preserved after a maintenance panel code crash, so it ispossible to attach to a D0 with Midas and look at storage after a crash(I doubt that this will be useful except during extraordinary circumstances).6) Microcode for color display, jasmine scanner, halftoning, and Mesafloating point opcodes is now part of the automatic loadup; those who havebeen using MicrocodeOverlay.Bcd with version 28 or 33 should delete it.Microcode developers note that the automatic loadup overwrites the area ofmicrostore formerly reserved for the Midas Kernel. If this interferes withsomeone's debugging, call me.7) WCBL (76b), ICBL (77b), and Misc opcodes with alpha byte in the range60b through 77b now trap through SD 151, 152, and 156, respectively; theseare for Cedar.8) Mesa JRAM opcode (367b) now treats the microcode to which it jumps as asubroutine, which can optionally "Return" to continue with the next opcode;formerly it was necessary to exit at P7TailLoc, sometimes inconvenient.Also, you can now use JRAM to start an arbitrary microcode task--simplypush a 16d-bit number on the stack in which bits 0..3 are the task andbits 4..15 are the starting microstore address; when the task thus startedblocks, the emulator will continue at the next opcode (The LRJ opcode alsoallows arbitrary tasks to be started this way).9) Two bugs in RXLPL and WXLPL and one page fault bug in RDBL Mesa opcodesare fixed courtesy of SDD (Frandeen or Johnsson, I think).10) BitBlt handling of gray mode has been modified so that it is compatiblewith the Alto. Previous microcode would occasionally fail to align graypatterns in adjoining rectangular areas. bApJ aE _G ^H ]KI \E Z-Y'!XU 'W'U'#'T S_'#'R"P' NiN M,O KQ JM IsN H6* E C@H BF @J ?H >JF ;I :J 8D 6E 5= 3 L 1F 0 .*J ,G +M )4E 'J &G %|J $>K # H HJ  J RK G G F \J J / fJ ): K pH 3( 6kY(211) Some improvements in the display microcode result in about 1% performanceimprovement for all emulators and improve the worst case timing enoughthat display glitching with LF monitors should occur less often.12) The refresh timer has been slowed from a 64 microsecond period to 256microseconds; this has been done to reduce timer task overhead from about4% of all cycles down to 1% of all cycles (i.e., emulators will run about 3%faster with the display off or about 4% faster with full screen display).Although the internal clock will tick more slowly, long-term "drift" withrespect to Alto compatible clock update will be lessened, so the clock willrun at about the same speed as on the Alto rather than about 0.4% faster.I know of no programs which rely upon the granularity of the 64 microsecondtick used previously, so this change should not affect any software.Unfortunately, the period over which all bits in storage are refreshed isslowed from 2 msec to 8 msec. 16K ic's used for storage specify that atthe maximum operating temperature (80 degrees C. at the surface of the ic)a period of 2 msec is required for refresh. I have been advised that therefresh period is exponential in absolute temperature such that the requiredperiod halves about every 5 degree rise in temperature, so quadrupling theperiod will lessen maximum operating temperature of a marginal part about10 degrees C. However, the spec is believed to be so conservative thatvery few parts require refresh at the maximum rate, and a 3% to 4% speedimprovement seems worth the possible replacement of a few storage ic's.If anyone runs into problems with this change or has reliable hardwareinformation, please let me know details. Note that it is desirable forstorage diagnostics to use an equal or slower refresh period to detectpossible problems in this area.Thanks to Hal Murray for help in checking out this microcode.Ngp aM _F ^@ \I ZI YL XUI WI UK TI S_K R"D OI NiH M,J KI JL IsJ H6I FG EH D}G BF @G ?F >J ;=p ;3,_}GACHA j/>iAMesaRelease.BravoFialaJanuary 19, 1981 11:09 AM