VOGONS


Newly made PCMCIA sound card

Topic actions

Reply 80 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie
Tiido wrote on 2021-03-18, 11:36:

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.

yep, this is what is described in the old ibm patents, and it is what I am currently recreating.

Reply 81 of 146, by Bondi

User metadata
Rank Member
Rank
Member
yyzkevin wrote on 2021-03-18, 09:04:

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?

Did some testing with IBM card in DOOM. There is a change in game speed. The CPU is 486 DX-50.
The game runs at 18 FPS with no sound.

no sound.png
Filename
no sound.png
File size
86.91 KiB
Views
691 views
File license
GPL-2.0-or-later

And at about 15 FPS with sound via IBM card.

sound.png
Filename
sound.png
File size
69.25 KiB
Views
691 views
File license
Public domain

Reply 82 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie

so, it is not easy to get my hands on an isa soundcard I can use for testing so I proceeded with what I have for now.

I am using the Atmel 89S51 with the soundblaster 2.02 dsp firmware that TubeTimeUS recovered.

I have the pcmcia enabler working, and the i/o working, so no issue doing dsp version check, , reset, interrupt test etc with sbdiag.exe .

when I request generate sinewave without dma (0F0h) I just get a blip, I am not sure if this is actually implemented fully in the 2.02 code? it certainly could be my absolutely hacked attempt at wiring up the DAC I have close to no idea what I am doing with that, which is why I wanted a known working ISA soundcard I could just attach wires to.

so now when the dsp starts a dma transfer I do an interrupt, and my TSR reads a status flag from the card to know if the interrupt was from IREQUEST or by my DMA emulation, if it was from IREQUEST it just does nothing and calls the normal ISR for the interrupt, if it is from my DMA code it checks the dma register to see location/count to start sending the bytes.

and this is where I am at, trying to get my head around how to do this without a microcontroller, I am only using the DSP and a GAL up until this point. I also have a 8bit fifo chip as I anticipate needing to transfer/store multiple bytes at a time to reduce number of dma emulation interrupt calls.

maybe I should just use a microcontroller. I am doing this as to not have to modify the dsp code, and it is not like I have the ability required to modify that assembly code anyway. not needing modified dsp code also means we could potentially also package this into a PCMCIA->ISA box, you could stick one ISA card in an external enclosure and use any soundcard you have already. maybe a neat idea. i am essentially doing this anyway for testing I think.

and for sure I am going to need help on the analog audio side of this. still hoping if I can have some cobbled together working version it will peak somebodies interest that can do this better.

Attachments

Reply 84 of 146, by bifo78

User metadata
Rank Newbie
Rank
Newbie
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.

FYI there were a number of laptops which for some reason used 201h in the motherboard design, as noted in this older PCMCIA gameport card: https://web.archive.org/web/20000526144514/ht … 3f?OpenDocument

Korg AG-10 | Kawai XS-1 | Roland CM-32P | Yamaha FB-01 | Roland D-110

Reply 85 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie
bifo78 wrote on 2021-03-25, 09:52:

FYI there were a number of laptops which for some reason used 201h in the motherboard design, as noted in this older PCMCIA gameport card: https://web.archive.org/web/20000526144514/ht … 3f?OpenDocument

Good to know. we can use alternate ports if any are supported, or it can be disabled. There are some options with the i/o window sizes and responding to only addresses in use when overlapping etc.

As for testing, I am at a stage I need to figure out how to connect the DAC so I can listen to sound.

When the SoundBlaster DSP raises the DREQ , I raise the interrupt which my TSR is the handler for, and as I mentioned before it knows if it was a result of ireq or from my dma logic (if from ireq it then defers to whatever other handler set itself up on the irq (the game)).

if it was dma, I lookup the dma buffer location and count from the dma register and start sending the data to an i/o port and updating the dma counter register, I send the size of my fifo chip. The i/o port I am sending to is connected to the input of the FIFO chip on the card. When the FIFO half-full signal goes active for the first time I have a byte come out of the fifo into a separate latch and tell the dsp there is byte available, once it reads it, it does dreq again which on the subsequent requests I use this to immediately populate the latch out of the fifo. I also use the half-full edge to to tell my tsr to send another half the size of bytes. the tsr signals to the card to clear the dma_en register and use the regular latch. I did it this way because I need to be writting to the fifo without interrupting the dsp reading from the fifo so it can keep the timing nice and no jitter/disruptions.

so this is kind of working, i need to get audio so to see what glitches I hear. Is waiting until half-full good enough indicator to start the dma transfer with the dsp, or should I do it on the first byte expecting I can outrun it. this is all trial and error for me. I am a blind person walking in the woods hopefully I find where I am going before I starve, or somebody comes and rescues me here.

