How to detect sound chips without Bios

Page 2/4
1 | | 3 | 4

By norakomi

Paladin (992)

norakomi's picture

21-10-2019, 18:40

@Grauw: I have been trying to understand the MSXAudio detection.
Is this all I need:
; f <- c: found
MSXAudio_Detect: PROC
in a,(MSXAudio_STATUS_PORT)
and 11111001B
ret nz
ld de,10000000B << 8 | MSXAudio_ADPCM_CONTROL
call WriteRegister
in a,(MSXAudio_STATUS_PORT)
and 11111001B
push af
ld de,00000000B << 8 | MSXAudio_ADPCM_CONTROL
call WriteRegister
pop af
xor 00000001B
ret nz
scf
ret
WriteRegister:
ld a,e
out (MSXAudio_ADDRESS_PORT),a
ld b,8 ; wait 12 cycles
djnz $
ld a,d
out (MSXAudio_DATA_PORT),a
ld b,8 ; wait 12 cycles
djnz $
ret
ENDP

I just don't understand this line of code:
ld de,10000000B << 8 | MSXAudio_ADPCM_CONTROL
The <<8 what's that ? and the | MSXAudio_ADPCM_CONTROL what does that do ?

By Manel46

Champion (431)

Manel46's picture

21-10-2019, 19:17

If it detects the existence of FMpac, that is, external "msx music", to activate it, you have to set bit 0 of # 7ff6 to 1.
Ok with the call bios # 000c. I also don't use bios in some roms, but at boot it is present, and that's where you have to detect and activate this.
I understand that it is difficult for a non-Spanish speaker to read the link information attached above. Use google translate. There all this is clearly explained.
The variables MFM1 and MFM2 are of use, only for this routine.

By Grauw

Ascended (8455)

Grauw's picture

21-10-2019, 20:51

norakomi wrote:

@Grauw: I have been trying to understand the MSXAudio detection.
Is this all I need:

; f <- c: found
MSXAudio_Detect: PROC
    in a,(MSXAudio_STATUS_PORT)
    and 11111001B
    ret nz
    ld de,10000000B << 8 | MSXAudio_ADPCM_CONTROL
    call WriteRegister
    in a,(MSXAudio_STATUS_PORT)
    and 11111001B
    push af
    ld de,00000000B << 8 | MSXAudio_ADPCM_CONTROL
    call WriteRegister
    pop af
    xor 00000001B
    ret nz
    scf
    ret
WriteRegister:
    ld a,e
    out (MSXAudio_ADDRESS_PORT),a
    ld b,8  ; wait 12 cycles
    djnz $
    ld a,d
    out (MSXAudio_DATA_PORT),a
    ld b,8  ; wait 12 cycles
    djnz $
    ret
    ENDP

Seems about right!

norakomi wrote:

I just don't understand this line of code:

ld de,10000000B << 8 | MSXAudio_ADPCM_CONTROL

The <<8 what's that ? and the | MSXAudio_ADPCM_CONTROL what does that do ?

The << operator is shift left by 8, and | is OR. In effect the same as:

ld d,10000000B
ld e,MSXAudio_ADPCM_CONTROL

But then using ld de,nn (a small size optimisation of 1 byte).

norakomi wrote:

@grauw:
So I call MSXAudio_Detect:, then output carry means MSXAUDIO found. Seems straightforward.
What does the PROC mean in the source
MSXAudio_Detect: PROC ?

PROC is short for procedure, it starts a scope so all the labels inside are local. Some other assemblers prefix local labels with a . to the same effect (e.g. .WriteRegister:).

norakomi wrote:

Many things I don't understand, like

this:
super: Driver MSXAudio_name, MSXAudio_CLOCK, Driver_PrintInfoImpl

These are two (local) labels in a macro definition, and using another macro named Driver within it. The main novel thing in Glass here is that you can get the offset of a label inside a macro so that it can be used as a struct, like MSXAudio.super which will equal 0 in this case because there’s nothing before it. I use it to achieve an “object oriented” programming style in assembly.

But for the purpose of detection you can ignore this structure, it’s not used in that part.

norakomi wrote:

Can I assemble that whole code with tniasm, or do I need something more for that.

