Showing posts with label appletalk. Show all posts
Showing posts with label appletalk. Show all posts

Saturday, March 2, 2024

An Apple district manager's Macintosh Portable in 1989-91 (featuring GEIS AppleLink and a look at System 7.0 alpha)

A few months ago I introduced you to one of the more notable Apple pre-production units in my collection, a late prototype Macintosh Portable. But it turns out it's not merely notable for what it is than what it has on it: a beta version of System 6.0.6 (the doomed release that Apple pulled due to bugs), Apple sales databases, two online services — the maligned Mac Prodigy client, along with classic AppleLink as used by Apple staff — and two presentations, one on Apple's current Macintosh line and one on the upcoming System 7. Now that I've got the infamous Conner hard drive it came with safely copied over, it's time to explore its contents some more.
We'll start with this Macintosh Portable itself and Apple's sales channel applications, moving from there to a brief presentation of Apple's Macintosh product line as Apple's own marketing staff would have presented it, at a distinct point in the company's history.
After that, we'll also look at the upcoming System 7.0 circa 1989-90 and a couple very different views of the operating system during its alpha phase.
Finally, after a brief glance at Mac Prodigy, we'll explore a little taste of AppleLink in its classic incarnation on General Electric's Mark III network — and spoof it enough to actually get it to log in.

Thursday, November 26, 2020

Not a refurb weekend: Apple IIgs

