ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<cr1901_modern>
Well I wasted today. Could've spent it doing something productive like streaming vectorizing (although I don't think my laptop would like that)
<cr1901_modern>
or hell, just doing vectorizing on its own
_whitelogger has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
superctr_ has joined ##yamahasynths
<cr1901_modern>
Anyone know what the bit depth of YM2203 samples are?
<cr1901_modern>
And, assuming I could extract RF5C68 samples from a Sega CD game, would it be possible to make them sound not-sucky using the YM2203 sampling h/w?
<cr1901_modern>
Sorry, YM2608*
glowcoil has quit [Ping timeout: 268 seconds]
superctr has quit [Ping timeout: 246 seconds]
glowcoil has joined ##yamahasynths
<Xyz_39808>
manual says 4-bit. pg43 of the pdf
<cr1901_modern>
ewww ._.
<Xyz_39808>
that's probably just the values of the deltas tho.... But that is the technical answer to that question
<cr1901_modern>
oh right... ADPCM
<Xyz_39808>
next page goes into detail more. I don't know enough about adpcm vs dpcm to be confident in saying how deep the channel itself goes internally
<Xyz_39808>
I could ask in a PMD server, what's the specs of that ricoh chip?
<cr1901_modern>
8 bit samples
<cr1901_modern>
8kb max per sample? I don't remember
<cr1901_modern>
okay I see it now. The Windows/Linux blob is a wrapper over the z80 code that runs on the pc88
<cr1901_modern>
basically emulating the absolute minimum required to generate sound
<cr1901_modern>
there is also a plugin architecture... wonder if I can use that for anything
<Xyz_39808>
cr1901_modern, from pigu/pigdevil2010: "the internal adpcm logic is 16-bit
<Xyz_39808>
. but the DAC output is likely 8-bit
<Xyz_39808>
. max sample size depends of ram type. I don't exactly know, there's a setting to choose DRAM addressing in 1-bit mode or 8-bit mode. one results in 4-byte resolution and the other results in 32-byte resolution"
<cr1901_modern>
hmm thanks
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<ValleyBell>
RF5C68 is raw 8-bit PCM, the chip outputs 32 KHz
<ValleyBell>
RF5C68 has a 5.11 bit fixed point "sample step" value to control the sample rate.
<ValleyBell>
(but most games will use rates <= 32 KHz for playing back samples)
<ValleyBell>
YM2608 ADPCM-B uses 4-bit ADPCM with sample rates of up to 55 KHz
<cr1901_modern>
ValleyBell: Noted
<cr1901_modern>
starting to get the hang of openmucom88's structure... mucom88 gives you a set of 70+ default FM instruments to play with. Relative to the source root, they are stored (as a raw binary) in voice.dat
<cr1901_modern>
if you open up voice.dat in a hex editor, you can find the name of each instrument
<cr1901_modern>
Someone ran voice.dat through a "c2bin" tool and then included the data as headers
<cr1901_modern>
I'm likely to do a writeup on this at some point
<cr1901_modern>
superctr_: Found the FM instruments editor... it's the binary called FmToneEditor.exe
<cr1901_modern>
how convenient!
<cr1901_modern>
(The reason I missed it is because I was mainly viewing mucom88's files in Atom, and my default .gitignore ignores .exe files
<cr1901_modern>
The FMToneEditor does _not_ appear to be FOSS
<cr1901_modern>
You have 8kB of space for FM voices... it not only exists in the z80 memory, but it is also mirrored in a "mucom88" bookkeeping structure. If you override the default FM instrument voice blob with your own (using the "-v" switch), the voice table is mirrored a _second_ time in malloc'd memory, and I haven't figured out why. Blaargh.
<cr1901_modern>
(The "mucom88" bookkeeping structure is stack-allocated)
* cr1901_modern
at this point is "Rubber Duck programming" to figure out how stuff works
<cr1901_modern>
that's why I keep sending msgs even tho no one's awake
<cr1901_modern>
Second mirror of the data is because it's possible to update FM voices in real time, and the code keeps a second immutable mirror around in case it needs it.
<cr1901_modern>
The immutable mirror ("fmvoice_original") isn't actually ever used anywhere AFAICT.
<cr1901_modern>
Ahhh well...
* Sarayan
waves
<cr1901_modern>
it's a shame Sarayan, but my energy has run out LOL. So I'll have to say bye for now :(
<Sarayan>
heh, good night
<whitequark>
Sarayan: alright, can you give me the tiles again
<whitequark>
i'll try it later today
<Sarayan>
og.kervella.org/ym2203/tiles.7z
<Sarayan>
og.kervella.org/ym2203/ym2203 is the leaflet
_whitelogger has joined ##yamahasynths
<cr1901_modern>
Well sleeping was a disaster... guess I'll keep looking at the mucom code and making stupid small tunes
<Sarayan>
anyone has the mu50 service manual?
<cr1901_modern>
Not about to dig this deep, but mucom88 exposes enough of its internal state such that if someone was inclined, they could hook it into their favorite text editor and get real time editing of music and FM params
sixtysix has joined ##yamahasynths
sixtysix has quit [Remote host closed the connection]
sixtysix has joined ##yamahasynths
<ValleyBell>
A small note about Mucom88: There is an MML command that lets you do arbitrary register writes, IIRC, so you can temporarily modify the instrument of the FM channel the command is executed on.
<ValleyBell>
I can't tell what command it is though - I just found it when I reverse-engineered the binary format a few years ago.
<superctr_>
you don't get complete control of register writes in MML
<superctr_>
you get y** commands that let you set instrument parameters
<superctr_>
yDM, yTL, yKA etc
<superctr_>
hm, you still get most of the stuff i guess.
<superctr_>
H to set the LFO
<superctr_>
or i'm just wrong
<superctr_>
yレジスタ直接書き込み(yn1,n2) n1=レジスタ番号 n2=データ
sixtysix has quit [Ping timeout: 255 seconds]
<ValleyBell>
IIRC the way it worked was: if (register < 30h) [write data value to register as is]
<ValleyBell>
if (register >= 30h) [write data value to (register + channel ID)
<superctr_>
yeah, it seems the 'y' register does direct register writes and yDM, yTL etc is specifically for operator registers
<superctr_>
you could in theory translate VGMs to Mucom88 using only these commands. But you'd hit the module size limit soon enough
<superctr_>
even a normal 'short' MML song easily hits 30-50% of the available size
l_oliveira has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
superctr_: The plugin API exposes a command to do a direct register write. Though seeing as the plugin will only be called at intervals outside your control, I think that doesn't count as full control (oops :P)
<cr1901_modern>
Also... anyone have an idea as to why some samples sound correct, but others sound like they're playing at the wrong pitch (I would expect the latter consistently for a ZSNES this old)? https://www.youtube.com/watch?v=Ay1UhN6P6y8
<cr1901_modern>
ValleyBell: Now that I think about it more... what prevents spc700 support in VGM when sampled chips like RF5C* are already supported?
<superctr_>
nothing really, but we decided not on it when there already exist formats for the SNES
<superctr_>
optimization might be difficult as the DSP sample and echo memory is shared with the SPC-700 program and working memory
<cr1901_modern>
superctr_: I mean, there's already formats for other chips too... x68k has MDX (which is what I wish VGM looked more like)
<superctr_>
MDX is the native playback format of a X68000 sound driver
<superctr_>
It's a sequence format, not a logging format
<cr1901_modern>
And what makes *spc files different from MDX? AIUI You have to emulate basically the whole CPU (65xx variant) to play SPC files.
<superctr_>
SPC consists of a savestate of the SNES audio subsystem, more or less
<superctr_>
"logging" a SPC is basically just taking a savestate of the audio subsystem at that time
<superctr_>
For MDX you have to convert the game's sequences to the MDX format if they don't use the MXDRV driver, in which case you can just copy files from the game directly
<cr1901_modern>
>(which is what I wish VGM looked more like) Oh, this was throwaway commentary :P
<superctr_>
And to playback MDX files on anything that's not a X68000 you have to take a this unholy mess that is a straight conversion of disassembled 68k code converted to C
<superctr_>
Maybe you're *actually* thinking of S98 instead, which is an alternative logging format :P
<superctr_>
I think libvgm already supports it
<cr1901_modern>
Maybe
<cr1901_modern>
>"logging" a SPC is basically just taking a savestate of the audio subsystem at that time <-- So logging SPC activity is no different than creating a traditional SPC file?
<superctr_>
if you were to 'log' SPC you'd be essentially replacing the CPU
<superctr_>
you log all writes from the CPU to the DSP registers, but since the DSP shares memory with the CPU you also need to log all writes from CPU to RAM
<superctr_>
Since this contains sound driver variables, zero page and all that stuff, it's going to be huge
<superctr_>
you will need to optimize by removing everything that's not a sample and then probably create datablocks out of consequential writes
<superctr_>
also, note, with CPU i mean the SPC700, not the SNES main CPU in this case
<cr1901_modern>
right, I said it was a 65xx variant which is kinda-sorta true
<cr1901_modern>
I was comparing SPC to MDX because in both cases, the structure of the original music data/patches is still intact. This is what I wanted out of VGM. But in MDX's case, the format is (badly) documented and in principle you don't need to emulate a 68k to create a player since the format is specified
<cr1901_modern>
w/ SNES, there's no universal data format, so we emulate the CPU :/
<superctr_>
in that case, M1 is probably what you want
<superctr_>
It emulates the audio subsystems from a ton of arcade games
<l_oliveira>
the CPU SONY uses on the module (SPC700) is also used on CD Players and other devices as display contoller, user keys scanner, etc
<superctr_>
Unfortunately it hasn't been updated in a long time
<superctr_>
the S-SMP is basically a simple SOC containing a few peripherals as well as the main CPU core iirc
<superctr_>
the S-DSP is the sound chip itself
<l_oliveira>
two timers, a I/O port (similar to 2x 74LS670 chips) and a small boot rom
<cr1901_modern>
it runs a bootstrap program on boot
<cr1901_modern>
I think there's 4 I/O ports
<l_oliveira>
4x74LS670s
<l_oliveira>
because it is bidirectional
<cr1901_modern>
but they're identical so it doesn't matter which one you use after bootstrap
<cr1901_modern>
(since bootstrap ROM hardcodes which port does what)
<l_oliveira>
each 74LS670 is 4 addresses register file but each is a nibble
<l_oliveira>
and unidirectional
<l_oliveira>
so you need two to send and two to receive
<cr1901_modern>
right, but there are 4 distinct 8-bit I/O ports between main CPU and spc700
<cr1901_modern>
so you'd need 16 :P
<superctr_>
i think there are 4 input and 4 output ports
<superctr_>
in the end those are the only way for the SNES main CPU to access the sound subsystem, it can't DMA data to it
<superctr_>
hence the need for a bootstrap ROM
<cr1901_modern>
It reminds me of Sega CD 68k-to-Genesis 68k communication protocol, except EVERYTHING is done in software (l_oliveira explained how the Sega CD protocol works to me once)
<l_oliveira>
each 670 is four addresses
<l_oliveira>
but a nibble
<cr1901_modern>
l_oliveira: Oh, whoops
<l_oliveira>
with two you have four bytes
<l_oliveira>
but they're unidirectional
<l_oliveira>
you can read the read side without worries about what is happening at the write side
<l_oliveira>
so all communication between the SNES and the sound module has to be PIO because it's fully asynchronous
<cr1901_modern>
PIO?
<superctr_>
parallel io
<l_oliveira>
Programmed I/O? (as in software driven using the host CPU)
<cr1901_modern>
not sure how this follows from "you can read the read side without worries about what is happening at the write side"
<superctr_>
and it's asynchronous so the main CPU has to clock the data written to the sound CPU
<cr1901_modern>
(see: synchronous dual port RAM)
<l_oliveira>
means you write what you want without affecting the other side, the other side CPU can poll it whenever it wants
<cr1901_modern>
And I lost my scrollback
<cr1901_modern>
oh...
<l_oliveira>
so both CPUs can operate on their best performance without being interrupted
<superctr_>
arcade games that used latches for communication between the main cpu and sound cpu typically used an IRQ to "ping" the sound CPU
<superctr_>
I guess on the SNES you have to use a flag instead which the sound CPU constantly polls
<l_oliveira>
or they can just poll the register, like CPS1 does
<l_oliveira>
most games use a protocol like: write sound code, read acknowledgement from the other side then write a "no command" value which does nothing
<l_oliveira>
next time a sound code is sent it repeats
<l_oliveira>
Super Mario World for example has only two SPC images each has half of the musics in the game
<cr1901_modern>
superctr_: System 1 is a very "bare bones" example of IRQ and flag
<cr1901_modern>
the "communications area" is one 8 byte reg LMAO
<cr1901_modern>
f8 bit*
<l_oliveira>
Youi know, Capcom ZN also use that hahaha
<l_oliveira>
they have a 8Mhz Z80 with the DPS16 chip on the romboard, it talks to the MIPS CPU through a single byte I/O port. Accesses on that port at the N
<l_oliveira>
MIPS side causes NMIs
<l_oliveira>
each command is four bytes
<superctr_>
i know
<l_oliveira>
I was saying that to cr1901, though :3
<superctr_>
that's why in MAME you can play sounds directly from the debugger in a lot of arcade games (not just the ones you mentioned) by writing to certain address
<l_oliveira>
I modded the drivers to make them work on the CPS2
<l_oliveira>
Z80 drivers
<superctr_>
It will write to the latch and trigger the IRQ on the sound cpu immediatley
<superctr_>
also most Capcom CPS2 drivers are similar
<superctr_>
It might be possible even to port the sound data from one sound driver to another
<l_oliveira>
so I could listen to Star Gladiator2 music on the CPS2
<superctr_>
without having to mess with the code
<superctr_>
I know for sure that was possible with the Namco sound drivers I reversed
<superctr_>
The one exception might be the Arika ZN driver (used in TGM and Street Fighter EX2), as it's unique
<l_oliveira>
it was a lot easier to change the way it talks to the hardware, I only had to add a new routine at a empty spot on the rom which polls the shared ram and calls the NMI handler when a command arrives
<l_oliveira>
I did that to the arika driver too lo
<l_oliveira>
sending invalid codes make it crash D:
<superctr_>
the commands are completely different from the capcom drivers
<l_oliveira>
yes they are but I made it work
<l_oliveira>
but sending sound codes that do not exist crashes it
<superctr_>
for that sound driver, I reversed the sequence format :P
<l_oliveira>
capcom one just does nothing
<superctr_>
although i never completed it, I was planning to port all songs over to the Quattro sound driver
<l_oliveira>
would be better porting the music to something else indeed
<superctr_>
note that it's not using the qsound chip
<l_oliveira>
C352?
<superctr_>
yeah
<l_oliveira>
I have some C352s on scrap boards I am so itching to make them sing
<superctr_>
the good news with the C352 is that you don't even need to modify the sound driver to make it play most songs
<l_oliveira>
I never tried because it requires a 16bit CPU
<superctr_>
even the ones from games with a different sound CPU
<l_oliveira>
a 68000 is good enough to control it, right?
<superctr_>
yeah, probably
<superctr_>
if you are able to compile the quattroplay source code for that system perhaps you could play the original soundtracks for that chip
<superctr_>
i would not suggest VGMs because many of them were victim to bad emulation at the time they were logged
<superctr_>
Also the pinout for the C352 chip isn't completely known yet
<superctr_>
you'd need to trace them from an arcade PCB
<l_oliveira>
best way of figuring that out would be trying, right?
<superctr_>
in the end I think I would really just suggest taking an arcade PCB, and make a custom ROM board since the original games use SMT flash ROMs
<superctr_>
System 11 arcade PCBs aren't very expensive
<cr1901_modern>
Not sure what caused this beauty to happen, but I love it
<l_oliveira>
haha that sounds a lot like Raf World/Journey to Sillius
<l_oliveira>
even though it is a different game
<l_oliveira>
They used the same driver on a lot of games at Sun Electronics, no?
<ValleyBell>
cr1901_modern: Just for clarification: SPC is a "ripped" format (because it has sound code + sound data), just like NSF, GBS and the PSF formats.
<ValleyBell>
VGM, S98 and DRO are "logged" format, because you just capture all data between the CPU and the sound chip.