created 21.01.2015, last changes: 05.02.2019 ps

>>> UsbWidEx - ProFile/Widget Debugger <<<

WidEx was the name of a tool Apple's Disk group used to format, debug and troubleshoot their Widget hard drives. It was written in Apple /// Pascal, somewhere in 1984. UsbWidEx is a modern representation of this tool. It is a stand-alone system based on a Renesas R8C/34 16 bit microcontroller, which connects to a PC or Mac via USB. A virtual COM port is emulated, so that any terminal program can be used to control it. UsbWidEx can be used to read or write single data blocks, to create backup images of a whole disk and write them back, and to send diagnostic messages to the drive controller and retrieve status information. If your drive tells you that it does't work anymore (by keeping its Ready light off), this tool is what you need to see what's going on. And on the lowest level, you can talk directly to the servo board and move the heads around the disk.

Some examples how this looks like can be found here.

Close-up of the UsbWidEx module (left image) and the whole setup required to debug a ProFile drive (right image).
UsbWidEx module Debugging a ProFile

Connecting a Hard Drive

ProFile and Widget drives are connected to their host by way of a parallel interface. A more detailed description of this interface is given in my IDEfile article. While IDEfile simulates the device side, UsbWidEx recreates the host interface, i.e. emulates a Lisa or an Apple /// with parallel interface card running special test software.

Any hard drive system consists of two parts: a controller board and the drive itself. The controller board acts as a link between the host and the drive. It gets commands like "give me block number 0x002F" from the host and translates them into the signals necessary to move the heads over the desired track, pick up the data stream, extract the requested data bytes, and pass them over to the host. The controller board may be physically integrated into the drive, or it may be a separate module. It must not be confused with the host interface inside the computer. MFM, RLL and ESDI drives have separate controller boards, IDE, SATA and SCSI have them embedded into the drive's PCB.

Both ProFile and Widget have separate controller boards. The ProFile controller is sitting on the power supply cage, next to the Seagate ST-506/9 HDA. This drive unit is rather dumb, it just contains the amplifier circuits required to read or write data and a stepper motor to move the heads. Though it bears the name "ST-506", its mechanism is not identical to a generic ST-506 MFM drive. For some reason nobody knows Apple requested a special stepper motor with double resolution. With a standard drive mechanism, ProFile would use only every 2nd track and the heads would bang into their endstop after 77 cylinders. Fortunately the much more common ST-412 is a fine replacement -- it has 306 cylinders. Skipping every second one leaves us the 153 we need.

Looking at a Widget drive, you see five PCBs surrounding the HDA. Four of them belong to the drive itself, the fifth located on the top is the controller board. It is connected to the drive with a 40 pin flat cable. Widget's head positioning system is much more sophisticated -- it is a closed-loop servo with optical coarse positioning and automatic track following. The controller just requests a seek, and the servo takes care of the rest. Controller and servo communicate via a serial line at 57600 bps.

UsbWidEx has two target connectors: one is for the ProFile/Widget bus, the other connects directly to a Widget servo board. Only one of them should be used at the same time. The Servo connector is used for the Widget servo debugger function. All other functions use the ProFile bus connector.

UsbWidEx pinout

ProFile has a female Sub-D25 connector, while the Widgets use a 26pin header. The pinout of both connector variants is the same. Build a cable with two pin headers to test Widgets, and a second one with one header and a crimped Sub-D25 male connector for the ProFiles. The outermost wire (pin 26) is not used with the Sub-D25 connector and can be removed. These cables should not be longer than necessary. 50cm is good, up to a meter should work.

Connecting to the servo board is more difficult. UsbWidEx is attached directly to the card edge connector of the Widget motherboard, and you have to provide power to the drive as well. In a similar way, the Nisha and RO522 drives used inside the Macintosh HD20 can be accessed, too.

signal from servo connector pin to Widget Motherboard pin to Nisha / Rodime pin
ServoIn 3 (TxD output) 19 17
ServoOut 5 (RxD input) 17 15
ServoErr 7 (input) 26 23
ServoRdy 9 (input) 22 21
SioRdy 6 (input) 21 19
-ServoRst 8 (output) 28 18
Gnd 1 and 10 2..20 (all even pins), 40 2, 4, 6, 26
+5 V 35, 36, 37, 38 8, 10
+12 V 33, 34 20, 22
-12 V 31, 32 24
+12 V for motor 39 25

You can use the same power supply for analog +12 V and motor supply, but use separate cables and connect them at the power supply.

Note: To keep the drive heads from moving around during transport, the actuator gets blocked by a solenoid brake when power is removed. Issue a servo reset pulse after the drive has come to full speed (after approximately 20 seconds) to release the HDA brake. When debugging is finished, park the heads before turning off the power! This ensures the brake will clamp them in the correct position.

