github.com/Interlisp.medley
1
0
Fork 0
mirror of synced 2026-01-12 00:42:56 +00:00
Code Issues Projects Releases Wiki Activity

Add documents from envos/LISPCORE/internal/docs (#812)

Browse Source
This commit is contained in:
Larry Masinter 2022-07-02 22:08:47 -07:00 committed by GitHub
parent 32128f5e19
commit f86be45834
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
146 changed files with 3031 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/internal/1982BUGS.TEDIT Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/32MBAddressSpaceLayout.tedit Normal file
View File

Binary file not shown.

38
docs/internal/AR-How-To-Edit.tedit Normal file
View File

File diff suppressed because one or more lines are too long

8
docs/internal/ATOMHIST.TXT Normal file
View File

@ -0,0 +1,8 @@
((0 246) (1 15332) (2 3591) (3 1765) (4 897) (5 654) (6 442) (7 339) (8 232) (9 180) (10 176) (11 125)
(12 108) (13 107) (14 91) (15 65) (16 74) (17 48) (18 57) (19 46) (20 35) (21 31) (22 28) (23 28) (24
24) (25 22) (26 26) (27 27) (28 9) (29 18) (30 10) (31 9) (32 10) (33 7) (34 10) (35 6) (36 4) (37 8)
(38 2) (39 4) (40 6) (41 7) (42 3) (43 11) (44 4) (45 3) (46 3) (47 4) (48 5) (49 1) (50 3) (51 2) (
52 2) (53 1) (54 1) (55 4) (56 7) (57 2) (58 2) (59 4) (60 2) (61 1) (62 3) (63 2) (64 2) (66 1) (67 5
) (69 1) (70 2) (72 1) (73 1) (74 1) (75 2) (77 2) (79 1) (82 2) (83 1) (84 2) (86 1) (89 1) (91 1) (
93 2) (97 1) (111 1) (116 1) (119 1) (130 1) (133 1) (136 1) (145 1) (146 1) (148 1) (152 2) (159 1) (
163 1) (168 1) (179 1) (185 1) (188 1) (196 1) (207 1))

116
docs/internal/Addarith.tty Normal file
View File

@ -0,0 +1,116 @@
There are a few additional arithmetic functions:
(MASK.1'S <position> <size>) returns a number equivalent to
(llsh (sub1 (expt 2 size)) position), but faster, and without consing.
Currently, the sume of <position> and <size> cannot exceed 32.
(MASK.0'S <position> <size>) is basically (logxor -1 (mask.1's position size))
These two functions use a diagonal array of pre-computed masks, which
is accessed by \getbaseptr's over a 32-cell index array (this is to substitute
for "fast" elt, since ELT isn't yet in microcode). Macro definitions for both
funs cause all calls to MASK.1'S to turn into these "fast" elts.
(POWEROFTWOP <x>) where <x> is an integer, quickly returns its result.
(INTEGERLENGTH <x>) is basically log2 of n; that is how long the integer
representation of <x> is when expressed in base 2. For example,
(haulong 13) = 4; <x> must be an integer, and for negative arguments,
the result is the same as that of the absolute value.
(HAIPART <x> <n>) gets the high-order <n> bits of the two's complement
representation of the integer <x>; for negative <n>, it gets the low-order
<-n> bits. Note that "high-order" is not dependent on word size, but
is derived from (HAULONG <x>).
(IMOD <x> <modulus>) returns <a> where <a> is in the closed interval
[0, 1, ... < modulus-1>] and <x> = m*<modulus>+<a>. NoteWell:
this is *not* the same as the REMAINDER function, since <a> is always
non-negative. The argument <modulus> may also be CELL or WORD,
in which case the appropriate size is substituted to truncate to a cell-sized
or word-sized integer. A macro definition for mod optimizes the case for
compilation where <n> is constant and is a power of two.
(EVENP <x> <n>) is true iff <x> is 0 mod <n>; <n> defaults to two if not
supplied. Currently both arguments must be integers. A macro
definition also does some compile-time optimization, particularly
for the case where <n> is a power of two.
(ODDP <x> <n>) is just (not (evenp <x> <n>)); has both expr and macro
definition.
(IMODLESSP <x> <y> <modulus> <equal?>) This function is inspired by
the need to use "wrap-around" counters. It is not possible to define a
"perfect" ordering function on the integers [0, 1, ... <modulus-1>], but
this function takes the view that it is better to limit the "diameter"
of the applicable domain, than to "bump" into the singularity at the
endpoints of the interval. So MODLESSP will return "true" iff
<y>-<x> mod <modulus> is less than 1/2*<modulus>. The optional
argument <equal?>, if non-null, says to do a "less than or equal"
test rather than a "lessp" test. Generally the <modulus> should be
a power of two (for faster running speed), but this isn't necessary.
Two exceptional arguments are also admitted -- if <modulus> is
'WORD, then the appropriate value is taken for word-sized arithmetic;
if it is 'CELL, then the appropriate value is taken for double-word,
or cell, sized arithmetic. In Interlisp-D, WORD sized is 16-bit, and
CELL-sized is 32-bit.
(TIMEREXPIRED? <x> <y>) Basically, this function just calls MODLESSP with
<x> and <y> and a modulus argument derived from the size of the clock
behind the CLOCK function; however, if <y> is omitted (or is NIL), it
defaults to the value of (CLOCK 0), but without doing any consing.
Typical usage is in implementing an "alarmclock". One will set some
variable, say TIMEOUT, to (MODPLUS (CLOCK 0) <duration>), and
then frequently test (TIMELESSP TIMEOUT); when this test first
becomes false, the timer, or "alarmclock", has expired.
(IMODPLUS <x> <y> <modulus>)
(IMODDIFFERENCE <x> <y> <modulus>)
These two functions are essentially (MOD (<operation> <x> <y>) <modulus>),
except no overflow is permitted to occur during the intermediate <operation>.
A macro produces some slightly-optimized code for the case where <modulus>
is CELL. A current limitation is that an arithmetic overflow occurring when
<modulus> is not a power of two (or CELL or WORD) causes an error.
(BITTEST <n> <mask>) is the CommonLisp function defined as
(NEQ 0 (LOGAND <n> <mask>)).
(ROT <x> <n> <wordsize>) is a slight extension of the CommonLisp ROT
function; it performs a bitwise-rotation of the integer <x>, by <n> places,
within a field of <wordsize> bits wide. The optional argument <wordsize>
defaults to CELL, and must either be an integer in the range 1 to
<bitspercell>, or else be one of the litatoms CELL or WORD; in the latter
two cases the quantities <bitspercell> and <bitsperword> are respectively
substituted. A macro optimizes the case where <wordsize> is WORD and <n>
is 1; this is to help with the 16-bit rotate found in checksumming algorithms.
***** The remaining documentation is about \-named functions ******
The following two functions are essentially the CommonLisp functions
LOAD-BYTE and DEPOSIT-BYTE, but without any error or consistency
checking. There are versions with the checking, under similar, non-\
names, in another file (to be released at a later date).
(\XLOADBYTE <x> <position> <size>) is derived from the PDP-10 LDB
instruction; it takes a byte of length <size> out of the integer <x>
which byte has <position> bits to the right of it when <x> is viewed
in binary notation.
(\XDEPOSITBYTE <x> <position> <size> <newval>) is derived from the PDP-10
DPB instruction; it does not "modify memory" however, but returns
an integer obtained by replaceing the byte of <x> as specified under
LOADBYTE with the low-order <size> bits of <newval>.
The following four functions implement a feature that Ron asked for a long
time ago, and probably should not be documented for random users, unless
all the \-functions will be so documented:
(\GETBASEBITS <addr> <bit-offset> <n>) returns a integer obtained by
starting at the word address <addr>, skipping over <bit-offset> bits,
and getting the next <n> bits from memory. In this scenario, bits
are numbered with 0 being the high-order position in the word, and
with incresing bit-addresses leading to increasing word address. Thus
bit address 15 is the low-order bit of some word, and bit address 16 is
the high-order bit of the next word. The low-order bit of the result
is obtained from the bit found at <bit-offset>+<n>-1 bits after bit 0 of
the word at <addr>. This ordering of bits and bytes within a memor

BIN
docs/internal/AddressSensitiveFns.TEdit Normal file
View File

Binary file not shown.

BIN
docs/internal/Array-Space.TEdit Normal file
View File

Binary file not shown.

BIN
docs/internal/BROKENMotown-wishlist.TEdit Normal file
View File

Binary file not shown.

151
docs/internal/BUILDINGUCODE Normal file
View File

@ -0,0 +1,151 @@
File: [FS6:PARC:Xerox]/ISLDisplay/Display1/Software/LispOptionsHandlers.message
Last Edited: DDavies - 3-Nov-88 18:12:10
I hyperventilated a lot trying to figure out what to do. Here's the procedure I think should work. CORRECTIONS APPRECIATED!!!!!!
Already Nick Briggs and Karey Krauter have cleared up many points. Without them, this would never have happened.
Examples of the files used to build the color display handler can be found on [FS6:PARC:Xerox]/ISLDisplay/Display1/Software/IOP/*.
---------------------------------------------------------------
This is a procedure for adding an options handler to an existing LispDove.db. It is an amalgam of the procedure in RAMMemHandlers.doc and what I've been able to figure out. I assume the new options handler will live in Main Memory. Its name will be "xyz."
The first thing to realize about building a LispDove.db is that you have unlimited opportunities to demonstrate your toughness and resolve. This procedure took me about a week to get through successfully the first time. Then for about 6 months it was easy. Then it was impossible again, so I switched from Lyric (a Lisp release) to Medley (a later release). This document describes the process of building the Medley release since I seem to have lost the ability to build one for Lyric.
This document is mostly about the process of assembling the files needed to do the final build, not about the tactics of writing a handler. There are a few hints below, but you'll really need to read the Opie documentation and look at the existing options handlers (Bringover PPOHandlerDove.df or CDspHandlerDove.df). Having a knowledgeable (and understanding) friend helps a great deal. You should also read everything on [Ohio:OSBU North:Xerox]<IO Architecture>MesaDoveDoc> and <IO Architecture>Opie>. The file called PerfectMap.mp2 is really called Perfect.mp2 and is on <IO Architecture>, not <IO Architecture>MesaDoveDoc>.
We assume that you know 80186 assembly language. We also assume knowledge of PCs, XDE and all the tools you'll use to get the job done.
I'm intentionally ignoring ConfigOnly files, since there is no Lisp Configuration Tool (they use the Mesa one).
I'm also ignoring the Lisp software necessary to communicate with the new Handler, since I don't know anything about it. Maybe we'll add that later (Nick?). I do know that Lisp doesn't have processes, just tasks that voluntarily give up control and execute in strict round-robin fashion. There is no limit on the length of time a Lisp task may hold the processor. Well-behaved tasks give up control occasionally. Lisp tasks can send interrupts to the IOP. The IOP handlers essentially cannot sent interrupts to Lisp tasks (if you ignore the timer). Timer interrupts appear 60 times/sec, but don't seem to do much.
We'll assume you're doing all your assembling, linking and locating on a real XT or AT. The Assembler, Linker, Locator, CRLFTool and PC/XNS software are floating around. We also assume you're doing your editing in XDE. XDE is also needed to run the BringOver/SModel, Fetch and MakeDoveMicroboot tools. Files are transferred between your workstation and the PC using the Ethernet. All the command files used will pull the relevant files over, do the work, and send the results back. Since the XDE editor doesn't use linefeed characters and the PC software demands them, we'll incorporate a program on the PC to insert linefeeds (CRLFTool). Unfortunately, the program isn't smart enough to recognize existing CRLF sequences - it turns them into CRLFLF. That means we'll have to remove any linefeeds that exist on the XDE side.
(1) First, we'll BringOver all the dreck you'll use to build your handler. There are lots and lots and lots of versions of this stuff around. The current Lisp system is not based on any particular DSBU release. The only way to get an approximation to the files used by the rest of the Lisp code is to bring it all over. First, carefully get rid of whatever .asm, .def, .lst, .obj, .lnk, .loc, .mp1 and .mp2 files you've got lying around.
BringOver "[Pogo:AISNorth:Xerox]<UCode>DF>LispDove.df"
BringOver exactly the version of LispDoveIOPIntegration.df now on your disk.
BringOver exactly the version of AllocSgs.df now on your disk.
BringOver exactly the version of KeyboardMouseHandlerDove.df now on your disk.
Go get [Wilma:OSBU North:Xerox]<Maple>Working>IOP>XtndOpie.loc (it will be used by ColorLispDove.cm)
Now, you're close. You've noticed by now that these DF files specify numerous versions of some files. Here are my rules: 1) BringOver the latest version whenever there is a conflict. This works except for the following files (as of 12-Jul-88 11:07:06 anyway):
IOREther.obj, STKEther.obj - The version of IOREther used in LispDoveIOPIntegration uses up about 13KB of the 16KB available for IORegions. The rest of the IORegions won't fit in the remaining space below 8000H. Why is this important? Well, if you plan to debug your handler IOP code using Lisp, you need to put an image of the PROM into RAM. At SDD, they changed things so the PROM image can live at C000H. However, Lisp hasn't changed so it's PROM image still lives at 8000H. As of this date (12-Jul-88 11:10:26), the Lisp code doesn't take advantage of the extra ENet buffers, so you can use the IOREther.obj and STKEther.obj from the 12.3 release if you need to. For the Medley build, I'm using the big ENet buffers and doing my handler debugging in the Mesa environment.
(2) Create an IORegion segment definition both in 80186 assembly language and Lisp code. Make sure they match. The 80186 segment must be named "xyzIOR" and be contained in a file called "IORxyz.asm". Your IOR segment must be declared "COMMON". Many copies of it will appear in different files below. The locator will combine the copies only because of the COMMON declaration.
(3) Create a stack segment definition in 80186 assembly code. The segment must be named "xyxSTK", and its standard file name is "STKxyz.asm". Your STK segment must be declared "COMMON". Many copies of it will appear in different files below. The locator will combine the copies only because of the COMMON declaration.
(4) Write your 80186 handler. Remember that its name can be no longer than 8 characters (MS-DOS limitation). This will contain all the tasks needed by your device. A useful way of thinking about an Opie task is that for every interrupt serviced by your handler, you need one task. An interrupt may not be serviced by two tasks and a task shouldn't try to service two interrupts. You can have more tasks than interrupts if that is useful. Watch out for the way Opie handles interrupts when receiving tasks aren't waiting for them.
You might also want to think about where variables are stored. All the PROM handlers put their variables in the IORegion, since that's the only RAM they are allowed to use. Since your handler will be in RAM, you could bury some variables in it if necessary. Remember that the number of segment registers is limited and care should be taken when passing pointers with implied segment registers. For example, if passing a pointer to a parameter block which might be either in the code segment or in the IORegion, the procedure receiving the pointer must have some way of figuring out what segment register to use. One way out of this is to put all variables in the IOR.
Your handler code must contain an externally defined variable called "xyzHandlerID" declared as follows
EXTRN xyzHandlerID: ABS
Note that you really must use "xyzHandlerID", not "xyzHdlrID" or "MyHandlerID" or something else. Opie uses macros to assemble names and you must conform to the pattern. The xyzHandlerID is passed as an argument to Opie macros like %InitializeTask or %Restart.
Your handler must also contain an initialization procedure declared as
xyxInit PUBLIC FAR PROC
.
.
.
xyxInit ENDP
Again, only "xyzInit" will do, not "MyInit" or "xyzInitializtionProcedure" or "HereWeGo".
The code segment for your handler must be named "IOPEInRAM".
(5) Look at all the .asm and .def files you have now in XDE. Remove the line feeds from all of them. (I tried using MakePC to do this and succeeded in removing all the CRs too!) Some files are stored with line feeds, some without. We'll assume no XDE files have line feeds. The *.bat files seem to be an exception - they are often stored with line feeds.
(6) Assemble and link your Handler code, IOR segment and STK segment files. There should be one unresolved reference, xyzHandlerID. That will be resolved in RAMHands.asm. Make a DF file called "xyzHandlerDove.df" which covers the sources, object files and the final link file (which is an 8 character name something like xyxHndlr.lnk).
(7.0) Modify AllocSegs.df (note this is called "AllocSegs" and the others are called "AllocSgs"). Add a clause of the form
Imports [FS6:PARC:Xerox]<ISLDisplay>Display1>DF>xyzHandlerDove.df Of >
Using [IORxyz.obj, STKxyz.obj]
(7.1) Modify the version of AllocSgs.bat you brought over in step 1 so that it pulls over IORxyz.obj and STKoxy.obj (e.g. XFILE RET IORxyz.obj -O). Insert STKxyx.obj into the link command that produces STKSegs.lnk. It must go after STKFlop.obj and before STKEnd.obj. It's safe to put it next to STKCDsp.obj or STKPPO.obj.
As a general rule, don't specify directories or particular machines in the command files. That way they can be used by anyone on any machine.
(7.2) Insert IORxyz.obj into the link command that produces IORSegs.lnk. It must go before IOREnd.obj.
(7.3) In SegLoc.bat, add the size of the xyzSTK segment to the first parameter in the RS clause of the locate command. The size will be listed in the .mp1 file for your linked handler. For example, for the following SegLoc.bat:
SS(IORegion(+1C4H)) &
PC(PURGE) &
RS(13B1H TO 3FFFH) &
AD(SM(IOPEINRAM(10000H)))
the parameter to change is "13B1H" in the RS clause "RS(13B1H TO 3FFFH)". The "+1C4H" allows the IOR to grow from its size in local RAM during booting time to its bigger size in main memory after booting. It won't change. Address 4000H (3FFFH+1) is the start of Main Memory. The 10000H is a screwball way of getting around a bug in the loader that causes it to get upset when it sees 0000. It interpretes 10000H as 00000H (?).
(8) Edit the RAMHands.asm now on your disk. Add an entry of the form:
%Handler(xyz,n,PROC,MEMORY)
where "n" equals the desired number of your HandlerID. Options handler ID's begin at 97. They must be less than 128. So far as I know, the PPO/PSO combination used up 97 and 98. The CDsp color display used 99. Use whatever number is next at the time you add your handler. Remember the number, you'll need to put n-96 into the EEProm later (by hand using the System Configuration Tool).
At this time, you might want to comment out the PPO handler entries (put a "'" immediately after the "%"). This depends on whether you're going to include the PPOHndlr.lnk file in MEMCode.loc. If not, comment it out in RAMHands (see "To toss a handler" below).
(9) Run AllocSgs.bat on the PC. It should pull over all the files, do the assembles, links and locs, producing AllocSgs.loc. If your PC stops with "TOO MANY FILES OPEN", add an entry like "FILES=20" to your Config.sys.
I spent a day finding out that PC-DOS stupidly truncates command lines that are too long. My AllocSgs.bat was producing IORSegs.ln instead of IORSegs.lnk. Watch the lengths of your command lines in ALL the .bat files.
The Medley version of the DF's do a funny thing. They use the released version of AllocSgs, but make three new batch files, AllocIOR.bat, AllocSegs.bat and AllocSTK.bat. AllocSegs.bat uses the other two as line continuation files. AllocSegs.bat binds up all the IOR and STK segments as AllocSgs.bat, except it puts in IORPSO and STKPSO and takes out IORPPO and STKPPO. Since we must modify RAMHands (=> must run AllocSgs.bat anyway), I just changes AllocSgs.bat so it conformed with AllocSegs.bat. That is, I uncommented the lines that bring over IORPSO.obj and STKPSO.obj; commented the lines that bring over IORPPO.obj and STKPPO.obj and replaced IORPPO.obj and STKPPO.obj with IORPSO.obj and IORPSO.obj respectively in the IORSegs and STKSegs link commands.
In this step and the steps below, you can pretty safely ignore warnings from the Linker about POSSIBLE OVERLAP in IOPELOCALRAM. Other warnings and error messages should be taken seriously.
(10) Here's your first looping point. Look at AllocSgs.mp2. Compare it with Perfect.Mp2 (see above). The segment map should start with IOPELOCALRAM, ??SEG, OPIESTK, etc. If it doesn't, the order of the files given to the linker in AllocSgs.bat is wrong. The lask STK entry, ENDSTK, should end at (the address in the RS clause of SegLoc.bat - 1). For example, for the SegLoc.bat given above, the STOP address of ENDSTK should be 013B0H. If the real end address is wrong, adjust the number in SegLoc.bat and loop back to step 9.
Next, look at the START address of IOREGION. It should be 04000H. This is really a double check on the number in SegLoc.bat. If IOREGION doesn't start at 4000H, the reserve clause is either too low (STK entries overflowing above 04000H) or too high (IOR entries falling below the reserved space). In either case, fix it and run it again.
Finally, look at the STOP address of ENDIOR. This is a bit tricky. In the beginning of Daybreak development, the IORegion was divided in half. The part between 4000H and 8000H was used for handler IOR's. The part from 8000H to C000H was used to hold the image of the code that normally sits in PROM when debugging. This worked fine until the IOR's grew out of the bottom half. DSBU fixed this sometime around the 12.5 release. As of today (12-Jul-88 13:14:44), the AIS folks have sort of half-way changed. Their code assumes the space above 8000H isn't sacred, but they haven't bothered to make room for the PROM image at C000H either. If you have some other way of debugging your handler (like using the released SDD Mesa environment), you can use the standard AIS release. That's what I'm doing for the Medley release. Your Lisp system will not be debuggable if the STOP address of ENDIOR is greater than or equal to 08000H. If you never plan to debug your handler in Lisp, fine. Otherwise, you must start throwing out handlers to make things fit. I tossed the PCE, Parity, TTY, RS232C, PSO and PPO handlers. If AIS has gone to the expanded IOR by the time you're working on this, ENDIOR must STOP at 0C000H.
2-Sep-87 17:57:52: Well, there's a bit more to this story. First, as stated in the documentation, RAMCode must fit roughly between 1400H and 4000H. I say roughly because booting tosses some other stuff in there too. Second, MEMCode must fit between ENDIOR and 8000H (current AIS systems that you want to debug) or C000 (current Mesa systems or current AIS systems that you can't debug). Just because ENDIOR is below 8000H, doesn't mean you're done. There's no way to check this here, check it in step 14 below. If things don't fit, you either get to reduce the size of the IORegion (by tossing handlers or using the small version of IOREther.obj) or reduce the size of MEMCode.
To toss a handler:
* Comment out its entry in RAMHands.asm (use the "%'Handler(..." trick).
* Remove its STK entry from the list of things linked to form STKSegs.lnk in AllocSgs.bat
* Remove its IOR entry from the list of things linked to form IORSegs.lnk in AllocSgs.bat
* If the code for the handler lives in IOP local RAM (a "RAM handler"), remove its .lnk file from the list of things linked to produce RAMCode.lnk in RAMCode.bat.
* If the code for the handler lives in Main Memory (a "Memory handler"), remove its .lnk file from the list of things linked to produce MEMCode.lnk in MEMCode.bat.
While we're at it, correlate the entries in RAMHands with those in RAMCode.bat and MEMCode.bat. If a handler is a memory handler (it's linked into MEMCode.lnk), the corresponding entry in RAMHands.asm must end in ",MEMORY)". If the handler is linked into RAMCode.lnk, the entry in RAMHands must end in ",)". This bit me a couple of times. This entry tells the code whether the handler is to be found in main memory or IOP Local RAM. The various PCE code modules are spread between local RAM and Main Memory so unless you really know what you're doing, leave them alone.
Remember, you must run AllocSgs.bat every time you change RAMHands.asm.
(11) Since KyMoInit.asm imports the RAMHands.asm you just changed, run KyMoInit.bat on the PC.
(12) The original RAMMemHandlers.doc said to run RAMOpie.bat at this point. So far as anyone can tell, we haven't changed any of the RAMOpie components, so never mind. However, my version of RAMOpie was built with an old version of STKOpie.obj (see step 1 above) so I had to rebuild it just to get that right. If you have to rebuilt RAMOpie, modify RAMOpie.bat to insert the XFILE and CRLFTool commands as necessary and run it on the PC.
(13.1) Run RAMCode.bat (modifying it to pull over all the files to the PC and send RAMCode.loc back if necessary). This produces RAMCode.loc. Watch out! The comments in RAMCode.bat had gotten out of touch with the files in RAMCodeI.bat, but you couldn't tell just by looking at RAMCode.bat. If you touch the list of files being linked, remember to retain the order. The order of the linking for RAMcode must be: STKSegs.lnk,IORSegs.lnk,RAMHInit.obj,RAMOpie.lnk,{all the ram handlers in any order}.
(13.2) Look at RAMCode.mp2. The same conditions stated in step 10 should apply here (STK segments first, followed by IOREGION at 04000H, ENDIOR not exceeding 08000H or 0C000H depending on what Lisp you're building). RAMCode must fit between ENDSTK and 4000H. That's really not the test since booting is likely to offset the start of RAMCode from ENDSTK, but that's the best you can do for now. In one version of life, the offset was 1450H-13B1H = 9FH.
My original version of RAMCode.bat had some stuff about Ethernet tasks. That task is in PROM in our machines. The commands were commented out. I deleted them.
(14.1) Modify MemCodeI.bat, inserting xyxHndlr.lnk in the list somewhere before "TO". Alternately, merge MEMCode.bat and MEMCodeI.bat and do the same thing. Again, be careful of the order of the files being linked. The order of linking for MemCode must be: IOPLRAM.obj,STKSegs.lnk,IORSegs.lnk,MemHInit.obj,GermInit.obj(or lisp equiv), {all the mem handlers in any order}. Add all the XFILE and CRLFTool commands if necessary (see RAMCode.bat on FS6:).
(14.2) Run MemCode.bat. This produces MEMCode.loc. Inspect the segment map in MEMCode.mp2, watching the same ENDSTK/IOREGION and ENDIOR boundries. Note that booting will actually put the code for MEMCode (the stuff listed in IOPEInRAM) immediately after ENDIOR. If you're using the old debug setup, MEMCode must fit between ENDIOR and 8000H. If you're using the new setup, MEMCode must fit between ENDIOR and C000H.
My MEMCode.bat had some stuff about a new KeyHndlr.lnk (as opposed to a KyMoInit.loc thinger, which is different), also commented out. The Keyboard handler code is also in PROM, so I deleted this too.
(15) Back in XDE (which is where your .bat files have been putting the results of all of your work), run the command file LispDove.cm. This produces LispDove.db. If you get an error message like
Reading... MEMCode.loc Illegal start address as a switch on .loc file.
get a newer version of MakeDoveMicroboot.bcd.
(16) Save the results of your work!! If you're adventurous, ask your favorite Lisp wizard to install the new LispDove.db as Pilot microcode on an 1186 (6085) and go for it! Of course, you can only debug this by watching what happens and staring at your source code. If you want to set breakpoints and stuff, keep reading. Installing your LispDove.db and trying it without your option enabled in the EEPROM (see next step) is certainly a good idea just to see if it is built correctly.
(17) Modify the EEProm using the System Configuration Tool. You should insert the Handler ID you chose minus 96 into one of the three Universal Options entries, along with whatever options specific data and interrupt vectors you like. Without this, Opie will not start your options code. Zero is not a valid options number. It is useful if you want to run your new Pilot Microcode with the new handler turned off, just to see if you've broken anything.
(18) Have a good time debugging! I haven't tried this much yet. You'll probably need the image of Opie that's normally in PROM. If you're using the old debugging setup (ROM Image at 8000H), it's on [Huey:OSBU North:Xerox]<APilot>12.0>DoveMicrocode>Private>B2>RAMSysB2.loc. If you're usign the new setup, It's on [Dino:OSBU North:Xerox]<APilot>14.0>DoveMicrocode>Private>B2>RAMSysB2.loc. There's a Bermuda command file called [FS6:PARC:Xerox]<ISLDisplay>Display1>Software>IOP>IOPDebug.bermuda. Besides loading the pieces of your LispDove.db (not the LispDove.db itself, just the individual pieces) and RAMSysB2.loc into memory, they do lots of interesting stuff.
This is what seems to work for me. Before actually running IOPDebug, manually load all the symbols shown in the commented-out statements. That's because they only need to be loaded once. The first time you do this, you won't have RAMDebug.loc and MEMDebug.loc, but never fear. IOPDebug.bermuda boots the IOP, loads the code for RAMSysB2, turns on main memory and (that's the WriteIO[80,8000];). The write to E01F just fusses with a map register. It doesn't seem to harm anything. Now, the way the initialization code decides whether or not to use the expanded IOR (see step 10 above), is it looks in word 053C. My version of IOPDebug.bermuda writes a 0000H there, telling it not to use fatIOR. If you want fat IOR (the new stuff), write a 4000. Make sure you have the new RAMSysB2.loc if you're using a fat IOR (and not if not).
The command file then fusses with starting the initialization code. For this to get any farther, you must already have your LispDove.db and SYSOUT installed on your disk. Note the commented-out breakpoint at DisplayInit+C. The machine blew up when I did this and worked fine when I didn't, so I got rid if it. I'm told this is a sign of having a version of RAMSysB2.loc that doesn't really match the PROMs in the machine. Well, commenting it out seemed to work, I commented it out. The breakpoint IOPE@Restart is in the DiskInitialDove.db code (whose symbols you must already have fetched. DiskBoot.loc can be found from LispDoveIOPIntegration.df). IOPDebug.bermuda sets a breakpoint in DiskInitialDove at location StartRAM after RAMSysB2.loc has pulled DiskInitialDove into memory. StartRAM is where DiskInitialDove is about to jump off into the RAMCode.loc file. Great, right? Well, not exactly. The DiskInitialDove loader ignores all the location information in the RAMCode.loc file so you don't know where RAMCode is yet. DiskInitialDove just loads RAMCode.loc where it fits. Don't ask me how the segment registers get fixed up. Anyway, when we get to the StartRAM breakpoint, the RAMSysB2 file smashes the Cmos display handler (apparently the normal display handler works well enough and the CMOS one tries to use funny address arithmetic that doesn't work since the PROM image isn't where the PROM is), and stops. Without this smash, the booting process gets stuck around 1191 or 1192. If you stop the IOP, CS=0800 and IP = 97xx. That's your clue that the wrong display handler is running. Your task is to single step over the StartRAM instruction. You get to the first instruction in the RAMCode, which is at a label called RAMInitialization. You read the CS register, AND ONLY THE CS REGISTER! That tells you where the IOPEInRAM segment of RAMCode really starts! For example, if your CS register has 0140 in it, IOPEInRAM starts at 1400H. Swell! Now, you go back and use .bat files (thought you were done, huh?) like [BamBam:OSBU North:Xerox]<WMicro>Dove>RAMDebug.bat, RAMDbLc.bat and MEMDbLc.bat to build RAMDebug.loc and MEMDebug.loc. You put the number from CS into the AD(SM(IOPEINRAM(1400H))) line of RAMDbLc.bat. You put the address of ENDIOR (from MEMCode.mp2) into the corresponding line of MemDbLoc.bat. You'll only use the the symbols for these files! Load the symbols, set your breakpoints and go to town.
Good Luck!!
----------------------------------------------------------------

67
docs/internal/BigBitmaps.TEdit Normal file
View File

@ -0,0 +1,67 @@
Subject: A proposed design for big bitmaps (for Maiko Color (aka Kaleidoscope))
From: shih:mv:envos
Here's a proposed design for big bitmaps (for Maiko Color). This message is also filed as BigBitmaps.TEdit, under {Pogo:MV:envos}<DSUNLISP>Documents>Development>Color>, and {Eris}<lispcore>internal>doc>.
There are basically two alternatives, either change allocblock to allow blocks bigger than 65K, or to change bitblt (and perhaps many other functions) to allow a new datatype, BIGBM.
The following describes the second BIGBM alternative.
------
DESIGN MOTIVATION
The color code currently uses ALLOCPAGEBLOCK to create a non-GC'able large bitmap for the color screen. Windows on that screen, I believe point to that screen bitmap, but Window "backing bitmaps" (the thing that holds what is behind an open window, and what is inside a closed window), is a separate bitmap.
The problem is that the backing bitmap currently cannot be as big as the window would like it to be.
The BIGBM design would keep the noncollectible color screen bitmap, but would allow windows to have BIGBM backing bitmaps. In addition, this design is more likely to be portable backwards (e.g. into Medley1.0 or Medley1.1) since no existing system datatypes need to be changed (unlike the plan to change ALLOCBLOCK).
Since XAIE does not (I believe) allow (currently) DIG operations on closed windows, then there are no DIG operations (except BITBLT) which need to occur on BIGBM backing bitmaps.
Therefore, a BIGBM need merely be a GC'able datatype which supports BITBLT between itself and all other legal datatypes (principally windows and bitmaps, but possible streams (e.g. Interpress), and possible other datatypes).
Longer term, having a generalized BITBLT will be useful, for the following reasons:
Color - 8 bpp bitmaps will begin to push Medley's 32Mb address limitation, and 24 bpp bitmaps certainly will (the screen alone will take up 3Mb = 10% of the address space!).
Remote Bitmaps - there may be applications which need bitmaps outside of the address space (color above for example). Nick Brigg's Maple color processor for the 1186 had a generalized remote bitblt, which "did the right thing" when source and destination bitmaps were both remte (e.g. remote bitblt).
XWindow Medley- might require remote bitmaps.
NonSun Medley - might require remote bitmaps, especially because it is doubtful the SunOS system call MMAP exists elsewhere. When not, the screen itself will need to be remote.
------
BIGBM DESIGN
A straightforward design would be to have a BIGBM simply be a collection of ordinary bitmaps ("slices of the big bitmap"), and then generalize BITBLT to handle the collection (by repeated bitblts).
More elaborate designs would allow BIGBMs to be a collection of any BitBlt'able objects (streams, windows, bitmaps, bigbitmaps), or perhaps collections of raw blocks (to save some of the BITBLT initialization overhead).
Probably at least one dimension of the slices should be a multiple of the LCD (least common denominator) of any TEXTURE (currently 16), so that textures do not show seams across the slices.
Probably also the slices should be "short and fat" (e.g. the BIGBM is made up of several rows of bitmaps), since the ucode inner loop runs in the X direction, but this partially depends on the application.
For example, font bitmaps are short and *very* wide. If large color fonts need a BIGBM font bitmap, then each character would cut across several slices, slowing down each character. For fonts, column slices might be better. Note that each character is also more "coherent" in memory this way, which might improve paging behaviour.
Having BIGBMs be composite objects (rather than a large coherent allocblock) might also improve GC behaviour, because a BIGBM can be allocated out fragmented free space. There may not be enough coherent free space to allocate a large allocblock, due to fragmentation.
Another design elaboration would be to provide full Imagestream capabilities onto BIGBMs, to that (DSPCREATE dest) will work on BIGBMs.
------
BIGBM IMPLEMENTATION
There is currently a draft implementation of BIGBMs on {Eris}<lispcore>internal>library>BIGBM. It has several limitations:
0. It is intended to be a subfunction of BITBLT (which explains the limits 1 & 2 below)
1. It doesn't handle clipping (I'm not sure, but clipping might be handled generically in BITBLT by changing the srcex, srcey, destx, desty, width, & height args).
2. It doesn't handle default arguments (BitBlt does this).
3. It currently only makes the slices 16 bits tall (it should make the slices as big as possible).
4. Its not very efficient. It only walks the slices linearly (the first relevent slice could be found by algebra), and it doesn't stop when the last relevent slice is bltted.
5. Because of 3 & 4, for large bitmaps its roughly 2x slower than normal bitmap blts. For small bitmaps, it may be much worse. This may be OK though for backing color windows, because color windows are large.
Mostly, this code needs to be folded into BITBLT & BLTSHADE, at the appropriate spots, and optimized if necessary.

BIN
docs/internal/CALL-C-SPEC.TEDIT Normal file
View File

Binary file not shown.

BIN
docs/internal/CHAT-GENERIC.TEDIT Normal file
View File

Binary file not shown.

8
docs/internal/CMLERROR-PROPOSAL.TEDIT Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/DAYBREAKS.TEDIT Normal file
View File

Binary file not shown.

454
docs/internal/DIGguide.TEdit Normal file
View File

File diff suppressed because one or more lines are too long

50
docs/internal/DIRECTORY-ORGANIZATION Normal file
View File

@ -0,0 +1,50 @@
<LispCore>Good> : used only for LISP.SYSOUT for MAKEINIT bootstrap
<LispCore>TR> : used for saving the technical reports for Interlisp-D
These are part of the 'release', i.e., should contain only part of what we release, and be snapshot when we relese:
LISPCORE>NEXT => Lisp>Harmony>Basics (more or less)
LISPCORE>CM => Lisp>Harmony>CM, with rename of internals
These release merely by changing "LISPCORE" to "Lisp>Harmony":
LispCore>Doc documentation about the release
LISPCORE>DLION dlion microcode
LISPCORE>DLIONINITIAL>SHUGART>KLAMATH sources for Lisp11SAx000Initial.db
LISPCORE>DLIONINITIAL>TRIDENT>KLAMATH sources for Lisp11TriInitial.db
LISPCORE>LIBRARY sources, .DCOM and documentation for library
LISPCORE>LISPUSERS new versions of LispUsers packages coordinated with Harmony
LISPCORE>MASS new version of MicroAssembler, destined to getting back into SDD
LISPCORE>MESA
LISPCORE>MESASOURCES>* (several subdirectories)
LISPCORE>SOURCES
LISPCORE>UCODE environment for compiling dolphin/dorado microcode
LISPCORE>BCPL environment for making Lisp.RUN for Dolphin/Dorado
LISPCORE>DLIONDOMINO sources for domino (8085 code in DLion)
LISPCORE>DEMO needs to be cleaned up; some go on LispUsers, some on
This should be archived and deleted:
LISPCORE>DLISP Warren Teitelman's DLisp sources
The following should be cleaned up, moved to other directories, private directories, or deleted:
LISPCORE>DIG temporary working directory -- clean up when DIG released
LISPCORE>DLIONINITIAL>TRIDENT>SIERRA obsolete, archive & delete
LISPCORE>DRAWFILES contains a few hacks, can read in with READDRAW and show on iris?
LISPCORE>INTERPRESS temporary working directory
LISPCORE>MAIL => LISPCORE>INTERNAL>MAIL (??)
LISPCORE>MISC I guess some of the other stuff can go here. Need to clean out junk from here
LISPCORE>NEW temporary working directory
LISPCORE>NEW>ARCHIVE temporary working directory
LISPCORE>OLDDOC old documentation files which need to be cleaned up and rewritten, etc.
LISPCORE>ONCOCIN was for ONCOCIN demo. Has some files which we may want to import
LISPCORE>TEST some old test files
LISPCORE>UNKNOWN apropriate name, but should be cleaned up...
plus any file on <LispCore> not on a subdirectory.
Some files on <Lisp>Carol>* and <Lisp>Fugue.6>* should be moved forward to <Lisp>Harmony> if they don't appear on LispCore

BIN
docs/internal/DLD.TEDIT Normal file
View File

Binary file not shown.

5
docs/internal/FASLChangeLog.tedit Normal file
View File

@ -0,0 +1,5 @@
Fasl format change log.
Version 3 (10-Nov-86)
Added opcode 149, FASL-INTERLISP-SYMBOL pname(V).
Upward compatible with version 2.

13
docs/internal/FLOPPY.TEDIT Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/HarmonyReleaseMSG.txt Normal file
View File

Binary file not shown.

BIN
docs/internal/Hashing-MISCN-ops.TEdit Normal file
View File

Binary file not shown.

BIN
docs/internal/Hello.tedit Normal file
View File

Binary file not shown.

31
docs/internal/HowToWriteReleaseNotes.tedit Normal file
View File

@ -0,0 +1,31 @@
Subject: How to write the release notes
To: James
cc: Sannella.pa
How to write a release note for a fixed AR:
When an AR is fixed, it is important to write a release note for the AR, even if it is just a note saying "Release Note: none needed". There is no better time to do this than when the problem is still fresh in your mind. And there is no better person to do this than the implementer, who knows exactly how important the AR fix is.
Does this AR affect the next release? There are some ARs which are created and closed during the course of development. However, it is hard to tell just from the text of the AR. It is important to put this information in the AR, so the Release master can tell that it shouldn't be collected. The note "Release Note: Don't release -- development bug" is better than nothing.
Does this AR affect outside users? If an AR just affects internal users, put a release note "Release Note: Don't release -- internal info" in the AR.
If there is info in the AR that the outside users should know, compose a release note. It doesn't have to be perfect, but the implementer is in a better position to know what needs to be told than anyone else.
A single release note item should be talk about one piece of information. If a single AR contains or refers to multiple subjects, compose multiple release notes.
A release note contains a title, telling the substance of the item. Like AR subjects, the release note title should be short and as informative as possible (think of newspaper headlines). Include as many keywords as possible. For example "* New window functions: FOOBAR, BAZ" is better than "* New window functionality". When documenting bug fixes, try to make the titles "positive", saying "* FOOBAR arguments interpreted correctly" rather than "* Bug fixed where FOOBAR ignored argument".
When in doubt about whether a bug fix or new feature is worth documenting in the release notes, please document it. It is a lot easier for the release master to throw away information than to write it from scratch.
-----
How to assemble individual items into the "Release Notes":
If the individual release note items have been written, the primary job is to sort them by subject and importance, and assemble the big document.
For the Harmony release, the "topics" were ordered loosely on the importance of the different areas for that release (a lot of changes were made to I/O, fonts, printing, so they came first). This order is not sacred.
Within each topic area, the items are sorted by importance to the user, a subjective decision. Major new functionality, and incompatible changes obviously want to come first.

43
docs/internal/ImplManual-DLionDiskDriver.TEdit Normal file
View File

File diff suppressed because one or more lines are too long

152
docs/internal/ImplManual.TEdit Normal file
View File

File diff suppressed because one or more lines are too long

42
docs/internal/InstallLisp.doc Normal file
View File

@ -0,0 +1,42 @@
InstallLisp.doc --- Lichtenberg.wbst, Masinter.PA 8-Jan-85 07:12
This is a tool for those who use both Interlisp-D and XDE. It is similar to Install and friends, except that it is used for installing Interlisp-D virtual memory image files. (For more details about running Interlisp-D at Xerox, contact LispSupport.PA; it requires a DLion with at least 1.5 MB of memory and at least 13000 free pages in a single volume. You must install new Initial microcode Lisp11sax000Initial.db before running Interlisp.)
The syntax is:
InstallLisp volumeName _ fileName/switches
volumeName is the name of the volume that you want the Lisp installed on; fileName is the name of the source file, which may be either local or remote. Switches may be one or more of the following:
/d - set to default boot-lisp (the lisp that will be run when 0-booted)
/s - start the lisp after installation
/x - expand file to fill volume (you should always do this)
To combine switches, do not duplicate the slashes. (to specify all switches, use /dsx).
An alternative command format,
> InstallLisp volumeName/switches
allows one to apply the switches to the file that is already on a volume.
Examples:
>InstallLisp User _ [eris]<Lisp>Harmony>Basics>Full.sysout/xs
Bring over and install Interlisp on the User volume, and boot it when done.
>InstallLisp Lisp _ Lisp.sysout/XS
if you keep a copy in Tajo
> InstallLisp Lisp _ [Eris]<Lisp>Harmony>Basics>Full.sysout
will install the "Harmony" release, as will
> InstallLisp Lisp _ [Phylex:PARC:Xerox]<Lisp>Harmony>Basics>Full.Sysout
> InstallLisp User/s
will merely start the Lisp which was installed on the "User" volume.

205
docs/internal/LIBRARY-DIFFERENCES.12-NOV-85 Normal file
View File

@ -0,0 +1,205 @@
_COMPAREDIRECTORIES(CORE>LIBRARY> >KOTO>LIBRARY>]
Core>library>4045STREAM.;15[ 7-Nov-85 14:48:09/jellinek.pa] newer than >KOTO>LIBRARY>4045STREAM.;2[ 3-Oct-85 14:08:17].
Core>library>4045STREAM.DCOM;14[ 7-Nov-85 14:49:10/jellinek.pa] newer than >KOTO>LIBRARY>4045STREAM.DCOM;2[ 3-Oct-85 14:09:53].
Core>library>BUSTEST.;1[18-Sep-85 03:26:40/Purcell.pa], not found.
Core>Library>BUSTEST.DCOM;1[28-Sep-85 17:44:36/Purcell.pa], not found.
Core>library>BUSTEST.TEDIT;1[18-Sep-85 04:10:19/Purcell.pa], not found.
Core>LIBRARY>C150STREAM.;9[ 7-Nov-85 23:45:02/NUYENS.pa] newer than >KOTO>LIBRARY>C150STREAM.;2[ 4-Oct-85 12:55:37].
Core>LIBRARY>C150STREAM.DCOM;9[ 7-Nov-85 23:54:27/NUYENS.pa] newer than >KOTO>LIBRARY>C150STREAM.DCOM;2[ 4-Oct-85 12:56:58].
Core>LIBRARY>c150stream.tedit;3[ 4-Oct-85 14:48:55/Jellinek.pa] newer than >KOTO>LIBRARY>C150STREAM.TEDIT;1[ 5-Sep-85 14:35:24].
Core>LIBRARY>CENTRONICS.;4[ 8-Nov-85 14:08:03/JELLINEK.pa] newer than >KOTO>LIBRARY>CENTRONICS.;1[ 4-Sep-85 18:41:25].
Core>LIBRARY>CENTRONICS.DCOM;4[ 8-Nov-85 14:08:19/JELLINEK.pa] newer than >KOTO>LIBRARY>CENTRONICS.DCOM;1[ 4-Sep-85 18:41:35].
Core>library>centronics-port.tedit;1[23-Sep-85 17:39:48/jellinek.pa], not found.
Core>LIBRARY>CHAT.TEDIT;4[20-Sep-85 17:09:39/SCHOEN.pa], not found.
Core>LIBRARY>CML.;12[ 4-Nov-85 20:31:16/Fischer.pa] newer than >KOTO>LIBRARY>CML.;1[ 6-Sep-85 22:47:20].
Core>LIBRARY>CML.DCOM;5[25-Oct-85 15:55:06/Fischer.pa] newer than >KOTO>LIBRARY>CML.DCOM;1[ 6-Sep-85 22:47:29].
Core>LIBRARY>CML.IP;1[ 3-Oct-85 15:37:30/FISCHER.pa], not found.
Core>library>cml.tedit;53[ 3-Oct-85 03:42:00/Fischer.pa] newer than >KOTO>LIBRARY>CML.TEDIT;2[15-Sep-85 16:51:00].
Core>LIBRARY>CMLARITH.;9[11-Nov-85 16:11:46/FISCHER.pa] newer than >KOTO>LIBRARY>CMLARITH.;1[ 5-Sep-85 02:58:55].
Core>LIBRARY>CMLARITH.DCOM;9[11-Nov-85 16:13:12/FISCHER.pa] newer than >KOTO>LIBRARY>CMLARITH.DCOM;1[ 5-Sep-85 02:59:25].
Core>LIBRARY>CMLARRAY.;71[11-Nov-85 21:43:37/Fischer.pa] newer than >KOTO>LIBRARY>CMLARRAY.;8[16-Oct-85 14:59:41].
Core>LIBRARY>CMLARRAY.DCOM;65[11-Nov-85 21:47:31/Fischer.pa] newer than >KOTO>LIBRARY>CMLARRAY.DCOM;8[16-Oct-85 15:02:00].
Core>LIBRARY>CMLARRAY.TEDIT;23[26-Sep-85 03:28:59/FISCHER.pa] newer than >KOTO>LIBRARY>CMLARRAY.TEDIT;3[14-Sep-85 03:56:41].
Core>LIBRARY>CMLARRAYINSPECTOR.;3[13-Oct-85 17:03:07/FISCHER.pa] newer than >KOTO>LIBRARY>CMLARRAYINSPECTOR.;1[ 8-Aug-85 01:03:48].
Core>LIBRARY>CMLARRAYINSPECTOR.DCOM;3[13-Oct-85 17:05:51/FISCHER.pa] newer than >KOTO>LIBRARY>CMLARRAYINSPECTOR.DCOM;1[ 8-Aug-85 01:04:35].
Core>LIBRARY>CMLCHARACTER.;18[28-Oct-85 21:29:14/masinter.pa] newer than >KOTO>LIBRARY>CMLCHARACTER.;2[16-Oct-85 17:33:50].
Core>LIBRARY>CMLCHARACTER.DCOM;15[28-Oct-85 21:29:36/masinter.pa] newer than >KOTO>LIBRARY>CMLCHARACTER.DCOM;2[16-Oct-85 17:34:08].
Core>LIBRARY>CMLDEFMACRO.;2[31-Aug-85 17:50:01/ROACH.pa], not found.
Core>LIBRARY>CMLDEFMACRO.DCOM;1[31-Aug-85 17:50:26/ROACH.pa], not found.
Core>LIBRARY>CMLDEFSTRUCT.;8[ 1-Sep-85 23:36:54/ROACH.pa], not found.
Core>LIBRARY>CMLDEFSTRUCT.DCOM;3[ 1-Sep-85 23:43:26/ROACH.pa], not found.
Core>LIBRARY>CMLDEVELOPMENT.;18[ 2-Sep-85 00:21:32/ROACH.pa], not found.
Core>LIBRARY>CMLDEVELOPMENT.DCOM;10[ 2-Sep-85 00:22:04/ROACH.pa], not found.
Core>LIBRARY>CMLEVAL.;15[31-Aug-85 15:51:38/ROACH.pa], not found.
Core>LIBRARY>CMLEVAL.DCOM;3[31-Aug-85 15:51:56/ROACH.pa], not found.
Core>LIBRARY>CMLEXEC.;10[ 8-Nov-85 14:05:17/Masinter.pa] newer than >KOTO>LIBRARY>CMLEXEC.;3[17-Oct-85 18:19:29].
Core>LIBRARY>CMLEXEC.DCOM;10[ 8-Nov-85 14:10:27/Masinter.pa] newer than >KOTO>LIBRARY>CMLEXEC.DCOM;3[17-Oct-85 18:19:41].
Core>LIBRARY>CMLFLOATARRAY.;8[24-Oct-85 16:16:19/Fischer.pa] newer than >KOTO>LIBRARY>CMLFLOATARRAY.;3[30-Sep-85 14:56:02].
Core>LIBRARY>CMLFLOATARRAY.DCOM;10[24-Oct-85 16:18:39/Fischer.pa] newer than >KOTO>LIBRARY>CMLFLOATARRAY.DCOM;2[30-Sep-85 14:57:25].
Core>LIBRARY>CMLFLOATARRAY.TEDIT;8[30-Sep-85 14:52:51/Fischer.pa] newer than >KOTO>LIBRARY>CMLFLOATARRAY.TEDIT;1[ 8-Sep-85 21:36:13].
Core>LIBRARY>CMLFORMAT.;6[ 1-Sep-85 20:19:36/ROACH.pa], not found.
Core>LIBRARY>CMLHASH.;1[ 7-Oct-85 15:54:36/ROACH.pa], not found.
Core>LIBRARY>CMLKBRSTRING.;3[ 7-Oct-85 12:13:41/ROACH.pa], not found.
Core>LIBRARY>CMLLIST.;4[31-Aug-85 20:21:18/ROACH.pa], not found.
Core>LIBRARY>CMLLIST.DCOM;4[31-Aug-85 20:21:45/ROACH.pa], not found.
Core>LIBRARY>CMLLMMSEQ.;1[ 1-Aug-85 16:36:09/MASINTER.pa], not found.
Core>LIBRARY>CMLLMMSEQ.DCOM;1[ 1-Aug-85 21:48:49/MASINTER.pa], not found.
Core>LIBRARY>CMLMACROS.;12[ 1-Sep-85 21:06:06/ROACH.pa], not found.
Core>LIBRARY>CMLMACROS.DCOM;6[ 1-Sep-85 21:07:22/ROACH.pa], not found.
Core>LIBRARY>CMLMISC.;1[31-Aug-85 21:58:16/ROACH.pa], not found.
Core>LIBRARY>CMLMISC.DCOM;1[31-Aug-85 21:58:27/ROACH.pa], not found.
Core>LIBRARY>CMLOPT.;1[14-Aug-85 14:51:04/Masinter.pa], not found.
Core>LIBRARY>CMLPACKAGE.;2[ 1-Sep-85 21:52:45/ROACH.pa], not found.
Core>LIBRARY>CMLPATHNAME.;3[31-Aug-85 22:10:00/ROACH.pa], not found.
Core>LIBRARY>CMLPATHNAME.DCOM;1[31-Aug-85 22:10:16/ROACH.pa], not found.
Core>LIBRARY>CMLPRED.;3[ 1-Sep-85 21:00:31/ROACH.pa], not found.
Core>LIBRARY>CMLPRED.DCOM;2[ 1-Sep-85 21:00:45/ROACH.pa], not found.
Core>LIBRARY>CMLREAD.;7[ 6-Nov-85 17:12:28/Fischer.pa], not found.
Core>LIBRARY>CMLREAD.DCOM;6[ 6-Nov-85 17:12:42/Fischer.pa], not found.
Core>LIBRARY>CMLSEQ.;5[ 1-Sep-85 21:01:05/ROACH.pa], not found.
Core>LIBRARY>CMLSEQ.DCOM;4[ 7-Oct-85 12:35:54/ROACH.pa], not found.
Core>LIBRARY>CMLSETF.;4[ 2-Oct-85 16:06:29/FISCHER.pa] newer than >KOTO>LIBRARY>CMLSETF.;1[ 6-Aug-85 18:47:49].
Core>LIBRARY>CMLSETF.DCOM;2[ 2-Oct-85 16:06:40/FISCHER.pa] newer than >KOTO>LIBRARY>CMLSETF.DCOM;1[ 6-Aug-85 18:48:00].
Core>LIBRARY>CMLSPECIALFORMS.;71[ 7-Nov-85 18:18:22/Fischer.pa] newer than >KOTO>LIBRARY>CMLSPECIALFORMS.;6[23-Oct-85 11:50:15].
Core>LIBRARY>CMLSPECIALFORMS.DCOM;69[ 7-Nov-85 18:21:35/Fischer.pa] newer than >KOTO>LIBRARY>CMLSPECIALFORMS.DCOM;6[23-Oct-85 11:53:32].
Core>LIBRARY>CMLSTRING.;4[10-Sep-85 21:28:02/FISCHER.pa], not found.
Core>library>CMLSTRING.DCOM;4[10-Sep-85 21:28:13/FISCHER.pa], not found.
Core>LIBRARY>CMLSTRUCT.;9[ 8-Nov-85 17:26:52/Kahn.PA] newer than >KOTO>LIBRARY>CMLSTRUCT.;1[ 5-Sep-85 02:57:36].
Core>LIBRARY>CMLSTRUCT.DCOM;7[ 4-Nov-85 21:01:28/Fischer.pa] newer than >KOTO>LIBRARY>CMLSTRUCT.DCOM;1[ 5-Sep-85 02:58:04].
Core>LIBRARY>CMLSYMBOL.;4[29-Aug-85 17:12:36/ROACH.pa], not found.
Core>LIBRARY>CMLSYMBOL.DCOM;2[29-Aug-85 17:13:10/ROACH.pa], not found.
Core>LIBRARY>CMLTYPES.;19[12-Nov-85 14:58:08/FISCHER.pa] newer than >KOTO>LIBRARY>CMLTYPES.;3[26-Sep-85 03:34:07].
Core>LIBRARY>CMLTYPES.DCOM;18[12-Nov-85 15:00:19/FISCHER.pa] newer than >KOTO>LIBRARY>CMLTYPES.DCOM;3[26-Sep-85 03:34:21].
Core>LIBRARY>COLOR.;5[30-Oct-85 11:56:08/Nuyens.pa] newer than >KOTO>LIBRARY>COLOR.;1[ 2-Jul-85 12:13:58].
Core>LIBRARY>COLOR.DCOM;5[30-Oct-85 11:57:34/Nuyens.pa] newer than >KOTO>LIBRARY>COLOR.DCOM;1[ 2-Jul-85 12:14:33].
Core>LIBRARY>COLORNNGS.;8[20-May-85 18:53:59/ROACH.pa], not found.
Core>LIBRARY>COLORNNGS.DCOM;4[20-May-85 18:57:22/ROACH.pa], not found.
Core>library>DANDELIONKEYBOARDS.;2[ 6-Nov-85 05:22:20/sybalsky.pa] newer than >KOTO>LIBRARY>DANDELIONKEYBOARDS.;1[15-Aug-85 12:54:43].
Core>LIBRARY>DANDELIONUFO.;13[ 9-Apr-85 18:13:08/jellinek.pa], not found.
Core>LIBRARY>DANDELIONUFO.DCOM;15[ 9-Apr-85 18:13:42/jellinek.pa], not found.
Core>library>dandelionufo.tedit;1[ 6-Dec-84 14:03:15/Lichtenberg.pa], not found.
Core>LIBRARY>DANDELIONUFO4096.;6[ 8-Mar-85 11:12:41/jellinek.pa], not found.
Core>LIBRARY>DANDELIONUFO4096.DCOM;6[ 8-Mar-85 11:13:22/jellinek.pa], not found.
Core>LIBRARY>DAYBREAKKEYBOARDS.;1[12-Nov-85 14:27:45/sybalsky.pa], not found.
Core>LIBRARY>DICOLOR.;2[15-Aug-85 19:45:04/nuyens.pa], not found.
Core>LIBRARY>DICOLOR.DCOM;2[15-Aug-85 19:45:53/nuyens.pa], not found.
Core>LIBRARY>DINFO.;6[10-Nov-85 17:48:47/cutting.pa] newer than >KOTO>LIBRARY>DINFO.;2[13-Sep-85 16:58:15].
Core>LIBRARY>DINFO.DCOM;6[10-Nov-85 17:49:19/cutting.pa] newer than >KOTO>LIBRARY>DINFO.DCOM;2[13-Sep-85 16:59:43].
Core>LIBRARY>DINFO.INIT;1[13-Sep-85 17:15:15/CUTTING.pa], not found.
Core>LIBRARY>dinfo.tedit;5[10-Nov-85 15:15:16/cutting.pa] newer than >KOTO>LIBRARY>DINFO.TEDIT;1[13-Sep-85 16:51:01].
Core>LIBRARY>DLTTY.;12[12-Nov-85 18:56:24/Schoen.pa] newer than >KOTO>LIBRARY>DLTTY.;3[29-Oct-85 13:59:17].
Core>LIBRARY>DLTTY.DCOM;11[12-Nov-85 18:57:06/Schoen.pa] newer than >KOTO>LIBRARY>DLTTY.DCOM;3[29-Oct-85 14:00:00].
Core>LIBRARY>DORADOKEYBOARDS.;1[12-Nov-85 14:29:48/sybalsky.pa], not found.
Core>LIBRARY>EDITBITMAP.;2[11-Oct-85 16:18:55/blum.pa] newer than >KOTO>LIBRARY>EDITBITMAP.;1[24-Jul-84 18:20:50].
Core>LIBRARY>EDITBITMAP.DCOM;2[11-Oct-85 16:22:38/blum.pa] newer than >KOTO>LIBRARY>EDITBITMAP.DCOM;1[24-Jul-84 18:21:05].
Core>LIBRARY>EDITBITMAP.tedit;2[24-Sep-85 10:51:48/blum.pa] newer than >KOTO>LIBRARY>EDITBITMAP.TEDIT;1[ 6-Jun-85 20:37:30].
Core>LIBRARY>EDITMARK.;3[ 2-Apr-85 11:26:44/burton.pa], not found.
Core>LIBRARY>EDITMARK.DCOM;2[ 2-Apr-85 11:27:42/burton.pa], not found.
Core>LIBRARY>editmark.tedit;5[ 8-Apr-85 16:21:27/Burton.pa], not found.
Core>LIBRARY>ETHERRECORDS.TEDIT;1[ 6-Oct-85 15:10:03/vanMelle.pa], not found.
Core>LIBRARY>EVALSERVER.;1[ 2-Jan-85 12:09:10/Lichtenberg.pa], not found.
Core>LIBRARY>EVALSERVER.DCOM;1[ 2-Jan-85 12:11:05/Lichtenberg.pa], not found.
Core>LIBRARY>EVALSERVER.TTY;1[17-Feb-84 09:40:59/Lichtenberg.pa], not found.
Core>LIBRARY>EXPORTS.ALL;50[20-Sep-85 21:01:49/nuyens.pa] older than >KOTO>LIBRARY>EXPORTS.ALL;3[16-Oct-85 11:44:01].
Core>LIBRARY>FASTFX80STREAM.;5[ 5-Nov-85 20:05:16/jellinek.pa] newer than >KOTO>LIBRARY>FASTFX80STREAM.;2[ 3-Oct-85 16:43:47].
Core>LIBRARY>FASTFX80STREAM.DCOM;4[ 5-Nov-85 20:05:36/jellinek.pa] newer than >KOTO>LIBRARY>FASTFX80STREAM.DCOM;2[ 3-Oct-85 16:44:25].
Core>LIBRARY>FILEBROWSER.;49[20-Oct-85 18:18:43/vanMelle.pa] newer than >KOTO>LIBRARY>FILEBROWSER.;2[28-Sep-85 22:55:55].
Core>LIBRARY>FILEBROWSER.DCOM;48[20-Oct-85 18:19:22/vanMelle.pa] newer than >KOTO>LIBRARY>FILEBROWSER.DCOM;2[28-Sep-85 22:56:13].
Core>LIBRARY>FILECACHE.;13[ 6-Nov-85 16:11:39/Masinter.pa] newer than >KOTO>LIBRARY>FILECACHE.;3[19-Sep-85 15:28:45].
Core>LIBRARY>FILECACHE.DCOM;11[ 6-Nov-85 17:49:09/Masinter.pa] newer than >KOTO>LIBRARY>FILECACHE.DCOM;2[19-Sep-85 15:31:02].
Core>LIBRARY>FILECACHE.TEDIT;1[11-Sep-85 15:13:15/Masinter.pa], not found.
Core>LIBRARY>FILENAMES.;1[12-Mar-85 14:02:35/James.pa], not found.
Core>LIBRARY>FILENAMES.DCOM;1[12-Mar-85 14:03:32/James.pa], not found.
Core>LIBRARY>FILESTUFF.DCOM;1[11-Nov-85 14:47:49/FISCHER.pa], not found.
Core>LIBRARY>FLOATARRAY.DCOM;1[27-Mar-85 08:10:59/Lichtenberg.pa], not found.
Core>LIBRARY>FLOATARRAY.TEDIT;5[ 1-Apr-85 17:45:25/Masinter.pa], not found.
Core>LIBRARY>FREEMENU.;15[ 3-Oct-85 18:03:20/Wozencraft.pa] newer than >KOTO>LIBRARY>FREEMENU.;1[ 7-Sep-85 23:17:27].
Core>LIBRARY>FREEMENU.DCOM;17[ 3-Oct-85 18:04:50/Wozencraft.pa] newer than >KOTO>LIBRARY>FREEMENU.DCOM;1[ 7-Sep-85 23:18:17].
Core>LIBRARY>GRAPHER.;49[30-Sep-85 09:06:35/KAPLAN.PA] newer than >KOTO>LIBRARY>GRAPHER.;1[ 9-Jun-85 22:54:47].
Core>LIBRARY>GRAPHER.DCOM;55[30-Sep-85 09:07:56/KAPLAN.PA] newer than >KOTO>LIBRARY>GRAPHER.DCOM;1[ 9-Jun-85 22:59:02].
Core>LIBRARY>HASH.TEDIT;3[ 4-Oct-85 17:03:59/sybalsky.pa], not found.
Core>LIBRARY>HELPSYS.TEDIT;2[ 9-Nov-85 20:53:53/cutting.pa] newer than >KOTO>LIBRARY>HELPSYS.TEDIT;1[11-Sep-85 12:44:59].
Core>LIBRARY>HRULE.DATABASE;2[17-Oct-85 11:48:47/sybalsky.pa], not found.
Core>LIBRARY>HRULE.TEDIT;2[30-Sep-85 16:16:34/sybalsky.pa], not found.
Core>LIBRARY>IMAGEIO.DCOM;1[20-Jul-85 00:01:04/MASINTER.pa], not found.
Core>LIBRARY>IRM.DINFOGRAPH;1[ 9-Nov-85 17:02:37/Cutting.pa] newer than >KOTO>LIBRARY>IRM.DINFOGRAPH;1[17-Oct-85 22:43:18].
Core>LIBRARY>IRMTOP.TXT;1[13-Sep-85 17:41:32/Cutting.pa], not found.
Core>LIBRARY>KERMITMENU.;12[12-Nov-85 19:52:07/Schoen.pa] newer than >KOTO>LIBRARY>KERMITMENU.;3[ 7-Oct-85 09:54:12].
Core>LIBRARY>KERMITMENU.DCOM;12[12-Nov-85 19:52:45/Schoen.pa] newer than >KOTO>LIBRARY>KERMITMENU.DCOM;4[ 7-Oct-85 09:54:54].
Core>LIBRARY>KEYBOARDEDITOR.TEDIT;8[ 5-Oct-85 11:21:43/sybalsky.pa], not found.
Core>LIBRARY>KINETIC.;1[ 1-Jun-82 16:34:51/Lichtenberg.pa], not found.
Core>LIBRARY>KINETIC.DCOM;1[ 1-Jun-82 16:35:02/Lichtenberg.pa], not found.
Core>library>LispLibrary.tty;1[22-Aug-84 09:42:36/Lichtenberg.pa], not found.
Core>LIBRARY>LISTEN.;3[ 8-Nov-85 14:02:16/Masinter.pa] newer than >KOTO>LIBRARY>LISTEN.;2[14-Oct-85 18:21:26].
Core>LIBRARY>LISTEN.DCOM;3[ 8-Nov-85 14:02:40/Masinter.pa] newer than >KOTO>LIBRARY>LISTEN.DCOM;2[14-Oct-85 18:21:40].
Core>LIBRARY>LISTEN.TEDIT;2[14-Oct-85 18:20:11/FISCHER.pa], not found.
Core>LIBRARY>MAKEDIR.;1[11-Nov-83 17:47:16/Lichtenberg.pa], not found.
Core>LIBRARY>MAKEDIR.DCOM;1[11-Nov-83 17:49:12/Lichtenberg.pa], not found.
Core>library>matmult.tedit;3[15-Oct-85 14:38:55/jellinek.pa], not found.
Core>LIBRARY>MATRIXUSE.TEDIT;2[ 4-Jun-85 12:36:37/Jellinek.pa], not found.
Core>LIBRARY>MINISERVE.TEDIT;1[ 6-Oct-85 15:30:26/vanMelle.pa], not found.
Core>LIBRARY>MSHASH.;5[ 6-Jun-85 17:02:21/Nuyens.pa], not found.
Core>LIBRARY>MSHASH.DCOM;9[ 6-Jun-85 17:03:59/Nuyens.pa], not found.
Core>LIBRARY>MSHASHSYSTEM.;4[28-Jan-85 05:01:46/nuyens.pa], not found.
Core>LIBRARY>NEWMATMULT.;1[ 4-Jun-85 12:48:17/Jellinek.pa], not found.
Core>LIBRARY>NEWMATMULT.DCOM;1[ 4-Jun-85 12:50:14/Jellinek.pa], not found.
Core>LIBRARY>newmatmult.tedit;1[ 4-Jun-85 12:53:49/Jellinek.pa], not found.
Core>LIBRARY>NSCHAT.;9[23-Oct-85 14:32:37/Schoen.pa] newer than >KOTO>LIBRARY>NSCHAT.;1[10-Aug-85 00:26:50].
Core>LIBRARY>NSCHAT.DCOM;9[23-Oct-85 14:33:12/Schoen.pa] newer than >KOTO>LIBRARY>NSCHAT.DCOM;1[10-Aug-85 00:27:25].
Core>LIBRARY>NSMAINTAIN.;24[23-Sep-85 23:32:59/MASINTER.pa] newer than >KOTO>LIBRARY>NSMAINTAIN.;1[ 6-Sep-85 22:45:33].
Core>LIBRARY>NSMAINTAIN.DCOM;17[23-Sep-85 23:33:51/MASINTER.pa] newer than >KOTO>LIBRARY>NSMAINTAIN.DCOM;1[ 6-Sep-85 22:46:12].
Core>LIBRARY>NSTOASCIIDISPLAYFONT.;7[26-Feb-85 10:13:21/KAPLAN.PA], not found.
Core>LIBRARY>NSTOASCIIDISPLAYFONT.DCOM;7[26-Feb-85 10:13:43/KAPLAN.PA], not found.
Core>LIBRARY>PAGEHOLD.;4[19-Jul-85 12:00:41/vanMelle.pa], not found.
Core>LIBRARY>PAGEHOLD.DCOM;4[19-Jul-85 12:04:17/vanMelle.pa], not found.
Core>LIBRARY>PAGEHOLD.TEDIT;1[13-Dec-84 04:30:57/Lichtenberg.pa], not found.
Core>LIBRARY>PCE.;7[ 3-Nov-85 08:55:28/purcell.pa], not found.
Core>LIBRARY>PCE.DCOM;4[31-Oct-85 20:15:17/Schoen.pa], not found.
Core>Library>PCMEMTEST.;1[29-Sep-85 18:11:50/Purcell.pa], not found.
Core>Library>PCMEMTEST.DCOM;1[29-Sep-85 18:50:08/Purcell.pa], not found.
Core>Library>PCMEMTEST.TEDIT;1[18-Sep-85 06:53:16/Purcell.pa], not found.
Core>LIBRARY>PIXELBLT.;2[30-Sep-85 11:44:38/jellinek.pa], not found.
Core>LIBRARY>PIXELBLT.DCOM;2[30-Sep-85 11:44:51/jellinek.pa], not found.
Core>LIBRARY>PIXELBLT.TEDIT;4[30-Sep-85 12:40:48/jellinek.pa], not found.
Core>LIBRARY>PLURAL.;7[16-Dec-84 17:27:22/jonl.pa], not found.
Core>LIBRARY>PLURAL.DCOM;7[16-Dec-84 17:27:30/jonl.pa], not found.
Core>library>PLURAL.TEDIT;1[13-Dec-84 04:21:30/Lichtenberg.pa], not found.
Core>library>Press.im;2[25-Jul-85 16:44:59/Sannella.pa], not found.
Core>LIBRARY>PRINTER.TTY;1[22-Jul-83 16:31:32/Lichtenberg.pa], not found.
Core>LIBRARY>PUPIDSERVER.;1[12-Jun-84 17:01:36/Lichtenberg.pa], not found.
Core>LIBRARY>PUPIDSERVER.DCOM;1[12-Jun-84 17:01:50/Lichtenberg.pa], not found.
Core>LIBRARY>PUPIDSERVER.TXT;1[ 9-Aug-83 10:00:15/Lichtenberg.pa], not found.
Core>LIBRARY>RAID.DCOM;1[11-Nov-85 14:46:04/FISCHER.pa], not found.
Core>LIBRARY>RS232CMENU.;10[12-Nov-85 19:12:26/Schoen.pa] newer than >KOTO>LIBRARY>RS232CMENU.;3[ 8-Sep-85 18:46:41].
Core>LIBRARY>RS232CMENU.DCOM;10[12-Nov-85 19:12:46/Schoen.pa] newer than >KOTO>LIBRARY>RS232CMENU.DCOM;3[ 8-Sep-85 18:47:06].
Core>LIBRARY>SINGLEFILEINDEX.;28[27-Feb-85 09:20:32/KAPLAN.PA], not found.
Core>LIBRARY>SINGLEFILEINDEX.DCOM;28[27-Feb-85 09:21:40/KAPLAN.PA], not found.
Core>library>SINGLEFILEINDEX.Tedit;1[17-May-84 01:48:21/Lichtenberg.pa], not found.
Core>LIBRARY>SKETCHSTREAM.;3[31-Oct-85 09:35:21/Burton.pa] newer than >KOTO>LIBRARY>SKETCHSTREAM.;1[ 5-Oct-85 09:51:42].
Core>LIBRARY>SKETCHSTREAM.DCOM;3[31-Oct-85 09:35:40/Burton.pa] newer than >KOTO>LIBRARY>SKETCHSTREAM.DCOM;2[ 5-Oct-85 09:51:56].
Core>Library>TABLEBROWSER.;3[20-Oct-85 18:19:57/vanMelle.pa] newer than >KOTO>LIBRARY>TABLEBROWSER.;1[19-Sep-85 16:50:40].
Core>Library>TABLEBROWSER.DCOM;3[20-Oct-85 18:20:09/vanMelle.pa] newer than >KOTO>LIBRARY>TABLEBROWSER.DCOM;1[19-Sep-85 16:51:13].
Core>Library>TABLEBROWSERDECLS.;1[18-Sep-85 19:10:58/vanMelle.pa], not found.
Core>LIBRARY>TCP.;17[15-Sep-85 23:35:13/Schoen.pa] newer than >KOTO>LIBRARY>TCP.;1[22-Jun-85 03:23:57].
Core>LIBRARY>TCP.DCOM;19[15-Sep-85 23:37:22/Schoen.pa] newer than >KOTO>LIBRARY>TCP.DCOM;1[22-Jun-85 03:25:23].
Core>LIBRARY>TCP.TEDIT;10[27-Sep-85 10:23:55/schoen.pa] newer than >KOTO>LIBRARY>TCP.TEDIT;1[ 8-Sep-85 23:01:37].
Core>LIBRARY>TCPFTP.;36[ 9-Nov-85 14:43:50/Schoen.pa] newer than >KOTO>LIBRARY>TCPFTP.;2[11-Oct-85 13:50:23].
Core>LIBRARY>TCPFTP.DCOM;37[ 9-Nov-85 14:44:34/Schoen.pa] newer than >KOTO>LIBRARY>TCPFTP.DCOM;1[19-Aug-85 12:08:01].
Core>LIBRARY>TCPTFTP.;18[15-Sep-85 17:56:49/Schoen.pa], not found.
Core>LIBRARY>TEDIT.;46[11-Oct-85 18:55:19/SYBALSKY.pa] newer than >KOTO>LIBRARY>TEDIT.;4[ 3-Oct-85 17:54:26].
Core>LIBRARY>TEDIT.DCOM;50[11-Oct-85 18:56:53/SYBALSKY.pa] newer than >KOTO>LIBRARY>TEDIT.DCOM;4[ 3-Oct-85 17:56:02].
Core>LIBRARY>TEDITCHAT.;4[12-Nov-85 19:53:44/Schoen.pa] newer than >KOTO>LIBRARY>TEDITCHAT.;1[ 4-Sep-85 18:54:14].
Core>LIBRARY>TEDITCHAT.DCOM;4[12-Nov-85 19:54:27/Schoen.pa] newer than >KOTO>LIBRARY>TEDITCHAT.DCOM;1[ 4-Sep-85 18:54:35].
Core>LIBRARY>TEDITHCPY.;43[11-Oct-85 18:42:11/SYBALSKY.pa] newer than >KOTO>LIBRARY>TEDITHCPY.;3[25-Sep-85 17:09:34].
Core>LIBRARY>TEDITHCPY.DCOM;44[11-Oct-85 18:43:58/SYBALSKY.pa] newer than >KOTO>LIBRARY>TEDITHCPY.DCOM;3[25-Sep-85 17:10:16].
Core>LIBRARY>TEDITKEY.;1[ 9-Oct-85 22:11:29/nuyens.pa], not found.
Core>LIBRARY>TEDITWINDOW.;50[11-Oct-85 18:21:02/SYBALSKY.pa] newer than >KOTO>LIBRARY>TEDITWINDOW.;5[ 8-Oct-85 16:40:52].
Core>LIBRARY>TEDITWINDOW.DCOM;53[11-Oct-85 18:23:09/SYBALSKY.pa] newer than >KOTO>LIBRARY>TEDITWINDOW.DCOM;5[ 8-Oct-85 16:43:38].
Core>LIBRARY>TTYCHAT.;2[20-Sep-85 10:22:10/Schoen.pa] newer than >KOTO>LIBRARY>TTYCHAT.;1[ 8-Sep-85 18:18:27].
Core>LIBRARY>TTYCHAT.DCOM;2[20-Sep-85 10:22:48/Schoen.pa] newer than >KOTO>LIBRARY>TTYCHAT.DCOM;1[ 8-Sep-85 18:18:48].
Core>LIBRARY>TWODINSPECTOR.;2[13-Oct-85 17:21:05/FISCHER.pa], not found.
Core>LIBRARY>TWODINSPECTOR.DCOM;2[13-Oct-85 17:22:38/FISCHER.pa], not found.
Core>LIBRARY>twodinspector.tedit;2[10-Oct-85 22:44:47/FISCHER.pa], not found.
Core>LIBRARY>VIRTUALKEYBOARDS.TEDIT;4[ 3-Oct-85 15:06:21/sybalsky.pa] newer than >KOTO>LIBRARY>VIRTUALKEYBOARDS.TEDIT;1[19-Jun-85 11:14:36].
Core>LIBRARY>VTCHAT.;5[12-Nov-85 20:32:32/Schoen.pa] newer than >KOTO>LIBRARY>VTCHAT.;1[26-Aug-85 12:06:22].
Core>LIBRARY>VTCHAT.DCOM;6[12-Nov-85 20:33:18/Schoen.pa] newer than >KOTO>LIBRARY>VTCHAT.DCOM;1[26-Aug-85 12:08:43].

1
docs/internal/LITATOMHASH.TXT Normal file
View File

File diff suppressed because one or more lines are too long

16
docs/internal/LOCALFILE.TEDIT Normal file
View File

File diff suppressed because one or more lines are too long

45
docs/internal/LOCALFILEIMPL.TEDIT Normal file
View File

@ -0,0 +1,45 @@
LocalFile Implementor's Guide
Filed as [eris]<lispcore>internal>doc>localFileImpl.tedit
Written by Tayloe Stansbury 18-Feb-85
Modified by Tayloe Stansbury 15-Aug-85 12:27:46
The Dandlion/Dove local file system is implemented in two files: LocalFile and DskDisplay. User-level documentation for the file system can be found in the 1108 User's Guide or on [eris]<lispcore>doc>localfile.tedit.
The Dandelion/Dove local file system has two layers: the Pilot layer and the Lisp streams layer. The Pilot layer emulates a subset of the Pilot file system, as described in the Pilot Programmer's Manual. The Lisp streams layer implements the Lisp streams specification laid out in [eris]<lispcore>internal>doc>streams.tedit.
The Pilot layer is implemented by three modules in the file LocalFile:
1. LFALLOCATIONMAPCOMS, which keeps track of which pages have been allocated and which are free. LFAllocationMap provides the functionality of [idun]<apilot>11.0>pilot>private>volallocmapimpl.mesa, though its implementation is only very loosely based on that file.
2. LFFILEMAPCOMS, which keeps track of the mapping between file ID numbers and runs of disk pages. This mapping is stored in a specialized B-tree. LFFileMap provides the functionality of [idun]<apilot>11.0>pilot>private>volfilemapimpl.mesa, though its implementation was based more on [idun]<apilot100>pilot>private>volfilemapimpl.mesa, and later updated to be compatible with the Mesa 11.0 release of Pilot.
3. LFPILOTFILECOMS, which has a primitive notion of file, as embodied in its datatype FileDescriptor. LFPilotFile handles things like creating, extending, shrinking, and deleting files; reading and writing file pages; labels; and volume root directories (which map file types onto higher level directories -- e.g. Lisp file type -> Lisp directory ID, Mesa file type -> MFile directory ID, etc.). LFPilotFile does not emulate any particular Mesa file, but rather grew up as the gray area between the two layers became more well-defined during the evolution of the Lisp local file system.
The Lisp stream layer is defined by three more modules in the file LocalFile:
1. LFDIRECTORYCOMS, which implements the Lisp directory. The Lisp directory maps symbolic Lisp file names onto Pilot file ID numbers, and handles directory search and directory enumeration.
2. SCAVENGEDSKDIRECTORYCOMS, which implements a scavenger for the Lisp directory. It works by purging the old Lisp directory, creating a new one, using the BTree to figure out what Lisp files there are on the volume, using the leader page of each Lisp file to figure out what its name is, and then inserting an entry in the new directory for each Lisp file. There is no Pilot-level scavenger implemented in Lisp; for that we rely on the Othello Scavenge Logical Volume command.
3. LFCOMS, which implements all other operations of the local disk file device. LocalFile uses Pilot files as backing files for Lisp streams: page 0 of the Pilot file becomes the stream's leader page (containing stuff GETFILEINFO and the scavenger will be interested in), page 1 of the Pilot file becomes page 0 of the stream, etc. Pilot backing files may be longer than the Lisp stream they hold.
In addition, the file DskDisplay provides a window which displays file system status. This file is separate because it relies on the window system and therefore must be loaded considerably later in the loadup process than LocalFile need be.
Some future projects for the file system (apart from fighting off the stream of ARs):
1. Modify the READPAGES and WRITEPAGES methods to transfer contiguous pages all at once, and set the MULTIBUFFERHINT to be T.
2. Rewrite DiskDlion (which implements the Dandelion/Dove disk head) so that disk requests that cross cylinder boundaries are handled in runs rather than a page at a time (for both the Dandelion and Dove). Without this, large disk requests (which happen especially during deleting) can tie up the system for quite a while.
3. Modify DiskDlion to do a process switch while waiting for the disk. Currently it busy waits.
4. Currently too much of the file system is uninterruptable. Unfortunately, the primitive UNINTERRUPTABLY now prevents process switch in addition to preventing keyboard interrupts. What we really need is a construct that will do the latter but not the former. (There is now an AR for such a beast.) Given that, we should remove as many calls to UNINTERRUPTABLY as possible.
5. Currently files are allocated 20 pages at a time, regardless of whether the openfile request came with a size hint. This was originally because allocating long files sometimes took long enough that NS connections got dropped. Once #2 is accomplished, long allocations should be quite a bit faster though; and #s 3 and 4 will make it possible for other processes to sneak in while allocations are going on. Then it would make sense to change the file system to allocate files all at once when a hint is provided.
6. Currently, allocation map buffers and file map buffers are written out only once per stream creation or deletion. Without automatic built-in scavenging, that strikes me as a bit unsafe (although it does speed things up some). It would probably be better to write them out once every allocation or deallocation (and the performance penalty for doing so will not be too great if allocation requests are larger as a result of #5).
7. Longer term: rewrite the directory so that it uses some form of tree search. The linear search currently used gets unacceptably slow for large directories.
Should you have any questions, do not hesitate to contact me. My mail address is Stansbury.pa, and my extension is 4330. Good luck!

BIN
docs/internal/LeafSpec.press Normal file
View File

Binary file not shown.

BIN
docs/internal/LispARFields.TEdit Normal file
View File

Binary file not shown.

BIN
docs/internal/LispMPCodes.IP Normal file
View File

Binary file not shown.

12
docs/internal/LispMPCodes.TEdit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/LispMPCodes.press Normal file
View File

Binary file not shown.

2
docs/internal/Maiko.DocPointers Normal file
View File

@ -0,0 +1,2 @@
All the documentation for Maiko (Medley running on Suns, AKA the bytecode emulator) resides on {Pogo:AISNorth:Xerox}<DsunLisp>Documents>.

99
docs/internal/MakeLispFloppies.doc Normal file
View File

@ -0,0 +1,99 @@
-- MakeLispFloppies.doc
-- Last edit 11-Oct-84 16:27:50 by Masinter
-- Instructions for building Floppies for installing Interlisp-D on 1108s
-- Follow these instructions if running in Mesa 11.1 Tajo or Copilot.
-- To execute these commands, make sure the insertion point is in the
-- Executive window (by clicking left mouse button in Executive window).
-- Then, while holding the "Copy" key down, select the command you want to
-- execute (including the "return" at the end of line.) When you let up on
-- Copy, the command will be "unread" the Executive input buffer.
-- Before you transfer files, you should have approximate 6000 pages
-- in your volume to contain all the files.
-- If you want to keep the files separate, you can work on separate directory
-- to keep files in one place.
Create FloppyFiles -- creates a new directory
push FloppyFiles -- puts the directory on your search path (like Connect)
-- bring over tool for making floppies.
-- Change "Iris" to to the name of the server has Mesa closest to you (Phylum and Rose are candidates)
ftp Iris directory/c Mesa>11.0 retrieve/a<> MakeDLionBootFloppyTool.bcd FloppyInitial.db Mesa.db MoonBoot.db DLion.germ
-- get Lisp specific files:
ftp Eris directory/c Lisp>Harmony>Mesa ret/<>A HelloDLion.boot directory/c Lisp>Harmony>CM retrieve/<>A GetHello.othello GetLisp.othello PartitionLisp.othello PartitionLispTajo.othello PartitionLispStarTajo.othello
-- now start up tool. Execute:
MakeDLionBootFloppyTool.bcd
-- Insert new floppy
-- Make the following settings in MakeDLionBootFloppyTool:
-- Drive: 0 -- default is correct --
-- Floppy Name: LispOthello -- *** CHANGE THIS ONE *** --
-- Initial uCode: FloppyInitial.db -- default is correct --
-- Diagnostic uCode: MoonBoot.db -- default is correct --
-- Pilot uCode: Mesa.db -- default is correct --
-- Germ File: DLion.germ -- default is correct --
-- Boot File: HelloDLion.boot -- *** CHANGE THIS ONE *** --
-- Turn on all three options (Format Floppy, Reserve Last Cylinder For Diagnostics, Install Boot Files) and button Start!
-- Now execute the following WITHOUT REMOVING FLOPPY:
floppy write Lisp11SAx000Initial.db DLion.germ Mesa.db HelloDLion.boot getLisp.othello PartitionLisp.othello PartitionLispTajo.othello PartitionLispStarTajo.othello
floppy info list/v
----------------------------------------------------
-- You have now made a "LispOthello" diskette
----------------------------------------------------
-- To make a floppy with a SYSOUT on it, generally you should use Lisp:
-- COPYFILE of a file to floppy (after FLOPPY.MODE(SYSOUT)) or SYSOUT({FLOPPY})
-- work. However, you can also do this from Tajo:
ftp Eris directory/c Lisp>Harmony>Basics ret/A<> Lisp.SYSOUT
-- Insert a new floppy, then do the following. The "--y" is so that if it asks you if you want to overwrite, it will get a "Yes" response after complaining about the "--", but if it doesn't ask, the "--y" will get ignored.
floppy format "Lisp Sysout '#1"/n
-- y
floppy write lisp.sysout[0..2249]/s lisp.sysout
floppy info list/v
-- Insert a new floppy, and then
floppy format "Lisp Sysout '#2"/n
-- y
floppy write lisp.sysout[2250..4499]/s lisp.sysout
floppy info list/v
-- If SYSOUT>4499 pages, insert a new floppy, and then:
floppy format "Lisp Sysout '#3"/n
-- y
floppy write lisp.sysout[4500..6749]/s lisp.sysout
floppy info list/v
-- If SYSOUT>6749 pages, insert a new floppy, and then:
floppy format "Lisp Sysout '#4"/n 3/f
-- y
floppy write lisp.sysout[6750..8999]/s lisp.sysout
floppy info list/v
floppy format "Lisp Sysout '#5"/n 3/f
-- y
floppy write lisp.sysout[9000..11499]/s lisp.sysout
floppy info list/v
-- done (extend for sysouts bigger than 11500 pages). If any changes to files were made, back up:
-- stop working in the "FloppyFiles" subdirectory
pop

BIN
docs/internal/Making-a-Patch.TEdit Normal file
View File

Binary file not shown.

136
docs/internal/Motown-wishlist.TEdit Normal file
View File

@ -0,0 +1,136 @@
Hardware:
Bigger Disks
Faster local IFSs
Color display
Sell better peripherals
Laser writer
better file server
SCSI
Labelless Disks
Streaming Tape
Documentation:
Updated and online doc
Improved documents
Consistent paradigm for writing documents (IM formatting replacement)
Make system easy to learn
Window system / User interface:
Interruptable pop-up Menus
TIP tables
Remote Windows
Faster text display
Imager
Image Streams
clean up code
collapse common code
add clipping
Rethink & overhaul Image Objects
Loopsified window system
Consistent look & feel (window UI and commands)
User interface as consistent as Viewpoint or Macintosh
Same keying or mousing gets same op everywhere
Cheap, Pervasive Text (TTYIN replacement)
Symbol ESC completion on type-in
Programming Environment:
Same machine low-level debugger
Source level debugger
Good stepper
NS based Teleraid
Teleraid and CL stack ops
revert
return from
Teleraid Inspect
Interactive Interface to File manager
Better File Browser
Definition groups
Extensible SEdit
Programmers Interface to SEdit
More Common Lisp integration
Higher level language features:
Unification
Single, Common prettyprinter
Fast prettyprinter
Path name cleanup
use pathnames all the way down
get SAME object always for same file
Single Compiler
Decouple DWIM - CLISP
Fast sequence functions
Ropes
System building and installation:
Non-Dorado loadups
FASL in the init
Packages in the init
Common Lisp primacy, eg in the init
State saving smaller than sysout-sized
Revamp software Installation process
better user interface
written in Lisp, not Mesa
FAST
include error Recovery
Language kernel:
Big Reference counts w/microcode support
Full GC (circular objects)
Get arith to IEEE compliance
GCable Symbols
Unboxed floating point compler
Finalization of GCed objects
Smaller base sysout
More Common Lisp microcode, eg EVAL
Common Loops IN the system
Operating system:
Pre-emptive scheduler
Non-consing Synchronizers (monitorlocks)
Device drivers:
SNA networking
Floppy speed
Improve local disk speed
Real Subdirectories
Support File Cacher
Reliable TCP & RS232
Run in XNS only world
Run in Stand Alone World
Sun NFS support
XNS over phone lines
Applications:
Video Image Manipulation
Bitmap Editor as good as MacPaint
Mail support for
X.400
SMTP
Release Lafite
Lisp based File Server
3270 terminal emulator
Good 3rd party software development path
Database
Spreadsheet
AR category clean up
Programming system Management Tools
Adobe Tools
Notecards
TEdit
Footnotes
Index
toc
egns
styles
LPT output
change masks
better than Tex
WYSIWG Page mode
DES/DIS/DIF/VP convert
Easier Landscape Printing
YACC and such
C, Fortran, Pascal, Cobol
Work environment:
Work at Home
Better design process

5
docs/internal/NSCharacters.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/OPCODES-IMPL.TEDIT Normal file
View File

Binary file not shown.

1
docs/internal/OPCODES.STATUS Normal file
View File

@ -0,0 +1 @@
"SNOW.PA" "21-Sep-87 14:18:20"

BIN
docs/internal/OPCODESURVEY.TEDIT Normal file
View File

Binary file not shown.

BIN
docs/internal/PORT.NOTEFILE Normal file
View File

Binary file not shown.

20
docs/internal/RETCALL.MAIL Normal file
View File

@ -0,0 +1,20 @@
*start*
00530 00024 US
From: masinter.PA
Date: 17-Jul-86 22:42:29 PDT
Subject: Re: [STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU: Tail Recursion in Common Lisp ???]
In-reply-to: Pavel's message of 17 Jul 86 20:57 PDT
To: Pavel
cc: TamarinCore^
for the curious, I did an experiment with tail recursive call. There's an "opcode" called RETCALL, complete with UFN which fakes it using the standard awful hacks.
The simplest spec is that
RETCALL <n> <name>
works like
FNX <n> <name>
except that it throws away the current frame first.

BIN
docs/internal/SEdit.NOTEFILE Normal file
View File

Binary file not shown.

BIN
docs/internal/SOURCEFILES.TEDIT Normal file
View File

Binary file not shown.

BIN
docs/internal/STREAMS-KOTO.PRESS Normal file
View File

Binary file not shown.

204
docs/internal/STREAMS-KOTO.TEDIT Normal file
View File

File diff suppressed because one or more lines are too long

177
docs/internal/STREAMS.TEDIT Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/SYSTEM.NOTEFILE Normal file
View File

Binary file not shown.

2
docs/internal/StackFig.sketch Normal file
View File

File diff suppressed because one or more lines are too long

16
docs/internal/StackFormat.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/TEDITSTREAM.TEDIT Normal file
View File

Binary file not shown.

BIN
docs/internal/allegro.ip Normal file
View File

Binary file not shown.

BIN
docs/internal/allocblock.mail Normal file
View File

Binary file not shown.

388
docs/internal/briefingBlurb-DRAFT.tedit Normal file
View File

File diff suppressed because one or more lines are too long

138
docs/internal/codeimage.bltchar Normal file
View File

@ -0,0 +1,138 @@
\BLTCHAR
114 opcodes
1 free variable lookup (possibly more)
100: 21 160 6 BIND ; [pvar0] .. [pvar6]
103: 100 IVAR CHARCODE
104: 154 377 SIC 255
106: 345 LOGAND2
107: 134 PVAR_ [pvar4]
110: 277 POP
111: 102 IVAR DISPLAYDATA
112: 144 COPY
113: 311 76 GETBASEPTR.N
115: 100 IVAR CHARCODE
116: 343 LRSH8
117: 360 EQ
120: 246 TJUMP-> 130
130: 311 16 GETBASEPTR.N
132: 225 FJUMP-> 141
141: 102 IVAR DISPLAYDATA
142: 311 0 GETBASEPTR.N
144: 133 PVAR_ [pvar3]
145: 102 IVAR DISPLAYDATA
146: 311 60 GETBASEPTR.N
150: 114 PVAR [pvar4]
151: 320 ADDBASE
152: 310 0 GETBASE.N
154: 330 IPLUS2
155: 131 PVAR_ [pvar1]
156: 102 IVAR DISPLAYDATA
157: 311 30 GETBASEPTR.N
161: 361 IGREATERP
162: 235 FJUMP-> 201
(freplace (\DISPLAYDATA DDXPOSITION) of DISPLAYDATA with (IPLUS CURX (\DSPGETCHARWIDTH CHAR8CODE DISPLAYDATA)))
201: 102 IVAR DISPLAYDATA
202: 113 PVAR [pvar3]
203: 102 IVAR DISPLAYDATA
204: 311 20 GETBASEPTR.N
206: 114 PVAR [pvar4]
207: 320 ADDBASE
210: 310 0 GETBASE.N
212: 330 IPLUS2
213: 24 0 RPLPTR.N
215: 277 POP
216: 102 IVAR DISPLAYDATA
217: 311 4 GETBASEPTR.N
221: 270 PVAR_^ [pvar0]
222: 113 PVAR [pvar3]
223: 110 PVAR [pvar0]
224: 330 IPLUS2
225: 273 PVAR_^ [pvar3]
226: 111 PVAR [pvar1]
227: 110 PVAR [pvar0]
230: 330 IPLUS2
231: 131 PVAR_ [pvar1]
232: 102 IVAR DISPLAYDATA
233: 310 43 GETBASE.N
235: 130 PVAR_ [pvar0]
236: 361 IGREATERP
237: 221 FJUMP-> 242
242: 113 PVAR [pvar3]
243: 102 IVAR DISPLAYDATA
244: 310 42 GETBASE.N
246: 130 PVAR_ [pvar0]
247: 361 IGREATERP
250: 221 FJUMP-> 253
253: 110 PVAR [pvar0]
254: 272 PVAR_^ [pvar2]
255: 111 PVAR [pvar1]
256: 112 PVAR [pvar2]
257: 361 IGREATERP
260: 264 170 NFJUMPX-> 450
262: 102 IVAR DISPLAYDATA
263: 311 52 GETBASEPTR.N
265: 130 PVAR_ [pvar0]
266: 6 14 256 DTEST PILOTBBT
271: 310 11 GETBASE.N
273: 152 '0
274: 360 EQ
275: 263 152 TJUMPX-> 447
277: 150 'NIL
300: 135 PVAR_ [pvar5]
301: 276 PVAR_^ [pvar6]
302: 127 16 FVARX \SOFTCURSORP
304: 262 42 FJUMPX-> 346
346: 101 IVAR DISPLAYSTREAM
347: 140 30 161 GVAR \TOPWDS
352: 360 EQ
353: 255 TJUMP-> 372
372: 110 PVAR [pvar0]
373: 112 PVAR [pvar2]
374: 315 2 PUTBASE.N
376: 277 POP
377: 110 PVAR [pvar0]
400: 111 PVAR [pvar1]
401: 112 PVAR [pvar2]
402: 331 IDIFFERENCE
403: 315 10 PUTBASE.N
405: 277 POP
406: 110 PVAR [pvar0]
407: 102 IVAR DISPLAYDATA
410: 311 22 GETBASEPTR.N
412: 114 PVAR [pvar4]
413: 320 ADDBASE
414: 310 0 GETBASE.N
416: 112 PVAR [pvar2]
417: 330 IPLUS2
420: 113 PVAR [pvar3]
421: 331 IDIFFERENCE
422: 315 6 PUTBASE.N
424: 277 POP
425: 110 PVAR [pvar0]
426: 152 '0
427: 166 PILOTBITBLT
430: 277 POP
431: 116 PVAR [pvar6]
432: 231 FJUMP-> 445
445: 151 'T
446: 20 RETURN

54
docs/internal/codeimage.dspprintchar Normal file
View File

@ -0,0 +1,54 @@
Code for \DSPPRINTCHAR. Best case:
42 opcodes.
3 free variable lookups.
1 function call.
2 unnecessary DTESTs (since not tested at 101).
100: 100 IVAR STREAM
101: 311 60 GETBASEPTR.N
103: 21 1 0 BIND DD;
106: 140 24 273 GVAR \CARET.UP
111: 224 FJUMP-> 117
117: 126 FVAR *DRIBBLE-OUTPUT*
120: 262 35 FJUMPX-> 155
155: 101 IVAR CHARCODE
156: 154 377 SIC 255
160: 361 IGREATERP
161: 262 31 FJUMPX-> 212
212: 127 16 FVARX \PRIMTERMSA
214: 101 IVAR CHARCODE
215: 302 GETBASEBYTE
216: 154 30 SIC 24
220: 345 LOGAND2
221: 144 COPY
222: 152 '0
223: 360 EQ
224: 262 146 FJUMPX-> 372
226: 277 POP
227: 101 IVAR CHARCODE
230: 144 COPY
231: 154 15 SIC 13
233: 361 IGREATERP
234: 262 31 FJUMPX-> 265
236: 100 IVAR STREAM
237: 110 PVAR DD
240: 13 30 231 FN3 \BLTCHAR
243: 277 POP
244: 100 IVAR STREAM
245: 6 1 15 DTEST STREAM
250: 100 IVAR STREAM
251: 6 1 15 DTEST STREAM
254: 310 6 GETBASE.N
256: 153 '1
257: 324 PLUS2
260: 315 6 PUTBASE.N
262: 261 1 161 JUMPXX->1043
1043: 150 'NIL
1044: 20 RETURN
1045: 0 -X-

120
docs/internal/concordia.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/fontchars.ip Normal file
View File

Binary file not shown.

BIN
docs/internal/fontchars.tedit Normal file
View File

Binary file not shown.

BIN
docs/internal/fpbenchmarks.tedit Normal file
View File

Binary file not shown.

1
docs/internal/freemenu.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/gcoverview.tedit Normal file
View File

Binary file not shown.

11
docs/internal/how-to-references.tedit Normal file
View File

@ -0,0 +1,11 @@
Additional information on "How-To" can be found on:
{Eris}<Sybalsky>How-to>
such as:
Installing New 1108 ucode
Running AR cleanup
Seding info to Sales
Writing AR test cases

BIN
docs/internal/iddescription.tedit Normal file
View File

Binary file not shown.

BIN
docs/internal/opcode-review.tedit Normal file
View File

Binary file not shown.

BIN
docs/internal/opcodes.tedit Normal file
View File

Binary file not shown.

BIN
docs/internal/sedit/LIST-FORMATTING.tedit Normal file
View File

Binary file not shown.

BIN
docs/internal/sedit/RELINEARIZATION.tedit Normal file
View File

Binary file not shown.

54
docs/internal/sedit/linearizer.tedit Normal file
View File

@ -0,0 +1,54 @@
SEdit Linearizer Internal Documentation
Fields in the context:
CurrentNode
The node whose linear form is currently being computed.
LinearPointer
Points to the "next" item in the linear form. This is the item with which the next generated item will be compared, and the item before which it will be inserted if it doesn't match.
LinearPrev
If LinearPrev is a cons, (CDR LinearPrev) is LinearPointer (LinearPrev is one behind LinearPointer in the linear form). Otherwise, it's a node, and (fetch LinearForm of LinearPrev) is LinearPointer. Used to fixup linear form.
CurrentLine
The LineStart most recently generated in the linear form.
CurrentX
The X coordinate at which the next linear item will be displayed.
RightMargin
The right margin for generating the linear form.
CurrentBlock
The LineBlock describing the most recently generated linear items on this line. Reset to FirstBlock at the end of each line displayed.
FirstBlock
The beginning of the LineBlock list. The LineBlocks from FirstBlock to CurrentBlock describe the segment of the linear form between CurrentLine and LinearPointer, indicating which parts are already available in the window for BITBLTing and which will have to be repainted.
Matching?
Means something like: the linear form we're generating has been matching the linear form that was already there (at least since the beginning of CurrentNode)
Below?
T if the linear form we're generating is definitely off the bottom of the screen. NIL if it might have to be displayed. 'new if we're redisplaying from scratch (nothing to BLT).
Visible?
T if we're matching and the bits we're matching are actually on the screen.
RelinearizationTimeStamp
NIL if we're prettyprinting, otherwise incremented by 1 each time we relinearize from the top. Used to determine the validity of cached info in LineStarts
RepaintStart
RepaintLine
RepaintX
If there are no bits to be reused at the end of a line, we postpone displaying it until we find something that needs to be moved (or we get to the end of the window). This can go on for many lines. during this time, RepaintStart records where the painting needs to start from, RepaintLine has the y information, and RepaintX records where the painting will start from. It may always be the case that
RepaintLine = (CAR RepaintStart)
RepaintX = (fetch Indent of RepaintLine)
Fields in EditNodes:
StartX
The X coordinate at the time this node was linearized. not sure what 0 means (something magic). \\reuse.linear.form seems to think this means that the node is atomic and hasn't been displayed before.
The coordinate system:
The top left corner is (1,-1) (or maybe (0,0)?). Therefore everything's displayed with positive x and negative y (bottom right quadrant).

7
docs/internal/sedit/list-formats.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/sedit/node-types.tedit Normal file
View File

Binary file not shown.

4
docs/internal/sedit/old/LISP-PrettyPrinting.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/sedit/old/code-editing.tedit Normal file
View File

Binary file not shown.

73
docs/internal/sedit/old/details.tedit Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/sedit/old/intro.tedit Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/ARRAY-FREE.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/ARRAYBLOCK.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/COMPFORM.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/CSPEC.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/DEVELOP.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/DISP-BITMAP.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/DLFAULTINIT.SKETCH Normal file
View File

Binary file not shown.

1
docs/internal/sketches/DOC/EVALFORM.SKETCH Normal file
View File

File diff suppressed because one or more lines are too long

BIN
docs/internal/sketches/DOC/FAULTHANDLE.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/INTERP.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/LINKBLOCK.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/LOCKEDPAGEP.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/LOOKUPPAGEMAP.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/MOVEDISPLAY1.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/MOVEDISPLAY2.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/MOVEIOCB.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/NEWCONS.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/OPCODES.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/REPEAR-EVALQT.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/RESETSTACK0.SKETCH Normal file
View File

Binary file not shown.

BIN
docs/internal/sketches/DOC/RPMAP1.SKETCH Normal file
View File

Binary file not shown.

1
docs/internal/sketches/DOC/RPMAP2.SKETCH Normal file
View File

File diff suppressed because one or more lines are too long

Some files were not shown because too many files have changed in this diff Show More