awgamer wrote:

Looks like there's room for a second opl2 to sit behind the first to do sbpro/pas.

How would that work out? I thought those would use an OPL3?

root42 wrote:

How would that work out? I thought those would use an OPL3?

The first-generation Sound Blaster Pro used dual OPL2, as did the original Pro Audio Spectrum.

Scali wrote:

The first-generation Sound Blaster Pro used dual OPL2, as did the original Pro Audio Spectrum. http://www.amoretro.de/wp-content […]
Show full quote

root42 wrote:

How would that work out? I thought those would use an OPL3?

The first-generation Sound Blaster Pro used dual OPL2, as did the original Pro Audio Spectrum.

Oh, TIL! One for each stereo channel?

root42 wrote:

Oh, TIL! One for each stereo channel?

Yes.
As far as I recall, writing to port 388h (AdLib port) will send the audio to both OPL2 chips, for mono. Writing to 220h will send to the left OPL2, and writing to 222h will send to the right OPL2, or something to that effect.

LABS wrote:

Hey guys,
can anyone check please if Impulse Tracker 2.14 makes a single click on startup screen with SB 2.0 or any other old SB? I have a click and I logged it's communication with the card and found nothing fancy there - usual DSP resets, set time constant (0x40), turn speaker on (0xD1), set DMA buffer's length (0x48) and start high-speed DMA auto-init transfer (0x90). No other game/tracker clicks during sound startup/autodetection etc, only IT. Can't understand is it me or is it IT?
Thanks a lot.

Dang it I forgot to check it today, I will do it tomorrow. I have a Sound Machine that is a rebadged 1350B. Will report back.

LABS wrote:

So it is officially SB-compatible now