Attachments

Reply 86 of 146, by radiance32

User metadata
Rank Member
Rank
Member
yyzkevin wrote on 2021-03-26, 07:20:
Good to know. we can use alternate ports if any are supported, or it can be disabled. There are some options with the i/o w […]
Show full quote
bifo78 wrote on 2021-03-25, 09:52:

FYI there were a number of laptops which for some reason used 201h in the motherboard design, as noted in this older PCMCIA gameport card: https://web.archive.org/web/20000526144514/ht … 3f?OpenDocument

Good to know. we can use alternate ports if any are supported, or it can be disabled. There are some options with the i/o window sizes and responding to only addresses in use when overlapping etc.

As for testing, I am at a stage I need to figure out how to connect the DAC so I can listen to sound.

When the SoundBlaster DSP raises the DREQ , I raise the interrupt which my TSR is the handler for, and as I mentioned before it knows if it was a result of ireq or from my dma logic (if from ireq it then defers to whatever other handler set itself up on the irq (the game)).

if it was dma, I lookup the dma buffer location and count from the dma register and start sending the data to an i/o port and updating the dma counter register, I send the size of my fifo chip. The i/o port I am sending to is connected to the input of the FIFO chip on the card. When the FIFO half-full signal goes active for the first time I have a byte come out of the fifo into a separate latch and tell the dsp there is byte available, once it reads it, it does dreq again which on the subsequent requests I use this to immediately populate the latch out of the fifo. I also use the half-full edge to to tell my tsr to send another half the size of bytes. the tsr signals to the card to clear the dma_en register and use the regular latch. I did it this way because I need to be writting to the fifo without interrupting the dsp reading from the fifo so it can keep the timing nice and no jitter/disruptions.

so this is kind of working, i need to get audio so to see what glitches I hear. Is waiting until half-full good enough indicator to start the dma transfer with the dsp, or should I do it on the first byte expecting I can outrun it. this is all trial and error for me. I am a blind person walking in the woods hopefully I find where I am going before I starve, or somebody comes and rescues me here.

Hey kevin,

I'm sorry I can't help you with this as I completely lack any skills with digital electronics engineering at this level,
but if you're really stuck and need help, I think it might be a good idea to make a new post in the appropriate forum here,
so it's more visible to everyone, as currently you're request for help is deeply buried on page 5 in a topic already...

Might be a good idea, if you really are stuck and have hit a brick wall, as more people will see it and maybe someone with the appropriate skills will notice your thread and reply...
Try to use a good thread topic asking exactly for what you need help with in a fairly short and concise way...

Good luck! 😀
Terrence

Reply 87 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie

no brick walls.

I think I am close (to something), I can now play audio however it is not the expected audio, I am reading from the wrong place in memory. I will have to re-evaluate how I am using the address and page latch info that gets setup to the dma controller to assemble an address back to a usable segment:offset

Reply 88 of 146, by radiance32

User metadata
Rank Member
Rank
Member
yyzkevin wrote on 2021-03-26, 07:20:
Good to know. we can use alternate ports if any are supported, or it can be disabled. There are some options with the i/o w […]
Show full quote
bifo78 wrote on 2021-03-25, 09:52:

FYI there were a number of laptops which for some reason used 201h in the motherboard design, as noted in this older PCMCIA gameport card: https://web.archive.org/web/20000526144514/ht … 3f?OpenDocument

Good to know. we can use alternate ports if any are supported, or it can be disabled. There are some options with the i/o window sizes and responding to only addresses in use when overlapping etc.

As for testing, I am at a stage I need to figure out how to connect the DAC so I can listen to sound.

When the SoundBlaster DSP raises the DREQ , I raise the interrupt which my TSR is the handler for, and as I mentioned before it knows if it was a result of ireq or from my dma logic (if from ireq it then defers to whatever other handler set itself up on the irq (the game)).

if it was dma, I lookup the dma buffer location and count from the dma register and start sending the data to an i/o port and updating the dma counter register, I send the size of my fifo chip. The i/o port I am sending to is connected to the input of the FIFO chip on the card. When the FIFO half-full signal goes active for the first time I have a byte come out of the fifo into a separate latch and tell the dsp there is byte available, once it reads it, it does dreq again which on the subsequent requests I use this to immediately populate the latch out of the fifo. I also use the half-full edge to to tell my tsr to send another half the size of bytes. the tsr signals to the card to clear the dma_en register and use the regular latch. I did it this way because I need to be writting to the fifo without interrupting the dsp reading from the fifo so it can keep the timing nice and no jitter/disruptions.

