Would this be possible?

C

cyclone3d

[H]F Junkie
Joined
Aug 16, 2004
Messages
16,301
So I have a thought about how to make a setup so I could use add-in cards on a different computer over a network connection.

Would this even be possible with a bit of programming?

1. Have two systems on a network
2. Control an add-in card on the 2nd system from the first system. ISA is my primary concern.

So if I had an interceptor/sender setup on both computers in order to grab/send raw data to/from the cards ports that was sent over the network. would I be able to do it?

I would guess there would at least be a little bit of delay.
 
Depends..

What's the OS?
What's are the cards?
What's your definition of "control an add-in card"?
Are delays important?
 
modi123 said:
Depends..

What's the OS?
What's are the cards?
What's your definition of "control an add-in card"?
Are delays important?
Click to expand...

OS: MS-DOS

Card: Sound Blaster AWE64 Gold!

"Control" :Be able to send the sound data from games or whatever to it. Not sure if it would require any data to come back to the controlling computer or not. DMA would definitely be required. I already have a PCI to ISA external expansion bus, but it doesn't support DMA transfers. OR rather, the specs for the interface cards seem to say they would support DMA, but the drivers do not.
I think it would work if I initialized the card on the computer that it is physically installed on. I am pretty sure than no games would require any TSRs for the card to be running on the system I am sending the data from.

Delays would be sort of important, but I would be more interested to see if I could even get it to work at all.
 
Okay.. I'm a little lost. What's the over all plan then? Computer A has DOS/Soundblaster.. route that audio to computer B for.. something?
 
Well, overall plan is to use a Socket-A board that supports DDR for the main system - no ISA slot.

Secondary system with an ISA slot would be running as an extension to the primary one in order to be able to use the AWE64.

I know it is kinda pointless, but would be really cool to set something like that up for the "wow" factor.

Something like PulseAudio, but for DOS would work great.
PulseAudio - Wikipedia, the free encyclopedia

It is open source, so maybe I could make a DOS compatible branch of it.
 
Last edited:
Another generalized/abstract approach would be two have applications: a controller and a listener. The controller app would run on your Socket A machine and send instructions; the listener app would run on your DOS machine and execute the instructions. Additional work could be put into the listener sending a response indication when a command was successfully processed. Application instructions could be passed over serial connection between the two boxes. (Note that I'm mentioning Serial communication due to the lowest common denominator for compatibility in this abstract example; there are certainly other options.)

As for the Pulse Audio idea, you could look into writing the listener application for the DOS machine, and create an addon/extension to Pulse Audio for sending commands over Serial (if it does not already support it). If Pulse Audio does support Serial communication, then clearly your work is less and already has a starting off point with the existing communication.
 
Sgraffite said:
What about a Sound Blaster compatible PCI-E card?

There are also PCI versions using that chipset.
Click to expand...

Thing is, I already have PCI cards that I could use... but I have some games that specifically support the AWE64 Gold!... such as FFVII.

This is more of a want to do if possible project that would be just for the fun of it. Then again, if I could get it to work, I could possibly have a software package that could make any old ISA slotted computer be an ISA bus extension for a newer computer.
 
It would be very complex to do something like that since the hardware interface for legacy ISA devices may not even be included in the southbridge*. On that socket A system, the game wouldn't be able to "see" the AWE64 ports when probed, since it's not mapped to memory as it would be when plugged in**. That's the first and last problem to reasonably consider.

If you want to use software that requires a native AT/ISA bus card, you should use a motherboard with an AT/ISA slot. The cheapest option is to go for a different motherboard and possibly CPU, one with an ISA slot. eBay has old crap boards and CPUs for dirt cheap.

* if legacy ISA support for cards were included in the SB, but no slots were on the board, you could theoretically scrape off some traces or pads on the motherboard (if all balls are connected to something and have electrical connections to pads or traces) and "make" an ISA slot by soldering wires to an ISA slot connector.

** a good example is legacy serial and parallel ports included with southbridges, even when ISA card support is not included. Those ports are mapped to the expected locations in memory to read and write to.
 
pxc said:
It would be very complex to do something like that since the hardware interface for legacy ISA devices may not even be included in the southbridge*. On that socket A system, the game wouldn't be able to "see" the AWE64 ports when probed, since it's not mapped to memory as it would be when plugged in**. That's the first and last problem to reasonably consider.

If you want to use software that requires a native AT/ISA bus card, you should use a motherboard with an AT/ISA slot. The cheapest option is to go for a different motherboard and possibly CPU, one with an ISA slot. eBay has old crap boards and CPUs for dirt cheap.

* if legacy ISA support for cards were included in the SB, but no slots were on the board, you could theoretically scrape off some traces or pads on the motherboard (if all balls are connected to something and have electrical connections to pads or traces) and "make" an ISA slot by soldering wires to an ISA slot connector.

** a good example is legacy serial and parallel ports included with southbridges, even when ISA card support is not included. Those ports are mapped to the expected locations in memory to read and write to.
Click to expand...

Well, some of the PCI cards have programs that add old Sound Blaster support. So it is not like you actually have to have a south bridge with ISA support.

Why would it be super difficult to capture the calls to certain addresses and then send them to the other computer?

It is not like the games are actually looking for specific hardware. Pretty much all the old games you would manually set the settings for the sound card and it would try to use whatever you set them as.

I would think it would be simpler than just completely emulating the older card.
 
That won't work. Games need to read and write to both the card's memory to load samples and control the sound card through a stream of commands. Under DOS, it's writing directly into I/O registers mapped into memory address space. PulseAudio is completely unsuitable for something like that.
 
I've got nothing. You'd need a special resident driver of some sorts, which is a broad term.
All I have is a suspicion that you could cheat by using two Dosboxes and piping between the devices in another place, like the filesystem.
 
Ok, so there are a couple already made sound card emulators for DOS.

One is call Virtual Sound Blaster and is open source. I will probably work off of this.. yay - assembler.

There is another called remus which is meant to emulate different sound cards. Not open source so probably pretty useless.

And apparently EMM386 has an undocumented API that allows for the virtualization of IO ports.

Historical archive of linux-parport: Re: [PARPORT] [ANNOUNCE] I

QEMM-386 apparently also has an API that works better for this sort of thing - not as buggy supposedly.
 
You must log in or register to reply here.
Back
Top