My personal ramblings from stomping out random bugs


Yvan Janssens


Demystifying AS/400 DASD

Yvan Janssens  March 11 2019 08:11:11 AM

There seem to be quite a few misconceptions about AS/400 hard drives, commonly referred to as DASD (directly attached storage device). It is commonly known that only IBM-supplied DASD work, and typically only the FRUs listed. The big question though is "why is this the case?".

Spinning disks die eventually. At the moment, generic SCSI disks are fairly commonly available, however, the FRUs to keep old AS/400 alive for hobbyist and archival purposes are becoming more and more scarce, with the supply eventually drying up.

Distinction between models
Some of the information here is model-dependant, so a distinction is made between the following systems:

CISC/IMPI-based AS/400s
These are the old pre-PowerPC-based AS/400s. They will typically run OS revisions up and until V3R2. They operate on a complex interaction of microcode on top of a more generic architecture and several subsystems, not unlike the channel architecture on it's larger brethren. A more thorough description on how these machines work is a future project. Example model numbers are 9401-P03 or 9401-P02

Early PowerPC-based AS/400
PowerPC-based AS/400s were gradually introduced to replace the earlier CISC/IMPI-based models. Typically, the high end models were replaced first. PowerPC brought a massive speed boost to the AS/400 product line, however, it's real potential was only realised later. Early OS revisions (e.g. V3R6) were direct ports of the CISC/IMPI-based code and were quite slow. A thorough rewrite of the kernel in V4 addressed most of these issues. Early PPC-based AS/400s would typically have been able to run V3R6 or later. Example models are e.g. the 9403-53X. I am still not convinced this is due to OS revision or hardware revision.

PowerPC-based AS/400
These are the models typically supplied with OS/400 V4 or later, all the way up until the Power5-based models (P5-based models are a special case though, but this is not relevant for DASD). Example models are 9406-170 or 9406-250

520, 522 and 512 bytes per sector
It is currently commonly known that the AS/400 uses an odd sector size. However, the information that can be found online is quite contradictory - some sources quote 520, some 522. Some sources quote that 522 is only used in systems with a RAID controller. Based on my observations and tests this is not true - the difference does not lie in the use of a RAID controller or not, but in the type of AS/400. PowerPC-based AS/400s will typically have 522 bytes per sector, and CISC/IMPI-based AS/400s will have 520 bytes per sector. There are a few edge cases though, especially in early PowerPC-based AS/400s - if the DASD have been migrated from a CISC/IMPI-based machine they would not typically be re-formatted on those early machines on the OS/revisions at the time.

So, TL;DR:
  • Standard SCSI disks: 512 bytes per sector
  • CISC/IMPI-based AS/400: 520 bytes per sector
  • Early PowerPC-based AS/400: 520 or 522 bytes per sector
  • PowerPC-based AS/400s: 522 bytes per sector.

Custom VPD

This would be obvious to anyone with any idea on how SCSI disks work, but the vital product data on AS/400 DASD contains entries verified by the firmware. This VPD typically contains serial number, disk type (e.g. 6713) and serial number. When installing SLIC on a PowerPC-based AS/400, this is verified to contain the expected data. Another quirk to note is that the OS does not (always) rely on SCSI READ CAPACITY commands to identify the size of the DASD. As a result, putting the VPD of a 6714 (~18GB) over a 70GB volume does not result in the drive being detected as a 70GB drive.

Magic commands

Another common misconceptions is that IBM uses proprietary commands to interact with the drive. This is actually not entirely true. There are however a few implementation based quirks that the OS relies on when dealing with drives.

SCSI FORMAT implementation

The SCSI FORMAT implementation needs to be accurate. The OS relies on the disks being formatted using a SCSI FORMAT command. OS/400 technically doesn't have a file system (more about that will be documented in another write-up), and the way it deals with data storage requires hard drives to be completely empty upon first use. If the SCSI FORMAT implementation doesn't fill the drive with the specified pattern (not all drives implement this properly), the OS installer will crash/hang because it tries to read a few sectors to verify if formatting succeeded (it does not just trust the status code returned by the SCSI FORMAT command).


To optimise disk read and writes, OS/400 heavily relies on SKIP READ and SKIP WRITE. These commands need to be implemented and need to be implemented properly. More information about this can be found on The reason why OS/400 relies on this is another story, closely related to the way the file system (or lack thereof) works.


That's it really. The only things which makes an AS/400 DASD special are:
  • custom VPD
  • 520/522 byte sector size based on model
  • SCSI FORMAT being implemented properly
  • SKIP READ and SKIP WRITE being implemented properly

I hope this helps some people troubleshooting their failing hard drives.

Getting files onto my PS/2 50Z

Yvan Janssens  March 10 2019 02:03:11 PM

The usual problem most people face with old PCs is the dreaded file transfer challenge. I am aware that USB floppy drives like
these exist, however, they're less than ideal. They're okay for transferring individual files, but they often mess up when you try to write disk images to them. Writing the Windows 95 DMF floppies with those is completely out of the question even.

I've stumbled upon FastLynx by accident while trying to solve another issue. It works really well to transfer files using a null modem serial cable to a DOS machine, and allows you to use a 'bootstrap mode' to copy the client to your target device without being able to write any floppies. It also works reasonably well on Windows 10 with USB to Serial adapters. There's a free demo available which is enough to transfer a handful of files (you would probably want to ZIP them anyway and run them through PKUNZIP on the target device to reduce file size since RS232 is quite slow).

Download link for demo (in case the original website disappears): fx33demo.exe

Fixing my PS/2 Model 50Z floppy drive

Yvan Janssens  March 10 2019 01:35:13 PM
Recently I acquired a second PS/2 Model 50 (I already had a Model 50Z), which was listed on eBay for spares. The machine was indeed dead (well, beyond reasonable repairs, but that's another story), but it did came with a bunch of parts I was looking for to use on my main PS/2:
  • 386 upgrade CPU
  • More memory
  • Spare ESDI drive (you always need spares of these)
It also had a FDD. The case was badly damaged so there wasn't much to recover from that, however, the front plate for the floppy drive was in good shape. As a result, I decided to add this drive to my main PS/2 to have a second floppy drive (which is always useful, especially when dealing with reference diskettes). However, the drive from the other PS/2 didn't seem to work. It got detected, but it didn't seem to be able to read or write floppies. Last weekend I decided to take it apart to give it a good clean and inspect for potential failures, and I noticed this switch:

Image:Fixing my PS/2 Model 50Z floppy drive
Sony MP-F77W drive, IBM FRU 72X8523, IBM model MFD-77W

This switch has four positions, and I discovered the following outcomes:

Position 0: not working; machine hangs during IPL and doesn't even boot the reference diskette from the first drive (which is a known working drive)

Position 1: drive gets detected, failure mode as described above

Position 2: drive works as expected.

I successfully wrote a floppy using this drive and read it in the other drive and vice-versa.

Recent Entries

    Recent Comments