Extension Konami SCC flips

By ro

Scribe (4669)

05-03-2022, 16:18

Hai, I'm working on something SCC music related on OpenMSX17.0. I'm using the extensions to add "Konami SCC" to slot B. I have a Sunrise IDE in slot A. I' working in WBASM2 (yes, I do)

Here's the thing.
I've made an SCC detection routine, which checks all prim/ext slots for ROM at #8FFF and RAM at #9800 (SCC wave data). It works flawlessly. no worries there.

HOWEVER

as soon as I open the memory monitor @9800 in the SCC slot. BAM! the SCC is gone. Detection yields zero. I have to remove the extension in openMSX and add it again.

It also looks like I can't "read" the wave tables since they always return the value 255.

like...help?

By Manuel

Ascended (18705)

05-03-2022, 16:32

What if you insert an SCC game cartridge instead?

By ro

Scribe (4669)

05-03-2022, 16:55

I tested with the PazosMegaFlashRomScc, same deal
How do I insert a game cart without reboot? (and start the game)

It looks like the emu can't handle the "RAM" portion of the extension, I can monitor or read data anywhere without problems EXCEPT the SCC wave table part (which should be ordinary RAM, according to well known info). When I access #9800 it stops working..

By Manuel

Ascended (18705)

05-03-2022, 17:15

Just insert it without rebooting... Unlike a real MSX, it won't break the hardware.

By ro

Scribe (4669)

05-03-2022, 18:07

I did, but it reboots automatically (when inserting in cartridge slot). is there a setting? Or ia this only with CART cli cmd?

By Manuel

Ascended (18705)

05-03-2022, 18:44

If you use the cart command in the console, it won't reboot.
Or use catapult.

By ro

Scribe (4669)

05-03-2022, 19:35

nope, same deal.

But.
Been testing a bit further and found out that by reading one of the TEST registers, things crash.
- 98E0h - 98FFh test register

When I access (read, write) any of these 16 bytes, openMSX looses the SCC cart (any). I have to re-attach it. In this case I used
> cartb F1SPIRIT.ROM

By Manuel

Ascended (18705)

05-03-2022, 19:50

I'm sure it's not lost. Doesn't reading that just disable the SCC?

Using the cart command will really not reboot the MSX. If it does, you may have accidentally removed something else from a slot?

By ro

Scribe (4669)

05-03-2022, 20:33

No, it does not boot. Thaz okay.
Accesing the test reg, just peek 98E0 will lose the possibility to find the scc. That is what is happening. I am not sure if it is openmsx or scc. Perhaps i would ask in the forum in another topic.
Still it bugs my progress

By Manuel

Ascended (18705)

06-03-2022, 00:19

Please check it (or ask someone to) on real hardware.

So, you are reading from memory with WBASS (so from MSX program) at 98E0, right?

According to the openMSX source code, Manuel Pazos wrote this on 14 Apr 2003:

Quote:

// I have some info about SCC/SCC+ that I hope you find useful. It is about
// "Mode Setting Register", also called "Deformation Register" Here it goes:
//
// bit0: 4 bits frequency (%XXXX00000000). Equivalent to
// (normal frequency >> 8) bits0-7 are ignored
// bit1: 8 bits frequency (%0000XXXXXXXX) bits8-11 are ignored
// bit2:
// bit3:
// bit4:
// bit5: wave data is played from begining when frequency is changed
// bit6: rotate all waves data. You can't write to them. Rotation speed
// =3.58Mhz / (channel i frequency + 1)
// bit7: rotate channel 4 wave data. You can't write to that channel
// data.ONLY works in MegaROM SCC (not in SCC+)
//
// If bit7 and bit6 are set, only channel 1-3 wave data rotates . You can't
// write to ANY wave data. And there is a weird behaviour in this setting. It
// seems SCC sound is corrupted in anyway with MSX databus or so. Try to
// activate them (with proper waves, freqs, and vol.) and execute DIR command
// on DOS. You will hear "noise" This seems to be fixed in SCC+
//
// Reading Mode Setting Register, is equivalent to write #FF to it.

So, as you are reading from 98E0, it means 0xFF is getting written to the deformation register. Does the effect of that kill your detection routine?

Anyway, you could check that source code to see what openMSX is going...

By ro

Scribe (4669)

06-03-2022, 09:20

Thanks for you effort, Manual. Appreciated. It's a case of #98Ex registers indeed, just peeking will have effect. The detection routine fails, prolly because it can't "write" to wave data anymore. Haven't checked it on real hardware. I'll have a deeper look and do tests.