Making SCSI-equipped sound cards bootable?

[ltning]

Hi all, apologies if this is the wrong forum - please educate me if necessary.

I'm toying with the idea of making some of my SCSI-enabled sound cards bootable. I have several SB16 and Orchid SoundWave32 cards, and a small handful of others, that have either an Adaptec, NCR, Trantor or Future Domain chip on them (there may be others, I can't recall right now). It occurs to me that by using the same approach as with XTIDE - sticking a suitable BIOS on a NIC or something like that - it might be possible to make these cards bootable.

For some reason - call it a gut feeling - I suspect my best chance is with the Future Domain-equipped cards, but any information you could provide to help me decide which end to start (or not!) would be appreciated.

I foresee, first and foremost, problems getting the BIOS to recognize the chips at all. If they aren't at any of the I/O ports the BIOS expects, or if the card needs NVRam for the BIOS to even load, then nothing's going to work. But I'm kinda hoping that I can find a BIOS dumb enough to load and let me set run-time settings, even if it cannot save the settings. I realise this means I'll need to configure it at every boot, but defaults are often good enough to get it to boot from a SCSI HDD (or ZuluSCSI, as the case might be).

Anyway, asking just in case someone can warn me not to go down this rabbit hole.

/Eirik

 

[MiaM]

Sorry if I'm Captain Obvious here, but:
At least in theory you have two options. One would be to modify an existing BIOS from a "regular" SCSI card using the same chip as a sound card, or write your own, probably based on the XTIDE Universal BIOS plus perhaps code from the Linux and/or some BSD flavor kernel.

IIRC there were at least one motherboard back in the Pentium-1 days where the motherboard BIOS supports booting from one particular type or group of SCSI cards without it's own BIOS, similar to how 286 and newer will boot from the most common type of MFM and IDE/PATA controllers without any BIOS on the controller.

I would think that making your own BIOS seems like the better option, given that the XTIDE Universal BIOS already is a good base to build upon and it handles all interaction with the PC BIOS, DOS and things like allowing the user to select boot device and whatnot.

A thing that might differ between sound cards and "real" SCSI cards is that I wouldn't count on sound cards having an interrupt and/or using DMA. IIRC 16-bit ISA DMA is slower than PIO anyways, but still.

Maybe check if Linux (or any BSD) can use these cards as a generic SCSI controller.

I would think that it would be a good idea to start writing your own code that just reads a few blocks from disk, based on the chip data sheets and/or the Linux (or BSD) Kernel code, would be a good start. An intermediate step could be to write a driver loadable in CONFIG.SYS that adds SCSI disks. Or maybe skip this intermediate step as I just realized that I forgot that we have EEPROM based cards and great emulators like 86box to test a "real" BIOS on.

If you succeed the end product could obviously go into the boot rom socket of a network card, or for that sake be part of the XTIDE Universal BIOS (or perhaps rather a fork of it?) as IIRC there are space left in the 32k EEPROM.

 

[Timo W.]

sticking a suitable BIOS on a NIC or something like that - it might be possible to make these cards bootable.

Do you have a NIC installed already? If not, just install a proper SCSI controller instead, it would cost you one free slot anyway.

If you have, all you need to find is the firmware from a SCSI controller that uses the same chip as on those sound cards and set the i/o port to one supported by the firmware. Issue could be that for PnP sound cards, resources may have not been assigned when the firmware is executed. That would be a dead-end then.

Another issue is that the SCSI ports on sound cards were cut-down for CD-ROM drive operation only. Even if you find the correct firmware for the chip, it may fail to work due to missing components on the sound card.

 

[MiaM]

Another issue is that the SCSI ports on sound cards were cut-down for CD-ROM drive operation only. Even if you find the correct firmware for the chip, it may fail to work due to missing components on the sound card.

What does/did this actually mean?

To me it sounds like they either didn't supply a boot rom, or something in the hardware (perhaps the presence/absence of a boot rom?) acts as a dongle for running loadable drivers to access anything else than optical drives.

I.E. say for example Adaptec would sell a SCSI chip to a sound card manufacturer but only if they does something to the hardware that makes the generic Adaptec drivers to not work, in order for Adaptec to be able to sell their SCSI cards for more money than what a customer would pay for the SCSI part of a sound card.

 

[Plasma]

I would think that making your own BIOS seems like the better option...

Ah yes, the old "left as an exercise for the reader."

It will be light years easier to use an existing SCSI BIOS, with minor modifications if necessary.

 

[Plasma]

For some reason - call it a gut feeling - I suspect my best chance is with the Future Domain-equipped cards, but any information you could provide to help me decide which end to start (or not!) would be appreciated.

I foresee, first and foremost, problems getting the BIOS to recognize the chips at all. If they aren't at any of the I/O ports the BIOS expects, or if the card needs NVRam for the BIOS to even load, then nothing's going to work. But I'm kinda hoping that I can find a BIOS dumb enough to load and let me set run-time settings, even if it cannot save the settings. I realise this means I'll need to configure it at every boot, but defaults are often good enough to get it to boot from a SCSI HDD (or ZuluSCSI, as the case might be).

I would start with the Orchid SoundWave 32 and a Future Domain 8.x BIOS.

 

[MiaM]

Ah yes, the old "left as an exercise for the reader."

It will be light years easier to use an existing SCSI BIOS, with minor modifications if necessary.

