New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

taito_zm: DSP emulation (work in progress!) #3854

Merged
merged 19 commits into from Aug 17, 2018

Conversation

Projects
None yet
9 participants
@superctr
Contributor

superctr commented Aug 15, 2018

Still working on this, but I'm opening the PR in order to bring some attention...

This PR improves sound emulation in Taito Zoom sound system games. This includes FX-1B and GNet boards. Comes at a fairly big performance hit, but I think you'd rather take that than the really tinny sound from before?

cam900 and others added some commits Aug 9, 2018

taito_zm.cpp : Updates
Add DSP, Reduce MCFGs, Add device_mixer_interface for sound gain, Add imperfect_features related to DSP, Add notes
Improve Taito Zoom ZSG-2 sound emulation
zsg2.cpp: implement emphasis filter, this is a noise reduction scheme
that amplifies higher frequncies to reduce quantization noise.

zsg2.cpp: Add sample interpolation and another adjustable lowpass
filter. This seems to be roughly what real hardware does...

zsg2.cpp: Improve panning registers and identify DSP output gain
registers.
zsg2: minor changes [nw]
zsg2: Register 0b appears to be status flags [nw]

zsg2: Linear ramping probably makes more sense [nw]
tms57002: Fixes to make Taito Zoom DSP working
tms57002: Add undocumented instruction saom / raom, they set saturation
mode for the ALU.

tms57002: Implement MACC pipeline.

tms57002: Add callbacks for EMPTY and PC0 pins.

tms57002: Add a few unimplemented instructions.

tms57002: Proper behavior of CMEM UPLOAD mode.

tms57002: Fix an issue where program is not properly loaded if PLOAD is
set after a program has already been written.
taito_zm: Working DSP emulation
Pretty much OST quality now. A pretty decent upgrade from how it was
previously, I'd say.
@BPzeBanshee

Hi superctr! Just one compile issue I found and aside from that was able to compile fine. Amazing work!

I know you said you were still working on this but in case you weren't aware I did notice some of Psyvariar Revision's tracks being unbalanced towards a speaker (and amplified) since these changes which I didn't notice with the previous pull request.

Show outdated Hide outdated src/devices/cpu/tms57002/tms57002.cpp
@superctr

This comment has been minimized.

Show comment
Hide comment
@superctr

superctr Aug 15, 2018

Contributor

I'll look into the issue regarding psyvarrv when I get home. All GNet games use the same DSP code, so it's possible it's related to the raycrisis song 9 issue.

Contributor

superctr commented Aug 15, 2018

I'll look into the issue regarding psyvarrv when I get home. All GNet games use the same DSP code, so it's possible it's related to the raycrisis song 9 issue.

@rb6502 rb6502 merged commit 3b57b7e into mamedev:master Aug 17, 2018

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/tea the build was successful
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@superctr

This comment has been minimized.

Show comment
Hide comment
@superctr

superctr Aug 17, 2018

Contributor

I was still working on this...

Contributor

superctr commented Aug 17, 2018

I was still working on this...

@rb6502

This comment has been minimized.

Show comment
Hide comment
@rb6502

rb6502 Aug 17, 2018

Contributor

Please don't open PRs you don't want merged then :)

Contributor

rb6502 commented Aug 17, 2018

Please don't open PRs you don't want merged then :)

@superctr

This comment has been minimized.

Show comment
Hide comment
@superctr

superctr Aug 17, 2018

Contributor

How else should I get feedback then? Like that Psyvariar issue, I might not have found it otherwise. Anyway, I looked at that, it's weird, the CPU sends to the DSP which looks like a value and what is supposed to be the same value, but inverted. Except the sign bit actually isn't set, making it a huge positive integer instead. And looking at the CPU code, it looks completely intentional there, so it leads me to the DSP, where somehow there must be some behavior that causes a CMEM variable to be left shifted 1 before being sent to the multiply ALU, in order to make the value signed.

Contributor

superctr commented Aug 17, 2018

How else should I get feedback then? Like that Psyvariar issue, I might not have found it otherwise. Anyway, I looked at that, it's weird, the CPU sends to the DSP which looks like a value and what is supposed to be the same value, but inverted. Except the sign bit actually isn't set, making it a huge positive integer instead. And looking at the CPU code, it looks completely intentional there, so it leads me to the DSP, where somehow there must be some behavior that causes a CMEM variable to be left shifted 1 before being sent to the multiply ALU, in order to make the value signed.

