summaryrefslogtreecommitdiffstatshomepage
path: root/src/devices/sound/qsound.cpp
blob: 7d1ac1c7b9b484283663ca4cdf67d55b73874c45 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
// license:BSD-3-Clause
// copyright-holders:Vas Crabb
/***************************************************************************

    Capcom System QSound™

    Sixteen-channel sample player.  Previous HLE implementation by Paul
    Leaman and Miguel Angel Horna, with thanks to CAB (author of Amuse).

    The key components are a DSP16A, a TDA1543 dual 16-bit DAC with I2S
    input, and a TC9185P electronic volume control.  The TDA1543 is
    simulated here; no attempt is being made to emulate theTC9185P.

    Commands work by writing an address/data word pair to be written to
    DSP's internal RAM.  In theory it's possible to write anywhere in
    DSP RAM, but the glue logic only allows writing to the first 256
    words.  The host writes the high and low bytes the data word to
    offsets 0 and 1, respectively, and the address to offset 2.  Writing
    the address also asserts the DSP's INT pin.  The host can read back
    a single bit, which I've assumed reflects the current state of the
    DSP's INT pin (low when asserted).  The host won't send further
    commands until this bit goes high.

    On servicing an external interrupt, the DSP reads pdx0 three times,
    expecting to get the address and data in that order (the third read
    is needed because DSP16 has latent PIO reads in active mode).  I've
    assumed that reading PIO with PSEL low when INT is asserted will
    return the address and cause INT to be de-asserted, and reading PIO
    with PSEL low when int is not asserted will return the data word.
    The DSP program will only respond to one external interrupt per
    sample interval (i.e. the maximum command rate is the same as the
    sample rate).

    The DSP program uses 2 kilowords of internal RAM and reads data from
    external ROM while executing from internal ROM.  As such, it
    requires a DSP16A core (the original DSP16 only has 512 words of
    internal RAM and can't read external ROM with internal ROM enabled).

    To read external ROM, the DSP writes the desired sample offset to
    PDX0, then reads external ROM at address (bank | 0x8000), for a
    theoretical maximum of 2 gigasamples.  The bank applies to the next
    read, not the current read.  A dummy read is required to set the
    bank for the very first read.  This latency could just be a quirk of
    how Capcom hooks the DSP up to the sample ROMs.  In theory, samples
    are 16-bit signed values, but Capcom only has 8-bit ROMs connected.
    I'm assuming byte smearing, but it may be zero-padded in the LSBs.

    The DSP sends out 16-bit samples on its SIO port clocked at 5 MHz.
    The stereo samples aren't loaded fast enough for consecutive frames
    so there's an empty frame between them.  Sample pairs are loaded
    every 1,248 machine cycles, giving a sample rate of 24.03846 kHz
    (60 MHz / 2 / 1248).  The glue logic seems to generate the WS signal
    for the DAC from the PSEL line and the SIO control lines, but it
    isn't clear exactly how this is achieved.

    The DSP writes values to pdx1 every sample cycle (alternating
    between zero and non-zero values).  This may be for the volume
    control chip or something else.

    The photographs of the DL-1425 die (WEDSP16A-M14) show 12 kilowords
    of internal ROM compared to 4 kilowords as documented.  It's unknown
    if/how the additional ROM is mapped in the DSP's internal ROM space.
    The internal program only uses internal ROM from 0x0000 to 0x0fff
    and external space from 0x8000 onwards.  The additional ROM could
    be anywhere in between.

    Meanings for known command words:
    (((ch - 1) << 3) & 0x78     sample bank
    (ch << 3) | 0x01            channel sample offset within bank
    (ch << 3) | 0x02            channel playback rate
    (ch << 3) | 0x03            channel sample period counter
    (ch << 3) | 0x04            channel loop offset (relative to end)
    (ch << 3) | 0x05            channel end sample offset
    (ch << 3) | 0x06            channel volume
    ch | 0x80                   left/right position on sound stage
    0x93                        delayed reverb volume
    ch + 0xba                   channel reverb contribution
    0xd9                        reverb delay (need to add 0x0554)
    0xde                        left output filtered component delay
    0xdf                        left output unfiltered component delay
    0xe0                        right output filtered component delay
    0xe1                        right output unfiltered component delay
    0xe2                        write non-zero to set delays
    0xe4                        left output filtered component volume
    0xe5                        left output unfiltered component volume
    0xe6                        right output filtered component volume
    0xe7                        right output unfiltered component volume

    The weird way of setting the sample bank is due to the one-read
    latency described above.  Since the bank applies to the next read,
    you need to set it on the channel before the desired channel.

    Links:
    * https://siliconpr0n.org/map/capcom/dl-1425

***************************************************************************/

