AlessandroB wrote on 2023-12-28, 12:55:

Incredible, the problem was in the presence of the SoundBlaster 16. What led me astray was the incorrect Bios message, otherwise I probably would have tried first to see if there were any conflicts.

I immediately saw the 1.2GB disk, then I entered the controller configuration (ctrl-a) and set support for large disks and it saw an 8GB disk.

What do you think?

I have BIOS and Microcode 2.11 on my 1542CF, and that version supports disks bigger than 8GB. It has a BIOS option "BIOS Support for INT 13h Extensions" which needs to be enabled, and of course you need an operating system that supports Int 13h Extensions, too. This means you need a sufficiently new Windows 95 OEM Service Release or Windows 98. MSDOS 6.22 or original Windows 95 do not support more than 8GB, even if the BIOS support INT 13h Extensions (AKA "LBA support").

My 1542CF with BIOS 2.10 also has Int 13, never tried it on a drive bigger than 18GB but it did see it all iirc. I also have bios 2.11 in archive but never flashed it, didn't find a need but maybe with a 36 or 73GB HD I would....

AlessandroB wrote on 2023-12-28, 12:55:

Incredible, the problem was in the presence of the SoundBlaster 16.

fantastic 😀 so after all Adaptec firmware was indeed failing to initialize its buildin floppy controller and concluding its on a wrong card 😮
Looking at https://github.com/mamedev/mame/blob/master/s … sa/aha1542c.cpp everything goes thru one single IO port. FDC initialization must have been first on the list for this firmware, 1542C would most likely also fail, but in a slightly different way.

rasz_pl wrote on 2023-12-28, 23:37:

AlessandroB wrote on 2023-12-28, 12:55:

Incredible, the problem was in the presence of the SoundBlaster 16.

fantastic 😀 so after all Adaptec firmware was indeed failing to initialize its buildin floppy controller and concluding its on a wrong card 😮
Looking at https://github.com/mamedev/mame/blob/master/s … sa/aha1542c.cpp everything goes thru one single IO port. FDC initialization must have been first on the list for this firmware, 1542C would most likely also fail, but in a slightly different way.

No, this is a trap. The "F" in 1542CF is for *f*ast SCSI, not for floppy. Floppy / no floppy is indicated by the 0 or 2 in the end. The Adaptec BIOS does not care about the floppy at all. The 1542C is 5MB/s only, whereas the 1542CF supports 10MB/s. They have a different SCSI controller chip, and a different firmware. If Adaptec/MircoSemi is distributing the same firmware for the 1542C and 1542CF, this is clearly an error. The firmware of the 154x controller family, starting at the 1542C, supports an ID command that returns the type of SCSI controller. The type code is a constant value in the firmware. The BIOS of the 1542C family controllers asks the firmware for the ID and version code, and if it receives a different hardware ID than expected, it prints a message like this. In the case of the OP, the SB16 interfered with the communication between the BIOS and the firmware and made the BIOS receive a garbled hardware ID.

I was wondering how the controller can know there is a difference between a C and a CF and yet the software is the same, because the controller clearly wont work when you cross over the software.

I love these old computers because of these kinds of things. Modern computers seem to almost completely obfuscate any problems like this.

the 1542ccfg BIOS they have is interesting though, as its file name implies it is for the c cf g...

mkarcher wrote on 2023-12-29, 00:16:

rasz_pl wrote on 2023-12-28, 23:37:

AlessandroB wrote on 2023-12-28, 12:55:

Incredible, the problem was in the presence of the SoundBlaster 16.

fantastic 😀 so after all Adaptec firmware was indeed failing to initialize its buildin floppy controller and concluding its on a wrong card 😮
Looking at https://github.com/mamedev/mame/blob/master/s … sa/aha1542c.cpp everything goes thru one single IO port. FDC initialization must have been first on the list for this firmware, 1542C would most likely also fail, but in a slightly different way.

No, this is a trap. The "F" in 1542CF is for *f*ast SCSI, not for floppy. Floppy / no floppy is indicated by the 0 or 2 in the end. The Adaptec BIOS does not care about the floppy at all. The 1542C is 5MB/s only, whereas the 1542CF supports 10MB/s. They have a different SCSI controller chip, and a different firmware. If Adaptec/MircoSemi is distributing the same firmware for the 1542C and 1542CF, this is clearly an error. The firmware of the 154x controller family, starting at the 1542C, supports an ID command that returns the type of SCSI controller. The type code is a constant value in the firmware. The BIOS of the 1542C family controllers asks the firmware for the ID and version code, and if it receives a different hardware ID than expected, it prints a message like this. In the case of the OP, the SB16 interfered with the communication between the BIOS and the firmware and made the BIOS receive a garbled hardware ID.

Damn, and here I was so proud of myself for figuring F out 😜

