superfury wrote:

- DMA by about 9 on average to get it's transfer rate in bytes/second?

The DMA controller runs at 4.77 MHz, so same as a stock PC/XT CPU. DMA controller speed is fixed, like the PIT speed, so they don't vary with CPU speed on later systems. They're always 4.77 MHz and 1.19 MHz respectively.

superfury wrote:

- Adlib output sampling frequency is divided by 288 to get ~49kHz?

The YM3812 needs an input frequency of 3.58 MHz.
They probably generate it by taking the 14.318 MHz clock from the ISA bus and dividing it by 4.

So the DMA controller takes 1 cycle for each byte to transfer, so about 4.77 MegaBytes(MB) per second, not depending on CPU speed?

With the YM3812 I need the resulting 80us(and 320us by further division) times used to divide that 3.58MHz signal. Do you know what it uses?

I already have a global 14MHz clock, which supplies the amount of clocks passed for each CPU instruction. This gets passed to the hardware supporting that style of processing(atm CPU, PIT, DMA, Adlib, Game Blaster and Sound Blaster) with normal us timings as well for extra support(Adlib 80us clock) when required. The other hardware (Sound Renderer itself and Covox Speech Thing) use the old us time passed.

Atm DMA divides by 9 for each byte transferred(Previously 8.732575), Game Blaster by 650(22050Hz) and Sound Blaster by 644(22222Hz).

superfury wrote:

So the DMA controller takes 1 cycle for each byte to transfer, so about 4.77 MegaBytes(MB) per second, not depending on CPU speed?

No, each byte takes 4 cycles to transfer on a PC/XT at 4.77 MHz.
Also, of course DMA and CPU have to share the bus, so when DMA transfers a byte over the bus, the CPU gets a wait state.
The Intel datasheet for the 8237 claims up to 1.6 MB/s, but in practice it will be much lower.

superfury wrote:

So the DMA controller takes 1 cycle for each byte to transfer, so about 4.77 MegaBytes(MB) per second, not depending on CPU speed?

With the YM3812 I need the resulting 80us(and 320us by further division) times used to divide that 3.58MHz signal. Do you know what it uses?

Not everything is based on the 14318180 Hz clock.

Adlib card divides the 14318180 by 4 with logic chip and sends it to YM3812 master clock so it is 3579545 Hz. Chip divides by 72 to get sampling rate. Divide sampling rate by 4 to get 80us and divide that by 4 to get 320us.

superfury wrote:

I already have a global 14MHz clock, which supplies the amount of clocks passed for each CPU instruction. This gets passed to the hardware supporting that style of processing(atm CPU, PIT, DMA, Adlib, Game Blaster and Sound Blaster) with normal us timings as well for extra support(Adlib 80us clock) when required. The other hardware (Sound Renderer itself and Covox Speech Thing) use the old us time passed.

Atm DMA divides by 9 for each byte transferred(Previously 8.732575), Game Blaster by 650(22050Hz) and Sound Blaster by 644(22222Hz).

Game Blaster (at least SAA1099 chips on regular Sound Blaster card) gets the 14318180 divided by 2 with a logic chip, so it is 7159090 Hz. So for rudimentary emulation purposes, if you want to have a sampling rate for Game Blaster emulation, it would be the chip clock divided by 256, or about 27965 Hz.

So all these devices get their clocks from the ISA bus 14318180 Hz oscillator, so they are perfectly synced together.

Sound Blasters before SB16 uses separate 12MHz crystal for 8051 microcontroller which divides it internally by 12 so it runs at 1MIPS, so their sampling rate is determined by exactly 1MHz divided by the time constant sent to DSP. The minimum divider is either 43 or 44 which gives the maximum sampling rate of about 23 kHz, but it does not have a fixed sampling rate.

The Disney Sound Source has 7000 Hz (+/- 5%) sampling rate as specified by manual.

The Covox Speech Thing has no concept of sampling rate, the sample is updated based on the playback software.

Jepael wrote:

Not everything is based on the 14318180 Hz clock.

Yes, to elaborate on that...
CGA cards *are* based on the 14138180 clock. In fact, that's the reason why that clock is used: it's the standard NTSC frequency. You want the CGA card (CRTC and other logic) to work at this clock as well, synced with the CPU.

