Compact Flash adapter

[GiGaBiTe]

44100 x 16 bits x 2 channels = 175 KB. Then double that, to read the data from the drive and write it to the sound buffer. Thus, you need to move 350 KB/s worst case.

Yes, you can. A 386 has more than enough horsepower to play 16-bit sound at 44.1 KHz. Nobody said anything about "period correct" drives. Go back and read my post.

Because I don't want to get my 386 system out of storage, here is the cycle accurate PCEM v17 showing that you CANNOT in fact play back 16 bit 44100 kHz PCM audio in real time on a 386DX-40. This audio sample is 22050 kHz, 44100 is going to be much worse. Additionally, these emulators are handling the disk controller, so on real hardware, it will be even worse from the CPU having to bit bang PCM data from the disk to the sound card in PIO mode.

http://sanzen.in/files/mpxplay.mp4

Also for good measure, here is a less cycle accurate DosBox-X changing between cycle counts to approximate several CPUs. I had to fudge the core to a 486 because mpxplayer crashes with a 386 instruction set for some reason. But here is going from a 386DX-25, 386DX-33, 486DX-33 and 486DX2-66. Both 386s are lost causes. The 486DX-33 can just squeak by doing 8 bit PCM at 11025 kHz, but it requires a 486DX2-66 to play the 16 bit 22050 kHz sample back at full speed. I suspect you'd need an 80 or 100 MHz 486 to do the full 44100 kHz sample rate.

http://sanzen.in/files/mpxplay2.mp4

The answer is NO. A 386 at any speed cannot play Redbook digital audio, or anything approaching it. Pure analog audio passthrough to a sound card only.

The CD audio input on the Sound Blaster Pro is analog, and it goes to an analog mixer. The Sound Blaster does not know or care about the Redbook Audio spec.

Except for the part where it degrades the output significantly with noise. Not all analog mixers are equal. I've had many SB cards pass through my hands over the years, some of them are terrible and you definitely don't want to pass through CD audio through them.

There are literally hundreds of games that disprove this assertion.

You mean like Doom that proves this assertion? In full screen in lowres mode, going from no sound at all to 8 channel sound is a 15% performance penalty, or about 2 fps. A 386 is going to have more performance loss. 2 fps doesn't seem like much, but it is a lot when your frames are in the teens, literally anything helps.

 

[DeltaDon]

Chuck, there's no room in the hard drive caddy for a SATA to PATA adapter. Unless you have a PATA 2.5" drive you are limited to some form of solid state device with adapter due to space issues.

 

[Plasma]

Because I don't want to get my 386 system out of storage, here is the cycle accurate PCEM v17 showing that you CANNOT in fact play back 16 bit 44100 kHz PCM audio in real time on a 386DX-40. This audio sample is 22050 kHz, 44100 is going to be much worse. Additionally, these emulators are handling the disk controller, so on real hardware, it will be even worse from the CPU having to bit bang PCM data from the disk to the sound card in PIO mode.

http://sanzen.in/files/mpxplay.mp4

Also for good measure, here is a less cycle accurate DosBox-X changing between cycle counts to approximate several CPUs. I had to fudge the core to a 486 because mpxplayer crashes with a 386 instruction set for some reason. But here is going from a 386DX-25, 386DX-33, 486DX-33 and 486DX2-66. Both 386s are lost causes. The 486DX-33 can just squeak by doing 8 bit PCM at 11025 kHz, but it requires a 486DX2-66 to play the 16 bit 22050 kHz sample back at full speed. I suspect you'd need an 80 or 100 MHz 486 to do the full 44100 kHz sample rate.

http://sanzen.in/files/mpxplay2.mp4

The answer is NO. A 386 at any speed cannot play Redbook digital audio, or anything approaching it. Pure analog audio passthrough to a sound card only.

Do you seriously think a 386 cannot move data around at 350 KB/s? Cubic Player can play a 44.1 KHz 16-bit stereo wave file without skips on a 20 MHz 386. There is no "bit banging" to the sound card required. You put the data in a buffer and start the DMA transfer. I don't know what was wrong with your test, but it's definitely flawed. Remember the SB16 came out in 1992. Nobody had a 100 MHz 486 in 1992.