UsbWidEx connected to the Widget controller (left image) and directly to the sevo board (right image).
connected to controller connected to servo

Hardware Design

The hardware consists of two parts: a generic PCB with the R8C microcontroller and USB interface, and a piece of breadboard that holds the remaining components. As speed does not matter here, the whole interface protocol is carried out in software. All lines from the ProFile connector are buffered and routed to microcontroller pins. This results in a very simple schematic (click on the image for a pdf version):

UsbWidEx schematic diagram

A 74LS245 bus driver is used to buffer the data bus PD0..7, which is driven by the R8C/34 port P0. These lines are bi-directional, therefore their direction can be set with pin P6.7. A second 74LS245 driver is used for the status signals. Except for /PBsy all these signals are generated by the host. Their direction can be swapped to emulate a device (by setting pin P1.3 low), but this is not used at the moment.

The servo interface has two output and four input lines, therefore a 74LS367 is used as a buffer. These parts can be substituted with almost anything that is able to drive a couple of TTL loads. However, classic 'LS are recommended here because they are more robust against ESD, latchup and other misuse than their modern 'HCT or 'LVC counterparts.

UsbWidEx is a bus-powered USB 2.0 device. It has to ask the host computer for permission before drawing more than 100 mA from the USB connector. Today nobody cares about this, but this is what the spec says. Therefore the I/O buffers can be disabled by the microcontroller. They are off when P1.2 high or open.

Finally, there is a two-color indicator lamp that glows green when the I/O power is applied, and red when P1.6 is set low.

The most magic part of the circuit is in the bottom right of the schematic: the R8C module. This is a small PCB that holds a Renesas R8C/34 microcontroller (R5F21348GJFP or similar type) with its associated components and a FTDI232R USB-to-UART bridge. Here is the schematic diagram of this module. The pictures below give some impression of the mechanical construction.

Mechanical construction. The R8C PCB is plugged into a piece of vero board with the interface circuits.
inside top view UsbWidEx disassembled

To implement the firmware, the KPIT GNUM16C v11.01 Windows Tool Chain has been used. KPIT has dropped the support for the M16C/R8C family, but the compiler is still available in their toolchain archive section.

Build your own?

I have designed UsbWidEx because I needed a tool to troubleshoot my non-working drives. It has been revised many times, and one after another all necessary functions have been added. It may still change in the future, in case I dislike anything or require something new. For many years, everything I knew about ProFile and Widget was based on firmware disassembly and reverse engineering. This yielded enough information to design IDEfile in 2004. Recently, a lot of documents from Apple's disk group have appeared. These have been scanned and can be viewed at bitsavers.org. This bunch of information helped me to correct and complete the command set.

UsbWidEx is no commercial product and I do not provide any kits or assembled modules. However, its hardware is no rocket science and someone capable of SMD soldering should be able to build his (or her) own. Partlists, schematic diagram and the firmware code file can be downloaded below.

a) Renesas R8C module:

For UsbWidEx, the R8C module is operated in host-powered mode. The power is supplied from the USB port, which means L1 has to be fitted. Voltage regulator IC2 and its surrounding components are not required. Use an 18.432 MHz resonator.

b) the UsbWidEx-specific periphery. This has been build on a prototype board, so there is no PCB layout avalable:

Having assembled the R8C module, first make sure that the USB bridge is working. Open the solder jumpers SJ1 and SJ2 and short pin 1 of SJ1 to pin 1 of SJ2. This connects RxD of the FTDI chipto TxD so that everything you type in the terminal window on your PC is looped back. Install the Virtual Com Port Driver from the FTDI website and connect the R8C module to your PC. In your system settings, you should see a new COM port. Open a terminal window and select this port. Set the communication parameters to 57k6, 8 data bits, 1 or 2 stop bits, no parity. Turn local echo off. Type some text to check if this is working properly. Then remove the short on the R8C board and close both solder jumpers. Now the microcontroller is connected to your serial port.

Use the Renesas Flash Development Toolkit (FDT) software to program the microcontroller. The current version is 4.09, later ones should work, too. Download it from the Reneas website and install the package. Close your terminal program and start the FDT Basic tool.

Select "new settings" from the menu. In the device selection dialog, enter "r5f21348e" (or which type you are using). Select the device and click "next". Select UsbWidEx' COM port and click "next". Remove the check mark at "Use Default" and select a speed of 115200. Click "next". Check "Readback Verification" and click "finish".

Now disconnect the USB cable and short the pins "MODE" and "Gnd" at the programming connector JP4. Reconnect the board. In the FDT window, check "User/Data Area" and select the file with the UsbWidEx firmware:

