The Apple Lisa is a quite rare collector’s item today. So if you hold one in your hands, you better take some high resolution pictures of the boards. Here they are:
CPU Board
I/O Board
Memory Board
Archive for the ‘archeology’ Category
Pictures of Apple Lisa 2 Boards
Tuesday, September 1st, 2009Amiga intern (PDF)
Tuesday, August 18th, 2009(German) Die Qualität dieses Scans ist furchtbar, aber wenigstens ist die PDF durchsuchbar.
Dittrich, S., Gelfand, R., & Schemmel, J. (1988). Amiga intern. Düsseldorf: Data Becker. (PDF, 718 S., 11 MB)
|
DAS STEHT DRIN: In der dritten überarbeiteten Auflage finden Sie alles von der Hardware über den Betriebssystemkern EXEC bis zum DOS, alle entscheidenden Informationen zum Amiga. Und zwar so verständlich, daß auch die Nicht-Profis unter Ihnen die Arbeitsweise des Amiga-Betriebssystems schnell verstehen werden. Aus dem Inhalt:
UND GESCHRIEBEN HABEN DIESES BUCH: Johannes Schemmel ist Hardware-Spezialist mit der Fähigkeit, Gesamtzusammenhänge verständlich darzustellen. Stefan Dittrich als 68000-Spezialist hat schon mit seinem Buch “Amiga Maschinensprache” dem interessierten AmigaAnwender gezeigt, welche Fähigkeiten in dem Rechner stecken. Ralf Gelfand ist ausgefuchster Amiga-Programmierer, der spätestens seit dem großen Floppy-Buch zum Amiga ein Begriff ist. ISBN 3-89011-104-1 |
LOAD”$”,8
Tuesday, July 28th, 2009Commodore computers up to BASIC 2.0 (like the Commodore 64, the VIC-20 and the PET 2001) only had a very basic understanding of mass storage: There were physical device numbers that were mapped to the different busses, and the “KERNAL” library had “open”, “read”, “write” and “close” functions that worked on these devices. There were also higher-level “load” and “save” functions that could load and save arbitrary regions of memory: The first two bytes of the file would be the (little endian) start address of the memory block.
With no special knowledge of “block storage” devices like disk drives, BASIC 2.0, which was not only a programming laguage but basically the shell of Commodore computers, could not express commands like “format a disk”, “delete a file” or “show the directory”. All this functionality, as well as the file system implementation, was part of the firmware of the disk drives.
Sending a Command
Sending commands to the drive was done by using the “open” call with a “secondary address” of 15: The computer’s KERNAL just sent the file name and the secondary address over the IEC bus as if it were to open a file, but the floppy drive understood secondary address 15 as the command channel. So for example, deleting a file from BASIC looked like this:
OPEN 1,8,15,"S:FOO": CLOSE 1
“1″ is the KERNAL’s file descriptor, “8″ the device number and “15″ the secondary address. Experts omitted the close, because it blocked on the completion of the operation.
Getting Data Back
While the “OPEN” line for disk commands was pretty verbose, it was still doable. Getting the error message of the last operation back was more tricky: It required a loop in BASIC that read bytes from channel 15 until EOF was reached.
Getting a directory listing would be in the same class of problem, since it requires the computer to send a command (and a file name mask) to the floppy and receive the data. Neither BASIC nor KERNAL knew how to do this, and since this was such a common operation, it wouldn’t have been possible to have the user type in a 4 line BASIC program just to dump the directory contents.
The BASIC Program Hack
Here comes the trick: If the program to load started with a “$” (followed by an optional mask), the floppy drive just returned the directory listing – formatted as a BASIC program. The user could then just “LOAD” the directory and “LIST” it if it were a BASIC program:
LOAD"$",8 SEARCHING FOR $ LOADING READY. LIST 0 "TEST DISK " 23 2A 20 "FOO" PRG 3 "BAR" PRG 641 BLOCKS FREE.
In this example, “TEST DISK” is the disk name, “23″ the disk ID and “2A” the filesystem format/version (always 2A on 1540/1541/1551/1570/1571 – but this was only a redundant copy of the version information which was never read and could be changed). There are two files, 20 and 3 blocks in size respecively (a block is a 256 byte allocation unit on disk – since blocks are stored as linked lists there are only 254 bytes of payload), and both are of the “PRG” type.
Encoding of Commodore BASIC Programs
The floppy was aware of the encoding that Commodore BASIC (a derivative of Microsoft BASIC for 6502) used and prepared the directory listing in that way. A BASIC program in memory is a linked list of lines. Every line starts with a 2-byte pointer to the next line. A 0-pointer marks the end of the program. The next two bytes are the line number, followed by the zero-terminated encoded line contents.
The LIST command decodes a BASIC program in memory by following the linked list from the start of BASIC RAM. It prints the line number, a space, and the line contents. These contents have BASIC keywords encoded as 1-byte tokens starting at 0×80. Character below 0×80 are printed verbatim. Here is what 10 PRINT"HELLO WORLD!" would look like:
0801 0E 08 - next line starts at 0x080E 0803 0A 00 - line number 10 0805 99 - token for PRINT 0806 "HELLO!" - ASCII text of line 080D 00 - end of line 080E 00 00 - end of program
The example directory listing from above would be encoded by the floppy like this:
0801 21 08 - next line starts at 0x0821 0803 00 00 - line number 0 0805 '"TEST DISK " 23 2A ' 0820 00 - end of line 0821 21 08 - next line starts at 0x0821 0823 14 00 - line number 20 0825 ' "FOO" PRG ' 0840 00 - end of line [...]
A couple of things are interesting here:
- The line with the disk name and the ID is actually printed in inverted letters, which is done by having the “revert” character code as the first character of the first line, i.e. the floppy makes the assumption that the computer understands this convention.
- BASIC will print the file sizes as variable-with line numbers, so the floppy adds extra spaces to the beginning of the line contents to have all file names aligned.
- The floppy needs to populate the next line pointers for the linked list.
The Link Pointer
The obvious question here is: How can the floppy know where in the computer’s memory the BASIC program will live? The answer is: It doesn’t. The BASIC interpreter supports having its program anywhere in memory, and loading programs that were saved from other locations on memory – or possibly other Microsoft BASIC compatible computers with a different memory layout. The VIC-20 had BASIC RAM at 0×0401, the C64 at 0×0801 and the C128 at 0×1C01. Therefore, BASIC “rebinds” a program on load, searching for the zero-terminator of the lines and filling the (redundant) link pointers.
The floppy therefore only has to send non-zero values as the link pointers for BASIC to accept the directory listing as a program. In fact, a 1541 sends the directory with a 0×0401-base, which would be valid on a VIC-20. The reason for this is that the 1541 is only a 1540 with minor timing fixes for C64 support, and the 1540 is the floppy drive that was designed for the VIC-20.
Therefore, if you do LOAD"$",8,1 on a C64, the extra “,1″ will be interpreted by the KERNAL LOAD code to load the file at its original address (as opposed to the beginning of BASIC RAM), and since there is screen RAM at 0×0400 on the C64, garbage will appear on the screen, because the character encoding of screen ram is incompatible with BASIC character encoding.
Directory Code in 61 Bytes
There are two problems with this “directory listing is a BASIC program” hack: Listing the directory overwrites a BASIC program in RAM, and listing the directory from inside an application is non-trivial.
Therefore, many many implementations to show a directory listing exist on the C64 – and I want to present my own one here, which is, to my knowledge, the shortest existing (and maybe shorted possible?) version. It is based on a 70 byte version published in “64′er Magazin” some time in the 80s, and I managed to get it down to 61 bytes.
,C000: A9 01 LDA #$01 ; filename length ,C002: AA TAX ,C003: A0 E8 LDY #$E8 ; there is a "$" at $E801 in ROM ,C005: 20 BD FF JSR $FFBD ; set filename ,C008: A9 60 LDA #$60 ,C00A: 85 B9 STA $B9 ; set secondary address ,C00C: 20 D5 F3 JSR $F3D5 ; OPEN (IEC bus version) ,C00F: 20 19 F2 JSR $F219 ; set default input device ,C012: A0 04 LDY #$04 ; skip 4 bytes (load address and link pointer) ,C014: 20 13 EE JSR $EE13 ; read byte ,C017: 88 DEY ,C018: D0 FA BNE $C014 ; loop ,C01A: A5 90 LDA $90 ,C01C: D0 19 BNE $C037 ; check end of file ,C01E: 20 13 EE JSR $EE13 ; read byte (block count low) ,C021: AA TAX ,C022: 20 13 EE JSR $EE13 ; read byte (block count high) ,C025: 20 CD BD JSR $BDCD ; print 16 bit integer ,C028: 20 13 EE JSR $EE13 ; read character ,C02B: 20 D2 FF JSR $FFD2 ; print character to stdout ,C02E: D0 F8 BNE $C028 ; loop until zero ,C030: 20 D7 AA JSR $AAD7 ; print carriage return character ,C033: A0 02 LDY #$02 ,C035: D0 DD BNE $C014 ; skip 2 bytes next time (link pointer) ,C037: 20 42 F6 JSR $F642 ; CLOSE ,C03A: 4C F3 F6 JMP $F6F3 ; reset default input device
(There is a similar implementation here.)
There are two limitations of this code though: It omits the extra space between the block number and the filename, leading to a slightly different output, and it cannot be interrupted.
This is Copyright 1983 Microsoft – NOT!
Tuesday, July 14th, 2009If you look at a hexdump of any version of the Logitech mouse driver for MS-DOS, you will see the following:
*** This is Copyright 1983 Microsoft ***
000007c0 2a 2a 2a 20 | *** | 000007d0 54 68 69 73 20 69 73 20 43 6f 70 79 72 69 67 68 |This is Copyrigh| 000007e0 74 20 31 39 38 33 20 4d 69 63 72 6f 73 6f 66 74 |t 1983 Microsoft| 000007f0 20 2a 2a 2a | *** |
Microsoft introduced the mouse to MS-DOS, and they specified the mouse driver interface and implemented the first MS-DOS mouse driver. Did Logitech license their code? Or did they steal it? Let’s look closer:
This is a LOGITECH mouse driver, but some software expect here the following string:*** This is Copyright 1983 Microsoft ***
00000770 54 68 69 73 20 69 73 20 | This is | 00000780 61 20 4c 4f 47 49 54 45 43 48 20 6d 6f 75 73 65 |a LOGITECH mouse| 00000790 20 64 72 69 76 65 72 2c 20 62 75 74 20 73 6f 6d | driver, but som| 000007a0 65 20 73 6f 66 74 77 61 72 65 20 65 78 70 65 63 |e software expec| 000007b0 74 20 68 65 72 65 20 74 68 65 20 66 6f 6c 6c 6f |t here the follo| 000007c0 77 69 6e 67 20 73 74 72 69 6e 67 3a 2a 2a 2a 20 |wing string:*** | 000007d0 54 68 69 73 20 69 73 20 43 6f 70 79 72 69 67 68 |This is Copyrigh| 000007e0 74 20 31 39 38 33 20 4d 69 63 72 6f 73 6f 66 74 |t 1983 Microsoft| 000007f0 20 2a 2a 2a | *** |
This string is located directly before the INT 0×33 API entry point, so it is easy to check for it. There’s a sucker born every minute, but this still makes you wonder what kind of programmer would really check for a string like this, even if some Microsoft API reference indeed suggested to do so. Maybe it was only Microsoft software to compare the string.
In either case, this is a very bad and unfair practice. If you define an interface, don’t add a call to ask for the version (or even the vendor!), but add feature bits instead, so that an alternative implementation can choose to be compatible with parts of it (or extend the interface independently). And if you are a developer that uses an interface, use feature bits if they are there, and resist the temptation to check for the vendor, even if the API documentation tells you to do so.
Apple Copland Reference Documentation
Tuesday, June 30th, 2009The Copland project was Apple’s ill-fated attempt in the mid 1990s to replace the aging classic Mac OS with a more modern operating system that had a microkernel, virtual memory and preemptive multitasking. Information on Copland is scarce, therefore I have compiled 20 hard to find Copland reference documents, as well as the 359 page book “Mac OS 8 Revealed”.
Note that Copland was supposed to be the next major OS release after System 7, so the while the first two beta releases D7E1 and D9 were called “Copland”, the final beta D11E4 was called “Mac OS 8″ everywhere. After the cancellation of the Copland project, Apple reused the term “Mac OS 8″ for a System 7 update.
Copland D9 (Copland Developer Release – Tools Edition)
November 1995
|
An Introduction to Copland. The Mac OS Foundation for the Next Generation of Personal Computers |
 |
