For visibility, i have dtk pem 4036y and yb versions.
Tested with ess1869 in win 311.
Seems to work.

Do your drivers have the "single mode DMA option"? If not, maybe the drivers for 1869 are already in single mode DMA mode by default?

feipoa wrote on 2024-05-04, 02:29:

Is there any performance benefit in using single-mode DMA vs., presumably, multi-mode DMA?

There is a performance draw-back in using single-mode DMA. The full name would be "single-cycle mode DMA". Single Mode DMA is the simplest mode of DMA, and using it for high-bandwidth applications is not desireable. For an expansion card, the modes are very similar, and likely many sound chips are designed to work in both the "single cycle" and the "demand" DMA mode. Regarding your presumption "multi-mode DMA", it's not that far off if you are thinking of IDE Multi-Word DMA: The IDE DMA mode (later called single-word DMA mode) is based on the 8237 "single-cycle mode", and the IDE multi-word DMA mode is based on the 8237 "demand mode".

There is one key difference between the single-cycle and the demand mode: The original 8237 is "too stupid" to interrupt an on-going DMA transaction, even if a higher-priority DMA request comes in. So one a device got its DMA request granted, the DMA controller will only serve this device until "the transaction is over". The difference between "single-cycle mode" and "demand mode" is the way it is decided whether "the transaction is over": In single-cycle mode, as the name says, every grant only performs one cycle (8 bit on DMA 0-3, 16 bit on DMA 5-7), and then "the transaction is over". If the device still requests DMA, a new arbitration will happen, and unless a higher-priority request is there, another single cycle will be granted to that device. This re-arbitration is not just inside the DMA controller, but at the end of every DMA transaction, the DMA controller relinquishes bus ownership, and needs to re-arbitrate for the bus itself. As an arbitration happens after every cycle, this is the slowest possible DMA mode. Demand mode behaves slightly different: It works just like single-cycle mode, but at some point before the end of that single cycle, the DMA request line of the device currently in service is checked, and if it is still asserted, another DMA cycle will be performed without re-arbitration.

To understand why there is an issue about (re-)arbitration, and why the preceeding paragraph is relevant for the PC architecture, you need to understand that on the classic PC/AT architecture, memory refresh is reflected on the ISA bus, to assist ISA-based memory expansion cards. A memory refresh cycle is requested every 15.6µs, but it can't take place while the bus is owned by the DMA controller. On the PC, memory refresh uses a DMA request to channel 0, the highest-priority channel on the 8237 to claim bus ownership. On the AT, the memory refresh logic is dedicated, and can only take ownership if no DMA transaction is active. In either case, there won't be a memory refresh cycle interrupting a DMA transaction, so any ISA device using DMA has to make sure that no refresh cycles get lost due to blocking the bus for too long. While I don't have any hard specification at hand right now, the accepted maximum DMA transaction time 13µs to 15µs. With single-mode DMA, this is not an issue at all: No single cycle may take that long (you can make cycles take that long by adding enough wait-states, but this is also forbidden, independent of DMA design), and once that single cycle is over, re-arbitration of the bus will pass over to DMA0 (on the PC) or stall the DMA controller for getting the bus re-granted until the refresh cycle completes. On the other hand, in demand mode, the device is responsible for not keeping its request line active for more than 15µs.

In the case of sound cards, the 15µs limit is not an issue, because the sound card can use demand mode only to fill an internal FIFO of typically 16 items. Transferring 16 items at 4MHz DMA clock might hit the 16µs limit, if every cycle takes 4 clocks, but usually you don't hit an completely empty FIFO every time DMA is requested, so this will just work out. The idea of sound cards using a FIFO is that you rely less on DMA latency, so the higher the sample rate, the more important it is to have a FIFO to be able to continue playback while you can't own the bus. As soon as a sound card has a FIFO (e.g. on Creative Labs cards, starting with the SB16), it makes sense to run the DMA controller in demand mode to reduce bus load by avoiding frequent re-arbitrations. This is especially important if a card plays 16-bit stereo samples through an 8-bit DMA channel. You get corrupted sound playback in two cases:

