inthe SoundBlaster spec I see that many things could be done better (the 16bit IO and 16bit DMA usage for fullduplex mode) but have been kept on such level becouse of compatibility.
Still, how come that the Gravis Ultrasounds emulating the SB is weak point? (Modplay Pro 2.19b does not work with GUS MAX on 486). The GUS MAX uses the CS4231A which is itself with 8bit bus, 8bit DMA equipped, (thus with port mapping all should be done in hardware).
Still surprise. THe GUS MAX works under the win3.x only with 8bit DMA! Why? UNder the DOS it works with 16bitDMA too. there is a tremendous difference when using the DMA channel 1 or 6 😀

Came do decision to these specifications for development that the first experiment to make as simple as possible, thus then it is simpler to add the features or upgrade them in modules.

*alright... the on development card itself can be SB16 compatible, with its low and high DMA, but the 8bit I/O usage will be switchable to NOWS. The reported DSP version will be then 4.00
at first.
*also the whole card can free the ressources just by software (so it will free ports, DMA and IRQ channels. Just when other cards need them in the system with 3..4 soundcards). The tricky thing here is just to see what sort of IO adress can be reserved for this feature (hey the simplest way is to add the tumbler switch to back panel 😉 ).
*For a 24bit operation the double 16bit DMAs can be used for in the separate DOS recording software.

*Debuging leds: the fifo utilization/load, digital audio error stream led, midi I/O, DMA low dma high channel activity, sampling rate lock led (incoming digital), 32 / 44 /48 / 88 / 96kHz leds.
*connectors: optical 2x and DB9F or DB15F socket for breakout cable for digital in/out, MIDI IN/out, wordclock in/out, +5V
*Digital audio separate 512bytes FIFO for playback and record. (can be customizable as these chips are standard),
*optional SRC in order to convert the non-standard sample rates to any sample rate during playback
(the external DACs cant accept always the 62000 / 22050 / 22000 / 11000 etc sample rates, the 32kHz is lowest on studio dac racks). I am not into need for this, however those who are into gaming or like the old module players with non-standard sample rates, this can be really generous then.
pins for this IO reserved: serial clock in, LRCLK in, serial data i2s compatible 64 x fs, serial data out, LRCLK out, master clock signal 128 x fs in, master clock signal to dac out.

* in the future the option for digital audio interpolating from 8bit to 16bit can be useful for slow 286, 386 computers. Well here the algorithm needed. The hardware option can get the following
pins for this IO reserved: serial clock in, LRCLK in, serial data i2s compatible 64 x fs, serial data out, LRCLK out, master clock signal 128 x fs in, master clock signal to dac out.

* no mixers or other analog audio ports as it can added later just like general midi synth.

* mp3 (and other formats) with the extra chip, VS1063. (With additional software, which purpose is just to feed the incoming stream data to card port, go ahead you have a radio stream player under DOS as a TSR)

The wondering thoughts:

0* that "sound clicking" bug between DMA transfers. Perhaps it can be fixed with interpolating (by repeating the same last sample byte several times?) . Optional, can be adapted in firmware.

1* MIDI /MPU401 port... how much FIFO should be enough for sending and receive? 16..64..512 ? (leaving this option open too). (So, wake up trackers with midi controllers!)
2.*The DMA chip... can be with 2 x 8237, the 5Mhz version should be enough perhaps. I guess it should simplify the count of transferred bytes and IRQ generating.
Or perhaps there should be instead a counters for data activity and T-flipflops?
3* that ADPCM compression in hardware. Which software ever uses that?
I have seen it on the GUS and SB documentation, however never ever seen that in action during record or playback. Also not even the ESS IMA-ADPCM is practical as only its own audiorack can play it.

At first after the board is running the challenge is to get the board running with 96kHz sampling rate with 24bit DAC/ADC modules in half duplex mode on a 486. (if the bus speed allows -- 700..768kB/s, I do not remember if I did in the past multitrack on a 486 with 4 stereo pairs 16bit audio at 44/48kHz).
The hardware preparation: the FIFOs 512bytes, with 16bit DMA transfers to try with all modes possible for own program. as a last resort if needed then the data truncating in hardware from 32bit to 24bit (thus reducing the data flow from 768kB to 529kB/s on ISA bus).