|
Glossary of Copland Terminology. This Acrobat file contains the document “Glossary of Copland Terminology,” which defines many of the terms used throughout Copland developer documentation. Note, however, that the terms defined in this glossary are preliminary and subject to change. |
|
|
The Copland Toolbox. This Acrobat file contains the two-chapter book The Copland Toolbox. The first chapter introduces the event-handling model and human interface elements supported by the Copland Toolbox, and it describes the programming concepts necessary to use the Toolbox in applications. This will help you plan frameworks and tools that take full advantage of Copland’s Toolbox features. The second chapter compares the System 7 Toolbox with the equivalent Copland managers and capabilities, and this chapter includes information on backward compatibility with System 7 applications and requirements for Copland-savvy applications. This is especially useful for helping you adapt your existing System 7-based frameworks to work in Copland. |
|
|
Software Extensibility. This Acrobat file contains the document “Software Extensibility and the System Object Model (SOM),” which describes where and why Copland uses SOM classes, dynamically linked libraries, and other mechanisms to support extension and modification of system software, and how you can use these to add extensibility to your own software. |
|
|
Intro to Kernel and OS Services. This Acrobat file contains the document “Introduction to Kernel and Operating System Services,” which provides conceptual information about how and when to use services provided by the microkernel and related portions of the Copland operating system. This document will help you plan frameworks and tools that take full advantage of Copland’s operating-system features. |
|
|
Microkernel White Paper. Containing the document “Microkernel White Paper,” this file gives a conceptual overview of the Copland microkernel. This document discusses tasks, hardware and software interrupts, and privileged software execution; it describes address space management, including such topics as areas and memory reservations; and it describes messaging, such as how to use message objects, how to send and receive them, and how reply or cancel them. This version of the “Microkernel White Paper” differs only slightly from that delivered at the 1995 Worldwide Developer’s Conference. |
|
|
Patch Manager. The document “Patch Manager” contained in this Acrobat files describes the new Copland mechanism for patching the Mac OS. This will help you plan how to create patch-type system extensions for your development environment and to produce code that creates or uses extensions that patch Copland. The Patch Manager defines an application programming interface (API) that enables software to patch the system in a consistent, more easily supported manner. This is the only documentation provided for this release of Copland that describes an application programming interface. Note, however, that as with the rest of this release, all of the Patch Manager’s programming interfaces are subject to change. |
|
|
I/O Architecture. This Acrobat file contains the document “About the Copland I/O Architecture,” which provides an overview of the architecture and features of Copland’s new I/O system. This document will help you with any driver development that you might be planning for Copland, and will help you design or adapt software that writes to or otherwise directly manipulates devices. This document is identical to the chapter supplied in the Copland Technical Overview delivered at the 1995 Worldwide Developer’s Conference. |
|
|
About the Copland file System. This Acrobat file contains the document “About the Copland file System,” which introduces the features of the new file system available with Copland. It describes the various components of the file system, including the file Manager, the Navigation Services API, and the file systems API. This document also describes how to get your program ready to use the new file Manager. finally, the Documentation for MPW folder contains information describing the Macintosh Programmer’s Workshop. |
|
|
Copland Desktop. The Copland Desktop Picture is a very high quality version of the CD cover art. To use this as your desktop picture, place it on your Copland Drive. While running Copland, you can open the picture from the Appearance Control Panel. |
 |
