@c ;;; -*- Mode:Text; Package:User; Base:10 -*- @library(gsi-patbo) @library(lisp) @library(gsi) @tolerance 300 @overfullrule 0in @setpagewidth 6.25in @textbodyindent = 0.5in @begin(document) @baselineskip 13pt @parskip = 0.2in @parindent = 0in @secheadingskip .25in @defindex cp @settitle K/Mac Interface @setx titlecomment Design Issues and Requirements @setx gsipart Rev 1 - @datestamp @headings off @titlepage @copyrightpage @sp 2 @center @b[THIS DOCUMENT IS CONFIDENTIAL AND PROPRIETARY] This is a draft requirements specification for the proposed K-machine / Macintosh interface. The interface is referred to within as ``K/Mac''. The program that implements the Macintosh-resident portion of the interface is referred to within as ``the application''. The contents of this document are the result of meetings held in Cambridge during May and June, 1988. @sp 2 Comments on this document should be addressed to David Saslav (saz@@gsi-cam) or Keith Corbett (keith@@gsi-cam). @end(copyrightpage) @setchapternewpage odd @headings on @evenheading @thispage@|@|@thistitle @oddheading @thistitle@|@|@thispage @chapter K/Mac Interface Structure and Procedure The discussion below of booting the K-Machine from the Macintosh application needs further research and refinement. The K/Mac boot process, and the user's interface, differs from the ``brute force'' approach used to boot the K from the Lambda. @section K/Mac Boot Process K/Mac applications (those responsible for booting up the K from the Macintosh) use a standard boot procedure: @sp 2 @settabs 4 @columns @< @\ @i(Step) @\ @i(Goal) @cr @sp 2 @< @\ 1. Boot Up @\ Mac application @cr @< @\ 2. Find @\ Bus Couplers @cr @< @\ 3. Initialize @\ Bus Couplers @cr @< @\ 4. Scan @\ Nubus all boards @cr @< @\ 5. Find @\ K Memory / Processors @cr @< @\ 6. Pair Up @\ K Memory / Processors @cr @< @\ 7. R/W Test @\ Bus, boards @cr @< @\ 8. Initialize @\ K Memory Board (& disable bad sections) @cr @< @\ 9a. Test @\ Low K Memory @cr @< @\ 9b. Test @\ K Memory boundaries @cr @< @\ 10. Load @\ K Low Memory (IR cache?) @cr @< @\ @\ @ (include comms. area) @cr @< @\ 11. (Optional) Test @\ Complete K memory check (is K damaged?) @cr @< @\ 12. Initialize @\ K Processor @cr @< @\ 13. Start @\ K Processor @cr @< @\ 14. Allocate @\ Screen @cr @< @\ @\ Keyboard/Mouse @cr @< @\ @\ Paging Descriptor @cr @< @\ @\ File System Table @cr @< @\ @\ Device Table @cr @< @\ 15. Fill In @\ Screen Descriptor @cr @< @\ 16. Fill In @\ Paging Descriptor @cr @< @\ 17a. Fill In @\ Configuration Record @cr @< @\ 18a. Load Options @\ for @l(si:lisp-reinitialize) @cr @< @\ 19b. Read Over @\ Initial KFSL files @cr @cleartabs Late in the sequence, the K performs certain operations in series with steps performed by the Macintosh application. These K boot operations are numbered in conjunction with the Mac operations listed above. @sp 2 @settabs 4 @columns @< @\ 17b. Read In @\ Configuration Record @cr @< @\ 18b. Call Options @\ @l(si:lisp-reinitialize) @cr @< @\ 19a. Read In @\ Initial KFSL files @cr @cleartabs @section Configuration Record File A Macintosh file will hold certain information to be managed by the K/Mac application and passed to the K processor(s) at boot time. The configuration record data items include: @enumerate @item Processor(s) (serial #) to run within the application; @item Mac's (host) name; @item Memory enabled/disabled sections; and @item Volume and File-ID of default world load file. @end(enumerate) There is no uniform standard for where to look for the host name on the Mac. For example, TOPS (one popular network software package) stores it as the "User Name" 'STR ' resource. It puts this in the file "Tops Prep", which does not exist if some other network software is being used. The ``world load file'' is the K/Mac equivalent of the Lambda ``load band''. @chapter K/Mac Shared Memory @section Memory Cache and Mapping @c include kmemory @section Data Formats Although shared memory resides physically on the K, storage conventions for data within K/Mac shared memory will follow Macintosh standards. That is, the convention for byte-ordering, argument and value strings, etc., will be specified to be MAC-friendly as required. Each individual shared memory location will denote either a 32-Bit scalar quantity or physical address within K memory where the data resides. Pointers to locations outside of the major header area (i.e., control blocks) reside in static memory on the K (in a safe, wired, non-GC-able place) The following is a fractional Pascal-like specification for the command and argument portions of a control block: @example CMD: (CMD1, CMD2, ... CMDn) {enumerated sequence} ARG: ARRAY [0..255] of LONGINT; @end(example) @itemize - @item K-Owned, K-Allocated @item Slot-relative (i.e., pointers are absolute, non-relocatable physical addresses in low K memory.) @item No type codes included in the control blocks. @end(itemize) Issue: Use a pre-determined starting address in shared memory (i.e., same for all machines?) or a dynamic location (e.g., specified in K config PROM)? Any K-to-Mac initialization information could conceivably be located in the K's config PROM, accessible to the Mac application. @section K Configuration Prom GSI-CAM is currently working on completing the specificaton of the final layout of the K Config PROM. Suggested additions include a unique (serial) ID for each machine produced. Benefits include: @itemize * @item Advantages to VAR's @item Advantages to third-party S/W vendors @item Ease of solving MOBY addressing problems. @end(itemize) @section K/Mac Shared Memory -- Diagram In the shared memory diagram on the next page, and in all diagrams that follow, the following symbolic conventions apply: @display ----> Arrows indicate pointers to structures at other physical locations within shared memory. Structure-Name Mixed case indicates a structure name. NUMERIC-CONSTANTS Upper case indicates numeric constants. {Variable-Values} Braces indicate variable values. [ Thirty-Two-Bit-Word ] Brackets enclose each 32-bit word. [ {Variable-23} / Contiguous 16-bit half-words {Variable-47} ] are separated by a slash. @end(display) @page @center THE K-MACHINE/MACINTOSH SHARED MEMORY SPACE (K-MAC-AREA) @smalllisp ********************************* K-MAC-Area ********************************* Header-Table ********************************* [ MAC-K-AREA-HEADER-TOKEN ] ;Verify pattern [ {HOW-MANY-K-MACHINES} ] ;Count of K machines avail. [-->Major-Command-Block ] ;Fast global commands [-->Keyboard-Mouse-Command-Block] ;Keyboard/mouse commands [-->Screen-Descriptor-Block ] ;Screen drawing commands [-->Paging-Command-Block ] ;Paging, world load [-->FileSystem-Table ] ;Access to MAC file system [-->Network-Area ] ;Access to MAC network controller(s) [-->Serial-Port-Area ] ;Serial I/O / modem [-->Printer-Area ] ;Access to MAC printing : ********************************* Major-Command-Block ********************************* [ {K-To-MAC-Command-Opcode} ] ;Table (to be done) [ {K-To-MAC-Status} ] ;0=null, 1=ongoing, -1=finished [ {K-to-MAC-Argument-Count} ] ;Or fixed # arguments? [ {K-to-MAC-Argument-1} ] ;Argument length/string : [ {K-to-MAC-Argument-N} ] ;How many? [ {K-to-MAC-Values-Count} ] ;Or fixed # values? [ {K-to-MAC-Values-Block-1} ] ;Argument length/string : [ {K-to-MAC-Values-Block-N} ] ;How many? [ {MAC-To-K-Command-Opcode} ] ;Table (to be done) [ {MAC-To-K-Status} ] ;0=null, 1=ongoing, -1=finished [ {MAC-To-K-Argument-Count} ] ;Or fixed # arguments? [ {MAC-To-K-Argument-1} ] ;Argument length/string : [ {MAC-To-K-Argument-N} ] ;How many? [ {MAC-To-K-Values-Count} ] ;Or fixed # values? [ {MAC-To-K-Values-Block-1} ] ;Argument length/string : [ {MAC-To-K-Values-Block-N} ] ;How many? ********************************* @end(smalllisp) @section Major and Minor K/Mac Commands Each processor will send no more than one "major command" at a time. (This makes the interrupt processing more straight-forward.) Major commands are requests that must be dealt with at a high priority; these requests may be accomplished by interrupting the other processor for immediate attention. Minor command areas will be dealt with in the Mac's normal processing loop. For example, the K can pass several file command(s) before the MAC deals with them; but at any time the K can issue a major command to reset files, reset the network, or reset the entire K/Mac state, at any time. @subsection Major Commands @figure @itemize @item Reboot (Cold, Warm) @item Shutdown @item Restart @item Quit Current Application @item Allocate File Control Block @item Release File Control Block @item How-Many-K-Machines] @item Return-To-Mac @item Return-To-K @item (Reset/Close-all- files?) @item (Reset network?) @item (Reset entire state?) @item (Priority-{area}?) @item Read In Configuration Record @item Fill In Screen Descriptor @item Fill In Paging Descriptor @end(itemize) @caption List of K/Mac Major Commands @end(figure) Major commands are intended to perform global operations which either take very little time to execute (such as Allocate File Control Block), or which are performed infrequently but with drastic effects (such as Reboot). When returning status and values, the other processor (almost always the Mac) need not guarantee to always respond as desired, but it will return something -- at least a response-status string. (LISPM can use this, e.g., in the who-line to indicate what the MAC is thinking about.) @subsubsection Major Commands Under Discussion (Moving Window?) Perhaps to give a way for the MAC to move the LISP window, even to a different monitor (this would require a priority interrupt.) (How-are-you?) When somebody wants/needs a "keep-alive" reassurance. @chapter File-System Interface @section Pathnames The K/Mac interface will consistently use an extended version of the Macintosh native pathname syntax. When parsing filenames, the following fields will be recognized: @lisp "KMAC : : : ... : name.type.version" @end(lisp) {Please note the suggested change, using @t(``.'') as the version delimiter in place of @t(``#''). The Macintosh itself does not support wildcards, but GSI has converged on a wildcard protocol tailored around the existing ITS standard. @enumerate @item On @b(directory listings), the wildcard character, @t(``*''), matches any full pathname sub-component. (Partial string matches are not supported.) @item On @b(OPEN file commands), all @i(non-delimiting) characters are parsed as normal characters. Therefore, any acceptable Macintosh pathname can be parsed. @end(enumerate) In general, the wildcard character is respected for multiple file operations such as @l(Meta-X Delete File), networking lookups, and tape dump requests. For all single file operations, such as @l(deletef), @l(probef), and @l(listf), wildcards are not supported. @subsection Pathname version numbers Some form of version numbers must be supported. GSI is discussing the GNU EMACS method of omitting suffixes on @l(:HIGHEST) (most recent) versions only, giving explicit version numbers to all other filenames. This requires searches through the file system only upon calls to @l(probef) and @l(truename) (but not at write time), and on output operations. On output, a Mac resource will be used to store the computed version number. This will help prevent possible confusion, for example if previous versions of a file have been deleted. @need 1600 @section FileSystem Table Structure @sp 2 @center FILESYSTEM (MINOR) COMMAND TABLE @smalllisp ************************* FileSystem-Table ************************* [ {File-Handle-Count} ] ;Number of established file handles ;(MAC limitations may improve?) [ ---> FileHandle-1 ] ;If 0, slot for handle is "available" : [ ---> FileHandle-{N} ] ;What is current limit? ************************* FileHandle ************************* [ {File-Open-Flag} ] ;Used e.g. by K to close, MAC to say OK [ {File-Open-Mode} ] ;READ-SEQUENTIAL, WRITE-SEQUENTIAL, etc. [ {File-Buffer-Count} ] [ ---> FileBuffer-1 ] : [ ---> FileBuffer-N ] ************************* @end(smalllisp) The FileSystem-Table is used by the K to access files in the Mac's local file space. Command: OPEN-MAC-FILE @break Description: K asks MAC to open a native Macintosh file, given its name and CommonLISP arguments (I/O mode, :characters, etc.). The K gives as one of its arguments a "file handle", and sets a pointer into the FileSystem-Table. The K then passes a file handle index after preparing pointers to (requested number of) buffers. Depending on mode, MAC may initiate I/O immediately (e.g. on sequential read, MAC could transfer first buffers' worth). Thereafter, until the K closes file, both sides manipulate file buffer pointers in standard LISP buffered stream fashion. Command: CLOSE-MAC-FILE @break Description: From the K's point of view, could well be handled in the FileHandle area, for example, by setting the {File-Open-Flag} to -1. ZetaLISP interfaces: a K-MAC host/device, Macintosh pathname host type, and K-MAC file access method are all required. Comments: I/O must be "LISP Machine standard". No new artificial requirements should be required. On the other hand, flexibility must be maintained to allow efficient implementations. Details should be worked out in our next meeting. @section Internal File Operations @subsection FileSystem Minor Commands The fillowing FileSystem minor commands must be implemented for the first release: @display Open Close (Read) (Write) Create Directory Delete (see below) Expunge (see below) Directory Listing Rename Change File Properties Set EOF [??? Rewind (Tape? :set-pointer?)] @end(display) @i(Precise semantics to be documented here.) @subsection Supported File Properties Standard LISP machine file properties are currently supported through functions such as @l(fs:file-properties). The Macintosh must supply and maintain these properties as required by the LISP software. Some properties can be inferred from information already associated with a Macintosh file. The remaining properties must be stored with each file in the resource fork. (These properties will be written only into the K's filetypes, thereby eliminating any danger of conflict in names of resource types.) @need 2000 @example Stored Properties Vs. Inferred Properties: LISP File Property S/I Comments :author S Resource :byte-size S Resource, default to 8 (Lookup table based on Mac file type) :creation-date I Derived from creation date :deleted - NA for Mac files (see below :characters I from Mac file type :dont-delete I from Mac locked bit :dont-reap I from Mac locked bit :not-backed-up S but not in a resource; see below :modification-date I from modification date :length-in-blocks I derived from file size, byte size :length-in-bytes I derived from EOFs :qfasl-p I from Mac file type @end(example) @subsection Supported File Access Methods @subsection File Deletion Schemes It is agreed that for initial release, ``soft delete'' (which permits recovery of a deleted file unless a secondary ``expunge'' operation has been performed) will not be supported. This is consistent with existing LISPM code; very little modification should be required. @subsection Future Enhancement - Soft Delete Schemes @setq section-softdelete section-page Note that various soft deletion schemes have been discussed, but are tabled for future consideration. In ``a future release'', Soft Delete and Expunge could be supported by the K/Mac interface by various means. Suggested implementation: modifying the File Access Methods to access and maintain a parallel trash hierarchy. @display Soft Delete Expunge Release 1.0 Not supported NOOP Release 2.0 Renames file into Booting the K creates special "TRASH" In-core file image such folder hierarchy that LISP Machine's Dired displays parallel Mac directory lookups. @end(display) To be designed: A file command to view contents of trash folders (deleted files) An inter-filesystem consistency mechanism (ideas: counters, ticks, semaphores, locks) @subsection File Control Blocks File System control blocks within the communications area must be laid out to support the required operations in a way that is natural within the existing LISP streams methodology. @b(File I/O issues:) Read-ahead; write-behind; setup-input-buffers scheme allows Mac to serve as feeder. MTL should make a MAC-FAMILY-PATHNAME flavor mixin (patterned after the one for UNIX). Scratch the IOPB, and replace it with a new block containing relevant information, in the same way as for major commands. The Mac does not have a MultiBus map; therefore, build a gather/scatter memory scheme. Swapping should use RQB, block offsets. LIMITS: Largest Mac file/ Paging band/Paging file size. Do not assume contiguous block file memory allocation; Use Mac files, and find out at boot time where all blocks are located for file, do a sort/merge on these blocks, leave files open, so we need deal only in physical addresses. On the K, Buffers and File Control Blocks will be implemented uniformly as LISP Resources. @subsection Supported File Types The relevant analogy is that Folders on the Macintosh are analogous to directories on the Lisp Machine. For Release 1.0, we will support only Data forks of Macintosh files. (Resource forks are being used to store certain file properties, however.) We will support four Mac file types only: @lisp KFSL -- 8-bit binary executables KD08 -- 8-bit binary (non-executables) KD16 -- 16-bit binary (non-executables) TEXT -- 8-bit all-text text files @end(lisp) Files of type TEXT will be used to implement program source files, typically those with a @i(.LISP) suffix. We need a mapping for all strange characters in the LISP Machine character set for Mac TEXT files. (GSI to define a mapping standard.) @chapter Devices A uniform approach to devices must be adopted for all peripherals, such as Network Tables, Serial Streams, Tape Ports, and Raw Floppies. Not all such devices will be supported in the initial release. @section Tape Devices LMFL tape format should be adaptable for use with Mac files, preserving integrity of file and its contents: @example property list (most properties) stream <-> Resource Fork data stream <-> Data Fork @end(example) Backups: in Release 1, bits will not be stored in a resource, but rather in backup logs. These ``side files'' will serve as final authority on files' statuses. Need to know: How does the Mac tape device work? Ideally, the tape software could produce transportable floppies for LISP users. Need to write: OPEN-RESOURCE-FORK (OPEN needs to know which fork to act upon) @chapter Stream I/O multibuffering: @itemize @bullet @item Need to pool resources @item Spec must be inferred from Montreal @item Mac must maintain consistent state for each buffer. @item Buffer state transitions from Montreal exist @end(itemize) We must support (K/Mac must implement) the methods to SI:BUFFERED-OUTPUT-STREAM-MIXIN: @itemize @bullet @item SETUP-NEXT-INPUT-BUFFER @item SETUP-NEXT-OUTPUT-BUFFER @item DISCARD-INPUT-BUFFER @item DISCARD-CURRENT-OUTPUT-BUFFER @item SEND-OUTPUT-BUFFER @item (SET-BUFFER-POINTER?) @end(itemize) @chapter Paging I/O Raw disk commands are used to establish, utilize, and maintain raw disk partitions. These are used by LISP for paging, world-loading, and metering. (Any other standard usages envisioned?) To the MAC, these partitions might look like large native files. @section Disk Mapping Raw paging involves low-level address translation on the Mac; a fairly complex scheme may be required to simultaneously 1) minimize LISP software changes, 2) support changes required for the K, and 3) fit comfortably within the robust Macintosh environment. The Mac application assumes the burden of maintaining address maps below the LISP view of physical addresses. Everything else will be done in LISP and must be compatible with current code. If disk block size < minimum pageable unit, then look up the physical address of the paging files and eliminate all pieces which are not contiguous chunks of (physical) memory. Paging files must always be kept open by the application. We might want to use Mac memory as a paging disk cache. Can the Mac's cache be used to build a disk cache? Or must we start from scratch? [Consistent with: Partitions currently serve as bounding addresses for a "pseudo-pseudo-file" scheme] The LISP Machine does virtual ---> logical page translation, which the Mac then translates into (native) physical disk locations. These addresses are derived from files, not partitions as previously suggested. @chapter Screen, Keyboard, and Mouse @i(The following discussion is strictly a transcription of meeting notes.) Keyboard I/O requires combining the buffer space for mouse and keyboard. We propose that two mouse/kbd command channels be maintained: one for normal operations, and the other for high-priority (interrupt-level) operations (such as positioning the cursor during redisplay of the blinker). {??? Above was a way around a mouse scenario that needs to be reconstructed and documented. -KmC} Two pointers are required (I and O); equal pointer values indicate an empty buffer. The Mac advances the pointer upon encountering keystrokes. Use the Mac File System char set as a first-order approximation. We will propose full character set mapping. Control of the cursor and synchronizing the state on each side may be tricky. When using the LISPm's cursor, make the Mac's go away, with appropriate transfer of control. For screen updates: the K writes directly to its own local screen array. The K issues a command to the Mac to do a (region) copy, then the Mac copies out of this K-local screen array. When the mouse moves off of the Mac window containing the K screen, the Mac takes the mouse back, unless a GRAB-MOUSE was done (from the K side). When in bit-array-in-memory-option, provide for K to tell Mac where to look for it using an interface to open- and set- blinker, and an array in memory. Copy just enough bits to make it work. Add mouse-x and mouse-y registers to this scheme. Interrupts vs. Lossage of characters when clicking We need periodic calls to Mac's GET-NEXT-EVENT operation to handle certain screen refresh commands and to enable background processes to run. (We must be) "MultiFinder-aware." @b(Screen-Interface Commands:) This area is used by the MAC to tell the K where to (re)establish its screen drawing region. buttons>. Command: DRAW-LISP-SCREEN Arguments: base (NuBus), height (X), width (Y). [Scaling?] @b(Properties of the K/Mac Mouse Interface) K/Mac mouse clicks can be treated like a combination of a position report and a key input. The Mac also has mouse speed-dependent scaling as an option, if there is a desire to incorporate this as a future feature. Five char mouse message: buttons, dx1, dy1, dx2, and dy2, with each d being an 8-bit signed number; The process : figuring out five arguments, simulating mouse's serial action (or simulating fake mouse moves using a click decoding scheme); if all are unchanged, do nothing. About Mouse Commands: Major commands are used to establish control of the mouse. Minor commands are used to establish mouse position. commands: TAKE-MOUSE, SURRENDER-MOUSE Start with the serial action scheme in MTL Tailor Mac's event manager to conform to the Lisp mouse's behavior for clicks (create event , post them for the LISPM to read). Obviously the details of K/MAC screen interaction, and the varying proposed strategies, need to be discussed further. SCREEN DRAWING and MOUSE ISSUES Pending a total Window System redesign, we should at the very least obtain the NuBus spec. Until we have it, we understand this much about the way screen and mouse drawing should work: 1. The entire process of drawing a screen should be a process of the highest possible priority. 2. The {Screen-Descriptor-Block} points to two command(-word)s: @itemize * @item High priority draw command (word) @item Low(er) priority draw command (word) @end(itemize) The difference between these is only in their ability to be interrupted. 3. (Both kinds of) screen descriptors will have the following as components: @itemize * @item Screen coordinates @item Physical address of the local screen array @item Screen height @item Screen width @item The number of words per line @item The number of bits per pixel @end(itemize) 4. A screen-interrupts scheme cannot be determined until a microcode sequence break and high-priority channel operations (have been determined and ordered.) 5. Possible screen drawing schemes include: @itemize * @item The K can draw into the Mac's local memory (when and where permissible), with a supporting bitmap, the Mac providing a masking ALU operation, and then do a copy. @item Alternatively, the K can send the Mac logical (screen-drawing) operations. @end(itemize) 6. Warping the mouse: @itemize * @item Inherently bad idea (as it induces ergonomic inconsistency). @item (Atomically) changes the blinker position and alerts the Mac to the new position. @item Only addresses are sent to the Mac, never bits. @item Only (mouse rectangle?) regions are ever refreshed. @item (The mouse cursor bits are sent to the screen before the position is set.) (Update area and set position.) @item Warping the mouse cancels all pending moves, tracks, and positions the mouse might have had queued up. @end(itemize) Two commands are needed: @itemize * @item UPDATE-REGION (rectangle) @item UPDATE-REGION-AND-SET-MOUSE (rectangle, point) @end(itemize) 7. (Employing) two channels would greatly improve mouse tracking @itemize * @item One channel for "draw this now" @item One channel for "keep everything else up to date") @end(itemize) @chapter Other Software Issues @section Toolbox Calls A proposed K-to-Mac major command, CALL-ROUTINE, would load a `MacR' resource by name, and optionally pass shared-memory compatible arguments. These routines may be normal Macintosh routines. They could be available to the user from the K/Mac application menu. Upon invocation, the K/Mac could open a specified set of such `MacR' resources. This could be used to implement convenient ``patches'' to the application. As another example, the LISP Machine's @l(initialize-timebase) return value could be provided by the K/Mac via a `MacR' CALL-ROUTINE. @b(Bob! what was that @ii{devious} indirect scheme whereby a KFSL file could also name a Mac interface routine for special purposes??? RWK sez: You can trivially create a Mac interface routine to load a open an additional resource file. Then a KFSL file can, when loading, call this routine to open itself as a resource file, and have its own Mac-side interface routines as well as Lisp side, all in one file.) This would supersede an earlier proposal using general purpose entry vectors (simple #'s) to gain access to subroutines with mainline calls. @section Interlocks The proposed interlocking of commands and buffers between the K and Macintosh is done with a flag word or byte. The values of the proposed flags are as follows: @itemize @bullet @item 0 = NULL-STATE == thing is available, action is not required @item 1 = BUSY-STATE == action is underway, waiting @item -1 = DONE-STATE == action is completed @end(itemize) For some flags, values other than 1, 0, and -1 may be used to indicate error or status codes. It must be clearly established in each context which of the two processors is exclusively responsible for manipulating a flag. [Has a better scheme been proposed?] @section Areas for Future Discussion The following are areas for research and future projects: @itemize @bullet @item "KFSL" MacFiletype Possible extensions to K/Mac application. For example, clicking on an executable .KFSL file could boot the K/Mac with initializations to run the selected program. @item Integrating KFASL Integrating QFASL and KFASL formats -- within ZMacs, 8-bit bytes, with the compiler. @itemize - @item Integrate Jim's 8-bit QFASL change @item Integrate KFASL with RG's "target processor" in Lambda compiler/ZMacs code @end(itemize) [Deferred until future meeting among Peter, Jim, Keith, and Bob.] @item How much work will be required to check out and, if needed, clean up canonical types and generic pathnames? @item Conditionalizations There will be a wide variety of configurations (per processor, software, bus links). We need to support read- and run-time conditionalizations for each case. This must wait until the migration and integration plans have been written. [GSI needs to generate a separate specification.] @item Cambridge / Montreal communications We would like to ensure that the Macintosh group can reliably use UUCP mail for intersite communications. @item Lambda microcode Sources have been provided to Montreal to facilitate first-pass interface designs. @item Lambda/Macintosh configuration Montreal is working with a facility for Lambda/Macintosh communications that allows for simulation of the interface. We would like to have the means to do this as well. This will facilitate testing procedures before the K has been completed. Test areas: Replace kbd, mouse with Mac's [paging should be a last resort]. Incrementally design and test interface and communications area, moving gradually away from microcode. Use Lambda programs as simulators. @item Soft deletion issues As a future enhancement, we might consider a file command to view contents of trash folders (deleted files). See section @ref[section-softdelete] for proposed scheme. @item An inter-filesystem consistency-maintenance mechanism (counters, ticks, semaphores, locks?) @item Documentation, validation, and test code If possible, we would like to review any test software used for validation of the K/Mac software developed in Montreal. Integration with the LISP sources will be done by GSI, and some (re-)testing will be required. Also, design (theory of operation) documentation for the Macintosh application code will be very helpful. @item Keyboard redesign The keyboard re-layout project, including the character set mapping, is still pending. @item BYTE layout (LDB) Suggestion: If the new, K-specific byte-specifier formats can be changed to be compatible with the Lambda, some extensive LISP software modifications could be avoided. @item Apple licenses and registration issues Registering filetypes, application names, etc. with Apple? What is required? @item Nubus issues Find out whether Macintosh NuBus behavior affects the ability of other processors to become the bus master. If so, what impact does this have? Issue: Are K-to-Mac interrupts ``guaranteed''? ...Mac-to-K interrupts? Question: How is data provided to the Mac on an interrupt? @end(itemize) @contents @end(document)