4.* So, can be interfaced to 24bit DAT recorders or DA88 compatible and synced on a setup with master word clock.
TIMECODE, MIDI CODE for synchronizing through MIDI port or separate line(!). And so there will be this as a tape recorder.

The other uses:
iN THEORY thats the first molecule of the digital oscilloscope too if to modify the accessories connected to AES/EBU lines and the software which assumes that the incoming data stream is actually a short 40..200MS/s bursts through the digitizing buffers with a free choice of data bit depth. 😉

That won't matter a single bit, it just takes 2 or 3 DMA cycles to transfer one sample. WSS cards are all on an 8bit bus and yet they play 16bit stereo, it just takes multiple DMA cycles. SB16 can also play 16 bit samples over 8bit DMA channels.
The DMA's don't even have to be synchronized to sample rate and often they're not, instead a FIFO gets filled up at maximum burst speed on bus end and then emptied into the DAC at sample rate on card end.

Tiido wrote:

That won't matter a single bit, it just takes 2 or 3 DMA cycles to transfer one sample. WSS cards are all on an 8bit bus and yet they play 16bit stereo, it just takes multiple DMA cycles. SB16 can also play 16 bit samples over 8bit DMA channels.
The DMA's don't even have to be synchronized to sample rate and often they're not, instead a FIFO gets filled up at maximum burst speed on bus end and then emptied into the DAC at sample rate on card end.

Of course, DMAs arent synchronized on these cards sample rate.
Yes, still there is a difference if to use 8 or 16bit DMA.
just try with gravis ultrasound and mpxplay, it makes difference if the playback is on the 8bit DMA or 16bit DMA: the CPU load is much lighter with 100Mhz DX4 with mp3 playback.
Also, SB16 / 32 / 64 can play over 8bit DMA, however the 16bit DMA can be used too and reduces CPU load.

But I had in that sample truncating trickery in my mind with a thought for high sample rates. The old cards
none of those cards with 8bit dma are for 88/96kHz 24bit, which are considerably higher load compared to one CD-audio stereo stream. For 24bit audio it will be with a 8bit DMA then 6 DMA cycles minimum if to transfer 6 bytes, and 8 bytes if transferring 32bit audio stereo.
While if having the 16bit DMA and 32bit audio, then it will be 4 DMA cycles and packing together as 24bit, then it will be 3 DMA cycles to transfer 6 bytes. And we still have 88.2 or 96kHz sample rate. Thus the concern if the 486 can handle this or what will be the BUS hog then.

After implementing the current design it will be soon quite easy to see what is the difference if trying to send 24bit 96kHz audio using with 8bit DMA compared to 16-bit DMA.
Everything is optional and I do not even hardcode or tie the DMA 1 channel as "must be", like it is on SOundblaster original cards. 😉

still many many many things are still over my head before I hear the "Hallooo".

now, the lovers of the different SB versions wake up!

the help needed which should be rather the side-by-side comparison table of the different Soundblasters about the hardware programming specifics.
how differs the programming of the different SB versions from each other? (the most common ones listing from SB 1.0, 1.5, 2.0, SB Pro, compared to SB16 and SB16 ASP ).
Just to start from the initialization procedure (what they report for their DSP revision)?
and the programming differences for digital audio stream and sample rate differences becouse of different SB versions etc.
That is needed as a table.

That is needed if I would add the some other SB compatibility version too in the hardware design.

Also, how much would be enough for a MIDI buffer for receive and how much for send?

Note, the project itself does NOT get ready with moneypot, but with more developers
and knowledge.

(Going back to chipset search).

found something. well, thäts seriöös 😀
https://pdos.csail.mit.edu/6.828/2008/reading … oundBlaster.pdf

so, to choose the DSP version then it will be 4.05 (or 4.16) in this case, based on reported Wikipedia article about SB16 . But higher leads to confusing with AWE version boards in the system?
Any program which pays attention to the specific version for avoiding the buggy daughterboard versions, should be happy enough.