Click "Program Flash" to load the firmware into the microcontroller. Exit FDT and disconnect the USB cable. Remove the short from the programming connector.

If you own a Renesas E8a debugger, you can use this to flash the firmware -- it is significantly faster than the serial bootstrap mode.

Reconnect the USB cable and start your terminal program (remember: 57600-8-1). The two-color LED on the UsbWidEx board should glow red. Open the COM port and press any key on the terminal window. The LED should turn off and a signon message should appear:

UsbWidEx --- ProFile/Widget Debugger V1.02
 (c) Patrick Schaefer, 2012-14

  1 - Backup drive to file
  2 - Restore drive from file
  3 - Low-level format
  4 - Surface scan
  5 - ProFile 5M debugger
  6 - ProFile 10M debugger
  7 - Widget controller debugger
  8 - Widget servo debugger
  9 - Interface line test

Select function: 

Now press "9" to select the Interface line test and check all pins of the ProFile Bus and Servo connectors.

Using the Tester

UsbWidEx uses a FTDI FTDI232R serial-to-USB bridge chip, so from the host computer's point of view it looks like a serial port and gets a COM number assigned (e.g. COM8). Start your favourite terminal program (for Windows TeraTerm works fine), the RS-232 settings are 57600-8-1, no handshake.

Press any key to get the main menu:

UsbWidEx --- ProFile/Widget Debugger V1.02
 (c) Patrick Schaefer, 2012-14

  1 - Backup drive to file
  2 - Restore drive from file
  3 - Low-level format
  4 - Surface scan
  5 - ProFile 5M debugger
  6 - ProFile 10M debugger
  7 - Widget controller debugger
  8 - Widget servo debugger
  9 - Interface line test

Select function: 

Type the appropriate number to select a function.

1 - Backup drive to file

This function allows you to create a backup file on your PC from a ProFile drive connected to UsbWidEx. There are three options than can be selected:

To create an image that can be copied directly into an IDEfile volume, select options "YNN". To get a BLU file, select "NYN" for a Widget and "NYY" for a ProFile.

UsbWidEx now reads each block from the drive and sends it to the host PC using the XMODEM protocol (128 byte records, checksum and CRC supported). This takes around 57 minutes for a 5 MB volume sent with 1024 bytes per block. The resulting file sizes are:

   5 MB volume  10 MB volume
 532 byte/block   5 175 296 (0:30)   10 350 592 (1:03) 
 with BLU header   5 175 828  10 351 656
 1024 byte/block    9 961 472 (0:57)   19 922 944 (1:55) 
 with BLU header    9 962 496  19 924 992

In case a block is unreadable, it is replaced by a dummy block. This consists of the block number (in hex), a message "THIS BLOCK WAS UNREADABLE ", and is padded with spaces (0x20). Of course, before a block is considered unreadable a couple of retries are done.

After the transfer is completed, the number of faults is reported.

2 - Restore drive from file

Use this to write an image file on your PC back to a ProFile drive connected to UsbWidEx. You have to specify the image format -- 1024 or 532 bytes, BLU header or not, 5:1 interleaving or not. In case you don't remember the image settings, use a hex editor (like HxD) to look into the file. If the first line starts with "PROFILE" or "WIDGET", this is likely to be a BLU header. Otherwise there might be an "AAAA" signature in the first line, which identifies a Lisa boot block, Now look where the next block starts: at 0x214 or at 0x400. This gives you the block size -- 532 or 1024 bytes.

Now the image file has to be sent in XMODEM format (128 bytes per record, Checksum or CRC). In case the file is smaller than the drive capacity, only the blocks given in the file are written. The rest of the drive remains unchanged. If the image is bigger than the drive, everything after the last useable block is ignored.

3 - Low-level format

During low-level format, initial data structures are generated on the magnetic disks. All tracks are erased, sector marks and headers are written, and all blocks are filled with a test pattern. After that, a surface scan is done and the spare tables for bad block management are initialized.

Note: I do not own a ProFile 10M, therefore this LLF procedure has not been tested yet. It has been implemented according to my disassembly of the P10LLF firmware revision D6.06.

The drive type is detected automatically and the appropriate algorithm is chosen. ProFile drives require diagnostic firmware to be fitted. For the ProFile 5M algorithm, P5LLF revision D3.11 is required, ProFile 10M needs P10LLF rev. D6.06. Other revisions may work but have not been tested. Widgets can be formatted with their stock firmware. The latest revision 1-A.4.5 (341-0289-D) is recommended.

After formatting, re-install the R/W firmware and run the read/write/read test a few times. This will detect any bad blocks and let the drive enter them into its spare table.

4 - Surface scan

