GlobalTalk Technical Note 2024.01: Network Numbering

OK, so the title of this post might seem a bit presumptuous, but stay with me, there’s good reason for it…

As previously discussed, GlobalTalk is an international conglomeration of AppleTalk networks tied together using the Apple Internet Router software from 1993.

Humble beginnings have blown out to a wild success for this aspect of #MARCHintosh 2024, and I know at least some admins (including myself) are planning on leaving their nodes online beyond 31 March, and others are planning to spin theirs back up for 2025 – but I also hope we see additions before and during next year’s event.

To date, technical information supporting optimal configuration has been rather sparse, mostly worked out on the fly, and supported by Paul Rickards, dan and Mac84 through initial successful experimentation, original setup instructions, and moderation of the spreadsheet used to coordinate network/zone names and numbers, for example.

I believe an assumption was made that a selection of a Network Number range spanning 10 “addresses” was seen as adequately servicing the number of devices individual GlobalTalk Admins might want to connect, but I think this is based on a false assumption of what the Network Numbers accommodate/represent.

So, what should we do? Well, as always, we should…

RTFM

As I’ve settled into GlobalTalk, seen messages in my Router Log, discussions on Mastodon, and Comments in the coordinating spreadsheet, I realised it would be ideal if I and my fellow GlobalTalk admins could benefit from reading the Apple Internet Router 3.0 Manual…it that were at all possible.

I mean, ideally, don’t we all like to obey the Fourth Golden Rule of Computing – RTFM?

However, this is getting harder and harder these days – for older hardware and software, the manuals might be nigh on impossible to get a hold of, and for modern hardware and software, you might have to be satisfied with a Regulatory Compliance note and a sticker…if you’re lucky!

So far, for the Apple Internet Router v3.0 software being used for the majority of GlobalTalk nodes, all I have found online is the plain text of the primary chapters of the Apple Internet Router Manual (no appendices).

It’s a little hard to pick out sections, chapters, and headings, but it is absolutely better than nothing.

As a side note, I’ve seen such plain text PDFs of Apple manuals before – I’m not sure if these plain text files have somehow leaked from Apple or their design houses, or if it’s just the output of OCRing the originals (which I would expect said originals to be available, but they often aren’t). I generally settle on the former due to the lack of scanned originals suggested by the latter.

While incomplete to provide full technical details (I want Appendix A!), it has still brought me fuller understanding of how network numbers and ranges operate, which informs the recommendations I make below.

Should these recommendations be accepted by the GlobalTalk Admin community, I believe it will allow for any future potential growth of the network, optimise the Admin experience, improve flexibility on the network, and minimise (if not eliminate) network number conflicts (a small, but persistent issue on GlobalTalk to date).

News just in: in a timely change of fortunes, I have discovered while writing these very RTFM paragraphs that I have secured the original, full, Apple Internet Router 3.0.1 package on eBay, including ring-bound manual. Huzzah!

Once scanned (and uploaded to The Internet Archive), I’ll be donating the full package to the Australian Computer Museum (of which I am a volunteer sysadmin), which will be joining GlobalTalk as soon as I can get the time to get their configuration together.

Unfortunately, the package won’t arrive before the end of 2024, but the plain text has enough information to inform my proposals below regarding Network Numbering to the wider GlobalTalk Admin community.

What the Manual Says…
Identifying networks on an internet

Networks connected by the router retain separate identities. Each AppleTalk network in an internet must have a unique network number or network range.

- A single network number identifies a LocalTalk network.

- A network range is a series of contiguous network numbers that identifies any other type of AppleTalk network, such as an EtherTalk or TokenTalk network. A network range can neither include a network number already assigned to another network nor overlap another network range.

Each network in an internet can include a maximum of 253 devices. You can assign up to 253 devices to each network number in a network range. Thus, a network range determines the maximum number of devices on a network. For example, a network having the network range 1-10 could include up to 2,530 devices (10 × 253).

If you designated the EtherTalk or TokenTalk port as a seed port, type the lowest network number in the network range for the network connected to that port in the Network Range text box and the highest network number in the network range in the "to" text box.

IMPORTANT A network range must be unique in an internet. It can neither include a network number already assigned to another network nor overlap another network range.

