jmarsh,
- the DOSBox-X team has integrated and tested your DMA status register fix: https://github.com/joncampbell123/dosbox-x/issues/1961, and I suspect it will appear in their next release.
- it's been further integrated into DOSBox Staging, https://github.com/dosbox-staging/dosbox-staging/pull/685 with yourself credited as the original author in the commit.

After seeing the documentation that Jon Cambell references, it's indeed a correction and improvement. Thank you.

So I guess this emulation improvment isn't in DOSBox SVN ?

Ähm, reread the initial question by Kcroft...

Oh, good.

What about Nuked OPL ?

Nuked OPL is another implementation of the OPL implementation that some people think is superior to other implementations. What else do you need to know about it?

Many thanks to jmarsh, Jon Cambell and krcroft for the joint improvement efforts to the GUS implementation.

Dominus wrote on 2020-10-25, 21:24:

Nuked OPL is another implementation of the OPL implementation that some people think is superior to other implementations. What else do you need to know about it?

All other forks added it as an option, and to me and others it is clearly superior. I compared to real hardware, and it's noticeably more faithful. Why isn't it in SVN ?
Any reason would be fine, but I did not find anything.

It's on the table to be checked to be added.
Do you have any games in which this opl core is superior to the others ? (so I can compare it myself)

Lands of Lore comes to mind, especially the forest part (beginning of the game) compared to a real SB16.

Edit:
Also, Cryo's Dune with Adlib music is clearly better with Nuked OPL enabled.
After all, this games contains specific drivers and uses undocumented features, or so the story goes anyway.

xcomcmdr wrote on 2020-10-26, 07:48:

After all, this games contains specific drivers and uses undocumented features, or so the story goes anyway.

Unless it uses the "composite sine wave mode", which afaik nobody has ever documented (not even Yamaha themselves), I don't think there are "undocumented features" in the OPL2.

JAL

Some more info here :
http://www.vgmpf.com/Wiki/index.php/HERAD

But that's beside the point, anyway.

xcomcmdr wrote on 2020-10-26, 09:05:

Some more info here : http://www.vgmpf.com/Wiki/index.php/HERAD

Ad Lib Inc., in its Programmer's Manual, shows the full register map of the OPL2, as far as I can see. So this may perhaps be a misinterpretation or a misremembering of that person.

But that's beside the point, anyway.

Agreed that it's besides the point. Dosbox should not strive to be "good enough" to play games, it should run the games as good as possible. If that means better OPL2 emulation, then I'd go for it.

JAL

jmarsh wrote on 2020-10-09, 09:30:

7 commits affecting the debugger in the past 12 months, including 2 in the past 30 days.
104 commits overall in the past 12 months.
Maybe take a look at the project's activity before declaring it dead?

We are now down to a single commit in the past 12 months. It’s dead, Jim.

With Staging and X we can see PRs being merged almost daily, they are attracting new developers, and if I was asked for a list of games which work better on the forks, I wouldn’t know where to start.

How about blessing one of the forks as an official DOSBox?

Yes, because it turns out every time a commit was made to SVN it got adopted by some of these forks and trumpeted as if it was some grand improvement that they had implemented themselves. So now they're left to their own devices... good luck running DOSBox on anything but the latest and greatest hardware/OS without a bunch of unwanted dependencies along for the ride.

OldPlayer wrote on 2023-09-06, 19:31:

We are now down to a single commit in the past 12 months. It’s dead, Jim. […]
Show full quote

jmarsh wrote on 2020-10-09, 09:30:

7 commits affecting the debugger in the past 12 months, including 2 in the past 30 days.
104 commits overall in the past 12 months.
Maybe take a look at the project's activity before declaring it dead?

We are now down to a single commit in the past 12 months. It’s dead, Jim.

With Staging and X we can see PRs being merged almost daily, they are attracting new developers, and if I was asked for a list of games which work better on the forks, I wouldn’t know where to start.

How about blessing one of the forks as an official DOSBox?

What is it these days? Too much sun and everyone needs to nag on DOSBox again?
And there is nothing to bless. X has forked so far away, pure might be an option but I wouldn't be able to judge, I'm not following it, and staging just burnt every bridge they could.
(IMO I my favorite of those is X as that is actually working on bettering the emulation)

OldPlayer,
For questions on the future of DOSBox I suggest asking Qbix or Harekiet who are the devs responsible for it. Digging up old threads is not the way.

Keep in mind that the purpose of DOSBox is an entirely open source emulator to make as many DOS games work as possible on multiple operating systems and hardware without a lot of dependencies and with default emulated options and hardware to run as many games as possible without having the user having to configure hundreds of options.

It seems that people nowadays prefer the Apple method of throwing hardware and software away since there is no money in "old" things (even though those "consumers" bought it for alot of money....). So any replacement or continuation would need to decide if they are only going to use the latest and greatest programming language, compiler, OS, Hardware, etc and stop supporting anything older or support both or decide if there is a certain cutoff period based off of bad statistics or statistics they want to believe, facts please.

It also needs to make sure it's protected legally as far as so called "abandonware" is concerned so any such project should separate itself from that unless they have the funding, time and mentality to deal with it.

Something else to keep in mind is project drift or bloat. Just because a fork has a commit doesn't mean the original project should have that commit. Forks have different purposes, commits should stay with the fork if they don't align with the other project.