Copland D11E4 (Mac OS 8 DDK 0.4)
June 1996 (WWDC)
|
This Inside Macintosh for Mac OS 8 Read Me provides a road map to the chapters within this folder, provides information on viewing the Acrobat files contained within this folder, and lists the methods you can use to give us your feedback on the Inside Macintosh documentation. |
|
|
For an overview of new features supported by the Toolbox, such as human interface objects, panels, window groups, imaging objects, and themes, see the chapter “Introduction to the Mac OS 8 Toolbox” in Human Interface Toolbox. For reference information on human interface objects, see the chapter “HIObject Class Reference” in Human Interface Toolbox. |
|
|
For an overview of how Apple events are used pervasively throughout Mac OS 8 by system services as well as other programs, see the chapters “Introduction to the Mac OS 8 Event Model” and “Event Model Reference” in Apple Events in Mac OS 8. For information on how Apple events are processed by the Toolbox, see “Toolbox Event Routing” and “Toolbox Events Reference” in Human Interface Toolbox. |
|
|
For information on the Mac OS 8 File Manager, Navigation Services, and other file services, as well as reference information on the Mac OS 8 File Manager, see File Navigation and Access. |
|
|
For information on the extensive support for text handling that enables you to develop your application for a worldwide market, such as support for Unicode, locales, and the use of text objects, see “Introduction to Text Handling and Internationalization” in Text Handling and Internationalization. |
|
|
For information on the use of the System Object Model (SOM) in Mac OS 8, see Software Extensibility. |
|
|
For information on creating resources that are new in Mac OS 8, see ResEdit 3.0 User’s Guide. |
|
|
For an overview of the Mac OS 8 microkernel, including information on tasks, processes, scheduling, preemption, multithreading, allocation of memory, and other services, see the chapter “About Mac OS 8″ in Microkernel and Core System Services. See subsequent chapters in Microkernel and Core System Services for reference information on many of these topics. |
|
|
For information on the Mac OS 8 I/O architecture, including information on families, plug-ins, and I/O services, see “About the I/O Architecture” in Modular I/O. For information on families for specific hardware devices, see subsequent chapters in Modular I/O. |
|
|
For updated information on Open Transport, see Open Transport. |
|
|
Please note that all presentations in this folder were created using Aldus Persuasion; an application we have not included on the DDK. (Displays Presentation, Keyboard Family Presentation, Mac OS 8 I/O Overview, OT General Presentation, OT Serial Presentation) |
 |