The most advanced Apple II computer was, of course, the one Apple insisted would be a dead end: the 1986-1992 Apple IIGS. And the reason was simply that the GS was too good a computer, offering Apple II compatibility, 16-bit performance, a 4096-colour palette with up to 640x200 high resolution graphics, and one of the best sound chips since the SID in the Commodore 64 (in fact, Bob Yannes designed the SID, then went on to found Ensoniq who produced the GS'). It was so good, in fact, that it posed a real risk during its development of cannibalizing sales from the Macintosh. Apple thus made sure it couldn't be a threat by deliberately hobbling the 16-bit 65816 CPU to just 2.8MHz when it was capable of up to 14MHz and at minimal additional cost, and intentionally never did more with the system publicly other than token ROM upgrades and pathetic bumps in memory. It takes some truly inspired buttheadery to hold back a fabulous system in that fashion, but that's what Apple was capable of in those days, and arguably still is.

This particular computer in my collection — and yes, that's a Canon Cat next to it, a topic for another day — is a Frankenstein assembled from three partially working units. It has a ROM 03 motherboard (the last revision not counting the 8MHz "Mark Twain" prototype) but with a Woz Limited Edition topcase just 'cuz, a 1MB Apple RAM expansion card (for 2.125MB of memory), an original 7MHz Applied Engineering TransWarp GS CPU accelerator with the 8K cache daughtercard, and a 20MB Applied Ingenuity InnerDrive consisting of a SCSI card plus a unified drive enclosure and replacement power supply. It is connected to an ADB keyboard and mouse, a LocalTalk network box, an AppleColor RGB display, an Apple joystick and 3.5" and 5.25" floppy drives, and boots into GS/OS 6.0.1.

A few months ago after I got LocalTalk up and running and was transferring some other things to it, it started to get flaky, and would invariably crash into the Apple machine language monitor after sitting at the GS/OS Finder for a few minutes. This machine was certainly produced in the "crap caps" era and bad capacitors are in the differential diagnosis, but with so many things installed a more systematic approach would be required. Today it's the Thanksgiving long weekend during a pandemic, and I've got only dayjob work and take-out dinners to look forward to for the next several days. Sounds like an opportunity for another ... Refurb Weekend!

First, let's pop the hood and check for obvious damage. I blew out some dust with an air can, but everything looked pretty shipshape otherwise.

Looking overhead you can see the combination drive cage-power supply for the AI InnerDrive plus its ribbon cable to the controller card. Between the controller card and the enclosure is the TransWarp GS, and the Apple RAM expander card is furthest away.
Closeups of the InnerDrive and TransWarp GS cards.
Closeup of the Apple RAM Expansion card (670-0025-A).

To check for board damage, you also need to remove the power supply, since a couple large capacitors sit under it and, inconveniently with the larger size of the AI combo cage and PSU, the PRAM battery.

Clean as a whistle. I even got out the multimeter and checked the PRAM battery, and it still reads a full 3.65V.

I'm not a fan of prophylactically replacing capacitors that are not obviously bad, especially since you have a non-zero chance of accidentally breaking something in the process of fixing what ain't broke to begin with. At this point I resigned myself to having to test components independently: remove or disconnect something, fire it up and see if it crashes. I was strongly suspecting either the TransWarp card or the RAM expander, since those would certainly cause random failures. For that matter, it might even be heat related. Anyway, to get a baseline, I went ahead and disconnected the LocalTalk network, the joystick and the external drives, rebooted it and waited for it to crash.

After an hour it was still cheerfully sitting at the Finder. I fired up a game of Crystal Quest GS (ported by Becky Heinemann, who also wrote the firmware for the InnerDrive and had very nice things to say about TenFourFox). No crash. I fired up Wolfenstein 3D (ported by Logicware, which Heinemann co-founded). No crash. I played some Tunnels of Armageddon, one of my favourite GS games (no known connection to Heinemann). Still no crash.

I reconnected the joystick and let it sit for a few minutes. The joystick doesn't work too good, but it didn't make anything crash.

I reconnected the disk drives (best done with the power off, just in case) and let it sit some more. The machine had gotten good and warm with all this burning-in, so if heat was a factor, it should have been by then. No crash.

I reconnected the LocalTalk box and let it sit a couple more minutes. Boom, straight into the monitor while it was sitting idle.

I powered it off, disconnected the LocalTalk box, rebooted and let it sit a couple more minutes. No boom, no monitor, normal operation. The LocalTalk network was crashing GS/OS. And, actually, this makes sense, because the last thing I was doing with it before it got "wacky" was copying stuff from the network. It had never been connected to the house LocalTalk segment before because it never needed to be.

So what's crashing it, and why doesn't it do so right away? My guess is that the delay is because something on my household AppleTalk network transmits a packet intermittently that GS/OS's stack doesn't like. The segment itself couldn't be the cause because there were no other LocalTalk hosts up (the 486 and the Colour Classic are both connected to the segment, but neither were on). A Dayna EtherPrint-T bridges the LocalTalk segment to the main Ethernet via EtherTalk; on the other end of the Dayna is the little Macintosh IIci running old Netatalk which services old hosts, this Raptor Talos II running modern Netatalk which doesn't, and the G4 Sawtooth file server running Tiger (not Netatalk). Any one of those could be sending packets that GS/OS 6.0.1 just doesn't know how to cope with, but a cursory Google search and a look through comp.sys.apple2 didn't come up with anything similar. A mystery to be further investigated in a later entry.

In any event, it's good to see it doesn't appear to be caps nor hardware, and there are other ways to get files to the GS, so not having LocalTalk isn't the end of the world. Turns out this wasn't a Refurb Weekend after all, but who's complaining? That said, however, now that it's back in its right mind there are some future upgrades to do. The first is to consider some other means of mass storage since even old battleaxe SCSI drives don't last forever, and the InnerDrive firmware is notorious for only being able to work with a very small number of specific drive geometries (forget using a drive much later or larger than the 20MB one it has). A Compact Flash card solution exists and would seem the obvious choice rather than faffing around with another SCSI controller. The second is to put the full 8MB of RAM in it; there are some third party cards still made by homebrewers that will do this. If nothing else, between the two of them I'll be able to shoot a whole lot more Nazis for a whole lot longer, and that's always a(n Apple II) plus.

Saturday, July 25, 2020

AppleShare PC on MS-DOS and the Apple LocalTalk PC Card

One of the machines in my office is a non-descript Am5x86/133 (486 class, infamously claimed by AMD to be "Pentium 75 equivalent") in a generic tower case that exists purely to play MS-DOS games I like and run a few DOS-only applications. Its name is Alex, after Alex St. John, who was the evangelist for DirectX during his tenure at Microsoft (despite the fact this machine does not have any version of Windows on it).

Being a late 486-era system it has an ISA motherboard with a couple VESA Local Bus slots and not a scrap of PCI. Most of us of a certain age will remember how rickety lots of cards in a VLB/ISA system could be, though fortunately the (ISA) Sound Blaster ViBRA 16X and (VLB) S3 86C805-P cards work, so games work and that's what it's largely here for anyway. In fact, some games only work on this system that won't work with my AT&T Pentium 75. One thing I have never gotten working on it, however, is networking. I've tried several ISA network cards, even a Xircom parallel port adaptor, and nothing will talk to anything else on the network -- with the exception of AppleTalk using Apple's own ISA LocalTalk card.

The Apple LocalTalk ISA card was actually a fairly early release, appearing in 1987 just two years after LocalTalk debuted to allow Macintoshes to connect to the new LaserWriter printer, an integral part of the benighted Macintosh Office initiative. The fact that AppleShare for the Mac appeared the same year is notable, since PC support for LocalTalk networks must clearly not have been an afterthought at Apple. Although a company called Tangent Technologies was apparently first to the punch in 1985, it doesn't look their PC MacBridge product sold in any large numbers, and I've never seen one myself.

The card uses a standard 8-bit ISA slot and has its own 6502 CPU (a Rockwell R65C02) running at 3.6864MHz with an 8K 2764 ROM ("© APPLE '86") and an 8K 6264 RAM chip. Like Macintoshes, the RS-422 serial support is provided by a Zilog Z8530 Serial Communications Controller (here the second-source VLSI Technology VL8530). The "PCI" marking in this case means PC Interface, not actually PCI slot logic, provided by an MMI PAL16R4ACN programmed for the purpose. I don't know what the DIP switches do; my cards have switches 1, 3, 4 and 6 off and 2, 5, 7 and 8 on, so I assume those are the factory settings.

The sticker 630-5306 on top is covering the original Apple part number, 630-0113. I don't know why Apple used a different number, because I have a -0113 also, and they seem to be otherwise identical. Just to make things confusing, there is also a later 630-5306 card ("©1986/87" rather than "©1986") with that part number actually printed on the board that has a later ROM copyrighted 1989.

Here it is installed in the back of Alex. You'll note it does not have the more typical Mac 8-pin mini-DIN connector and instead has a more PC-like DE-9 serial port. That's actually because Macs of that generation didn't have mini-DINs either, so you had to get the Apple LocalTalk Locking Connector Kit DB-9 [sic] package, sold separately of course, to hook it all up. However, I have a Farallon PhoneNET connector plugged in here instead which they manufactured with a DE-9 port as well, and I then use a Dayna EtherPrint-T to bridge the LocalTalk segment to wired Ethernet. The EtherPrint-T doesn't do MacIP (that is, IP over LocalTalk) but it does do LocalTalk to EtherTalk bridging pretty much seamlessly and was less mucking around than with a GatorBox, so that's what we've got.

The software side was provided as a DOS Terminate and Stay Resident (TSR) program, sold as AppleShare PC. I have both AppleShare PC 2.0 (1987) and 2.0.1 "2.01" (1989), but unless you have very old machines on your network you really want 2.0.1 for proper support of AppleTalk Phase 2. Interestingly, the earlier version was on 3.5" floppies, but the later version I have is on 5.25". The TSR provides a "desk accessory" triggered by a hotkey combination (by default Ctrl-Alt-Esc) that pops up and lets you log on, mount and unmount network shares as DOS drive letters. Since I have two hard disks and a CD-ROM as C: through E:, the AppleShare volume invariably appears as F:.

Let's see how this works. I took these pictures transferring across yet another vain attempt to get the NIC working for useful purposes (it failed, of course, because this machine hates me). Rather than do screen captures I've chosen just to photograph it with my phone to give you the full 1990s PC CRT monitor experience.

Booting up. All the little submodules consume rather a lot of conventional memory to the point where many games won't run, so one of the first things I did after installing the software was set up a boot menu (it runs MS-DOS 6.22) with separate profiles for games and the LocalTalk card. With the 2.01 software loaded, and the sound and CD-ROM drivers, I have just 432K of conventional memory free despite loading 66K of everything else into the UMB. (I don't miss DOS memory management at all.)