Except for the part where it degrades the output significantly with noise. Not all analog mixers are equal. I've had many SB cards pass through my hands over the years, some of them are terrible and you definitely don't want to pass through CD audio through them.

I'm not sure what your point is. Earlier you were conflating the CD In port with Sound Blaster Pro DAC sample rates. Which is why I pointed out that if you use the CD In, the path is 100% analog to your speakers.

You mean like Doom that proves this assertion? In full screen in lowres mode, going from no sound at all to 8 channel sound is a 15% performance penalty, or about 2 fps. A 386 is going to have more performance loss. 2 fps doesn't seem like much, but it is a lot when your frames are in the teens, literally anything helps.

Your claim was that "The 386 has trouble even doing multi-channel FM synth at the same time as something else (ie. games) without having performance issues." Your graphs are showing performance comparisons for digital audio mixing. Two entirely different things. There are hundreds of games for the 286 and 386 with Adlib music (which is multi-channel FM synth) that don't have "performance issues."

To reiterate my original point before I derail this thread further, it does not take a lot of CPU to play digital CD audio. Certainly not a Pentium. There is no special processing required. It's simply that the drives didn't support reading audio data over the bus, because they didn't need to. Hard drives were small and nobody had CD burners. The only thing you were doing with an audio CD was playing it, not ripping or copying. So you might as well save the CPU and send the analog audio directly to the sound card.

 

[DeltaDon]

I've seen a couple of 6x CD drives, but are mostly 8x devices from Teac and are not Atapi connector compatible. I've never looked into making an adapter to use other drives and have just lived with what they came with. The CD drives also do have issues with reading burnt disks from modern burner drives and again I've not looked into a solution.

Back in the day if you wanted to play video on Socket 5/7 laptops you needed a Margi card (with its software) to do the processing and I'm not sure if the Green 753 is compatible with a Margi since it's PCMCIA's are 16 bit only. I've only used a Margi with Chicony MP975's and IIRC only one of the two PCMCIA slots was compatible on that laptop. Someone gave me a movie on 3 CD's and I messed around with making it work just to see if it worked.

 

[3lectr1c]

I've seen a couple of 6x CD drives, but are mostly 8x devices from Teac and are not Atapi connector compatible

You said something like this about the G753’s drive, and that it needs a special driver, but for me it’s worked fine out of the box with OAK and Windows’ drivers?

 

[Zare]

Before that, CD drives had an audio out port on the back of them that you had to plug into the sound card on the PC

One of selling points of early CD-ROMs was standalone CD player.
When I moved from ROM to first R (Phillips 6200 SCSI), I repurposed a multimedia desktop case as a standalone cd player. The old Mitsumi had 3 buttons on front for exclusive CD player control.

 

[jknightandkarr]

What's odd to me is, it can't play audio cds, but the driver disk installed an app to play them.

 

[DeltaDon]

 

[DeltaDon]

Above is the connectors on the Teac CDROM drives used in the Green 753 (& Green 755). As you can guess the mating connector covers all the pins and therefore has power plus signals all brought out to the other end of a mylar ribbon with a connector screwed to the caddy that plug-into the laptop and mates up with an internal connector.

Regarding drivers needed for this drive I don't know why I've had to load the Teac driver, but if the std. OAK driver works for you then so much the better.

 

[3lectr1c]

 

[3lectr1c]

Here's a few photos. First shows how it IDs in Windows, this is without using the driver floppy disk. Next are both when booted from a DOS 6.22 floppy disk with the OAK driver. The CD-ROM drive works fine, but for whatever reason gets assigned to be the R:\ drive instead of D:\.
Is it possible that you missed that it was mounted as R instead of D when you were testing?

 

[DeltaDon]

That's possible, I guess. I haven't attempted to load Windows from the CD drive in some time and I should go back and try it again. One more thing to add to the long list of round to it's.