• Please review our updated Terms and Rules here

IBM ps/2 model 50

There is a later sequence that even starts using one byte of a 'reserved' field:

E9-06-00-00-00-06-01-30-00-36-00-00 = 30 01 06 00, MLC 'C81004', WD-3160S, 'C81004', '1990'

E9-06-00-00-02-06-01-30-00-36-00-00 = 30 01 06 02, MLC 'C81555', WD-380S, 'C72778'/'285010E', '1989'
More single-stepping will be needed, but I believe that the '36' in the "Reserved" field is just an ASCII-encoded analog of microcode version '0006' on the IBM ESDI controller - it just seems to match up.
 
This is the raw data from the IBM ESDI controller (https://www.ardent-tool.com/storage/ESDI.html) on the Model 60 and 80 - which I initially gained versioning by dumping the microcode ROM from the adapter directly. The results here are interesting in that the microcode version is prepared with ASCII encoding for display. The external ROM FRU is listed, with the internal FRU and date of the ROM:

'3x 30 30 30' Model 60/80 ESDI controller Series:

E9-06-00-00-32-30-30-30-00-00-00-00 = 30 30 30 32 ('0002'), 90X7399, 90X6853, 03 Feb 1987
E9-06-00-00-33-30-30-30-00-00-00-00 = 30 30 30 33 ('0003'), Likely 90X8635, Unknown, Unknown
E9-06-00-00-34-30-30-30-00-00-00-00 = 30 30 30 34 ('0004'), 15F6587, 15F6588, 07 Oct 1987
E9-06-00-00-35-30-30-30-00-00-00-00 = 30 30 30 35 ('0005'), 15F6807, 15F6809, 13 Jan 1988
E9-06-00-00-36-30-30-30-00-00-00-00 = 30 30 30 36 ('0006'), Likely 91F7430, Unknown, Unknown
E9-06-00-00-37-30-30-30-00-00-00-00 = 30 30 30 37 ('0007'), 04G3759, 04G3761, 05 Apr 1991
 
So, it sounds like the 60MB drive that I have is not really a ESDI drive, but merely a drive with an interface on it that appears to be ESDI, is that correct? How does it know the drive parameters and size? Are these things hardcoded into the controller or did it get this information off the drive? Were the drives prepared using the same controller board, or ahead of time before being attached to it? Could there be some undocumented commands that the board accepts? Is there a cpu on the board? Is its firmware known or downloaded anywhere? Just more questions I am pondering!
 
So, it sounds like the 60MB drive that I have is not really a ESDI drive, but merely a drive with an interface on it that appears to be ESDI, is that correct? How does it know the drive parameters and size? Are these things hardcoded into the controller or did it get this information off the drive? Were the drives prepared using the same controller board, or ahead of time before being attached to it? Could there be some undocumented commands that the board accepts? Is there a cpu on the board? Is its firmware known or downloaded anywhere? Just more questions I am pondering!
On later DBA-ESDI drives, I see an Intel 80C196KB microcontroller - and I will start doing photos of the controller PCB. All of the IBM drives, with the exception of the WD-336R (which is listed as an 'ST506-"like"' with 'Type 33' drive parameters in documentation) are 'ESDI-"like". The DBA-ESDI drive parameters are encoded on the drive itself. Yes, there could be undocumented commands - I've only recently focused on what the microcode levels are.
 
I can't shake the thought that they could have been prepared from raw using their own controller and there could be a way to do the same if only it were known. My theory is that one drive I have that somewha works (the one above that refuses to format) has a bad primary defect list and that is the reason is fails the format command. If there were just a way to clear that out maybe it would format.
 
I can't shake the thought that they could have been prepared from raw using their own controller and there could be a way to do the same if only it were known. My theory is that one drive I have that somewha works (the one above that refuses to format) has a bad primary defect list and that is the reason is fails the format command. If there were just a way to clear that out maybe it would format.
There is the 10-pin header close to the MPU on all (including the WD-336R), but I don't know what communication / programming / preparation it would do from an external device. If the drive parameters can't be read, the drive also fails (I had one drive with 'stiction' that now spins up, but CTRL-A can't complete for the defect list too). Different capacity drives have the same controller board and firmware levels - if only there was static RAM or some other way that had been used to save away the parameters and defect list.

At the same time, I see that dynamic capacity as easier to mimick in the modern age...
 
This controller on it started out a bit flaky with a 10490 error or something like this (maybe I posted it earlier in this thread), but then it started working to where it would at least function in terms of reading/writing most sectors just fine. i think it has about 1-1.5% bad sectors on it, but they are all spread out and there are enough of them that it is tough to find a range where you could fit a fat table without errors. I was successful in making a 2MB partition on it and formatting it, it has bad sectors, but none during the FATs so it works.
 
I hate to resort to this stereotyped Hail Mary, but if the “bad sectors” are so evenly distributed I wonder if it’s remotely possible renewing some analog component (bad caps!, etc) in a sense amplifier or something could ”fix” signal integrity issues that are coming across as bad sectors. Or it could legit be the platters flaking apart, in the long view these things were kind of built to be disposable.
 
It isn't a perfect distribution, but in scandisk it looked like every 20 or so. I can try to replace the caps and see it is makes any difference.
 
Realistically it’s probably more likely to be a failing head or something, but the distribution looks weird because of how the drive is doing translation. But who knows.
 
I wondered about that, but it isn't perfectly symmetrical. I suppose no loss in trying to replace some caps and see if the issue changes. It is always the same blocks though.
 
So, it sounds like the 60MB drive that I have is not really a ESDI drive, but merely a drive with an interface on it that appears to be ESDI, is that correct? How does it know the drive parameters and size? Are these things hardcoded into the controller or did it get this information off the drive? Were the drives prepared using the same controller board, or ahead of time before being attached to it? Could there be some undocumented commands that the board accepts? Is there a cpu on the board? Is its firmware known or downloaded anywhere? Just more questions I am pondering!
The controller boards (1987-1989) on the WDL-330R (30Mb, using the "PASCAL4" PCB), WD-387[T] (60Mb), and WD-3158 (120Mb) DBA-ESDI drives all use an 80C31 microcontroller just like the Model 60/80 ESDI adapter. These are the DBA-ESDI drives that have the microcode version sequence ' 32 02 00 xx' (I have observed 19, 20, 22 24, and 50h in 'xx'). Notice that the capacities double.

In 1989 and 1990, the 40Mb (WDL-40S), 80Mb (WD-380S), and 160Mb (WD-3160S) DBA-ESDI drives have a shared controller board with an 80C196KB microcontroller. These are the microcode sequence '30 01 06 xx' (I have observed '00' - '02' for 'xx'. In one of the "unused" fields offset after the microcode field, there is also a value of '36' returned. Notice that these capacities are also doubled.

As discussed previously, the WD-336RT (30Mb) differs in that it is 'ST506-"like"'. There are also the Seagate drives ST-1381 (30Mb) and ST-1771 (60Mb) that have their own components without a discernable MCU. The true ESDI drives for the Model 60 and 80 were 70Mb, 115Mb, and 340Mb.
 
Hi all -- I'm just going to repost some info that I posted on the MFM emulator discussion forum (the MFM HDD emulator project -- which is awesome -- is here: https://www.pdp8online.com/mfm/mfm.shtml)

The problem with MFM drives, well, hey, yeah they all die. Soooo... I had been wondering about using a hardware MFM drive emulator on a microchannel machine. Got it working yesterday (yay!). I know there are alternatives (MCA scsi adapters, ZZXIO's great McIDE product, etc) but this one is also just fun, and I suspect MCA MFM Controller cards might be found on ebay not too expensive-ly? I haven't looked recently. That said, building the MFM emulator isn't really cheap (you can also buy a prebuilt one from these folks (no affiliation): https://decromancer.ca/mfm-emulator) but hey -- inexpensive and MCA/PS2 don't really go together :)

-- MFM Discussion Post below --

Hi all -- not sure if this was already accomplished, but I was forever curious as to whether I could get the emulator to work with any of my microchannel PS/2 machines. I had acquired a model 80 with an mfm controller card and dead drive, and my model 50 came with a (working-ish) 20mb mfm drive and the model 50 mfm controller (both cards are equivalent, see https://www.ardent-tool.com/storage/MFM.html), specifically the "late model" mfm adapter, IBM PN 90X8643.)

ANYWAY, long story short, I was able to eventually get it to work in my model 50 (I assume this will also work in the model 80). Using the 90X8643 card and the two cables that came in my model 80 (a 34 pin control cable with two drive connectors and a twist, much like an ibm floppy cable -- though I'm not sure if the twist is in the same location) and a 20 pin data cable, I connected to the emulator using the card edge connectors, set the drive select jumpers to 2 (e.g, DS1, e.g., second position in the jumper block of 1-4) and (CRUCIALLY) removed the resistor pack from RN1. There is a discussion on the ibm cabling on the page link above).

I set up a drive on the mfm with 615 cylinders and 4 heads (20mb) and set the PS2 bios to type 2 (a full listing of the IBM types is here (I think it's pretty accurate): https://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes-3.html

At this point the PS2 hated the drive. So I saved the changes to setup, rebooted back in, and pressed CTRL-A on the main menu to get to the low level format option. I chose that, and the PS2 complained that the drive wasn't ibm. So i pressed f3 and it asked if I wanted to "prepare it" and I said yes. It hated that too, so I pressed F3 AGAIN, and then it asked if I wanted to FACTORY prepare it, so I said yes, and away it went :)

This low-level format takes quite a long time, especially with bigger drives, so make sure you have other things to do.

After that, I was able to restart the machine (I had to actually power it down, not just reboot) and then installed dos 7 after using dos 7 fdisk to create a partition.

I was also alble to get a type 22 (30mb), type 4 (60mb) and a type 9 (112mb) drive working. Sometimes it was a bit gremliny and fdisk would fail with "can't read fixed disk". Playing with the arbitration level setting of the mfm controller card in the ps2 setup and powering off (rather than rebooting) seemed to do it, though I haven't yet 100% established the pattern. I think perhaps there's a bug in the ibm code somewhere, not sure.

ANYWAY, with stacker installed on the 112mb drive, I've got a nice model 50 with an mfm drive and a 250mb or so C partition. Happy! The emulator works a treat.

I also played around a bit with speedstor 6.5 when I was having the gremlins, but though it worked it didn't seem necessary, as the IBM setup low level format was always able to complete successfully. speedstor can be found on minuszerodegrees.net

Best to all, Alison
 
Back
Top