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
futarisIRCcloud has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
ej5 has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Stilett0>
ej5: can that also become cloned? because damn
<Wohali>
how much is a GUS worth these days
<Stilett0>
less than that :D
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Wohali>
even in box? :)
<fseidel>
how the fuck did that sell for that much?!?
andlabs has joined ##yamahasynths
nukeykt has joined ##yamahasynths
<cr1901_modern>
What does an adblib gold have compared to a sound blaster?
<Lord_Nightmare>
given that price, about 2.5oz of solid gold
linkmauve has quit [Ping timeout: 255 seconds]
linkmauve has joined ##yamahasynths
linkmauve has quit [Ping timeout: 240 seconds]
linkmauve has joined ##yamahasynths
<Lord_Nightmare>
!seen furrtex
<Lord_Nightmare>
!seen furrtek
<cr1901_modern>
I don't have a bot in here that can do that
<cr1901_modern>
anyways, furrtek said he doesn't want distractions until the FPGA neogeo is done last I checked
<cr1901_modern>
(few months ago)
<cr1901_modern>
I suppose I could prod him to come in here again
<Lord_Nightmare>
i need him for something yamaha related but not fm related
<Lord_Nightmare>
maybe i can just poke him on twitter
<Lord_Nightmare>
basically, I need him to edit https://wiki.neogeodev.org/index.php?title=ADPCM_codecs to fix a stupid bug in the YM2610_ADPCM_A_Decode function, which madbr pointed out and darrylrev tested on hardware (proving madbr correct) and I fixed upstream in MAME
<Lord_Nightmare>
since the code in YM2610_ADPCM_A_Decode was derived from MAME a long while ago and has the bug in it
<Lord_Nightmare>
if ((acc & ~0x7ff) != 0) // acc is > 2047
<Lord_Nightmare>
else acc &= 0xfff;
<Lord_Nightmare>
acc |= ~0xfff;
<Lord_Nightmare>
that code doesn't do at all what it was intended to do
<Lord_Nightmare>
it checks whether the value overflowed 0x7ff to 0x800, and if so, it sets the high bits, otherwise it does the pointless task of masking all but the low bits
<Lord_Nightmare>
the problem is acc is SIGNED
<Lord_Nightmare>
and can range from -0x800 to 0x7ff
<Lord_Nightmare>
what's supposed to happen is when the accumulator overflows 7ff->8xx or underflows -0x800->-0x801 it wraps to the other end
<Lord_Nightmare>
it doesn't saturate
<Lord_Nightmare>
the current code instead makes it do really bizarre stuff
<Sarayan>
If it wraps you should just sign-extend at the end
<Lord_Nightmare>
yes, and that's what i just committed to MAME
<Lord_Nightmare>
and it matches the tests on hardware
<Sarayan>
13:53 <Lord_Nightmare:##yamahasynths> if ((acc & ~0x7ff) != 0) // acc is > 2047
<Sarayan>
that is not a sign-extension test
<Sarayan>
acc & 0x800 is
<Lord_Nightmare>
metal slug has two samples it plays during attract mode which make the accumulator both underflow and overflow on real hardware
<Lord_Nightmare>
i haven't found any other samples on neogeo which do that, yet
<Lord_Nightmare>
but i don't douby they exist
<Lord_Nightmare>
*doubt
<Lord_Nightmare>
the old code in MAME (and on that wiki) if the sample overflows, it turns it negative, which is correct, but if it underflows it doesn't turn it positive, it sort of semi-clamps it within the 0xfff7ff-0xfff000 range, and that range does wrap if it goes below 0xfff000
<Lord_Nightmare>
the new code is:
<Lord_Nightmare>
acc &= 0xfff;
<Lord_Nightmare>
if (acc & 0x800)
<Lord_Nightmare>
acc |= ~0xfff;
<Sarayan>
that's good
<Sarayan>
that patterns happens so often I wonder if we should make a templte out of it (like make_bitmap)
<Lord_Nightmare>
perhaps
<Lord_Nightmare>
what i discovered while picking at that is that the msm5205 behaves pretty much identically to the ym2608/2610 with the exception that the q table index adjust for the low 3 bits of each nybble is different
<Lord_Nightmare>
on msm5205 the adjust is -1 -1 -1 -1 2 4 6 8
<Lord_Nightmare>
on ym2608/2610 the adjust is -1 -1 -1 -1 2 5 7 9
<Sarayan>
that's adpcm right?
<Lord_Nightmare>
otherwise i think they're identical
<Lord_Nightmare>
yes
<Lord_Nightmare>
msm5205 is the same as adpcm_a on the ym2608(the internal ROM samples only) and ym2610 ADPCM_A
<Lord_Nightmare>
with that one change
<Lord_Nightmare>
msm5218, which was a codec chip that encoded oki adpcm for the msm5205 is different: on that chip the 12 bit accumulator saturates at 0x7ff and -0x800
<Lord_Nightmare>
i suspect the msm6295 behaves like the msm5218
<Lord_Nightmare>
MAMEs msm5205 code of course implements the msm5218 saturation, which is also wrong. bah...
<Lord_Nightmare>
if (new_signal > 2047) new_signal = 2047;
<Lord_Nightmare>
else if (new_signal < -2048) new_signal = -2048;
<Lord_Nightmare>
msm5205 also duplicates some code that lives in okiadpcm.cpp, but given msm5205 doesn't saturate and pretty much every other oki chip does, perhaps that's for the best
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
l_oliveira has joined ##yamahasynths
nukeykt has quit [Quit: Page closed]
<cr1901_modern>
whitequark: While it's on my mind- if someone ever sends you a Sega CD as part of your Electronic Detritus Collection Program, could you decap and image the RF5C68 PCM chip? The truth is, it's a relatively easy chip to emulate. But I'm still curious about how things are timed internally
<superctr>
i don't think it needs to be decapped to understand the timings
<superctr>
you have full control of the sample address, so with a logic analyzer you can see when it uses on the bus
<cr1901_modern>
Maybe not, but it's not like I'm gonna get my hands on a Sega CD and make a breakout board for one anytime soon
<superctr>
perhaps it's interesting to see how it multiplexes CPU and sample access to the memory, but at the same time existing emulation already handles that well I think
<superctr>
there are no known issues with that part. there's however that japanese mega cd game that apparently has broken samples on real hardware but sound good in emulation
<superctr>
i forgot exactly what the problem was but it might have been the "stop" sample (the chip 0xff to stop a sample)
<superctr>
more accurately 0xff to go to the loop point
<l_oliveira>
RF5C164 on the case of SEGA-CD
<superctr>
well, the part number is strange
<superctr>
on the mega cd it's most usually a Sega branded part with 315-xxxx part number
<cr1901_modern>
Yea I couldn't remember the actual part number, I just used the one for where I actually have the datasheet
<l_oliveira>
I was looking the circuitry for RF5C68 on the System 18, they don't need a DAC to get sound out of it
<superctr>
same chip has been found on arcade boards, which sometimes has Ricoh parts or Sega 315-xxxx parts
<l_oliveira>
that's system 32
<l_oliveira>
that one use exactly the same chip as the SEGA-CD
<superctr>
there are at least three variants, RF5C68, RF5C105 and RF5C164
<l_oliveira>
they're mostly the same from a software point of view, no?
<superctr>
from software pov they're identical, hardware they support different types of memory i believe
<superctr>
perhaps SRAM vs DRAM?
<l_oliveira>
but there's something on the RF5C164 datasheet about per channel registers being readable
<l_oliveira>
I tried to connect a RF5C164 to a MSX computer to probe it but it malfunctioned. I suspect I might have ESD damaged the chip
<cr1901_modern>
superctr: Broken samples don't appear to be particularly timing sensitive. What I've probably do is: decompile the music driver in ghidra or binja, hook up a PCM chip to FPGA, put a RISCV core on it and then attach to a logic analyzer.
<whitequark>
cr1901_modern: i mean, sure
<whitequark>
i can decap it
<superctr>
the problem is not the sound driver
<superctr>
The problem is that the sample data itself appears incorrect
<cr1901_modern>
Then why does it sound correct in an emulator
<cr1901_modern>
It makes perfect sense, but I didn't know there was Ricoh PCM support in VGM until this morning
<l_oliveira>
wq: waiting anxiously for better pictures of that YM2608 decap :D
<l_oliveira>
die came out neatly
<cr1901_modern>
Mostly fascinated b/c I'm one of the 10,000 people who wonder where the Sonic CD "hue" sample comes from
<superctr>
ricoh support in VGM is a bit funny, both RF5C68 and RF5C164 is specified in the standard
<superctr>
and both have dual chip supported
<superctr>
so you can really have 4 instances of just this chip in a VGM file
<superctr>
(sort of like how you can have 6 instances of AY-3-8910 if you use the OPN chips)
<cr1901_modern>
it's not a complex chip (well compared to Yamaha FM anyway). I feel like it should've been included as part of a stock Genesis
<cr1901_modern>
if ppl _insisted_ on creating sampled music
<superctr>
i don't really think it's required
<superctr>
the Z80 is sufficiently powerful to do sample mixing if you really wanted that
<whitequark>
l_oliveira: my microscope is not with me rn
<whitequark>
new mirror is in the mail
<cr1901_modern>
The MOD player that Jon Burton made does the mixing on 68k side
<l_oliveira>
Toy Story?
<cr1901_modern>
right
<superctr>
Stef wrote a 4 channel 16khz PCM mixer on the Z80, and the XGM player also does 4ch PCM mixing on the Z80, though at 12khz instead
<superctr>
The RF5C68/164 does not handle compressed samples, which would be a pretty big issue anyway for early Megadrive games
<superctr>
the SNES had "BRR" which helped keep sound data small and game developers happy
<cr1901_modern>
mmmm
<l_oliveira>
playstation also use that BRR thing
<superctr>
Most Mega CD (and also sega arcade) soundtrack just swap samples constantly between sample RAM and sub cpu RAM (or ROM for the arcade games)
<l_oliveira>
same design, just bigger capacirt
<l_oliveira>
capacity*
<superctr>
the PSX and PS2 SPU is based on the SNES DSP
<superctr>
both were designed by Sony so it makes sense anyway
<l_oliveira>
lol the PS2 SPU compared with the PS1 SPU is like a OPL3 to a OPL2 chip
<superctr>
tough the PSX BRR uses more samples per block compared with the SNES
<l_oliveira>
there's two PS1 SPU cores in it
<superctr>
i believe the block size on the PSX is 16 bytes and 8 byte son the SNES
<cr1901_modern>
If you play ff7 music on two SNESes at once, it's indistinguishable from PS1
<l_oliveira>
hahaha
<cr1901_modern>
or nearly so
<superctr>
anyway, i think an interesting PCM chip to decap would be the RF5C400
<superctr>
It's another ricoh chip, but this one has a currently unemulated "Spatializer" effect
<superctr>
it was only used in Konami arcade games, i think
<l_oliveira>
a lot of konami boards use it
<l_oliveira>
the newer ones
<l_oliveira>
with power pc cpu
<superctr>
System16 says that another TMS57002 is used to do the effect instead, that could also be true though
<l_oliveira>
I might have one of it here
<superctr>
since I fixed the TMS57002 last year, it could be emulated
<l_oliveira>
don't system GX have that DSP in it?
<superctr>
yeah, GX had that
<l_oliveira>
for echo and spatial effects?
<superctr>
and the effects were only half-working due to the broken DSP emulation
<l_oliveira>
hm ... maybe fix GXP
<superctr>
it does reverb effects anyway
<Sarayan>
what was broken in the dsp emulation?
<l_oliveira>
with the new updated code
<l_oliveira>
you know GXP?
<superctr>
the multiplication pipelined wasn't emulated
<superctr>
So multiply results would show up immediately on the bus when it was supposed to be delayed
<Sarayan>
Oh funky, I missed that
<l_oliveira>
oh there's the author, no?
<l_oliveira>
<excitement rising>
<superctr>
Taito Gnet/FX1B also had another saturation flag that wasn't even mentioned in the manual
<Sarayan>
gxp, is that my gx player?
<l_oliveira>
yes
<Sarayan>
mwahhaa
<Sarayan>
I didn't even realize it was out there
<l_oliveira>
oh man I got it back in 2001
<l_oliveira>
kept it dearly here
<l_oliveira>
even though it is stuck at the quality MAME had back then
<Sarayan>
I think you mean 2011 though
<l_oliveira>
"gxp: Konami GX sound player v0.1
<l_oliveira>
October 5, 2001
<cr1901_modern>
I was about to say... you did MAME work back in 2001?
<l_oliveira>
By Sarayan from the Borg, errr, I mean Mame
<l_oliveira>
Second in a series of Modeler Muppet hacks. Enjoy!"
<l_oliveira>
that is very early, no?
<l_oliveira>
am I outdated?
<superctr>
lol, perhaps i could fix it up and add it to Quattroplay
<l_oliveira>
it even mentions you had a hot headed slot 1 athlon back then
<cr1901_modern>
October 5, 2001 was approximately the time that I was learning how to run ZSNES, and wondering why it would exit immediately when I tried running it from double clicking the icon
<l_oliveira>
which was also what I had back then
<Sarayan>
when was street fighter 1 added to mame?
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Sarayan>
og.kervella.org/gxp.tar.bz2 current state of my gxp directory
<cr1901_modern>
convert the cvs repository to git :P?
<l_oliveira>
this one has source in it, if you're missing it
<cr1901_modern>
that's what ppl used then, right?
<superctr>
ah, it emulates the 68k as well
<superctr>
My approach is to reverse engineer the music format and play it directly
<l_oliveira>
yeah it's similar to psf/ssf/dsf players
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
<Sarayan>
superctr: there may be more than one format though
andlabs has joined ##yamahasynths
<superctr>
well of course, they also could have sticked with one format with minor eventual changes
<superctr>
Namco would be quite good example of that actually, they used different variations of the same basic sequence format between 1985 and 2000
<superctr>
Sega's arcade games also used a fairly similar format (with minor changes) from the 80s until they changed to a MIDI-based format around midway though System 32 era
<superctr>
Konami i haven't looked very much into, all I know there is that they used standard MIDI files for the Gticlub/Hornet sound driver (Ricoh sound chip)
<l_oliveira>
looking at the dates, the version of GXP I have here is from 2003 ( I thought I had the earliest version but that isn't the case)
<l_oliveira>
2003/04/20
<superctr>
a nice thing is that when they don't change the sound format, your code will work for all kinds of games despite the original sound hardware
<superctr>
like Quattroplay works for games that used 6809, M37702, H8/3002 etc, even one X68K game
<Sarayan>
superctr: you REd and collated the music formats?
<superctr>
yeah
<Sarayan>
I'm very interested, it's something I always wanted to do but never had time to
<superctr>
I also have a proof of concept where I reverse engineered the music format from Battletoads arcade (BSMT2000), converted it to Namco's Quattro format and replaced the music in Tekken 3
<Sarayan>
quattro is specifically a namco format then?
<superctr>
yeah
<Sarayan>
what I was interesting in, conceptually, is something that converted the music data into something DAWs can cope with.
<superctr>
that would be MIDI files
<Sarayan>
but I'm not even sure what that format could be
<Sarayan>
you need instruments too
<superctr>
SF2 for the samples
<superctr>
Though of course that won't work for FM sound
<Sarayan>
yeah
<superctr>
A problem with MIDI is that you have a limitation of 16 channels (they have polyphony but need to use the same instrument, panning etc)
<Sarayan>
possibly some "generic" vst for fm
andlabs has quit [Ping timeout: 250 seconds]
<superctr>
Quattro supports 32 monophonic channels, so it doesn't really convert 100% into MIDI
andlabs has joined ##yamahasynths
<Sarayan>
yeah, that's annoying
<superctr>
in many cases MIDI were the original source format and they later converted it to sound driver custom formats, but here this is not the case. Apparently they used a tracker or similar application to produce the music
<Sarayan>
mapping the samples/fm to gm/xg voices can be an interesting problem too
<superctr>
there's a program called VGMTrans that supports a few different sound formats (mostly SNES and PSX) and creates MIDI and SF2 files
<superctr>
it also supports a few Capcom Qsound games
<Sarayan>
nice
<superctr>
hm, vgm2midi uses heuristics to convert FM instruments to MIDI voices
<superctr>
it's really not perfect (hard to detect different kinds of percussion sounds for example)
<Sarayan>
that's for sure
andlabs has quit [Ping timeout: 246 seconds]
<superctr>
Someone in vgmrips was working on a CPS3 sequence to MIDI converter (i helped him with reversing the sequence format)
<Sarayan>
cool
<superctr>
he recently gave up though, it was hard to make envelopes and LFO sound correct in the MIDI files
<Sarayan>
yeah, that's a real problem
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
<Wohali>
cr1901_modern: PCBs will arrive Monday now. I'll need a couple of days to sort out shipping estimates and get the cart online
<l_oliveira>
ugh it was a pain to get that GXP build to compile
<l_oliveira>
but it works
<l_oliveira>
thanks for the update Sarayan
<whitequark>
Sarayan: crazy idea
<whitequark>
openstreetmap has a map editor
<whitequark>
collaborative map editor
<whitequark>
that lets you vectorize raster maps into polygons
<whitequark>
maybe we can use it for silicon RE??
<l_oliveira>
lots of debug printf on it, too (hehe)
<l_oliveira>
(DSP stuff)
andlabs has joined ##yamahasynths
<ValleyBell>
superctr: Yes, I added a hack in VGMPlay to make Cosmic Fantasy Stories sound better. They used value 0x00 for -127 (which would usually be 0xFF). I might remove it from libvgm at some point though. (I'd like to do the fix on the VGMs themselves instead.)
<ValleyBell>
I assume it was a broken converter.
<ValleyBell>
I don't think all samples are affected though. Maybe only few were clipping.
<cr1901_modern>
Wohali: Thanks for the update :)
<Wohali>
anytime
<whitequark>
hm
<whitequark>
I wonder if I can use an FM synthesizer to generate DTMF tones
<whitequark>
i mean, probably, yes
ej5 has joined ##yamahasynths
<MicroHex>
without a doubt, really
<TD-Linux>
hard mode: one channel
<whitequark>
ha
<MicroHex>
expert mode: percussion channels only
<whitequark>
do it
futarisIRCcloud has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]