• Letters - A Written Adventure (first Prototype) Mac Os 8
• Letters - A Written Adventure (first Prototype) Mac Os X
• Letters - A Written Adventure (first Prototype) Mac Os 7
• Letters - A Written Adventure (first Prototype) Mac Os Download

Apr 20, 2021 Adventure Time (2010–present) Yes, it’s a kids show, and yes, it’s way, way more than that. Os Mutantes), the Minas Gerais. A prototype for so many of Will Ferrell’s characters. Doorways: Old Prototype is a short game created before the development of Doorways: Prelude, the first episode in the Doorways saga. This version was built between late 2011 and early 2012. It’s an early prototype made to show the main features of the game.

The history of tablet computers and the associated special operating software is an example of pen computing technology, and thus the development of tablets has deep historical roots. The first patent for a system that recognized handwritten characters by analyzing the handwriting motion was granted in 1914. The first publicly demonstrated system using a tablet and handwriting recognition. All-Business-Letters for Mac v.4.3.5.181 Over4500 professionally written business letters which nearly cover every imaginable business situation. All-Business- Letters offers a comprehensive and categorized library of business letters that are sure to save time and efforts in every business. It is written with portability in mind, with builds actively maintained for Windows, Linux and OS X. A Qt based 'previewer' of a doc files. The result of the compilation is a single Javascript file with minimum dependencies (modernizr only), ready to use in mobile and desktop environment and accompanied by sample.

2 Years ago11 Feb 2019 7:48 pm by Dog Cow

Apple had already been bitten by the cloners: unscrupulous companies who duplicated the Apple II motherboard and its ROM and sold unauthorized copies. Steve Jobs wasn't going to let that happen again with Macintosh. Per his orders, a small icon which read 'Stolen from Apple Computer' was embedded in the ROM. Unlike the Apple II, whose commented 6502 ROM source was printed in its reference manuals, the Macintosh ROM source was a closely-guarded secret. Thus the Macintosh ROM remains one of the most mysterious aspects of the machine.
But as Sherlock Holmes famously said in The Adventure of the Dancing Men, 'What one man can invent another can discover.' With this adage in mind, let us begin on a voyage of discovery into the Macintosh 64K ROM with MacsBug.
Where is the ROM Located?
This is a question with two answers. If you are asking where is the ROM physically located? the answer is in two chips on the motherboard, labelled ROM HI and ROM LOW, respectively. The 64 kilobytes of data in ROM is split in half between these two chips. The 'HI' chip holds the high-byte of each address in ROM, while the 'LOW' chip holds the low-byte.
To visualize what half means in this case, imagine a book with 64 pages. You take a pair of scissors and cut each page in half vertically. So you have the left half of 64 pages, and the right half of 64 pages. Call the left half 'HI' and the right half 'LOW', and now you have the equivalent of how the Mac ROM is divided.
The HI ROM is Apple part number 342-0220-B while the LOW ROM is 342-0221-B There was an earlier revision of the ROM, with suffix -A. This ROM has a slightly different Sony disk driver which is only compatible with early model Sony OA-D34V 400K disk drives. The -B ROM revision is compatible with both early and later model Sony drives.
The Mac has two ROM chips located near the 68000 microprocessor
Notice one big difference between these two chips and the other 49 on the motherboard: the two ROM chips are the only ones socketed. All other chips are soldered to the motherboard. Macintosh was designed with a future ROM upgrade in mind. The original Macintosh ROM is only 64K in size, but the motherboard has 16 address lines for the ROM sockets, granting a maximum capacity for 128K of ROM.
Where is the ROM logically located?
Now here is the second answer to the question. Where is the ROM logically located within the 68000 CPU's address space? The 68000 has a 24-bit address space meaning there are 16,777,215 memory locations, or 16 MB. This address space is divided into quarters, meaning that 4 MB of space is reserved for ROM.
ROM is mapped into memory starting at address $400000 (decimal 4,194,304). It's physically impossible for there to be 4 MB of ROM (without modifying the logic board), so the 64K ROM ends up being repeated several times. The last byte of ROM is at location $40FFFF. Accessing the next location, $410000, brings you back to the beginning of ROM, and it continues on, wrapping around a dozen or more times.
The ROM's base address is stored in global variable ROMBase which is stored in low-memory at $2AE. Assembly language programmers should use ROMBase to determine the ROM's location. The wrapping around effect described previously is merely trivia and should not be used in any code you write for Macintosh.
At the very earliest stages of system startup, the Mac ROM is also located at address 0. This location allows the 68000 CPU to access some hard-coded vectors, stored in ROM, that it needs for initialization. The Synertek SY6522 VIA vOverlay bit is used only during system startup to cause the ROM to appear at the bottom of memory. After the RAM is tested, the overlay bit is cleared, placing RAM starting at location 0 as usual and ROM at $400000.
What is in the ROM?
ROM is the Macintosh's permanent read-only memory and contains information and instructions that give the Mac its look, feel, and personality. While your data on disk may change and contents of RAM be altered, Apple Computer personally guarantees that the ROM will never change while your Macintosh is running.
There are about 480 routines in ROM, which can be divided into 3 main groups:

