Bondi wrote on 2021-03-15, 09:22:

I don't mind doing this, but I have no idea how. As for the drivers, here they are. I include the autoexec.bat, the two files t […]
Show full quote

yyzkevin wrote on 2021-03-15, 08:32:

What would be quite helpful would be if somebody could dump the CIS off the ibm card, with that along with the drivers I could work backwards to make something compatible with the existing software.

I don't mind doing this, but I have no idea how.
As for the drivers, here they are.
I include the autoexec.bat, the two files that are loaded and the archived whole drivers folder. There is nothing in config.sys apart form standard IBM CS and SS drivers.

PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\DOS;C:\VC;C:\VR;C:\MWD\MANAGER;C:\ALTEC
SET TEMP=C:\DOS
REM IBM 3D Card requires CS and SS
SET MWROOT=C:\MWD
SET MWPATH=C:\MWD\MANAGER;C:\MWD\MWGAMES
LOADHIGH C:\MWD\MANAGER\MWPCMS.EXE
LOADHIGH C:\MWD\MANAGER\MWDGAME.EXE
SET BLASTER=A220 I5 D1 P330

MWPCMS.EXEMWDGAME.EXEMWD.RAR

Funny enough that is where I live and grew up, Scarborough and Pickering are beside eachother.

There must be favorable atmosphere for PCMCIA sound cards developers in that area 😁

thanks! in terms of the card information structure, if you could run the following command, the 1 is socket number so maybe you would need a 0 depending which slot you put it in. dtpl.exe you should be able to find online, if not I could attach it.

dtpl.exe -r 1 > dump.cis

yyzkevin wrote on 2021-03-15, 18:43:

Bondi wrote on 2021-03-15, 09:22:

I don't mind doing this, but I have no idea how. As for the drivers, here they are. I include the autoexec.bat, the two files t […]
Show full quote

yyzkevin wrote on 2021-03-15, 08:32:

What would be quite helpful would be if somebody could dump the CIS off the ibm card, with that along with the drivers I could work backwards to make something compatible with the existing software.

I don't mind doing this, but I have no idea how.
As for the drivers, here they are.
I include the autoexec.bat, the two files that are loaded and the archived whole drivers folder. There is nothing in config.sys apart form standard IBM CS and SS drivers.

PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\DOS;C:\VC;C:\VR;C:\MWD\MANAGER;C:\ALTEC
SET TEMP=C:\DOS
REM IBM 3D Card requires CS and SS
SET MWROOT=C:\MWD
SET MWPATH=C:\MWD\MANAGER;C:\MWD\MWGAMES
LOADHIGH C:\MWD\MANAGER\MWPCMS.EXE
LOADHIGH C:\MWD\MANAGER\MWDGAME.EXE
SET BLASTER=A220 I5 D1 P330

MWPCMS.EXEMWDGAME.EXEMWD.RAR

Funny enough that is where I live and grew up, Scarborough and Pickering are beside eachother.

There must be favorable atmosphere for PCMCIA sound cards developers in that area 😁

thanks! in terms of the card information structure, if you could run the following command, the 1 is socket number so maybe you would need a 0 depending which slot you put it in. dtpl.exe you should be able to find online, if not I could attach it.

dtpl.exe -r 1 > dump.cis

Here you go

Absolutely perfect, thank you!

Okay so easy part so far, I reconstructed the cis and I can get detected like the card, and resources get configured to it etc.

some of the other stuff though I can see it attempting to load that DSP code, so I am trying to trick it into thinking that worked as all I am really trying to see right now is their method of ferrying data across.

okay sorry to reply to myself again, not sure proper protocol, edit previous post

anyway, I think there is actually a possibility I can do this, it would not use the ibm drivers as it is a bit too complex I think to emulate a card enough. It would need to be my own enabler/tsr which I have started during my testing.

what is the target laptop this would be used for? in terms of MPU-401 it made sense to me as no laptop generally has that, same with gameport, and as for the OPL3 I guess some have some other type of synth. Having the general midi chip onboard fed from the mpu-401 is a useful function.

what is the laptop that we need dos soundblaster support on that does not already have it? 1. I am interested to know to be sure this effort is really justified and 2. I actually want to get one of these laptops for the purposes of testing.

yyzkevin wrote on 2021-03-17, 04:31:

okay sorry to reply to myself again, not sure proper protocol, edit previous post

anyway, I think there is actually a possibility I can do this, it would not use the ibm drivers as it is a bit too complex I think to emulate a card enough. It would need to be my own enabler/tsr which I have started during my testing.

Is your enabler going to support real mode games as well? IBM is the only card that could do this. A couple of other cards and also parallel port sound devices were capable of emulating SB only in real mode games.

