LocalTalk Networking of Two Macintoshes

A long time ago, in a land far, far away… before ethernet was widely deployed, Macs were networked via AppleShare over AppleTalk, which itself made use of LocalTalk, a serial connection between two or more Macs, printers etc. LocalTalk was capable of the whopping great transfer rate of 230 Kbps. This may seem slow by today’s standards, but back in the mists of time, when the 1200 baud modem (a glacial 1.2 Kbps!) was the speed king of the day, 230 Kbps seemed blazingly fast!

When my efforts to LocalTalk between my Apple IIGS and a Mac failed miserably, I decided to drop back and make sure I could get LocalTalk to work between two Macs first, thus ensuring that I had a reasonable grasp of what it takes to make LocalTalk go. The simplest form of a LocalTalk network involves just two Macs, directly connected via a single LocalTalk cable plugged into the printer port of each.

Everything I have read said that this was the trivial case; the easiest form of a LocalTalk network that could be put together. Assuming that AppleShare and AppleTalk were already loaded on the Macs, all that was necessary was to connect the Macs together via a LocalTalk cable whose two ends were plugged into the printer port of each Mac. The last step was then to change the AppleTalk connection from “Ethernet” to “Printer Port” and it should just work…

And guess what? …it just did! In a radical departure from the usual narrative of these posts, there were no irrational problems to solve, no major issues to overcome, no new software to load… nothing. It all just worked! How very nice for a change!

The web-based research I did before attempting to connect the two test Macs made it clear that there are a universe of variations on this topic, including the very successful Farallon PhoneNet. In addition, the specific steps to be taken vary based on the version of Mac OS each machine is running, and the exact form of the physical connection being used. So, with all this variability in mind, here is EXACTLY what I did to get LocalTalk between two Macs working.

The two machines in question were a Mac IIfx running Mac OS 7.0.1 and a Quadra 840AV running Mac OS 8.1. Each OS version is preconfigured with AppleShare-based Personal File Sharing (a.k.a. AppleShare File Server) and these two Macs are known to network with each other successfully when using AppleTalk over Ethernet (EtherTalk vs. LocalTalk).

I concluded from this that the AppleShare/AppleTalk software was already in place and set up properly. All I had to do was physically connect the two machines, printer port to printer port, swap the AppleTalk connection from “Ethernet” (EtherTalk) to “Printer Port” (LocalTalk) and enable File Sharing. With all of this done, each Mac should “see” the other in Chooser, and each Mac should be able to mount volumes from the other and transfer files.

Let’s decompose this and look at each step. First the physical connection. I got on Amazon and ordered “C2G 02318 8-Pin Mini-DIN M/M Serial RS232 Cable, Beige (10 Feet, 3.05 Meters)”.

Pretty much from the Mac II onwards, the DIN8 connector was used for printer ports, and so this was definitely the correct cable to get, at least from a plug compatibility perspective. With both machines powered down, I ran one end of this cable to each of the printer ports of the two Macs and plugged them in. So far, so good.

The process for swapping the AppleTalk connection to the printer port was different on each of the two Macs due to their Mac OS version differences.

On the Mac IIfx (Mac OS 7.0.1), there is no AppleTalk control panel. Instead, you go to the Network control panel and there select LocalTalk vs. EtherTalk. This accomplishes the switch of AppleTalk from the ethernet port to the printer port.

On the Quadra 840AV (Mac OS 8.1), there IS an AppleTalk control panel. There you select “Printer Port” vs. “Ethernet”, which again shifts AppleTalk over to the printer port of the machine.

Like the AppleTalk port switching, enabling File Sharing was also different between the two machines, again due to their different Mac OS versions.

On the Mac IIfx (Mac OS 7.0.1) I went to the Sharing Setup control panel and turned on File Sharing.

Then I went back to the desktop and selected the boot drive. From the menu bar File menu, I selected “Sharing…” and ticked the “Share this item and its contents” box. This step gave File Sharing something to share!

On the Quadra 840AV (Mac OS 8.1) I went to the File Sharing control panel and again turned on File Sharing.

[include screenshot of Quadra 840AV File Sharing control panel].

Then I went back to the desktop, but instead of sharing the entire boot volume, I decided to try something a little more granular, and instead created a new folder called Shared840AV and then shared it using the menu bar File Menu “Sharing…” selection. Again, File Sharing had something to share.

That was it! I was ready to test it all out. On the Mac IIfx, I started Chooser. Once it was up, I was careful to check that the radio buttons at the bottom right were set for “AppleTalk Active”. Then I selected the AppleShare icon from the icon set on the left of the Chooser dialog and boom! …up popped the Quadra 840AV in the Chooser pane where available AppleTalk servers should be presented!

I selected the Quadra 840AV’s boot volume from the presented set of volumes and it mounted successfully on the Mac IIfx desktop. I was able to copy files from the newly mounted Quadra 840AV to the Mac IIfx desktop and visa versa. At this point I will note… yup, it is SLOW! A 230 Kbps link is not much of a speed demon! It took an observable amount of time to transfer 400 KB files back and forth. It was tolerable, but slow by today’s standards.

Now I repeated this whole exercise from the other side. From the Quadra 840AV’s Chooser, I selected the Mac IIfx and then selected its boot volume from the presented list of volumes. Again, I was careful to ensure that AppleTalk was set to Active via the radio buttons in the lower right of the Chooser dialog. Again I was able to successfully “see” the other Mac and copy files back and forth, and again, it was not much of a speed demon while doing it.

So there you have it! Networking two Macs via AppleShare/AppleTalk over LocalTalk… every bit as easy as the material you will read online makes it sound.

One note of caution. Also from Amazon, and from the same manufacturer as the LocalTalk cable used in all of the above testing, I order an extension cable as well, since the two Macs are of such a distance apart that the one cable just barely makes it.

This did not work! When I took the working LocalTalk cable and simply added the extension cable to the end of it prior to use, neither Mac would see the other in Chooser. I am not sure what the issue is but be forewarned. It could be a maximum length limitation, it could be poor-quality cable, it could be both, or it could be something entirely different, but no matter what, using at least that extender cable does not seem to be a good idea, even if using an extender cable in general is a good idea!