The desk accessory immediately starts after load to let you mount a volume. Here I will mount Jonathan, my Power Mac 7300 with a Sonnet G4/800 running Mac OS 9.1. You don't need to know the other servers, spank you very much, but the software seems only to "like" "real" Macs: it will not log on properly to thule, my NetBSD Macintosh IIci running netatalk, despite it being a "real" Mac, and it obviously doesn't know how to do AFP-over-TCP so you're limited to hosts running Jaguar (10.2.8) and prior.

Logging on. Using function keys to proceed is not really intuitive. One wonders if Apple did that on purpose.

Jonathan has two drives, each an individual volume (HFS+ volumes work fine), so we will pick the main drive and mount it as F:. As a convenience you can automount drives on boot, just like a Mac could.

And here are the contents of the newly mounted network share. Files and folders that have a resource fork have an exclamation point prepended as a visual warning they are not PC files, and there are no LFNs (please, it's 1989), so filenames just spill into the extension (!System.Fol for System Folder). If names clash, a digit is used (!Games_t.hat versus !Games_t.ha0, using underscores to replace spaces within the filename and extension fields). Just two files show up without a "!", which are the ones I earlier FTPed over to the Power Mac 7300 and have only a data fork.

While network transfers are in progress, a little set of arrows appears at the upper left, almost sorta kinda like a Mac would do.

Files are copied (regular old DOS COPY), so let's log off. It still doesn't work, of course, and I'm pretty sure I have the right packet driver and everything else. I'm going to have to take this machine apart down to the slots to figure out why. Anyway!

AppleShare PC 2.01's "About" box, just for completeness. Interestingly, the PC driver is given as version 2.61, but everything else is 2.01. I don't know anything about the authors. Do you?

There are some odd things about this card but it could again just be something wacky about this system. One of the oddest is that the packet driver I tried to set up for the SMC EZ 1660 NIC it has in it now actually knocks the LocalTalk ISA card completely off line, as in it won't respond to commands anymore until I power down the system, let it sit a bit, and bring it back up.

LocalTalk was gradually displaced by EtherTalk as Ethernet became more commonplace, and the PC ISA card was relatively expensive and limited to environments where Macs and PCs co-existed, so Apple never observed strong sales and discontinued the package with the rest of their LocalTalk offerings around 1991. There were a surprising number of third-party versions, though. After Apple quit LocalTalk entirely and handed the market over to Farallon, Farallon produced their own version of the card, allegedly strongly based on Apple's, until 1993 or so and integrated the software into the Windows 3.x versions of Timbuktu. It was still DOS-based, however, and the two halves I'm told never fit together well; issues with Windows 95 seem to have limited its further evolution. Daystar reportedly bought out Tangent and produced additional cards branded as the Daystar LocalTalk PC Card, but I've never seen one of those either. Dayna and Centram Systems also apparently made their own versions too; a company called COPS bought out Dayna's and Daystar's products and continued to produce them for several more years. Some of these cards had proper DOS ODI and NDIS drivers, so it was eminently possible to use those under Windows 95 or 98 with Miramar MacLAN or Thursby TSSTalk. NT 4.x drivers also apparently existed for the Daystar card(s). Miramar MacLAN is particularly handy as it allowed peer-to-peer networking with other AppleTalk clients without needing Windows NT.

Other than ISA cards, there were parallel port ones, but these were apparently crummy. One company even made a prototype PCMCIA LocalTalk adapter but it was never released.

Besides regular EtherTalk, some DOS Internet suites provided packet drivers for the LocalTalk card, the analogous equivalent to MacIP on a "real" Mac. However, you need to set up a AppleTalk IP router for this, so I haven't tried this functionality and it would be just as slow as MacIP would be otherwise. Still, I guess it beats no networking at all. Overall the card is an interesting device, it worked out of the box and it's still working reliably years later, so if I end up only being able to transfer files this way there are worse first world problems to have.