#include "emu.h"
#define QSOUND_LLE
#include "qsound.h"

#include <algorithm>
#include <fstream>

#define LOG_GENERAL     (1U << 0)
#define LOG_COMMAND     (1U << 1)
#define LOG_SAMPLE      (1U << 2)

//#define VERBOSE (LOG_GENERAL | LOG_COMMAND | LOG_SAMPLE)
//#define LOG_OUTPUT_STREAM std::cout
#include "logmacro.h"

#define LOGCOMMAND(...)     LOGMASKED(LOG_COMMAND, __VA_ARGS__)
#define LOGSAMPLE(...)      LOGMASKED(LOG_SAMPLE, __VA_ARGS__)


// device type definition
DEFINE_DEVICE_TYPE(QSOUND, qsound_device, "qsound", "QSound")


// DSP internal ROM region
ROM_START( qsound )
	ROM_REGION( 0x2000, "dsp", 0 )
	ROM_LOAD16_WORD_SWAP( "dl-1425.bin", 0x0000, 0x2000, CRC(d6cf5ef5) SHA1(555f50fe5cdf127619da7d854c03f4a244a0c501) )
	ROM_IGNORE( 0x4000 )
ROM_END


//-------------------------------------------------
//  qsound_device - constructor
//-------------------------------------------------

qsound_device::qsound_device(machine_config const &mconfig, char const *tag, device_t *owner, u32 clock)
	: device_t(mconfig, QSOUND, tag, owner, clock)
	, device_sound_interface(mconfig, *this)
	, device_rom_interface(mconfig, *this, 24)
	, m_dsp(*this, "dsp"), m_stream(nullptr)
	, m_rom_bank(0U), m_rom_offset(0U), m_cmd_addr(0U), m_cmd_data(0U), m_new_data(0U), m_cmd_pending(0U), m_dsp_ready(1U)
	, m_samples{ 0, 0 }, m_sr(0U), m_fsr(0U), m_ock(1U), m_old(1U), m_ready(0U), m_channel(0U)
{
}


WRITE8_MEMBER(qsound_device::qsound_w)
{
	switch (offset)
	{
	case 0:
		LOGCOMMAND(
				"QSound: set command data[h] = %02X (%04X -> %04X)\n",
				data, m_new_data, (m_new_data & 0x00ffU) | (u16(data) << 8));
		m_new_data = (m_new_data & 0x00ffU) | (u16(data) << 8);
		break;
	case 1:
		LOGCOMMAND(
				"QSound: set command data[l] = %02X (%04X -> %04X)\n",
				data, m_new_data, (m_new_data & 0xff00U) | data);
		m_new_data = (m_new_data & 0xff00U) | data;
		break;
	case 2:
		m_dsp_ready = 0U;
		machine().scheduler().synchronize(
				timer_expired_delegate(FUNC(qsound_device::set_cmd), this),
				(unsigned(data) << 16) | m_new_data);
		break;
	default:
		logerror("QSound: host write to unknown register %01X = %02X (%s)\n", offset, data, machine().describe_context());
	}
}


READ8_MEMBER(qsound_device::qsound_r)
{
	return m_dsp_ready ? 0x80 : 0x00;
}