And one last caveat. Connecting two Macs directly really IS the trivial case. If you want to create a REAL network, with multiple Macs, and perhaps a printer or two, you will need some LocalTalk Connector kits, one per Mac or Printer on the network. Happily, these are still in ready supply on eBay. The one shown below is one of many presently on offer, but with the distinction of being NOS (New Old Stock) – still in the original shrink wrap.

With that, I will wrap this post up and wish you happy (LocalTalk) networking!

Apple IIGS Classic Desk Accessories

Working on Mysteries Without Any Clues, Part II

As described in earlier posts, I am relative novice where the Apple IIGS is concerned. I have (literally) decades of experience working with PCs and classic Macs, stretching back farther than I want to admit, but no experience at all with the Apple IIGS. In this strange and foreign world, EVERYTHING is new and NOTHING is known. This can make problem solving very slow and tedious, and often leads you to missing the obvious. That is what happened in this post… I may be slowly climbing the very steep IIGS learning curve, but there is a LONG way to go. Today’s post will demonstrate that in spades. 

Today’s topic is Desk Accessories, and how to access them on a IIGS. Like classic Mac OS, the GS/OS operating system supports a limited form of multi-tasking via programs called Desk Accessories. These can be loosely analogized to widgets today – small, single purpose programs that provide a useful atom of functionality. GS/OS is fundamentally a single-tasking operating system – only one application can be running at a time – but a sort of multi-tasking can be had via Desk Accessories. While a primary application is running, users can also activate and use Desk Accessories by dropping the menu bar’s Apple menu and selecting one from the list presented.

As you may guess, this gave rise to an enormous range of VERY useful functions implemented as Desk Accessories: calculators, file managers, tiny word processors, small spreadsheets and so on. The reason I mention all of this is because the screen shot functionality I wanted to add to my IIGS setup came as a Desk Accessory. This perfect sense when you consider when and why you would want to use it. Being delivered as a desk accessory should not have been a problem, but it was. As many of you may already know, but I have only recently learned, there are TWO kinds of Desk Accessory, Classic Desk Accessories (CDA) and New Desk Accessories (NDA). This simple fact caused me no small amount of grief.

It turns out that it is only NDAs that show up under the menu bar’s Apple menu. CDAs show up quite differently, as part of a text page menu that is accessed by simultaneously holding down the Apple, Control and ESC keys. All the documentation I read agreed that this was how the menu was accessed, so I gave it a try. However, no matter what I did with those three keys, the desired CDA menu would not appear. This was a major problem: No CDA menu meant no screen shots. I REALLY needed the CDA menu, but it would not appear as the documentation said it would.

SO coming back to where I started… EVERYTHING is new and NOTHING is known. What was wrong? It could be SO many things! Was there a missing configuration file or an incorrect configuration entry? Was there a conflict with another piece of software on the IIGS that was preventing this keystroke from getting to its intended destination? Was the documentation wrong, and perhaps it was the Option, Control and ESC keys (or countless other combinations) instead? Did I need to do something undocumented in the Slots control panel? Was it the hardware? It COULD be the hardware… I did in fact find an article that pointed me to the S1 jumper on the motherboard; if jumped, this jumper disables access to the control panels and CDAs! In this case, there was nothing on that jumper, but could it be some other jumper on the motherboard? So many possible causes, all new and unknown… Where to even start?

There was no obvious place and so as I often do when confronted with a temporarily unsolvable problem, I “parked” the issue for the moment and moved on to another one (there are LOTS of problems to be solved in a new environment like this!). This turned out to be illuminating. Ultimately, I found myself on another text-based page, in another text-based menu. This particular menu was easy enough to operate: the arrow keys moved the cursor around the screen, the Enter key selected the current entry, and the ESC key exited the menu. This all seemed simple enough, except that the ESC key did NOT exit the menu. In fact, it didn’t seem to do anything at all!

That’s when it hit me. My CDA menu struggle was not caused by some esoteric configuration issue that I had failed to understand… it was simply a bad key on the keyboard! The ESC key almost certainly wasn’t working. Really? Foiled by a simple keyboard failure? Consideration of this obvious possibility had completely eluded me! 

Well, this at least was a place to start and so I did. With lots of vintage Macs available in the Happy Macs lab, I had no shortage of compatible keyboards I could try, so I swapped in a different one and rebooted. I then pressed the Apple, Control and ESC keys simultaneously and instantly, up popped the (never before seen by me) CDA menu! It had been a simple keyboard fault all along! Sheesh! 

While I was desperately searching for some esoteric point of configuration that I had failed to understand, I had been undone all along by the most obvious of things: a simple failure of just one key on the keyboard! 

This whole episode is frustrating and illuminating all at the same time. Without consciously considering it, made the assumption that the hardware was good and that the issue lay in me not understanding something about this new machine. That assumption cost me several hours of time and no small amount of frustration. How often have similar things happened to you? We all need to be on guard against our built in biases and assumptions. Lesson learned. From now on, I will eliminate the obvious first when I encounter new problems on my journey through Apple IIGS land!

I subtitled this post “Working on Mysteries Without Any Clues, Part II”, harking back to my initial post on the IIGS (Adding a ZIP-100). This Bob Seger lyric continues to resonate because it is just SO descriptive of what it feels like to dive feet first into a wholly new computing environment. I am sure that there will be many more such moments in the weeks and months ahead. Stay tuned for a probable “Part III” (and maybe even “Part IV”!) to this series!

Fun with Floppies (the Apple IIGS Way)

As you may be aware if you have read my last two posts, I have been busy upgrading the hardware and software environment of my new (to me) ROM03 Apple IIGS. Along the way, I ran into and eventually came to understand (I thought!) the Slots control panel. As a coarse summary, hardware placed into a slot won’t work unless that slot is set to “Your Card” in the Slots control panel. In addition, AppleTalk and AppleShare won’t work either unless Slot 1 is set to “AppleShare” in the Slots control panel. This control panel is clearly a critical piece of Apple IIGS configuration.

