64-bit build of Tutti II, the Tomy Tutor Emulator

A quick note that there is now a 64-bit macOS build of Tutti II, the best Tomy Tutor emulator other than MAME (being, near as I can tell, the only Tomy Tutor emulator other than MAME). This fixes issues with blank windows on 10.14 and runs correctly on 10.15, and damn well better run on 11.0. Don't worry, I haven't forgotten about Power Mac and 32-bit owners; you get a minor fix too with some improved timings. 32-bit Tutti II will run on any Power Mac or Intel Mac from 10.4 through 10.13; 64-bit Tutti II will run on any Intel Mac from 10.12 to 10.15.

Tutti II is open source; as of this release development has moved to Github. Although I don't offer a fully-fledged Win32 build yet, I do have work on a Windows port completed, and once I am satisfied it is of the same poor quality as the Mac versions, I will release that too. You can build it for yourself if you like if you have mxe and MinGW; I am willing to accept Visual Studio solution files if you come up with any.

RIP, Curt Vendel

Very unfortunate to hear about the sudden passing of Curt Vendel, a great figure in the Atari scene. The best Atari Flashback (2600 clone) was the second one where he learned from the error of using the "NES on a chip" in the first Flashback, and instead designed a system so compatible you could put a cartridge port in it and play your old VCS games (and a system so easy to hack that the board has specific solder points and guides you how to make the modification). Probably his most lasting contribution to vintage computing was the Atari History Museum he founded in 1988 with over 15,000 files, folders and documents, plus two entire room-sized archives of schematics, mechanical drawings, artwork and design film, some of this even salvaged from Atari's own dumpsters. He was only 53. Rest in peace.

A second look at computer stereoscopy with the Minoru 3D webcam and Camaglyph

This article will be part of a series -- you can read other entries

Did you see what I did there? I'm proud of that title. Thank you very much.

Is 3D vintage computing? Well, it's complicated. 3D in computing didn't really have much traction in the early microcomputer age because of the limited palette, resolution and computing power: it was hard enough generating one image, let alone two and then figuring out ways to merge them. (I have some ideas about that but more later.) Apart from colour anaglyphs, best known as the red-blue glasses method, early stereoscopic computing was generally limited to active technologies (i.e., show one eye and then show the other), and the slower switching rates made this a rather flickery, headache-inducing affair. While some higher-end video cards like the Nvidia Quadro FX 4500 in my Power Mac Quad G5 (circa 2005-6) have connectors for active stereo glasses -- in this case a 3-pin mini-DIN -- almost all of these were proprietary and very few software packages supported it. Worse, these glasses wouldn't work with flat-panel LCDs, which were already displacing CRTs by then, because of the higher refresh rates required. There were some home gaming products like the Sega Scope 3D for the Master System, plus the infamous Nintendo Famicom 3D System and Nintendo Virtual Boy, but these only succeeded in showing the technical infancy of the genre and possibly increasing local referrals to ophthalmologists. (I'm intentionally ignoring lenticular and Pulfrich stereoscopy here because of their limited applications.)

IMHO, stereoscopic computing didn't really hit the mainstream until the advent of Blu-ray 3D, which increased, at least temporarily, the home market for polarized LCD displays that could show 3D content using passive glasses. Colour anaglyphs are neat, and can be done well, but they necessarily interfere with the colour palette to ensure that each eye gets as separate an image as possible (even tricks like Dolby 3D do this, though usually imperceptibly). Although active displays are still a thing -- my 3D home theatre is DLP, and uses DLP-Link, which are 120Hz active glasses -- they're also heavier and have to be powered, and active display solutions are overall more expensive. Passive LCD 3D screens, however, were for at least a few years plentiful and relatively inexpensive, and most TVs of a certain vintage came with the feature when it was thought 3D would be the next big thing. 3D movie cameras powered many major studio production shoots and 3D movies were plentiful in consumer stores. Many games for contemporary consoles, notably the Xbox 360 and PlayStation 3, offered stereoscopic gameplay, and you could even buy computer monitors that were 3D. My secondary display is a Mitsubishi Diamondcrysta RDT233WX-3D, which is an exceptionally fine IPS passive display I ended up importing from Japan, but there were many manufacturers on both shores.