//-------------------------------------------------
//  rom_region - return a pointer to the device's
//  internal ROM region
//-------------------------------------------------

const tiny_rom_entry *qsound_device::device_rom_region() const
{
	return ROM_NAME( qsound );
}


//-------------------------------------------------
//  device_add_mconfig - add device configuration
//-------------------------------------------------

MACHINE_CONFIG_START(qsound_device::device_add_mconfig)
	MCFG_DEVICE_ADD("dsp", DSP16A, DERIVED_CLOCK(1, 1))
	MCFG_DEVICE_IO_MAP(dsp_io_map)
	MCFG_DSP16_OCK_CB(WRITELINE(*this, qsound_device, dsp_ock_w))
	MCFG_DSP16_PIO_R_CB(READ16(*this, qsound_device, dsp_pio_r))
	MCFG_DSP16_PIO_W_CB(WRITE16(*this, qsound_device, dsp_pio_w))
MACHINE_CONFIG_END


//-------------------------------------------------
//  device_start - device-specific startup
//-------------------------------------------------

void qsound_device::device_start()
{
	// hope we get good synchronisation between the DSP and the sound system
	m_stream = stream_alloc(0, 2, clock() / 2 / 1248);

	// save DSP communication state
	save_item(NAME(m_rom_bank));
	save_item(NAME(m_rom_offset));
	save_item(NAME(m_cmd_addr));
	save_item(NAME(m_cmd_data));
	save_item(NAME(m_new_data));
	save_item(NAME(m_cmd_pending));
	save_item(NAME(m_dsp_ready));

	// save serial sample recovery state
	save_item(NAME(m_samples));
	save_item(NAME(m_sr));
	save_item(NAME(m_fsr));
	save_item(NAME(m_ock));
	save_item(NAME(m_old));
	save_item(NAME(m_ready));
	save_item(NAME(m_channel));
}


//-------------------------------------------------
//  device_reset - device-specific reset
//-------------------------------------------------

void qsound_device::device_reset()
{
	// TODO: does this get automatically cleared on reset or not?
	m_cmd_pending = 0U;
	m_dsp_ready = 1U;
	m_dsp->set_input_line(DSP16_INT_LINE, CLEAR_LINE);
}


//-------------------------------------------------
//  sound_stream_update - handle a stream update
//-------------------------------------------------

void qsound_device::sound_stream_update(sound_stream &stream, stream_sample_t **inputs, stream_sample_t **outputs, int samples)
{
	std::fill_n(outputs[0], samples, m_samples[0]);
	std::fill_n(outputs[1], samples, m_samples[1]);
}


//-------------------------------------------------
//  rom_bank_updated - the rom bank has changed
//-------------------------------------------------

void qsound_device::rom_bank_updated()
{
	machine().scheduler().synchronize();
}


// DSP external ROM space
void qsound_device::dsp_io_map(address_map &map)
{
	map.unmap_value_high();
	map(0x0000, 0x7fff).mirror(0x8000).r(FUNC(qsound_device::dsp_sample_r));
}


READ16_MEMBER(qsound_device::dsp_sample_r)
{
	// FIXME: DSP16 doesn't like bytes, only signed words - should this zero-pad or byte-smear?
	u8 const byte(read_byte((u32(m_rom_bank) << 16) | m_rom_offset));
	if (!machine().side_effects_disabled())
		m_rom_bank = offset;
	return (u16(byte) << 8) | u16(byte);
}