1. Operating System
   
2. User Interface Toolbox
   
3. QuickDraw

Each of these groups consumes roughly 1/3 of the 64K of ROM. The majority of the Mac's Operating System is in fact stored in ROM, not on your startup disk. The System file merely contains resources for localization, keyboard mapping, desk accessories and fonts, some icons, and other resources that customize the way the Mac works. The Operating System in ROM contains the Memory Manager, Segment Loader, File Manager, Device Manager, Disk Driver, Serial Drivers, Vertical Retrace Manager, among others. These are all low-level routines that don't have any impact on the Mac's user interface.
Now the User Interface Toolbox in ROM gives the Mac its windows, menus, and icons interface! Within the Toolbox are found the Font Manager, Event Manager, Window Manager, Control Manager, Menu Manager, TextEdit, Dialog Manager, Scrap Manager, and so on. These managers control how the user interface works, but not what it looks like. As you may know, there are several types of windows. You can have a window with a black, rounded title bar, or a window with no scroll bars, or a window with no close box. The appearance of each type of window is stored in a WDEF resource in your System file on disk. WDEF stands for Window Definition, and it's these definition routines that determine how the windows, menus, controls (such as scroll bars), and so on look.

Using a WDEF resource that draws round windows in the Finder
The Window Manager in ROM does not assume rectangular windows. Its routines will move, close, resize, and redraw any window of any arbitrary shape. For example, it's possible to have round windows, or a window with a hole in it that shows part of the desktop. You can have menus with an icon next to each item. You can have custom controls beyond just radio buttons and scroll bars, such as an analog clock face, or a three-way toggle switch in your application. You could have circular scroll bars to work with your circular windows! These definition routines are all stored as resources on disk, not in ROM, precisely so they can be customized and changed.
The final block of code in ROM is QuickDraw, the patented graphics package for Apple Lisa and Macintosh, written single-handedly by Bill Atkinson. QuickDraw is about 40,000 lines of assembly source code, and is identical on Lisa and Macintosh. It is used to draw everything you see on screen: windows, icons, fonts, shapes, patterns, and so on. It is also used in the Print Manager to reproduce on paper an identical copy of what you see on screen.
Using MacsBug to Disassemble ROM
Now let's use MacsBug, the Macintosh debugger, to disassemble and explore the ROM. If you don't have MacsBug on your startup disk, refer to the MacsBug article on where to get it and how to install it. Among other places, MacsBug can be found on MDS Disk 2.
You should also have the Programmer's switch installed on the left side of your Mac to access MacsBug. In a pinch, you can use the round end of a paperclip to push the Interrupt button, but it's not an ideal solution, as you could hit the Reset button by mistake!
Once you have everything installed, boot your Mac, and at the Finder desktop, press the Interrupt button to enter MacsBug.
First, let's verify ROMBase. We will use MacsBug's DM (display memory) command. Type:

Code:

DM 2AE

After you press Return, you should see:

Code:

>DM 2AE 0002AE 0040 0000 0000 0B00

Letters - A Written Adventure (first Prototype) Mac Os 8

There will be more to this line after 0B00, but we only care about the first 4 bytes which read $00400000. That's the location of the ROM.
Now let's examine the first 16 bytes of ROM. Type:

Code:

DM @2AE

This MacsBug command uses @ to make location 2AE a pointer.
You should see the following:

Code:

400000 28BA 4E50 0040 002A 0069 6000 0038 6000

At the far right will be the ASCII interpretation, but it's gibberish. Let's begin by dissecting these first 16 bytes of ROM.
The first 4 bytes $28BA4E50 is the ROM checksum. The next 4 bytes tell the 68000 where its program counter (PC) should initially point after reset. $40002A is the address of the BootStart routine in ROM. We'll explore this routine next.
The following two bytes, $0069 is the ROM version number. In decimal this is 105. $69 corresponds to 6.9 which was the final developmental version number of the Mac ROM. When the ROM was frozen in September 1983, it was called to ROM 7.0. The point is that version numbers $69, 105, 6.9, and 7.0 all refer to the same ROM version: the final release of the original 64K ROM.
The 128K ROM, used in the Macintosh 512Ke and Mac Plus, is version number $0075, or 117 in decimal.
After the 2-byte verion number, the remaining 6 bytes are 68000 instructions. These instructions begin at $40000A. Let's switch to using MacsBug's IL command to disassemble the machine code.
Type:

Code:

IL @2AE+A

to disassemble the first 16 instructions beginning at $40000A. Press Return again to disassemble the next 16 instructions, which should almost fill up the Mac's screen.
At $40002A, shown with the red arrow in the screenshot above, is the entry point for BootStart. BootStart begins by checking location $F80000 for signature bytes $AA55. This was a hook for debugging hardware or software used in early Macintosh development. If the debugger wasn't found, then execution branches to $400044 to initialize the 68000 status register, address register A5, and continue with the rest of the startup procedures.
A future Mac 512K Blog article will explore the Mac's startup procedures in depth.
Tracing the Trap Dispatcher
Whenever an application or desk accessory wants to use a Macintosh Toolbox routine, it uses a 2-byte trap number to refer to the particular routine. The Trap Dispatcher in ROM looks up this number and calls the appropriate subroutine, which may be located in ROM or RAM. Andy Hertzfeld wrote the Trap Dispatcher, beginning in July 1982.
Here are a few common Toolbox routines and their corresponding trap numbers:

• AddResMenu - A94D
  
• DrawString - A884
  
• GetNewDialog - A97C
  
• InitCursor - A850
  
• Open - A000
  
• PackBits - A8CF

Notice that every hexadecimal trap number begins with A. These are termed A-line traps, because they use a set of unimplemented 68000 instruction codes beginning with A. Motorola reserved these instruction codes to allow systems designers to extend the instruction set with additional, virtual instructions. The Macintosh designers used this functionality to put most of the Operating System and Toolbox in ROM, and make it easily accessible by applications and desk accessories.
To the 68000 CPU, Macintosh Toolbox and Operating System traps look like a special set of instructions. The CPU recognizes, or traps these instructions, and hands them off to the Macintosh Trap Dispatcher for further processing.
The Trap Dispatcher, located in ROM, refers to a table of all possible code numbers with corresponding subroutine locations for each. To save space, the original 64K ROM has only one table to hold both Toolbox and Operating System traps. This table is kept in ROM, in a compressed format. When you startup the Mac, the table is copied into RAM at location $400 so that it may be patched to fix ROM bugs or add new traps.
There is room for only 512 trap entries, and each entry is 2 bytes long, making 1024 bytes total. The 128K ROM in the Mac Plus and 512Ke maintains separate tables for Operating System and Toolbox traps which allows for many more traps.
Let's trace and disassemble the Trap Dispatcher to learn more about how it works!
At the Finder desktop, press the Interrupt switch to enter MacsBug. Type

Code:

AB LAUNCH