Screenshot from Sweet16 Emulator

As I was working away at getting all the new hardware and supporting software to work (RAMFast SCSI card, SCSI HDD card and a Uthernet II card) I had cause from time to time to use the floppy drives I have attached to the system. I have both a 3.5” and a 5.25” floppy drive attached. I noticed as I tried to use these drives that sometimes they worked and sometimes they didn’t. I did not understand why, but thought “one problem at a time… I will get back to that after I have the rest working”. And so I did…

My IIGS removable media “stack” – 5.25″ floppy, 3.5″ floppy, ZIP-100 drive (Macintosh SE sitting behind it)

I had everything else up and running several days later and turned my attention to the seemingly erratic floppy drives. Thanks to the INCREDIBLY helpful people over at the Facebook “Apple IIGS Enthusiasts” group, and I have been led to understand, and then was able to prove in practice, that the 3.5” floppy is governed by the setting in the Slots control panel for slot 5. The 5.25” is similarly governed by the setting for slot 6.

To use the 3.5” floppy, slot 5 must be set to “Smart Port”. To use the 5.25” floppy, slot 6 must be set to “Disk Port”, both in the Slots control panel. If these settings are not in place, the respective floppy drives simply don’t work! If these settings are in place, they work exactly as expected. Going back to my observations above however, this means that they CANNOT be set to “Your Card”, which in practice said to me that you cannot populate slots 5 and 6 with expansion cards if you want to use both of the floppy drives (and I do)!

This was proven out by my real world experience. When I was first working on the RAMFast SCSI card, I had it installed in slot 6. Slot 5 was free, and eventually I added the Uthernet II card to slot 4. During that period of time, the 3.5” floppy worked; the 5.25” one did not. Eventually, in the course of my work, I rearranged the cards, moving the RAMFast card to slot 5. Slot 6 was now free and guess what? The 5.25” floppy suddenly worked like a champ but the 3.5” floppy was deader than dead.

This was when the good denizens of Facebook’s “Apple IIGS Enthusiasts” group clued me in to the connection between the floppies and the slot settings. Armed with this information, I rearranged my card layout one more time, such that slots 5 and 6 were both free, and both were set to their correct (to enable floppy use) settings of “Smart Port” and “Disk Port” respectively. That is all it took. Both floppies worked perfectly after this change.

It was a hair-raising change, mind you! After I rearranged the cards to accomplish this, the IIGS simply refused to boot, seeming to get stuck somewhere in its internet setup (the boot sequence Time icon appeared and then the boot seemed to get stuck). Leaning on my Macintosh experience, I rebooted while holding down the Shift key and the machine started up without Inits and DAs. Started like this, it booted fully, so I knew that I had a software issue to deal with, not a hardware one, which was a relief.

One small inspiration later and I had a solution. As part of the above card rearrangement, I had moved the Uthernet II card from slot 4 to slot 2. Since part of the software configuration of the Uthernet II link layer involves telling it what slot the card is in, this was clearly now broken. The machine wouldn’t boot, and so I could not change the configuration to match the hardware, so instead I changed the hardware to match the configuration! I rearranged the cards yet again, such that the Uthernet II card was returned to its original slot 4 location and boom! … the machine booted flawlessly.

So, in the end, my IIGS has only three slots open, and two of them have to remain open (5 and 6). The remaining one, slot 3, is typically reserved and kept free, although I have yet to read why. In practice therefore, my IIGS is maxed out on expansion cards. If I ever want to add another, I will have to sacrifice something… a floppy drive, the HDD card… something.

My hardware and software slot arrangement, in the end, is as follows:

Slot 1 – SCSI HDD card (slot is set for “AppleShare”)

Slot 2 – RAMFast SCSI card (slot is set for “Your Card”)

Slot 3 – Open (slot is set to its default “Text Display”)

Slot 4 – Uthernet II Internet card (slot is set for “Your Card”)

Slot 5 – Open (slot is set for “Smart Port”, enabling the 3.5” floppy drive)

Slot 6 – Open (slot is set for “Disk Port”, enabling the 5.25” floppy drive)

Slot 7 – Turbo IDE card with CF card boot volume (slot is set for “Your Card”)

Startup is set to “Scan”.

All of the above slot settings are in the Slots control panel.

In summary, what I have learned is that if you wish to use an external 3.5” floppy drive, keep slot 5 free and set it to “Smart Port” in the Slots control panel. If you wish to use an external 5.25” floppy drive, keep slot 6 free and set it to “Disk Port” in the Slots control panel. If you wish to use both floppies, keep both slots 5 and 6 free, and configure them in the Slots control panel as “Smart Port” and “Disk Port” respectively.

That is more fun (?) than I planned to have with floppies on this machine, but it is done, and I am a little further up the IIGS learning curve. I hope that this post may be useful to other IIGS newbies like myself.

Next up? I have come across some IIGS “beautifications” that I want to apply (desktop images, nicer icons, etc.) and have also come across the unofficial GS/OS 6.0.4 upgrade. And when all of that is done, it is time to move on to installing and using Orca/C. Even further out may be GNO/ME. Plenty more to come!

Putting an Apple IIGS on the Internet

Getting a vintage machine like the Apple IIGS onto the internet should have been a herculean task, but it wasn’t – it was a cakewalk! If you are interested in getting your Apple IIGS onto the net, read on. It is not nearly as hard as it might seem. This is thanks to some well executed hardware from A2 Retro Systems (Uthernet II) and some equally well-crafted software from the Marinetti Open Source Project (Marinetti TCP/IP + apps). I suspect that these two names will be familiar to most Apple IIGS aficionados.

My research on the web consistently pointed me to the Uthernet II card as the network card to get, and the Marinetti TCP/IP stack as the software to drive it with. These two, so my research said, were smoothly integrated and would just work. This all sounded far too easy, but in fact it really was pretty much that easy.

There are of course other network cards and other TCP/IP stacks, and so there are almost certainly many other ways to accomplish the task of getting your Apple IIGS onto the Internet. However, if you would like to follow the approach taken in this post, the prerequisites for getting your Apple IIGS on the Internet are:

• Uthernet II card
• At least 2MB of Apple IIGS RAM – this is required by the Uthernet II card. If you do not have any additional RAM in your IIGS, you can buy a RAMGS expansion card (4 MB or 8 MB) from Amazon, eBay and many other places. See Purchasing GGLABS products | gglabs.us for full details. Just to be clear, I have no affiliation with GGLabs whatsoever. I am just a satisfied customer.
• Marinetti 3+ software

Getting the Uthernet II card was the easy part. They can be ordered from a2retrosystems.com and I had done so quite some time back. Getting the Marinetti software was not that hard either, but it did present some challenges to a new Apple IIGS user like myself. It was available from many places, and in two formats. The first was a (to me) new and mysterious format, a .po file. This was apparently completely preconfigured and absolutely the way to go. The second was a .SHK file, a format I was more familiar with. I read that this file might need a little more configuration than the .po file to deliver the intended result and so in the end, I went for the mystery .po file. I downloaded the file from a2retrosystems.com’s Marinetti download page, getting Marinetti3.0b11.po.

OK, so what was a .po file and how did I open it and use its contents? More Google’ing revealed that .po stands for “ProDOS Order” and that it was a ProDOS disk image. This image could be mounted on the GS/OS desktop and used directly as if it was a real disk. The only problem was that I could find no description of HOW to go about mounting it. Back to Google. Eventually, I ended up at Brutal Deluxe Software, and downloaded their MountIt package. This claimed to be able to mount most common disk images, including .po.

Regrettably, MountIt downloaded as a .po file! Apparently I needed to have MountIt already installed in order to unpack and install it! This was an obvious Catch-22 and clearly a dead end. There was also the above-mentioned .SHK file, and I downloaded that too (not that I knew how to unpack .SHK files either!).

At this point, dim memories of a program I had played with in the past, called CiderPress, came to mind. I remembered that it was pretty good with obscure archive file types and I Google’d around to find it. It seems to be a Windows-only program, which is odd for a program that works with Apple disk images, but there you go! The world doesn’t always have to make sense… in fact it rarely does!

I downloaded and installed CiderPress on a Windows 10 PC I have available and then downloaded both MountIt and Marinetti again, this time onto the PC vs. the Mac I had originally downloaded it to. I then pointed CiderPress at the MountIt .po file and it opened it right up, “no muss, no fuss”. I extracted all the files and copied them, along with Marinetti, over to a Mac in the Happy Macs lab that is equipped with an external ZIP-100. From there I copied the files onto that ZIP-100 and transferred it to the ZIP drive now successfully working on my IIGS (see my last post for details of how this was accomplished).

The next few steps were pretty straightforward. I installed MountIt and then restarted. It presented a unique start up icon and so I felt confident that it had installed, but there was no other trace of it… no control panel, no application program, nothing. But it was there; I had seen it at startup. So, I navigated the GS/OS Finder over to the ZIP-100 disk and double clicked on the Marinetti .po file. Sure enough, the .po file mounted as a new disk on the desktop. I could open it and work with all the contents as expected. Excellent! MountIt is a winner!

At this point, it was time to return to the hardware. I unpacked my Uthernet II card, which is surprisingly small, selected a slot for it (4 in this case), and plugged it in. I was careful, per the manual included in the shipping package, to ensure that the Uthernet II RJ-45 connector was pointed towards the front of the IIGS (i.e. towards the keyboard). I then removed one of the slot barriers at the back of the machine and carefully threaded an ethernet cable through it and into the inside of the Apple IIGS. I then plugged that cable into the RJ-45 connector on the Uthernet II and plugged the other end of it into the Happy Macs lab network switch. Finally, I used the Slots control panel to set the Uthernet II slot to “Your Card” and restarted.

All was well. The machine booted successfully and I was able to check that all the right indicator lights on the Uthernet II were lit, indicating that a solid 100 Mbps connection had been established between the Uthernet II and the network switch. Great! It was now time to return to the software side of things.

This was a total joy, and I don’t say that often about installing software! The Uthernet II shipping package included a one page Quick Start guide which included a “Software” section that told you exactly how to install the Marinetti software. There were only three simple steps (run the installer, copy the TCPIP file into System:System.Setup and copy the UthernetII file into System:TCPIP). That was it! Restart and enjoy? Well, not quite, but almost. Once restarted, there was the usual TCP/IP configuration that had to be done via the new TCPIP control panel (gateway address, enable DHCP, etc.) and another restart needed. Once that was done, the whole task was done. The Apple IIGS was on the internet… I think!

That was the problem. I think the IIGS was on the net, but there was no sign of it, and no helper apps like MacTCPPing to test it out with. There wasn’t even anything that would tell you what your IP address was! This seemed rather like going to a lot of work to build the world’s best car, only to discover that there was no instrument panel to monitor it with and no pedals to control it with!

I went back to Google looking for Marinetti applications, and ultimately found GW_FTP, SAFE2 FTP and something called Spectrum, which after examination didn’t seem like what I was looking for. As I write this post, I have yet to try these applications, but I DID find two other applications that were installed by Marinetti, a web server and a Telnet program. I did not need a web server, but I tried it (Casper) anyway just to see if it worked.

It did! Not only that, but Casper also told me what my IP address was and the path from which it was serving files. Using the Teach application on the IIGS, I quickly hacked together a small welcome.html file and put it into the directory Casper was serving content from.

Then I moved over to one of the Macs in the lab (in this case my trusty PowerMac G5 Dual). First I pinged the IP address that Casper had given me and was gratified to see a continuous set of ping responses. My IIGS really WAS on the Internet. Then I pointed a web browser at the same address and was beyond pleased when the “Welcome to IIGS” message from my welcome.html file appeared on screen.

So there you have it. A IIGS now on the Internet. The job is not quite done however. I did not title this post “Networking an Apple IIGS” because while my IIGS is on the Internet, it is not on the Happy Macs lab internal AppleTalk network. I have read lots of confusing and contradictory material on how to achieve this, but nothing that has led anywhere useful yet. The apparently “typical” answer, AFPBridge, simply doesn’t seem to work against any of the Macs I have in the lab, and so the search for a networking solution continues.