OK OK, I took two days off because I was really angry and disappointed, mounting the 2940u2w (and a twin of the disk I'm testing together with the 1542cf) on the Pentium200 was smooth and the result was excellent, fast and without problems.

I didn't sell the controller because I wanted to give it a second chance, in fact a high level scsi controller of the time (and not those limited controllers like I had without bios to connect the PhilipsCDD2600) was too cool.

With more calm I then tried to connect the hard disk and a scsi burner to the scsi chain, using various 68-50 converters and taking advantage of the terminator present in the 68pin cable. the computer boots from floppy and by doing several tests I managed to install DOS 6.22, the problem is that by restarting the computer once the DOS installation is finished the computer stops when loading the OS. I also tried starting the computer with diskette number 1 of DOS 6.22, pressing F3 and exiting I ran fdisk which correctly partitioned the 1GB disk but then told me that disk C: was not present, from here I deduced that DOS is not compatible with this hard disk, the controller probably works but the disk is too big, even enabling support for disks larger than a gigabyte in the 1542 bios. Small note, the IBM computer bios does not support disks larger than 1GB , but I imagine that using scsi this thing is bypassed right?

I then did another test, I started the computer with the Win98 boot floppy, with both the 73GB hard disk (68 Pin SE mode) and the 50pin SCSI burner connected to the SCSI chain. The boot floppy loaded the scsi controller driver and I was able to access the windows98 CD-ROM and ran the win98 installation. The installation was successful and win98 starts correctly, I therefore deduce that there is no hardware problem between 486->1542CF->HD SCSI 15k 73GB. The problem is only with the operating system which does not see the hard disk correctly.

At this point I find myself with um 486 with windows98 installed, which I don't like very much, the machine dedicated to windows98 are the computers from Pentium200 to higher. I would have liked in my plans to have a 486 dedicated solely to DOS6.22 and Win3.11.

What do you think I can do? Is the only option to get a hard disk compatible with DOS 6.22?

How can I be sure that this disk works with DOS?

Wouldn't I eliminate the advantages of SCSI if I mounted an old hard disk (perhaps SCSI II) instead of the current 15,000 rpm one? Probably louder.

My project was precisely to have a series of identical SCSI disks (you can see them in my post at the top) to also be used as spares between the various IBM machines (also IBM branded which together with the rest is very cool installed in IBM machines)

Thank you all for your replies

Im not really sure.
Ive never used such old software on what I consider intermediate age technology. Where SCSI U320 was late age.

Its clearly something to do with the software as the hardware is what it is and at first it can be seen.

If you want to install DOS 6.22 onto a SCSI disk why not get yourself one of the old hard disks from the time?
That will give you the full experience of doing it like its the early 90s again.

Just because the hardware is backwards compatible it doesnt mean the software is forwards compatible.

ElectroSoldier wrote on 2023-12-31, 14:15:

Im not really sure. Ive never used such old software on what I consider intermediate age technology. Where SCSI U320 was late ag […]
Show full quote

Im not really sure.
Ive never used such old software on what I consider intermediate age technology. Where SCSI U320 was late age.

Its clearly something to do with the software as the hardware is what it is and at first it can be seen.

If you want to install DOS 6.22 onto a SCSI disk why not get yourself one of the old hard disks from the time?
That will give you the full experience of doing it like its the early 90s again.

Just because the hardware is backwards compatible it doesnt mean the software is forwards compatible.

For example because it will be nice to have only one model of hard disk and use it for alla my era-retrogaming machines, so i can get ten of this disk to use as a spare, no matter in wich computer i put it.

The 50pin hard disk are really pricey, if i use win98 in this 486 and only use it booting in non gui mode? i mean always in DOS 7 prompt?

Yeah I can see what you mean and why youre trying to do it, but youre already coming into the problems with it.

Maybe Im wrong, maybe DOS can access a 73Gb hard disk, but its not something Ive ever tried myself, and what what I can tell given your description of your hardware setup I cant really see anything wrong with it... Maybe seperate the hard disk onto a 68pin cable and the CDROM onto a 50pin cable.
But having said that all youre really doing by sharing a cable is slowing down the hard disk to run at the same speed as the CDROM.
So I cant see how that will change anything at all.

ElectroSoldier wrote on 2023-12-31, 15:20:

Yeah I can see what you mean and why youre trying to do it, but youre already coming into the problems with it. […]
Show full quote

Yeah I can see what you mean and why youre trying to do it, but youre already coming into the problems with it.

Maybe Im wrong, maybe DOS can access a 73Gb hard disk, but its not something Ive ever tried myself, and what what I can tell given your description of your hardware setup I cant really see anything wrong with it... Maybe seperate the hard disk onto a 68pin cable and the CDROM onto a 50pin cable.
But having said that all youre really doing by sharing a cable is slowing down the hard disk to run at the same speed as the CDROM.
So I cant see how that will change anything at all.

Is not a speed problem, is a operating system undertanding drive the problem. When the system is ready only the HD will be on the channel, no problem to slow it, and i'm not really sure the bottleneck with be the unit on the chain but will be the ISA interface, but even in the worst case of 10Mb/s is huge for a 486 class machine, that coupled with a extremely low access time and a free cpu for the drive accees can be a good situation.

There are DOS drivers for the 2940U2W controller.
Have you loaded them?

ElectroSoldier wrote on 2023-12-31, 15:38:

There are DOS drivers for the 2940U2W controller.
Have you loaded them?

no, why? computer with 2940 have win98 and zero issue

I thought you wanted DOS on that computer?

Or is this a Swiss army penknife build?

ElectroSoldier wrote on 2023-12-31, 15:51:

I thought you wanted DOS on that computer?

Or is this a Swiss army penknife build?

Yes, but the computer with 2940u2w is a pentium200Mhz and is full functional, the computer with 1542CF is a 486 one and have "some" problem. two controller in two computer.