about Classic Macintoshes

2025-03-14 | [retro-files]

Some notes about dealing with files and networking and other stuff on my compact macs, and moving them between modern computers. I have a Macintosh SE and a Macintosh SE/30. I learned all this once before, but it's been a while and I forgot, so this time I'll write it down. There's also been a few developments since I last checked, so I'll look at that too.

All this from someone from long after the classic mac era. My desktop OS is Linux Mint, my server OS is Debian, and I don't really use modern OS X / MacOS. Classic macs are fun historically - not counting the Apple Lisa, Xerox and some other early ones, the Mac was first to a GUI in a lot of ways. Using one is like looking at some offshoot experiment that never caught on, except it did.

Things that make it hard:

• The computers don't have compatible hardware, even if it looks like they do (serial ports, floppies)
• Files on these aren't quite like files you are used to (the resource fork)
• Networking is pre TCP/IP and nearly pre Ethernet

Also:

• Classic Mac OS changed over time and was around for a while, but has been gone a long time. So, if you research it, the whole era kind of gets mushed together, and it's hard to tell what information applies to which version at which time period. Classic macs were on the internet before the web was invented, but were also around for the dotcom boom.
• Enthusiasts are still working on these systems - a lot of new stuff has come out in just the last few years! While good, it also generates a lot of information - incomplete documentation, and branches off branches of both software and hardware, as everyone makes various fork to go their own way. Similarly, it can be hard to tell which thing you should use, which one is current, and which ones are abandoned.

Working with classic Macs is interesting, because sometimes you'll see something that was years ahead of it's time, and other times you'll wonder how anyone was able to get anything done inside of this wild west nightmare.

Some terminology