In summary, to put your Apple IIGS on the Internet, get a Uthernet II card, get the Marinetti TCP/IP stack and then simply follow the included instructions. A2 Retro Systems and Marinetti are to be congratulated on a job well done. Minus my now resolved confusion about how to deal with .po files, it all “just worked”. I hope that you may have similar smooth sailing!

Adding an Iomega ZIP-100 to the Apple IIGS

“Working on mysteries without any clues…” These lyrics, plucked from the song “Night Moves” by Bob Seger, have been running through my mind for days. The year was 1976 and the song had nothing to do with the Apple IIGS (which didn’t even exist yet!), but those lyrics just seemed so appropriate as I struggled to accomplish the first major objective I had set myself for this fascinating machine.

“Working on mysteries without any clues” really does sum it up nicely. To a veteran Mac OS Classic user like myself, the Apple IIGS, cloaked in its GS/OS skin, feels very familiar. But it is not. It is a completely different animal. Everything about it was new and strange to me and I scarcely knew where to start. And no matter where I started, nothing worked… and as of yet I had no mental framework with which to troubleshoot it.

What was I up to? I was adding a ZIP-100 removable file system to the IIGS. I knew that in order to do anything meaningful on this machine, I needed a high bandwidth pathway onto and off of it so that I could transfer files to and from. This meant either connecting a large removable file system (think ZIP and Jaz drives) or getting the machine onto AppleShare. The former required me to add a SCSI card to the IIGS and the latter required me to add a Uthernet II card to IIGS.

In my experience, it has always been a deeply involved nightmare to get networking up and running on a new machine that doesn’t have it configured already and so I opted to take the SCSI card path instead, with that card hosting the SCSI ZIP-100 drive I wanted to add. Not coincidentally, I just happen to have a RAMFast SCSI card, replete with a full installation manual … it sounded like a good place to start.

However, every single part of the path from the IIGS to the ZIP disk itself was an unknown. The RAMFast card was new (to me) and its operational status was unknown. The software to drive it, how to configure that software and how to install it were all also new and total unknowns to me. The connecting cable was new and untested. The ZIP drive itself was new to me and again, untested. It all either just worked and success was at hand, or it didn’t, and I would be left with a lot of mysteries and not very many clues.

It will come as no surprise that it did not “just work”. Of course it didn’t. Nothing is ever that easy. It started out easily enough however. I read the install manual for the card, selected a slot for it and inserted it. I rebooted and the machine came back up. This was a good start, right… or was it? Perhaps not. According to the manual, GS/OS was supposed to find an onboard ROM volume on the RAMFast card and mount it onto the desktop. All the necessary SCSI driver software was on that onboard volume and so without it, I was rather stuck.

Where to start? Was the card bad? Was the slot bad? Was the software not set up correctly to “see” the slot? Was the SCSI bus hung up?  Lots of mysteries and not many clues!

Well, that is not entirely true… I had just a few clues. The RAMFast install manual provided helpful directions here and there, but nothing that led anywhere productive for my usage. This is because it was written assuming that the host IIGS the card was going into did not have a hard drive already, and the objective was to install the RAMFast card, hang a hard drive off of it, make that drive the primary boot volume and install GS/OS on it. Since I already had a perfectly good IDE boot volume and was instead installing the RAMFast to host a secondary removable file system, the directions simply didn’t apply most of the time.

Nonetheless, they had some value. They reminded me to check SCSI bus termination, taught me how to bypass the card entirely during the boot sequence and provided just enough details on the software contained on the still absent ROM volume to help me blunder through it when I eventually found it. The manual also informed me that the control panel entry for the slot the card was inserted into had to be set to “My Card”. This Control Panel entry was to be found in the Slots control panel – a wonderful tip except that I didn’t have a Slots control panel on my GS/OS install! Further, I had never encountered such an animal in all my journeys through Macintosh land!

OK, clearly I needed to find a copy of the Slots control panel, get it onto a floppy and get it into the IIGS. Then maybe I could progress towards the next obstacle. One step at a time. I have the Sweet16 Apple IIGS emulator and thinking that it might have the Slots control panel, I fired it up. Sure enough, I found the Slots control panel there and several other interesting ones besides!. After spending a fair amount of time reconfiguring Sweet16 itself so that it was possible to copy files out of its file system and onto the host Mac’s desktop, I finally managed to get the control panels out onto my Mac Pro’s desktop.

Now all I needed was to get those shiny new control panels onto a floppy and ingest them on the IIGS. Simple enough, right? Not even close! It seemed to me that a floppy that had been formatted by the IIGS would be the best place to start, and so I did. The IIGS offered to format one for me in either ProDOS or HFS. I chose HFS, reasoning that any of my classic Macs should be able to read and write it.

I formatted the floppy and brought it over to a Mac OS 8.6 system I have. Of course, it would not recognize the floppy. It did however “helpfully” offer to reformat it for me, and amazingly offered ProDOS as a formatting option. That sounded promising I thought and so I took it up on the offer. Minutes later I had a freshly formatted ProDOS floppy. If the IIGS recognized it, I could transfer the missing control panels from my Mac Pro to my Mac OS 8.6 system over AppleShare, drop them onto the floppy and then “sneakernet” them over to the IIGS. If it accepted the floppy, I was done.

Did it accept that floppy? No, of course it didn’t! To cut a long story short, there was no combination of floppy formats and sizes that both machines could agree on and mutually recognize. After a fair amount of time spent, this was a dead end. At that moment, I not only did not have a high bandwidth way in and out of the IIGS, I had NO way at all!  … and yet I NEEDED to get the Slots control panel onto it. I had to find another way.