@balr0g

This comment has been minimized.

Show comment
Hide comment
@balr0g

balr0g Aug 17, 2018

Contributor

How else should I get feedback then?

The best way is by putting DO NOT MERGE in the PR text.

Contributor

balr0g commented Aug 17, 2018

How else should I get feedback then?

The best way is by putting DO NOT MERGE in the PR text.

@superctr

This comment has been minimized.

Show comment
Hide comment
@superctr

superctr Aug 17, 2018

Contributor

Ok, I thought I was clear with the "WIP" tag, but I'll just do that next time then.

Contributor

superctr commented Aug 17, 2018

Ok, I thought I was clear with the "WIP" tag, but I'll just do that next time then.

@rb6502

This comment has been minimized.

Show comment
Hide comment
@rb6502

rb6502 Aug 17, 2018

Contributor

The best way to get operational feedback is to have it merged so everyone can test it. Non-merge PRs in the future will be closed summarily; we have too much cruft already to deal with.

Contributor

rb6502 commented Aug 17, 2018

The best way to get operational feedback is to have it merged so everyone can test it. Non-merge PRs in the future will be closed summarily; we have too much cruft already to deal with.

@MooglyGuy

This comment has been minimized.

Show comment
Hide comment
@MooglyGuy

MooglyGuy Aug 17, 2018

Contributor

And summarily reopened, because there's nothing wrong with submitting a PR in order to get feedback before it goes in. That's how we've operated for months now, and how we will continue to operate. If you don't feel like giving feedback, don't give it, but let others do what they wish.

Contributor

MooglyGuy commented Aug 17, 2018

And summarily reopened, because there's nothing wrong with submitting a PR in order to get feedback before it goes in. That's how we've operated for months now, and how we will continue to operate. If you don't feel like giving feedback, don't give it, but let others do what they wish.

@rb6502

This comment has been minimized.

Show comment
Hide comment
@rb6502

rb6502 Aug 17, 2018

Contributor

We have never operated that way. You get testing by having your changes go in like a big boy or girl and letting people bang on them. If you can't handle that, you arrange for your friends to pull from your private github.

Contributor

rb6502 commented Aug 17, 2018

We have never operated that way. You get testing by having your changes go in like a big boy or girl and letting people bang on them. If you can't handle that, you arrange for your friends to pull from your private github.

@rb6502

This comment has been minimized.

Show comment
Hide comment
@rb6502

rb6502 Aug 17, 2018

Contributor

The only kind of submit-for-feedback we have supported is on coding style/standards.

Contributor

rb6502 commented Aug 17, 2018

The only kind of submit-for-feedback we have supported is on coding style/standards.

@MoochMcGee

This comment has been minimized.

Show comment
Hide comment
@MoochMcGee

MoochMcGee Aug 19, 2018

Contributor

Oh come on, Arbee, MOST projects prefer if you submit a PR in the meantime, just so they can review your approach and shit, and so the coder doesn't end up wasting nearly as much of their time.

Contributor

MoochMcGee commented Aug 19, 2018

Oh come on, Arbee, MOST projects prefer if you submit a PR in the meantime, just so they can review your approach and shit, and so the coder doesn't end up wasting nearly as much of their time.

@superctr superctr deleted the superctr:taito_zoom_dsp branch Aug 20, 2018

@@ -14,12 +14,15 @@
#include "cpu/tms57002/tms57002.h"
#include "sound/zsg2.h"
#define USE_DSP // Uncomment when DSP emulation is working

This comment has been minimized.

@cuavas

cuavas Aug 29, 2018

Member

This name is far too generic for something in a header that needs to be included in downstream driver sources. Could someone please either remove it completely if the DSP is in fact working, or at least prefix it with something to make it less likely to class with something equally generically named in another header?

@cuavas

cuavas Aug 29, 2018

Member

This name is far too generic for something in a header that needs to be included in downstream driver sources. Could someone please either remove it completely if the DSP is in fact working, or at least prefix it with something to make it less likely to class with something equally generically named in another header?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment