• Please review our updated Terms and Rules here

IBM ps/2 model 50

I find a little bit of humor in that they build a "format prepare" into the controller that has to be called before the format command as a safety, then they don't bother to do the same with the interrupt call on the PC!

I've really gotten a lot further into the bios than I thought finding both the int13 table and also the int 13/1c subfunction table. Some functions have the same address and some do not. I'm going to try to get the device status after the failure in my fmt utility to see what it reveals too.

00,07 --> f000:4c14
01-05,12 --> f000:4e53
06 --> f000:4e51
08 --> f000:4e61 get comm compl status
09 --> f000:4e68 get dev stat
0a --> f000:4e6f get dev conf
0b --> f000:4e76 get adapt conf
0c --> f000:4e88 get pos info
0d --> f000:4e81
0e --> f000:4e8f translate rba to aba
0f --> f000:4e7f
10 --> f000:4e9c
11 --> f000:4ea7
 
Get command completion status codes show:

0A - diagnostic failure during formatting
0C - command completed with failure
05 - unrecoverable ecc error
 
alank2 said:
I find a little bit of humor in that they build a "format prepare" into the controller that has to be called before the format command as a safety, then they don't bother to do the same with the interrupt call on the PC!

I've really gotten a lot further into the bios than I thought finding both the int13 table and also the int 13/1c subfunction table. Some functions have the same address and some do not. I'm going to try to get the device status after the failure in my fmt utility to see what it reveals too.

00,07 --> f000:4c14
01-05,12 --> f000:4e53
06 --> f000:4e51
08 --> f000:4e61 get comm compl status
09 --> f000:4e68 get dev stat
0a --> f000:4e6f get dev conf
0b --> f000:4e76 get adapt conf
0c --> f000:4e88 get pos info
0d --> f000:4e81
0e --> f000:4e8f translate rba to aba
0f --> f000:4e7f
10 --> f000:4e9c
11 --> f000:4ea7
Click to expand...
I'm interested if 1C0Bh returns anything for a microcode level on an ESDI-"like" DBA-ESDI drive. Of course, at least the POS(3) returned by 1C0Ch will be different (the @DDFF.ADF has it as to whether the BIOS extension is enabled and at what address - DBA-ESDI doesn't have a ROM extension, and uses the @DF9F.ADF). Which "MCL" value is on the white label of your drives (there will also be labels or silkscreened microcode levels on the PCB as well)?
 
Chuck(G) said:
My Phoenix PS/2 reference only mentions ESDI in connection with AH=1A: Format ESDI disk...
Click to expand...
It's also interesting that there is an @DF9F.ADF version (for the IBM DBA-ESDI drives) from Phoenix/NCR - Despite NCR being linked closely to IBM and modifying some aspects to microchannel on their systems, I wasn't aware of them using the DBA-ESDI interface or a substition for it.
 
Do ESDI drives remap sectors at all after the formatting process? I've done a wipe of the drive and about 1% of the sectors return an error while trying to write them.
 
IBMMuseum here are the answers you asked for:

INT 13, AH=1Ch, Subfunction 08h
01 07 00 01 00 1b 00 00 00 00 00 00 00 00
INT 13, AH=1Ch, Subfunction 09h
08 03 00 00 00 1b
INT 13, AH=1Ch, Subfunction 0ah
09 06 0c 06 00 d0 01 00 ff 02 06 1b
INT 13, AH=1Ch, Subfunction 0bh
e9 06 00 00 19 00 02 32 00 00 00 00
INT 13, AH=1Ch, Subfunction 0ch
ea 05 df 9f 28 55 ff ff ff ff
 
I figured out why not test my format tool on the noisy 80mb, so I started it with a modifier code of 20 (0x14) which is what LLFORMAT does. It ran for a little maybe less than 1 minute and failed with:

0Dh invalid number of sectors on format (PS/2 hard disk)

Any thoughts on this? Is there some command that needs to be issued before the AH=1A format command? I've tried to trace LLFORMAT back a bit before that and I don't see anything.

Needless to say, I wouldn't use the esdifmt.exe utility above, it does not work currently (or maybe ever!).
 
Last edited:
alank2 said:
IBMMuseum here are the answers you asked for:

INT 13, AH=1Ch, Subfunction 08h
01 07 00 01 00 1b 00 00 00 00 00 00 00 00
INT 13, AH=1Ch, Subfunction 09h
08 03 00 00 00 1b
INT 13, AH=1Ch, Subfunction 0ah
09 06 0c 06 00 d0 01 00 ff 02 06 1b
INT 13, AH=1Ch, Subfunction 0bh
e9 06 00 00 19 00 02 32 00 00 00 00
INT 13, AH=1Ch, Subfunction 0ch
ea 05 df 9f 28 55 ff ff ff ff
Click to expand...
Thank You - What is the 'MLC' value on the white drive label for the drive that was tested? It is important to note that the Model 60 and 80 ESDI controller gives a "little-endian" result that is actually set up for single-character ASCII output (leading zeros being changed to '30'h, and '5' being '35'): Microcode version '0005' is returned as '35 30 30 30'.

This would be microcode level '32 02 00 19' in your results - '32' is a printable '2', but the other digits aren't ASCII-encoded. Notice that the DBA-ESDI "adapter ID" (9FDF) is returned for the 1C0Ch subfunction, instead of DDFF as the 60 and 80 ESDI controller. I'll start analyzing (and testing myself) to line it up with actual microcode versions.
 
Drive for the results above has:

barcode 11208378
smaller barcode BB
larger barcode *B1AL8Z00866*
white label 6128256
supplier code : 933
IBM FRU P/N 90X8627
P/N 6128250 60MB
FRU P/N
MLC : C13035
MODEL: WD-387
 
alank2 said:
Drive for the results above has:

barcode 11208378
smaller barcode BB
larger barcode *B1AL8Z00866*
white label 6128256
supplier code : 933
IBM FRU P/N 90X8627
P/N 6128250 60MB
FRU P/N
MLC : C13035
MODEL: WD-387
Click to expand...
There are possible PCB variations, with older versions a darker green, and the microcode as silkscreens rather than small labels on the PCB. My WD-387[T] 60Mb drives vary the most but document the changes well. Here are sections of what I previously recorded (all are "Supplier Code: 933", which I think is IBM Japan):

With 'Control Program 1987' on the PCB:
6128092 (silkscreened on PCB): "A07087M"
6128091 (silkscreened on PCB): "A071900"
Dark green PCB
Both identified as 'MLC: 341722' on the drive label
The black label on the drive has 'P/N: 33F5703, EC: A79678, Supplier Code: 933, IBM FRU P/N 90X8627'
P/N 6128250
FRU P/N [Blank]


With 'Control Program 1988' on the PCB:
6128095 (silkscreened on PCB): "C13044"
Lighter green PCB
MLC: 'C13052'
Black label on drive has 'P/N: 33F8711, EC: C00888, Supplier Code 933, IBM FRU 90X8627'
P/N 6128256
FRU P/N [Blank]
[Yours would place in this entry]


With 'Control Program 1989' on the PCB:
56F8672 (on PCB label): 'C64391-D'
Lighter green PCB
MLC: 'C27850'
No black label on drive
P/N 6128257
FRU P/N 6128294
 
Both the drives have C13044 on the bottom of them. The T drive works, but the non T doesn't. I'd be tempted to try swapping the boards to see if the problem moves with it, but the working one (T) is perfect so I'm not touching it.

Interestingly it had bad LBA 16 and 19 which are no longer bad now. I think 23 is bad and it was bad before, but now LBA 23 is the first bad block it runs into when I try to write 0's to all of its sectors.
 
Chuck(G) said:
Is there a detailed techref for the adapter board, like there is for the 5170 line of products (O&A)?
Click to expand...
The "ESDI Fixed Disk Drive Adapter/A Technical Reference" is for the Model 60 and 80 controller, of course - and was dated in April of 1987, which is the initial PS/2 introduction (the 30, 8550-021, and Model 60 - which had an MFM and ESDI submodels. The Model 80 was released a few months later). DBA-ESDI would end up on more PS/2 models, but that came with time. This is an effective probe at how much (excluding the few drives like the WD336RT and Seagate versions) is shared between true ESDI and DBA-ESDI with an 'ESDI-"like"' drive.