Well, those days have died. If you look at Wikipedia's list of stereoscopic video games, which is a good summation of the industry, there is a dramatic falloff around 2014. Most 4K TVs in the United States don't offer a 3D mode of any sort, partially for technical reasons I'll mention, and only a subset of console games still support stereoscopy. Many players will still play them but Blu-ray 3D movies are all but gone from the American market. While movie theatres still offer(ed) 3D showings, COVID-19 has kind of crushed that industry into little tiny theatre bits, and very few major motion pictures are filmed in native 3D anymore. I think it's safe to say that until such time as the fad revives, as fads do, stereoscopic computing has retreated back to the small realm of enthusiasts.

And, well, I'm one of them. I'm not as nuts as some, but in addition to the Diamondcrysta monitor I have a 3D home theatre (using DLP and DLP-Link glasses), a Vizio 3D TV, a Nintendo 3DS and a Fuji FinePix Real 3D W3 still and video camera. I've got heaps of Blu-ray 3D that I imported at sometimes confiscatory rates, but happily most of them are all-region. I'm pretty much on my own for software, though, so I figured writing a simple display tool for a 3D webcam was a good place to start with writing my own stereoscopic applications. And there's one available very cheaply on the remaindered market:

This device is the Minoru 3D webcam, circa 2009. Despite the name (it means "reality" in Japanese), the device is actually a British creation. It is not a particularly good camera as webcams go, but it's cute, it's cheap and it's 3D. However, it only comes with Windows drivers, and they don't even work with Windows 10 (probably why it's so cheap now). My normal daily driver is Linux. Challenge accepted.

The Minoru appears to the system as two USB Video Class cameras in a single unit connected by an internal hub; lsusb sees the two cameras as Vimicro Venus USB 2.0 devices, which is a very common USB camera chipset. Despite the documentation, the maximum resolution and frame rate of the cameras is 640x480 at 30fps and the 800x600 mode advertised appears to be simply software upscaling. Nevertheless, when treated as separate devices, the individual video cameras "just work" with Video4Linux2 in VLC (the "eye" lights up when it's viewing you), so what we really need is something that can take the two images and merge them.

The Minoru's included drivers offer a side-by-side mode but most people will run it in anaglyph mode. Appropriately, it comes with a metric crapton of cardboard glasses you can give to your friends so they can see you in all your dimensions. There are many colour schemes for anaglyphs but the most common is probably red on the left lens and blue (or preferably cyan) on the right, and there are many algorithms for doing that. I wrote a simple V4L2 backend that runs both camera sides simultaneously and pulls left and right frames with an SDL-based frontend as the visualizer, and then selected two methods that are generally considered high(er) quality.

The first, the optimized anaglyph method, is quite straightforward to implement: for the merged image, use the green and blue channels from the right image, and compute the red channel of the merged image using 0.3 of the left image's blue channel and 0.7 of the left image's green channel. (Some versions of this boost use a 1.5 factor prior to merging them, i.e., a 50% boost, which helps with dimness, but means the resulting value needs to be clamped.) This has the effect of dropping both images' red channels completely but the eye can compensate somewhat, and the retinal rivalry between eyes is reduced compared to more simplistic methods. A SIMD-friendly method of doing this is to simply copy the entire right image to the merged image, and then overwrite the red channel in a separate loop. There is still a bit of ghosting but this sort of image can be rendered very quickly. Here is an optimized anaglyph image of yours truly from the Minoru, viewable with red-cyan glasses:

A superior and widely adopted anaglyph method is the one devised by Eric Dubois. His innovation was using a least-squares approach in the CIE-XYZ colourspace which can be approximated with precomputed coefficients, using matrix multiplication to merge the two images. It is slow to compute and requires saturation math to deal with clipping, and reds get turned into more of an umber (you can see this on what's supposed to be my red anaglyph lens), but the colour rendition is overall better and ghosting between the two sides is almost absent. Here is a Dubois image of me in almost the same position, also viewable with red-cyan glasses:

But anaglyph is just not satisfactory for good colour rendition even if you get accustomed to it, and even the best anaglyph glasses with good lenses and dioptres will still have some ghosting between sides on most colour images. This is where passive 3D comes in.

Most passive 3D monitors use alternating polarization, implemented as either a second glass substrate called a patterned retarder, or more recently using a film overlay (called, naturally, a film-based patterned retarder). Each separate line of the display alternates polarization, which without polarized glasses only shows up as a very faint linear interlace. My Diamondcrysta and Vizio passive 3D displays are 1080p, so with glasses off you get all 1080 lines, and with glasses on 540 lines go to one eye and 540 lines go to the other. (This is probably why 4K displays don't do this, other than cost: it would make upscaling 3D 1080p content lower quality because the horizontal lines cannot be interpolated or smoothed.)

This is obviously lower 3D resolution than an active display, where the entire screen (like on my DLP projector) alternates between each eye. However, the chief advantage to us as homebrewers is that the polarization is an intrinsic property of the display -- anything displayed on that screen is subject to it, rather than relying on some vendor-specific video mode. That means anything can display anything in 3D as long as you understand which lines will be activated by what you draw.

My Diamondcrysta is a R-L display (the polarization goes right-left-right-left-etc.), so starting with line 1 at the top, odd lines must show the right image and even lines the left image. This requires us to find out where the actual image is positioned onscreen, not just the position of the window, since window decorations will shift the image down by some amount. SDL 2.0 will tell us where the window is, but I'm using SDL 1.2 for maximal compatibility (I'd like to port this to my G5 running Mac OS X Tiger), so instead when we display the image we ask SDL for the underlying widget, get its on-screen coordinates, ask X11 how big the window decorations are and then compute the actual Y-position of the image. You could then draw the merged image by doing alternating memcpy()s line by line, but with today's CPUs with potentially big SIMD vector registers, I simply did a big copy of one entire view and then on every other line drew in the lines from the other view, which is noticeably faster. This yields the following image, which redraws itself with the proper lines in the proper places when the window is moved:

You'll need to view the full-size image (click on it). To view this on a passive polarized 3D display or a 3D TV acting as a monitor, you've got exactly a 50% chance that your web browser will already have it at the right Y-position. If it doesn't, you may want to save the full size image to disk, open it up on that display, and shift its window up or down pixel by pixel with your polarized glasses on until it "pops." Your monitor does not have to be put into any special "3D mode" for this to work.

The source code is in pure C, runs entirely in userspace, and should build on any Linux system (including big-endian) with V4L2 and SDL 1.2. I call it Camaglyph and it's on Github. It's designed to be somewhat modular, so once I sit down and write a QuickTime or QTKit grabber I should be able to make this work on my G5. I've included a configuration file for akvcam so you can use it as, you know, a webcam.

In future posts we'll look at converting classic games to work with stereoscopic displays instead of just having anaglyph modes, and explore some ideas about how we can get classic computers to display anaglyph 3D.

PAL RF or bust with the LCDT600: unscreenshotable part IV

This is part of a series — you can read prior entries

For the Secret Weapons of Commodore, part of the updates for the 15th edition involved the Commodore TV Game series, Commodore's unusual and infrequently seen family of Pong clones based on their own MOS 5601 and 7601 Pongs-on-a-chip. It would have been nice to get screengrabs of these, but not only are they strictly RF (i.e., analogue television), they're PAL, and I'm here in the United States of COVID-19. While many PAL TV sets could be dual-mode, NTSC sets almost never were, and nowadays everything is digital anyway. So what to do? Get a TV tuner that emits some other signal you can capture. And, incredibly, such a thing exists: the LCDT600 and LCDT601.

These are rebadged by a variety of distributors but except for some case and button differences are the same basic unit, and most retail for around US$60. As the ports on the rear show, the LCDT600 is a multifunction device that takes input from either composite CVBS video, S-video, VGA (using a strange mini-DIN port, but a converter is in the box) or RF, and then emits it to VGA at a variety of resolutions. Audio is supported, though not needed for our particular purpose, and the unit also allows you to overlay video from another source on top of the VGA output for "picture-in-picture." The LCDT600 and its newer but otherwise identical sibling LCDT601 emit at resolutions from 800x600 through 1920x1200, all at 60Hz, controlled by a chintzy little mini remote. Most of the machine's functions are controlled with on-screen menus, so don't lose it.

We are most interested in the tuner, and the LCDT600 does well here too. Out of the box it has a standard PAL female jack, which the TV Games connect to readily, but can be converted to an NTSC F-style jack with a simple converter (also included). It tunes NTSC and PAL B/G/D/K/I. Some primitive post-processing is available to smooth the images, but I didn't really test this thoroughly.

Capturing the stream, then, is merely a matter of capturing the VGA output. Fortunately, we already have a device for that: the INOGENI VGA2USB3. And since the LCDT600 emits at 60Hz, the signal is fully compatible with the VGA2USB3, so no further conversion is required. I was able to view the stream in VLC on my Raptor Talos II workstation and take direct screengrabs from there.

However, the next problem is I have no idea what channel the TV Games transmit on, let alone the frequency. Fortunately, the LCDT600's auto channel scan comes to the rescue, after I changed the on-screen language to English instead of Chinese and set the TV standard to PAL-G (since these were Western European devices):

With the TV Game console connected and turned on, the LCDT600 easily found the channel it was transmitting on and presented credible pictures. There is some smearing with bright white but otherwise relatively little chroma noise. Here are some full-res grabs, the top two from the TV Game 2000K and the bottom from the TV Game 3000H:

If all you've got is RF or bust, then the LCDT600 is probably the best and easiest solution, and the price isn't exorbitant. Nothing will make super-sharp images but at least you'll have them.

On a related note, if you can't get a look at the main chip on the TV Game 2000K board because the motherboard is soldered in place underside up, use a little cheap USB camera probe to get a look at the other side:

Now go read the 15th edition updates for the Secret Weapons of Commodore.

Refurb weekend: Mac mini G4

A year ago, I set up a Mac mini G4 as a network bridge running NetBSD (the "secret last generation" with a 1.5GHz G4 CPU), and it rapidly became one of the hardest working machines in my machine room. Last week, it abruptly ceased responding.

I went and looked at the console, and found it had thrown a couple ATA controller timeouts and then seized up completely. I restarted it and fsck started timing out on sectors all over the place. Hah! said I. The hard disk must have crapped out. It was still running an original hard disk, and those certainly fail with time, so that didn't seem at all strange to me. That means we're gonna have ... a Refurb Weekend!

Since I was expecting to replace the drive anyway, I figured I might as well make it an SSD and bought an inexpensive Kingston mSATA. The drive I was replacing was 80GB, and I could get 120GB nearly for the same price, so we'll call it an upgrade.

The G4 Mac mini only takes 2.5" PATA drives, thus requiring a laptop mSATA-PATA enclosure as well.

Let's get out the putty knife. Yes, that's really how you crack these older minis open ("crack" being, sometimes, the operative word). We jam the blade into the space between the base and the metal top case and work around the outside, freeing up the clips, until we can pull out the base.

The G4 mini comes apart basically in two halves, the motherboard sitting on the base (usually with the Bluetooth-WiFi module mounted on it, and/or the modem on older models) and then this drive cage/fan assembly that contains the optical drive, hard disk and main cooling fan. This unit has the infamous original Apple-rebadged Panasonic UJ-845-C slimline drive. These fail if you look at them crossways, and this one was already refusing to read burned CDs from certain manufacturers, but we're not here to replace that currently. The antennas on top are for the Bluetooth and WiFi, and sit under holes cut out for them in the metal of the top case. We unscrew and pull the drive cage from its logic board connector, making sure to unmount and thread through the antennae. There's a bit of Kapton tape securing these and the wires for the power button to the drive cage; make sure you peel those back too.

The drive cage is now separated from the logic board. Ugh, dusty. Blowers employed at this point on the fan blades, fan race, air intake, processor heatsink and logic board.

There are four screws holding the hard disk in the cage. The two on the exposed side are easy enough to see, but one is under the fan (the fan screws are rather tightly threaded, so they need a little bit of cranking to get out without stripping them), and the last one is only easily accessible with a shafted driver through an access hole provided for that purpose (covered, obnoxiously, also with Kapton tape).

With the screws out, a little prying (not too much, or you'll bend the card and/or the pins) with a nylon spudger will push the drive off the socket on the interposer board connecting both the optical drive and hard disk. I intended to do a little post-mortem on it, so I put it aside and picked up the new drive in its enclosure.

The main drive is actually suspended with a slight air gap between it and the optical drive; they are not flush. Wedging the spudger in between will make it easier to line up the screw holes.

With that done, I screwed back in the fan, threaded the antennae back through the drive cage on top, carefully made sure the interposer board was plugged back into the logic board, screwed down the drive cage, remounted the antennae on their mount points and replaced the top case. I got out my trusty iBook G4 to format and partition the drive, hooked the mini up to the iBook via FireWire and held down T as the mini started up ("bonnng!") to enter FireWire Target Disk Mode.

... nothing happened. The monitor stayed dark. Huh.

Well, sometimes the Mac's parameter RAM gets scrambled after a hardware change, so I reset PRAM with Command-Option-P-R. (Probably should have replaced the PRAM battery — a 3V 2032 or equivalent — while I was in there.) I held the keys down, made sure it bonged a few times, and let it try to boot whereupon it (expectedly) displayed the "No system folder" icon. The drive is of course blank so that seemed okay, so I popped in a CD I knew it would boot from, restarted the mini and tried to boot from it with the C key. Still nothing. Time to get to the Open Firmware prompt (Command-Option-O-F while starting it again) and figure out what was wrong.

A little known trick is that you can start FireWire Target Disk Mode from the Open Firmware ok prompt too (after all, holding down T is just a snag key shortcut). This is useful for showing a little more information about what's going on; it shows debugging messages while starting up and while the other system is connected. The magic incantation is dev /firewire-disk-mode and then target-mode.

Yikes! No drives are showing up! No wonder Target Disk Mode didn't do anything!

I powered down the mini and removed the top case to ensure the interposer board was mated to the motherboard. It was. This could only mean the controller died and/or the logic board was shot, and the hard drive wasn't actually the culprit. Well, that's why we keep spares around! I had a spare G4 mini of the same speed with the drive cage from my dad's old system (new OEM optical drive and 120GB hard disk, both of which I installed for him back in the day); let's put the SSD in that system instead.

Transplanting the SSD from the old drive cage to the new one on the right and blowing dust out of every orifice on this one as well. I also replaced the PRAM battery while I was at it, since the voltage was measuring a little low.

Before packing up the old system for the parts bin, I wanted my CD back, but with a shot board the mini couldn't command the drive to eject it through software and unfortunately these drives don't have an eject hole. Instead, to get a disc out of most Panasonic UJ-series laptop drives, it's a matter of removing the top shell screws and taking off the cover, and the CD can then simply be popped off the spindle. The drive is defective anyway so I didn't bother reassembling it since it'll just go to the recyclers'.

That's more like it! Notice that, having manually started Target Disk Mode from the Open Firmware prompt, we have a little debugging log on the left half of the screen. The iBook G4 was able to partition and format the drive successfully.

Finally starting NetBSD/macppc 9.0 from the CD, since we've now got a working optical drive "for free" and we might as well upgrade the OS since we're reinstalling it. The system is back up and running.

This was an unexpected fault, and while a logic board failure on a 15-year-old computer is certainly not unheard of I wouldn't ordinarily think the board would fail before a spinning disk would. It's probably just bad luck, but there is one thing I chose to do differently with it: for this unit, as an experiment in longevity, I was using the Intel Core 2 Duo mini's 110W power supply because it has the same connector and same voltages but requires less of its capacity than the G4's 85W stock supply. I don't know if doing so had anything to do with it or not, but now that its power usage is even lower than the 21W it typically pulled before (down to just 15W), I put the original 85W supply back in service.

Overall, I think it might have been better to call this endeavour a Replacement Weekend, since it's now got a replacement logic board, a new SSD and a new-ish optical drive. It's still good to have the system back up and running, but now I think I'd like to find another spare.

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.

Carry on (the) Arithmometer

There are a number of devices that go by the name "Arithmometer," including the original one which went into production in 1851. They aren't computers, to be sure, and are best described as mechanical calculators, but I like them because they're fun to play with, they don't need a power source (other than a stylus and your fingers), and — as the manual for this Tasco Pocket Arithmometer says — if they're operated correctly the machine will always give you the correct answer immediately.

The Tasco Pocket Arithmometer here has an unusual lineage that appears to start in 1913 in Germany with the Trick Rechenmaschine (Trick Calculating Machine), though "trick" may not be the image you'd want in mind to suggest accurate accounting. The Trick itself is an evolution of the "slide adder," using rows of sliding numbers to calculate sums; its primary innovations were a semi-automatic carry feature and a sliding subtraction plate, making it probably the prototype of this class of "shepherd's crook" mechanical calculators. In the 1920s the design ended up Stateside and was manufactured by the Gray Arithmometer Company in Ithaca, NY. These early units had a dull nickel finish, and some are labeled Morse Chain Co., who were at one time the primary distributor. Somewhere around 1940 to 1945 manufacture of the product was taken over by Tasco, apparently unrelated to the modern manufacturer of crappy telescopes, who produced it in almost exactly the same form except for a new name plate and a chrome finish. They seem to have been manufactured at least through the 1950s, and came with a manual, a metal stylus that could poke out an eye and a little leatherette snap case.

The T-P-A does addition and (with the use of the sliding subtraction plate) subtraction. Since multiplication is merely repeated addition, it can do that too, and division via repeated subtraction with some additional effort, though these are plainly not its strong suits. I'll talk specifically about addition here, being the T-P-A's primary function.

Numbers are dialed in by pulling the top tab, which clears all the columns, and then by using a stylus in the provided holes. The metal between the holes is either white or red. When the colour above the number is white, we pull the stylus down; when it is red, we pull it up. In this animation, we demonstrate twelve plus five by dialing 2 and 10, and then pulling down 5 to yield 17:

The "hook" at the top (or at the bottom, when the subtraction plate is engaged by sliding it up) is the automatic carry system. When adding, the stylus gets pulled up and over the hook to add one to the next column. Here is 12 plus 9, dialing in 2 and 10, then pulling up and over the 9 to yield 21:

Although fascinating and intuitive when you know the trick, the manual assumes a lot of someone not already familiar with this style of calculator. In particular, while the automatic carry is innovative, it does not cascade. The reason for this can be seen when we try to dial in 999:

The left-most 9 (in the hundreds place) has a block in the right, but the stylus can still move into the hook. However, the other two nines in the tens and units places are "double blocked": two blocks completely prevent the stylus from advancing into the hook. What the manual doesn't make clear is that you have to cascade the carry yourself if you have multiple positions that are double blocked. Let's consider how to add 1 to 999.

1. We attempt to add 1 to the rightmost column. This column is red, so we put the stylus in the one-slot and pull it all the way up (yielding zero), but this column is double blocked so we can't move into the hook to automatically transfer the carry.
2. We thus attempt to add 1 to the next column as well, but it's double blocked also, so we end up zeroing that column too and continuing to move the carry to the next column to the left.
3. This last column is single blocked, so now we can finally pull the one up and over the hook, setting it to zero and carrying the 1 automatically. There's nothing more to add, so we're done.

By cascading the carry over multiple columns, the machine reads 1-0-0-0, which is the answer.

Similarly, consider adding 11 to 999. This is nearly the same, except having added the 1 and propagated the carry left, we then just add 10. The columns now read 1-0-1-0, which is the answer.

Finally, let's consider the case of 999+999=1998.

1. We attempt to add 9 to the rightmost column, but it is double blocked. Instead, we put the stylus in the nine-slot and pull it up, setting this column to 8, and carry the 1 to the left.
2. We attempt to add 1 to the next column, but it is double blocked, so we put the stylus in the one-slot and pull it up, setting this column to zero, and carry the 1 to the left.
3. We attempt to add 1 to the next column, and it is single blocked, so we put the stylus in the one-slot and pull it up and over the hook, setting this column to zero and carrying 1 to the left.

At this point the dials read 1-0-0-8, but you've probably figured out the next two steps already:

4. We add 90 (1-0-9-8).
5. We add 900 (1-9-9-8).

Demonstrated below:

This is the answer, correctly and immediately.