Very nice...using a PI pico w design to keep costs down, simplify build, and streamline updates.

Incredible work - keep up the great progress!

yyzkevin wrote on 2021-03-18, 06:18:

I am starting to feel quite confident about this DMA emulation, I have a very rough proof of concept working I think I could […]
Show full quote

I am starting to feel quite confident about this DMA emulation, I have a very rough proof of concept working I think I could do it. If performance becomes an issue somebody smart can rewrite in assembly.

I do need to figure out how many people would want these cards. Once I have some further tangible results maybe we can approach some of these guys that do it for a living and see if they want to pick it up now. Maybe they will take what I did as inspiration to start their own, maybe some of what I have cobbled together is useful and they can use it. It is not rocket science just seemed nobody wanted to take the time to investigate?

What I have working today:
330h MPU-401 based on the HardMPU project.
338h Yamaha OPL3, seems to work but I did not connect DAC, I have it though.
201h Gameport,

To simplify my effort I actually ordered an ISA soundblaster compatible card based on crystal chip locally, maybe I will receive it in a few days, I will use the "SLAM" method if I can to bypass PnP and I will wire it to my pcmcia development board and then I can focus on the DMA emulation instead of analog stuff too.

currently I am testing with my built on ESS, by setting set it to DMA3 when Doom is looking for DMA1 and driving the data out a different i/o port on my pcmcia. as I have no audio representation right now I cannot confirm I identified the correct place in memory when reading the dma registeres. I downloaded SBDIAG.CPP (Shark Barker) and perhaps will use it to help in my testing by sending known data that is not actually uesful audio but something I can verify on my logic analyzer.

I definitely want one, or more. I have several laptops with AC97 chip, they will be more useful with a PCMCIA sound card plugged.

yyzkevin wrote on 2021-03-18, 06:47:

again, i should reiterate I do not know what I am doing or saying. my understanding is that those other tsr's are using some kind of ioport trapping which I know nothing about. also i thought the main issue was they could only be used with applications that do not enter protected mode but were okay with real mode.

I am not doing any of that. the DSP will be available directly over i/o port no software magic, interrupt will also be direct no software magic. My TSR is simply monitoring the DMA controller to see when the game/application has setup the DMA controller for a transfer. I look at what page/location in memory and how many bytes it said to transfer etc. On the card when it requests to start the dma transfer I interrupt, my tsr knows this is related to the dma and transfers the byte(s) to the card and does the DMA transfer on the card.

I am confident at this point I can do it. what I don't now is can I do it efficiently enough. If i have a version working that is just a resource PIG maybe somebody can chip in and rewrite in assembly.

Finally I've read through the thread today.
If I understand correctly, what you're doing is:
1. config IO ports to SB (220/240etc), and preferable IRQ (5/7) on your card, game directly talk to it.
2. monitor DMA controller register status via TSR (timers), when DMA happens, the TSR records the DMA transfer address & size.
3. generate interrupt request when the SB chip starts DMA, the TSR will send the data in the monitored address to the card's "DMA buffer chip" and then the card do the DMA on board.
My question maybe stupid but I need ask: how does the SB chip know when to start a DMA transfer? Does the game inform the SB hw before doing DMA transfer?

crazii wrote on 2022-12-04, 09:34:

Finally I've read through the thread today. If I understand correctly, what you're doing is: 1. config IO ports to SB (220/240et […]
Show full quote

yyzkevin wrote on 2021-03-18, 06:47:

again, i should reiterate I do not know what I am doing or saying. my understanding is that those other tsr's are using some kind of ioport trapping which I know nothing about. also i thought the main issue was they could only be used with applications that do not enter protected mode but were okay with real mode.

I am not doing any of that. the DSP will be available directly over i/o port no software magic, interrupt will also be direct no software magic. My TSR is simply monitoring the DMA controller to see when the game/application has setup the DMA controller for a transfer. I look at what page/location in memory and how many bytes it said to transfer etc. On the card when it requests to start the dma transfer I interrupt, my tsr knows this is related to the dma and transfers the byte(s) to the card and does the DMA transfer on the card.

I am confident at this point I can do it. what I don't now is can I do it efficiently enough. If i have a version working that is just a resource PIG maybe somebody can chip in and rewrite in assembly.

Finally I've read through the thread today.
If I understand correctly, what you're doing is:
1. config IO ports to SB (220/240etc), and preferable IRQ (5/7) on your card, game directly talk to it.
2. monitor DMA controller register status via TSR (timers), when DMA happens, the TSR records the DMA transfer address & size.
3. generate interrupt request when the SB chip starts DMA, the TSR will send the data in the monitored address to the card's "DMA buffer chip" and then the card do the DMA on board.
My question maybe stupid but I need ask: how does the SB chip know when to start a DMA transfer? Does the game inform the SB hw before doing DMA transfer?

The SB DSP is informed by the software(game) afaik. After setting the sampling rate for SB DSP and the DMA controller the game as a final step sends a command 14h/1Ch to the SB DSP and it starts the DMA tranfer.
Here is an article that can be of use.
https://tubetime.us/index.php/2019/01/19/soun … s-of-operation/

Bondi wrote on 2022-12-04, 14:42:

The SB DSP is informed by the software(game) afaik. After setting the sampling rate for SB DSP and the DMA controller the game a […]
Show full quote

crazii wrote on 2022-12-04, 09:34:

Finally I've read through the thread today. If I understand correctly, what you're doing is: 1. config IO ports to SB (220/240et […]
Show full quote

yyzkevin wrote on 2021-03-18, 06:47:

again, i should reiterate I do not know what I am doing or saying. my understanding is that those other tsr's are using some kind of ioport trapping which I know nothing about. also i thought the main issue was they could only be used with applications that do not enter protected mode but were okay with real mode.

I am not doing any of that. the DSP will be available directly over i/o port no software magic, interrupt will also be direct no software magic. My TSR is simply monitoring the DMA controller to see when the game/application has setup the DMA controller for a transfer. I look at what page/location in memory and how many bytes it said to transfer etc. On the card when it requests to start the dma transfer I interrupt, my tsr knows this is related to the dma and transfers the byte(s) to the card and does the DMA transfer on the card.

I am confident at this point I can do it. what I don't now is can I do it efficiently enough. If i have a version working that is just a resource PIG maybe somebody can chip in and rewrite in assembly.

Finally I've read through the thread today.
If I understand correctly, what you're doing is:
1. config IO ports to SB (220/240etc), and preferable IRQ (5/7) on your card, game directly talk to it.
2. monitor DMA controller register status via TSR (timers), when DMA happens, the TSR records the DMA transfer address & size.
3. generate interrupt request when the SB chip starts DMA, the TSR will send the data in the monitored address to the card's "DMA buffer chip" and then the card do the DMA on board.
My question maybe stupid but I need ask: how does the SB chip know when to start a DMA transfer? Does the game inform the SB hw before doing DMA transfer?

The SB DSP is informed by the software(game) afaik. After setting the sampling rate for SB DSP and the DMA controller the game as a final step sends a command 14h/1Ch to the SB DSP and it starts the DMA tranfer.
Here is an article that can be of use.
https://tubetime.us/index.php/2019/01/19/soun … s-of-operation/

Thanks for your tip and the ref link, guess I have to do a little homework to catch up. 🤣

crazii wrote on 2022-12-05, 12:58:

Bondi wrote on 2022-12-04, 14:42:

The SB DSP is informed by the software(game) afaik. After setting the sampling rate for SB DSP and the DMA controller the game a […]
Show full quote

crazii wrote on 2022-12-04, 09:34:

Finally I've read through the thread today. If I understand correctly, what you're doing is: 1. config IO ports to SB (220/240et […]
Show full quote

Finally I've read through the thread today.
If I understand correctly, what you're doing is:
1. config IO ports to SB (220/240etc), and preferable IRQ (5/7) on your card, game directly talk to it.
2. monitor DMA controller register status via TSR (timers), when DMA happens, the TSR records the DMA transfer address & size.
3. generate interrupt request when the SB chip starts DMA, the TSR will send the data in the monitored address to the card's "DMA buffer chip" and then the card do the DMA on board.
My question maybe stupid but I need ask: how does the SB chip know when to start a DMA transfer? Does the game inform the SB hw before doing DMA transfer?

The SB DSP is informed by the software(game) afaik. After setting the sampling rate for SB DSP and the DMA controller the game as a final step sends a command 14h/1Ch to the SB DSP and it starts the DMA tranfer.
Here is an article that can be of use.
https://tubetime.us/index.php/2019/01/19/soun … s-of-operation/

Thanks for your tip and the ref link, guess I have to do a little homework to catch up. 🤣

I have this sample asm program that plays a wav file in SB single cycle mode. it's very straight forward and well commented, pretty easy to understand.

Bondi wrote on 2022-12-05, 13:31:

crazii wrote on 2022-12-05, 12:58:

Bondi wrote on 2022-12-04, 14:42:

The SB DSP is informed by the software(game) afaik. After setting the sampling rate for SB DSP and the DMA controller the game as a final step sends a command 14h/1Ch to the SB DSP and it starts the DMA tranfer.
Here is an article that can be of use.
https://tubetime.us/index.php/2019/01/19/soun … s-of-operation/

Thanks for your tip and the ref link, guess I have to do a little homework to catch up. 🤣

I have this sample asm program that plays a wav file in SB single cycle mode. it's very straight forward and well commented, pretty easy to understand.
SBDMASCE.txt

Thanks, it helped my understanding the DMA transfer. 😁

Yeah, the game/program puts the data into memory somewhere, configures the dma registers to point to it etc, then programs the DSP to do the transfer.

if you look at sbdiag.cpp in the SnarkBarker project that can also help understand at least a single cycle dma transfer. Looking at the SnarkBarker was like my masterclass in soundblasters, without it I am not sure I would have tackled it at all.

Are you taking on a pcmcia soundcard project of sorts now?

crazii wrote on 2022-12-04, 09:34:

Finally I've read through the thread today. If I understand correctly, what you're doing is: 1. config IO ports to SB (220/240et […]
Show full quote

yyzkevin wrote on 2021-03-18, 06:47:

again, i should reiterate I do not know what I am doing or saying. my understanding is that those other tsr's are using some kind of ioport trapping which I know nothing about. also i thought the main issue was they could only be used with applications that do not enter protected mode but were okay with real mode.

I am not doing any of that. the DSP will be available directly over i/o port no software magic, interrupt will also be direct no software magic. My TSR is simply monitoring the DMA controller to see when the game/application has setup the DMA controller for a transfer. I look at what page/location in memory and how many bytes it said to transfer etc. On the card when it requests to start the dma transfer I interrupt, my tsr knows this is related to the dma and transfers the byte(s) to the card and does the DMA transfer on the card.

I am confident at this point I can do it. what I don't now is can I do it efficiently enough. If i have a version working that is just a resource PIG maybe somebody can chip in and rewrite in assembly.

Finally I've read through the thread today.
If I understand correctly, what you're doing is:
1. config IO ports to SB (220/240etc), and preferable IRQ (5/7) on your card, game directly talk to it.
2. monitor DMA controller register status via TSR (timers), when DMA happens, the TSR records the DMA transfer address & size.
3. generate interrupt request when the SB chip starts DMA, the TSR will send the data in the monitored address to the card's "DMA buffer chip" and then the card do the DMA on board.
My question maybe stupid but I need ask: how does the SB chip know when to start a DMA transfer? Does the game inform the SB hw before doing DMA transfer?

yyzkevin wrote on 2022-12-10, 05:12:

Yeah, the game/program puts the data into memory somewhere, configures the dma registers to point to it etc, then programs th […]
Show full quote

Yeah, the game/program puts the data into memory somewhere, configures the dma registers to point to it etc, then programs the DSP to do the transfer.

if you look at sbdiag.cpp in the SnarkBarker project that can also help understand at least a single cycle dma transfer. Looking at the SnarkBarker was like my masterclass in soundblasters, without it I am not sure I would have tackled it at all.

Are you taking on a pcmcia soundcard project of sorts now?

crazii wrote on 2022-12-04, 09:34:

Finally I've read through the thread today. If I understand correctly, what you're doing is: 1. config IO ports to SB (220/240et […]
Show full quote

yyzkevin wrote on 2021-03-18, 06:47:

again, i should reiterate I do not know what I am doing or saying. my understanding is that those other tsr's are using some kind of ioport trapping which I know nothing about. also i thought the main issue was they could only be used with applications that do not enter protected mode but were okay with real mode.

I am not doing any of that. the DSP will be available directly over i/o port no software magic, interrupt will also be direct no software magic. My TSR is simply monitoring the DMA controller to see when the game/application has setup the DMA controller for a transfer. I look at what page/location in memory and how many bytes it said to transfer etc. On the card when it requests to start the dma transfer I interrupt, my tsr knows this is related to the dma and transfers the byte(s) to the card and does the DMA transfer on the card.

I am confident at this point I can do it. what I don't now is can I do it efficiently enough. If i have a version working that is just a resource PIG maybe somebody can chip in and rewrite in assembly.

Finally I've read through the thread today.
If I understand correctly, what you're doing is:
1. config IO ports to SB (220/240etc), and preferable IRQ (5/7) on your card, game directly talk to it.
2. monitor DMA controller register status via TSR (timers), when DMA happens, the TSR records the DMA transfer address & size.
3. generate interrupt request when the SB chip starts DMA, the TSR will send the data in the monitored address to the card's "DMA buffer chip" and then the card do the DMA on board.
My question maybe stupid but I need ask: how does the SB chip know when to start a DMA transfer? Does the game inform the SB hw before doing DMA transfer?

Nah. I'm an idiot on hardware. I'm so eager to get one of your PCMCIA soundcard for my laptop. Just cannot wait so I might start studying a little bit.
So when is it ready for sale?

yyzkevin wrote on 2021-02-23, 23:44:

Those sounded much better than I expected that is quite promising, I was specifically wondering about the HP200LX! […]
Show full quote

lolo799 wrote on 2021-02-23, 22:37:

I can answer that one, it doesn't sound that bad really, it just depends on the laptop, "newer" ones use the same speakers for t […]
Show full quote

I can answer that one, it doesn't sound that bad really, it just depends on the laptop, "newer" ones use the same speakers for the integrated audio card out and the basic system speaker sounds, so it's quite good on those.

On older models usually without integrated audio, the system speaker is just a piezo electric device which makes a somewhat distorted sound, it has its charm though!

I posted a sample here of me playing Doom using the Panasonic cf-vew211 opl3 based card:
Re: System Beeps - a PC Speaker music album

Interestingly enough the (also by Panasonic) fm radio pcmcia card can also output the audio signal through the system speaker, I tried on my 200lx and it was alright.

I assume it's mono, it's probably written in the pcmcia specs but I'm not going to look for the answer right now.

Great project you're doing yyzkevin, I'm eagerly curious to see how it goes.

Those sounded much better than I expected that is quite promising, I was specifically wondering about the HP200LX!

There are various pages of information about the speaker function of the spec, I have a few actual books helping me along as it is not that easy to find information online for this topic.

Just ordered the "PCMCIA System Architecture: 16-Bit PC Cards, Second Edition" on the net.
I think there's too much to learn to complete a soundcard project, let alone the PCMCIA part.

Its a good one.

here are just a few of mine.

crazii wrote on 2022-12-11, 07:24:

yyzkevin wrote on 2021-02-23, 23:44:

Those sounded much better than I expected that is quite promising, I was specifically wondering about the HP200LX! […]
Show full quote

lolo799 wrote on 2021-02-23, 22:37:

I can answer that one, it doesn't sound that bad really, it just depends on the laptop, "newer" ones use the same speakers for t […]
Show full quote

I can answer that one, it doesn't sound that bad really, it just depends on the laptop, "newer" ones use the same speakers for the integrated audio card out and the basic system speaker sounds, so it's quite good on those.

On older models usually without integrated audio, the system speaker is just a piezo electric device which makes a somewhat distorted sound, it has its charm though!

I posted a sample here of me playing Doom using the Panasonic cf-vew211 opl3 based card:
Re: System Beeps - a PC Speaker music album

Interestingly enough the (also by Panasonic) fm radio pcmcia card can also output the audio signal through the system speaker, I tried on my 200lx and it was alright.

I assume it's mono, it's probably written in the pcmcia specs but I'm not going to look for the answer right now.

Great project you're doing yyzkevin, I'm eagerly curious to see how it goes.

Those sounded much better than I expected that is quite promising, I was specifically wondering about the HP200LX!

There are various pages of information about the speaker function of the spec, I have a few actual books helping me along as it is not that easy to find information online for this topic.

Just ordered the "PCMCIA System Architecture: 16-Bit PC Cards, Second Edition" on the net.
I think there's too much to learn to complete a soundcard project, let alone the PCMCIA part.

Cool. It's a hell of a lot books you got there. Are some of them in Japanese?

After digging into some SB/DMA emulation, I think the DMA monitor method may not work for some games which reads the DMA counter to fill the playback buffer seamless, one that I encountered is The Lion King. Such DMA controller reading, can only be emulated through port trapping I guess?

I am just coming back around to this. I wanted to mention I got around to trying The Lion King, and it works no problem with my DMA manipulation method.

My method is very rudimentary, I intend to see how a subset of the tricks you implement in sbemu could be helpful to expand compatibility.

crazii wrote on 2023-01-27, 22:22:

After digging into some SB/DMA emulation, I think the DMA monitor method may not work for some games which reads the DMA counter to fill the playback buffer seamless, one that I encountered is The Lion King. Such DMA controller reading, can only be emulated through port trapping I guess?

Any recent progress of this? I’ve got a thinkpad 380Z and this has me thrilled! The crystal audio it has is imperfect but still compatable with DOS. But this would be insane! Having Sound blaster and OPL2 in the same laptop would be the cooles thing in the world! What is the price point you’re looking for?

Here is a short demo, nothing too new here but I sorted out a few items dealing with the non-intel PCIC in this Compaq

https://www.youtube.com/watch?v=EcF_Xhu-wgY

yyzkevin wrote on 2023-06-24, 02:39:

Here is a short demo, nothing too new here but I sorted out a few items dealing with the non-intel PCIC in this Compaq

https://www.youtube.com/watch?v=EcF_Xhu-wgY

Cool! What was the solutoin for the Compaq? Does it work with enabler or CS/SS?

Very interested in this as my laptop doesn't have a sound card built in, how's it coming along?

BitFlip wrote on 2024-02-22, 18:16:

Very interested in this as my laptop doesn't have a sound card built in, how's it coming along?

All I can say is that the project is moving on. I'm sure it will be released at some point. However, with equal chances it may take a month or a year. I have some updates form Kevin, but he probably wants to tell about it himself.

Getting close. I need to get an idea on current interest/demand to finalize.

https://www.youtube.com/watch?v=YoJ12leojwo