Have you tried test-sbc.exe ? It's making me crazy - at the moment it's ONLY software (that I'm aware of) that doesn't work with the firmware for my FPGA-based cards... Last time I spent almost half day with the ISA bus logger trying to find a difference in the behavior, but couldn't see any... And still after my card is detected properly and I chose to test digital sound output, it falls into DOS...

LABS wrote:

Hey guys,
can anyone check please if Impulse Tracker 2.14 makes a single click on startup screen with SB 2.0 or any other old SB? I have a click and I logged it's communication with the card and found nothing fancy there - usual DSP resets, set time constant (0x40), turn speaker on (0xD1), set DMA buffer's length (0x48) and start high-speed DMA auto-init transfer (0x90). No other game/tracker clicks during sound startup/autodetection etc, only IT. Can't understand is it me or is it IT?
Thanks a lot.

Hi, maybe I can help. I've got an older SB2.0 model (+CMS option) for testing, but it is installed in a 286 currently, which can't run IT.
May I ask which kind of computer do you prefer for testing ? 386 or Pentium 133 PC ? 😀
Best regards, Jo22

Jo22 wrote:

Hi, maybe I can help. I've got an older SB2.0 model (+CMS option) for testing, but it is installed in a 286 currently, which can't run IT.
May I ask which kind of computer do you prefer for testing ? 386 or Pentium 133 PC ? 😀
Best regards, Jo22

Thanks a lot, Jo22! P133 is closer to my workbech machine, so that would be great.

newold86 wrote:

Have you tried test-sbc.exe ? It's making me crazy - at the moment it's ONLY software (that I'm aware of) that doesn't work with the firmware for my FPGA-based cards... Last time I spent almost half day with the ISA bus logger trying to find a difference in the behavior, but couldn't see any... And still after my card is detected properly and I chose to test digital sound output, it falls into DOS...

test-sbc was a pain for me as well. It was unable to detect my card at all. But I ran it in a debugger and found that it was too unpatient for my P166MMX. When detecting OPL2 it was writing its registers too fast. Also it uses undoc DSP regs and makes a trial DMA transfer for recording, which was unsupported by my card at first. I suppose you should run it in a debugger as well and see where it crashes exactly. BTW it cannot be disassembled using kinda hex editor, because its code is encrypted. It must be run in a debugger to let it decrypt itself. Good luck!

I just tried with my SB1350B and a 486DLC (386DX) setup, when IT starts and reports the card it detected I get 3 clicks - maybe your p1 system being faster does that quicker and it sounds like a single click.

Made a quick video of it, you can hear the 3 clicks at startup, there is also a single one on exit but the keyboard sound covered that...

https://youtu.be/5WSDUkV6Mx0

LABS wrote:

test-sbc was a pain for me as well. It was unable to detect my card at all. But I ran it in a debugger and found that it was too unpatient for my P166MMX. When detecting OPL2 it was writing its registers too fast. Also it uses undoc DSP regs and makes a trial DMA transfer for recording, which was unsupported by my card at first. I suppose you should run it in a debugger as well and see where it crashes exactly. BTW it cannot be disassembled using kinda hex editor, because its code is encrypted. It must be run in a debugger to let it decrypt itself. Good luck!

I have never had any issues with test-sbc detecting OPL2 part (neither just temporary simulated, nor real one). Also I went through quite a long process of detecting DSP debugging, at the end everything detects pefectly. On the actual test part, OPL2 plays absoulutely fine as well, but DSP just crashes into DOS... I compared ISA bus logs with my card and the original CT1350 - they are identical in commands until the very crash, even timings are quite close ! Also turned debug mode "on" in Dosbox and logged test-sbc there - nothing unusual, all commands I support... Pretty sure it's a timing issue, but don't understand where (aqgain, as I have mentioned before, my timings now are pretty close the the original SB)...

So, just to be clear, does test-sbc work fully on your card now ?

By the way, what do you feed for "a trial DMA transfer for recording" ?

Thanks !

keropi wrote:

I just tried with my SB1350B and a 486DLC (386DX) setup, when IT starts and reports the card it detected I get 3 clicks - maybe your p1 system being faster does that quicker and it sounds like a single click.

Made a quick video of it, you can hear the 3 clicks at startup, there is also a single one on exit but the keyboard sound covered that...

https://youtu.be/5WSDUkV6Mx0

Thanks, man! I had 4 clicks at first actually at startup and 1 on exit - a DAC voltage biasing issue during speaker on/off. Now only 1 left on startup and none on exit. So I guess it's ok now)

newold86 wrote:

So, just to be clear, does test-sbc work fully on your card now ?

By the way, what do you feed for "a trial DMA transfer for recording" ?

Well... it did some time ago, but now:

I've made quite a lot modifications to firmware since then. Obviously goes to my checklist.
I have test-sbc.exe v1.91. Which machine did you use when ran it with a real OPL2? I still have OPL2 detection issue on P166 - it is successful only sometimes, but on 386 it is ok on every run.
"a trial DMA transfer for recording" - as I remember it tries 0x24 or 0x2C command for IRQ/DMA detection.

That runtime error looks like the typical Turbo Pascal problem when running on a too fast PC...

LABS wrote:

Well... it did some time ago, but now: […]
Show full quote

newold86 wrote:

So, just to be clear, does test-sbc work fully on your card now ?

By the way, what do you feed for "a trial DMA transfer for recording" ?

Well... it did some time ago, but now:

testsbc.jpg

I've made quite a lot modifications to firmware since then. Obviously goes to my checklist.

At what moment is it happening ?

LABS wrote:

I have test-sbc.exe v1.91. Which machine did you use when ran it with a real OPL2? I still have OPL2 detection issue on P166 - it is successful only sometimes, but on 386 it is ok on every run.

PC XT
Actually, it's strange - I assume there is only discrete logic in the circuit (no MCU involved) ?

LABS wrote:

"a trial DMA transfer for recording" - as I remember it tries 0x24 or 0x2C command for IRQ/DMA detection.

My question was what byte are you sending out (assuming it's just a fake ADC output) ?

newold86 wrote:

At what moment is it happening ?

Just after "Test Menu" -> "Sound Output"

newold86 wrote:

PC XT
Actually, it's strange - I assume there is only discrete logic in the circuit (no MCU involved) ?

No MCU. When you run something like Ultima 6 or Prince of Persia on a too fast PC - the music is a mess, nevertheless some notes do reach OPL2, so the same is here.

root42 wrote:

That runtime error looks like the typical Turbo Pascal problem when running on a too fast PC...

Update: After disabling QEMM there is no run-time error anymore, but no sound as well, it just hangs.

newold86 wrote:

My question was what byte are you sending out (assuming it's just a fake ADC output) ?

FF

LABS wrote:

When you run something like Ultima 6 or Prince of Persia on a too fast PC - the music is a mess, nevertheless some notes do reach OPL2, so the same is here.

Have you tried older “real” SB on your PCs ? If they behave the same, relatively simple wait-states circuit should help...

8bit SB cards with pentium1 systems is a real mess, the lower that I found working OK is the CT1600

newold86 wrote:

LABS wrote:

When you run something like Ultima 6 or Prince of Persia on a too fast PC - the music is a mess, nevertheless some notes do reach OPL2, so the same is here.

Have you tried older “real” SB on your PCs ? If they behave the same, relatively simple wait-states circuit should help...

Actually I was going to implement such circuit in the board, but dropped it.
Even pulling IOCHRDY on every OPL2 I/O for a maximum period (before DRAM refresh) helped just a little. On P166 Prince of Persia sounded fine, but for example Ultima 6 and Indiana Jones were still a mess, but already more recognizable. test-sbc was way more responsive during detect, but not perfect. As I remember now the maximum period I got was 16us, but OPL2 requires 23us. The only workaround I see is implementing a FIFO accumulator.

Are you sure your IOCHRDY was implemented for READ operations as well ? If the software was designed with OPL2 in mind, they supposed to implement fake reads to slow down IO process, and if tou get just a few us for each fake read, it should be enough.
Yes, FIFO could be an answer, but without CPLD way too many ICs...

newold86 wrote:

Are you sure your IOCHRDY was implemented for READ operations as well ? If the software was designed with OPL2 in mind, they supposed to implement fake reads to slow down IO process, and if tou get just a few us for each fake read, it should be enough.
Yes, FIFO could be an answer, but without CPLD way too many ICs...

Yes, it was /CS-driven

Just received some fresh OPL2s 😀