MDA/Hercules cards are not based on this clock, and have their own 16.257 MHz crystal (Hercules and some other clones may have a 16.000 MHz crystal).
EGA does both: for 200-line modes it runs on the NTSC frequency. For 350-line modes it has a 16.257 MHz crystal, like MDA/Hercules.
VGA is not based on NTSC, and has multiple frequencies, like EGA. It has both a 25.175 MHz and a 28.322 MHz crystal (SVGA cards may have even more frequencies). This is because textmode has a slightly higher resolution/frequency (720x400) than graphics modes, while it maintains the 70 Hz refresh that the 640x400 graphics mode has, to reduce flicker (640x480 mode has a slightly lower refresh rate, at 60 Hz).

I've modified the Game Blaster and OPL2(Adlib) emulation to use those correct dividers to produce their sampling rates(512 for Game Blaster audio, 288(=4 times 72) for OPL2 audio, which is further divided by 4 to get the 80us counter(which already is divided by 4 to get the 320us timing)).

The Sound Blaster output sampling rate is now determined by the 14MHz clock(rounded to the higher sample rate). The sample rate used by the rendering of Sound Blaster audio is still based on the 1MHz divided by (256 - data), which is set for the duration of the playback, until a new rate is set(variable samplerate).

The Sound Source (7KHz) and Covox Speech Thing(software sample driven(output to device sets new voltage), with the renderer sampling the outputted software sample voltages at a 44kHz(44100Hz) sample rate) are unchanged. Basically, the Covox Speech Thing does the same as the Sound Blaster, only the sound blaster has more features(interrupts and automatic sample output using DMA).

The video card emulation(VGA-based) is unchanged, able to function as a VGA, CGA, MDA and Tseng ET4000/ET3000 graphics cards. This uses the old nanoseconds timing to provide compatibility with the different cards(25MHz, 28MHz, MDA clock, 14MHz and the various ET4000/ET3000 SVGA speeds).

Currently the following hardware runs based on the 14MHz clock generated by the CPU timings in the main loop:
- PIT(Sound rendering is based on nanoseconds timing)
- DMA
- Adlib
- Game Blaster
- Sound Blaster(Sound rendering is based on 14MHz clock. IRR, Reset timing and DMA transaction control are based on nanoseconds timing)

All other support and hardware use the nanoseconds timing(either uses it's own clocks or no clocks specified):
- Mouse emulation
- DRO player
- Parallel port
- Sound Source/Covox Speech Thing
- ET4000/ET3000/VGA/CGA/MDA CRT emulation
- Joystick emulation
- Audio rendering
- Timeout for too slow host CPUs

Is this correct>

superfury wrote:

The video card emulation(VGA-based) is unchanged, able to function as a VGA, CGA, MDA and Tseng ET4000/ET3000 graphics cards.

Technically, VGA in EGA/CGA/MDA mode is not the same as native EGA/CGA/MDA hardware, because both the refresh rate and the actual resolution are different. Aside from that, VGA is not fully backward compatible.
So if you want to emulate things properly, you should do it like eg DOSBox and PCem do it: you can select whether you want CGA, EGA or VGA. And running CGA/EGA software in VGA mode is like it is on a real VGA card, not how it is on CGA/EGA.

The Sound Blaster 1.0 uses a 12Mhz clock input to an 8051 timer (as mentioned above it's 12Mhz, I was thinking of an sb clone that has a 30mhz clock). The Sound Blaster 16 uses a 46.615120Mhz clock divided by (1024*256) and multiplied by a 8-bit value from a lookup table based on the desired frequency.

Like I said, my video card rendering is has a shared CRT emulation, which handles (S)VGA vs CGA/MDA style rendering. Mostly unchanged, CGA/MDA add a little logic to it, together with scanline buffering. The basic CRT emulation(which runs at 25Mhz, 28Mhz, 14Mhz or MDA speed) is used by all video cards. CGA and MDA just enable some extra logic to it(they also use a CRT display after all), like waitstates and special pre-scanline(CGA/MDA memory mappings vs (S)VGA mappings) and post-scanline(Re-enigne's NTSC convertion algorithm for CGA, CGA RGBI conversion and MDA 4-color(different attributes) conversion).

You can compare it to the way Dosbox handles it's video card rendering using a basic SVGA base(The Trio hardware in Dosbox's case), with extensions to emulate the related hardware. UniPCemu just does this using a CRT base instead, allowing for accurate emulation.