It then occurred to me that a long time ago I had purchased a set of GS/OS install disks. This might just be the answer – by definition these had to be IIGS native floppies formatted for ProDOS. If THEY had the missing Slots control panel, I could just slurp them up onto the IIGS from its own floppy drive and all would be well. And for once, all was well. This actually worked! I methodically worked through each of the install disks and on the third one, I found the control panel of interest, along with several other things that were curious omissions from the install on the IIGS I have, such as TeachText (my install had no editor at all!).

Based on my Mac System 6 knowledge, I deduced where to put the new control panels, and rebooted. Once again, a good start – the IIGS booted successfully. I was then able to fire up the Slots control panel and have a first look at this new and foreign (to me) piece of software. It was blissfully direct and obvious, and using it I changed slot 6, where I had the RAMFast inserted, to “My Card”. I hopefully rebooted.

No joy. After this seemingly simple change the boot hung, stalling shortly after it took off, never to recover again. This was very bad news indeed! I had NO idea how to overcome a failed boot in this new environment. So I “followed my nose” and did what I would do if I was working on a vintage Mac… I powered off and rebooted, just to ensure that it really WAS stuck.

It wasn’t! Miraculously this next boot was 100% successful. A short post-boot trip to the new Slots control panel revealed that Slot 6 had reverted back to “Disk Port” (seemingly its default setting) and all was well once more… except that I was no further ahead in my quest to get the SCSI card and ZIP drive up and running. If I set the slot the way it needed to be set for the SCSCI card, the boot failed. If I left it at its default, the boot succeeded, but there was no hope for the SCSI card. Clues … I needed some new clues! 😊

This is where the RAMFast installation manual came to the rescue. There was a Troubleshooting section at the end, and near the end of that section it mentioned that if you had a GSLabs RAM expansion card in your IIGS, it might interfere with the RAMFast SCSI card. I DO have such a card (my IIGS thus sports 4 MB of RAM) and so I pulled it out, again reset Slot 6 to “My Card” and rebooted.

Magic! Pure Freakin’ Magic (PFM)! Not only did the long missing RAMFast ROM volume suddenly establish itself on the GS/OS desktop but so did the ZIP disk! Removing the RAM card had snatched victory from the jaws of defeat – thank goodness for that manual; I would have NEVER thought to try this without that pointer!

This is not quite the end of the story, but very close to it. Thanks to its “we are installing a hard disk that you want to make your boot volume” paradigm, the software on the RAMFast ROM volume would not do its thing. The install simply would not work, every time. However, there were just two files on the volume, one a .SYSTEM file and one a .DRIVER file and so I again “followed my nose” and manually copied the two files to where I thought they should be on my existing boot volume. The next reboot proved my nose to be pretty accurate. I was greeted with pretty new desktop icons for the ROM volume and the ZIP disk and an otherwise fully operational setup. I could drag the ZIP icon to the trash, ejecting it, and then pop it back in, at which point it would remount on the desktop. Large, removable storage achieved!

The best part is that with all of this in place, I reinserted the RAM expansion card, and all of the above kept working! Another mystery that I do not understand, but I will take it!

Just one problem now remains, and it is manageable. Each time I power off, vs. restart, Slot 6 defaults back to “Disk Port” and I have to go in, reset it to “Your Card” and restart. A minor inconvenience, and it sounds like a simple case of a dead motherboard battery anyway. I can fix that!

And so my first objective has been accomplished. I have successfully added a ZIP-100 removable file system to my IIGS and can now move files onto and off of it in large volume. Along the way, and I have learned a few things about the IIGS environment as well. There are still plenty of mysteries left to solve, but I have a few more clues now. As always, persistence, determination and intelligent use of whatever resources are available at hand have paid off. Never say “die”!

Next up? I will return to the Uthernet II card I mentioned above and see what I can do about getting the IIGS onto the Happy Macs lab network. I suspect that this will be a longer and more difficult fight than this first one. Once done however, I can close up the IIGS case and stabilize the hardware environment permanently. From then on, it is all software, which is always easier and less dangerous to play with than with hardware!

Stay tuned for more adventures from IIGS’land!

More Progress: HappyMacs Gopher Site Back “On the Air”

I am pleased to announce that the HappyMacs Gopher site, hosting the Happy Macs vintage Mac software repository, is back online once more and available for your downloading pleasure. I took the site offline when we undertook the last move, and it has been that way ever since. It is good to be back!

Below is a quick screen grab of the site, as seen through the Gophie macOS Gopher client.

Never heard of Gophie? Neither had I! I just found it this morning. Gophie is a modern, minimalistic and native Gopher client for macOS, Windows and Linux. In my limited testing with it today, it seems stable, if not particularly fast. Point your browser at https://gophie.org to download a copy. Gophie is the first native macOS Gopher client I have ever come across, so I was pretty pleased to find it. I have run it on my M1-powered Mac Studio (macOS Monterey) and on my Intel-powered Mac Pro (macOS High Sierra). It worked well in both environments. I have downloaded, but not yet tried, the Windows 10 version as well.

The Next Frontier – the Apple IIGS!

As I announced in Another Long Hiatus Comes to an End, I have been focused on getting the Happy Macs lab back up and fully operational. At this point, that work is pretty much done. Now that the related activity is winding down, it is time to turn my attention to the Apple IIGS, as I indicated I would in the above post.

As I have mentioned in the past, the Apple IIGS is a fascinating crossover product – almost a Mac, almost an Apple II and yet truly a unique product unto itself. It COULD have been the future of Apple’s computer lineup, delivering Apple II backward compatibility and Macintosh-like future capability. Alas, this tantalizing prospect was never realized and the Macintosh became the focal point of Apple’s computing effort. As history shows, this was clearly not a bad choice, but we will never know what might have happened had the decision gone in a different direction.

This will be challenging. I am a nearly total Apple IIGS newbie, and so the journey ahead will be long and tortuous. Accordingly, I have set myself an ambitious goal to give the work focus. For more years than I want to admit, I have authored and maintained the VE text editor, a terminal text editor in the spirit of vi, emacs and so on. Think vi power, but smaller, faster and more friendly to use. You can learn more about VE at its website: www.inverary.net/ve

