NeXT Cube
Computers in Collection
NeXTcube, serial AAK0001948
Acquired 2020/07/14 from Aaron.
Inventory
- Case
- Logic board
- SMT capacitors: 47uF 16V, 6.3mm diameter, 6.5mm x 6.5mm footprint.
- Through-hole capacitors: 220uF 25V, 10mm diameter, 13mm height, 5mm lead spacing.
- RAM: 4 x SEC (Samsung?), each 8 x KM41C16000BK-6, from Korea or Portugal, seemingly unreliable and replaced with new.
Repair Log
Appears to be a 68040 25 MHz NeXTcube processor board inside an earlier NeXT Computer chassis (model no N1000, part no 23.00, serial AAK0001948).
Initial attempts at boot were erratic (power button seemed to take a long time to trigger). The hard drive spun up, but was incredibly noisy (which I think is typical of this drive). Screen was dim and full of noise. No indication that the computer was executing code – brightness control keys were inoperative, and power button would not turn computer off.
Opened the computer to inspect. The fan cable was unplugged. I don’t think it was due to me removing the back panel. After plugging it in again (with the correct polarity), it worked fine. I also found an empty clear plastic bag that was labeled as if it might’ve had RAM inside at one point.
The processor board is an MC68040 at 25 MHz with four SIMMs installed. The battery and electrolytic capacitors appear to be in OK shape – no evidence of leaking. I jostled the SIMMs and battery, but the system still powered up with noise on the screen and no responsiveness.
I tried unplugging the two ribbon cables (which turned out to be the SCSI and MO drive cables). The system then booted to the monitor before announcing that the SCSI bus was deserted. I tried booting with just the SCSI cable attached, and the system would cycle through a diagnostic loop repeatedly. With the MO cable plugged in too, the screen noise returned and the system would hang. Rumor has it these MO drives are prone to electrical failure, though I’m surprised it would impact video behavior… At no point did I see the diagnostic LED light up, but it’s possible I was looking in the wrong place (I was watching something that looked kinda like an LED, but could be wrong), or I was watching at the wrong times.
In examining the processor board, capacitance was tested across several capacitors in-circuit, and I got reasonable values. The battery tested at 1.88V, which is way too low, and may be part of the reason system booting is so erratic. At some point, I hot-wired a 3V DC power brick across the battery terminals, and the system would consistently boot in whatever way I configured it. The original battery is a Panasonic BR-2/3A, lithium 3V primary non-rechargeable (Digi-Key P133-ND). The date code on the one I removed is “0643”, so somewhat recently replaced! There’s a BR-2/3AG replacement that adds about 20% to the nominal mAh (capacity).
After extensive reading about the magneto-optical (MO) drive, I decided to recap three of the boards, commonly referred to as the analog, digital, and motor boards. However, the first order of business was cleaning the drive internals, as early NeXT machines had air drawn in through the MO drive slot, which caused tons of dust to collect inside. This alone would make the MO drive unreliable.
Removing the capacitors from the motor board revealed significant corrosion of the solder mask and traces underneath. The motor board capacitors tested at a useless fraction of their labeled value, often <1%. Capacitors in the 10-47uF range were testing in the low nF or even pF range. Capacitors on the other boards tested much closer to the intended values, but were often more than 20% below their original values.
There are several versions of the MO drive boards. These are the capacitors I ordered for my version. Please double-check they’re appropriate for the versions you have.
| Digi-Key | Part Number | Description | Part Designation |
| 493-15580-ND | UMV1H3R3MFD | CAP ALUM 3.3UF 20% 50V RADIAL | C306,369 |
| 493-15576-ND | UMV1H010MFD | CAP ALUM 1UF 20% 50V RADIAL | C1,2,30,281 |
| 493-15569-ND | UMV1C100MFD | CAP ALUM 10UF 20% 16V RADIAL | C2[21,44,6[69]],36[45],4[21,33,4[78],77] |
| 493-15571-ND | UMV1C470MFD | CAP ALUM 47UF 20% 16V RADIAL | C277,279,303,352,353,354,355 |
| 493-16959-ND | UMV1A220MFD | CAP ALUM 22UF 20% 10V RADIAL | C31,32 |
| 493-15579-ND | UMV1H2R2MFD | CAP ALUM 2.2UF 20% 50V RADIAL | C3 |
| 493-15578-ND | UMV1H100MFD | CAP ALUM 10UF 20% 50V RADIAL | C4,5,6,7,8 |
When reassembling the MO drive, I didn’t route a few bundles of wires correctly and wound up pinching them between parts of the chassis. They appear to have survived. I eventually realized one of the stand-offs between the analog and digital boards was different for precisely this reason, so I routed the cables through the guide on the unique stand-off.
My first tests of the recapped MO drive were unsuccessful. I was able to boot the system and get it to ingest a disk. But it never seemed to read the disk. I was able to eject the disk, but then was unable to insert a disk again, despite resetting and power-cycling the machine. Research indicates the drive needs to be connected to a responsive host computer to perform ingest and ejection of media. And since the machine was acting erratic in other ways, this might be why the drive wouldn’t accept disks.
I plowed on trying to get the computer to boot from the MO drive, despite persistent RAM errors during power-on system testing. I removed and reinserted the four 1Mbyte SIMMs, applied a film of DeOxit, and rearranged the SIMMs. All that did was change the nature of the errors a bit, but didn’t fundamentally improve anything. Eventually, I tried unplugging all drives, hot-wiring the battery to a 3V supply, and reconfiguring for netboot from the twisted-pair Ethernet. Still, there were RAM errors. A more disciplined mind than mine would’ve addressed the RAM errors first. So I went online and procured some SIMMs – 4 x 4MB (no parity) from Garrett’s Workshop, and 4 x 4MB (parity) from Keystron.
The title bar in the ROM monitor reports v59, and the ROM in the system says it’s version 2.0. It’s a 128K ROM, a “TMS27C010-250JL LP9035”. It appears to match the Rev_2.1_v59.BIN ROM file, except for what I’m assuming are MAC and checksum bytes. The latest version of the ROM for this processor board is version 2.5 and v66. The 1.0 ROM (1142.00) I have in a case is on a “TMS27C512JL ALDQ 8913” chip. And sure enough, versions in the 1.2 and earlier timeframe were 64Kbyte images. The 1.0 ROM matches the Rev_1.0_v41.BIN ROM file, except for five bytes, presumably once again MAC and checksum data.
Backing up the ROMS using the MiniPRO:
minipro --device TMS27C512@DIP28 --read /tmp/next_cube_rom_release_1_0_1142_00.bin
# Chip ID 0x9785
minipro --device TMS27C010@DIP32 --read /tmp/next_cube_rom_release_2_0_2918_00.bin
# Chip ID 0x9746
The battery was replaced with the aforementioned Panasonic BR-2/3A. I had to reset the boot parameters to get the machine to not boot off the magneto-optical drive by default.
After a few attempts, I was never able to get the RJ-45 (twisted-pair) Ethernet port to link or communicate with my home switches (which are all modern, 2010s-era 10/100/1000 switches). I bought an Allied Telesyn AT-MR820TR 8-port 10Mbit hub with a selectable AUI/BNC port. I connected it up using a short 50-Ohm BNC coax with a tee and terminator at the NeXT side. I enabled the terminator on the hub side, and switched the port to 10base2 media. However, it didn’t seem to work until I also turned on “backplane enable”. Now the Cube can talk IP to the outside world! Too bad ping isn’t available and I don’t know how to configure DNS… NeXT Computers Forums to the rescue. However, do I need to be running a newer NeXTSTEP to get things like DHCP? There’s also a document that should help.
Magneto-Optical Drive Imaging
I entertained using rsh and rcp, ftp, and NFS to copy disk images from the NeXT Cube to a modern system. I eventually settled on using NFS, as it seemed the most amenable to using dd as a means to copy a disk image directly to the remote system with minimal fooling around.
I set up a Raspberry Pi 3 Model B+ with the latest (2020-08) Raspberry Pi OS Lite image, installed the NFS server, and exported a directory I could mount from the Cube. The first complication was trying to resolve a machine name when mounting the NFS share on the Cube. I had NetInfo active, which seems to take precedence over /etc/hosts, so I used the NeXT NetInfo application to add a machine entry with a name and ip_address of the Raspberry Pi. Then, I got an error about the NFS protocol version being wrong. I had to change the configuration on the Pi to enable NFSv2 (which is disabled due to being deprecated and insecure). I successfully mounted the NFS share on the Cube. I could read from the mounted share, but could not write to it. This was due to incorrect permissions on the shared NFS directory on the Pi. After fixing that, I could then use dd to transmit an image of the optical disk to the shared directory on the Raspberry Pi. Yay for archiving old, unreliable media!
# On the Raspberry Pi
sudo apt install nfs-kernel-server
sudo vi /etc/defaults/nfs-kernel-server
# Add the line `RPCNFSDOPTS="--nfs-version 2,3,4"`
sudo mkdir /srv/nfs
sudo chown -R nobody:nogroup /srv/nfs
sudo vi /etc/exports
# Add the line `/srv/nfs 192.168.1.0/24(rw,sync,no_subtree_check)`
sudo systemctl restart nfs-kernel-server
# Verify the versions of NFS support that are enabled, including "+2":
sudo cat /proc/fs/nfsd/versions
# On the NeXT Cube (`retro-pi` is the name of the NFS server and resolves to
# the IP address of that server)
mkdir /Net/nfs
mount -t nfs retro-pi:/srv/nfs /Net/nfs
# There's probably a more appropriate place to mount NFS than /Net?
An outstanding question is should I be using od0a or rod0a?
While copying MO disk contents, it was handy to have the NeXT Console open. Errors reading from the MO drive or writing to the NFS share will be displayed. I experienced some of both… In the case of NFS, the transfer hung silently (except for a Console message!) until I jiggled the Ethernet BNC connection on the back of the Cube.
NeXTSTEP 3.3 on a SCSI2SD
Initially, I installed NeXTSTEP 2.0 from a magneto-optical disk to a SCSI2SD partition (helpful thread). It worked fine, but I quickly got the sense there wasn’t a whole lot of software that would run on it, versus a newer version of the OS. So I set about installing NeXTSTEP 3.3 from some floppy and CD-ROM images I found. NeXTSTEP 2.0 apparently doesn’t know what to do with filesystems labeled with 2,048-byte sectors (e.g. CD-ROMs), but the NeXTSTEP 3.3 installation floppy has a kernel that supports it, since its installer boot floppy needs to read from the NeXTSTEP 3.3 CD-ROM to complete the installation.
Side note: Use a good SD card in your SCSI2SD! Initially, I’d used a random 2G Kingston card I’d had lying around. I have no idea how old or worn out that card was. Over several hours of messing around with MO backups and installing a new OS, the Cube got more and more eccentric, freezing for minutes at a time with constant disk activity. I replaced the old 2G card with a Sandisk “Switch” 128G card, and immediately observed far greater disk speed when installing NeXTSTEP 3.3. The initial file copy, which took maybe 30 minutes on the old 2G card, took maybe three minutes with the new card. Wow! Something’s still unreliable though. The machine wouldn’t shut down smoothly and is complaining about an invalid floppy format and a Workspace fatal error, requiring a forced logout that never moves beyond a blank screen.
NeXT recommended certain SCSI IDs for certain device types. I’m going to ignore this for now, as later on, I discovered that original Maxtor drive was configured for SCSI ID 0.
| SCSI ID | Device Type |
| 1 | Primary boot hard drive |
| 2 | Secondary (data) hard drive |
| 3 | CD-ROM |
| 5 | Internal floppy (optional) |
I’m also removing the special disk geometry I saw recommended in the NeXT forum, as it has a whiff of cargo cult reasoning. It’s supposedly related to a bug in earlier OSes that miscomputed geometry for larger disks. But would NeXTSTEP 3.3 have that problem?
Since the 330MB Maxtor XT-8380S in the system was working remarkably well, maybe I should look at its jumper settings for clues. Terminating resistors were installed in the sockets. Jumper labels are quite unhelpful. Looking for documentation… SCSI ID jumpers are spread all over the board! But it appears my drive was configured for ID 0.
| SCSI ID | JP37 | JP36 | JP35 |
| 0 | Open | Open | Open |
| 1 | Open | Open | Closed |
| 2 | Open | Closed | Open |
| 3 | Open | Closed | Closed |
| 4 | Closed | Open | Open |
| 5 | Closed | Open | Closed |
| 6 | Closed | Closed | Open |
| 7 | Closed | Closed | Closed |
JP14 and JP38 determine the power-up options. My drive has JP14 closed and JP38 open, which means “start when power is applied”.
Terminator behavior is determined by JP34 and JP41. My drive has JP34 open and JP41 closed, which means “terminator power is internal, from the drive”.
JP40 determines parity behavior. My drive has JP40 closed, which “enabled odd parity detection in the drive”. Apparently, the drive outputs parity regardless. This jumper just determines if it checks parity on incoming data. So there’s something I need to change! I’ve got parity disabled on my SCSI2SD.
This drive supports SCSI disconnect/reconnect and unit attention, so let’s enable those too.
The drive’s geometry is 1632 cylinders, 8 heads, 54 sectors/track, 512 bytes/sector.
Well, that didn’t work. Trying without “unit attention”. Nope, no better. How about without “SCSI disconnect”? Nope. How about “parity”? Nope. What the hell? OK, interesting, when I disabled targets 0 and 1 (both 2G drives), I could now boot OK from the floppy drive at ID 5. Maybe this is the geometry problem I poo-pooed. Trying first with default geometry and much smaller drives (0=512M, 1=512M). Nope, trying smaller (256M). Nope. I almost think it may be because of the remnants on drives 0 and 1… The ROM monitor reports:
Boot command: sd
boot sd(0,0,0)
booting SCSI target 0, lun 0
Bad version 0x0
Bad version 0x0
Bad version 0x0
Bad version 0x0
Bad label
NeXT>
I found a most useful thread which mentions several of the problems I’ve observed. First, to try the geometry hack, since I don’t think problematic floppy emulation is the cause for the boot ROM not finding the floppy. Didn’t help! Trying making the drives an even multiple of the sectors in a cylinder. Nope. What the hell? How about unique device serial numbers? No. Removed an extra space after the prodId in the last device. No effect. Change floppy ID to 2, so that devices are in order from 0 to 3. Well damn, that worked. Adding back parity, unit attention, disconnect. Still working. Enlarging drive sizes to ~2G (rounding down to a whole number of cylinders)… Still working! NeXTSTEP 3.3 kernel detects ATTENTION feature and the installer sees drive 0 as being 2047 MB – all good!
I still kinda hate this 139 sectors and 4 heads business though. It seems super arbitrary and not very “round”. I don’t trust it. As an example, the Maxtor drive removed from this system has 1632 cylinders, 8 heads, and 54 sectors per track.
Oh hey, we crashed out of the NeXTSTEP 3.3 installer, because of some SCSI-related error. Yay. I wasn’t fast enough grabbing a picture before it cleared. I did have the back cover off, but it’s pretty cold today, so somehow I don’t think it’s heat-induced. I suppose this is a good sign, in that maybe enabling SCSI parity checking might be uncovering other stability issues?
OK, caught one of the errors, which was much shorter than the first one, but happened only a few seconds after the NeXTSTEP 3.3 installer started its first pass of file copying.
sd3 (3,0): ERROR op:0x28 sd_state:2 scsi status:0x0........................
IO error on pagein (bread)
/private/etc/rc.cdrom: 49 Bus error
/private/etc/rc.cdrom: /private/tmp/mnta/private/etc/fstab: cannot create
CD-ROM boot procedure complete.
So sd3 is the CD-ROM. I wonder if the CD-ROM emulation is the problem? Or just the size of the device? I marked it as being 800MB, which is bigger than any CD-ROM should be. I’ll try shrinking the size of the disk first, to the precise size of the image I used.
Nope, similar failure (breadDirect, with a much longer error message, probably more like the first one I had but didn’t get a picture of). Somehow I wound up with a mostly viable install though. Trying again, with the device set to hard disk instead of CD-ROM. Nope, the installer expects the CD-ROM to appear as a CD-ROM, not a hard disk. Sigh. Switching back to type CD-ROM, disabling unit attention and disconnect. Interesting, the CD-ROM still shows up with “UNIT ATTENTION” in the kernel SCSI scan. Well, the first phase of file installation succeeded! The GUI-based second phase seems to have crashed and restarted though, which does not bode well… And it just crashed again. I wish I could get a message about what happened. Is there a debug serial port on this thing?
Trying a slightly smaller partition (3905900 x 139 x 4 x 512), based on an example from the NeXT forum. Of note, this is 1,999,820,800 bytes, just below 2 billion bytes. NeXTSTEP 3.3 kernel sees 1907MB – good… Then:
sd0 (0,0): ERROR op:0x28 sd_state:4 scsi status:0x0
sd0 (0,0): sense key:0x5 additional sense code:0x21
SCSI Block in error = 336; Partition a F.S. sector 8
(null pointer): CANNOT READ: BLK 2092392
(null pointer): UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Reboot failed...help!
…and that would be the old 2047MB partition with the half-finished NeXTSTEP 3.3 install. Apparently there’s pointers in the old filesystem that point beyond the bounds of the new disk geometry. Fair enough. Starting a new install (cold machine, has been off for a few hours): First stage file copy complete, rebooting, second stage file copying now, success, rebooting, final setup, Workspace! Got a message about an uninitialized SCSI disk, so I let it go ahead and initialize it. I have to assume that’s disk 1, not the one I just installed! Initialized, but why is the icon a CD?
Now to get it on the network. “SimpleNetworkStarter” looks like just the ticket.
And now the machine won’t shut down. The windows and menus have disappeared. Tiles in upper right corner are still there. Mouse still moves. SCSI2SD activity light is on pretty much solid – only a slight hint of a flicker, so something is happening. Is this the floppy or CD-ROM eject problem? Signs point to yes: I disabled the floppy and CD-ROM targets and the system shut down from a logged-in state just fine.
Another side note: You can plug your laptop into the SCSI2SD USB port while also having the SCSI2SD powered from the retro computer. That really shortens the debug cycle, and reduces wear and tear on the SCSI and power cables and connectors.
There is a 2Gbyte per partition limit in NeXTSTEP < 4.0 (and maybe 4.0, too?). Perhaps I’m pushing my luck with the 2G drive I’m installing to now…
It seems like NeXTSTEP prefers 1024-byte sectors?
Another unanswered question: is the twisted-pair Ethernet jack only supported by newer ROMs and OSes?
So I’ve finally got everything installed and understand the troubles along the way.
- Disk geometry for the hard drive is important, and a 2G (2 * 1024 * 1024 * 1024) partition seems too big. So I’ve used the drive geometry and partition size I found recommended frequently in the forum (bytes/sector=512, sectors/track=139, heads/cylinder=4, sectors=3905900, and therefore 7025 cylinders).
- The NeXTSTEP 3.3 install process will hang after the first reboot, at the message
Setting tape block size for /dev/nrst1(and printing periodic space characters), if you have a network connected (and presumably not responding as NeXTSTEP would like). - Using SCSI2SD device type 0x2 (optical drive) causes NeXTSTEP to hang when you attempt to power off from a logged-in state, which appears to be a SCSI2SD bug around removable/eject-able drive behavior. Setting the device type to 0x0 (fixed hard drive) doesn’t interfere with NeXTSTEP interpreting the CD-ROM image correctly, so makes for a decent work-around.