Anyone got a NeXT cube with a functioning MO drive?

[Chuck(G)]

The title pretty much says it all. If you're willing to take on reading three of the old MO disks, contact me.

 

[NeXT]

Last I remember there was ONE and exactly ONE (1) guy on nextcomputers.org that had a working drive and was offering a MO dump service.
In theory though you can get your own working if you recap the bloody thing but nobody has ever done the job.

 

[Chuck(G)]

Simply recap or also re-lasering?

 

[NeXT]

When I dismantled mine I found all the caps (tiny through-hole radials) on the motor control board had failed, which would explain why even NOS drives were winding up dead.

There are a few more elsewhere in the drive so it's entirely possible that replacing them will bring most of the drives back. The rest might have trouble with rumored cloudy optics.

 

[Chuck(G)]

Well, if anyone has a failed one to spare, I'll attempt a repair and get back to you as to what did or did not work.

 

[NeXT]

I unfortunately can't help you with that however I'm sure someone else between the two forums can offer their donor drive. Most people now are replacing the MO with CD anyways.

 

[joekster]

While I doubt its compatible, I do have a working pinnacle micro apex 4.6g MO. I know it can read 650mb MO disks. If you can give me some guidance, I'd be happy to dump your disks.

 

[Chuck(G)]

No--I have one of those also--along with both 1024 and 512-byte sector media. The NeXT stuff is quite different.

The more I read the Cube information, the worse the thing looks. Nobody seems to have any good idea of why the Canon drives fail--just a lot of guesses. The NeXT disks/discs were 256 MB, not standard 650 ones. Internal documentation on the NeXT box seems close to non-existent.

 

[Conmega]

Guess no-one contacted you with a working drive. I have mine working reliably. Another friend also got his working reliably. The bigger problem is figuring out how to actually image the disk. It looks like one solution is to use the "dump" command, then I guess in the 'previous' NeXT emulator you could use the "restore" command to get it back to an emulated MO disk image that people can use in the emulators.
This is probably the current best route. Since NeXTStep only ever seems to offer you the partition in '/dev/od0a' for example instead of giving you just '/dev/od0' as-well as modern *nix's do. I tried 'dd'ing the '/dev/od0a' and while it seems to give you all the data off the disk, its not in a usable format for something like the emulator, and I am not sure if you can 'dd' it back to an MO disk or not. Don't have a known empty scratch disk yet.

I'll let you know what I figure out. If I get a process down and you still need them imaged let me know.

 

[Chuck(G)]

Since my post was 10 years ago, I don't recall if the problem was ever solved or not. At any rate, I haven't received any other requests. I do recall contacting a NeXT-fanboi friend only to find that he'd gone the hard disk upgrade route. That MO drive as the sole mass storage device was a "what the heck were they thinking?" thing for me.

 

[stepleton]

Since NeXTStep only ever seems to offer you the partition in '/dev/od0a' for example instead of giving you just '/dev/od0' as-well as modern *nix's do. I tried 'dd'ing the '/dev/od0a' and while it seems to give you all the data off the disk, its not in a usable format for something like the emulator, and I am not sure if you can 'dd' it back to an MO disk or not. Don't have a known empty scratch disk yet.

In BSDs the device giving access to the entire disk is one of the lettered devices. According to Wikipedia, it's the device ending in the letter 'c':

BSD disklabel - Wikipedia

en.wikipedia.org

But to find out for certain which to use for NS, refer to the appropriate manpage on your NeXT box. I think the manpage is `sd`.

 

[NeXT]

I got some help on the NeXT forums back in 2015 and solved this. I was able to archive all but one cartridge out of my stack of 19. The one disk I couldn't was so bad that inserting the cartridge into the drive would crash NeXTSTEP on the spot.

You will need to download and compile GNUtar. Running just the usual TAR command ran into issues because the version that shipped with 3.3 lacked features.

While verifying that I had imaged the disks properly I noticed that I was missing files. Apparently tar is skipping a few because the filenames are too long. The supposed fix is

tar -Ecvf /archive.tar /source/folder

...according to this page but it seems that Tar on NeXTSTEP doesn't know what the E modifier stands for. It was apparently added to tar years after NeXTSTEP 3.3.

Edited: Adding insult to injury, it seems the latest releases of gnutar won't even configure on NeXTSTEP. Something about the shell being too old.

Edited: Ah right. Kb7sqi built gnutar for NeXTSTEP a while back. It's just not hosted locally in the file archive.

I did run into weird file size change issues but ultimately I blamed that on blocksize conversion. I sent the archive to the owner on a DVD and never heard back, so presumably they were able to read the data.

That MO drive as the sole mass storage device was a "what the heck were they thinking?" thing for me.

