If possible to put Sound blaster 16/Compatible chips on a PCI-E board

Not without onboard bridge chip, but it won't help with DOS stuff.

the southbridge would still make it not work, correct?

Modern motherboards don't have "south bridge" or PCI bus.

No need to apologize; you are completely understandable.

For a sound card to work in DOS, it has to be able to talk to IRQs, ISA-style DMAs, and x86 IO ports.

IRQs are not too hard. PCI devices can use the same interrupt scheme as ISA devices, although the PCI pins behave differently. PCI-E devices can talk to the Advanced Programmable Interrupt Controller (APIC). PC/PCI aka SB-Link is best, as it supplies the SERIRQ signal from the LPC bus to the PCI device, but that signal is not found on the PCI or PCI-E connector and has to be connected separately.

ISA style DMAs are harder for PCI and PCI-E systems. You mentioned having a Yamaha 7xx PCI card. That card has support for all three possible ways of talking to the DMA controller:

• PC/PCI aka SB-Link provides a dedicated DMA pin (connected to the LPC bus or the motherboard's PCI-ISA bridge). Unless the chip is physically mounted to the motherboard, then a cable must be connected from the card to the motherboard, as the signals are not present on the PCI connector.
• Distributed DMA (DDMA) requires support in the motherboard chipset and an implementation in the PCI device. Since it's only ever been used for sound cards IIRC, support for it disappeared from chipsets once DOS gaming was thoroughly defunct commercially. AFAIK no PCI-Express chipset includes support for it; someone correct me if I'm mistaken.
• DSDMA is a software hack. It is possible to "trap" or DMA requests with a TSR with some help from HIMEM.SYS. The TSR driver then translates the old-style DMA for the PCI device. This requires the CPU to be in "Virtual 8086 mode" instead of true "Real Mode". Most games work fine with this, but a few do not.

As I understand it, PCI-E devices can talk to x86 I/O ports, but almost never do, because that mechanism is really slow for real work nowadays. Calls to x86 I/Os can also be trapped by a TSR with the same caveats as DSDMA.

Since modern motherboards don't have a PC/PCI header (and haven't for literally decades), the trick is getting those signals to a hypothetical PCI-E sound card so we can avoid using a TSR. Almost every motherboard still has those signals somewhere, since the LPC bus is still a thing, and LPC is just a fancy serialized ISA bus. A few motherboards have LPC bus headers, others have solder points or test points with the LPC bus, and others would require soldering wires to a Super I/O chip or something else tied to the LPC bus.

The Serpent Rider wrote on 2020-12-03, 14:25:

If possible to put Sound blaster 16/Compatible chips on a PCI-E board

Not without onboard bridge chip, but it won't help with DOS stuff.

I think the industry faced these issues in the late 90's when they moved to PCI sound cards.

Is this a good summary of the issues?

1. The creative lab chips want to do DMA over an an ISA bus, and I don't think PCI or PCI-E does DMA the same way that ISA did. If you wanted to use soundblaster chips, you would need a bridge chip to translate ISA to PCI. I suppose it could be possible to adapt this bridge chip: http://arstech.com/install/ecom-prodshow/usb2isa.html but it wouldn't be cost effective.
2. DOS programs expect to use ISA IRQ & DMA, so you would need some sort of real mode TSR program that emulates the ISA hardware and feeds the data to PCI-E, like we saw with PCI sound cards in the late 90's.
3. Many DOS programs were very sensitive to exact hardware timing on soundblaster DMA & IRQ tasks, so by the time add the TSR & Bridge chips, you probably won't have the level of compatibility that you want, because the IO would not occur at the same speed that it would over the ISA bus.

The short story is that its easier to emulate a sound blaster chips in a VM than it is to try to bridge all the calls to a real soundblaster chip over a PCI bridge

One other thing - the firmware on many very recent motherboards have dropped legacy BIOS support and are completely UEFI. Without legacy BIOS support, one cannot install or boot into DOS or Win 9x at all.

LightStruk wrote on 2020-12-03, 14:57:

One other thing - the firmware on many very recent motherboards have dropped legacy BIOS support and are completely UEFI. Without legacy BIOS support, one cannot install or boot into DOS or Win 9x at all.

That's where VMs come into play.. and stuff like DOSBox.

And there may be a solution possible that I will be working on the software side pretty soon... but the hardware is not cheap.

douglar wrote on 2020-12-03, 14:55:

[*]The creative lab chips want to do DMA over an an ISA bus, and I don't think PCI or PCI-E does DMA the same way that ISA did. If you wanted to use soundblaster chips, you would need a bridge chip to translate ISA to PCI. I suppose it could be possible to adapt this bridge chip: http://arstech.com/install/ecom-prodshow/usb2isa.html but it wouldn't be cost effective.

The author of the USB2ISA STM32 implemented hardware and patches for PCEm said the bandwith of the adapter is enough for hardware MIDI, but may not be enough for PCM. Even USB3.0 seems to have too much latency for this task. Maybe for this task an PCIe/ISA backplane makes more sense? Or Firewire in bus mastering mode?
https://www.youtube.com/watch?v=5jW1dGRhmsE

This wouldn't be cheap in any case.

hyoenmadan wrote on 2020-12-03, 17:02:

The author of the USB2ISA STM32 implemented hardware and patches for PCEm said the bandwith of the adapter is enough for hardwar […]
Show full quote

douglar wrote on 2020-12-03, 14:55:

[*]The creative lab chips want to do DMA over an an ISA bus, and I don't think PCI or PCI-E does DMA the same way that ISA did. If you wanted to use soundblaster chips, you would need a bridge chip to translate ISA to PCI. I suppose it could be possible to adapt this bridge chip: http://arstech.com/install/ecom-prodshow/usb2isa.html but it wouldn't be cost effective.

The author of the USB2ISA STM32 implemented hardware and patches for PCEm said the bandwith of the adapter is enough for hardware MIDI, but may not be enough for PCM. Even USB3.0 seems to have too much latency for this task. Maybe for this task an PCIe/ISA backplane makes more sense? Or Firewire in bus mastering mode?
https://www.youtube.com/watch?v=5jW1dGRhmsE

This wouldn't be cheap in any case.

Why would the latency be too high? The throughput of USB 2.0 is 480Mbps (60MB/s) minus overhead. And if you need lower latency, just up the USB polling rate.

USB 1.0/1.1 of course isn't enough and the latency on USB 1.0/1.1 is horrid.

Even if you went PCIe to ISA, you would have to have some sort of bridge chip and software to capture all the HW addresses and forward them through.

It would probably be easier to do something via networking and have server and client programs.

cyclone3d wrote on 2020-12-03, 17:46:

Why would the latency be too high? The throughput of USB 2.0 is 480Mbps (60MB/s) minus overhead.

Is much, just not fast for ISA usage. I understand it as a "ferrari vs a truck", one carries more weight, but is slower. The other carries less, but is faster.
In any case, I'm not the one who developed the hardware and the patches, so i don't know or understand the technical details why even USB3 isn't fast enough for ISA hardware timings. But I don't think they would want to constrain their hardware on purpose. There should be a real technical reason why they said that.

The chipsets used on ISA soundcards have the ISA bus interface built into them.

And USB is slow (latency) because like almost all networking protocols it involves buffering (among other things), which bus-level communication does not.

cyclone3d wrote on 2020-12-03, 17:46:

And if you need lower latency, just up the USB polling rate.

Hi,

I built that project.
As far as I'm aware (and I'm not a USB expert by any means), USB FS has a fixed frame timing at ~1ms per frame. USB HS can do 125µs per frame.
Even with 125µs, that's only 4000 bytes/s, aka 4KiB/s. And that's in the best possible case with no additional latency due to PC or STM32 related delays.
There's no way to do any larger reads, as the execution of the emulator and also the behaviour of the cards is directly dependent on every single byte-wise read/write transaction.

Manawyrm

manawyrm wrote on 2020-12-03, 20:49:

Hi, […]
Show full quote

cyclone3d wrote on 2020-12-03, 17:46:

And if you need lower latency, just up the USB polling rate.

Hi,

I built that project.
As far as I'm aware (and I'm not a USB expert by any means), USB FS has a fixed frame timing at ~1ms per frame. USB HS can do 125µs per frame.
Even with 125µs, that's only 4000 bytes/s, aka 4KiB/s. And that's in the best possible case with no additional latency due to PC or STM32 related delays.
There's no way to do any larger reads, as the execution of the emulator and also the behaviour of the cards is directly dependent on every single byte-wise read/write transaction.

Tobias

Ok. I was doing a bit more reading and it looks like the polling rate is only for the usb devices to send data to the usb port. Looks like the USB port can send data to devices whenever it wants.

The throughput you are talking about sounds to me like that is just for interrupt packets. See here:
https://en.wikipedia.org/wiki/USB_(Comm ... 0940%20ns.

I have a couple of those ARStech USB 2.0 to 3-slot ISA adapters. My plan is to take their DOSBox code and then modify the regular newer DOSBox code so it can pass PCM data as well instead of just OPL and MIDI.

Edit: I somehow missed your thread about this. I have it in my watch list now.

The throughput of USB 2.0 is 480Mbps (60MB/s) minus overhead.

Actually, USB 2.0 tops out around 35 Mb/s, so 480 Mbps is more or less bogus even with practical overhead included.

The Serpent Rider wrote on 2020-12-03, 22:58:

The throughput of USB 2.0 is 480Mbps (60MB/s) minus overhead.

Actually, USB 2.0 tops out around 35 Mb/s, so 480 Mbps is more or less bogus even with practical overhead included.

Yeah, I know. I wonder under what perfect scenario they ran those tests at.

Still, 35MB/s is still way more throughput than ISA can do.

I'm not 100% sure how the latency of USB is going to relate to transferring the PCM data to go to an ISA sound card but I really don't see how it could be a problem.

I mean, there are USB sound cards. Stuff like the USB SB-Live! and Audigy 2 NX. Certainly you are not going to have more data for a 2-channel ISA card than you are for a USB sound card that supports 7.1.

There are a ton of USB audio devices out there and they don't really have problems with latency for the most part. The USB 1.0 based ones did, but that pretty much went away with USB 2.0.

Stuff like MIDI input timing can be wonky, but just dumping the data to an external device really should just work. It's not like the ISA bus isn't shared either.. and with USB, you could plug a USB device into a separate controller.

Maybe I am thinking about this completely wrong....

I wonder under what perfect scenario they ran those tests at.

USB is half-duplex, which eats away a lot of bandwidth. And while ISA is slow - it's full-duplex.

So, let's pretend emulation isn't an option.

Looking back at the bridgeboard for the Amiga platform (m68k), that had an intel cpu on board, ram and a lot of other things, it'd draw a window on workbench as far as I recall, and some software even let you use hard drive images to install ms-dos on to run on the amiga. It either used the onboard disk station for floppies, or had headers for an internal/external solution.

Would such a thing not be possible either? With all the passthrough going on in virtualization these days, a board with a CPU, Sound, etc, like a single board computer. I guess, kind of like the Blizzard series has a PPC chip on board, with software the can utilize it. However, a bridgeboard I think would better fit my example. I know they had to do this because of different architectures, however, is that not possible anymore?

Bear in mind, looking away from emulation and other SBC options, like the raspberry pi and the like.
I'm also not trying to brainstorm this as an idea, as I'm sure it's been well thought out before. I'd like to learn from the experts, or be pointed in the right direction if there are other places I could learn about such things.
I also know that the whole bridgeboard thing is device specific and everything, but I'm left wondering that in a day and age with less specific devices and more general devices, if such a thing can't be done anymore.

I'm sure a bridgeboard type setup could be made.. but at what cost. Throughput would not be a problem. You would have to have an in-between software like the USB options have in order to capture and send the data to the slave card or whatever.. but it should be doable. You would still be running the software through DOSBox or similar and it would have to have passthrough code to either send it directly to the bridge or to the middleware software.

