Home Page
Posted By: Vas Crabb Let's have fun with DSPs! - 03/14/18 04:59 PM
https://github.com/cuavas/mame/tree/dsp16

The DSP16A is an interesting chip. It's like the great granddaddy of VLIW and EPIC.
  • The instruction set is explicitly parallel, and it can manage a 16*16->32 multiply, a 32+36->36 addition, a 12+12->12 addition, a 16+16->16 (9+9->9 on DSP16) addition, two 8-bit increments, a ROM fetch, and a RAM access in a single cycle. Yes, the word is and, although there are limitations on the exact combinations you can use.
  • There are effectively no general-purpose registers - every register has an assigned role, although in some cases a few registers are interchangeable (e.g. the two accumulators and four RAM pointers).
  • It has dedicated silicon for saturation and rounding.
  • It has an on-board pseudorandom sequence generator.
  • It normally overlaps the ROM fetch for the next instruction with the current instruction, but it has a manually managed 15-instruction cache in the control unit. When executing from cache, it can overlap a ROM data fetch for the next instruction with the current instruction for higher throughput. By executing a tight loop from cache, you can make a very fast FIR filter with coefficients in ROM.
  • Although the DSP16 can only use internal program ROM or external program memory, but not both at the same time, the DSP16A can access external program memory while the internal ROM is enabled (QSound uses this to read sample data).
  • It supports multi-master time-division multiplexed synchronous serial protocols, making it ideal for processing circuit-switched voice calls.
  • The QSound DSP runs at 30MHz (60MHz clock input divided by two). On CPS2, it's already clocked at almost three times the speed of the main 68k CPU, it can issue an instruction every one or two cycles, and it can do up to four operations per instruction. The QSound DSP is far more powerful than the main CPU.


I've implemented almost all of the instructions, and enough of the onboard peripherals to for the QSound program to work. It's machine cycle-granular and fully interruptible. I think I've got a logic bug making looping samples screw up or something, so it doesn't sound right. It also has very high CPU requirements now that it's trying to run a 4-way explicit DSP at 30MHz.

Also, I want to meet the guy who wrote the program and buy him a beer. There are some pretty amusing techniques in the code.
Posted By: Dr.Zer0 Re: Let's have fun with DSPs! - 03/14/18 05:32 PM
Great !
Posted By: Lord Nightmare Re: Let's have fun with DSPs! - 03/14/18 06:47 PM
Originally Posted by Vas Crabb

Also, I want to meet the guy who wrote the program and buy him a beer. There are some pretty amusing techniques in the code.


