Sorry no never messed with a 1640 but am guessing it has to do with the way the Virtual drive is seen by the controller. Which version of DOS are you using ?
Did you read chapter 2 of the install guide about copying the Adaptec ADF file from driver disk to the Config/Reference disk, if you did then not sure what else to say other than the Zuluscsi is not compatible with a 1640...

Get in on the next batch, I run this in my 55SX and it is awesome: https://zzxio.com/product/mcide/?fbclid=IwAR1 … gYSxU58D-DhkKmM

IBM PS/2es are rare beasts. I'm not even sure you can change the boot order sequence with the reference diskette if said diskette can't recognize your SCSI card, or if it even offers "SCSI" in the boot order sequence, as done with "commoners" Award/AMI/Phoenix4.0 BIOSes. Many propietary BIOSes only offer [A:C] [C:A] sequence, and them have propietary ways to determine what [C:] means if there is an external disk controller with an INT13H rom installed.

Reading fast in google, it seems IBM offered special SCSI MCA cards which just work and can be used for the "System Disk" (aka, where your special BIOS and OS partitions are deployed. Not sure if this can be done with any other vendor SCSI HBA. You will have to find for old Adaptec FAQs about PS/2 compatibility if this is even possible.

ED: XTBIOS is different in the way it hooks on INT13H BBS routine, it basically patches it to execute in the end of the BIOS boot drive sequence if there isn't any bootable [A:C:] drive or its "Boot Menu" ROM tool basically replaces the BBS chain. Adaptec BIOSes do only the "standard" way, it has an "initialization" procedure which gets executed with all external card option roms, but it doesn't boot the drive. That has to be called explicit by the BIOS Boot Sequence procedure (the so called "SCSI" in the boot chain in "commoner" mobo BIOSes).

I have one of these scsi cards. I use it for external drives. I dont recall being able to boot. I ended up using the IBM-made scsi card for the internal drives. As ANY change to SCSI devices required the damned reference disk.

However for an external drive, the reference disk wasn't required if I made any changes. I still have the card installed in my model 95. Its what I connect my zip drive to.

If you are patient, the IBM scsi cards come up relatively often for "reasonable" prices.

All that said, it looks like there have been some more updates to the page: https://ardent-tool.com/SCSI/AHA-1640.html

OH, and bookmark https://ardent-tool.com - you are going to need it.

Thanks everyone for the advice! From what I read, it sounds like there is no easy fix (as always with the PS/2 line).

I think that my next attempt will be to update the BIOS of both the computer and the AHA-1640 to the latest versions. I want to keep the original 27C128/27C512 BIOS chips intact, so I have ordered some DIP-28 EEPROMs which I expect to receive during the coming week. They should fit according the the data sheets and my scope. I expect the update to fail (what else to expect), so the next step is probably to try and hack the BIOS. I'm going to set up a "normal" retro machine with an AHA-2940 and study the boot sequence there. Then, it should be possible to disassemble the PS/2 BIOS and identify the code that drops me into BASIC when the boot fails. By replacing the jump to BASIC with my own code, it should hopefully be possible to trigger some kind of boot sequence within the AHA-1640 BIOS.

If the hacking fails, then I will replace the AHA-1640 with an IBM SCSI card.

When starting MS-DOS 6.22 from a floppy, I can access the virtual hard drive without loading any drivers for the AHA-1640. This fact tells me that the AHA-1640 BIOS has successfully installed some interrupt handler (I'm almost sure that it is INT13h) before loading the boot sector of the floppy and transferring control to it, and that MS-DOS uses this low-level interrupt handler to access raw sectors on the virtual hard drive.

I've done bootloader/kernel programming in the past, and I know that BIOS loads a bootsector to 0x7c00 and jumps to that address. What I need to do is to replace the jump to BASIC with a call to INT13h that puts the boot sector of SCSI device 0 at 0x7c00, and then a jump to that address. Perhaps I also need to set the CPU registers to values that the bootloader expects. The BIOS does not expect the bootloader to return (i.e. it probably executes a JMP and not a CALL instruction), so there shouldn't be any need for code to handle that.

For some reason the 55SX was way more difficult to get a boot drive working (outside of my busted ESDI drives) with the SCSI MCA cards I had. I went through like 3 different ones that always worked with my Model 77 but not in my 55. I had given up and shelved it but recently got the McIDE and for $65 it was so worth it. Works amazingly well for drives and CD as well.

Sounds like those cards are coming back in stock this month unless you just want to get this working with OG hardware just to say you did.

I have a 50Z and a 55Sx as well - am waiting for the McIDE https://zzxio.com/product/mcide/ to come in stock - this thing sounds like a game changer.

I signed up. I'm fortunate to have a dragon horde of mostly working hardware. But if I can not put stress on these super unreliable drives, all the better.

Usuallay the 1640 should be able to boot from, but I have no personal experience in combination within the 55sx.
It has been some time since I messed around with my PS2s, but I am sure there is at least one (P70) booting from a 1640.
Probably it needs some fidling around with the PCs Refdisks and the adaptecs BIOS settings?
- the PC has to be set to no HDD present
- the adaptec BIOS has to be enabled
- for a boot drive attached to the adaptec I would choose ID 0 or 1 ( despite IBM choosing ID6 for the first SCSI device on their controllers causing funny effects booting LINUX with multiple SCSI drives)
- entering the adaptec BIOS by pressing CTRL-A should enable you to set it accordingly and even be able to initiate a low level format
- make sure your disks partition is set to bootable and active
- Not sure if SCSIFMT.EXE was only for the IBM SCSI adapters, then it will not detect any drive on the adaptec.
It may be helpful to crawl the archives of comp.sys.ibm.ps2.hardware newsgroup there is aggregated knowledge collected there.

Thanks everyone for the advice! I got it working now. First I tried to upgrade the BIOS of the AHA-1640 to the latest version, but it still wouldn't boot.

The next approach I tried was to write a simple boot loader that simply uses INT13 to read the first sector of drive 0x80 (the first hard drive, i.e. ID0 on the AHA-1640) to memory location 0x7c00 and jumps there. In essence, my boot loader just loads and executes the MS-DOS boot loader. I wrote my boot loader to a floppy and started using it. This was a success, and when seeing "Starting MS-DOS..." I knew that I had a path forward.

After that, I disassembled parts of the BIOS of the computer itself and found that while it is trying to access the floppy drive using INT13 when booting, the same thing is not true for the hard drive. It did not research it in detail, but to me it seems that the 55SX uses some proprietary MCA bullshit ports (weird in/out instructions) to boot from the original ESDI hard drive in some magical way. Hence, the computer will probably only boot using IBM hard drives.

I concluded that if I somehow could get my boot loader into the BIOS code, the computer would likely be able to boot from the AHA-1640. Since the computer falls back to Basic in case of boot failure, I started researching that code. I turned out that the INT18 instruction loads Basic on old IBM PCs, and the BIOS only contains one such instruction in one subroutine. The solution to the problem was to replace the subroutine that executes INT18 with a trampoline that jumps to my code (which executes the old code that jumps to Basic in case of failure). Executing my boot loader in this phase of the boot makes it possible to boot from a floppy before booting from the ADA-1640. The reason for using a trampoline is that the memory area that contains the subroutine that contains the INT18 instruction is not big enough to hold my code. This turned out not to be a problem since the BIOS contains plenty of areas consisting of INT3 instructions.

If anyone is interested in the code that I used to patch the BIOS, then I'm happy to upload it to GitHub in a couple of days.

I'm happy that I'm able to boot the computer without a floppy now. I have ordered an MCA ethernet card, and after installing that I'm only missing a sound card (I would like to have an original Sound Blaster MCV, but I do not think it will ever happen) before closing the case. Then, I just need to score an external SCSI CD-ROM drive before considering myself done with this project.

johand84 wrote on 2023-03-02, 19:10:

I have ordered an MCA ethernet card, and after installing that I'm only missing a sound card (I would like to have an original Sound Blaster MCV, but I do not think it will ever happen) before closing the case.

There is modern recreation available here: https://texelec.com/product/resound-new-wave-mca/

zyga64 wrote on 2023-03-02, 19:50:

johand84 wrote on 2023-03-02, 19:10:

I have ordered an MCA ethernet card, and after installing that I'm only missing a sound card (I would like to have an original Sound Blaster MCV, but I do not think it will ever happen) before closing the case.

There is modern recreation available here: https://texelec.com/product/resound-new-wave-mca/

Thanks for the advice! Yes, I will most likely order one of those cards.

I've decided to post the code that makes the patch here. I will post a more commented and proper code to GitHub later, but here it is as an attachment.

The original BIOS can be downloaded here: https://ardent-tool.com/firmware/system.html. The patch only works with 33F8146 / 33F8145 for the time being, and it depends on some Linux dist with make,nasm,python3, and the python3 package 'parse'. Download the correct files and place them in the directory containing the files extracted from the attachment in this post. Then run make. Two files, 33f8145.patched.bin and 33f8146.patched.bin will be built. 33f8145.patched.bin goes into the odd chip on the motherboard, and 33f8146.patched.bin goes into the even chip.

got it patched. Thanks, I am going to try it on my other SX.

I noticed the McIDE is back in stock for those MCA tortured souls. 😉

https://zzxio.com/product/mcide/?fbclid=IwAR1 … gYSxU58D-DhkKmM