My plan for the USB2ISA adapter is to first get it working for DOSBOX in XP.. and I could even test with sound cards in XP which already supports direct hardware access so I wouldn't have to worry about as much as trying to get it working through DOSBox in newer OSes.

Super simple setup.. just install the software for the adapter, install an ISA sound card such as a sound blaster 16 or whatever that XP has built-in drivers for and test it out.

mikedebian wrote on 2020-12-17, 18:08:

Would such a thing not be possible either? With all the passthrough going on in virtualization these days, a board with a CPU, Sound, etc, like a single board computer. I guess, kind of like the Blizzard series has a PPC chip on board, with software the can utilize it. However, a bridgeboard I think would better fit my example. I know they had to do this because of different architectures, however, is that not possible anymore?

x86 never was really designed with measures for "computer in computer" hardware in mind. The closest to this was VLB "Shablamm MIPS" coprocesor card, which could "parasite" a 486 board and take control of it, disabling the 486 CPU, but using onboard ram, chipset, ISA Bus peripherals and other stuff on it. Check you could select in software to keep booting to 486 mode and use DOS/Windows, or boot to the Card, effectively disabling 486Bus and using MIPS card CPU in place to boot NT/MIPS. BUT you couldn't use both at same time.

Then came PCI architecture, which doesn't allow this to happen. Sure Apple and others have modified their chipsets to violate the Spec a bit and allow ProDOS/ProWindows cards to work in Apple Macs, but this never has been done in any mainstream x86 pci chipset as far as I know. Then there are some Compaq chipset/board designs which allow you to have asynchronous SMP, using one CPU for the OS and making the extra CPUs act as coprocessors which can be assigned to applications, but this only works in NT and needs an specific Compaq HAL.

Then Hypertransport and Intel CSI "busses" allow alien architecture CPUs to be used as coprocessors for applications, but PCIe doesn't allow this. I dunno if these would allow for more complex bridge boards, but is moot point as none of these are presented as slots anymore, but sockets for chip packages.

PD: Come to think about it, the only platforms which supported "bridge cards" or similar sort of "computer-on-computer" hardware were the ones who exposed certain pins of the CPU to the peripherals in one way or other. This doesn't seem possible in PCI translator-based platforms, as it doesn't expose, and doesn't allow to expose CPU pins to the peripherals, unless you violate the spec like Apple.

What I'm wondering is how feasible would it be to make a PCMCIA Type-II implementation of some of these newer cards. That would open the door to a lot more older laptops as gaming rigs. esp if someone could figure out how the whole Panasonic CF-VEW series cards re-route the audio through the internal speaker. Think of that, a Soundblaster in a PCMCIA Type-II card that does not need some kind of dongle. I'd be buying one to slap in my Versa 40EC as soon as I could afford it.

PCMCIA FPGA soundcard would be really cool. Dongle is pretty much guaranteed required for MIDI, though you could probably fit 3.5mm jacks on it.

As far as PCI-e FPGA sound cards, your best bet would be to use the FPGA as a hardware assistance to DOSBox or PCEM or something else, in a similar way to DOSBox being able to use a real OPL2LPT. Forget about running real DOS on a modern system, that's a losing battle as hardware progresses, and also means you can't do other modern things at the same time.

Going further, as FPGA technology gets denser and denser (and x86 PC implementations improve, too) you could have a program on your main system that's pretty much the equivalent of a Teamviewer window to an entirely FPGAd system. In short, an FPGA bridgeboard. Could even maybe even share local storage to it like some bridgeboards did, though it'd be funnier (but much less practical) if it had a floppy header to put a real floppy drive in your case. Though I guess that would be nice to have since there's a dearth of good PCIe floppy cards. Could even read kryoflux format if you wanted, probably.

Bridgeboard approach solves the latency issue pretty much completely, and means you could also potentially make the bridgeboard-window software reprogram it to virtualize other systems in the FPGA in your system. You also don't have to worry about BIOS vs UEFI or other hardware incompatibilities and could plausibly even condense the board to an M.2 slot and use it in a laptop, supposing the laptop doesn't reject non-drive M.2 devices.