Reeks of Steve. It was shiny and new and was a hell of a gimmick. I'm sure the engineering department didn't like the idea either.

 

[Conmega]

Well I ended up getting away with the exact method I theorized with some extra convoluted steps to get a functional emulator MO disk. Also tried a few other things as you suggested stepleton, and no the `c` or `h` (as someone else suggested trying) partitions does not work to capture the entire MO disk `od` devices... Although it seems it should for `sd` or scsi devices. And I tried the r(aw) devices and the non-raw. Both gave an error. I suspect the probably rushed and half baked MO support cause a lot of little misses and things like that... So unfortunately conventional wisdom did not win out here.
I am going to try an experiment though later, I just got a Canon Diskfile 5001S off ebay... I can't recall if anyone has tried a single sided NeXT disk in one of those, but it should be the same logical format AFAIK? Could be wrong... But if it is that should allow a linux box over SCSI to actually 'dd' the entire block device instead of messing around with just a "partition".


Though this doesn't really matter. All you seem to really end up missing is the label of the disk since you have no boot blocks in NeXTStep and it just points to a #BOOTFILE link on the drive to look for a kernel for bootable disks. I did both 'dd' from /dev/od0a and 'dump'. Both restored in emulator to an emulated MO drive and both were bootable and seemed fine.


Few things to note. If you have bad sectors you MUST use the 'dump' command, 'dd' even with 'conv=noerror,sync' just hangs and eventually errors out on a read error. Where as it seems dump was patched and deals with bad sectors just fine then tells you at the end which sectors were bad. Nice and tidy. Clearly no-one at NeXT was testing 'dd'ing their MO disks as extensively as 'dump'ing.


So my process is as follows:

• Two 2~GB SCSI hard disks, a linux box that can work with SCSI drives, 'dd' a copy of NeXTStep to the first drive, I went with 3.0 but others should be fine.
  
  
• Another drive initialized and formatted under NeXTStep as your data drive, if its over 2GB then you must setup /etc/disktab to have at max 2GB partitions for NeXTStep 3.x and earlier I believe it was. This should mount at `/{data disk label}`
  
  
• First note the MO disk's label your about to image, should appear in the File Viewer, you'll need this later if your going to create an MO image for the 'previous' emulator.
  
  
• `cd /{data disk label}`
• `dd if=/dev/od0a of=./{disk name}.dd bs=1048576` You can leave block size default, 512, but it will take well over an hour to copy, 1M seems to get you to around 25 minutes.
  • If for some reason this fails part way through with a read error, instead do a `dump` of the disk to get as much as you can...
  • `dump 0fds {disk name}.dump 6250 9999 /dev/od0a` What you are doing here is, setting level 0 (aka dump everything!), f for file (default is a tape drive), d for density we set 6250, s for size or more accurately length, then you supply the partition your dumping. The reason for the density up from default of 1600 and length up is because otherwise dump will stop 1/5 of the way through dumping the MO and ask you to change the tape! Hah! We don't want that so just set it to high density and really long to make it think our dump will only take up a fraction of the tape
• With a 2GB partition you can just barely eek 8 disk dumps in, they are a bit smaller since they don't actually take everything, there is even an option to compress but I didn't bother you can try if you'd like. I think you may only getaway with 7 'dd's but you might be-able to fit 8.
  
  
• Either-way. What I do now is take the data drive back over to my linux box and you have two options.
  • Mount the disk readonly: `mount -t ufs -o ufstype=nextstep {device} {dir}` and now get your 'dd's and 'dump's off.
    OR
  • 'dd' the entire data disk to a file, open in 'previous' the NeXT emulator with a boot drive also mounted and some blank MO disk files mounted.
• For the later:
  • Initialize the blank MO disk files with the correct labels you noted down from the MO disks you imaged.
    
    
  • Then 'dd' them back or 'restore' the dump files as follows:
    • `dd if=./{disk name}.dd of=/dev/od0a bs=1048576`
    • `cd /{disk label}` then `restore rf /{data disk label}/{disk name}.dump` BE SURE YOU ARE IN THE ROOT DIRECTORY OF THE MO DISK, the restore function just spews it out at the current location. As far as I can tell from the docs there is no way to tell it a path to spit it to, just override the input with a `f`ile.

That's my process. Let me know if something doesn't make sense or you can think of any improvements.
I'll have to remember to post back here on what I can do with the Canon Diskfile unless someone already knows it works, or doesn't work!
As for the bad sectors... For now I guess we live with them, try and figure out what files may be corrupted. If the Canon Diskfile works out maybe I can run ddrescue on those disks.
Someone also suggested just trying to build ddrescue on the NeXT since GCC seems available. But I worry about whatever drivers lay underneath causing more issues than it may be worth for their custom interfaced MO drive... Might be worth a try if someone wants to give it a go though.

 