A network range must consist of a series of contiguous network numbers. You can specify a network range as two decimal numbers between 1 and 65,279, or two hexadecimal numbers between $1 and $FEFF. In Router Manager, a $ character must precede hexadecimal numbers. If you don't expect a network to grow beyond 253 devices, you can assign a single network number to a range – for example, you can specify a network range from 14 to 14.
How I Interpret this…

In the above, “internet” means the internetwork of AppleTalk networks being routed/bridged between all the GlobalTalk nodes (a “node” I define as a distinct Apple Internet Router-running Mac [or equivalent-functionality device or software from other companies] which allows joining of local networks to the GlobalTalk “internet”).

Additionally, “network” means the devices sharing a distinctive networking infrastructure, where those devices are directly able to see each other without any intermediaries such as bridges, routers, etc.

Network Numbers are valid within the range of 1 to 65,279, capping the potential number of networks connectable to GlobalTalk at that higher number.

For AppleTalk networks (whether LocalTalk, EtherTalk or TokenTalk), at most 253 devices can be on any single Network Number.

LocalTalk networks can only have one Network Number (which, once again, must be unique on the GlobalTalk internet), and EtherTalk (the most common network type on GlobalTalk) can have a range of unique Network Number/s, but that range may represent a single value (the “14 to 14” example above).

A Mac running AIR may have multiple LocalTalk networks (through printer and modem ports, or perhaps expansion cards), and multiple EtherTalk networks (through a combination of built-in Ethernet port/s and/or expansion cards). The number of networks an individual Mac running AIR can route for is limited to 32 networks, however (so 32 × 253 devices – 8,096 – devices maximum routed devices per GlobalTalk node).

Given any given Network Number must be uniquely assigned within each such “internet”, and each numbered network can have up to 253 devices within it, a single Network Number per network type (LocalTalk or EtherTalk) should be adequate for most, if not all, GlobalTalk nodes/networks. Many GlobalTalk nodes will not even need the second Network Number for a LocalTalk network (mine doesn’t [currently]).

The occurrence of a duplicate Network Number between individual LocalTalk networks or within EtherTalk Network Number Ranges anywhere across the GlobalTalk internet will cause the “Remote Net Range Conflict” errors we have been seeing in our AIR Router Logs, which prevents the second network attempting to use that Network Number from being visible until the conflict is resolved (which may be out of their hands and reliant on conflicting node’s Admin).

What I Propose be Adopted by the GlobalTalk Admin Community…

My feeling is we have an opportunity to lay some ground rules which will improve GlobalTalk administration moving forward, and the sooner we do so, the better.

And so, I propose:

  • Each GlobalTalk node be initially allowed up to two Network Numbers by default – one for their primary EtherTalk network, and another, if needed, for their LocalTalk network. Currently these are assigned on a first-come (i.e. first-requested), first served basis, and I see no reason to change this self-allocation.
  • Additional Network Numbers for additional network types (multiple physical LocalTalk or EtherTalk networks, or TokenTalk networks, connected to the Mac running Apple Internet Router) need to be requested after successful connection as a “base” GlobalTalk node (one EtherTalk network and, optionally, one LocalTalk network).
  • GlobalTalk Admins agree to request/reserve/assign a single number “range” to their EtherTalk network unless otherwise approved.

Assuming 1-2 Network Numbers per GlobalTalk node, we can accommodate somewhere between 32,639 and 65,279 GlobalTalk nodes on the GlobalTalk internet.

With up to 65,279 unique Network Numbers of up to 253 devices each, we can accommodate up to 16,515,587 individual network devices across the GlobalTalk internet.

I doubt we will run out, even with additional Network Numbers allowed when occasionally needed.

Conclusion

GlobalTalk is already a co-operative in the sense that anyone with access to the coordinating spreadsheet needs to co-operate with other GlobalTalk Admins to optimise everyone’s experience.

While things don’t necessarily have to change based on current usage, I think the above suggestions are worthwhile implementing for the long term benefit of all current and future GlobalTalk Admins.

Additionally, Network Number choice for individual Admins is increased with the recommended limitations – which, I feel, are not really limitations at all, given the device allowances per Network Number, and what I think are reasonable assumptions on the usage needs of any given GlobalTalk Admin/node.

I hope my fellow GlobalTalk admins embrace these suggestions, and I look forward to a very long life for this spontaneously ignited community of retro-Mac enthusiasts.

PS. Support

If you would like to support the preservation of the AIR original package and its donation to the Australian Computer Museum, please reach out to me via the contact page. Supporting the purchase of this software will provide an important resource to the global Mac retrocomputing community, and any excess funds will aid the ACM’s critical mission to preserve Australian computing heritage.

All donors will be acknowledged in the donation form to the ACM, and no moneys will be retained by me.

Thank you.

New server, new look…new headaches!

Save some money, I thought.

Have some fun, I thought.

I’ll set up a free Oracle Cloud Infrastructure (OCI) instance and host this blog there, and, while I’m at it, I’ll set up another instance and post to the Applesauce Fluxes Twitter image bot account from that instance, I thought.

Easy-peasy, I thought.

Well…no, I discovered.

I know if I laid out what I did I’d be here longer than it took to set up(!), and, while I understand video guides can be really annoying, it actually makes sense for me to just post this handy video representation of what happened next:

Yes, this is really what happened 😞

In the end, I went through probably eight OCI instances, four WordPress setups/migrations, two nervous breakdowns, and one case of wine (only three of those facts are true, no matter how you swap the numbers).

I’m happy to discuss at length what I did/learnt throughout this process in direct messages or e-mail (or via a Zoom if [and I {very much} doubt it] there’s enough interest), but I won’t inflict every step I took on anyone who’s paying me the respect of reading this blog – I have too much respect for you.

However, I will offer some takeaways:

  • Nothing, and I mean nothing, is easy – OK, the decision to go down this path is way too easy, but after that, a big fat nope!
  • OCI works well and is performant enough for the tasks at hand – I would definitely recommend it for technically-savvy self-hosters;
  • Don’t bother if (often) being elbow deep in a Linux CLI scares you;
  • SSH key-based login is your friend;
  • Webmin is your friend;
  • OCI Boot Volume Backups are your friend;
  • Don’t expect to get it right the first (or second [or third {or…}]) time;
  • Unicode characters in WordPress posts don’t migrate via the Duplicator plugin I used (or its MySQL code is unable to cope with them);
  • twitterImgBot has bugs (and extraneous code for most uses) – but it’s generally clear enough to work through the code;
  • Custom Permalinks vs Virtual Hosts…OMFG, WHY?!;

Why did I inflict all this on myself (other than being a techno-masochist [of the geek {not perverted} kind])?

Well, I’d been forced to migrate my G Suite legacy free edition mail hosting services, and I chose to migrate them to iCloud+, so I was out AU$10/month more for the additional iCloud+ subscription…but I was saving about AU$2/month not needing extra Google Drive storage (I have a lot of archival e-mail)…and I would have been paying about AU$6/month for my hosting next year so I thought I could eliminate that and almost break even compared to my current setup…and I had unexpected free time (due to some dodgy employment shenanigans [not on my part])…and I’d done all this before at one time or another so it was going to be smoooooth.

NARRATOR: It was notsmoooooth”.

But I’m here now, I think I’ve squashed all the WordPress issues (Permalinks work, Unicode characters updated, incompatible table-generator replaced), I have the Applesauce Fluxes Twitter image bot humming on the same OCI instance (after a few glitches, some also Unicode-related, some bug-related) and I’ve even decided to update from the old Twenty Eleven WordPress theme to something much more modern – Twenty Sixteen!

Yes, I’m a techno-masochist luddite – put it on my gravestone.