My goal is to port VE from its current MS-DOS/PC implementation (versions also exist for Linux and Mac OS X Terminal) to a new GS/OS, ProDOS 16 implementation. VE is written entirely in (mostly portable) C and so I have acquired the Orca C compiler and toolset for the Apple IIGS. The job will be done when VE has been ported to Orca C on the Apple IIGS and is running successfully under ProDOS 16.

In support of this new task, I will be upgrading the banner image for this blog to include the Apple IIGS. While it is technically not a “pre-Intel Mac”, it is so closely related that it seems a natural extension.  This blog will thus mix posts about the Apple IIGS with those about Macs. I hope that it may prove to be an interesting ride.

A Quadra 660AV Revived

As I have mentioned in previous posts, after our recent move I ended up with no working Quadras at all, despite the fact that two 840AVs and two 660AVs made the move with us. I recently recounted the story of the revival of one of the 840AVs, now happily humming away in the Happy Macs Lab, and indicated that I was moving on to the 660AVs to see what I could accomplish. I am happy to report that this effort has been successful, and the revived 840AV has been rejoined by its old 660AV running mate.

The non functioning 660AV presented with a wholly different set of symptoms than the 840AV. When powered on, it would simply repeatedly click, with a 5s to 10s frequency. The monitor light would turn on and off right along with each click and the lights on the keyboard would do the same. This seemed like a power supply issue at first blush, but after my recent experience with the 840AV, I decided to check out the motherboard carefully nonetheless.

This was a fruitful exercise. There was extensive “bad cap” fouling in one area of the board and I suspected that I might have found my culprit right there. Repeating the steps I took with the 840AV, I got my trusty rubbing alcohol and Q-tips and went to work:

The Pile of Dirty Q-Tips Post Motherboard Cleanup

This was MUCH easier on a 660AV than on an 840AV; no need to perform major surgery just to extract the motherboard. The 840AV is a fine machine, but it is a beast to service. Not so the 660AV, where everything is cleanly in reach once the case has been removed.

Cleaning the motherboard SEEMED to resolve most of the issue. After a few attempts at powering up, greeted in each case with the usual serenade of clicks, I was being extremely low tech and hovering my ear over each section of the motherboard to isolate the source of the clicking (by the way, it turns out to have been the speaker – it was getting power cycled every 5s to 10s and responding with a brief noise – the click – each time). While I was thus engaged, quite suddenly the machine stopped clicking, issued a startup chime and took off! Amazing!

I suspected that one of the damaged caps just needed a little time to build up enough charge to do whatever its job was and had finally done so. With bad caps, you never know if there is enough functionality left for the machine to work or not – in this case, it seemed like one or more caps just needed some time to get to health.

This was a good theory, but alas it was not the on-the-ground reality. After playing with the machine for a bit, and after several successful restarts, I took the plunge and turned it off. I let it sit for a few minutes and attempted a power on. Clicking… just endless clicking. No amount of waiting would be rewarded, and after multiple sessions of this, I had to dismiss that one lone power up as a successful, but extremely rare, fluke of timing. Clearly, I had not resolved enough of the problem with my motherboard cleaning.

So, back to my first theory – a power supply problem. I have two Quadra 660AVs, one which has never worked and was acquired for parts and the one I was attempting to revive. The “for parts” 660AV would reliably power up (disks would spin up, noise would be heard) but would not boot. SO… it seemed to have a good power supply at least.

To add to this diagnosis, checking my files I realized that when I had first acquired the 660AV, I had been lucky enough to find Apple’s original service manual for it online and had downloaded a copy. Darned if my very scenario wasn’t addressed in the manual! In the usually not very helpful “Troubleshooting” section, I found a note that said that if the 660AV clicked on power up instead of booting, the cure was to replace the power supply!

So, I did just that. I extracted the power supply from the “for parts” machine and transplanted it into the 660AV I was trying to revive.

Once done, my initial attempt at power up was met with a startup chime and a successful boot, as has every attempt since then. Now, prior to the move, this particular 660AV was a bit finicky about booting up. It always took two or more attempts to get it to boot. It always booted, but sometimes it took a little patience. Now however it boots every time – cleaning the motherboard does seem to have paid some benefits later on.

In the end, the issues I experienced with this particular 660AV were attributable in part to the physical trauma of the move and in part to one or more caps getting bad enough to interfere with the functioning of the product.

Most of you will not move vintage Macs nearly as often as my career has required me to do, and so you will not have to deal with issues caused by the physical trauma moving entails. As for the rest of us, we need to keep in mind that the older these vintage Macs get, the more distressed caps we will see, and the more perfectly functional machines we will see suddenly becoming non-functional. Be ready for it, keep your rubbing alcohol and Q-tips at hand, and keep the faith. In the end of course, if the worst comes to the worst, there are services out there that will recap vintage Mac motherboards. Find one, send your motherboard away and keep your fingers crossed!

Breathing Life into an Apparently Dead 840AV

It was starting to look dangerously like I was going to need to change the title of this blog. You cannot write a blog named “Quadras, Cubes and G5s” if you don’t have any Quadras! That was my situation up until this past Friday. Four Quadras moved with us in our latest move. Two were fully functional, one was functional but occasionally not, and the last was without any life at all – being kept as a hedge against days like these, when I might need a ready source of spare parts.

There were two Quadra 840AVs, the fastest 68K Macs Apple ever produced, and two were Quadra 660AVs, wonderful little “pizza box” form factor 68040 powerhouses. One 840AV and one 660AV were fully functional. One 840AV was functional, but occasionally would refuse to start. The remaining machine, a 660AV, was totally dead, and has to this day resisted my best efforts to restore it to life.

All four were DOA at our new location. I started with the 840AVs and stripped them both down, extracting the motherboards and an unknown NuBus card from one of them. I examined each circuit pack carefully, I verified that the power supplies were good and producing the requisite voltages and examined every interface connector to be sure all were in good shape. I even changed out the motherboard batteries, although that had been done recently before the move.