WRITE_LINE_MEMBER(qsound_device::dsp_ock_w)
{
	// detect active edge
	if (bool(state) == bool(m_ock))
		return;
	m_ock = state;
	if (!state)
		return;

	// detect start of word
	if (m_ready && !m_fsr && !m_dsp->ose_r())
	{
		// FIXME: PSEL at beginning of word seems to select channel, but how does the logic derive WS from the DSP outputs?
		m_channel = m_dsp->psel_r();
		m_fsr = 0xffffU;
	}

	// shift in data
	if (m_fsr)
	{
		m_sr = (m_sr << 1) | (m_dsp->do_r() ? 0x0001U : 0x0000U);
		m_fsr >>= 1;
		if (!m_fsr)
		{
			LOGSAMPLE("QSound: recovered channel %u sample %04X\n", m_channel, m_sr);
			if (!m_channel)
				m_stream->update();
			m_samples[m_channel] = m_sr;
#if 0 // enable to log PCM to a file - can be imported with "ffmpeg -f s16be -ar 24038 -ac 2 -i qsound.pcm qsound.wav"
			static std::ofstream logfile("qsound.pcm", std::ios::binary);
			logfile.put(u8(m_sr >> 8));
			logfile.put(u8(m_sr));
#endif
		}
	}

	// detect falling OLD - indicates next bit could be start of a word
	u8 const old(m_dsp->old_r());
	m_ready = (m_old && !old);
	m_old = old;
}

WRITE16_MEMBER(qsound_device::dsp_pio_w)
{
	/*
	 *  FIXME: what does this do when PDX is high?
	 *  There are seemingly two significant points where the program writes PDX1 every sample interval.
	 *
	 *  Before writing the right-channel sample to SDX - this causes the PSEL 0->1 transition:
	 *  0:5d4: 996e       if true a0 = rnd(a0)
	 *  0:5d5: 51e0 0000  pdx1 = 0x0000
	 *  0:5d7: 49a0       move sdx = a0
	 *
	 * This curious code where it writes out the a word from RAM@0x00f1 - this value seems significant:
	 * 0:335: 18f1       set r0 = 0x00f1
	 * 0:336: 3cd0       nop, a0 = *r0
	 * 0:337: d850       p = x*y, y = a1, x = *pt++i
	 * 0:338: 49e0       move pdx1 = a0
	 */
	if (offset)
		LOG("QSound: DSP PDX1 = %04X\n", data);
	else
		m_rom_offset = data;
}


READ16_MEMBER(qsound_device::dsp_pio_r)
{
	LOGCOMMAND(
			"QSound: DSP PIO read returning %s = %04X\n",
			m_cmd_pending ? "addr" : "data", m_cmd_pending ? m_cmd_addr : m_cmd_data);
	if (m_cmd_pending)
	{
		m_cmd_pending = 0U;
		m_dsp->set_input_line(DSP16_INT_LINE, CLEAR_LINE);
		machine().scheduler().synchronize(timer_expired_delegate(FUNC(qsound_device::set_dsp_ready), this));
		return m_cmd_addr;
	}
	else
	{
		return m_cmd_data;
	}
}

void qsound_device::set_dsp_ready(void *ptr, s32 param)
{
	m_dsp_ready = 1U;
}

void qsound_device::set_cmd(void *ptr, s32 param)
{
	/*
	 *  I don't believe the data word is actually double-buffered in
	 *  real life.  In practice it works because the DSP's instruction
	 *  throughput is so much higher than the Z80's that it can always
	 *  read the data word before the Z80 can realise it's read the
	 *  address.
	 *
	 *  In MAME, there's a scheduler synchronisation barrier when the
	 *  DSP reads the address but before it reads the data.  When this
	 *  happens, MAME may give the Z80 enough time to see that the DSP
	 *  has read the address and write more data before scheduling the
	 *  DSP again.  The DSP then reads the new data and stores it at
	 *  the old command address.
	 *
	 *  You can see this happening in megaman2 test mode by playing
	 *  command 0x11 (Gyro Man's theme).  Within two minutes, some
	 *  channels' sample banks/offsets will likely be overwritten.
	 */
	LOGCOMMAND("QSound: DSP command @%02X = %04X\n", u32(param) >> 16, u16(u32(param)));
	m_cmd_addr = u16(u32(param) >> 16);
	m_cmd_data = u16(u32(param));
	m_cmd_pending = 1U;
	m_dsp->set_input_line(DSP16_INT_LINE, ASSERT_LINE);
}