• The original Macintosh was released in 1984. It was the first Compact Mac (the kind that are an all-in-one design with a 9" black and white CRT), and the first 68k Mac (uses a Motorola 68000 processor).
  • Some later macs lost the Compact Mac form factor and were more like PCs with a tower and monitor
  • From the original 68k, the more powerful 68030 and 68040 were used, before the whole platform moved to PowerPC processors in the 90s.
• Classic Mac OS is what these old macs run as the operating system. This was originally called System Software and went from System 1 to System 7, before being renamed to Mac OS. Mac OS had versions 8 and 9, before the Unix-like OS X would entirely replace it in 2001. Much later, modern OS X, which is what modern Macs still run on, was renamed to MacOS.
• People still needed to run some of the older Mac OS software, so the Classic Environment was included on early OS X machines which was a compatibility layer that would let you run some Mac OS 9 apps. Some of those machines could also boot Mac OS 9 outright. This is where "Classic" Mac OS comes from. It is also used to refer to the computers themselves: Classic Macs.
• Not to be confused with the Macintosh Classic which was one of the versions of the Compact Mac. So the Macintosh Classic is also a Classic Mac, but not all Classic Macs are Mac Classics.

What is the Resource Fork?

So you know how on most modern systems, the file extension determines what kind of file it is? It's kind of like that, but much further extended. Each file in classic Mac OS is like 2 files. One is the normal data stuff you are used to. Got a text file? The text is in the data fork. The other part is called the resource fork and all sorts of stuff can be stored in there - icons, menus, window sizes and positions, executable code, and more. It's the sort of stuff that might be in a file header these days.

The problem is that since nobody else does this, whenever you transfer files between systems using any kind of cross-platform thingy, only the data section goes through. If you try to move files around using PC formatted floppy disks, or XMODEM/ZMODEM/KERMIT on serial ports with a terminal emulator, or HTTP/FTP over the network, the resource fork is discarded in the Mac -> elsewhere direction, and never existed in the elsewhere -> Mac direction. This is fine for some things like text files, documents and archives, but try to move an executable through and it will be a 0Kb file on the other side. A disk image file might lose the file type, and since DiskCopy doesn't open just any old file, it won't work with it, even though all the data is there. To make matters worse, some software can deal with files missing resource forks, but does so silently, so you might never know you were doing something wrong.

For this reason, a lot of stuff you'll find for the classic macs is available in .sit or .bin or .hqx files. These are various archive files formats, like .zip or .tar.gz but for Macs. If you have System 7 or later, then StuffIt Expander/DropStuff 5.5 can deal with all of them.

The good news is that these know how to preserve the resource forks and make everything into one big data-only file. The bad news is that they are usually compressed, and decompressing on real machines, especially the old ones, can be pretty slow. Of course you have to open them only inside Mac OS; even if you do use tools to read them on other systems you still have to deal with not losing the resource fork, but you can work with them inside an emulator instead and not need to worry about slow old CPUs taking a long time to decompress them.

Floppy disks

If your Mac has a SuperDrive (also known as FDHD), like the later Mac SEs and newer, then you're in luck, because your mac can read standard 1.44MB 3.5" disks that everything can read. You should be able to use any old USB drive you have. These macs can also read PC formatted disks, so you can probably move files around natively.

The biggest problem is that if you need to recreate disks, most Mac disk images don't come in the raw format like most of PC images you might be used to, but they can be converted. Then you can use dd or ImageDisk or a GreaseWeazle with gw write --format ibm.1440.

But if you can get the image file onto the mac itself some other way, then you can mount the disk images directly in macos, using either Dick Copy 6 if System 7 or above, or Mountimage on older systems.

For the older Macs, they have a 800K drive, which uses 720K 3.5" disks (the kind with the right hole filled in). It gets away with this by using a variable speed spindle motor, which slows down the disk near the outside to fit more sectors into the larger arc. The format is apparently quite similar to the Apple II format, though the drives are not compatible. However, this means that almost nothing can read them except other macs.

One thing that can read and write 800K disks is FluxEngine. Instead of slowing down the disk, it just writes the outside section faster, since it can write raw flux transitions to the disk. With verification, I might add, but I have found that specific combinations of disks and PC drives work or don't work as the case may be; it is very picky. FluxEngine can use a GreaseWeazle as the hardware, so if you've got one of those, you're set.

800k/720K physical media is kind of rare these days. You might be able to get away with taping over the hole in a 1.44 Mb disk, but I wouldn't rely on that.

Here is some more detailed info about what can and can't read Mac disks.

Another option is to use a FloppyEmu which is a hardware device which emulates the physical drive, and is one of the few things that can do that for Apple II disk images.

broken gear

All mac floppy drives use a motorized eject mechanism instead of a button like PC drives do, presumably so you can't eject a disk early and screw it up. One of the gears in this mechanism has a tendency to decompose and break (one of those yellowing nylon deals). You can resin print a new one yourself or buy higher quality resin printed ones on Ebay. I've even heard that someone is making injection molded ones. There's too many variants to list here, just google "macintosh floppy disk gear" and you'll find it.

Oddly, all the other gears are plastic too but don't seem to decompose and are usually in great shape.

Mac Serial Ports

The Mac has 2 serial ports on the back, in a 9-pin mini-DIN socket. Though one has a phone and the other has a printer, they are both the same hardware and can be used interchangably.

What is different about them is that they use RS-422 voltage levels instead of RS-232, at least for transmit and receive. RS-232 signals with a voltage which is a minimum of 3V above or below GND, but RS-422 uses differential pairs. Two pairs are used, one for TXD and one for RXD; a pin for GND, a pin for Shield, and the 3 remaining pins for flow control, using unbalanced non-differential RS-232 style signaling.

So if you don't need flow control, the RS-485 can take you pretty far! (like around an office, to do LocalTalk networking). The serial ports also work up to 230 Kbps.

Despite what Wikipedia says (which is that the ports have selectable hardware between RS-232 and RS-422), the actual way you connect an RS-232 device to a mac is by referencing the mac +RXD pin to GND and connecting the RS-232 TXD and RXD to -TXD and -RXD on the mac. Since RS-232 uses negative voltages for signaling a logical 1 it's a quick hack that works. The pinout for that would look like this but a better description of the whole deal is here. Here's another summary, for good measure.

I was a little concerned that RS-422 is supposed to use a voltage range of -6V to +6V, but I checked the schematics and the SN75175 receiver IC in the SE/30 accepts +/-12V just fine. PC serial ports can output +/-12V, sourced from the 12V and -12V power supply rails, and USB serial ports, which usually use a MAX232 or similar, tend to output +/-7.5V. The RS-232 spec goes up to +/-15V, so you should still probably check the signal level with a scope first to make sure you don't blow anything out.

TinyTransfer

When researching some ways to transfer files onto the Mac using the serial port, I found a new project called TinyTransfer. Connect two Macs (or one Mac and Basilisk II using one of the hosts serial ports), run TinyTransfer on each, and transfer files with no guesswork, keeping the resource fork intact.

It's not really different than BinHex-ing a file first, then transferring it using Kermit and un BinHexing it, but it's self contained and you don't have to track down versions of these that work on your OS. It's supposed to work on older OS versions too.

The downside is that it's slow - using serial ports, the best speed you can get is about 115 kbps, not counting file compression.

And to state the obvious catch: you still have to find a way to transfer the TinyTransfer app onto the Mac in the first place, so you'll have to use one of these other methods, but at least it's only one file.

Virtual SCSI hard drives

This is my favorite option. If your Mac has SCSI (either the 50 pin IEC internal or the external DB25 on the back), there's a hardware emulator for you. You load virtual hard drive images onto an SD Card and use them like real hard drives on the system. The same virtual hard drive files work in the emulators, making them a great way to move files around if you don't mind moving an SD card every now and then.

These have a storied history. As best I can tell:

• SCSI2SD was first
• BlueSCSI (the original) made a cheaper clone of SCSI2SD
• ZuluSCSI also makes a SCSI2SD clone
• the COVID parts shortage hits. STM32 chips are out of stock everywhere. Raspberry Pi releases the Pi Pico and RP2040 chips, which are more available.
• ZuluSCSI ports the STM32 code to use an RP2040, makes the first RP2040 version.
• BlueSCSI forks ZuluSCSI's RP2040 code, makes 2040 hardware themselves as the BlueSCSI v2.
• Both of them update to the newer RP2305B

The ZuluSCSI and BlueSCSI maintain separate forks to this day, and are not hardware compatible (I tried it), but both are open source. BlueSCSI's hardware is a little more open source - you can make bare boards yourself if you want, and it seems to get a bit more code contributions.

I have 2 ZuluSCSI devices as their hardware seems to be a bit cheaper and I didn't feel like sourcing and soldering components this time. Mine are both based on the older RP2040, but both work fine.

• ZuluSCSI Pico Slim for the SE, on the external SCSI port. Uses a Pi Pico W, so it has WiFi
• ZuluSCSI Compact RP2040. I have a slightly older revsion, but I did make a clever 3D printed mount (Mount | Cover) to fit it into the SE/30's expansion bay on the back, to make easy access for the micro SD card.

These work to mount hard drive images and CDs (manual), and you do this by simply renaming the beginning of the filename:

• HD40_512_se30_system.hda is a hard drive on SCSI ID 4
• CD3_SYSTEM_7-5-3-RETAIL.iso is a CD on SCSI ID 3

Apparently they can boot CDs too, but neither of my Macs ever supported that.

If you want to not mount the disk but still keep the file on the SD, I usually just put an X in front:

• xCD3_SYSTEM_7-5-3-RETAIL.iso

SCSI has selection jumpers just like IDE's master and slave, or shugart floppy drive's DS0-DS3. In SCSI's case you select an ID from 0 to 6 (ID 7 is the controller).

Networking Explained (the Ethernet way)

In the days of the compact mac, it was before ethernet and TCP/IP. Apple had their own network interface (LocalTalk), own data layer (AppleTalk) and own protocols (Apple Filing Protocol (AFP) and some others). This originally ran off the Mac's built in RS-422 serial hardware, as LocalTalk (or PhoneNet, which was just LocalTalk run over the 2 unused wires in a 4 conductor phone cable). Later, they got AppleTalk to work over Ethernet (EtherTalk), and finally the AFP/other protocols were updated to run on TCP/IP like everything else.

The Asante ethernet card in my SE/30 is from that time where there was ethernet, but did not use TCP/IP yet for AFP; AppleTalk was still its own thing. So things are a bit strange. Mostly what this means is that your modern OS has to support talking AppleTalk over Ethernet, which many Linux distros still do as a kernel module (Debian 12 has it out of the box, but on Raspberry Pi's Raspbian, you have to recompile the kernel).

Why networking? Two reasons:

• use AFP to mount file shares and access them just like a normal drive
• explore old web browsers and websites and stuff

I have a genuine old Asante MacCon for my SE/30. You can still get them on ebay but they are pricy and only getting more expensive. Ethernet is only 10mbps, but that's pretty quick, plus, you can connect it to modern ethernet switches and stuff that you already use for the rest of your network.

But, someone is making new ethernet cards based on a new design! for the SE and SE/30 at least. I have heard good things about these but don't have one.

A SCSI emulator with a Pi Pico W can do an emulation of a Daynaport SCSI ethernet card (but over WiFi). BlueSCSI and ZuluSCSI can both do it. If you get anything for networking, it will probably be this.

The other way (LocalTalk bridges)

Another way people have approached this problem is to interface with the Mac's serial ports and use LocalTalk, like it would have been done back in the day. The main one I found is called TashRouter which uses a Raspberry Pi and some hardware to convert LocalTalk to other protocols, like LToUDP, which runs LocalTalk packets over UDP, which some emulators (MiniVMac) use (but not Basilisk). Another option is multitalk to convert between LToUDP and EtherTalk.

There's also several other projects which convert hardware LocalTalk to something else.

Supposedly, you can even run TCP/IP over LocalTalk.

Netatalk

Netatalk does for the Mac what Samba does for Windows file shares. It runs on Linux and is an AFP server. Macintosh clients can mount shared folders natively; the resource fork is handled correctly, even though the shared directory runs on a Linux filesystem (I think the resource part goes into hidden files).

For quite a long time, Netatalk-2.x was the only modern version that would work with Ethertalk and the classic Macs. But, in 2024 they merged the 2.x and the later branches so now Netatalk 4 works with them too! This is the version I picked. Don't forget to read the manual!

installing on Debian 12

I'm working on a "retro file sharing server" which runs a bunch of services so all my old machines can access it, things like FTP, Samba with the old protocols enabled, a simple web page with an upload button, etc. I grabbed the latest Debian (12.9) and installed it into a virtual machine.

Netatalk 4 is included in system repositories for some previous Debian versions, but not 12, so I had to compile from source. The latest version as of writing this is 4.1.2, and I mostly followed the compile from source on Debian instructions here.

Set a static IP. My Ethernet interface is called ens18. Ignore the sheep_bridge interface for now, we'll get back to it.

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug ens18
#iface ens18 inet dhcp
auto ens18
iface ens18 inet static
        address 192.168.1.230
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1

allow-hotplug sheep_bridge
iface sheep_bridge inet static
        address 192.168.84.1
        netmask 255.255.255.0

Install avahi-daemon (Zeroconf/Bonjour) since debian doesn't come with it. I don't think it's required for Netatalk, but it lets you talk to the server in tcp/ip stuff with hostname.local.

apt-get install avahi-daemon

Commands to install Netatalk 4.1.2 dependencies, download source, build, and install it:

apt-get update
apt-get install --assume-yes --no-install-recommends bison cmark-gfm cracklib-runtime docbook-xsl file flex libacl1-dev libavahi-client-dev libcrack2-dev libcups2-dev libdb-dev libdbus-1-dev libevent-dev libgcrypt20-dev libglib2.0-dev libkrb5-dev libldap2-dev libmariadb-dev libpam0g-dev libtalloc-dev libtirpc-dev libtracker-sparql-3.0-dev libwrap0-dev meson ninja-build quota systemtap-sdt-dev tcpd tracker tracker-miner-fs unicode-data xsltproc
wget https://github.com/Netatalk/netatalk/releases/download/netatalk-4-1-2/netatalk-4.1.2.tar.xz
xz -v -d netatalk-4.1.2.tar.xz
tar -xvf netatalk-4.1.2.tar
cd netatalk-4.1.2
meson setup build -Dbuildtype=release -Dwith-appletalk=true -Dwith-dbus-sysconf-path=/usr/share/dbus-1/system.d -Dwith-init-hooks=false -Dwith-init-style=debian-sysv,systemd -Dwith-pkgconfdir-path=/etc/netatalk -Dwith-tests=true
meson install -C build

Make a share folder to use:

mkdir /retro
chmod 777 
chmod 777 -R /retro
chown alnwlsn:alnwlsn /retro

Update the configuration files. In afp.conf, I'll set up my share folder and turn on appletalk.

/etc/netatalk/afp.conf

; Netatalk 4.x configuration file
;

[Global]
; Global server settings
appletalk = yes
uam list = uams_guest.so,uams_clrtxt.so,uams_dhx2.so
;[Homes]
;basedir regex = /home

; [My AFP Volume]
; path = /path/to/volume

; [My Time Machine Volume]
; path = /path/to/backup
; time machine = yes

[retro]
path = /retro

The AppleTalk config. I couldn't make much sense of this so these settings come from here and seem to work for me. We'll again ignore and comment out the sheep_bridge interface for now.

/etc/netatalk/atalkd.conf

# AppleTalk daemon configuration (netatalk 4.x)
#
# See the `atalkd.conf' manual page for examples.
ens18 -router -phase 2 -net 1 -addr 1.1 -zone "retro"
#sheep_bridge -router -phase 2 -net 2 -addr 2.1 -zone "retro"

Last is enabling the systemd services, which Netatalk comes with, but the instructions in this part are out of date. What you really need to do is:

systemctl enable netatalk.service
systemctl enable atalkd.service
reboot

...and it worked! I can mount the network share in Chooser on my SE/30!

Printers

I don't have any Mac printers, but with Netatalk you can get classic Macs to print on modern ones over the network, somehow. You'll need CUPS for this.

Install CUPS on the system with Netatalk with apt-get install cups

Add yourself to the admins so you can log in to the config interface sudo usermod -aG lpadmin alnwlsn

By default, the CUPS web interface is only available on localhost, so use an SSH tunnel to the server to access it on port 3631: ssh alnwlsn@192.168.1.230 -T -L 3631:localhost:631

Now you should be able to add a printer like normal. You probably will need to search up a PPD file (PostScript Printer Description) for your printer, and select it when you add it. It should show when you run lpstat -p. Make sure to name it something sensible.

Uncomment the cupsautoadd:op=root: line in /etc/netatalk/papd.conf and then you can do systemctl enable papd and reboot.

...and, it worked again! I can go in Chooser, select the LaserWriter, and all the CUPS printers show in there. I tried printing a couple of things and all seemed well.

Print to PDF printer

No printer? No problem. Install CUPS-PDF and get PDFs instead. This sort of works - on my SE/30 on 7.1 the pages are upside down and backwards, but in the emulator they come out correct. I changed some of the settings...

/etc/cups/cups-pdf.conf

Out /retro/cups-pdf
AnonDirName /retro/cups-pdf
AnonUMask 0000
UserUMask 0000
Grp lpadmin
DecodeHexStrings 1

I also had to disable AppArmor for this with sudo aa-complain cupsd because it blocks everything not in a home folder. This is starting to get out of scope but it sort of works. Amazingly the PDF files are still readable in Adobe Reader 3.01 on the SE/30, though very slow.

Basilisk II (the emulator)

An introduction to emulators: Guy complains about Classic Mac emulation | reddit post about that post

I found Basilisk II to be my emulator of choice, because:

• it works on Linux
• you can share a linux folder with the VM mac os inside and transfer files in and out
• it supports hardware - you can share a serial port. I used this with TinyTransfer to move some files to my SE.
• it supports networking. You can get on your AFP shares.
• it reads the same virtual hard drive files that the Blue/ZuluSCSI uses. Another way to transfer files.
• adjustable screen resolution - larger screen size like 1024x768. Your modern screen has plenty of pixels - use them!

Basilisk II is a 68k emulator. Closely related is SheepShaver which is a PowerPC emulator. They actually share a lot of the same codebase and features, so things that work on 1 will usually be similar on the other.

From here, my process is usually something like:

• find a .sit file somewhere and download it
• copy it into the shared folder, access it from inside Basilisk II
• if files are in an archive, decompress it in the emulator (much faster than having the old CPUs do it)
• put it into AFP share
• access AFP share from the real Mac, copy files onto local hard drive

I run System 7.5.3 as my emulator OS of choice, but you have to be careful about installing it. You can get 7.5.3 as an ISO but I needed a Disk Tools floppy from the 7.0.1 install set to boot a system since it won't boot from the ISO. That's a bit of a catch-22 because even disk images are usually distrubited in .sit files which you need a Mac to decompress, but if you look hard enough you can also find premade hard drive images instead.

If you are installing fresh, don't install the A/ROSE extension or any graphics acceleration extensions. You might end up with a system that won't boot. I also tried to install the 7.5.5 update and it wouldn't boot after that, so I'll stay on 7.5.3 for now.

7.5.3 comes with OpenTransport as the network stack, which worked, except that Netscape 2.02 would not load many pages. I found this to be pretty weird, but I switched over to MacTCP (using the Network Software Selector in Apple Extras) and suddenly Netscape worked like it should. Not sure if this is a Basilisk issue or because that version of Netscape doesn't like OpenTransport, but I figured I would mention it.

You'll also need a rom. Following some random issues with ethernet inside the emulator after using a Mac IIci rom, I found this post and changed to one called 1993-02 - F1ACAD13 - Quadra, Centris 610,650,800.ROM which is just a search away. After that, ethernet worked great!

The release process is a bit strange, but I used this fork of Basilisk II and compiled from source.

The main issue I have with it on my machine at least is that it does not like to close cleanly. Usually, the way you exit Basilisk II is by using Special -> Shut Down in the emulated Mac OS, the same way you shutdown a real mac. If you can't get to that menu, it will not close without a SIGKILL signal being sent to the process. Be aware that if you do this, it will likely corrupt your OS hard drive if not all virtual hard drives attached, so be sure to make a copy of them beforehand.

networking: slirp

Do you just need the internet? Maybe you just want to see a (http) website in netscape. Easy!

1. In BasiliskII config: Ports -> Ethernet interface -> slirp
2. boot the emulated machine
3. Contol Panels -> MacTCP (or TCP/IP if using OpenTransport)
4. Select Ethernet interface
5. IP Address: 10.0.2.15, then More
6. Subnet mask: 255.255.255.0
7. Gateway address: 10.0.2.2
8. DNS address: 10.0.2.3
9. reboot emulator

Open up netscape and it should now work, and you can look at websites. Other TCP/IP stuff should work too. The downside is, you are now behind a NAT, and AppleTalk will not work. That's kind of what I was going for, so I'll try something else.

networking: Ethernet

TCP/IP is easy, but you're running an emulator. So you should get frame level access to Ethernet, right? On basilisk II, you would do this if you want to use AppleTalk / AFP file sharing features. And the way you do this is by handing over a full ethernet interface to the emulator (on linux, you need to install a kernel module called sheep_net which BII comes with). I've run across the same thing before with Dosbox networking.

All good if you have an ethernet interface you're willing to surrender, but of particular note is that it will not work on WiFi. You can't just hand over the WiFi interface and pretend that it's an ethernet one. I'm sure there's some linux trickery which involves creating virtual interfaces, but I don't want to do that and risk messing up my main network interfaces.

One creative solutions I found with this: run the whole thing inside a VM. We're used to VM packages which provide an emulated Ethernet interface to the emulated machine, sharing the host's network. The idea here is to run linux in the VM and then BII on top of that. I'm sure it would work, but seems a little convoluted.

But you don't really need the whole ethernet interface, you just need to be able to send Ethernet frames around. You know what can do that? OpenVPN in TUN mode. A great idea to be sure, with the added benefit that if you set everything up correctly, you could use this when traveling, over the internet. Also not the path I took, as OpenVPN is a bit complicated to set everything up (I've done it before), especially when your networking knowledge outside of 192.168 is limited.

Installing sheep_bridge

Someone apparently had the same issue with SheepShaver/Basilisk II and surrendering an entire ethernet interface as that which led to the creation of LToUDP, so they grabbed a spare UDP port and wrote up a mode to tunnel Ethernet frames over it. In this technical manual it's just called special "tunneling" mode. It was originally intended only to help network multiple SheepShaver/Basilisk II instances together, but someone else wrote a Python program called sheep_bridge to bring it out to a real network using a TAP interface in Linux.

This is most similar to the VPN setup I talked about above, but without messing with the Basilisk II host's network interfaces.

I run it on the same VM I use for Netatalk. Sheep_bridge creates an extra network interface called sheep_bridge (which shows in ip a) and it's like having a second ethernet connection on a network with your Basilisk II Mac on it. You assign it an IP address on a different subnet, and enable internet sharing so the Mac can go in the internet using the VM's main internet connection. You also set up netatalk to talk on the sheep_bridge interface too so file shaing works.

It very nearly worked out of the box, but Basilisk II uses its host's IP address to come up with the MAC address for the virtual ethernet interface it makes. This should be your main interfaces' address (WiFi or Ethernet), but Basilisk II gets the host's IP address from /etc/hosts using the hostname, which is 127.0.1.1 on all my machines. So you can just go in there and change it to your actual IP address, like 192.168.1.100. Otherwise, sheep_bridge won't know which IP address to send retruning UDP packets to.

The sheep_bridge github page has a pretty good description of what to do to get it running manually, which you'll probably want to do to make sure everything is working. After that, I set it up as a service on the Netatalk VM.

inside Mac OS VM

1. Contol Panels -> MacTCP (or TCP/IP if using OpenTransport)
2. Select Ethernet interface
3. IP Address: 192.168.84.232 (or to taste), then More
4. Subnet mask: 255.255.255.0
5. Gateway address: 192.168.84.1
6. DNS address: 192.168.1.1 (or your favorite DNS server)

Also, change your AppleTalk connection from LocalTalk over to EtherTalk; reboot, and select your share in Chooser (only after you have got Netatalk/atalkd running on the sheep_bridge interface)

as a service

git clone https://github.com/VinDuv/sheep-bridge
cd sheep-bridge
cp sheep-bridge.defaults /etc/default/sheep-bridge
cp sheep-bridge.service /etc/systemd/system/sheep-bridge.service
cp sheep_bridge.py /usr/local/sbin/sheep_bridge.py

Edit the configuration file:

/etc/default/sheep-bridge

# /etc/default/sheep-bridge: Configuration variables for sheep-bridge

# Network address to listen on; must be a local IP address that this machine
# has, followed by a slash and a network mask.
# Ex: 192.168.1.25/24
# Note that if that address is incorrect, sheep-bridge will start up anyway
# but the virtual interface will not be functional.
NET_ADDR="192.168.1.230/24"

# Network port used by the SheepShaver/Basilisk II emulators on the network to
# communicate.
PORT=6066

Edit the network config to auto-add an IP address to the sheep_bridge network interface (I already did this edit in the netatalk setup above).

/etc/network/interfaces

allow-hotplug sheep_bridge
iface sheep_bridge inet static
        address 192.168.84.1
        netmask 255.255.255.0

and add this line to the atalkd config so it will use that interface also:

/etc/netatalk/atalkd.conf

sheep_bridge -router -phase 2 -net 2 -addr 2.1 -zone "retro"

Next, get internet access to work:

add net.ipv4.ip_forward=1 for /etc/sysctl.conf

run iptables -t nat -A POSTROUTING -j MASQUERADE

Get iptables to stick with iptables-persistent:

run sudo apt-get install -y iptables-persistent

It should offer to save the current settings during setup. If it's already installed or you need to make changes later, run the iptables commands you want and then do sudo dpkg-reconfigure iptables-persistent to run the setup again.

Make the changes below to the systemd service files so that things start up in the right order.

Finally, run systemctl enable sheep-bridge and reboot.

Fixing sheep-bridge startup

The readme for sheep-bridge says that if you setup the systemd service that it comes with, it's supposed to start up before the network starts. After the network starts, conceivably the ip address gets assigned to the sheep_bridge interface, and then sheep-bridge can get on with it.

Not in my case. Sometimes the system would start up correctly, but sometimes it doesn't, and I check systemctl status sheep-bridge only to see:

● sheep-bridge.service - Sheep Bridge virtual interface
     Loaded: loaded (/etc/systemd/system/sheep-bridge.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-03-08 17:29:51 EST; 22s ago
   Main PID: 316 (sheep_bridge.py)
     Status: "Waiting for host IP configuration"
      Tasks: 1 (limit: 2312)
     Memory: 24.3M
        CPU: 108ms
     CGroup: /system.slice/sheep-bridge.service
             └─316 /usr/bin/python3 -u /usr/local/sbin/sheep_bridge.py 192.168.1.230/24 6066

It's stuck waiting for the interface to get an IP, which should already be there. But when I do systemctl restart sheep-bridge, it always goes right to...

● sheep-bridge.service - Sheep Bridge virtual interface
     Loaded: loaded (/etc/systemd/system/sheep-bridge.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-03-08 17:37:54 EST; 22s ago
   Main PID: 452 (sheep_bridge.py)
     Status: "Ready"
      Tasks: 1 (limit: 2312)
     Memory: 22.1M
        CPU: 114ms
     CGroup: /system.slice/sheep-bridge.service
             └─452 /usr/bin/python3 -u /usr/local/sbin/sheep_bridge.py 192.168.1.230/24 6066

..."Ready". But then I also need to restart atalkd and netatalk and papd.

Let's rethink this. If sheep-bridge always works after the networking starts, lets change the systemd service file to make it wait until after that happens rather than before.

/etc/systemd/system/sheep-bridge.service

[Unit]
Description=Sheep Bridge virtual interface
#Before=network-pre.target
#Wants=network-pre.target
After=network-online.target

[Service]
EnvironmentFile=/etc/default/sheep-bridge
ExecStart=/usr/local/sbin/sheep_bridge.py "$NET_ADDR" "$PORT"
#StandardOutput=null
Type=notify

[Install]
WantedBy=multi-user.target

Now, I'll need to make the netatalk stuff wait for sheep-bridge to be ready, because sheep-bridge is responsible for setting up the sheep_bridge interface. It all depends on atalkd - that has to start first. I'll add a one liner ExecStartPre to make it wait until the sheep-bridge service changes its Status to "Ready" before it continues. Not sure if it makes a difference, but I added sheep-bridge.service to After as well (ChatGPT told me to do it).

/lib/systemd/system/atalkd.service

# This file is part of Netatalk 4.1.2.

[Unit]
Description=Netatalk AppleTalk daemon
Documentation=man:atalkd(8) man:atalkd.conf(5) man:nbp(1)
Documentation=https://netatalk.io/
After=network-online.target sheep-bridge.service

[Service]
Type=forking
GuessMainPID=no
ExecStartPre=/bin/sh -c 'while ! systemctl status sheep-bridge | grep -q "Ready"; do sleep 2; done'
ExecStartPre=/bin/sh -c 'systemctl set-environment ATALK_NAME=$$(hostname|cut -d. -f1)'
ExecStart=/usr/local/sbin/atalkd
ExecStartPost=-/usr/local/bin/nbprgstr -p 4 "${ATALK_NAME}:Workstation"
ExecStartPost=-/usr/local/bin/nbprgstr -p 4 "${ATALK_NAME}:netatalk"
PIDFile=/var/lock/atalkd
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target

Now, whenever I reboot the server, it starts up in the right order and works every time.

spare links

• the Classic Mac networking Guide
• another rambly journey which takes a lot of the same steps here, but over LocalTalk
• https://bluescsi.com/docs/WiFi-DaynaPORT
• https://jcs.org/2023/08/23/scsiwifi#ethertalk