• The DMA controller is set to single mode, and the bus overhead caused by using single mode DMA prevents the card from getting the required throughput. Many cards don't handle buffer underflow gracefully, and especially with 16-bit samples, if a single 8-bit transfer is missed, the card starts mixing up high bytes and low bytes, causing a lot of static-like noise. This is an issue for WSS-type cards (AD1848/CS423x).
• The DMA controller is set to demand mode, but the timing for relinquishing the DMA request is off, such that the DMA controller performs an extra cycle while the card already tried to end the transaction. This extra cycle on a full FIFO may cause a single byte to get lost, causing the same misalignment issue as described above. The root cause for "the timing is off" might be either on the mainboard side (sampling DRQ too early) or on the card side (negating DRQ too late), and the DMA controller clock clearly influences how early the DMA controller samples.

While there are a lot of appropriate criticisms to the architecture of Creative Labs SoundBlaster cards, this is one thing Creative seems to have gotten perfectly right with their SoundBlaster 16 architecture, which handles DMA underruns during playback perfectly by just repeating samples on underrun.

So, what is the take-away for you: If a driver doesn't offer the choice between single-cycle mode and demand mode, the only way to use the other mode is patching the driver at the point where it requests ISA DMA (either by talking to the DMA controller, or requesting it from a kernel-level DMA driver). Also, if you have issues with demand-mode DMA that vanish when using single-mode DMA, an overclocked DMA controller (related to ISA clock!) or a bad contact on the DRQ line hampering signal response time might be the root cause.

This is the best explanation I've seen of single mode vs. demand mode for sound cards. I can see why demand mode is the default mode now. I tried running the ISA at 10 MHz and 8 MHz, but it doesn't help the situation when using demand mode.

I've attached an image of the CMOS settings if you think there's something in here which might be causing this. Note that in this BIOS, CLK2 = FSB, not the crystal oscillator freq. So if crystal = 80 MHz, then ISA = (80/2)/4 = 10 MHz.

Also, I'm using an AHA-1522B SCSI controller, which uses PIO for tranfers, but still has a DMA channel setting, which I set to 6.

I have another Symphony 461-based board with the same BIOS I will try next.

feipoa wrote on 2024-05-05, 22:09:

Also, I'm using an AHA-1522B SCSI controller, which uses PIO for tranfers, but still has a DMA channel setting, which I set to 6.

In fact, that controller can use DMA, both 8-bit DMA and 16-bit DMA (you can set it to DMA0). On the other hand, ISA DMA causes a lot of trouble (extra virtualization and/or VDS required with EMM386, 16MB barrier, 128KB barrier, low clock of the DMA controller) that it is just not worth it, as the competing mode is "REP INSW" taking 128 bytes at a time, which is the default transfer mode for that controller. One of my too many started-and-postponed project is creating a representative microbenchmark for the 1522B DMA performance and if I get good numbers, trying to make a ASPI driver that can use DMA transfers.

I agree with Adaptec that AT-style DMA, even at 16 bit, doesn't cut it. Did you know that there actually is one situation in which an official Adaptec driver actually uses DMA on the 1522B? It's the OS/2 driver in mainboards with EISA chipsets. That's because non-IBM learned a lot from the shortcomings of the cheap-but-crappy AT-style DMA, and shipped a vastly improved version of it as part of the EISA specification. The EISA DMA controller has the following highlights:

• The 64KB/128KB page wraparound is a compatibility feature which can be disabled.
• There are 8 extra address bits, allowing full 4GB coverage
• The behaviour of the 8237 is available in the default "legacy" mode, but there are two improved modes that can be used with ISA DMA targets (but only with mainboard RAM as counterpart), called Type-A and Type-B DMA, which only differ in the amount of wait states.
• Type-A and Type-B DMA can be interrupted by a higher priority DMA request. For a conforming card, this won't be a problem, because a DMA target will wait for its DACK line to be pulsed for every transfer, not just every transaction. If a transaction is interrupted, the DACK line of the victim target will not be pulsed during the interruption, so it will just look like an excessive delay between two cycles.
• There is hardware to process scatter/gather lists.
• There is a special burst mode DMA called Type-C DMA. Type-C DMA is only available for EISA hardware, because it requires burst handshaking signals.

