Connecting a Macintosh SE to the Internet with a Raspberry Pi(metalbabble.wordpress.com)
metalbabble.wordpress.com
Connecting a Macintosh SE to the Internet with a Raspberry Pi
https://metalbabble.wordpress.com/2020/02/08/the-final-frontier-connecting-a-macintosh-se-to-the-internet-with-a-raspberry-pi/
47 comments
If the local mac web browser supports proxy server, you can set up a https bypassing proxy on your RPi and browse modern websites (to an extent since web is a pile of JS now) from that mac.
Or, better, this:
https://github.com/tenox7/wrp
The rendering/handling of JS is done on the RasPi, so almost everything should work
The rendering/handling of JS is done on the RasPi, so almost everything should work
That is brilliant. And you can even run it remotely (e.g. on a VM somewhere) and have your old vintage machine connect to it.
> a https bypassing proxy
Any particular recommendations? I have a similar need.
Any particular recommendations? I have a similar need.
mitmproxy with the sslstrip.py script.
You know you can just connect a Mac SE to the Internet with an Ethernet card, right? This seems needlessly complicated.
> You know you can just connect a Mac SE to the Internet with an Ethernet card, right?
I think the author knows, since it is mentioned early in the article, twice. But the availability for SCSI Ethernet cards with Mac drivers is not what it used to be...
I think the author knows, since it is mentioned early in the article, twice. But the availability for SCSI Ethernet cards with Mac drivers is not what it used to be...
They are not easy to come by. Often it’s the coax kind of ethernet as well. I have done a simular setup to get a shell on my modern mac via kermit over serial cable.
It's literally the third paragraph of the article - did you read it before commenting?
He didn't have one, but he did have a Pi.
He didn't have one, but he did have a Pi.
No, I didn't, I simply dismissed this as yet another person using a RPi when an Arduino would do, or using an Arduino when a 555 would do, or...
There are a few considerations here:
- The Raspberry Pi is one of the better technical solutions. It is relatively low cost, low power, and is fairly representative of how the Macintosh SE would get on ethernet networks back in the day. (In many cases a more powerful computer would serve as a bridge between LocalTalk and ethernet networks.)
- Ethernet cards for the SE are rather uncommon since most SE's used LocalTalk for file and printer sharing. PDS cards were more-or-less specific to a model of Macintosh, so the option of sticking in a card intended for later models is not an option. SCSI-to-ethernet bridges are only an option if you find one with the drivers, since the drivers are virtually impossible to find after the fact.
I will admit to being a bit disappointed by this article. I was hoping for something more along the lines of interfacing an SE to the Raspberry Pi's internal UART since that would take a bit more skill, though not an absurd amount of skill. On the other hand, it is a demonstration of getting an archaic SE online is more about creativity than ingenuity. That's important for many of the people who pursue vintage computers as a hobby since they don't necessarily have the electronics background to design anything more sophisticated.
- The Raspberry Pi is one of the better technical solutions. It is relatively low cost, low power, and is fairly representative of how the Macintosh SE would get on ethernet networks back in the day. (In many cases a more powerful computer would serve as a bridge between LocalTalk and ethernet networks.)
- Ethernet cards for the SE are rather uncommon since most SE's used LocalTalk for file and printer sharing. PDS cards were more-or-less specific to a model of Macintosh, so the option of sticking in a card intended for later models is not an option. SCSI-to-ethernet bridges are only an option if you find one with the drivers, since the drivers are virtually impossible to find after the fact.
I will admit to being a bit disappointed by this article. I was hoping for something more along the lines of interfacing an SE to the Raspberry Pi's internal UART since that would take a bit more skill, though not an absurd amount of skill. On the other hand, it is a demonstration of getting an archaic SE online is more about creativity than ingenuity. That's important for many of the people who pursue vintage computers as a hobby since they don't necessarily have the electronics background to design anything more sophisticated.
Another option would be a Ethernet-Localtalk bridge box (which were commonly used for Apple printers). These used to be dirt cheap on ebay, but I guess people are into this stuff and they're now over $100.
Thank you for the correction.
I just saw a video by a vintage computer collector who had one of those Ethernet-Localtalk bridges, then realized I used to own one!
I just saw a video by a vintage computer collector who had one of those Ethernet-Localtalk bridges, then realized I used to own one!
In the past I would swing by some retro Mac discussion and say "hey! you're trying to network that classic mac? just buy this bridge for $25 on ebay!" But they're not so cheap anymore so I guess make your own if you want.
> or using an Arduino when a 555 would do, or...
This is becoming a horrific meme. You didn't read the article, made an assumption and reverted to this cliché
This is becoming a horrific meme. You didn't read the article, made an assumption and reverted to this cliché
That IP address configuration screen in the MacOS of yesteryear was amazing, wow. The slider to select the number of host/network bits is slick. I wonder why we don’t have something like that today.
> I wonder why we don’t have something like that today.
Because CIDR happened. The net/subnet/node nomenclature used by MacTCP is a relic of classful routing.
Because CIDR happened. The net/subnet/node nomenclature used by MacTCP is a relic of classful routing.
Just because CIDR happened doesn't mean that the subnet selection isn't relevant anymore.
However, classful subnet selection is not longer relevant today (A, B, C...) The Mac UI limited you to those three classful subnet masks.
Today, it's much simpler to type /26 after your IP address instead of entering 255.255.255.192, or playing around with a non-standard host/network slider.
Today, it's much simpler to type /26 after your IP address instead of entering 255.255.255.192, or playing around with a non-standard host/network slider.
> The Mac UI limited you to those three classful subnet masks.
And it assumed a specific network architecture -- e.g, if you have a class A network, the middle two octets of your address represent a "subnet" and the last octet represents a "node". This may have been appropriate in pre-CIDR networks where all local nets were /24, but it's no longer true today; it's not uncommon to have networks which split on non-octet boundaries.
And it assumed a specific network architecture -- e.g, if you have a class A network, the middle two octets of your address represent a "subnet" and the last octet represents a "node". This may have been appropriate in pre-CIDR networks where all local nets were /24, but it's no longer true today; it's not uncommon to have networks which split on non-octet boundaries.
That UI only made sense if you already understood:
- That there were 4 octets in an IP address.
- Class-based IP addressing.
- Subnet bit masks.
The UI that replaced it was an improvement in that all it asked for was a series of numbers, separated by dots, constrained to 0-255.
- That there were 4 octets in an IP address.
- Class-based IP addressing.
- Subnet bit masks.
The UI that replaced it was an improvement in that all it asked for was a series of numbers, separated by dots, constrained to 0-255.
This is interesting as I’m trying to connect a Macintosh SE/30 that I recently brought back to life, without having to shell out crazy money for a network card on eBay. I wonder whether this TCP/IP over PPP solution also works under A/UX, which is what I want to run.
Could the SE/30 run A/UX?! Wow!
Yes, it's the only compact Macintosh that does.
Oh, how I wish I still had my SE/30. Looking back through rose-tinted glasses, still the machine I had the most fun using. (Partly because of the machine, partly because everything I did on a computer back then was fun.)
Anyway, good luck!
Anyway, good luck!
I remember the SE/30 had an expansion slot that could have a video card to power an external monitor. I wonder if such boards survived and could be resurrected.
Does A/UX have a PPP driver ?
You could run NetBSD on your SE/30, it will do PPP (and IPv6).
You could run NetBSD on your SE/30, it will do PPP (and IPv6).
Delved into this a bit, and found some claims that there's no PPP driver for A/UX, so I guess there's the answer. I know about NetBSD. However, in my somewhat irrational mind, it lacks the cool factor of A/UX, the spiritual stepfather of Mac OS X (the biological one being NeXTStep, obviously).
The PPP protocol isn't very complicated, how easy it would be to add to a binary-only UNIX is another question. You could have a look for whether the A/UX network stack is from BSD or System V. One thing that would make a big difference is whether it supports STREAMS [1].
[1] https://en.wikipedia.org/wiki/STREAMS
[1] https://en.wikipedia.org/wiki/STREAMS
A few minutes of googling make it look like SLIP and PPP solutions exist for A/UX.
Pretty sure from my college days it has a full tcp stack, certainly I remember running X11R3 on A/UX and using two machines to get decent performance (one as server, one as client)
I used to have my RS-6000 (connected to my Intergraph monitor and a proper Model-M keyboard) running as X client to my laptop, which had a much smaller screen, and work that way. I could run a browser on the laptop (Firefox doesn't like X too much) and have a couple terminals and Emacs on glorious AIX flavored CDE.
Since there's enthusiasts in this thread: I have a working SE/30 in storage but the monitor light is dead. What would be the simplest/cheapest way of fixing it?
I'd say to have it diagnosed. It could be the tube or something in the analog board. Someone experienced in repairing CRT TV's or computer monitors can help pinning it down.
Head over to the 68kmla.org forum where the gurus are, and state the precise symptoms. Also, make sure you've replaced the PRAM battery as they will leak at some point and damage the mainboard, usually beyond repair. Same for old leaky capacitors, which leak their corrosive contents onto the mainboard, causing all kinds of nasty and hard to diagnose problems.
if the display is too dim and you have verified the analog board is good, crt rejuvenation is an option [1] but if it doesnt come on at all, replace the crt.
[1] https://youtu.be/YikOY8WTnLU
[1] https://youtu.be/YikOY8WTnLU
2 years younger (1985) Atari 520ST (1), upgraded to 3MB ram.
Here (2) with proper NE2000 compatible Realtek 8019 ISA network card (3) connected to cartridge port with super simple converter board, one 74LS245 chip.
1/ https://www.youtube.com/watch?v=dqSZQzCMZSU
2/ https://www.youtube.com/watch?v=LvKXWkyyYhc
large jpgs https://www.youtube.com/watch?v=5_UqkQ3QbWQ
animated gifs https://www.youtube.com/watch?v=CPaBQijrWAQ
3/ https://sites.google.com/site/probehouse/networking-the-atar...
Here (2) with proper NE2000 compatible Realtek 8019 ISA network card (3) connected to cartridge port with super simple converter board, one 74LS245 chip.
1/ https://www.youtube.com/watch?v=dqSZQzCMZSU
2/ https://www.youtube.com/watch?v=LvKXWkyyYhc
large jpgs https://www.youtube.com/watch?v=5_UqkQ3QbWQ
animated gifs https://www.youtube.com/watch?v=CPaBQijrWAQ
3/ https://sites.google.com/site/probehouse/networking-the-atar...
The screenshots demonstrate a world in Apple where Apple isn't stupidifed by making everything simple.
MacTCP and PPP are complex and all of the configuration options given demonstrate a level of control that's unheard of in even Linux these days, let alone Apple or Microsoft or Google products.
I wish modern software had that level of configurability.
MacTCP and PPP are complex and all of the configuration options given demonstrate a level of control that's unheard of in even Linux these days, let alone Apple or Microsoft or Google products.
I wish modern software had that level of configurability.
Like with having to dig into WDEF and CDEF resource fork entries to make a GUI application, I am inclined to view that more as a limitation of the technology and the era, not a feature. It certainly wasn't what Apple wanted to do.
Mac networking was, of course, supposed to be Appletalk, a system with no configuration dialogues for normal use beyond a human-readable setting for the computer's name. It also worked surprisingly well. The idea you could just connect two computers together and they'd automatically network was absent from most of the competition for another decade or more.
(For the record, I consider myself an anti-Apple fanboy. But it's only honesty that Appletalk was a big deal.)
Mac networking was, of course, supposed to be Appletalk, a system with no configuration dialogues for normal use beyond a human-readable setting for the computer's name. It also worked surprisingly well. The idea you could just connect two computers together and they'd automatically network was absent from most of the competition for another decade or more.
(For the record, I consider myself an anti-Apple fanboy. But it's only honesty that Appletalk was a big deal.)
Cool project! I had a Mac SE a while back that I only finally got rid of a couple of years ago. It did have some weird ancient Ethernet card that had an actual 10baseT interface with the RJ45 connector. I think I managed to get it connected back before I lost the floppy disk with the drivers for it. Like the article says though, the trouble is what to do with it after you're connected.
Even over the fast-ish Ethernet connection, any attempt to browse the web is painfully slow, esp when dealing with a tiny black-and-white screen. That's before even getting into crypto issues with modern TLS and the lack of modern Javascript. Considering that the phones in everyone's pocket these days make vastly better web browsing gadgets, it's hard to see what it's good for, besides a curiosity.
Even over the fast-ish Ethernet connection, any attempt to browse the web is painfully slow, esp when dealing with a tiny black-and-white screen. That's before even getting into crypto issues with modern TLS and the lack of modern Javascript. Considering that the phones in everyone's pocket these days make vastly better web browsing gadgets, it's hard to see what it's good for, besides a curiosity.
I've had a Craigslist alert for Mac SE ever since seeing how someone made theirs into a Spotify dashboard [1]. If anyone else has one and is interested, the code is all found here [2].
[1] https://www.hackster.io/news/a-macintosh-se-30-spotify-music...
[2] https://github.com/antscode/MacPlayer
[1] https://www.hackster.io/news/a-macintosh-se-30-spotify-music...
[2] https://github.com/antscode/MacPlayer
I wish the screen wasn't out on my SE. I'm terrified to open it up with that CRT. I'm almost certain that it just needs to be resoldered. I've been waiting for someone to do this with a Raspberry Pi.
Can the SE run any alternative OSes? The SE/30 can run A/UX. I think you need at least the Motorola 68020 to run OpenBSD... The SE is a 68000 with no MMU. Are you limited to Mac OS?
From like 95-97 I had my SE/30 (whose slot was tied up with a color graphics card) accessing the internet through my PC running slackware. The whole thing was going through a dialup connection! PPP between the two and and between the linux box and the ISP. I don't have the SE/30 anymore though.
This reminds me of a time when I sort of did the opposite: I networked a serial-only DEC PDP-11/83 running 2.11BSD using SLiRP running on a Power Mac…I want to say 7500; what I remember is that it was one of the earliest models with PCI slots, running Yellow Dog Linux, and that I was mostly using it as a router at the time.
Incidentally, does System 7.5 support AppleShare IP connections[1]? If so, Netatalk should easily build and run on Raspbian, and would allow file sharing between the SE and newer Macs with full filesystem semantics (resource forks, etc.), though, at 9600 bps, I suppose the floppy drive is faster, though, unlike floppies and floppy-compatible Mac filesystems, current Mac OS releases still happily connect to AFP file shares (over TCP/IP).
Speaking of serial port speeds: at least at the software level, the "printer port" on older Macintosh models sometimes ran faster than the "modem port", so PPP over the printer port instead of the modem port might be worth trying.
As serial communications on older Macs was also somewhat CPU-intensive, again speaking from decades-old memory, it might also be worth experimenting with a more lightweight protocol like SLIP instead of PPP.
[1] While PPP is a layer 2 protocol that should, at least in principle, be able to carry AppleTalk traffic, and while both Linux and Netatalk, at least historically, supported the AppleTalk protocols, I'd be (pleasantly) surprised if AppleTalk-over-PPP was supported on the Mac OS end.
Come to think of it, that's an interesting-if-less-than-useful question that I may just have to investigate (he wrote, as he confirmed his SheepShaver OS 9 install still works fine under Catalina).
Incidentally, does System 7.5 support AppleShare IP connections[1]? If so, Netatalk should easily build and run on Raspbian, and would allow file sharing between the SE and newer Macs with full filesystem semantics (resource forks, etc.), though, at 9600 bps, I suppose the floppy drive is faster, though, unlike floppies and floppy-compatible Mac filesystems, current Mac OS releases still happily connect to AFP file shares (over TCP/IP).
Speaking of serial port speeds: at least at the software level, the "printer port" on older Macintosh models sometimes ran faster than the "modem port", so PPP over the printer port instead of the modem port might be worth trying.
As serial communications on older Macs was also somewhat CPU-intensive, again speaking from decades-old memory, it might also be worth experimenting with a more lightweight protocol like SLIP instead of PPP.
[1] While PPP is a layer 2 protocol that should, at least in principle, be able to carry AppleTalk traffic, and while both Linux and Netatalk, at least historically, supported the AppleTalk protocols, I'd be (pleasantly) surprised if AppleTalk-over-PPP was supported on the Mac OS end.
Come to think of it, that's an interesting-if-less-than-useful question that I may just have to investigate (he wrote, as he confirmed his SheepShaver OS 9 install still works fine under Catalina).
Ah, my parents had one of these. It stopped booting in the mid 90s or so. I wonder if all it needed was some battery replacement or something.