MoonSound, problem with custom samples on real machine

Page 1/3
| 2 | 3

By yzi

Champion (441)

yzi's picture

10-04-2014, 22:20

Ok, I need help from more experienced folks again. My MoonSound XM routine is working nicely with the Yamaha ROM samples, and even with custom samples in OpenMSX, but not on a real machine. I've tried all sorts of variations and rediculously long waits, but all I'm getting is weird noises from my custom-loaded samples. What am I missing here... Let's see the facts:

- In OpenMSX, everything is fine. Yamaha ROM songs are OK, custom sample songs are OK, mixed ROM+custom songs are OK.
- On a real machine (Sony HB-F1XV MSX2+ with regular Z80), Yamaha ROM sounds are OK (tone/wave number 0..383)
- On a real machine, custom samples just play noises.
- I have verified, on a real machine (as well as OpenMSX), by reading all the values back from OPL4 wave register 6, that the PCM values and headers are actually being transferred correctly to MoonSound's memory
- Before starting to upload sample and header data, I set the OPL4 wave register 2 to 0x11, and after uploading I set it to 0x10. Otherwise the custom samples wouldn't work even on OpenMSX (because the emulation checks for bit 0 being set)
- If I don't set register 2 to 0x10 after uploading, then the real machine only produces short snapping sounds. The spec says that if it's in memory read/write mode, then there's no sound production, and I can verify that. Smile (OpenMSX doesn't emulate this no-sound-mode by the way)

What might be missing? Is there some additional register I need to set, or otherwise my custom samples won't work on a real machine?

Login or register to post comments

By msd

Paragon (1372)

msd's picture

11-04-2014, 08:56

I think you set the header offset wrong.. register 2 should be 0x15 for writing to ram and than back to 0x14 when done.
The sram starts at 0x200000Hex. There can be 128Headers. start writing your sample data to address 200600H.

By yzi

Champion (441)

yzi's picture

11-04-2014, 17:23

I tried changing it to 0x15 and 0x14, but then OpenMSX played just silence or very quiet noises, and the Sony played just different noise. With 0x11 and 0x10 it works correctly in OpenMSX, and Avelino Herrera Morales's library routines had 0x10, and 0x10 is also the right value according to all the specs and documents I could find.

By yzi

Champion (441)

yzi's picture

11-04-2014, 17:49

I made a version that increments the tone header by 8 after each pattern of the song, going through all possible values in increments of 8... and _none_ of the settings was right on the real machine. In OpenMSX, all values that had the critical bits, sounded right, like for example 0x10 and 0x30. I'll try once more with increments of 4... though I'm pretty sure that's not where the problem is.

Edit: ok, listened through all of the values in increments of 4, and nothing sounded right. Just pitched noises, except with some values it sounded like the Yamaha ROM tones, which is to be expected. I'm beginning to think that maybe the problem is with the contents of the headers I'm writing there.

By yzi

Champion (441)

yzi's picture

11-04-2014, 17:53

The header of my first sample goes to address 0x200000h, and the first seven bytes are (in hex): 20 06 00 0E 0C F1 F4.
And like I said, OpenMSX plays this nicely, but the real machine does not.

By yzi

Champion (441)

yzi's picture

11-04-2014, 18:51

Wow, you may not believe this but I just discovered this thing called OpenMSX Debugger... How come I didn't know I could have got it from apt-get all this time. Tongue I started to disassemble existing MoonSound prods to see what they actually do. It seems that the Coral1 music disk (which is the reason I started this whole project) is writing 0x11 to OPL4 register 2 every once in awhile. Many, many times. I wonder why. Does it do it for every sample upload perhaps?

By msd

Paragon (1372)

msd's picture

11-04-2014, 19:45

;------------------------------------
;--- Set OPL4 for SRAM read/write ---
;------------------------------------
; In: EHL = SRAM address
; Out: C = wave data port

set_opl4_wrt:
	ld	c,2	; enable SRAM access
	ld	a,10001b
	call	opl4_out_wave
	inc	c
	ld	a,e
	and	111111b
	call	opl4_out_wave
	inc	c
	ld	a,h
	call	opl4_out_wave
	inc	c
	ld	a,l
	call	opl4_out_wave
	ld	a,6
	out	(WVIO),a
	ld	c,WVIO + 1
	ret
;----------------
;--- OPL4 out ---
;----------------

opl4_out_wave:
	ex	af,af
	ld	a,c
	opl4_wait	; wait if Turbo-R
	out	(WVIO),a
	ex	af,af
	opl4_7mhz	; wait if 7Mhz
	opl4_wait	; wait if Turbo-R
	out	(WVIO+1),a
	ret
;--- put samples in SRAM ---
; In: HL = RAM address DE = length


ramtosram:
	push	hl
	push	de
	push	bc
	dec	de
	ld	b,e
	inc	b
	inc	d
	ld	c,WVIO + 1
.l:
	otir		; unsigned
	dec	d	
	jp	nz,.l
	pop	bc
	pop	de
	pop	hl
	ret
	macro opl4_wait	
	IF	R800ASM
	push	bc
	pop	bc
	ENDIF
	endm
	macro opl4_7mhz	
	IF	Z80HASM
	nop
	ENDIF
	endm

Code from the moonblaster wave driver. I hope this helps

By yzi

Champion (441)

yzi's picture

11-04-2014, 20:06

Thanks, that out_wave routine looks great. But the PCM upload is pretty much what I currently have. I'll try more combinations. For wait, I had something like 30 NOPs just to make absolutely sure it's enough, but your ramtosram routine seems to blast away with OTIR. oO

Anyway, I made another test. I replaced all of my 7 header bytes with 40 18 3f 00 00 ee 6a, which is header number 1 in the ROM, and it actually does play that ROM sample without noises. So the problem has something to do with what there is in the SRAM, or in the way I'm pointing it to the stuff.

By msd

Paragon (1372)

msd's picture

11-04-2014, 21:23

What kind of sample data do you try to upload and did you setup the 8,12 or 16 bit sample type correctly?

By yzi

Champion (441)

yzi's picture

11-04-2014, 22:14

The stuff originates from a 4chn MOD, regular 8bit samples. This particular test tune is an old Amiga MOD first converted to XM and then converted to my own format and the samples written out to individual raw files (because then the songs in our planned music disk can share common samples). And it plays correctly in OpenMSX... The bytes 20 06 00 0E 0C F1 F4 are the first 7 bytes of my first sample header, at 0x200000. So I'm loading the sample starting from 0x200600, leaving room for all 128 headers before it. I see that for example the Coral music disk seems to load the sample data to 0x200300, so there's only room for 64 headers.

Thanks for your help already. Smile

Anyway, I'm beginning to think that maybe I'm loading the data too slowly. Is it possible that the OPL4 "forgets" its address position if it takes too long for the data to arrive at port 0x7F? I'm loading the samples 128 bytes at a time with the old CP/M legacy (?) sequential read 14h DOS call. Wink Though I _did_ also try re-setting the OPL4 address registers 3, 4 and 5 every time after loading a new block, and it didn't help at all.

The latest thing I tried was to just upload the same first 128 bytes over and over again, without loading the rest of the file at all, and it did in fact have an effect on the playback.

Tomorrow I'm going to try loading the samples with the faster "random block read", RDBLK, 27h DOS call. But now I need to sleep.

By msd

Paragon (1372)

msd's picture

11-04-2014, 23:13

No it will not forget as long as you don't select other registers.

Page 1/3
| 2 | 3