The interruptability of Type-A and Type-B transfers is a great win, because this allows a short interruption of a DMA transfer for memory refresh on the ISA bus without the Adaptec 1522 actively negating its DRQ line, which allows a significantly faster continuation after the interrupting event is over. If used in conjunction with Type-A and Type-B DMA, the optional feature to periodically drop DRQ can be disabled by the driver for the 1522B card. The setting to control the periodic DRQ drop are called "bus on time" and "bus off time", and the best-performing configuration for conforming legacy-type DMA is 15µs "bus on" / 1µs "bus off". In Type-A and Type-B configurations, you can use infinite "bus on" instead. This makes a very noticable difference.

While most people do not have an EISA mainboard at home, most Socket-5/7 PCI chipsets supports "Type-F" DMA, which is a slightly faster variant of "Type-B" DMA, including interruptability. Enabling Type-F DMA on the Adaptec channel is a noticable performance benefit in my preliminary edition of the micro benchmark, which might be enough to make DMA a viable choice for data transfer. Furthermore, the Intel Saturn II chipset is not providing EISA slots, but its south-bridge supports all EISA DMA features that work with EISA cards (i.e. everything except bursts). With the Saturn II southbridge, you get the removal of the 16MB limit, the removal of the 128KB wraparound and interruptability of ISA DMA, as well as scatter/gather support. This would be great if there were a critical mass of software support for it... With Socket-7 PCI mainboards, you just get higher speed, but all the other ISA DMA annoyances are still threre.

(sorry for derailing the thread, if you want to discuss DMA on the 1522B any further, this should be split off)

feipoa wrote on 2024-05-05, 22:09:

Note that in this BIOS, CLK2 = FSB, not the crystal oscillator freq. So if crystal = 80 MHz, then ISA = (80/2)/4 = 10 MHz.

Are you sure about that? Typically, CLK2 means the doubled clock signal. Possibly they actually mean CLK2, but Bus clock is twice the ISA clock, which would be identical in the end to your way of explaining "CLK2 actually means CLK". I don't see any obvious setting that can help make demand mode more stable, though.

I tried the AHA-1522B with DMA off, however I still could not use demand mode DMA with sound in Windows. I may need to use a different sound card entirely. Unfortunately, all SB16 type cards I have tested didn't work properly with a wavetable board in the games I've tested. I'm running low on usable ISA sound cards. The ES1868 had worked great on every system until now.

Yes, normally CLK2 refers to the crystal oscillator frequency when selecting the ISA bus clock speed. Sometimes BIOSes have CLK and CLK2 flipped from my normal understanding. I've come across a few times with 386 motherboards, so I always measure the ISA frequency with my oscilliscope. The options for ISA bus clock are:

CLK2
/
2, 2.5, 3, 4, 5, 6, ATCLK2

When selecting the ISA clock on this board, I must replace CLK2 with CLK to arrive at the correct values shown on the scope.

If CLK2 was really CLK2, then the lowest ISA clock with a 80 MHz crystal would be 80/6 = 13.3 MHz, which is too fast.

Your postponed project for the AHA-1520/1522B sounds very interesting. I find the 152X more DLC/SXL friendly compared to the 1540 series.

No I wasn't aware that OS/2 had working 152X DMA mode for EISA chipsets. Too bad its for OS/2 only. There isn't too much retro interest in that OS. I do have a dual socket 5 PCI/EISA system though. At any rate, I'd be interested to test your benchmark if you ever finish it, along with the ASPI for Windows.

I hear the same white noise on the other Symphony based 461 board (all other hardware the same).

feipoa wrote on 2024-05-06, 00:33:

I hear the same white noise on the other Symphony based 461 board (all other hardware the same).

I just checked photos of the DTK PEM-4030Y and noticed that it doesn't have a 82c206 IRQ/DMA/Timer controller chip, but that functionality is included in one of the three big Symphony chips, the 461, the 362 and the 485. Maybe their 206 variant is marginal and incompatible with your sound card in demand mode (sampling DRQ for continuation at an unsuitable point in time). It would be interesting to know whether this problem only appears with DMA controllers by certain manufacturers. As you likely know, every major chipset vendor had their 82c206 edition in the sales catalog. Possibly all of them were licensed copies of the C&T design, though.

I have an Yamaha OPL3SAx sitting with my US-based reshipping guy, but am not ready to ship my stuff yet. Thus, I am not sure when I can get back to this. I don't want to pillage sound cards from my other systems as it always seems to mess something up.

