MV/Wiki

A Generation Ago

Replacing the MV/2500 DC System Disk

Background

When I received the MV/2500 it appeared that one of the two disks installed was not spinning up and the other (primary) one was operational but reporting many ‘soft errors’. Both disks were removed from the MV/2500 and I attached the partially working disk to a PC to try to extract as much data as possible from the disk with the http://www.gnu.org/software/ddrescue/ program. It remains to be seen if that backup is of any use. Later, upon attempting to run FIXUP on the disk, it failed entirely.

Replacement Options

DG had a reputation for locking-in customers by ‘vendorizing’ any off-the-shelf peripherals so they could only be replaced by DG-badged versions; this was commonplace in the industry before the advent of ‘open’ systems.

There appeared to be three replacement options:

  1. Source a direct DG vendorized replacement
  2. Attempt to re-ROM an equivalent OEM disk
  3. Use a modern disk replacement device

Option one seemed the least likely to be feasible - these disks rarely come on to the market, and when they do it is usually in the US. Shipping to the UK would be expensive and I doubt if the disk would survive intact.

It had been suggested to me that merely swapping the ROM from the DG-ized Micropolis drive into an exactly equivalent original drive might work. This might be an interesting avenue to pursue in the future but availability of even these disks is limited and the longevity of any such disk would be questionable.

As far as I could discover at the time (January 2015) no-one had yet attempted to replace this type of disk with a modern substitute, however, this operation is common amongst vintage sampler/synthesizer hobbyists and 80’s microcomputer collectors. After a little research I decided to approach Michael McMaster, the developer of the SCSI2SD project, to discuss the feasibility of using SCSI2SD to replace the “vendorized” SCSI-I disks in my MV/2500.

Michael was very encouraging so I placed an order for a fully constructed board and waited for it to arrive from the other side of the world. It was clear that it would not work out-of-the-box with the MV, but Michael was happy to help me attempt to emulate the vendorized behaviour of the original drive.

SCSI2SD

SCSI2SD emulates SCSI I and II hard drives using micro-SD cards as a storage medium. With the version 4 firmware up to four drives can be emulated by a single device which is configured via a USB interface from either a Windows(tm) or Linux PC.

After trying the SCSI2SD card on my test rig I connected it to the MV/2500. Then followed a short iterative process during which I captured the SCSI activity on startup failure and Michael sent new firmware to address unimplemented SCSI commands in the SCSI2SD firmware. See also Investigating the MV/2500DC System Disk

Bypassing Non-Critical Startup Errors

There is a key sequence which can be entered into the primitive boot environment on these DC-class machines to attempt to bypass non-critical errors during the self-test. The sequence is

 [BREAK]
 >NB[RETURN]
 >RP[RETURN]

Where the two greater-than symbols are printed by the machine. The NB command may not be echoed, but the RP one should be.

If successful the self-tests will continue after a few seconds. I spotted this a couple of years ago on a fellow DG restorer’s blog, I don’t know where - or even if - it is documented.

Settings

  • Primary disk must have SCSI ID 4 (not 0)
  • Secondary disk SCSI ID 0 (then 1 and 2)
  • Parity Enabled
  • Sector size: Standard 512 bytes
  • Sector count: 631053
  • Vendor and Product ID must be copied faithfully from [[hardware:mv2500sysdiskinvestigation|Investigating the MV/2500DC System Disk]]
  • Revision: DG02
  • I don’t think the Serial Number matters, but I copied one from the original disk.

Operation

On the 12th February 2015 I was finally able to boot up the MV/2500 and install and run AOS/VS!

As of March 2015 I still have to load the microcode from tape - it will not install (I think that is because it is diagnostic microcode, not the standard SCP/System Media distribution). Once that is done the system runs normally - except more quietly and using less power than it would with original full-height 5.25 inch SCSI disks. I also now have the intriguing possibility of setting up four emulated disks on a single SCSI2SD card, maybe each larger than was available when the machine was in production.