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
<kode54>
yeah, I kind of reverse engineered enough of the API of SCVA's core library to make it usable outside the VST plugin
<natarii>
i do have the overdrive 2 music in vgm though ;p
<cr1901_modern>
bbahahaha nice
<natarii>
overdrive 2 is probably one of the most impressive ym2612 tunes i've heard
<natarii>
in the one part, it uses the pcm channel for reverb for the psg. mind blowing
<cr1901_modern>
They did some weird filtering and shit to get the music just right. I asked about it in early 2017 on efnet, asking kabuto directly. They gave me some gists to look at. But I never followed up on it.
<cr1901_modern>
And I'm sure it's waaay too late to follow up now.
* cr1901_modern
reads Overdrive 2 is apparently a genuine real time 3d renderer for the Genesis. And it's 4MB in cartridge space.
<cr1901_modern>
Meaning unrolled loops I guess
<cr1901_modern>
3d could be done on the Genesis in a limited form for commercial games (which have to use the remaining data, for well, the game). There's a GameHut vid on it
<andlabs>
also relevant to this channel I also am pretty sure star cruiser is the first game on the Genesis to mix PCM samples, though it only does it for drums
<andlabs>
maybe
l_oliveira has joined ##yamahasynths
<TD-Linux>
is there a good free software compatible sc-55 soundfont?
<superctr>
MSGS
<superctr>
:P
<superctr>
it's a DLS file AFAIK
Xyz_39809 has quit [Ping timeout: 260 seconds]
<TD-Linux>
I've found it floating on some websites, but does it have a home website
<TD-Linux>
and I've seen some number of people use it with emulators like munt etc. it would be neat to do a version that has a built in FPGA synth
<superctr>
munt is a different beast though
<superctr>
and you don't need an fpga to implement a synth, doing so will just make your design too complicated. stick with an SoC, all you need is UART in (for MIDI) and wave out.
<TD-Linux>
yes, I intentionally asked about sc-55 (also x68000 is new enough that GM/GS games are more common than mt-32)
<superctr>
there are no SC-55 emulators and if you're going to use a soundfont then a simple softsynth (fluidsynth) running on a cheap SoC is the way to go
<cr1901_modern>
> there are no SC-55 emulators
<cr1901_modern>
Wait, what? ._.
<cr1901_modern>
Really?
<superctr>
the problem with the SC-55 is that Roland encrypted the sample ROMs
<cr1901_modern>
ooooh :/
<superctr>
apart from a few bytes ASCII in the beginning, the rest looks like noise
<TD-Linux>
also, it's not nearly as interesting to emulate as it's a wavetable synth
<superctr>
considering that the decryption is almost likely in real time, then it's probably not that secure considering the 90s encryption standard
<TD-Linux>
part of this project could be writing a sc-55 emulator
<superctr>
someone who is interested enough and have a few SC-55s to spare could probably try and figure out something with a logic analyzer / bus sniffer
<TD-Linux>
but I'm not intrested in distributing something that uses the original sample ROMs so...
Xyz_39808 has joined ##yamahasynths
<superctr>
Munt requires the original ROMs too
<TD-Linux>
yes, I figured in its case they would actually be more critical to operation
<superctr>
i think it's an "interesting enough" emulation target considering it's the standard that many 90s PC games used
<superctr>
again, it's hard to emulate it since it's essentially a "black box" and Roland made things harder for us with the encryption
<Sarayan>
the sc55 sample roms are actually dumped?
<superctr>
they're dumped
<Sarayan>
gimme?
<superctr>
they're in MAME
<Sarayan>
oh
<Sarayan>
didn't notice :-)
<superctr>
i see a lot of repeating patterns in the ROM actually. That could point to a stream cipher consisting of LFSR and XOR (aka GSM style encryption)
<Sarayan>
extremely improbable for technical reasons
<Sarayan>
the sampler has to replay samples at variable rates, with sometimes a rate that is such that a sample value is skipped
<Sarayan>
that's very not compatible with a stream cypher
<superctr>
it depends on how the stream is generated
<superctr>
if the LFSR is simply clocked once address is increased or if the address is actually part of the key (like a block cipher in CTR mode)
<superctr>
something tells me the SC55 sample format is based on 4-bits ADPCM, in which case you can't skip samples anyway
<Sarayan>
yeah, you're probably right, feels very 4-bits
<superctr>
i also see now that the patterns tend to be 32 bytes
<superctr>
maybe the samples are interleaved across the roms
<superctr>
with a logic analyzer you could figure out in which order it reads from rom, i suppose
<Sarayan>
it may be similar to cm-32p
<superctr>
yeah
<superctr>
i'm looking at the asic pinout in the service manual
<superctr>
and i wonder if the bitswap is just done by scrambling the address lines from the rom there, because the order of the address and data pins of the sample rom don't make much sense
<superctr>
of course they do this too to optimize silicon space, but if you look at the other buses, they aren't as scrambled
<Lord_Nightmare>
is it for sure a 4-bit format, or is it a 4-bit-in-a-block format like brr/cd-xa/xboxadpcm/adpcm36/etc ?
<Lord_Nightmare>
xboxadpcm is weird, i didn't know about that one until today. its basically ima adpcm retrofitted to be a block format
<superctr>
lol, we don't know
<superctr>
impossible to tell without having a complete sample
<superctr>
but it's pretty easy to see that the format appears to be 4-bit
<Lord_Nightmare>
well if its a block format it would be obvious in binxelview since if you stretch it the block length pixels wide, you will get a very obvious stripe down the left side
<Lord_Nightmare>
since the block header has less variance than the sample data
<cr1901_modern>
I just realized... the ROMs themselves are not a separate chip, are they?
<Sarayan>
cr: what?
<cr1901_modern>
If the ROMs are encrypted, and they are _also_ separate chips, why can't one probe the data/addr lines witha logic analyzer to correlate the encrypted data to the decrypted data?
<superctr>
well, all the sample processing is done by a single chip
<superctr>
it reads the sample roms directly
<Sarayan>
oh, you can do a lot of stuff with a logic analyzer, a trillion probes and working hardware
<superctr>
now it appears roland did some address scrambling similar to the cm32p, i am trying to reverse that with the chip pinout
<superctr>
but that would be reliably done with a logic analyzer, probably
<Lord_Nightmare>
64 word blocks
<Lord_Nightmare>
word is 4 bits
<superctr>
i doubt it
<superctr>
there's no recognizable header in the beginning of each block
<Lord_Nightmare>
i mean the low address bits are in the order 5 4 3 2 1 0 -1(nybble sel)
<Lord_Nightmare>
the upper ones are scrambled
<Lord_Nightmare>
or at leats grouped like that
<superctr>
ah yes, sure
<superctr>
that's what it looks like
<Lord_Nightmare>
its possible the bits 543210-1 are scrambled too, but they seem to be a cohesive group
<Lord_Nightmare>
there could also be data bit scrabling based on the address, which would be annoying if so
<Lord_Nightmare>
or possibly just data bit scrambling altogether, so the bits are mixed up between two nybbles at a given address
futarisIRCcloud has joined ##yamahasynths
<cr1901_modern>
andlabs: Good point re: Star Cruiser. That's one of my fav FM soundtracks period too