Music Module test

Page 1/2
| 2

By Louthrax

Paragon (1694)

Louthrax's picture

11-08-2017, 19:56

Could anybody that has a Music Module expanded with FRS & MSXPro expander (BIOS v1.2 or v1.3) try the following:

  • Boot to BASIC with no other cartridges inserted.
  • Type the following:
    CALL AUDIO
    PLAY #2,"AA"
    

Please report if you hear something or not.

It looks like there's a strange initialization problem with Music Module, but on the Philips machines only (no sound is produced on the Philips, when everything works perfectly on the Sony's or National MSX with the same Music Module).

That's not related to the MSX-AUDIO BIOS, the same thing can be observed when playing a Music Module VGM-ripped file: no sound at all, but only on the Philips machines.

Looks like a hardware initialization difference at reset or power-on time... The strangest thing is that Gorby's Pipeline works well in Music Module mode (other Music Module demos too) on my VG-8235, that's really crazy...

Login or register to post comments

By Louthrax

Paragon (1694)

Louthrax's picture

11-08-2017, 20:18

A simpler test that can be perfomed with any Music Module: just open this file this file using Grauw's VGMPlay and tell me if you hear something (wait until the end of the play, the musics takes some time to start).

Again, this should produce sound on all machines except the Philips.

EDIT: The same problem can be observed with the Toshiba HX-MU900.

By Meits

Scribe (4526)

Meits's picture

11-08-2017, 21:08

Just tested it with my freshly arrived dal-so-ri 2.
call audio
play #3,"aa"
gives desired result.

By Louthrax

Paragon (1694)

Louthrax's picture

11-08-2017, 22:51

Meits wrote:

Just tested it with my freshly arrived dal-so-ri 2.
call audio
play #3,"aa"
gives desired result.

Thanks Meits, could give the beginning of an explanation here... Some additionnal questions:
- What were the results with PLAY #2 ?
- Which machine did you use for the test?

By Louthrax

Paragon (1694)

Louthrax's picture

12-08-2017, 00:59

OK, I think I've got it.

On non-Philips MSX, when you do a "PRINT INP(&hC0)" with Music Module connected, you get 0. On other MSX machines, you get 6.

That test (INP(&hC0)=6) seems to be used by some softwares to detect if a Music Module is present or not (at least VGMPLAY.COM, maybe others). It just does not seem to work on Philips machines. Why but why??

VGMPLAY.COM can be fixed easily by replacing this:

; f <- c: found
MSXAudio_Detect:
	in a,(MSXAudio_STATUS_PORT)
	sub 06H
	and a
	ret nz
	scf
	ret

by that:

; f <- c: found
MSXAudio_Detect:
	in a,(MSXAudio_STATUS_PORT)
	cp 0FFH
	ret z
	scf
	ret

in MSXAudio.asm. But maybe that could lead to some false-positive detections?

By Grauw

Enlighted (6261)

Grauw's picture

12-08-2017, 01:44

Louthrax wrote:

On non-Philips MSX, when you do a "PRINT INP(&hC0)" with Music Module connected, you get 0. On other MSX machines, you get 6.

I guess you mean to say that Philips returns 0 here… Hm, I was pretty sure that was the proper detection method, and that I read that in some application manual somewhere. If any of the flags are set though, it could be that it’s not 6, but normally those bits should be 1. I can’t test on my Philips unfortunately because it’s not booting up atm.

Checking for 0FFH is not the correct method either; for unconnected I/O ports the data bus is in principle uninitialised. Although pull-up resistors on the data-bus will make it 0FFH, I’m not sure this is mandated by the standard and thus always set to this value on all machines.

The pull-up resistor on data bus thing is also the only reason I can think of why the status value would differ between machine types. But I can’t imagine that the Y8950 leaves two data bus bits in high-impedance state when the status register is read? Maybe the MSX-AUDIO BIOS mod does something to it?

I suppose the best detection method would be to access the ADPCM features and check the corresponding status register bits.

By sd_snatcher

Prophet (2578)

sd_snatcher's picture

12-08-2017, 01:49

The MSX-Audio BIOS does a more advanced detection than just checking if the port C0h=0. It uses the Yamaha standard algorithm:

1) initialize the chip
2) Check the flags
3) Start timer-1
4) Stop timer-1
5) Check the flags and chip signature

So maybe something else is trying to initialize the OPL before and causing the detection to fail?

By Grauw

Enlighted (6261)

Grauw's picture

12-08-2017, 02:01

I just checked the MoonBlaster 1.4 sources, it checks by in (0C0H) != 0FFH.

Something like the MSX-Audio BIOS does would be better. Though the timers alone would not be enough to detect the different OPL variations.

On PC, they also check for 06H to detect the OPL2.

By sd_snatcher

Prophet (2578)

sd_snatcher's picture

12-08-2017, 01:53

Quote:

Although pull-up resistors on the data-bus will make it 0FFH, I’m not sure this is mandated by the standard and thus always set to this value on all machines.

I heard that the were made mandatory only for the MSX2 and higher. But I couldn't check this myself because it's probably in Japanese.

But the fact is that the majority of MSX1 models don't have pull-up resistors on their databus.

By Grauw

Enlighted (6261)

Grauw's picture

12-08-2017, 01:57

Good to know sd_snatcher, that I’m not making an assumption (that it can be anything) for no good reason Big smile. Definitely != 0FFH is not a good detection method then.

By sd_snatcher

Prophet (2578)

sd_snatcher's picture

12-08-2017, 02:01

Direct I/O on MSX is never a good detection. ;D

(Don't be mad at me, I just couldn't miss the oportunity for the joke Running Naked in a Field of Flowers )

Page 1/2
| 2
My MSX profile