Resurrecting A Recalcitrant SE/30

The Macintosh SE/30 is well regarded as the choice pick of the compact Mac line. Packing a powerful 68030 processor and with the capability to use up to 128 MB of RAM, it brought serious grunt to bear in a tight form factor. With these machines now over 30 years old, they’re often quite worse for wear. [This Does Not Compute] had his work cut out for him getting this particular example up and running. (Video embedded below.)

With the computer displaying the famous SimasiMac screen on startup, it was sadly non-functional when switched on. [This Does Not Compute] went through all the usual attempts to fix this – washing the board, recapping, checking potentially broken traces – all to no avail. After much consternation, the fix was not so hard – a fresh set of RAM helped cure what ailed the Mac.

With the Mac now showing some signs of life, there was more to do. The floppy drive refused to boot, ejecting disks and failing to read anything. A head cleaning proved helpful, but not enough. It was only when the head motor’s worm gear was relubricated, enabling it to seek properly, that the drive was successfully able to boot. The hard drive proved resistant of any attempts to get it to work, so was replaced with a SCSI2SD instead.

With the suite of repairs completed, the SE/30 was once again up and running. With a little elbow grease, the case and keyboard turned up a treat, too. [This Does Not Compute] now has one of the all-time classic Macs in excellent condition.

We’ve seen some great restorations over the past – this Commodore 64 full of dirt was a particularly compelling story. Video after the break.