to set a breakpoint on the Launch trap. Be sure to press Return after each command line you enter in MacsBug. Return to the Finder with the G command. Now double-click any application icon.
MacsBug should appear immediately and show:

Code:

MACTRAP A9F2 LAUNCH

Note that the trap code for Launch is A9F2. If the disk drive is spinning, enter

Code:

DM DFF1FF

to stop it. Now type S to step forward one instruction.
You are now in the Trap Dispatcher, at its entry point $401018. But how did we get here? The Motorola 68000 CPU stores the location for all A-line traps in low-memory location $28. This vector is one of several for the various errors and exceptions which the 68000 must handle. The Macintosh designers decided to route just about all of the possible exceptions, except for A-line instructions for Toolbox traps, through a central Error Manager. This is the same Error Manager that shows the infamous bomb dialog.
If you type

Code:

DM 28

you will see that the vector for A-line traps is $775E8 (or similar, depending on your version of MacsBug). This is deceptive, because we are using MacsBug to debug the Macintosh, and MacsBug modifies most of the 68000 vectors to point to itself instead of the usual Macintosh Error Manager. Normally, location $28 will hold $401018 to point directly to the Trap Dispatcher.
Type

Code:

IL PC

Letters - A Written Adventure (first Prototype) Mac Os X

to disassemble the trap dispatcher. Press Return again to see the next 16 instructions. The Trap Dispatcher is short and sweet. It has to be, for the time it takes is pure overhead in an application with dozens of Toolbox traps.

Letters - A Written Adventure (first Prototype) Mac Os 7

Type S, then continue pressing Return to step through the Trap Dispatcher and see it in action. You will see that the trap code for Launch, A9F2, is copied from the stack into register D2. The code in D2 is then compared against #$A800. If the trap code is less than A800, it's an Operating System trap. Otherwise it's a Toolbox trap. The two traps are handled slightly differently when it comes to saving and restoring registers.
Launch happens to be a Toolbox trap used to run an application. The Trap Dispatcher computes an index into the dispatch table by first chopping off bits 9 thru 15 to yield an index number from 0 to 511. As mentioned earlier, the trap dispatch table only holds 512 entries. $A9F2 becomes $1F2. Each entry in the table is 2 bytes long, so D2 is doubled by adding it to itself, resulting in $3E4.
The address of the dispatch table, $400 is loaded into A2, and will be used as a base address to find the trap location in the table. The next instruction adds this base address $400 to D2, checks the value in the table, and saves the result, $2609 in D2.
You can verify this operation yourself by typing

Code:

DM 400+3E4

Next, this value from the trap dispatch table is also doubled, again by adding D2 to itself, which yields

Letters - A Written Adventure (first Prototype) Mac Os Download

$4C12. This value is an offset from a base address. But from which base address? The trap dispatch table can point to either ROM or RAM. Bit 15 of this offset is a flag: if set, the trap is in RAM; if clear, the trap is in ROM.
In this case, the high-bit is clear in $4C12 meaning that this is a ROM offset. The BCS instruction which tested for the high-bit will not branch. The next instruction will add ROMBase, stored in $2AE, to our offset in D2. ROMBase, as shown earlier in this article, is typically $400000.
At last we have computed the subroutine location for Launch. It is $400000 + $4C12 = $404C12. The next few instructions in the Trap Dispatcher push this address on the stack and then 'fake' an RTS to transfer control to the Launch subroutine in ROM. Apple II users will recognize this programming technique was also used in the Apple II Monitor.
If you have been following along thus far, pressing Return to step through each instruction in the Trap Dispatcher, you should have reached the RTS at $401042. After you press Return, you will see that you are at $404C12. Type

Code:

WH PC