The Soundblaster Pro only command differences are the high-speed DMA mode.

It should not make difference, but the version number can be emulated for 3.xx then for programs which need this.

THe command registri will get couple extra registers for these extra features added (for a 24bit operation, oversampling, 96kHz operation, wordclock, etc).
Mixer inputs will be selectable as before. (as the mp3 player will be added too).

In the software there is instead of sample rate such thing - time constant for the DSP versions up to 3.xx
Which in software is implemented as this way

timeconstant= 65536 - ( 256 000 000 / (channels*samplerate) )

how is its counterpart implemented in hardware in those SBs then?

Jo22 wrote:

(If there's any FM chip to go on board, too, an OPL4 clone/FPGA with sample RAM would cool!)[/size]

which chips can those be for a opl chip, the models which have the signal output as digital audio?
If those can be as "solder and put on" then this can be implemented and the feature pins or socket for this expansion too.
If it is not possible on this time right now then it can be used as option in future for a such FMsynth option.

I am not up to this clone programming, but I leave some room for this expansion on card.
So, anyone feeling like can do this programming, the pins for the port adressing are available for this option too as expansion option.

EDIT:

YMF262 -- 4 channel output digital I/O
anything else?
could not find the YMF278 availability in feebay.

Hm, yes. It seems as lot work as the main soundcard itself, however this could be very hilarious option. So perhaps someone would make this daughterboard in parallel development just meanwhile I make the main soundcard board.
for this just now I make a connector header with ports, becouse it can be developed as extra daughterboard. (ports data input, +-12V and +5V and digital audio pins outputs to main board)

So anyone? Anyone?

jxalex, I don't want to sound negative, but your questions show complete lack of even basic knowledge required for such an ambitious idea... I don't think you find someone with proper knowledge/skills who is willing to join you - first that person will need to teach you A LOT of basics... Of course, it's your right to ignore me (or anyone else), but I would recommend first to gain some skills/knowledge and complete at least basic working project before inviting others to join...

newold86 wrote:

...

Comments from any smart ones who solve situations by constructing instead of buying things, are very appreciated! 😉

Of course excuse me, I am not the one who likes to post or take 101 (fancy) pictures about things.
Perhaps I am the only silly member here who does not understand the most elementary ISA soundcard design, MIDI buffers requirement and but everyone else here have done their own clone every day and being so bored about this topic and thats why they are all silent about topics like DMA transfer times, and such?
Well... ok enough about irony.

The idea is that I would not do it all alone or then all those just jump on when the work is done already.

well explain more which is enough as a "basic working project" ? If the basic working project would be in this case to get the MIDI and digital audio section working then I am already done.
The OPL2/3/4 section will be others to do as I am not into gaming, but I leave the connection header for that.
But if in other case basic working project it means something that atleast to get the basic DMA-transferw working in action, then hold on.

ANYONE with a information is very appreciated who can solve these questions what I have here or has some expertise in this area by making these expansion cards.

Still I am NOT sure if all this latest past is enough for such ambitios step, however I think it will be far more simpler than making PCI expansion cards.
So far what I have done in the past with the _retro_ _digital_ _electronics_ :
1. the 8-bit and 16-bit I/O external board for my 486 and used for some memory chips reading and EPROM programming and using it with I/O operation, software was made for dos with Turbo Pascal for this and assembly optimized routines.
The projects which are related to sound converters AES/EBU, DAC modules, SRAM circuits, CPU interfacing.
2. m-audio Delta 1010LT modification to put for each dac the in parallel also AES/EBU transmitters.
3. Roland D550 digital output SPDIF converter project.
4 . Roland JD990 DAC improvement modifications
5. Roland M64C memory card clones, synthesizer memory card expansions for JX10/MKS70
6. Also memory equipment for those which needed the masking (Yamaha TX81z).
7. the ROland SR-JV board dumpreader
8. some PIC16Fxxx programming and also atmel studio use with atmega128 series microprocessors for motorcycle CDI systems
and spectrometer reader system.
All the 2-layer PCBs I have done myself at home, including for the 0603 SMD components. So far never had a need to order PCBs from china as I have all made spontaneusly at home with UV-lacquer, CNC, laser . So all about the 2-layers can handle at home without delay.
So far my the weak spots are : not knowing FPGA, avoiding modern development things, bad with people interfacing (admitting atleast).
and those which require modern schematic drawing applications. I prefer handdrawing and making the PCB layout directly without ratsnest (still). So thats my portfolio as for the teamwork.
Also some skills in turbo pascal and the assembly code it can use. DJGPP or watcom C I cant.

then it is perhaps enough to take a next step to make soundcard with some use with DMA?
All these things listed here is first making a plan for it while researching the first things needed to do and putting all ideas down even if it means that during first half of the year only some of these are implemented.

I have done the some electronic projects by myself but this time I thought that from the scratch this time it should be something where others would join from the beginning as a team experiment and dividing the job in smaller pieces instead of trying to know everything and making all by myself.

Well, so far I hope it clarify something, just like the thread is also more like a diary about this. HOwever I would count it much more successful when several things are developed in parallel. Some schematics coming soon.

jxalex wrote:

...why they are all silent about topics like DMA transfer times, and such?

Again, don't want to answer for everyone, but personally for myself, your questions are too general. I would gladly answer specific question if someone is struggling with something that I have done before, but to answer your DMA questions I will need to educate you about general ISA bus functioning/timing etc first. All this info is way too big to post here, but readily available on internet in different forms...

P.S. It's my second and last post on this thread...

newold86 wrote:

....your DMA questions I will need to educate you about general ISA bus functioning/timing etc first. All this info is way too big to post here, but readily available on internet in different forms...

All that very basic DMA transfer talks about what happens on the motherboard which is NOT answer for the question! My search is very specific -- expansion card development, which is not available widely nor DMA chips for expansion cards which already exist (and which chips should be for that so as not to reinvent the wheel with 5-logic chips schematic consisting of couple counters and triggers).

So far I think that the another 8237 on the expansion card should be enough, however even for this simple question there was zero answer which I wrote here some time ago,... but it would have been the start.

One of the very very specific question in the past was this: how much FIFO would be enough for a soundcard data transfers? Very basic or just no one really knew,
It was in a thought that to have a enough fifo to utilize maximally the DMA transfer bursts.

(perhaps everyone knew the datasheets about FIFO based soundcards by heart and so did not bothered about that boring fact, but to me it is a totally newbie detail and there is not even answer in the search engines).

[edit:]
some research confirmed that the project is on the right track about FIFO buffers and dma.

Perhaps, this will be as the worklog, this thread here with my ramblings, however I have something to share what I have done so far with these 5 weeks. So it has not been just a chase-speech and agitation. 😉 Hard work has been done with components preselection to get something started with. So, I hope you understand.

So, the plans.

Modulized build. It will be consisting of the separate PCBs which connect through DIP headers. As I suspect it will be
highly modified or tweaked in the future then instead of resoldering over the areas of PCBs, I just swap these things as modules as it can be capable in future many things when reserving extra adresslines: multichannel outputs, multi-MIDI ports, MP3 decoder in hardware, or I just modify over the DAC /ADC path.
the blocks are organized as follows

overview as the signal flow

simplified CPU process plan

the choice for CPU Atmega88/168, command buffer fifos with 12x16 organization. Goal is to have to return ready flag as fast as possible.
The registers for read in/out are with extra 373 registers to keep CPU free

After reading through the Soundblaster development kit, I realized that the system can be done so that every command sent, the software does not need to read back by waiting the acknowledge for the command process, but those commands can be queued in a adress-data paired FIFO buffers. It takes atleast 16 buffers before the system gives a busy flag to command status flag register. All this unnecessary polling can be avoided in the new software which is busy anyway transporting 500..700kB/s data, still how much gain this optimization gives, we will see.

Detailed plan about the DAC data flow section.
The PISOs can cascaded for the future operation as multitrack too. one PISO per 1 stereo pair. This is the pre-stage for AES-EBU transmitters.
The only signals the DAC section gets from the CPU board is the data and channels format, start/clear/pause and read data, thus keeping free from this load the main CPU, and sending back signals if there is not room for next incoming data or in case of runout.
The operation should then be as follows: during DMA transaction the 373s will be latched with the incoming data attached to bus, the PIC near to them gets the signal too and latches the incoming data into the FIFO in series.
The tricky part here is to conversion between little and big endian numbers while maintaining also compatibility for 8, 24, 32bit data. Data transmission from 8 and 16bit bus, 1 FIFO in use. This is handled by the second PIC at the end of the FIFO which gets the signal every LRCLK period to reload the PISO registers.

the flow with ISA bus.

IRQ handling is with separate uCPU, selectors for DMA and IRQ channels.
Should it be better to have possibility that the INT signal can be sent while the DMA transfer or commands over I/O is in progress? otherwise no need for
separate chip for IRQ handling.

plan for MIDI, the FIFOs can be from CY7C series or AM7200 from 64byte to 4096bytes
The USART converter chip choosed PIC16F887
additional idea (as always from project comes out 2) -- As the MIDI on original SB series uses just 8bit part of the BUS, it is theoretically to use 2 MIDI UARTS so to use the 16bit datapath with a very little modification for future usage -- one MIDI uart for LOW and another for HIGH bus for data, while keeping the data status registers and IRQ common since it uses 2bits anyway.

The plans.
The choice for chips: FIFOs are 9x512 organization (replaceable with others)

To limit the schematic down to hole components or atleast with 1mm pitch chips, otherwise only couple memers are capable of soldering together.

This way it has also the plans for a future upgrade with 2 MIDI UARTs as you see and multitrack capability which is expandable with several DAC modules on it.

At first the development begins with CPU board ("P6hiplaat") and the DAC module board to get some communication going on the bus.

jxalex wrote:

Yes, still there is a difference if to use 8 or 16bit DMA.
just try with gravis ultrasound and mpxplay, it makes difference if the playback is on the 8bit DMA or 16bit DMA: the CPU load is much lighter with 100Mhz DX4 with mp3 playback.

CPU load should have nothing to do with amount of dma transfers on isa bus, chipset keeps those two separate and can execute memory transfers transparently to the cpu.

jxalex wrote:

Also, SB16 / 32 / 64 can play over 8bit DMA, however the 16bit DMA can be used too and reduces CPU load.

https://en.wikipedia.org/wiki/Sound_Blaster_1 … 6waveffects.jpg
8 bit ISA only SB16 😀

jxalex wrote:

88/96kHz 24bit, which are considerably higher load

Even that is only ~300KB/s compared to ~10MB/s minimum non cached/~30MB/s cached memory read speed on a slow 386 motherboards.

jxalex wrote:

compared to one CD-audio stereo stream. For 24bit audio it will be with a 8bit DMA then 6 DMA cycles minimum if to transfer 6 bytes, and 8 bytes if transferring 32bit audio stereo.
While if having the 16bit DMA and 32bit audio, then it will be 4 DMA cycles and packing together as 24bit, then it will be 3 DMA cycles to transfer 6 bytes. And we still have 88.2 or 96kHz sample rate. Thus the concern if the 486 can handle this or what will be the BUS hog then.

and even if it was slowing things it would be of no consequence because nobody will have a use of such a card in a world of vintage DOS games. You either love to play around with old queeky slow hardware, or you run emulator on shiny 3GHz 8 core 16GB laptop/workstation.

As for Sound blaster, here is a fresh project, merely 6 days old, fully open sourced 100% replica of the SB 1.0 sound card:

https://github.com/schlae/snark-barker

SB 1.0 (and afaik 2.0/pro, maybe even 16) store samples in microcontrollers internal memory, of which it has whole 128 bytes 😉 so that answers your question about fifo size, at least its upper bound.
If you want more detailed documentation look into pcem/dosemu emulators. Afair mame/mess people even dumped and decompiled sound blaster 2.0 rom, or maybe it was a rom from a SB clone card.

8 bit ISA only SB16

You've missed gold fingers on the back.

The Serpent Rider wrote:

8 bit ISA only SB16

You've missed gold fingers on the back.

check ISA pinout 😈

Call me wierd, but if it has OPL4 and C/MS I'd buy one immediately for my 486.