26 thoughts on “Resurrecting A Recalcitrant SE/30

  1. Original late 80s to early 90s Mac are suffering badly from leaking caps and batteries. If you find one in classic eBay “untested” condition it is bound to require restoration. My SE/30 had chips so corroded they just fell off the board, leaving behind pads which would not wet solder until the corroded junk was sanded off.

  2. Over the years I got many many dozens of them for $10 a pop. I clean them up and sold them for a lot more. They were always in decent condition. I believe local businesses were giving them to Goodwill maybe it was cheaper than disposing of them.

    1. yes, but with significant OS add-ins (see the footnote on that page). Otherwise, 8MB is the limit on those 68030-based Macs. Which seemed like a lot at the time. When I realize that I could run my original Mac with 128K RAM and a 400KB floppy ($10 a pop) with a minimal OS, MacWrite and MacPaint, it’s pretty astounding that 35 years later I’m running a two-year-old phone with 4GB RAM (32,000X), 128GB (131,000X) storage… and it has to do memory swapping when I switch between apps.

      1. If you think about it, the original PalmOS did exactly that on about the same computational resources. Even Symbian was decently optimized for their time. It was Android (and before that, arguably, iPhone OS) that started the race for more RAM with way too hungry, unoptimized frameworks & programs.

        On the other hand, I cannot see how a 128MB equipped SE/30 might run out of RAM (or handle so much concurrent tasks) considering the lean nature of its OS & programs… Someone enlighten me please?

        1. All the way from the first Mac through Mac OS 9.2.2, RAM was treated like a hard drive. Every program would request a block of RAM and if a contiguous block was available, the program would run.

          What the program authors had to do was know how much RAM was needed to load the program, and how much additional RAM the program would need for temporary use. Add the two together and that’s how much it had to have.

          Mac users had to keep track of the order they launched and quit programs, especially on the early ones with small amounts of RAM. For example on a 128K Mac part of that was used by the System, INITs (Extensions with System 7 and later) and Control Panels. You could run only two or three programs if they were quite small.

          Launch Program A and it uses some RAM. Launch Program B and it uses some RAM. Launch Program C and it uses some RAM. Now quit Program B then launch Program D. But Program D is larger than Program B so it cannot fit in the space where B was. So System checks the RAM between the end of Program C and the end of RAM – which is also smaller than Program D.

          You get the not enough memory error, despite About this Macintosh showing it has enough free RAM for Program D.

          Apple *never* fully fixed this issue for 17 years, 1984 to 2001. From the first Mac System to the release of the final Mac OS 9.2.2 update December 5th 2001.

          Jump Development did fix it, and very damn well, with their RAM Charger software. It dynamically remapped the RAM space so no matter how fragmented free space got, the OS always saw it as a single block. For most programs, RAM Charger could dynamically grow or shrink the additional RAM programs required above the space needed to load the program. That could even fix poorly written software that would run out of RAM because it wouldn’t request enough additional space.

          What was Apple’s response to being upstaged by a small company who did a core System function far better than they? You might think they’d license a somewhat stripped down version of RAM Charger, like they did with SuperClock and several other enhancements that became core parts of the OS.

          Nope! Apple decided to be petty and break it, repeatedly, by making tweaks to their operating system with new versions and updates so that Jump Development would have to figure out how Apple had broken compatibility and tweak RAM Charger to work with the new OS version.

          Jump Development finally threw in the towel with the release of Mac OS 9.2. RAM Charger still does its main function of RAM defragmenting and dynamic space adjustment, but some other things don’t work with 9.2.1 and 9.2.2. I dunno why they didn’t go ahead and release a final version to fix those issues after Apple switched to OS X. Apple was highly unlikely to take a Parthian Shot with a 9.2.3 update just to break RAM Charger one more time.

          Make me wonder why Apple was so nasty towards Connectix when their RAM Doubler compression software included a far better and faster replacement for Apple’s own Virtual Memory function?

          RAM Doubler was much more flexible than Apple’s VM. You could select pretty much whatever size swap file you wanted. The mostly useless RAM compression could be turned off.

          The best setup was to use RAM Charger and RAM Doubler, with compression off so you were only using its virtual memory.

          If Apple had just swallowed its pride and licensed ‘feature reduced’ versions of RAM Charger and Connectix’s virtual memory, Mac OS could have been quite a bit better operating system.

          But that was not to be. Apple couldn’t even figure out how to make the “classic” OS use more than one network interface and protocol at a time, without 3rd party software. Meanwhile, Windows 95 could use up to six different network interfaces with multiple protocols on them simultaneously.

    2. But what about SIMM density? There were limited slots, either four or eight, for memory. Were there SIMMs with enough density to max tbat up to 128megs?

      I suspect that either they weren’t available, or were very expensive. So likely few at the time expanded that much. Things kept moving on before a given density became available. DIMMs had more density, and were cheaper for it, but they didn’t fit into a stock SE/30.

      The Mac Ii was more sustainable, since it started with more memory s!ots, and was easier to add a newer CPU board. But since it was more expensive, you’d want that ability to upgrade it and keep it running !onger.


      1. The Daystar company made a wide variety of upgrade addons. They made a different one for every model of Macintosh. Remove the CPU and (if equipped) FPU then plug in their upgrade. The Mac II was a special case. It had an MMU chip that added the ability to do virtual memory. However, that was optional. If the Mac II wasn’t ordered with the MMU it got an “Apple Memory Unit” which was a dummy chip that had the bare minimum circuitry inside for the computer to function.

        Some models of the IIc had the CPU soldered. Thus the DayStar upgrade didn’t include a CPU puller without the Mac owner verifying a socketed CPU. For soldered chips, Daystar offered a service to pull the CPU and install a socket.

        All of this changed with the introduction of the IIci with its “Cache Slot” that was a really a Processor Direct Slot.

        Instead of manufacturing unique upgrades for every Macintosh model, Daystar changed to making IIci Cache Slot adapters to fit their IIci compatible upgrade boards into most of the models prior to the IIci. For the IIsi they made an adapter with two slots, one IIci slot down low for the upgrade and one IIsi PDS passthrough up high in line with the card slot hole in the back so IIsi or some SE/30 cards could be used. IIsi and SE/30 had the same PDS, IIci, IIvi, and IIvx had the same “Cache” slot, but the only Mac able to use the IIci Cache Card was a IIci.

        That saved Daystar a huge amount of money because the adapters were mostly quite simple and comparatively inexpensive to make. It also enabled faster turnarounds on repairs and replacements. If someone’s upgrade failed, they could just unplug the IIci upgrade board from the adaptor and Daystar could ship out another from stock – instead of having to repair the returned unique upgrade board or manufacture a new one.

        Going to basing everything off the IIci PDS also allowed for Daystar’s Turbo 601 upgrade with a 60 or 66 Mhz PowerPC 601 CPU. Overclocking a 60 Mhz version to 66 Mhz was possible but not at all simple. Those CPUs were very tightly binned (at least the ones Daystar used were) so it wasn’t too likely for a 60 Mhz to be stable when overclocked.

        A 60 Mhz Turbo 601 I had in a IIci revealed something hidden in Mac OS 7.6. If I did a PRAM zap with the PPC enabled, it would reboot in 24 bit mode, running with the mainboard’s 68030 CPU. That’s not supposed to be possible with Mac OS 7.6. I never tried running any software that required 24 bit mode, I’d always launch the Memory control panel, click the 24-32 bit mode switch, re-enable the Turbo 601 and reboot. Use the Turbo 601 control panel to reboot to 030 mode and… no 24-32 bit switch showing in the Memory control panel.

        Another oddity was Apple’s 601 upgrade control panel could *turn off* Daystar’s Turbo 601 but would not recognize it to turn it on.

  3. great post. I scored two of these curbside a few years back and one was fully operational, but these tips will help me do preventative maintenance.

    So… sources for old applications to run on these classics?

  4. Huh. Only thing I didn’t try on my Mac 512K floppy drive that would just spit disks back out immediately was was regrease the worm gear for the head carriage. Don’t know why I didn’t try; I had to regrease the eject mechanism to get it to eject disks at all. I’ll have to pull it off the shelf and try that out.

    1. I’ve only had used Mqcs, but the floppy drives qlways seemed dirty. Maybe because the opening for the floppy had no cover. None of the drives I bought new were as dirty.

      The original Mac drives, the single sided, had a snap in bit of plastic to provide pressure on the unused side of the disk. The bit seemed prone to come out with jammed disks,. Lose the bit of plastic and you probably lost the drive, at least circa 1995 when I had one or two of them. Though I never tried to get a replacement bit of plastic, I assumed too expensive even if they were available.


Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.