to see where you are in memory. MacsBug should show that you are in the LAUNCH routine.
The Trap Dispatcher has successfully done its job, and we have arrived at the Launch subroutine.
Disassembling a ROM routine
After learning how the Trap Dispatcher works, let's disassemble a ROM subroutine. We could continue using MacsBug's step command to trace through Launch, but let's look at another one instead so we have more opportunity for learning. There is a trap that will allow an application to specify a function that should be called when the Memory Manager needs to allocate more blocks of memory, called SetGrowZone. Let's disassemble this trap.
First we need to know the trap number. Appendix C of Inside Macintosh volume III has a table of trap names to numbers. SetGrowZone is on page III-222. Its number is A04B.
Now we can apply the same transformations as in the Trap Dispatcher. A04B is less than A800, so this is an Operating System trap. For OS traps, bit 8 is a flag to save/restore register A0. After checking this flag, bit 8 is cleared. Clear bits 8 thru 15 to get $4B. Double it to make $96. This is an offset within the trap dispatch table.
Recall that the trap dispatch table begins at $400, so add $400 to $96 to get $496. Type

Code:

DM 496

to get the trap offset. I got $8DD9. Now double this, making $11BB2. This value exceeds 16 bits, so the effective offset is $1BB2. Because there was an overflow, this means that the high-bit is set (technically, the 68000's carry flag), so this is an offset from RAMBase.
Aha! Because this trap offset is pointing to a RAM location, we know that its address was patched by the System file.
RAMBase is stored at low memory global $2B2. Type

Code:

DM 2B2

to see RAMBase. This will usually be $B00, which is the beginning of the System Heap. Add $B00 to $1BB2 to get $26B2.
Due to the limits of a 15-bit offset, RAM patches can only be located within the first 64K of RAM. This limitation is no hardship for a Mac 128K, but it is something to be aware of for the Mac 512K. For this reason, RAM patches are typically loaded into the System Heap, which usually begins at $B00.
If an application patches a trap, it is possible for the patched code, stored in the application heap, to be beyond the 15-bit offset range.
Let's disassemble SetGrowZone by typing

Code:

IL 26B2

This subroutine is very short, only four instructions, which makes it good for an example.
This subroutine takes a single argument in register A0, the address to a grow zone procedure. The address of the current heap zone record is loaded from low memory global TheZone at address $118. The grow zone procedure is stored within this record. The subroutine returns a result code in D0, which is always 0 for success, before returning to the caller with RTS.
This routine is so simple; why was it patched in the first place? Let's compare with the original in ROM. SetGrowZone is located at $402C3C. If you disassemble it, you'll see that the only effective difference is the offset in the heap zone record used to store the grow zone procedure. In ROM, it's $10. The patched version was $2C.
Why the change in offset? I'll leave that as an exercise for the reader, with a note that Inside Macintosh, page II-23 for the Memory Manager has a warning not to store directly into the gzProc field, and instead use the InitZone or SetGrowZone procedures. Within the heap zone record, gzProc is offset $10, while $2C points to sparePtr.
Stolen from Apple Computer!
Andy Hertzfeld did a good job of telling the story behind this icon, hidden in the ROM of every Macintosh, in his Folklore blog. The idea was Steve Jobs'. Susan Kare drew an icon showing a face behind jail bars, while Steve Capps wrote a routine to compress the icon and make it difficult to detect.
All that was necessary was to use MacsBug to execute a hidden subroutine to decompress and display this little icon on the screen.

screenshot from Andy Hertzfeld's Folklore blog
This icon was later simplified to remove the jail bars, and is just 24 pixels tall instead of the usual 32. The subroutine to display the icon is located at $40AD26 while the icon data is located just beyond, at $40AD40. The icon is 96 bytes long, un-encoded bitmap. Steve Jasik, author of the MacNosy disassembler, was among the first to discover this hidden icon in 1985. An identical icon exists in a prototype Twiggy Mac ROM from mid-1983, suggesting that the jailbar icon antedates it by some months.
In MacsBug, type

Code:

G 40AD26

to display the Stolen from Apple icon. You'll have to restart your Mac afterward. This display subroutine is in the Mac Plus and 512Ke ROM too, at address $40E118, and in the Mac SE ROM at $4188A4.

Stolen from Apple Computer! This is the most well-known icon, but a different one lurks in ROM too
Better ROM Disassembly
If you're interested in a better tool for ROM disassembly, try MacNosy by Steve Jasik, the original power-user's disassembler. It has far more tools than MacsBug, and will convert numbers and offsets to symbolic names and equates.
At the tail end of ROM, $40FFF8 are two sets of initials. The first is RHS for Rony H. Sebok. The second is WDA for William D. Atkinson. Enter DM 40FFF8 in MacsBug to see these initials. Earlier or later versions of the Mac ROM may have more initials.
That's all for this Mac 512K Blog article! Join me next time as I experiment with an Micro Asanté Print LocalTalk bridge to connect a Mac 512K to an Ethernet network.

The Mac 512K Blog wrote:

This blog chronicles the Macintosh 512K and my projects with it. We will test software, fix hardware, program it, hack it, and generally take the 512K Macintosh to its limits. Do leave any feedback you may have, either to my email dog_cow@macgui.com or by posting a comment to this article.

Dunnet
Developer(s)	Ron Schnell
Genre(s)	Text adventure

Dunnet is a surreal, cyberpunk^[1]text adventure written by Ron Schnell, based on a game he wrote in 1982.^[2] The name is derived from the first three letters of dungeon and the last three letters of Arpanet^{[citation needed]}. It was first written in Maclisp for the DECSYSTEM-20, then ported to Emacs Lisp in 1992.^[3] Since 1994 the game has shipped with GNU Emacs;^[4] it also has been included with XEmacs.^[5]

The game has been recommended to writers considering writing interactive fiction.^[6]

Plot[edit]

The game starts out with the player standing at the end of a dirt road, but it turns to the surreal when players realize that they are actually walking around inside a Unix system, and teleporting themselves around the Arpanet. There are many subtle jokes in this game, and there are multiple ways of ending the game. Throughout the game the player moves through different areas and rooms trying to collect treasure to earn points.

Legacy[edit]

Dunnet is playable on any operating system with the Emacs editor.^[7] Emacs comes with most Unices, including macOS (prior to version 10.15 Catalina)^[8] and distributions of Linux. Several articles targeted to Mac OS X owners have recommended it as an easter egg as a game that can be run in Terminal.app.^[9][10] It can be run by running emacs -batch -l dunnet in a shell or the key sequence M-x dunnet within Emacs, the former being the preferred and official way to run it.^[11] Dunnet was used as a benchmark in the effort to port Emacs Lisp to Guile, progressing from running standalone games^[12] to running the entire Emacs system in less than a person-year of work.^[13]

References[edit]

1. ^'There Is A Surreal Cyberpunk Adventure Game Built Into OS X That You Never Knew About'.
2. ^'Original 1982 Dunnet predecessor found in MIT archives'.
3. ^Ron Schnell (1992-07-28). 'dunnet - text adventure for e-lisp'.
4. ^Richard M. Stallman (1994). GNU Emacs Manual. p. 314. ISBN9781882114047. M-x dunnet runs an adventure-style exploration game, which is a bigger sort of puzzle [compared to the other puzzle-games that ship with GNU Emacs].
5. ^Ben Wing. 'A Tour of XEmacs'. Archived from the original on 2000-06-19. Retrieved 2015-07-27. Most of the actual editor functionality is written in Lisp and is essentially an extension that sits on top of the XEmacs core. XEmacs can do very un-editorlike things; for example, try running XEmacs using the command xemacs -batch -l dunnet.
6. ^'Interactive Fiction – An introduction (updated)'. Archived from the original on 2015-08-23.
7. ^'Dunnet'. A text adventure that is built into almost every copy of the Emacs text editor.
8. ^'EmacsForMacOS'. EmacsWiki. Retrieved 2021-04-16.
9. ^'Play an 'old-school' adventure game'.
10. ^'Discover the Text-Based Adventure Game Built Into Your Mac's Terminal'.
11. ^Dunnet help command: 'NOTE: This game *should* be run in batch mode!'
12. ^'Guile Scheme Emacs-Lisp Compatibility Matures'.
13. ^'Re: Emacs Lisp's future'.

External links[edit]

• Source code, of the eLisp port, GPLv3 license