The following is a list of documentation, software and hardware wanted by the OS/2 Museum. Donations are most welcome (the OS/2 Museum is happy to pay for shipping costs from anywhere in the world), although a reasonable price can always be negotiated.
Either electronic or paper form is welcome. If necessary, the OS/2 Museum can convert images to PDF (with or without OCR).
- VESA Local Bus (VL-BUS) specification version 1.0
- PCI Local Bus Specification, Revision 2.0
- Any PCI Local Bus Specification prior to 2.0
- Original VESA VBE 1.x Specifications (not just ASCII text)
- IBM 386SLC and 486SLC data books
- ICS11614 aka Gravis GF1 documentation
- Crystal Semiconductor CS4289 datasheet
- Detailed information about Yamaha OPL2/OPL3 “LSI Test” registers.
- Complete MS OS/2 2.0 SDK (any version, circa 1990)
- Windows 3.0 DDK (1990)
- Microsoft Programmer’s Library 1.2 (circa 1990)
- IBM OS/2 2.0 pre-release builds older than Spring 1991
- Intel ASM86 assembler version 1.0 (anything older than V2.0, circa 1979)
- Watcom C 6.0 or 6.5 (1988)
- Watcom C 7.0 (16-bit, circa 1989)
- Watcom C 8.0 (16 and 32-bit, 1990)
- Original Solaris 7 Intel edition (FCS, not updated)
- A functioning ESDI hard disk
- Roland SCD-15/SCB-55
A list of already acquired/available items. Over time, this section ought to get longer and the rest shorter!
- Intel Family Binary Compatibility Specification 2 (iBCS2). Intel order number 468366-001. Purchased on Amazon, ISBN 0-07-031219-2 (published by McGraw-Hill). Does not reference Intel order number!
- Texas Instruments 486 SXL2-50 (similar to Cx486DRx2). Purchased on eBay.
- Cyrix FasMath CX-83D87-40. Purchased on eBay.
- Cyrix Cx486DRx2-66 CPU. Purchased on eBay.
- Microsoft Programmer’s Library 1.1 CD. Donated by a kind acquaintance.
- IBM OS/2 2.0 pre-release builds 6.123, 6.167, 6.605. Floppy disks donated/purchased.
- A variety of SIPP modules. Purchased on eBay and directly.
- Microsoft C 5.0. Now on archive.org.
- Microsoft Programmer’s Library 1.0. Surfaced on pcjs.org.
- Intel 420TX and/or 420ZX datasheet. Thanks to Maciej W. Rozycki.
To get in touch with the OS/2 Museum, please leave a comment with a valid e-mail address (neither the comment nor the address will be published).
I’ve recently imaged 9x 360k disks of Microsoft C Version 5.0 – you can find it on archive.org by searching for mscv5.7z or contact me for a direct link.
Found it. Very cool, thanks!
I have a number of IBM Redbooks, OS/2 programming guides, C Set/2, DB2 that I don’t want to move with me. I would be happy to donate what I have for the cost of shipping.
All books/manuals are in near new condition. I have a factory sealed ‘IBM Transaction Server foe OS/2 warp’ version 4… among others. I hate to see them just go to a recycling center.
Hello Mr. Necasek,
I just wanted to reach out and ask a couple of questions, if that was alright. Before doing so, however, I just wanted to say that this website is an invaluable treasure of knowledge and that a copy of your Alaris Cougar MR-BIOS saved my board. Thank you for all that you do!
What I wanted to ask was the following: Do you happen to have any extra EISA video cards that you’d be willing to part with for either a fair price or for a trade (or both, if I can provide something of interest)? I’d love to find an ELSA Winner XHR 1000 or EISA Mach32. Any other board would be welcome too!
If not, no worries at all. I wanted to then ask: Do you have any advice on finding these elusive graphics boards? I’ve got two EISA/VL motherboards and would love to do some testing. I am very curious in EISA video hardware, as such.
Thank you for your time and consideration. I look forward to hearing from you!
Glad to hear the Cougar BIOS helped. I guess somehow my board happened to have a BIOS newer than most.
I’m sorry to say that I don’t have any EISA video cards I’m willing to part with at this time. I too want to find out how the bus type affects graphics performance, but have not yet found the time to set up some sensible test environment. Off hand I can’t think of cards other than the Winner XHR 1000 or Mach 32, although I believe Compaq had some EISA VGAs too. I don’t have any special tips for finding such cards other than eBay (sadly tends to be super pricey nowadays) or some local classified ads.
I suspect the scarcity of EISA graphics cards has to do with the fact that EISA never really made it in the workstation market. Server machines were just fine with ISA VGA, and by the time EISA was a thing (1992-ish), VLB was already enthusiastically embraced by graphics hardware vendors. In 1993 there was the rush towards PCI, which was superior to EISA anyway. Only storage controllers seem to have been made in EISA format in larger numbers, presumably because storage (especially SCSI) could already move data a lot faster than ISA could handle in 1991 or so. EISA network cards OTOH seem to be rare, likely because EISA couldn’t make that much of a difference before Fast Ethernet, and by the time Fast Ethernet arrived, PCI was already there.
What EISA/VL boards do you have?
My apologies about the delay in responding. I’ve been a bit ill, but am fortunately on the mend.
Thank you kindly for getting back to me, and so quickly at that!
As to your Cougar board’s BIOS, I am almost stunned by the difference that it made. I was using an ARK1000VL with mine and noted something like ~15MB/s reads and writes, when on other boards I was averaging ~25-27MB/s. I figured your BIOS was worth a go and it worked! I’ve never seen anything quite like that. Have you ever encountered such an oddity?
I completely understand. Thank you for letting me know! I figured I might as well reach out, as these things seem quite impossible to track down. Hopefully I’ll run across something sometime, but in the meanwhile, I managed to grab a 1MB Compaq QVision 1024/E and it’s a pretty interesting board. It seems decently fast, but the 1MB VRAM is a limiting factor in Windows. I appreciate your thoughts, though, and will absolutely keep an eye out!
I see. I never really suspected that ISA graphics would have superseded EISA in a sense, being that servers never had much of a need for EISA graphics cards. VLB definitely provides more performance and I can’t deny that I’m a bit of a VLB graphics fiend, but something about EISA and even ISA graphics boards is so captivating! It’s funny—I didn’t consider PCI, but you are right. 1993 was a wild time for development, that’s for sure! EISA SCSI seems pretty nice and considering EISA’s excellent busmastering, there’s reasons to believe advantages exist over VLB in that area, no? I’d be curious to hear your thoughts on that, actually! Funny enough, I have a Fast Ethernet EISA network card; do you think EISA is up to the task in that regard? My experience with ISA Fast Ethernet cards shows no tangible benefit.
As far as EISA/VL boards, I’ve got two. They are both MCCI/NICE SuperEISA boards. Both are the exact same, just different revisions; the earlier model accepts Crystal oscillators for the bus clock and has a non-overdrive PGA socket, and the later model has the traditional Socket 3/selectable clock generator setup. They’re wonderful boards and incredibly robust, but they do only have 1 VLB slot, compared to the Tyan and AMI offerings.
Thanks again for the response and for your thoughts and advice! I appreciate it immensely.
I think server boards have had relatively substandard graphics ever since dedicated server boards became a thing. Which really makes sense… because what does something like a NetWare server need graphics-wise? And nowadays no one wants to attach an actual monitor to a server, everything is remote. I really do think that EISA graphics cards are such a rarity because between ISA, VLB, and PCI, there just wasn’t much of a market for them. Plus servers needed fast storage and networking, but not graphics.
EISA should definitely make a difference for Fast Ethernet. ISA is known to more or less eliminate any advantages of Fast Ethernet, even though there were a couple of ISA FE network cards. What kind of chip does your EISA Fast Ethernet adapter have?
I believe bus mastering was a bit iffy with VLB cards, not impossible but not guaranteed to work in every slot etc. EISA also had generally much better DMA capabilities. I’d expect EISA to be much better than VLB in terms of reliability, if not performance.
As for the BIOS… it’s possible that it sets up the chipset better. The ISA bus speed and timings setup can make a big difference, CPU cache setup can too. If the chipset has any kind of pipelining or write buffers or some such (not sure), that can boost performance too. In the Cougar board, the CPU type will also make a difference, and it’s plausible that a newer BIOS might be better able to set up especially non-Intel CPUs.
Thanks again for getting back to me! I definitely see the rationale, and I can definitely agree and add that that still applies today. I recently put together a FreeNAS system with a Ryzen 5 3600 and a X470 server board, and the integrated graphics chipset is pretty much 2D-only, which is perfect for that use case.
I have a 3COM 3C597TX, which has their later, parallel tasking chipset. I haven’t tested it much. Perhaps I should do a comparison between that and the Intel ISA 10/100 card I own? I’d imagine that the leap EISA provides is probably pretty substantial.
Ah, okay, that makes more sense than the convoluted answers I’ve heard before. I always presumed that VLB bus mastering sort of worked, but I always hear “oh, no, EISA is the way to go,” and that doesn’t sit right with me. I can see where the better DMA capabilities of EISA must be really nice for things like SCSI controllers, but I wonder if an IDE controller that supports PIO-4 over VL would win from the sheer bus throughput? Something like the Promise EIDE 2300+, perhaps?
I actually own an EISA IDE controller as well: the DTC 2290. Have you any familiarity with this card? I’ve never seen another IDE controller that uses EISA before, and I am led to believe performance is not as good as with EISA SCSI.
Interesting. My board came with an older MR-BIOS and the performance difference between the two has been night and day. I do believe that your BIOS is a later copy and can see where perhaps the timings, cache setup, and the like are properly configured to maximize the board, whereas the older one simply didn’t cut the mustard there. I have noticed that attempting to run the OPTi 283 MR-BIOS on the Alaris Leopard LX does not properly configure the SLC2-50 processor and that board; perhaps this is similar, as you suggest.
Thanks again for your insight!
I only have a couple of SCSI EISA HBAs, no IDE. I suspect EISA IDE is kind of like EISA VGA… few and far between. Lot of EISA machines went for SCSI, and IDE drives that could really take advantage of faster bus speeds didn’t appear right away.
One thing I can say is that the Adaptec VLB IDE controller on the Cougar board is rather fast, and finding a drive that would be bottlenecked by the bus speed is difficult. It can run at around 9 MB/s (according to Norton Sysinfo) which is quite a lot for a 486. I doubt a busmastering controller can be faster in raw throughput.
Somewhere I have a 3Com 3C515-TX, one of the few ISA 10/100 cards. It’s on my todo list to check how slow it actually is.
FYI OS/2 for PC-98 has been dumped on archive.org. It will not run on Neko Project 21/w however as it instantly crashes in the emulator. It requires a real PC-98 but you can find a compatible model such as a Cx2 for like $35 on YAJ and a keyboard for a similar amount right now.
I’m testing it right now to see how it works but if you want another OS/2 obscurity to mess with there you go.
In case you haven’t found it already, here you have Watcom C 6.5:
Thanks. I have seen this already, and unfortunately the two most important library files (CLIBS.LIB and CLIBC.LIB) are corrupted beyond help.
I worked in the computer industry retail from 1989 to 1999. I have acquired a host of boards (microchannel ISA EISA etc) MFM etc drives and software some of which I have not seen elsewhere. My thought at the time was to use it as a teaching aid, and I did actually teach in a college for a while. Cost of storage is going up, and i am getting older. Do you have any interest in this?
Sent an e-mail (in case it landed in the spam folder).
If you are looking for the 3C589B-TP cable, they have one on eBay right now:
Hello, this is Marko from the Slovenian Computer History Museum. We have been able to find a long lost copy of the Slovenian localization of OS/2 Warp 4 and in doing so, unearthed a lot of other cool trivia and memories.
I have written a draft of an article I would gladly publish on your website or just provide you with the information to put in an article of your own if you are interested, of course 🙂 It includes a lot of cool photos and screenshots to make it interesting for a wider audience.
I would also like to donate a digital copy of the Warp 4 CD disc image to your museum, just not to be publically downloadable for the time being as the source that provided it to me would probably not approve.
Looking forward to hearing from you,
Slovenian Computer History Museum
This is not a direct response to your requests, but I think you may be sympathetic anyways.
At one point someone told me you appreciated Pascal, even going so far as to say you’d write your own frontend for OpenWatcom if you could. Granted, this isn’t quite that, but it does compile with OpenWatcom: Pascal P4 (“public domain”) bytecode compiler (pcom, pint) from ETH Zurich (1976).
It’s still only a subset, and Scott Franco’s P5 is better (full ISO 7185 but needs dead GPC), but it’s better than the “official” p2c translation offered on Steven Pemberton’s website (some newer fixes by Scott with his partial test suite). Pemberton’s website still hosts his book on P4, too.
I’ll give you an ESDI HDD if you give me OS/2 1.03 SDK
I can see that you have deep knowledges of old HDDs. I’d like to discuss something and didn’t find vaild mail to you. I’m just experimenting with XTIDE BIOS on old 386 board with 16b ISA controller and trying use with SSDs (PATA version and via mSATA adapter). With normal pata platter HDDs and CF cards it works well but not SSD. After some fiddling I revealed it’s caused by missing IOCS16# signal on pin 32 of IDE that is simply not connected on SSD or SATA adapter. This cause I lost every MSB of data I try to read. On the IDE controller card the IOCS16# goes directly to ISA bus signal at pin D2. Did you meet this obstacle too? Did you succeed with generating IOCS16# signal for ISA bus and how? I have some idea using logic gates to decode CS1:0# and DA2:0 signals, if it will work?
I have not run into this problem, but I always used AT style boards/adapters/software. So everything was 16-bit.
If I understand your problem correctly, you have a 16-bit adapter but the XTIDE BIOS needs to do 8-bit transfers? If my recollection is right, the drive/adapter is driving the IOCS16# signal. But if you need 8-bit transfers, you really need the device/adapter to to support the SET FEATURES command and switch the drive to 8-bit mode. If that’s not supported by the drive/adapter, I don’t think the XTIDE BIOS can work.
The problem is that a 16-bit drive will present 16 bits of data in a single cycle, and in the next cycle it will deliver the next 16 bits. It might be possible to build some kind of buffer that can latch the 16 bits from the drive and then supply the low and high byte in separate cycles, but that’s well beyond my nonexistent circuit design skills.
we are clearing out some archives and files on the file servers, with some items dating back to DOS and OS/2 (which we used quiet extensively in the past).
Would you be interested to review before the server are shutdown? And how should I proceed?
Does the iBCS2 book explain the rationale for struct return calling convention, where the callee uses the ‘ret 4’ instruction to pop one argument off the stack? Alan Cox mentioned the book in his Retrocomputing SE answer at https://retrocomputing.stackexchange.com/a/26589/26339
The iBCS2 book does not offer much in the way of a rationale. It seems to assume that of course you return structs in memory, because they could be big. There are no provisions for returning small structs in registers. The book does say that the caller provides the storage space in order to make the call interface re-entrant; that makes sense. Note that the space could be on the caller’s stack but there’s nothing in the ABI which requires that.
The caller provides space for the returned struct, and passes its address to the called routine as a hidden first argument. The callee eventually returns that same address of the returned struct in EAX. There is no explanation given why the address isn’t passed in, say, EAX or ESI. Unstated but obvious is that if there is going to be a hidden argument, it must be the first one in order to support variadic functions.
The example given in the iBCS2 book does not use ‘RET 4’ at all. Instead, the callee prologue looks like this:
Instead of working with the re-jiggered stack frame layout and finishing with ‘RET 4’, the prologue immediately removes the hidden argument and then continues as if the hidden argument were never there.
Clearly some compilers do it differently, leave the stack frame unaltered, and then ditch the hidden argument with ‘RET 4’. The iBCS2 book again offers no rationale but clearly states that the called function must remove the hidden argument from the stack.
The scheme seems frankly a bit bizarre. Other x86 compilers tend to use ESI or some other register to pass the address of the memory where the struct should be returned, which obviates the need for the hidden argument and for requiring a different function prologue and/or epilogue.
I’ve been looking for the MS OS/2 LADDR Development Kit and can’t seem to find it anywhere. It’s referenced in https://www.os2museum.com/wp/ladders-and-dragons/, but I haven’t seen it archived anywhere. I’ve found the MS OS/2 DDK 1.0 and 1.2 versions, but nothing else. Does anyone have access to a copy? It would be interesting to me as I build some old computers and mess around with some retro coding.