Hi guys! Sorry for being absent for quite a while. Unfortunately my project has been cancelled even before it really took off. There are several reasons for that, one of them being that this endeavour would be beyond our current skills and knowledge. So, I'm extremely happy that this thread is still alive, it's great when someone can raise the flag once it falls out of a dead hand 😁

Same theres no reason to stop that project but the two do not necessarily need to be the same.
theres been products around made by Magma that are pcmcia to PC I am no engineers but Id think just a simple PCMCIA card to 2 port external PCMCIA would be even simpler than pcmcia to PCI.

Warlord wrote on 2021-04-09, 19:20:

Same theres no reason to stop that project but the two do not necessarily need to be the same.
theres been products around made by Magma that are pcmcia to PC I am no engineers but Id think just a simple PCMCIA card to 2 port external PCMCIA would be even simpler than pcmcia to PCI.

I purchased one of those magma devices earlier in the year or last year (not sure what time is anymore) I don't know why but I thought it was interesting to look at later, it is cardbus and requires drivers of course, this is for windows environments etc. It also appears to be extremely complex, there is a very intense board inside the enclosure not even getting into the card itself.

In terms of multiple pcmcia cards in a single slot on a HP palmtop, I have a device I purchased called an Accurite DoubleSlot that does this, I have taken it apart and reverse engineered it and was in the process of building a replica one.

I guess it got confusing perhaps I should start a new thread dedicated to my proposed new soundcard? in terms of MPU, Wave Table and OPL3 I am already at a stage I could be sending off for a prototype PCB. If I were going to make this for sale, I would want to get a very general idea soon how many would be needed to know if I need to buy more pcmcia frames or not, as I did get an end of availability notice from digikey on those. I only have a couple trays of them and I want them for my non-sound pcmcia projects,

I definitely want one or two cards.

I would definitely want one for my laptop 😊

yyzkevin wrote on 2021-04-10, 05:43:

I guess it got confusing perhaps I should start a new thread dedicated to my proposed new soundcard?

If you do, please post a link in this thread so that all of us followers could switch there and not get lost on the way 😀

What's up, Kevin? Wondering where you stand with the project. PCBs ordered? Did you have a chance to sort out the noise issue?

Id buy at least 1. More if the price is right. Ya make a new thread with pictures, etc. I wouldn't worry about it not being that popular becasue as far as I know yours is the only 1. Vitage PCMCIA sound cards are rarer than ultra rare and probably lack the features you are saying it has. You might be able to get rich off this if it really works good.

With your card it opens up a lot of options for mobile retro gaming, on early 2000s laptops started to get semi decent but the only sound options were AC97, but otherwise were perfectly fine for 98 and dos and xp.

I'd also be interested in one, since I have a nice (IMO) Thinkpad 486 laptop, which can be used to play most classic DOS games but it only has pc speaker as a sound output.

I would also be up for grabbing at least one. I am excited to see the how this could change DOS gaming for laptops in a positive way.

yyzkevin, I'm following your work on this and sidecar. You can count on me as a buyer!

So I had got this working as a proof of concept some time ago, but I have failed to get reliable operation. Initially I thought it was my breadboard nest.... I have recreated the circuit multiple times. A lot of the symptoms felt like floating pins, i.e. would be in dma playback no issue then I would roll my chair and suddenly it would stop working etc. I have tracked down the issue that, somehow what I am doing is killing some of the i/o pins on the AT89S51. They start to become very unreliable and eventually will not work. I am unclear how this is happening as they are simply connected to a GAL. I do not have this issue with the OPL3 or the ATMega for the MPU, so not sure.

Is there any opensource project like the BlasterBoard? As I have learned more along the way, I see that it is not necessary to to be using the AT89S51 so I could use official soundblaster firmware, I have learned after all that the DSP is not VERY complex. I would like to re-create the soundblaster DSP on an ATMega or pic etc but I would like to avoid writing this from scratch myself this myself to save time.

also the reason I do not want to just use the blasterboard hex file is I would like to make some small modifications to simplify my GAL. Not necessary but would be nice.

picture for fun:

I can think about ground bounce causing the issue you are observing which is able to destroy IO pins as signals extend past their range due to the effect.

There is also the Snark Barker project https://github.com/schlae/snark-barker
Here is more or less complete list of all sound card replica projects The comprehensive list of all modern reproductions of vintage sound cards

Bondi wrote on 2021-05-07, 09:00:

There is also the Snark Barker project https://github.com/schlae/snark-barker
Here is more or less complete list of all sound card replica projects The comprehensive list of all modern reproductions of vintage sound cards

I use the firmware SnarkBarker project recovered from a real DSP, and I run it unmodified on the AT89S51.

I sent a private message to LABS asking about any scenario that I could get the sourcecode he wrote for the ATMega, that I could use/modify for this. I will understand if he does not wish to share but it was worth to ask before I attempt to re-create something already done.