Right now I'm trying transplant the hardware onto my SiS Rabbit based board to ensure it can use demand mode DMA sound with this hardware combination. I'm also using a Promise Floppy Max card, which lets me have BIOS/boot support for LS-120 diskette drives. Maybe it or the SCSI card is messing up the sound. I don't think the Floppy Max uses DMA though.

With any luck, someone will come along who is interested in adjusting the NT 3.51 sound driver for single-mode DMA. As long as DOS still uses the demand mode DMA, it would be an acceptable compromise to have single-mode sound in Windows.

Using all the same hardware from the Symphony-based motherboard (PEM-4030Y), placed into a SiS-based motherboard (Chaintech 340SCD), then booted Win3.11 with ES1868 in Demand mode DMA (non-single mode DMA), and the sound worked fine (no white noise). Testing at only 66 MHz.

Next, I ran WinPlay3 using a 64 kbps, 11 Khz, mono mp3 file. After about 40 seconds, I start to hear occasional skips, perhaps once every 8 seconds. This usually happens when the CPU isn't fast enough to decode the mp3 file and is expected on this class of system. I ran the same test with the drivers set to demand mode DMA and single-mode DMA, but the playback was identical. I was hoping that demand mode, being more efficient than single-mode DMA, wouldn't have these occasional skips after 40 seconds of playback, but it did.

I'm not sure what else to test to demonstrate the increased efficiency of demand mode DMA. Nonetheless, this test demonstrates the issue is with the Symphony 461/362 /465 chipset in combination with the ES1868 sound card.

feipoa wrote on 2024-05-06, 03:10:

I'm not sure what else to test to demonstrate the increased efficiency of demand mode DMA. Nonetheless, this test demonstrates the issue is with the Symphony 461/362 /465 chipset in combination with the ES1868 sound card.

As the increased efficiency mainly targets ISA bus usage, try something else in parallel that requires the ISA bus. Like trying to play a video on an ISA graphics card, or copying files from/to an ISA disk controller. It doesn't matter whether you use an IDE controller or your AHA-1522B, as long as you are not bottlenecked by the attached hard drive. This might help to demonstrate that you got more remaining ISA bandwidth in demand mode. I'm not sure you are actually able to measure the effect, though.

Furthermore faintly remember that on a cheap SBPro/WSS card (sorry, I don't remember whether it was OAK, Opti or some other competitor), I got this static noise you describe 25 years ago when I tried dragging around full Windows in Windows 95 (a Plus! pack feature) with an unaccelerated graphics card (likely an ET4000AX), but only in single DMA mode in WSS mode. If the ESS chip handles DMA underruns better than the WSS codec on that card, you might not be able to reproduce this experience with your card, though.

I'll save these tests for when I have my other SXL2-66 system out. Multi-tasking on a Windows 3.1 system, let alone a 386 class system, isn't something that usually occurred in the natural course of things. This makes me think that the demand mode DMA vs. single-mode DMA comparison may be better suited for a 486 or later system. Similarly, since NT was more targeted for multi-tasking, this may be why the option for single-mode DMA was omitted from the driver options.

I did try two different ES1868 drivers for NT 3.51, versions 1.03 and 1.06.09, both of which didn't have the single-mode DMA option.

I managed to find a Yamaha OPL3SAx card at the bottom of a box. I installed the NT 3.51 drivers, but just like the ES1868 card, all I hear is white noise when trying to play wave or mp3 files. As with the ES1868, midi playback is also working on the OPL3SAx. Unfortunately, the Yamaha drivers also do not have any option for single-mode DMA. Looks like my SXL2-90 system will be limited to sound in Win3.11 due to the single-mode DMA option.

Replaced the AHA-1522B SCSI card with an ISA IDE card. Played sound in Demand Mode DMA, heard only static. Set to Single-Mode DMA, sound plays fine. Thus, the issue with sound was not related the SCSI card.

Conclusive update:

Someone came forward with a fixed ESS driver to enable single-mode DMA in NT 3.51 and NT4. Sound is now working in all 4 operating systems (w31, nt351, nt4, w95) on my Symphony 461/362 system. It is unfortunate that the original NT-based drivers for the ESS sound card didn't have a front-end configurable 'single-mode DMA' option.

feipoa wrote on 2024-05-09, 07:39:

Someone came forward with a fixed ESS driver to enable single-mode DMA in NT 3.51 and NT4.

See Re: Windows 95 VMCPD.VXD blue screen freeze on boot when FPU installed. Any ideas?