Battler wrote:

So basically, all I need to do is not map the high bank, and that's it?

Yes. For single OPL2 it's enough. But you should emulate somehow Dual OPL2.

The emulator already has something for that, opl2_r read/write and opl2_l read/write, each going to its own OPL2 chip. Hopefully I can just reuse that.

Hi nukeykt.
Will NukedOPL v2.0 be available as a patch?

James-F wrote:

Hi nukeykt.
Will NukedOPL v2.0 be available as a patch?

Yes. When i'll finish it.

Hello all!

please, can anyone tell me, how can install the patch file, the content of the"dosbox-nuked-opl.zip" I just replaced with the original dosbox.exe and the corresponding *.dll´s "SDL_net / SDL.dll,

For answer I am grateful 😉

Greets
Matthias

I'm using the DOSBOX ECE... I'm using my old DOSBOX conf file that was made by GoG for World of Xeen--- is oplemu the same as oplmode?

nukeykt, I noticed something when I used the YM3812-bearing CT1320 in my Tandy 1000 TX.

Most documentation states that the YM3812 can be distinguished from the YMF262 by reading the index port; a YM3812 supposedly always returns 0x06, while an YMF262 supposedly always returns 0x00. Well, on the Tandy 1000 TX, reading the index port only returns 0x06 if you write a byte with bits 1 and 2 set immediately to it before! Unlike standard ATs, the Tandy 1000 TX does not pull "open bus" bits high. That also manifests itself in reads from unmapped I/O ports returning whatever just happens to be on the bus, while on a standard AT, reading unmapped I/O ports always returns 0xFF.

Can you confirm that on the YM3812, index port bits 1 and 2 are open bus rather than "1" bits from the chip side?

Nuked OPL3 v1.8 is out.
Changelog:
* New envelope generator.
* Rhythm mode emulation is 100% correct now.

These and other aspects of chip have been verified on YMF262 die shot, so emulation should be perfect now.

P.S. For some reason i can't edit topic's header. So i'll attach patch here.

Can this be somehow used with the stable branch of Dosbox instead of SVN? I really don't like messing with SVN most of the time..

appiah4 wrote:

Can this be somehow used with the stable branch of Dosbox instead of SVN? I really don't like messing with SVN most of the time..

Yes. But you have to apply these changes to the source code manually.

nukeykt wrote:

appiah4 wrote:

Can this be somehow used with the stable branch of Dosbox instead of SVN? I really don't like messing with SVN most of the time..

Yes. But you have to apply these changes to the source code manually.

This would go way above my head I'm afraid. Would be very glad if you can build the patch for the stable version as well 😀 Thanks anyway.

appiah4 wrote:

This would go way above my head I'm afraid. Would be very glad if you can build the patch for the stable version as well 😀 Thanks anyway.

I'll give a shot then.

Here's windows builds. I've accidantly attached older build above and can't edit it.

Thank you nukeykt !

Thank you, nukeyt! DOSBox ECE was updated with your new version, as of r4088.2 it now includes version 1.8 of your Nuked OPL emu.

Hi, I have a question?
Does changing the mixer rate affects in any way the other sound sources inside DOSBox (e.g. pcrate, gusrate, tandyrate)?

If I am to take the information provided by D-Fend Reloaded as accurate, then each individual sound module as its own sample rate except for Disney Sounds Source. https://gyazo.com/c656b6de5e16b84245f7c485be8acdfc

Great , thanks for update.

Applied easily to dosbox libretro 😀
Hooking it up was eaaasy, thanks a lot!
https://git.retromods.org/dev/dosbox-svn/comm … d54743daf8861bc

nukeykt wrote:

Nuked OPL3 v1.8 is out. Changelog: * New envelope generator. * Rhythm mode emulation is 100% correct now. These and other aspe […]
Show full quote

Nuked OPL3 v1.8 is out.
Changelog:
* New envelope generator.
* Rhythm mode emulation is 100% correct now.
These and other aspects of chip have been verified on YMF262 die shot, so emulation should be perfect now.

Sad that Nuked OPL3 core is not available in "official" upcoming dosbox 0.75 branch.
It eats not too much CPU power, so it must be default as most-accurate core.