• Please review our updated Terms and Rules here

IBM ps/2 model 50

I've a blog entry that I posted years ago about reverse-engineering a combinatorial PAL using very simple hardware.
All of the other reverse engineering gizmos use essentially the same method, just using more modern hardware.
Where you get into the land of woo is trying to reverse-engineer the registered PALs. Memory can make determining function by brute force very, very difficult.
 
Yeah, you need the "upgrade" adapter.

That page only specifically mentions it being offered with a 60MB hard drive upgrade. Hopefully the ROMs on it actually work with any DBA drive. (Knowing IBM I wouldn't bet much on it.) :(
DBA-ESDI drives of the different capacities (30, 40, 60, 80, 120, and 160Mb) are interchangeable between the IBM systems that support them...
 
Eudimorphodon - so for the wide dba drives like in the auction above that I am getting, I would need a board like this:


This section:

DBA-ESDI Adapter w/ ROM FRU P/N 90X9571, P/N 15F6993, 90X9570

The ROM images are from a riser where they had to be desoldered (by Jim Shorney - I should look to whether he has an account here) - and I am not aware that anyone has tested them *yet*. Splitting the 50Z ROMs (you don't even need to do that from your new system - we've got them up at the 'Ardent-Tool' as well) to run in the 8550-021 might be easier. But I do need to test the riser BIOS extensions ROM images at some point.
 
I saw that mentioned. I wondered what address they were at.

Is there a guide/list of caps I should be looking to replace on the floppy drives somewhere?
 
I saw that mentioned. I wondered what address they were at.

Is there a guide/list of caps I should be looking to replace on the floppy drives somewhere?
For a BIOS extension, it really wouldn't matter as long as there aren't conflicts (and the two interleaved ROMs really aren't that big) - I haven't analyzed the images to see if it is hardcoded. Rather than reversing the riser, splitting the 50Z BIOS is an easier solution.

The 50Z is referred to as a 'Type 2' Model 50 in IBM literature - there were the 8550-031 and 8550-061 submodels, but the only "non-50Z" submodel is the 8550-021 that you have.
 
I thought I put a link to it so everyone could see the pictures and recognize what it is.


item 125360401788 on ebay
That's actually a really good price, for being the second owner, getting a Model M, a CRT and other goodies. Did the CRT arrive intact?

I'm late to this post as well. I've owned both a 50 and 50Z. The 50Z is a no-wait-state machine, and I want to say a little faster than the 50? Not to give you buyer's remorse, but I know more people tend to go for the PS/2 Model 30-286 as their first PS/2, only because it's a PS/2 AND has ISA slots. Microchannel definitely has benefits over ISA, but it's a pain in the ass to configure sometimes. You can find darn near all ADFs at MCAmafia or the ardent tool of capitalism site. I've been trying to downsize and sell off my PS/2s except some keepers, like my model 9595, but I might even still have a 50 here still.

If you want to save yourself some grief, what you could theoretically do is get yourself a SCSI MCA card, ideally one that has a standard 50 pin ribbon cable internally, and then use a SCSI2SD and boot that way. PS/2 hard drives were crappy when they were new, and most certainly don't work now, though I've sold some to people who've said they worked or managed to resurrect them somehow.
 
Thanks pkhoury. I love the machine despite its hard drive failings. I thought about the SCSI direction, but its seems that MCA SCSI cards are pretty pricy. The CRT arrived great; the guy took it to the UPS store and they did an amazing job of bubble wrapping it extensively. I've got 4 DBA drives that I am hopeful one may work tomorrow when a 50Z I also ordered arrives, so the anticipation is high!

One question though for anyone who knows PS/2's well. I formatted several new diskettes perfectly, but there is one disk that comes up with a track 0 failure. I can take the track 0 fail disk to another PC and it formats fine. Back to the PS/2 and it fails. It looks just like my good ones, detection holes are the same, etc., but yet it will not format no the PS/2. I can read or write to it on the PS/2 once it is formatted on another PC.
 
Some good luck so far. The 50Z arrived and boots the reference disk once I used a disk cleaner on it. It seems to have a new lithium battery in it too (>6V). The Alps floppy on the 50 seems better quality and has a nice metal cage around it, but the one in the 50Z (64F4473) seems more like a retrofit than original design, but I don't know.

WD-336RT (30mb): The drive makes some loud noises and does not seem to work. Not sure what I could try on it, but I've moved on to drive #2.

WD-387T (60mb): I am hopeful this drive might be fine!! It has made it through phase 1 of the reference disk low level format with 0 errors and is about 33% through phase 2 also with 0 errors. It isn't a fast LL! This one completed with 0 errors. FDISK/FORMAT run great and it boots great. Parked it and removed it.

WD-380S (80mb): It is noisy and at first I didn't think it was going to work, but it made it through phase 1 LL and is into the really slow phase 2. 0 errors so far out of 33 cylinders!

Drives still to test:

WD-387 (60mb)


It also doesn't have a red power toggle, but a white one that seems loose in the power supply, but still works.

There was also a small white plastic broken piece inside, but I'm not sure where it is from.

Why is one MCA slot bigger than the others?
 
Last edited:
The last drive WD-387 gives a 10490 error.

The 10490 seems to go away, but the drive will not LL format. It says:

The manufacturers defect configuration
area is unreachable or invalid
Replace the ESDI fixed disk controller
Suspect drive.

Some sectors can be read and written to the drive however.

I tried the instructions here to patch LLFORMAT, but it did not get by the above error.

Any other ideas? I wonder if the drive would work if I could just LL it. I tried sstor, but it sees the translated geometry of the drive and fails to initialize it.
 
Last edited:
I tried the instructions here to patch LLFORMAT, but it did not get by the above error
Think that will only work on the real ESDI interface. All the drives on the DBA interface have the data that the un-modded LLFORMAT requires. It was worth a try though.
 
Yeah, I've tried a number of things unsuccessfully just to see if I could get it to keep formatting. I read that the defect table has two places it is stored, at the last cylinder and then 8 cylinders before that. I was going to try to trace into the format call to see what it does and what it is getting back that causes it to give up, but I modified the LLFORMAT hooked interrupt which gets an update from cylinder to cylinder and it is never even being called.
 
Has anyone tried to direct read or write using the int13 functions? int13/ax=1cXX. they seem to line up except +1 with what is in the ibm esdi manual. Maybe they aren't implemented in the bios, but they could be.

Ralf Brown interrupt list - search for ESDI:
 
Have you tried using one of the calls? They could belong to a specific adapter. My Phoenix PS/2 reference only mentions ESDI in connection with AH=1A: Format ESDI disk. That call may be more useful in any case.
 
Not yet, I might mess with it tonight. I suspect at this point that the call that is being modified in the LLFORMAT above (AH=1A that you mentioned) is giving up with an error. I suspect that the AH=1A kicks off the format request to the controller (which carries out the entire format) and it keeps checking the controller status for pending/finished/etc. and calls the interrupt that updates the LLFORMAT, but likely an error is being returned that the AH=1A gives up on. Some of the results are just warnings so maybe it could proceed instead of give up. That is one way to attack it.

The other is to be able to read actual track/sector on the drive outside of the translated area and have full access to all cylinders. If that could be done, I might be able to read the last cylinder and 8 cylinders before it to see what data is there. Assuming that the ability to read/write is implemented in the bios under the 1cXX functions. I'm not sure what they. Maybe the regular functions could also do a read/write if they weren't limited by a check of what is "usable" sectors.

All of it is surely a massive long shot, but the drive can read/write sectors, but some fail. If I could just get something to try to successfully LL it, it could be fine.
 
So I made a tool last night to test all the format modifiers (0-31), but no luck. It always returns with an error 16 (0x10) : uncorrectable CRC or ECC error on read. I'd love to know the exact return code being sent by the ESDI controller, but I'll have to do some more BIOS digging tonight to see if it exposes that anywhere.

I'm enclosing the tool in case anyone wants to take a look at it. Use at your own risk as it is very untested at this point.

My VM obviously doesn't have the function implemented!

1656684394377.png
 

Attachments

  • esdifmt.zip
    9.2 KB · Views: 4
Has anyone tried to direct read or write using the int13 functions? int13/ax=1cXX. they seem to line up except +1 with what is in the ibm esdi manual. Maybe they aren't implemented in the bios, but they could be.

Ralf Brown interrupt list - search for ESDI:
Yes, I've started with them for the Model 60 and 80 ESDI controller - mostly to get the microcode version from software (INT 13h, 1C0Bh) before I see if it is implemented for (most of) the DBA-ESDI drives. There is the omission that for 1C0Bh, preload DL with 80h (the "device number" for the primary drive). I already knew by dumping the microcode ROM, but had to move into getting it through software: https://www.ardent-tool.com/storage/ESDI.html#Microcode_ROM
 
Have you tried using one of the calls? They could belong to a specific adapter. My Phoenix PS/2 reference only mentions ESDI in connection with AH=1A: Format ESDI disk. That call may be more useful in any case.
The microchannel IBM ESDI Adapter/A (https://www.ardent-tool.com/storage/ESDI.html) supports them - as the OP has pointed out, the subfunctions closely match the returned tables shown in the ESDI Technical Reference (PDF link at the same 'Ardent-Tool' page). I now have a Western Digital WD1007V-MC1 (https://www.ardent-tool.com/storage/WD1007V.html) with the same adapter ID (DDFF) as the IBM ESDI controller. Of course, I'm expecting the same INT 13h functions to be supported there as well, with the WD1007V-MC1 being the HDD controller for the Bull Micral 500 (which has an ongoing search for supporting configuration software) and the rare Tandy 5000MC.
 
Think that will only work on the real ESDI interface. All the drives on the DBA interface have the data that the un-modded LLFORMAT requires. It was worth a try though.
IBM describes the WD336RT as 'ST506-"like"', and all other DBA-ESDI drives as 'ESDI-"like"' - there are even microcode revisions (usually also identified through the 'MLC' listing on the white label on top) on the logic board. Does that maybe mean ESDI function support? I'm checking that out.
 
Back
Top