Apple ][/][+ Motherboard Test Sheets v1.2

Not long after WOzFest 18 I released some test sheets for Apple ][ and ][+ motherboards, to help tracking the testing of components on a motherboard, with separate sheets for the major motherboard revisions from Rev0 to RFI.

I silently updated them to v1.1 after correcting a weird default in my layout program that saw much of what was supposed to be solid black set to a very dark grey. No actual content changed, so I didn’t make a hullabaloo about that minor revision.

Today, however, I’m proud to release v1.2 of all the sheets, with improved content and some rewording I think makes things a bit clearer. In the background, I’ve also re-organised the underlying Affinity Publisher file to make changing common components between motherboard revisions easier.

Importantly, I’ve also included a second page with more space for notes and a representation of the keyboard so you can quickly record which keys work and which don’t.

I appreciate the feedback I received from Mark and Ross here in Australia, which helped me to either include extra info or clarify existing info.

Using the sheets on a couple of my machines also helped, and drove me to prepare the keyboard representation as well.

Mark also pointed out that printing onto A3 (i.e. at about 140%) makes the board layout roughly life-size – he placed this enlarged printout over some anti-static foam and pushed the chip pins through the printout into the foam while cleaning the board – a great way to store chips while cleaning or working on a bare board!

So, give the below a squiz and let me know if there’s anything else I need to do – or just use them as you check your Apple ][s.

Retrochallenge meets WOzFest – Check Your Caps!

Retrochallenge 2017/04 is almost over!

WOzFest PR#6 has now started!

It’s time for the two parts of my retrocomputing life to collide in the most resourceful of ways…

My “europlus Refurbapalooza”, whereby I’m trying to get all my europluses operational, has been the thrust of my two Retrochallenge entries in 2016/10 and 2017/04. With the vagaries of “real life” impinging more the second time around (just that time of year, I think), I’ve gotten even less done this month…but that doesn’t mean I’ve been entirely unproductive.

I’ve been able to test the electrolytic capacitors in all seven of my europlus Astec AA11040C power supply units (PSUs). Despite 14 electrolytic capacitors per PSU (so 98 total) and the PSUs being at least 35 years old, I was pleased to find only four capacitors are exceeding (or almost exceeding) their maximum ESR (Electrical Series Resistance) value.

I’m also going to follow the general guideline to replace the C1 filter capacitor, even if the original hasn’t blown (two of the seven originals have definitely blown, and a further three or four are showing cracking in their plastic covering). I’ve bought all the replacement capacitors I need, and hope to install them all and test the PSUs during WOzFest PR#6.

While carrying out these ESR tests, I wanted a ready-reference to the capacitor specifications for determining the correct ESR value to be testing and for when I came to purchase replacement capacitors.

As a non-expert, I also wanted a reference to the position and polarity of the solder points for each capacitor on the underside of the PSU circuit board – I was testing the capacitors “in-circuit” rather than removing them for testing (while not ideal, I’m trying to keep the task manageable).

I had found online a scan of a 1982 document from Apple which provided a great start to what I wanted. It has schematics and circuit board layouts for several Apple PSUs, as well as a components list for each of the PSU models it includes.

Although it has info on the AA11040B (while I have AA11040Cs), upon inspection I believe the primary difference is the AA11040C is the 230V version of the AA11040B with the “115V Select” wire removed and a 250V/2A fuse replacing the 125V/2.75A fuse.

So I decided to prepare just the sort of ready-reference I would have liked to have started with. Over several iterations to refine the design and info included, and taking input from enthusiasts with more PSU repair experience than me, (thanks Mark, Martin, Jon, Geoff and John!), I’ve created the “WOzFest Labs Apple Astec Power Supply Unit AA11040B/C Electrolytic Capacitor ‘Spec & Check’ Sheet” (it just rolls of the tongue!) – and I’m pleased to announce the release of v1.0 of this “Spec & Check” sheet for use by other enthusiasts looking to test and refurbish their AA11040B/C PSUs.

This release is the major result of my Retrochallenge 2017/04 entry and in line with WOzFest PR#6’s theme of “Preservation”.

I’ve designed the sheet so that it can be printed at 100% on A4 (297✕210mm) or US Letter (8.5″✕11″) without any information being cropped. When printed at 100%, the picture of the underside of the PSU circuit board is “life size”, so it’s easy to correlate the highlighted solder points to a physical circuit board.

The sheet can be used as a checklist of capacitors that are in or out of spec, has the maximum ESR values listed for each capacitor (as well as other specs) in both tabular and “call out” forms, and the polarity of the solder points are annotated and colour-coded.

This is only v1.0, and suggestions/corrections from other enthusiasts will be included in updates. If I’m able, I’ll also release versions for other PSU models that Apple used in Apple ][s.

This is the first resource issued under the name “WOzFest Labs”, and hopefully there’ll be many more (I’ll probably re-release my Silentype Font under that name, too). I’d be interested in collaborating on other resources, too, so hit me up if you have any ideas you”d like to work on with me.

A few notes:

  • I’ve provided specs and solder points for the C1 filter cap to ease replacement of this component along with any out-of-spec electrolytic capacitors;
  • Capacitors C13 and C14 are in parallel on the circuit, so testing either one to half the usual maximum ESR is adequate when testing them “in-circuit” – if capacitors are removed for testing, double the stated maximum ESR value for these two capacitors;
  • Capacitors rated to 105°C are recommended;
  • The 1982 document from Apple has at least two errors in the components list for the AA11040B PSU, so check its information carefully if you’re using it as a reference.
  • If you’re wondering about the typewriter-like font I used, it’s Prestige Elite, which, by my reckoning, is the font used in early Apple spiral-bound manuals such as The Applesoft Tutorial. It’s my theory that these early manuals were “typeset” using material printed by the ubiquitous IBM Selectric typewriter.

So, other than some soldering, testing and writing a recap on my re-capping adventures, that’s pretty well it for my Retrochallenge entry this time around. I’m looking forward to getting to the meat of my europlus refurbishment – testing (and hopefully repairing) motherboards – next go ’round in October!

Disk ][ refurbishment

One of the things that came out of WOzFest /// for me was that most, if not all, of my Disk ][s were no longer operational.

Given my desire to recreate the original Apple ][ setup we had when I was a teenager, operational Disk ][s are a must. Despite my infatuation with modern solid state storage solutions for retrocomputers, there’s just nothing quite like closing that door and hearing the mechanical symphony of a Disk ][.

So, in preparation for WOzFest $04, I decided to give my five Disk ][s a bit of TLC and try and get them all working (Figure 1).

Step one is to crack them open with a view to cleaning the read/write heads and possibly lubricating the rails. Luckily, they’re pretty simple devices to get into – four screws on the underside (Figure 2) and the upper case slides off the drive mechanism, showing the bare drive mechanism and the analog card that drives it (Figure 3).

To get to the read/write head, another two screws holding the analog card need to be removed and the card can be slid out of two slotted guides towards the rear of the drive (near the “D”s at the rear corners of the analog card). The analog card has two cable connections – for quick and simple work, only the one closest to the front of the drive (with a molex connector) needs to be disconnected to allow the analog card to be flipped upside down over the rear of the drive (Figure 4). This cable’s connector is “keyed” with a missing hole for the missing pin on the header to aid alignment and orientation.

Some Disk ][s have a plate covering the read-write head – this is simply clipped into place and easy to remove (Figure 5). You can then (gently) raise the sprung component (not too high!) of the drive head (which holds the disk against the read/write head) to clean the actual read/write head itself (Figure 6).

I’m leaving the outer covers off and the analog card unsecured in the drives I’m going to be using for disk imaging – this allows easy access to the drive head for cleaning. It’s amazing how quickly gunk builds up on the read/write head. I’m using isopropyl alcohol and cotton tips to clean the heads.

I had to lubricate the rails the head mechanism travels along in one drive – I used white lithium lubricant applied liberally with a cotton tip, then wiped off the visible excess with a paper towel after moving the head mechanism up and down the rails a few times.

Unfortunately, while working on my drives, I connected one to the interface card in the Apple ][ incorrectly – while I had it properly aligned along the length of the connector, I only plugged it into the outer row of pins, rather than to both rows (Figure 7). Snap, crackle, pop! I’d burnt out something on the drive’s analog card.

I was pretty sure the next drive I connected to the Disk ][ interface card I was using was connected correctly, but it also popped and was no longer working. I wondered if maybe something on the interface card had blown as well?

Visually, I could tell that the 74LS125 logic chips on the Disk ][ analog cards had blown (Figure 3 and Figure 8). By this point I had some confirmed working drives, so I swapped in a 74LS125 from a working drive’s analog card – the drives still didn’t work (I was using a different interface card in case the one I’d been using was also now a dud).

At this point I swapped a known good analog card into both drives in turn just to make sure that’s where the problem was and both drives worked, so I went back to swapping other chips from a known good analog card. Luckily, there aren’t many chips and I quickly determined both analog cards’ MC3470 chips were also faulty, even though there was no visible damage.

I was able to buy 74LS125s from my local Jaycar electronics store (for AU$1.75 each), and I bought replacement MC3470s from eBay (for about AU$2.50 each including delivery) – I bought enough of both chips to test a repaired drive with the suspect interface card. If the drive blew again I would be able to replace those two chips again.

As it turns out, that interface card didn’t blow up a repaired analog card, so I think it’s OK and I must have connected the second drive incorrectly as well. I vow: never again!

So, after all that, I now have five operational Disk ][s, and a bit more experience and confidence in doing my own retro repairs (which bodes well for my Retrochallenge entry).

Feel free to share your own Disk ][ damage and repair stories in the Comments section.