so this is kind of working, i need to get audio so to see what glitches I hear. Is waiting until half-full good enough indicator to start the dma transfer with the dsp, or should I do it on the first byte expecting I can outrun it. this is all trial and error for me. I am a blind person walking in the woods hopefully I find where I am going before I starve, or somebody comes and rescues me here.

Hi yyzkevin,

Look at this $10 IC:
https://www.sparkfun.com/products/11025

It's a high-quality DAC and ADC (for recording audio), but it has an MP3 codec (both real-time compression and decompression), and support for many other formats inside.
It will decode/play many formats: MP3 (MPEG 1 & 2 audio layer III (CBR +VBR +ABR)); MP2 (layer II) (optional); MPEG4/2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS); Ogg Vorbis; FLAC; WMA 4.0/4.1/7/8/9 all profiles (5-384kbps); WAV (PCM, IMA ADPCM, G.711 µ-law/A- law, G.722 ADPCM)

And, it can even encode (in real-time) the following formats: MP3; Ogg Vorbis; PCM; IMA ADPCM; G.711(µ-law,A-law); G.722 ADPCM

With one of these, we can turn our 200lx into a full-fledged MP3 player, or portable sound recorder...
To playback real-time mp3 files in 44.1KHz/16bit stereo, you would need at least a high-end 486 DX with FPU to do so,
like a 100MHz 486 system. The 200lx can stream the mp3 data from an mp3 file on your CF drive to the lxsidecar,
(I think, and correct me if I'm wrong, but the PCMCIA bus speed is more than fast enough to handle streaming a WAV file at 150KB/sec (eg CD-quality 44.1KHz/16bit stereo), or ~5x to ~10x less for mp3 files...
It's also got a built-in EQ and bass/treble settings in hardware, and many other interesting features...
Maybe you can use it as a DAC for your MIDI sound card you're building (not sure it has an i2c input for digital data),
and if we could hook it up in such a way that we can stream data to it directly,
I can develop a DOS application in C++ for the 200lx that allows you to select and play mp3 files...

Anyways, here is a link to the product PDF document with all the technical details:
http://cdn.sparkfun.com/datasheets/Widgets/vs1063ds.pdf

What do you think yyzkevin?

Cheers,
Terrence

Reply 89 of 146, by Bondi

User metadata
Rank Member
Rank
Member
yyzkevin wrote on 2021-03-27, 08:40:

no brick walls.

I think I am close (to something), I can now play audio however it is not the expected audio, I am reading from the wrong place in memory. I will have to re-evaluate how I am using the address and page latch info that gets setup to the dma controller to assemble an address back to a usable segment:offset

Sounds very promising. If it's only about reading from the correct memory address, then you seem to be very close to success.
You use IBM enabler and an own TSR for DMA emulation, right? Do you get sound from an actual game? A real or protected mode game?

Reply 90 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie
Bondi wrote on 2021-03-28, 08:37:

Sounds very promising. If it's only about reading from the correct memory address, then you seem to be very close to success.
You use IBM enabler and an own TSR for DMA emulation, right? Do you get sound from an actual game? A real or protected mode game?

I am using the Roland enabler but I have modified it to setup the 2x0 window needed as well. And I use my own TSR, which knows when the DSP is trying to signal to the DMA controller, and I feed it the bytes it is looking for, just from the wrong place still.

I am testing with DMA3, so I read twice from 0x6 to get the high/low bytes for the address, and I read the latch address 0x82 to get the other 4 bits. I am struggling turning this 20bit address into a far pointer in my C tsr to read from the dma buffer the game has allocated.

I need to spend some time understanding real/virtual/segment:offset etc (something I should already know), and then I can come back to this and then optimize the transfer process where required. If I load my own data info known memory location and hard code it, I get expected sound.

Reply 91 of 146, by Bondi

User metadata
Rank Member
Rank
Member

I'm sorry I can't be of any help here. Maybe reversing the TSRs from other cards can be useful?
Here are two of them. DMASTER is for devices based on DSP Solutions chip and VGAME is for Media Vision card. But both support only real mode games.

Filename
DMASTER.EXE
File size
50.78 KiB
Downloads
6 downloads
File license
Fair use/fair dealing exception
Filename
VGAMEON.EXE
File size
7.81 KiB
Downloads
7 downloads
File license
Fair use/fair dealing exception

Reply 92 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie

Okay I figured it out, it was a typo I was not shifting the value from the page register/latch correctly. I am now onto a timing issue that makes starting of the dma playback intermittent, because of how quickly the game initiates the DMA after hooking the interrupt my TSR may not have taken control yet.

Reply 93 of 146, by digger

User metadata
Rank Oldbie
Rank
Oldbie
yyzkevin wrote on 2021-03-18, 17:27:
Tiido wrote on 2021-03-18, 11:36:

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.

yep, this is what is described in the old ibm patents, and it is what I am currently recreating.

Not to add to add any burdens to your work on this, but it would be great if this mechanism from the IBM patents could be implemented in a generic way so that it could form a basis for other Sound Blaster emulation TSRs to piggyback on, to provide emulation that works both in real mode and in protected mode. So not only for this PCMCIA project, but as an emulation mechanism for other hardware as well.

Would it be possible without too much effort to structure your project in a way so that it could be reused in such a manner in other projects?

Reply 94 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie

This pcmcia card has specific hardware onboard that works in concert with the TSR to carry out the DMA transfer transparently to the application and the soundblaster dsp. There is not actually any emulation taking place, in that sense, there are no modifications to the game/application and there should be no concern about what mode the game runs in as there is no direct interaction between the game and TSR, the game talks to real hardware as it would in a normal situation.

Reply 95 of 146, by digger

User metadata
Rank Oldbie
Rank
Oldbie

Wait, but how is the fact that PCMCIA does not have access to the DMA controller overcome without any form of emulation? Wasn't that the major innovation in those IBM patents?

Perhaps I've misunderstood this.

Reply 96 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie

I guess when I hear the word emulate in relation to soundcards, I assume we are talking about i/o trapping as step1, which does not work with many games so it fails there.

the ibm method involves no i/o port trapping, the application is doing i/o transfers to the real hardware like normal, the isr is being called by real interrupts incoming, and it is updating a real dma controller.

the work of the tsr is strictly to know the when the dma controller is setup and to transfer the data to the card so it is ready onboard as the dsp requests it.

Reply 97 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie

i had a couple hours to play with this over the weekend. okay this is a very crude proof of concept but it works in principal, and does not matter what mode the game is in.

I am now at a point I am going to take it all apart and try to re-do it neater and trouble shoot some timing issues. every now and then on startup the buffer is not cleared and you heat a repeat for a split second at the start of the first transfer after reset. also, want to confirm the noise (i can here the fifo being loaded) is just electrical noise because of my lack of any bypass capacitors and my hack job of using the cvx4 as a 8bit dac for the soundblaster dsp.

the only other issue, every now and then the playback stops because the DSP did not get the number of expected bytes in the transfer it was a couple short. I am not sure if this is a software issue with my TSR or if some bytes get lost because of timing error in the hardware.

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

Reply 99 of 146, by yyzkevin

User metadata
Rank Newbie
Rank
Newbie
Bondi wrote on 2021-04-05, 19:42:

I like this frankenstein setup!
Are you still sure you can fit all this on a pcmcia pcb? Did you try any real games?

warcraft2 "your soundcard works perfectly" was one of my tests, doom and streamtracker. ST3 I was not getting the expected sound, I think there is still an error in how I calculate the page. I mostly test with sbdiag right now just because it is much easier to start and stop which is helpful during trial and error troubleshooting. I also had one other issue where, sometimes my TSR does not update the interrupt table fast enough and I miss the first interrupt, I am thinking about how to overcome this still but I am not worried, there will be a solution.

having the dissassembled soundblaster dsp code is quite interesting as if it comes down to it I can use some of the extra pins to generate any additional signals I needed with slightly different timing.

it should fit, I am using large chips so it is easy for testing but I make sure the part has a small package. For example the biggest chip there is the soundblaster DSP, during testing I use the AT89S51-24PU which is the massive 40pin DIP, but for the actual card I use the 24-AU which is the 44pin TQFP package.

the same goes for the hardmpu I use the small package for the atmega, all the flipflop chips are soic package that is something like 2.65mm tall, and with those hirose frames there is space for components up to 3.1mm tall.

I dont know if I can route it with 2layer board, but I do not think there will be an issue fitting everything:

1. Soundblaster DSP
2. HardMPU MCU
3. Yamaha OPL3 + DAC
4. DMA Fifo
5 . 4x octal flipflop
6. cpld for address decoding / logic
7. flash for card C.I.S
8. midi chip (dream.fr most likely)
9. timer for gameport

what I do not know about is the analog side and how I will mix these together for output. i was putting that off. will also need some space for passives, and some voltage regulation for the midi chip.

certainly it will be quite busy.