DBA-ESDI is actually a truncated microchannel adapter (@9FDF.ADF) attached to a drive that we are seeing the adapter ID in the 1C0C call ('Return POS Data'). It is so bound into the system BIOS that it can be an issue when attempting to add another controller, specifically with a different boot drive. Microchannel designs typically have the boot drive controller in the highest-numbered slot - DBA-ESDI is implemented on slot 4 on PS/2 models that have that as the total number of slots.

Extended CMOS is another factor with microchannel systems - with up to two hard drive parameter fields stored there. My Model 60 with the standard ESDI controller has the parameter fields filled with '5A'/'A5' alternating bits anyway, which is nutty, because both the Model 60 and Model 80 have Extended CMOS since they are tower units (8 microchannel slots) and the ESDI controller supports up to two drives. DBA-ESDI can be on PS/2 systems that don't have Extended CMOS (the 8550-021, 50Z, and 55SX lack it, and only have four slots). It also doesn't support more than a single drive.

And again, I want to figure out why there is an additional 9FDF ADF from Phoenix/NCR...
 
Last edited:
Yeah, I thought I would have a good test rig with a Model 53SLC2, but it apparently suppresses slot 4. I'll need to get out a 55LS 486 or Reply 55 system.

ESDIFail.jpg
 
Chuck(G) said:
Did IBM ever make a microchannel system that took standard-interface hard disk drives and floppies?
Click to expand...

Most later MC machines had SCSI internally, which I guess kind of counts as standard. Barely. And the early Tower 60/65/80 also used ‘normal’ MFM and ESDI drives in at least some configs. But the most common desktops (50/55SX/70), nope, you’re screwed.

Those later desktops with SCSI also mostly had 2.88MB floppies, so arguably maybe the situation is even worse on the floppy front.
 
Chuck(G) said:
Did IBM ever make a microchannel system that took standard-interface hard disk drives and floppies?
Click to expand...
The Model 53SLC2 as pictured has an IDE drive (as the 76i/77i also have) - and there is diskette drive cabling to add a 5-1/4" 1.2Mb drive internally on later models.
 
alank2 said:
Both the drives have C13044 on the bottom of them. The T drive works, but the non T doesn't. I'd be tempted to try swapping the boards to see if the problem moves with it, but the working one (T) is perfect so I'm not touching it.
Click to expand...
That's inverted from my WD-387 and WD-387T pair that are marked the same way ('C13044' label on the bottom and the same sequence returned from 1C0Bh). I've sampled enough drives now to know your drive PCBs are marked as '1988' - in fact, the oldest I have found with mine that still works, and every '1987' PCB drive I test has failed!

In fact, the versioning isn't even a sequence of "a larger number means later", and the 'MLC' value on the label doesn't resolve very well. I've compiled this sequence for the '32 02 00 xx' series. First is the entire table of returned 1C0Bh values, then converted to what would be in the 'microcode' field, the 'MLC' of the white label, drive model, and small label(s) on the PCB, with the 'Control Program' year last:

E9-06-00-00-19-00-02-32-00-00-00-00 = 32 02 00 19, MLC 'C13035', WD-387, 'C13044', '1988'

E9-06-00-00-19-00-02-32-00-00-00-00 = 32 02 00 19, MLC 'C13044', WD-387T, 'C13044', '1988'

E9-06-00-00-20-00-02-32-00-00-00-00 = 32 02 00 20, MLC 'C13101', WDL-330R, 'C13130-A', '1989'

E9-06-00-00-22-00-02-32-00-00-00-00 = 32 02 00 22, MLC '341669', WDL-330R, 'C27353-A', '1989'

E9-06-00-00-22-00-02-32-00-00-00-00 = 32 02 00 22, MLC '341669', WDL-330R, 'C27386-C', '1989'

E9-06-00-00-24-00-02-32-00-00-00-00 = 32 02 00 24, MLC 'C81194', WDL-330R, 'C81194-A', '1989'

E9-06-00-00-50-00-02-32-00-00-00-00 = 32 02 00 50, MLC 'C27850', WD-387, 'C64391-D', '1989'

E9-06-00-00-50-00-02-32-00-00-00-00 = 32 02 00 50, MLC 'C27850', WD-3158, 'C64391-D', '1989'

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'
 
You must log in or register to reply here.
Back
Top