Not sure where I am going to find help on this. My program sets up an ISR on 0x1C timer that watches the interrupt vector table for any changes to the SoundBlaster IRQ. If it detects a change, it changes it again pointing to my own ISR, and I make an I/O write to the pcmcia card to set a register that indicates the TSR is ready and has control of the IRQ.

The problem is, when I set that flag to indicate I am ready this will almost always result in an interrupt being triggered at that exact edge of the i/o write by the soundcard, and I do not always see that first interrupt that comes in while I am in the 0x1C ISR. When that happens it means the DMA transfer does not start and has about the same symptom as configuring the game with the wrong DMA, it will not pass initialization. if it does catch that first IRQ It will properly play the entire cycle no issue, and continue fine until the game/application unhook/hooks the IRQ again for any reason and then it is the same game of chance if I see the first interrupt.

I have played around with disabling/enabling interrupts inside the 01xC ISR, clearing/settings the interrupt flag, making sure irq is unmasked before setting my hardware flag etc. Is there no way to have the IRQ5 ISR preempt the 0x1C ISR? is that even my issue? that is the question I am trying to answer for myself.

I've started looking at the SoftMPU code to see how it handles different interrupt situations and see if I cannot by mistake learn something to help my issue.

Update:

So the issue may be unrelated to my software handling of the interrupts and is in fact related to my pulse width for the IREQ during DMA's being not quite long enough some times causing it not to register. I realized this after seeing that the interrupt was not even getting to the ISA bus out of the PCMCIA Controller. So I will look at easiest way to update my GAL equation to fix this if I can, without adding any hardware.

When you configure your game for the IBM 3D PCMCIA card, i.e IO/IRQ/DMA for 220/7/1, I am just wondering if you look at the actual IRQ that is allocated to the card, is it 7? or is it something else.

I am having a little bit a of a battle between my TSR and the game and control being passed back and forth (ivt vs idt etc). I am wondering if the IBM card's TSR is hooking the actual interrupt assigned to the card i.e 5, and then when the interrupt is not a trap it is looking up what hooked irq7 and calling it. Without sorting this out I am often dependent on a a timer to trigger an isr but this leads to some latency starting a transfer (not an issue once in autoinit) but it also adds a lot more overhead as I am now polling the card for interrupt status to see if I missed anything.

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 😁

yyzkevin wrote on 2021-05-27, 05:47:

When you configure your game for the IBM 3D PCMCIA card, i.e IO/IRQ/DMA for 220/7/1, I am just wondering if you look at the actual IRQ that is allocated to the card, is it 7? or is it something else.

I am having a little bit a of a battle between my TSR and the game and control being passed back and forth (ivt vs idt etc). I am wondering if the IBM card's TSR is hooking the actual interrupt assigned to the card i.e 5, and then when the interrupt is not a trap it is looking up what hooked irq7 and calling it. Without sorting this out I am often dependent on a a timer to trigger an isr but this leads to some latency starting a transfer (not an issue once in autoinit) but it also adds a lot more overhead as I am now polling the card for interrupt status to see if I missed anything.

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 😁

I configure the game with IRQ 5. It did not work with IRQ 7 (default) for me and I had to cahnge it to 5 in mwave.ini file (attached) in the [DOSgames] section. But looks like the card itself is configured to IRQ 15.

mwave.ini:

[MWAVE] OSName=C:\MWD\manager\mwos4klp.dsp bios=C:\MWD\manager\bioswos2.dsp meio=C:\MWD\manager\meioedqd.dll root=C:\MWD […]
Show full quote

[MWAVE]
OSName=C:\MWD\manager\mwos4klp.dsp
bios=C:\MWD\manager\bioswos2.dsp
meio=C:\MWD\manager\meioedqd.dll
root=C:\MWD

[Mwave,Board]
Com=2
Port=4e30
IRQ=15
DMA=None
Chipid=8feb
board=MWAT-???
chip=TMS320M500
bus=PCMCIA
GamePortSpeed=0
buscapacity=450000
memsize=4096
ips=16900000
hw1=Stereo_In
hw2=Stereo_Out
hw3=MIDI_IN
hw4=MIDI_Out
hw5=ACI
hw6=DSP
Slot=1

[DOSGames]
Int=5
DMAChannel=1
Compatibility=0
Port=220h

The changes to how I am hooking interrupts helped solve my issue with protected mode games, which has now exposed the flaw in how I am filling my FIFO. I know what to do next though.

I will try to think of a name for this and start a new thread soon.

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

edit: small tweak to the autoinit routine

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

yyzkevin wrote on 2021-05-31, 08:04:

The changes to how I am hooking interrupts helped solve my issue with protected mode games, which has now exposed the flaw in h […]
Show full quote

The changes to how I am hooking interrupts helped solve my issue with protected mode games, which has now exposed the flaw in how I am filling my FIFO. I know what to do next though.

I will try to think of a name for this and start a new thread soon.

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

edit: small tweak to the autoinit routine

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

This is awesome, Kevin. It is working perfectly!