I then carefully reassembled both machines and tried them in sequence. Nothing. No life. However, being the persistent type, and having seen too many strange things in my time with vintage Macs, I kept attempting to power them on and off. One gave no reaction at all to the power switch; the other would fire up the power supply and the hard drive, but refused to boot. This later one showed no signs of CPU life at all. There was no startup chime and complete indifference to the many boot time keyboard shortcuts that I tried. For all intents and purposes, the power supply was good, but the motherboard was not.

And then… it blinked. After multiple consecutive reboot cycles, it sprang to life and booted up Mac OS 7.5.1. Knowing that this could be a “one and done” scenario, I tinkered with it while it was up, running diagnostics and generally attempting to gather all the status information I could. I then powered it down and retried the boot. Once again it refused to boot, but once again after multiple consecutive attempts it “caught” and booted up. However, that was the last flicker of life I got from it. From that point onwards, it steadfastly refused to provide any indication that it might support life.

This was discouraging, but still useful. Clearly, the motherboard was more or less functional, and so there was hope. I stripped the machine down once again and completely reexamined the motherboard with the proverbial “fine toothed comb”. Eventually, careful examination of every nook and cranny revealed an unknown square, black surface mounted part that had clearly leaked some (or all) of its contents onto the traces around it. Finally! Something I could work with. Perhaps it was not the physical trauma of moving that had done in this machine. A part had simply exploded and fouled the board. Perhaps it was just the passage of time!

With rubbing alcohol and Q-tips in hand, I carefully cleaned the entire effected area, and then cleaned it again. One down, how many to go? I kept up the detailed examination and eventually found one other tiny cap that had similarly leaked a very limited amount its contents around it. This I cleaned carefully as well.

Eventually, I could find no more and methodically reassembled the machine. I held my breath and pushed the power button. The power supply and hard drives kicked into life, but that was it. I waited and waited, but there were no signs of CPU life (any life at all!) whatsoever.

Disappointed, I was mentally running over my options for next steps when the seemingly impossible happened. The monitor kicked on and there was good ol’ Mac OS booting up. “Of course!”, I thought – I had maxed out the RAM on this particular machine, giving it the full complement of 128MB that an 840AV can support. Running boot time RAM tests on such a large amount of RAM takes even a 40MHz 68040 more than just a few seconds. This explained the post power on delay!

I am happy to report that since then, the machine has been 100% reliable! The speaker is clearly dead (that will be a task for another day) but when I hooked up external speakers, the 840AV delivered a robust start up chime. It does this each time, then pauses for 45s or so while it runs the RAM tests and then moves on with the process of booting Mac OS. I have had no further boot failures and no other “flakey” behavior since I cleaned up those two areas of leakage on the motherboard.

SO… we can learn a few things from this sequence of events:

(1) Persistence counts. Never say “die’.

(2) A Mac that appears non-responsive may simply be busy. Be patient and give it a minute or two to complete boot tests before concluding that any given boot attempt has failed.

(3) Finally, examine all circuit packs very, very carefully, looking for “exploded” parts. Clean up any that you find. Macs were wonderfully over-engineered “back in the day”, and the loss of one or more caps may not cripple the machine. It depends on where they are located and what role they were playing on the board. In my case, I presumably lost the use of one unknown square black component plus one cap, and the machine still operates apparently normally.

When running, the revived desktop looks like this (Apple System Profiler results shown):

Quadra 840AV Running Mac OS 8.1

Now it is time to turn my attention to the two 660AVs and see if I can succeed in breathing life into at least one of them.

The “body count” (deceased computers) from the move is slowly dwindling. At this point, I have revived all except the Quadra 660AVs and the last PC I owned before moving over to Macs as my personal computers – a 2003-vintage 3GHz Pentium IV with Windows XP. This one boots and runs, but eventually seizes up. It is clearly overheating and the CPU is shutting down. Restoring it will not be a trivial fix, but there is a straightforward path ahead of me that should recover the machine.

Another Long Hiatus Comes to an End

This is how it happens. Blogs like this don’t die, they just fade into obscurity, with posts becoming less and less frequent until finally one day the author writes a final post announcing what everyone had already deduced long since – the blog is no longer active.

Happily, that is NOT the case here at Happy Macs. As I type this, another long hiatus is coming to an end. Once again, we have moved from one state to another, gone into temporary housing and built a new home. That process, now complete, has taken almost exactly a year, and in that year the equipment that comprises the Happy Macs Lab has been securely nestled in boxes in climate controlled storage.

I am now busily unboxing all of them and getting everything reconnected and set back up. That is a long task, but I am making good progress. Regrettably, there have been casualties, as there always are when you move delicate equipment like vintage Macs. Two older Apple monitors were reduced to crushed piles of plastic and electronics, and thus far, both of my Quadra 840AVs are non-responsive. I have not given up on them by any means, but they will undoubtedly need lots of love and care to get them back into working order.

In addition to getting the Happy Macs Lab back “on the air”, the scope of this blog is broadening as well, to include the truly fascinating Apple IIGS, a machine that COULD have neatly bridged the worlds of Apple II and Macintosh, providing the sort of seamless ongoing upward compatibility that the Wintel folks managed to pull off. Regrettably, Apple focused all their marketing attention on the Macintosh and the Apple IIGs slowly faded away. It has a vibrant enthusiast group however and so in reality it lives on.

For those not familiar with the Apple IIGS, it was a wholly new 16-bit machine that could be run in 8-bit Apple II backward compatibility mode. In native 16-bit mode, it was a completely new game however, and by the end of its life cycle, it was running the GS/OS operating system, which is visually nearly indistinguishable from Macintosh System 6. The Apple IIGS was the first Apple computer to sport a color GUI and the first Apple computer to feature the Apple Desktop Bus. Upon its introduction in 1986, it outsold the Macintosh by a healthy margin.

With Apple II backward compatibility and an essentially Macintosh GUI, it could have dominated if Apple had chosen to pour their marketing muscle into it. Unfortunately they didn’t, but perhaps that is what makes the machine so fascinating… the “what if” scenarios are amazing to contemplate.

Anyway, look for more in the coming months on this amazing machine, and some new software for it that I have been busily creating over this one year hiatus.

The Happy Macs Lab, and this blog, live on!