what is the target laptop this would be used for? in terms of MPU-401 it made sense to me as no laptop generally has that, same with gameport, and as for the OPL3 I guess some have some other type of synth. Having the general midi chip onboard fed from the mpu-401 is a useful function.

what is the laptop that we need dos soundblaster support on that does not already have it? 1. I am interested to know to be sure this effort is really justified and 2. I actually want to get one of these laptops for the purposes of testing.

There are a lot of laptops that have no sound whatsoever. These are mostly 486 laptops, early pentiums and some 386 that have pcmcia slot. I'd personally like to unmute my IBM Thinkpad 360CE and 330C. But there are tons of Compaq, NEC, TI, Samsung, Toshiba and other laptops without any sound capabilities.

There are also newer laptops that have only ac97 sound capability that would be nice to be able to have DOS sound capability.

okay got it, so for sure there is a use. I did not think about the slightly newer machines that have windows only cards. Would it be acceptable if I were to implement the capabilities of the original sound blaster generally? this is the easiest path given there is a lot of information out there on the clone isa boards that helps me. the OPL3 is no issue, and the intellegent MPU401 is no issue but in terms of the DSP same as the soundblaster 1.0/1.5 whatever these clone/replica boards are.

I thought the issue with other options was they only worked in real mode and not protected mode or these dos extenders etc? For me my "test" game been doom is that okay?

basically the game is still talking to the actual DSP over the i/o port, but what I am trying to do is implement a fifo on the card and that is what the dsp is actually getting its data from when it thinks it is doing a dma transfer. the tsr is transfer the data from the dma buffer on the host to the fifo/buffer on the card. now i don't know how serious of an impact on performance this will have I am waiting for some parts (8051 micro and dac) so I can do more realistic simulation and see if what I am getting out is actually audio. i was also looking at transfering two bytes at a time if i have 16bit pcmcia card and trying to keep up with 8bit dma transfer.

DOOM is an excellent reference point IMO. As it reperesents a number of good games based on the same engine.
Another group of games that is probably worth testing are those using Miles Sound System.
https://www.mobygames.com/game-group/sound-en … es-sound-system

Bondi wrote on 2021-03-17, 11:27:

DOOM is an excellent reference point IMO. As it reperesents a number of good games based on the same engine.
Another group of games that is probably worth testing are those using Miles Sound System.
https://www.mobygames.com/game-group/sound-en … es-sound-system

okay that is great, because I am using doom -timedemo demo3 to guage the impact of my tsr. very sloppy I can see immediate impact.

In terms of DSP, because I really know so little about soundcards despite the fact for some reason I am trying to make one, is a SB1.0 DSP acceptable? I am able to get those 8051 chips in an appropriate footprint for the pcmcia card, and I can get the program as recovered for the snark barker effort, so all I am doing then is dealing with the transport of this dma data and feeding the dsp during dma (in theroy). For some of these other SB2.0 options I am not sure availability of those chips etc?

CS4237B looks like it could be easier to work with but I dont see how to buy it too easy (through regular channels)

The more I research this, I think I want to use a crystal chip of sorts, as it seems to drastically simplify the design. There seems to be reasonable supply of various chips at these random places (ebay etc), maybe that is okay.

yyzkevin wrote on 2021-03-18, 01:40:

okay that is great, because I am using doom -timedemo demo3 to guage the impact of my tsr. very sloppy I can see immedi […]
Show full quote

Bondi wrote on 2021-03-17, 11:27:

DOOM is an excellent reference point IMO. As it reperesents a number of good games based on the same engine.
Another group of games that is probably worth testing are those using Miles Sound System.
https://www.mobygames.com/game-group/sound-en … es-sound-system

okay that is great, because I am using doom -timedemo demo3 to guage the impact of my tsr. very sloppy I can see immediate impact.

In terms of DSP, because I really know so little about soundcards despite the fact for some reason I am trying to make one, is a SB1.0 DSP acceptable? I am able to get those 8051 chips in an appropriate footprint for the pcmcia card, and I can get the program as recovered for the snark barker effort, so all I am doing then is dealing with the transport of this dma data and feeding the dsp during dma (in theroy). For some of these other SB2.0 options I am not sure availability of those chips etc?

CS4237B looks like it could be easier to work with but I dont see how to buy it too easy (through regular channels)

The more I research this, I think I want to use a crystal chip of sorts, as it seems to drastically simplify the design. There seems to be reasonable supply of various chips at these random places (ebay etc), maybe that is okay.