Four different tests are provided:

  1. linear read test. Reads each block, one after another. During reading, ProFile checks its internal CRC. If there is a mismatch, the block is re-read 100 times. If more than 20% of these reads fail, the block is rewritten. If rewriting fails, the block is spared. In case all of these 100 retries fail, up to another 90 retries are made. A block that cannot be recovered within these 191 attempts is entered into the Bad Block table.

  2. butterfly read test. Reads each block, but alternately one track from the center and one from the perimeter of the drive. This test puts more stress on the head positioning mechanim than the linear read test.

  3. read/write/read test. Reads each block, then overwrites each block with a test pattern and CRC, then re-reads each block and check for CRC match. The first run gives an overview about the current status of the drive. Weak (status 08) or bad (status 09) blocks are listed and bad blocks are entered into the Bad Block table. In the second run, all blocks are filled with a 55 5A AA test pattern and a CRC. ProFile will automatically spare all blocks with media defects or damaged headers. If you see too many faults in this run, abort here and low-level format the drive. The last run reads back all blocks and checks the previously written CRC. You should not see any errors here. In case you do, there might be a weak block. Re-run this test. A large number of faults in the last run (or after the R/W/R test has been repeated a couple of times) indicate a defective analog board or contamination inside the HDA assembly. CRC errors indicate a defective controller board or a bad (or too long) cable. The two resistor networks at position U1, U2 on the controller board should be 100 Ohm. Not 47 Ohm and not 470.

    This test will destroy any existing data on the drive.

  4. zero all blocks. Fills each block with 532 zeros. This test will destroy any existing data on the drive.

During the tests, press any key to abort.

5 - ProFile 5M debugger

From this menu you can read single blocks from your drive, modify their contents, and write them back. Besides that, diagnostic commands could be sent to a 5MB Profile with diagnostic firmware installed. ProFile 10M has a different diagnostic command set, so use the 10M ProFile Debugger for these drives.

Note that all parameter values have to be given as hex numbers. Leading zeros may be skipped, but parameters which are not separated by a comma have to be specified with the required number of digits. E.g. "r xxxx,rrtt" with xxxx = 0x002E, rr = 0x64 and tt = 1 has to be written as "r 2E,6401".

6 - ProFile 10M debugger

From this menu you can send diagnostic commands to a 10MB ProFile. ProFile 10M has a completely different diagnostic command set, therefore these commands will not work with a 5MB unit.

Note that all parameter values have to be given as hex numbers. Leading zeros may be skipped, but parameters which are not separated by a comma have to be specified with the required number of digits. E.g. "r xxxx,rrtt" with xxxx = 0x002E, rr = 0x064 and tt = 0x01 has to be written as "r 2E,6401".

7 - Widget controller debugger

From this menu you can read single blocks from your drive, modify their contents, and write them back. Besides that, diagnostic commands could be sent to a Widget. UsbWidEx talks to the controller board, which controls the R/W electronics and the servo system inside the drive.

Note that all parameter values have to be given as hex numbers. Leading zeros may be skipped, but parameters which are not separated by a comma have to be specified with the required number of digits. E.g. "r xxxx,rrtt" with xxxx = 0x002E, rr = 0x064 and tt = 0x01 has to be written as "r 2E,6401".

8 - Widget servo debugger

These commands are intended to talk directly to the Widget servo board. All you need is the HDA assembly (mechanics) with motor control board, motherboard and servo board. Connection is made via the edge connector on the Widget motherboard. By default, the servo is accessed at 19200 bps.

Note that all parameter values have to be given as hex numbers. Leading zeros may be skipped, except for the "c" command where you have to write both digits of each command byte.

Apple Nisha and Rodime RO552, the two drive mechanisms used for Mac 128's HD20 drive ("Rene"), use the same command set. However, they communicate at 58593 bps. Use the "n" command to switch to 57600 bps -- this is close enough.

9 - Interface line test

Use these commands to check UsbWidEx itself, or to troubleshoot a Servo or Controller board by driving the signal lines manually. When the pin status is displayed ("i" command), every signal line is marked with a number or a letter. Use this hex digit to select the line you want to set or clear.

----> Here is a command reference sheet with a summary for daily use.

A few sample sessions

To get a better idea how these commands should be used, a couple of sample sessions are shown here. There were recorded from the terminal program window and some comments have been added to explain the commands sent to and the responses received from the drive.

And in case you want to take an even deeper dive into the internals of a Widget, here are few logic diagrams that show the timing of some drive operations.

UsbWidex is copyright (c) by Dr. Patrick Schäfer, 2014

Apple, Lisa, ProFile, Widget and the ProFile communications protocol are (c) by Apple Computer Inc.

----> Back to my home page


This page is hosted at John, a server of the Computer Club der RWTH Aachen e.V. Validated by HTML Validator (based on Tidy)