[Wildfire]

Someone also suggested just trying to build ddrescue on the NeXT since GCC seems available. But I worry about whatever drivers lay underneath causing more issues than it may be worth for their custom interfaced MO drive... Might be worth a try if someone wants to give it a go though.

So the internal mo drive of the cube is not a scsi one ??
Otherwise it would not be a problem to connect it directly to a Linux box and use ddrescue there, i did this quite a lot of times with other scsi gear and it worked well for me...

 

[Chuck(G)]

Connection claimed by NeXT for the Canon MO drive to be proprietary. From what I've read, most problems of non-functional MO drives stem from the motor control board, which is usually plagued by leaky capacitors. If anyone wants a repair guide for this thing, it's here.
For the semi-purists, apparently substituting a 3.5" SCSI MO drive preserves the spirit and works a lot faster.

 

[Conmega]

Connection claimed by NeXT for the Canon MO drive to be proprietary. From what I've read, most problems of non-functional MO drives stem from the motor control board, which is usually plagued by leaky capacitors. If anyone wants a repair guide for this thing, it's here.
For the semi-purists, apparently substituting a 3.5" SCSI MO drive preserves the spirit and works a lot faster.

So its not just the motor board... There are about 4-5 boards sandwiched and folded over each other in that thing and all of them have electrolytic caps and they have all leaked by this point. I just opened mine up, got all the values and their height dimension, and ordered new caps as close as I could get...
Seems the bigger problem at this point is the corrosion from the caps damaging the relatively fragile ceramic trim pots and trim caps allllll over the boards.
It looks like the doc you linked gives you a good idea of all these boards and how cramped it is.

I heard people report that powering up your drive with bad caps will blow up the motor controller and I just don't think that's common. Out of 4 disk drives that had probably hours of power on them with bad caps, none of them ended up with bad motor controllers. So while its surely a possibility, its unlikely from my experience.

But yes completely proprietary interface in the NeXTs. Thus the annoying process.


A friend, Sark, was able to get a NeXTStep image running off a 230MB 3.5" MO disk. I thought I had a copy but couldn't get mine to boot off it. I tried to make a new one to no avail... I gave up for the sake of time. But I have seen it running that way and it does work good. Only limitation is 640MB and above goes from a 512 byte per sector to 2048 byte per sector... Which I don't think NeXTStep knows or likes playing with, at-least for older versions... So you may be limited to only 128MB and 230MB disks.

 

[bear]

Since my post was 10 years ago, I don't recall if the problem was ever solved or not. At any rate, I haven't received any other requests. I do recall contacting a NeXT-fanboi friend only to find that he'd gone the hard disk upgrade route. That MO drive as the sole mass storage device was a "what the heck were they thinking?" thing for me.

Well, what they were thinking was, since they were still only selling into academic accounts, that you could show up with your MO cart in a room full of NeXTs and instantly make any one of them "your" NeXT.

A not unreasonable idea on the surface, though immediately run afoul of the four pass MO write cycle on a system with a need for demand paged virtual memory. Their first take at offering NeXTs with hard drives in them were just ~40MB units solely for holding the pagefile. That didn't last long either.

 

[stepleton]

Also tried a few other things as you suggested stepleton, and no the `c` or `h` (as someone else suggested trying) partitions does not work to capture the entire MO disk `od` devices

Good to know. I'm sorry this didn't work.

As a last-ditch effort --- a while ago I had to use a NeXT to dump SCSI disks that were bigger than 2 GB. (It was the only SCSI-capable machine I had available, and I was just netcatting the disk contents onto a modern computer rather than trying to store them locally.)

I found that dd would fail at int32 boundaries, but I discovered that there was a separate SCSI I/O facility in NeXTstep that I could call with a homemade program to pull data off of the disk block-by-block. Naturally this program was NeXT-specific, but that was fine for me.

Perhaps there is a similar low-level I/O facility for the MO disk, and a similar strategy would work there for reading off the blocks you need.

Congratulations on repairing your MO drive. It's a TODO item for me (an early recap attempt failed many years ago, and now that my skills have improved since then, I need to try to make a proper repair).

 

[bear]

I just got a Canon Diskfile 5001S off ebay... I can't recall if anyone has tried a single sided NeXT disk in one of those, but it should be the same logical format AFAIK?
I'll have to remember to post back here on what I can do with the Canon Diskfile unless someone already knows it works, or doesn't work!

Can confirm Canon Diskfile 5001S will not read NeXT format cartridges. Because the NeXT OD interface is not "intelligent" it has the same kind of problem as ST412 type fixed disks; the embedded controller in the 5001S doesn't know the low level disk format of the NeXT controller.

 

[NeXT]

Will it however format NeXT cartridges to it's "own" format?