If you are highly skilled at x86 machine code, including figuring out any traps in an existing bios.

Also, I'm not suggesting writing something from scratch, but rather start with the XTIDE Universal BIOS as a base for interfacing with the PC BIOS/software, and Linux/BSD kernel source code (or any other source code using the SCSI chip in question) on how to talk to the disk interface.

It can't be that hard.
I admit that I've never done this on a PC, but on the Amiga I managed to cobble together a driver for a DIY IDE/MFM interface using the source code for another disk driver and the official ATA spec.

A benefit of doing it somewhat from scratch is that the code can be written using modern standards. By that I both mean using tricks to improve performance that wasn't obvious at the time, or wouldn't had been feasible (I.E. separate versions for different CPUs would be easy to use today, but would had been a bad idea back in the days), and also offer a nice user interface at boot time like the XTIDE Universal BIOS.


Btw, I think I forgot to write a thing earlier:
Older DOS versions can only handle max two hard disks detected by the BIOS. Can't remember when this was changed, but say DOS 2 won't see any hard disk at all if BIOS provides a list of three or more disks, while DOS 6 will handle it perfectly. Thus a common thing for SCSI BIOSes is to not search for disks at all if you already have two IDE/MFM disks, and only search for one disk if you have one MFM/IDE disk, and only search for two disks if you don't have any MFM/IDE disks. Or rather perhaps search and list all devices, but only install 0/1/2 hard disks.
This is also something that an existing BIOS likely always would do, but nowadays when each hobbyist can easily use customized versions, you could have a switch to enable/disable this.

(Bonus: This wasn't really well documented in mainstream publications at the time, but 486 and newer motherboards that support four IDE channels would thus result in no hard disks seen at all by old DOS versions if more than two hard disks were configured in the CMOS/BIOS SETUP).

 

[Plasma]

If you are highly skilled at x86 machine code, including figuring out any traps in an existing bios.

Also, I'm not suggesting writing something from scratch, but rather start with the XTIDE Universal BIOS as a base for interfacing with the PC BIOS/software, and Linux/BSD kernel source code (or any other source code using the SCSI chip in question) on how to talk to the disk interface.

It takes much less skill (and time) to disassemble an existing BIOS and change a few lines. I have done this to configure both floppy and IDE BIOSes for other hardware.

 

[ltning]

Hey thanks all for the replies. I am not anywhere near a point where I can start disassembling, modifying and reassembling other BIOSes, and I'm not aware of any SCSI BIOSes where the sources are available. I was thinking about looking at XTIDE but talking to an IDE "controller" and talking to an SCSI *controller* are two very, very different things - IDE being pretty dumb and SCSI being comparatively "smart". Also I do not assemble anymore (it's a stretch to say I ever really did).

I think I'll go with the suggestion to try the Future Domain BIOS first. But I'm fairly sure I'll hit snags - the most obvious one being that there's no EEPROM to store data. What would be the most likely scenario here - that the EEPROM - if it exists - is hidden behind and programmed by the SCSI chip and therefore would need to be actually added to the board, or that it sits on some I/O address and is written to directly by the BIOS code?

Or are there other problems that are more obvious and that I'm missing?

 

[MiaM]

What would have to be stored in EEPROM? You would either have the BIOS add one or two hard disks, depending on what it finds on the SCSI bus, or do nothing if two disks are already configured (for older DOS compatibility). Or just add every disk found (if requiring newer DOS versions).

 

[ltning]

Settings? Without the EEPROM the best-case-scenario would be that whatever the BIOS defaults are would be fine; more often than not that's not the case, though. Also if the BIOS tries to read settings from the EEPROM and fails to do so, I don't expect it to actually work .. but I'll test one of these days.

 

[Plasma]

Settings? Without the EEPROM the best-case-scenario would be that whatever the BIOS defaults are would be fine; more often than not that's not the case, though. Also if the BIOS tries to read settings from the EEPROM and fails to do so, I don't expect it to actually work .. but I'll test one of these days.

Both the Orchid SoundWave 32 SCSI and Future Domain TMC-950 use jumpers to set the memory segment and IRQ. There is no EEPROM. So it is quite possible that it will work as-is.

 

[Vortex286]

I think the SB16 will be the easiest and the Orchid SoundWave32 will be the hardest.



For the SB16, stick a BIOS from an Adaptec AHA-1510/1520 into a NIC.

https://www.minuszerodegrees.net/rom/rom.htm
The Adaptec AVA-1515 BIOS may work but you need a card that expose 16KB ROM.

Most NICs only expose 8KB. You can split it over 2 NICs at consecutive addresses.



For the Orchid SoundWave32:
When you configure a TMC-950 card, you select a 8KB memory range and an IRQ.

The memory map is as follow:
0000h-17FFh BIOS 6KB
1800h-1BFFh scratchpad RAM 1KB
1C00h-1DFFh Control register 1 byte aliased 512 time (SCSI control lines + Enable parity and Enable Interrupt flag)
1E000h-1FFFh Data register 1 byte aliased 512 time (SCSI data lines)
The aliasing is used on the data port to transfer a 512 bytes sector with just a REP MOVSB

The BIOS expects to find its data segment and I/O ports at specific offset within its segment.

You either need to rewrite the BIOS or design a card that expose 6KB of ROM in the same segment as your sound card