No, I am using various functions of the Glass assembler in my projects, for which there is no standard syntax across different assemblers so you can’t copy it verbatim. Most assembler source code except for very plain style tends to need some conversion when switching assemblers unfortunately. There’s a short manual in the README.md at that link, that should give the necessary details to convert it.

norakomi wrote:
Quote:

be aware that you’re supposed to detect internal FM-PACs first matching on the APRLOPLL string (also used by clones), and only after they’re not found do a broader search using the OPLL string. In case of the latter you need to enable the I/O by setting using the memory-mapped I/O flag at address #7FF6, or just use its memory-mapped I/O

This is complete Chinese to me. I didn't expect it to be that difficult to detect 2 sound chips.

While making VGMPlay, sound chip detection has often been quite troublesome :).

Basically the story starts with the features of the Panasoft FM-PAC. It provides memory-mapped I/O (writing to special addresses in memory, like the SCC) to control the OPLL sound chip instead of I/O ports. This allows you to have several of these plugged in and use them separately. However one of the FM-PAC functions is a memory switch to also listen to I/O ports 7CH-7DH, and this is what people usually use. You need to enable that switch first though, by writing to address 7FF6H of the FM-PAC slot, otherwise the I/O doesn’t work and you won’t get any sound.

Later various manufacturers released computers with MSX-MUSIC built in. These don’t have memory-mapped I/O, instead they are always active listening to I/O ports 7CH-7DH without needing to enable a switch. To prevent conflict with the FM-PAC, they introduced the initialisation method (described in the MSX Datapack) that to you need to detect and use the internal MSX-MUSIC first, and leave the FM-PAC disabled. The MSX-MUSIC can be detected by the ID string “APRLOPLL” in its slot. The FM-PAC has the ID string “PAC2OPLL”, but it’s better to just look for “OPLL”.

In the 90s various MSX groups started making MSX-MUSIC cartridges, often called FM-PAC “clones”. These don’t mimic the FM-PAC’s more advanced functions. Instead they work the same way as MSX-computers with MSX-MUSIC, because it’s a simpler and cheaper design.

By norakomi

Paladin (992)

norakomi's picture

22-10-2019, 12:15

Another issue I found now, is that when
* i run moonblaster-1.4.dsk (bluemsx)
* i disable all soundchips
* i do insert -special -> FM Pac cartridge
I have no sound at all playing songs. Only PSG

unfortunately I cannot test on real hardware, but it seems that moonblaster only plays fmpac if it's internal,
not if you use an external FM Pac cartridge...

Seems weird, could this be a bug in moonblaster ?

By Grauw

Ascended (8455)

Grauw's picture

22-10-2019, 13:25

Don' think so. (But you gotta insert the FM-PAC before MoonBlaster boots of course.) You could also try openMSX, it's more accurate...

Also if the machine you selected has an internal MSX-MUSIC, and you mute it and then insert the FM-PAC, because detection finds the internal MSX-MUSIC first and the FM-PAC stays disabled (as mentioned in the initialisation process before), it will only produce sound on the first (muted) OPLL. So you’ll want to make sure you use a machine without internal MSX-MUSIC for testing the FM-PAC.

By mars2000you

Enlighted (5513)

mars2000you's picture

22-10-2019, 13:24

If you disable all soundchips in blueMSX it's logic that you have only PSG sound.