https://en.wikipedia.org/wiki/Brian_L._Schmidt
Posted By: Phil Bennett Re: Let's have fun with DSPs! - 03/14/18 10:21 PM
Exciting stuff! Let me know if you need any digital audio captures from the hardware for verification purposes. I'm sure I can arrange something smile
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/15/18 01:26 AM
Thanks for the offer Phil - it might be useful. I've force-pushed an update, and it's working much better now (issue with interrupt emulation, and AM_MIRROR covering too many bits). It just seems to be reading samples from the wrong place in ROM or something.
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/15/18 02:01 AM
And with a bit more tweaking, it reads samples from the right place! Effects sound right to me. I guess it's time to think about making it fast now...
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/15/18 04:04 AM
http://arcade.vastheman.com/qsound.wav
The QSound jingle at 8s plays 16 channels simultaneously with effects, then you can hear the first few seconds of the attract music with spatialiser in effect from about 18s (it's a 30-second capture of sfz2alj with QSoundâ„¢ DSP emulated).
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/15/18 05:47 AM
Oh, while I think of it Phil, do you have the gear to check what the glue logic presents on the low eight data lines during sample reads? The DSP wants 16-bit signed samples, and the ROM contains 8-bit signed samples that need to end up in the most significant byte. I want to know what ends up in the least significant byte (I'm emulating it as byte smearing).

The lines in question are RB00 to RB07, on pins 35, 36, 37, 38, 39, 40, 42 and 43 (information manual p7-7 or 162 in PDF numbering). I want to know if they're always tied high/low, or if they're somehow affected by what's on lines RB08 to RB15, on pins 44, 45, 46, 47, 48, 49, 50 and 51. The DSP samples RB00 to RB15 on falling edges of the CKO output (pin 33, see p7-10/165). There are no read/write strobes as it's designed to be used with dumb ROM.
Posted By: Firehawke Re: Let's have fun with DSPs! - 03/15/18 07:28 AM
I put together a quick demo video of the new audio improvements: https://www.twitch.tv/videos/238950989
It goes SFA2 old, SFA2 with QSound, SFA1 old, then SFA1 with QSound. Seems like SFA2 is a lot more noticeable than SFA1, but I'd put that down to them having more time to work with QSound in general.
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/15/18 09:10 AM
And with a bit more love, the new DSP16 core and disassembler are in mainline, although it still isn't enabled for QSound due to the current performance.

Phil, I thought of another thing I'd like traced on a real game (doesn't matter whether it's CPS1.5/CPS2/ZN1/ZN2). Could you capture the following for a couple of sample periods and show a graph:
  • OSE (DSP pin 52, output)
  • OCK (DSP pin 59, output)
  • OLD (DSP pin 60, output)
  • SYNC (DSP pin 62, input?)
  • PSEL (DSP pin 72, output)
  • WS (TDA1543 DAC pin 2, input)
Posted By: Just Desserts Re: Let's have fun with DSPs! - 03/15/18 10:17 AM
So, yeah, there are definitely still issues. In test mode, music track 001E (Stone Man's stage, incidentally) in megaman2 starts out fine, but about 5-10 seconds in, starts playing sound effects as instrument samples.
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/15/18 03:42 PM
The remaining known issue is a communication breakdown between the DSP and the Z80 caused by MAME's timeslicing. It's too late to fix it tonight, I'll work around it another day.
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/20/18 12:02 PM
I did a write-up on the most prominent effect provided by the QSound DSP, and the one that's most obviously missing from the old simulation: https://rants.vastheman.com/2018/03/20/qfactor/
Posted By: R. Belmont Re: Let's have fun with DSPs! - 03/20/18 12:47 PM
Nice writeup! That explains the PS1 implementation, which simply cross-faded between dry and pre-processed (presumably with that filter) versions of each sample on each stereo channel. To my ears it didn't work as well as the realtime implementation on the Saturn's SCSP DSP.
Posted By: Haze Re: Let's have fun with DSPs! - 03/20/18 03:59 PM
vsav2 seems to have an instrumentation problem on the first loop of attract mode

compare 28 seconds in
https://youtu.be/KWl3EX5QniE?t=0m28s
with 8m16 seconds in
https://youtu.be/KWl3EX5QniE?t=8m16s

this is with code from last night

doesn't happen with the HLE, only happens the first time after boot, like something is uninitialized or initialized to the wrong value at that point.
Posted By: Olivier Galibert Re: Let's have fun with DSPs! - 03/20/18 05:53 PM
Originally Posted by R. Belmont
Nice writeup! That explains the PS1 implementation, which simply cross-faded between dry and pre-processed (presumably with that filter) versions of each sample on each stereo channel. To my ears it didn't work as well as the realtime implementation on the Saturn's SCSP DSP.


For great justice, you also need the inter-ear delay (both ears don't get the sound at the exact same time), and I suspect the ps1 implementation didn't have the trigger precision for that (we're talking up to 15 samples difference at 24KHz).
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/20/18 10:30 PM
Originally Posted by Haze
vsav2 seems to have an instrumentation problem on the first loop of attract mode

compare 28 seconds in
https://youtu.be/KWl3EX5QniE?t=0m28s
with 8m16 seconds in
https://youtu.be/KWl3EX5QniE?t=8m16s

this is with code from last night

doesn't happen with the HLE, only happens the first time after boot, like something is uninitialized or initialized to the wrong value at that point.


The DSP zeroes its RAM on start, so I'd say it's pretty hard for it to be something uninitialised there. The sample bank is set for every sample ROM read. I'd say the game is neglecting to set something the first time through.
Posted By: Haze Re: Let's have fun with DSPs! - 03/20/18 10:49 PM
I guess I'll poke Smit / TDU then

the only source material I can find that appears to from original PCBs does not have this problem, but I'll see if I can confirm it.
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 03/20/18 11:20 PM
If you want to make it easier, do the following:
  • Run with debugger enabled with DSP emulation
  • While bad music is playing, dump low 128 (0x80) words of DSP "ram" address space (AS_DATA)
  • While good music is playing, dump low 128 (0x80) words of DSP "ram" address space (AS_DATA)
  • The sample banks are at addresses 0x00, 0x08, 0x10, 0x18, ..., 0x70, 0x78 so identify the bad ones
  • Edit src/devices/sound/qsound.cpp to put "#define VERBOSE (LOG_COMMAND)" in the appropriate sport near the top and rebuild
  • Run with logging until the bad music plays and then stop it
  • Filter the log for lines matching the pattern "QSound: DSP command @[0-7][08] = " to see the Z80 setting sample banks
  • See if any of the sample banks in the RAM dump don't match what the most recent command Z80 command tried to set
Posted By: Haze Re: Let's have fun with DSPs! - 04/01/18 11:15 AM
well we have confirmation that it doens't happen on hardware, using same ROMs as MAME
https://www.youtube.com/watch?v=RWZAAHMnJ4M

So assuming none of the rejigging in MAME has changed anything already, I'll see if I can provide any more information with the above steps next time I get a chance.
Posted By: Haze Re: Let's have fun with DSPs! - 07/27/18 12:07 AM
I decided to give this another spin since I saw there were some DSP16 fixes in the latest build.

The behavior does seem to have changed, although I'd be hesitant to call it fixed.

On *first* boot, with no NVRAM, the game seems to play it correctly.

On subsequent boots, with NVRAM present, it glitches, however if you f3 reset during the music it plays correctly.

I haven't managed to get any useful information from debugging it tho.

One thing I have noticed, which I think is a regression is with the HLE tho. During the Qsound logo I'm getting random garbage samples playing in the background? I don't remember that happening with old versions (and testing with a build from november of last year, it doesn't) but at the same time don't know why the HLE would have regressed to the point of playing random samples!

I'm guessing there's something a bit out of spec with the sound program on this one, because I'm not seeing such weird behavior elsewhere.


Posted By: Tafoid Re: Let's have fun with DSPs! - 07/27/18 01:38 AM
To follow this up, 2 specific games (vsav2, qndream) both have this observed samples in the background while the Qsound logo is presented and the jingle is playing. As near as I could trace, The breakage happens March 19-20 after this commit:
https://github.com/mamedev/mame/commit/deaa08b3b29414e9c3ecfee4ab37e06741fca6a0

The other commit that day dealing with Qsound only appeared to change comments, no code.

Posted By: Vas Crabb Re: Let's have fun with DSPs! - 07/29/18 08:05 AM
Try with https://github.com/mamedev/mame/commit/51cebe3f60aa2584d02eac8c67455c8691fce934
Posted By: Haze Re: Let's have fun with DSPs! - 07/29/18 11:23 AM
yeah, that seems to bring the Qsound HLE back to working state, LLE unchanged, but that was to be expected.

the LLE problem is definitely a weird one, especially as it doesn't happen first boot, even if you hit F2 and go to the sound test and play the same song while it's glitching, it doesn't happen on the test mode, still haven't actually managed to find out what causes it / where it comes from tho.
Posted By: Vas Crabb Re: Let's have fun with DSPs! - 07/29/18 11:25 AM
It's a synchronisation problem, plain and simple. When Judge's Z80 core is ready we should be able to solve it properly.
© Forums