If we could get digital audio for sound FX in games and playback of MOD files and WAV files, besides MIDI GM / mt32 emulation and/or OPL2/3 music in the LXSidecar,
that would really make my day 😀 even if it's 8-bit mono audio similar to a COVOX speech thing... But, offcourse stereo 16-bit 44.1 or 48KHz would be amazing, if at all possible...
I think the SB1.0 is 8bit only, but i'm not %100 sure 😀

Terrence

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.

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.

Are you talking about producing a PCMCIA soundcard or about the LXsidecar project ?

Terrence

radiance32 wrote on 2021-03-18, 06:31:

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.

Are you talking about producing a PCMCIA soundcard or about the LXsidecar project ?

Terrence

this thread is specific to the pcmcia soundcard, but much of it has a overlap and will likely be included. As the HP200LX is much lower power machine I cannot be certain what the impact would be of the overhead from the DMA emulation TSR.

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

radiance32 wrote on 2021-03-18, 06:31:

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.

Are you talking about producing a PCMCIA soundcard or about the LXsidecar project ?

Terrence

this thread is specific to the pcmcia soundcard, but much of it has a overlap and will likely be included. As the HP200LX is much lower power machine I cannot be certain what the impact would be of the overhead from the DMA emulation TSR.

I guess also, will the TSR work on a 8086 CPU ?
most of the sound card driver TSRs i've seen all require 386+ cpus to run, so that would automatically exclude the 200lx,
or are you doing things differently ?

Terrence

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.

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.

I code C/C++ for a living, but i've hardly any experience with assembly. Last time I tried was on a 6502 when i was 11 years old... ;(
Maybe someone here will catch your message and respond ???
There's quite a few people on this forum that are quote good x86 assembly programmers (from the threads i've seen)...
If nobody responds, maybe make a thread in the appropriate forum asking for someone to help out with some assembly coding and describe what you need ?
That will be much more visible to all the forum users, than a request buried deep down a thread on page 4...

I feel bad I can't do more to help...

Cheers,
Terrence

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

What I have working today: 330h MPU-401 based on the HardMPU project. 338h Yamaha OPL3, seems to work but I did not connect […]
Show full quote

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,

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.

The fact that this is all working already is really amazing!
The SB part is tricky. Many PCMCIA cards used a SB compatible ESS chip, but none of them supported SB in DOS. It was either impossible/too complicated or maybe the reason for that was that IBM actually patented the DMA emulation method. Here is another patent.
https://pdfpiw.uspto.gov/.piw?PageNum=0&docid … ey=&HomeUrl=%2F

so I wondered about this too. For sure the patent must have played a role in others not doing this, and as is one of the issues with patents it is pretty broad, is it something they should have been able to patent? I don't know, I don't think so but that is looking back where a lot of just casual knowledge of retro computing today was cutting edge at some point. This patent is what I am doing and some parts I came to the same conclusion before even reading the patent deeper. This latest one you linked is a more direct version of what they explain in the one more specific to the soundcard, it is helpful.

Perhaps also there was less demand at the time, to play dos games on these laptops that had no sound? and the ones that were WSS were we happy to just run windows? I don't remember because during this era I only had desktop computers. I do have faint memories of the frustrations of windows only modems.

As I slowly get my head around this, it is not overly complicated but it certainly introduces an overhead, the one that DMA was specifically meant to address. With the IBM card does it cause a noticeable change in game speed? Like, will this be a problem trying to play doom on a 486DX2-50? Maybe not, but on a 386SX maybe?

yyzkevin wrote on 2021-03-18, 09:04:

Perhaps also there was less demand at the time, to play dos games on these laptops that had no sound? and the ones that were WSS were we happy to just run windows? I don't remember because during this era I only had desktop computers. I do have faint memories of the frustrations of windows only modems.

As I slowly get my head around this, it is not overly complicated but it certainly introduces an overhead, the one that DMA was specifically meant to address. With the IBM card does it cause a noticeable change in game speed? Like, will this be a problem trying to play doom on a 486DX2-50? Maybe not, but on a 386SX maybe?

I think that pcmcia sound cards producers always had DOS gaming in mind. As almost all the cards support Adlib sound, many support joysticks. Apart from that some had DMA emulation for DOS games in Windows. So there must have been something that prevented them from SB support in DOS.

I did not notice any significant slow down when using the IBM card. I can try doing some tests, AFAIR DOOM has a way (a weird one) to measure FPS. As for 386, it's probably too slow. But 386 laptpos with pcmcia slot are not that common, so not really a big issue here.

PCMCIA lacks ISA DMA mechanism, this makes it difficult to achieve compatibility with SB, WSS and others which use DMA to play back the sound streams. Some sort of software solution is necessary that simulates DMA controller and passes data to the card. Bus mastering is also unavailable so the card cannot read data from memory directly either.