To make correctly your test, you need to use the "MSX2 - Only PSG" machine, add the FM-PAC with the insert special menu (and don't disable the soundchips!)

Addendum: it's not a problem of accuracy, it's just that you need to use the emulator correctly. By default, all soundchips are emulated in blueMSX (and i know what I'm talking about).

By sd_snatcher

Prophet (3068)

sd_snatcher's picture

23-10-2019, 00:34

Grauw wrote:
NYYRIKKI wrote:

MSX-Audio detection is easy and should work out of the box.

The simplest good way of detecting MSX-AUDIO is to write to bit 7 of ADPCM CONTROL register #7, and check if this is reflected in bit 0 of the status register. See example code.

Please don't get me wrong, but detecting the ADPCM is not official and not a good practice too. This will leave out other perfectly compatible variations of the OPL family: OPL2, OPL3 and OPL4. The ADPCM detection should be used as a complementary step, to evaluate the chip features.

The correct Yamaha way to detect an OPLn chip is to detect its timers. The algorithm is described here.

I can't avoid to remind that none of this are the correct way according to the MSX standard. The official MSX way is described on the MSX datapack and involves calling the EXTBIO hook.

But I described the Yamaha method because, well, some people just don't care about the MSX Datapack. At least the Yamaha method is more compatible than just the direct detection of the ADPCM.

By DarkSchneider

Paladin (869)

DarkSchneider's picture

23-10-2019, 10:25

If it is using ENASLT maybe it is not restoring the correct slot into the page. Also, without BIOS on its slot it is not going to work. You could:
- 1st make detections with BIOS at page 0 and then change it.
- Change the BIOS call by inter-slot BIOS call.
- Be sure it restores the correct slot.
- If using the devices BIOS, read well the documentation, i.e. the INIOPL function modifies the slot for page 1, but it does not restores it, so you have to restore it manually.

Note: EXTBIO is so nice.

By Grauw

Ascended (8455)

Grauw's picture

23-10-2019, 12:25

sd_snatcher wrote:
Grauw wrote:
NYYRIKKI wrote:

MSX-Audio detection is easy and should work out of the box.

The simplest good way of detecting MSX-AUDIO is to write to bit 7 of ADPCM CONTROL register #7, and check if this is reflected in bit 0 of the status register. See example code.

Please don't get me wrong, but detecting the ADPCM is not official and not a good practice too. This will leave out other perfectly compatible variations of the OPL family: OPL2, OPL3 and OPL4. The ADPCM detection should be used as a complementary step, to evaluate the chip features.

I was specifically referring to detecting MSX-AUDIO (Y8950), and not OPL family in general which can indeed be done using the timer. This is the best and simplest way I have found to detect it.

As you know, when you attempt to write to sample RAM with an OPL the computer will hang, they are not perfectly compatible and supporting those chips where MSX-AUDIO is expected requires changes to the ADPCM part of the music driver. Detecting MSX-AUDIO by its unique feature (ADPCM unit) is therefore appropriate for a music driver made for MSX-AUDIO like MoonBlaster.

Even if you would want to modify the music driver to support OPL by omitting the ADPCM loading and playback if necessary, you would still need to determine whether it is an MSX-AUDIO or not. Since most MoonBlaster 1.4 music made for MSX-AUDIO relies heavily on ADPCM though, you will probably get a broken version of the music.

sd_snatcher wrote:

I can't avoid to remind that none of this are the correct way according to the MSX standard. The official MSX way is described on the MSX datapack and involves calling the EXTBIO hook.

That does not work with the Philips or Toshiba Music Module because they do not have the MSX-AUDIO BIOS, so it is merely a distraction to the goal of this thread.

DarkSchneider wrote:

If it is using ENASLT maybe it is not restoring the correct slot into the page. Also, without BIOS on its slot it is not going to work.

My recommendation is always to use RDSLT and WRSLT, and save ENASLT for when it is absolutely necessary. The former two are much easier to use since you don’t have to worry about the current slot selection state.

By DarkSchneider

Paladin (869)

DarkSchneider's picture

23-10-2019, 13:18

Grauw wrote:
DarkSchneider wrote:

If it is using ENASLT maybe it is not restoring the correct slot into the page. Also, without BIOS on its slot it is not going to work.

My recommendation is always to use RDSLT and WRSLT, and save ENASLT for when it is absolutely necessary. The former two are much easier to use since you don’t have to worry about the current slot selection state.

Yes that is what we use to look for MSX-Music. After using INIOPL a call to ENASLT to restore page 1.

Grauw wrote:
sd_snatcher wrote:

I can't avoid to remind that none of this are the correct way according to the MSX standard. The official MSX way is described on the MSX datapack and involves calling the EXTBIO hook.

That does not work with the Philips or Toshiba Music Module because they do not have the MSX-AUDIO BIOS, so it is merely a distraction to the goal of this thread.

WHAT!? Then those ones are not MSX-Audio compliant? Really bad, as we do not contemplate the possibility to do it in another way, as we work for MSX standard, like MSX-Music, MSX-Audio, or MSX-anything, not for "OPLx adapted to the MSX slot" and things like that. Bad news then Sad

Page 2/4
1 | | 3 | 4