Tony Francis: Mac OS 8 Revealed
July 1996
|
With the next release of the Macintosh operating system, Apple will provide a state-of=the-art platform for developers to create new software products. At the core of Mac as 8 is a redesigned operating system foundation based on microkernel technology that will dramatically increase user productivity. Author Tony Francis worked closely with the Mac as 8 engineering team to provide the inside story of the design and development of this innovative technology. The book describes the technical geography of Mac as 8 and illustrates how the system’s user benefits can be implemented in software and hardware products. Written for developers, system administrators, and information systems professionals, Mac OS 8 Revealed explains the key technologies of Mac as 8:
The accompanying CD-ROM contains an electronic version of the book with animated illustrations that demonstrate the capabilities of Mac as 8. Simply click on a screen shot marked with a film strip in the book and see how a new feature in the operating system works. Tony Francis has been with Apple for over 10 years as a lead writer on the Inside Macintosh team. ISBN 0-201-47955-9 |
|
I publish these files for educational purposes, especially for all computer archeology enthusiasts like me. This data is copyrighted, but since the project has been canceled ~13 years ago, nobody should still care about it. If you disagree, contact me. Thanks to all the people who have worked on Copland and written these interesting documents!
Apple Lisa Operating System Reference Manual (PDF, 1983)
Tuesday, May 26th, 2009The Apple Lisa from 1983 was the first consumer-class computer with a graphical user interface and significantly more advanced than the 1984 Macintosh, which had a similar UI, but a comparatively primitive underlying OS. Here, I present a searchable PDF of the rare “Operating System Reference Manual for the Lisa” (1983), as well as a quick overview of the OS and how it compares to UNIX.
“Operating System Reference Manual for the Lisa” (1983)
(PDF, 188 pages, 6.2 MB)
The OS Reference Manual is actually volume 3 of 3 of the Lisa Pascal documentation. As the last page states, the book was typeset on a Lisa and printed on a dot matrix printer.
I also converted the typewriter-written draft version from lisa.sunder.net into a searchable PDF:
“Lisa Operating System Reference Manual” (Draft March 1982)
(PDF, 113 pages, 1.2 MB)
In its spirit, the Lisa Operating System resembles UNIX a lot, and its features and details were pretty much on par with UNIX systems from that time.
Scheduling: Executable files are statically linked with the Pascal runtime, and they make syscalls into the kernel. The system manages processes (with a single thread of execution) with their own address spaces that are cooperatively scheduled (255 levels of priorities). A syscall or a code segment switch can yield the CPU. Processes are managed in a tree, and the death of a parent will kill its children.
Memory Management: There is no paging, but segmented memory (up to 106 code segments and 16 data segments), and explicit swapping of code and data pages. It is possible to write protect data segments.
Inter-Process Communication: Two processes can communicate through shared files on the filesystem, named pipes, event channels (blocking or callback messaging with typed data) and shared data segments. Exceptions are delivered as events.
Filesystem: The filesystem supports 32 character filenames and allows all ASCII characters except for “-”, which is the path separator. A path can be up to 255 characters; absolute paths start with “-” (processes have a working directory). There are no enforced extensions, but the convention is to use extensions for file types. Volumes can be mounted and unmounted, and accessed at the top level by using their device name or their volume name, if they are mounted. The serial (RS232A/RS323B) and parallel (PARAPORT) ports, stdio (MAINCONSOLE) and /dev/null (BITBKT) are
like character-devices and also accessible at the top level that also provide an ioctl-like interface (DEVICE_CONTROL).
File access goes through open/read/write/close. A file is associated with cdate, mdate, adate, a delete protection flag and an up to 128 character label. Apart from regular files, there are pipes, disk-mapped data segments and event channel files.
For safety, the on-disk data structures are very redundant. Every block contains context data like a size, name, filesize, forward/backward link, inode and position in file. Directories (catalogs) and the “medium descriptor data file” are managed just like regular files.