- Transcendental Prototype Mac Os Sierra
- Prototype Game Mac
- Transcendencerl Prototype Mac Os 11
- Transcendental Prototype Mac Os Pro
- Transcendencerl Prototype Mac Os Catalina
- Transcendental Prototype Mac Os Download
The classic Mac OS (System Software) is the series of operating systems developed for the Macintosh family of personal computers by Apple Inc. From 1984 to 2001, starting with System 1 and ending with Mac OS 9.The Macintosh operating system is credited with having popularized the graphical user interface concept. It was included with every Macintosh that was sold during the era in which it was. Explosive Transcendental Circulatory System 1.0 for Mac is free to download from our software library. This free Mac app is a product of Niall Moody. The software is included in Games. This Mac download was scanned by our built-in antivirus and was rated as clean.
2 Years ago08 Oct 2018 5:49 pm by Dog Cow
As with vecLib, vImage prototypes are accessible from your code by using the main Accelerate header file. To bit or not to bit. Starting with Mac OS 10.4, Accelerate is almost entirely 64-bit capable (vDSP on PowerPC is not currently 64-bit). VDSP aside, the rest of Accelerate is 64-bit capable. The coin project mac os. At US$29.99, it allowed adventurous Mac users to sample Apple's new operating system and provide feedback for the actual release. The initial version of Mac OS X, 10.0 'Cheetah', was released on March 24, 2001. Older Mac OS applications could still run under early Mac OS.
One of the promises of the Mac 512K Blog is that we're going to take the Mac 512K to its limits, and we'll exceed the limits if necessary!
Now let's take a look at the maximum System Software version that Apple says the Mac 512K can run. Apple says the limit for a Mac 512K is System 4.1/Finder 5.5. Everyone, the entire world, says we can't do any better than this.
Is this really the limit?
No!
There is no technical limitation preventing the Macintosh 512K with its 64K ROM from running newer System versions. Read on, and we'll see how to run later System versions on a stock Mac 512K, up to System 6.0.3/Finder 6.1! Let's begin with a
Brief Overview of Macintosh System Software
A couple months ago we took a trip inside the System resource file, explaining why it's necessary, and what resources it contains. In that article, we mentioned that the System file has both a data and a resource fork, but we only examined the resource fork.
About a year ago was an article with a list of System/Finder versions and an explanation of why System and Finder files had differing version numbers for many years. The reason is that the Macintosh Operating System is split between what's in ROM and what's on disk. The Finder is technically not part of the Macintosh Operating System; it's merely a graphical shell which can be replaced with any other application using the Set Startup command in the Special menu.
Now let's take a look at this division of the OS between disk and ROM. The first thing to know is that the majority of the Mac OS resides in ROM: the Memory Manager, Segment Loader, Device Manager, disk drivers, etc. Also in ROM are QuickDraw and the Macintosh User Interface Toolbox.
Putting as much as possible in ROM saves RAM space, which was limited and expensive in the 1980s, and it also saves disk space. It's less information that has to be loaded from disk, and less that needs to be kept in RAM. It means the Macintosh starts up faster too. Furthermore, code in ROM executes faster than code in RAM because the 68000 CPU doesn't have to compete with the screen refresh for access to RAM.
All in all, this is looking like a pretty good scheme. Keep as much of the OS as possible in ROM, because it runs faster, leaves more RAM for running applications, and results in less information to be loaded from disk on system startup.
But what's the downside? Bugs! The 64K Macintosh ROM was frozen in mid-September 1983. But within weeks, some bugs were found.
ROM Freeze Party for version 4.4. The final ROM version 7.0 freeze was in September.
Fortunately, the ROM was designed so that applications and even the Operating System itself do not call subroutines directly. Instead, there is a ROM dispatch table kept in low RAM. This table maps each system trap number to a memory address. Because the table is kept in RAM, it can be modified to point elsewhere. This means that a routine in RAM can be substituted for one in ROM. Any application can modify the dispatch table to patch the ROM this way.
When the Macintosh shipped in January 1984, the System disk contained a number of ROM patches to correct bugs found since September. The data fork of the System file on disk contained these patches. And yet there were still more bugs left in ROM.
Now that we know about patches to ROM, let's take a look at system startup. How are the ROM and RAM-based system married?
System Startup: Basic Overview
We're only going to cover the basics in this article, so as not to get too bogged down, but a future Mac 512K Blog article will dive into the details of system startup.
It's 1984. You power on your Mac 512K, and here's what happens:
- The Mac begins executing code in ROM to perform some system tests, detect how much RAM is installed, and initialize some low-level OS components such as the dispatch table, mouse cursor, and Sony disk driver.
- If everything checks out OK, the screen is cleared to gray, and the question-floppy icon appears on the screen.
- You insert a startup disk (let's say it's System 1.0/Finder 1.0) and the Sony disk driver reads blocks 0 and 1 into RAM at $10000. These are the Boot Blocks.
- Assuming that the boot blocks are valid, the Mac jumps to them in RAM and begins executing the code that they contain. The Happy Mac icon appears. Among other things, the boot blocks code sets system heap size, initializes the file system and mounts the startup disk, initializes some more managers, loads the debugger, and draws the startup screen (if any).
- However, one other important task that the code in the boot blocks performs is to open the data fork of the System file on disk and begin executing the code stored there.
- In the System file, the first thing this code does is to check the ROM version number at $400008 and ensure it's $69. If the version number doesn't match, then none of the following patches will load, under assumption that a future ROM has fixed the bugs. Then the code begins patching the dispatch table to patch various ROM routines, over 40 in total. These include SystemEvent, FlashMenuBar, InitWindows, and SystemClick.
- After all the patches have been installed, control returns back to the code in the boot blocks. The system is all ready to go. The final act is to call Launch, which starts the initial application, usually the Finder.
- ROM -> Load Boot blocks
- Boot blocks -> Load System file
- System file -> Load patches
- Back to boot blocks -> Load initial application (ex: Finder)
- Finder
Changes with the Mac Plus and 128K ROM
This method of maintaining ROM patches in the data fork of the System file was continued throughout Systems 1.1 through 2.1 in late 1985. But with the introduction of the Mac Plus and its new 128K ROM in 1986, now there were two
Transcendental Prototype Mac Os Sierra
ROM versions which needed to be patched (the Mac Plus ROM was frozen in fall 1985).Thus was born the PTCH resource. Beginning with System File version 3.0 in January 1986, ROM patches were moved out of the data fork and into PTCH resources. The code in the data fork of the System file was simplified to instead open and execute the PTCH resource corresponding to the Mac's ROM version number, either $69 or $75. PTCH 105 was for the 64K ROM, while PTCH 117 was for the 128K ROM. There were also patches for a Macintosh XL running MacWorks, contained in PTCH 28927.
PTCH resources in System File version 3.0
The PTCH resource actually made its debut a few months earlier in fall 1985 with the release of the Hard Disk 20 in September. The HD20 shipped with System 2.1/Finder 5.0, the first HFS-aware versions of the Macintosh System Software.
In fall 1985, the Mac Plus was still a few months away from release, so there was only one ROM to patch, and thus the patches were maintained in the data fork of the System file as always. The one difference is that the code in the System file was amended to open the Hard Disk 20 file and execute the PTCH resources there. One of them installed RAM-based HFS, the other installed the improved Sony driver capable of accessing 800K disks and the Hard Disk 20. Both HFS and the Sony driver were loaded in the system heap, and the trap dispatch table was patched to point to them.
However, the twist is that the code in the System file only loads the Hard Disk 20 patches if the Macintosh has both the original version $69 ROM and has at least 512K of RAM installed. If a Mac Plus, 512Ke, or newer machine were used, the Hard Disk 20 file and its patches aren't loaded, nor is it loaded on a Mac 128K.
Mac Plus and Beyond: Keeping Compatibility
The 64K ROM had a few resources stored within, such as the arrow cursor, but not much else would fit. With double the size, the new 128K ROM in the Mac Plus and 512Ke stored even more resources, such as additional cursors, the system font, RAM serial driver, and some utility packages, which all previously had to be loaded from disk. For compatibility with the original Mac 128K and Mac 512K, these resources were also kept in the System file on disk. But on the Mac 512Ke and Plus, they were unnecessary, and weren't loaded.
The Mac SE and Macintosh II of 1987 each sported a 256K ROM, which stored even more resources formerly loaded from a floppy disk. System file version 4.1 now had patches for four different ROM versions: the original 64K ROM, the Mac Plus ROM, the SE, and now the Macintosh II ROM. To keep compatibility with the Mac 512K and Plus, Apple maintained all resources in the System file, even if later ROM versions had them built-in. The only cost was disk space, and by now the 800K disk was standard.
PTCH resources in System File version 4.1
Thus we see Apple's scheme for maintaining compatibility across the Macintosh line in spite of newer ROM revisions which introduced new and changed routines, and more resources. The System file held both patches for older ROMs to add the new and changed routines, as well as the new ROM resources. Newer Macs with newer ROMs simply didn't load the older ROM patches, nor the resources from disk which were already stored in ROM.
The result is that the main factor limiting which system version a particular Mac could run is how much RAM it had to store all these patches, resources, and other system data structures. This is why the Mac 128K ran into limits early on: there was simply not enough RAM to load all these needed patches and resources to keep current with newer ROMs. The patch-loading code in the System file could be modified to ignore the RAM size check before loading the Hard Disk 20 patches, but then there would barely be any space left over in the application heap.
Drop the Patch, Drop Compatibility
So far we have seen how Apple kept older Macintosh models compatible with newer System software releases: ROM patches and storing ROM-only resources in the System file too.
Apple dutifully maintained support for the Mac 512K and its old 64K ROM up through System 4.1/Finder 5.5, released in August 1987. This system was distributed on 800K HFS disks, but you could copy a System and Finder to a 400K MFS disk and it would start up a Mac 512K without a hitch.
This was the last system release to do so. With System file 4.2 and Finder 6.0 in October 1987 (unhelpfully branded as 'System version 5.0'), 64K ROM support was officially dropped. If you managed to squeeze System 4.2 and Finder 6.0 onto a 400K floppy to boot your Mac 512K, you'd be greeted with a System bomb, ID = 12, immediately after Welcome to Macintosh.
Not very welcoming.
It's not hard to understand why Apple chose to drop support for the Mac 512K in late 1987. By then, the 512K was quite limited: no SCSI, no ADB, and 512K of RAM was not enough to support large databases, spreadsheets, or word processing documents. Furthermore, the System and Finder overfilled a 400K MFS disk! The only way to get both on one disk was to remove nearly every font and desk accessory, leaving room for little else.
Eliminating support for the Mac 512K also meant that the System file no longer needed the patches and extra resources for the 64K ROM, saving some disk space for the newer Mac models.
Most people accepted this and stopped here. System 4.1 is the limit for a Mac 512K, because Apple says so. Well here at the Mac 512K Blog, we don't accept Apple's limits, and we won't stop here. Let's use the knowledge that we have gained thusfar to restore support for the Mac 512K.
How to Modify System 4.2 to Support the Mac 512K
As we asserted at the beginning of this article, there is no technical limitation preventing the Macintosh 512K with its 64K ROM from running newer System versions.
First, we should open System file 4.1 to look at its patches, and see why it will run on the Mac 512K. Using ResEdit, open the System file. Scroll down to the PTCH resource type and open it. Following 0, you should see resource IDs 105, 117, 376, and 630. These are patches for the Mac 512K, Mac Plus and Mac 512Ke, Mac SE, and Macintosh II, respectively. PTCH 0 is for all ROMs.
Now let's compare with System file version 4.2, and see why it won't run on a Mac 512K. Open the System 4.2 file using ResEdit. Open the PTCH resource type. Here you should see resource IDs 0, 117, 376, and 630. But no 105! Nothing for the Mac 512K's 64K ROM!
System Files 4.1 and 4.2 PTCH comparison
Can we simply copy PTCH resource #105 from the System 4.1 and paste it into System 4.2? Is it that simple to restore compatibility with the Mac 512K? Let's try it and find out.
With both PTCH resource windows open in ResEdit, copy PTCH #105 from System 4.1 to System 4.2. Save changes, and eject the System 4.2 disk. Now boot up your Mac 512K using that disk.
![Prototype Prototype](https://developer.apple.com/design/human-interface-guidelines/macos/images/DarkMode_Materials_dark_2x.png)
![Transcendencerl prototype mac os 11 Transcendencerl prototype mac os 11](https://developer.apple.com/design/human-interface-guidelines/macos/images/DarkMode_Materials_light_2x.png)
System 4.3/Finder 6.0 (released as 'System Software 5.1' in December 1987), can be made to run on the Mac 512K by following the same procedure: simply copy PTCH #105 from System 4.1 into System 4.3. Save changes, reboot, and there you are!
Now Let's Run System 6 on the Mac 512K
So far it's been pretty easy to get newer System versions to run on the Mac 512K. All it takes is a single PTCH resource added, and presto! Probably other hackers discovered this trick 30 years ago to run newer systems on their Mac 512K.
But let's up the ante! Let's see if we can run System 6 on a Mac 512K. Can it be done?
For no particular reason other than that I have it in my box of disks in front of me, let's use System 6.0.3/Finder 6.1, announced January 1989 with the Mac SE/30. System 6 is a bigger and more complicated operating system. Merely copying the single PTCH resource is not sufficient. There are more resources which must be added. Inside Macintosh volumes IV and V tell which resources are in ROM for the Plus, SE and Macintosh II, respectively. This is a good starting point.
Pages 32-34 of Inside Macintosh V have a list of which resources are in the SE and Macintosh II ROMs. This list includes resources of the following types: CDEF, CURS, DRVR, FONT, KCHR, KMAP, MBDF, MDEF, NFNT, PACK, SERD, and WDEF. The Macintosh II has a few additional resource types in ROM to support the Color Manager: cctb, clut, gama, mitq, and wctb. And lastly, the Macintosh II ROM contains an snd resource, 'Brass horn.'
Let's compare the differences between System files 4.1 and 6.0.3. Specifically, let's see what's not included in 6.0.3 compared to 4.1. Then, check it with the list of in-ROM resources given in Inside Macintosh volume V.
- For DRVR, both .MPP (#9) and .ATP (#10) have been dropped from 6.0.3. These were RAM-based drivers for AppleTalk on the Mac 128K and 512K, but were included in the 128K ROM. They're only needed if you plan to use AppleTalk.
- One INIT resource, ID #2, was dropped from System 6.0.3. This INIT is responsible for showing the System bomb dialog.
- System 4.1 has two NBPC resources that are not in System 6.0.3. These are used by AppleTalk.
- Three PACK resources were eliminated from System 6.0.3: 4, 5, and 7. These are Floating-Point Arithmetic, Transcendental Functions, and Binary to Decimal Conversion. All three packages are in ROM in the Mac Plus, SE, and Mac II.
- PTCH #105, the necessary patches for the 64K ROM, is also missing from 6.0.3. But we already anticipated that.
Copying these nine resources from System 4.1 to System 6.0.3 is enough to get System 6 to boot on your Mac 512K! Success!
If you're running out of disk space, remember that you'll have to use the Font/DA Mover to remove as many fonts and desk accessories as you can from System 6.0.3. You can also delete PTCH numbers 376 and 630 (for SE and Mac II, respectively) to save about 51K.
After deleting those two PTCH resources, you should have enough room on the 400K floppy to copy in PTCH 105 to the System file, and copy Finder 6.1 to the disk as well. I ended up having 21K free space on my floppy.
Choose About the Finder.. from the Apple menu and take a look. The system heap is just 73K, leaving 439K free for applications.
Long-time System 6 users will notice that the miniature Finder icon looks different. I think this is due to differences in the original 64K ROM version of QuickDraw, compared to later versions of QuickDraw.
Also, the System Folder does not show a small Finder icon to indicate that it is the blessed folder. This is almost certainly because I am using an MFS disk, which has no concept of a blessed folder (because MFS doen't have folders!).
Concluding Notes and Thoughts
The first concluding note and thought is that next time someone tells you that you can't run System 6 on a Mac 512K with 64K ROM and 400K MFS floppy, refer him or her to this article.
But on that note, the 400K floppy does become the limiting factor here. As we learned from an earlier article on using the 800K drive with Mac 512K, you can make an 800K MFS disk, and if you're using the Apple 3.5' drive (A9M0106) you can boot from that double-sided MFS disk too.
HFS isn't necessary to running System 6, and moreover you can't boot a Mac 512K from an HFS disk anyway. This is one limitation that we can't so easily overcome, but perhaps with modified boot blocks, it could be achieved.
System 6.0.3 will load the Hard Disk 20 file. If you delete the other PTCH resources and some of the snd resources too, you'll have about 85K of free space on a 400K floppy, and you can copy the Hard Disk 20 file and some CDEV (Control Panel) files too. I copied MultiFinder, but was not able to get it to work. It crashes with a system bomb ID #3, Illegal instruction. If you need even more disk space, delete all the snth resources and every snd resource except for Simple Beep.
With Hard Disk 20 patches loaded, the system heap expands to 122K, leaving only 390K free for applications. Still not too bad.
Using a Hard Disk 20
But why limit ourselves to a 400K or 800K MFS floppy? We can easily install System 6.0.3 on a Hard Disk 20, copy the necessary resources into the System file to restore 64K ROM compatibility, and run System 6 off the hard disk.
The Hard Disk 20 Startup disk will cheerfully load whichever System is on the HD20. This way, we can have a universal System Folder on the HD20 that will boot a Mac 512K, 512Ke, and Macintosh Plus!
Would anyone else like to experiment with MultiFinder or newer versions of System 6 and see if it will run too? Let us know if you get MultiFinder or a newer version of System 6 to run on the Mac 512K. Or let's see if MacTCP will load. I put MacTCP v1.1.1 on the disk, and it appears to load into the system heap, consuming almost 100K, but when I load the Control Panel, I get a system bomb. It's ID #2, which is an address error. If I had room on the disk for Macsbug, I would debug this and see what's going on.
MultiFinder always required 1MB of RAM and the 128K ROM or better. It extends the Macintosh Operating System to allow multiple applications to be launched at once, by partitioning the application heap and providing multiple A5 worlds. It will probably be quite a challenge to get it to run in only 512K of RAM.
That's all for today. The next Mac 512K Blog article will show how to use Macsbug for debugging and other nefarious purposes!
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 [email protected] or by posting a comment to this article. |
« Mac 68000 Assembly Language Tutorial: Menu Demo • How to use MacsBug for Debugging Macintosh Software »
3 Years ago06 Mar 2018 6:58 pm by Dog Cow
When Apple launched its Macintosh Office concept in January 1985, part of its three-pronged approach to sharing computer resources was a network file server, in addition to the LaserWriter and Mac-PC interoperability. Apple promised this file server in 1985, which was designed to be a stand-alone machine, basically a headless Macintosh. However, this product, which was to include print spooling and electronic mail too, never shipped and instead Apple released its AppleShare file server software in spring 1987. During that time, a small number of third-parties already released their own file sharing software that used the AppleTalk network. Among these were Infosphere XL/Serve and MacServe, and Centram TOPS.
The first file sharing application that Apple demoed in spring 1985 was called
Prototype Game Mac
ClipTalk, which allowed users to transfer files between Macintosh computers using AppleTalk. It probably operated as a peer-to-peer arrangement, with no formal distinction between client and server. By March 1985, Bill Croft and others at Stanford had written implementations of Telnet and TFTP for Macintosh, as well as a Unix file server for Macintosh. This server, called EFS for External File System, was written by John Seamons of Lucasfilm and was adapted for AppleTalk by the people at Stanford.The first native Macintosh file server was XL/Serve, released in summer 1985, which allowed a Macintosh XL to act as a disk server and print spooler for an attached Imagewriter. The 10 MB hard disk of the Mac XL could be partitioned in up to 16 volumes, with a 2 MB volume size limit. XL/Serve ran under MacWorks and required 1 MB of RAM. Finally, a major component of Apple's Macintosh Office concept was now available: a file server and print spooler. In 1986, XL/Serve was ported to the Macintosh Plus and beta copies of MacServe were out for testing in spring 1986.
The Macintosh Office was indeed a concept ahead of its time, and we'll explore it more fully in a future Mac 512K Blog article. Today, we're going to take a look at the TOPS networking system for Macintosh.
All about TOPS
Transcendencerl Prototype Mac Os 11
TOPS stands for Transcendental Operating System and was an early experiment in cross-platform networking from Centram Systems West, and also the company's first product. There was a TOPS for Mac and a TOPS for PC. With the PC AppleTalk card, an IBM PC could join an AppleTalk network too. TOPS for Mac was first released in August 1986, about 6 months before AppleShare was demoed in February 1987. At the time, Centram was also working on a port to VAX VMS.
Beta copies of TOPS were out for testing in July. Jon on the Info-Mac mailing list reported seeing a friend's beta copy of TOPS:
Jon on mod.mac, 30 Jul 1986 wrote: |
I have a friend who is a beta tester for them and we toyed around with it. I only saw the Mac portion but he tells me that it works with his PC too. At any rate, you use a DA to publish your disks for use by others. Then they can mount these disks from a list on the DA. Then it acts just like a regular disk. Pretty nifty. I would recommend it although they have a sneaky scheme where each node has a serial number and they all compare to see if it is duplicated anywhere on the net and they all quit if it is. However, rumors assure me that this can be beaten although it would be wrong.. |
Apple touted PC-Mac connectivity for the Macintosh Office, and sure enough, both PCs and Macs could act as a TOPS file server. Bill Berner had a PCXT running TOPS, acting as a file sever. He connected to it with a Macintosh, copied MacWrite to the PC's hard disk, then launched MacWrite over the network from that PC. He was also able to use Excel on the Mac to save WKS format files to the PC hard disk, then open those files on the PC using Lotus.
In October 1986, Tim Maroney of Centram gave a talk at Stanford Macintosh Developer SIG about the development plans for TOPS. John Mark Agosta posted a summary of the talk to the Info-Mac mailing list, which is worth excerpting from:
John Mark Agosta on mod.mac, 24 Oct 1986 wrote: |
CENTRAM TOPS server software, which has been shipping for several months, is the company's first product, and has been doing well enough to let them move into a larger facility. It is built on top of a 'remote function protocol', a close relative of the 'Apple session protocol.' TOPS intercepts the basic file traps, like PBOpen, etc, and using the protocol, executes a corresponding routine remotely. This is how it lets you share files on another disk over AppleTalk. Apple's 'Apple File Protocol' will in principle be the same, and CENTRAM intends to maintain compatability with AFP in their 'TOPS-2' version of server software. This is where the story really begins.. CENTRAM is, in various stages of extending TOPS, in the next versions, to include: - A unix server. This would require a hardware connection, like one of the Kinetics gateway products. The main addition needed to the present product is 'file illusion management', eg., a way of aliasing files to various parts of the unix file stucture, like link allows within the file structure. Conceivably, there would be a table that maintained these links more or less invisibly to the user. - A VMS server also. This is still on the drawing board. Tim has been working on a commercial version of 'MacIP', a version of telnet for the Mac that runs on top of TCP/IP protocols. This grew out of the public domain version he worked on at CMU. This version, however will be commercial quality software. This would let the Mac live on a local net with unix machines (again connected by a Kinetics gateway), and, as far as I see, not require the rest of the net to understand the remote function protocol. The Mac would speak a range of the existing network protocols that run on TCP/IP, except I don't recall him having plans to let the Mac be an ftp server. As a consequence of this and other products, Tim has plans for a large number of 'building block' pieces of software. For MacIP he plans to write a complete complement of telnet/ftp/smtp/TCP/IP for the Mac. For TOPS he has an 'Interbase' multi-file B-tree package with multiple keys. Also, the SFfile routines required modification for TOPS, which is refered to as the 'file interface package.' Most exciting is a rewrite of the Mac OS to allow multi-tasking (no kidding). This would not be forward compatible with existing Mac software, (no one writes applications clean enough to make that possible) but rather would let CENTRAM applications work in a multitasking environment. These numerous building blocks are not planned as commercial products, but might be licensed (eg. to developers, so many people could use the TOPS protocols, for instance), and distributed thru developer channels. Finally, another product planned is a Postal system, with a nifty Mac interface and automatic remote retrieval of messages. It would work with or without a mainframe server host. |
The first version of TOPS did not use the same Apple Filing Protocol as AppleShare because it was released months ahead of AppleShare. TOPS was later acquired by Sun Microsystems. TOPS version 3.0 features mail, network printing, and file sharing for Mac 512Ke, Plus, and SE. It was released in 1989. It is compatible with AFP-based applications, meaning that the file server can be accessed by clients using AppleShare in the Chooser.
My version 3.0 bundle, pictured above, comes with a full set of manuals and installation disks for the entire TOPS networking system. Included as a bonus is Dataviz MacLink Plus, a file format translator for PC-Mac interchange.
Installing and Using TOPS
TOPS cost about $120 per computer. TOPS had to be purchased per-computer because each TOPS disk was serial numbered, and the serial number was broadcast on the network to check for duplicates. A post from Raines on the Delphi Mac digest explained more:
Raines in net.micro.mac, 7 Aug 1986 wrote: |
I ran NETCHECK (from Apple) while TOPS was running, and found out a bit about their copy-protection scheme. I'll tell you this much: their copy-protection is tied into the very essence of the way AppleTalk's NBP works, so it might be VERY DIFFICULT to change from that end. On the other hand, some people tell me that any serial number is easily findable and changeable. |
Transcendental Prototype Mac Os Pro
Insert the TOPS disk and run the Installer application. Installation only takes a minute.
Click the Drive button if necessary to choose which volume to install TOPS on, then click the Install button. A dialog box will show progress of installation, after which you'll see this dialog box. You'll need to restart your Macintosh afterward.
After your Macintosh restarts, open the Chooser from the Apple menu and ensure that AppleTalk is Active.
TOPS is controlled through a Desk Accessory in the Apple menu. At left is a listing of files and folders on your Macintosh. To share a file or a folder on the network, highlight its name, then click the Publish button.
At right are the file servers available on the network. Select a name from this list and click Mount to access its files on the Macintosh desktop. Right now, I don't have any other servers on my network, so this list is empty.
Transcendencerl Prototype Mac Os Catalina
The Copy button lets you copy files to or from your Macintosh across the network. Because TOPS is used as a Desk Accessory, you don't need to return to the Finder to copy files; you can do it from within any application that supports Desk Accessories.I setup my AppleTalk network using PhoneNet wiring for two Mac 512Ke units with expanded memory, but because I only have one set of TOPS disks, I could not use TOPS on both Macs. The TOPS software recognized that the serial number was already in use by the other Mac 512Ke, and it refused to run.
I did not try using InBox, the electronic mail application. It's possible that too is protected by a serial number.
So it seems that this adventure has come to a premature end. Either I need to figure out how to defeat the serial number protection scheme, or I need to find another copy of TOPS with a different serial.
Transcendental Prototype Mac Os Download
We are now once again at the end of yet another Mac 512K Blog article. The next article will show how to expand the Mac 512K's memory with a Dove MacSnap! And the one after that will show how to add SCSI to your Mac 512K, so we are in for very interesting times ahead!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 [email protected] or by posting a comment to this article (when logged in to Mac GUI) |