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
<interruptinuse>
>you could just rescale the notes
<interruptinuse>
please dont correct for a wrong clock or w/e by compensating it on-chip
<interruptinuse>
not even sure how that would work with e.g. percussion
<cr1901_modern>
In OPM's case, 4MHz and colorburst are two legitimate clock freqs I've seen on various boards. In fact, 4 MHz is the one I'm used to even though it's "wrong" (max allowed freq) :P.
<cr1901_modern>
x68k, and Atari System 1 both use 4 MHz
<whitequark>
using max allowed freq is not wrong.
<cr1901_modern>
colorburst is considered the "recommeneded/nominal" freq
<whitequark>
you have to consider the datasheet values in context
<whitequark>
.. oh wait
<whitequark>
i just realized something unrelate
<whitequark>
i can stop the entire synth on command stream underflow -to compensate for usb latency spikes-
<cr1901_modern>
Furthermore, the minimum duty cycle (on) for the OPM clock is 40% (it is supplied as 100ns, which at 4 MHz would be 40%).
<cr1901_modern>
Since x68k generates its 4MHz clock from a 10MHz clock, and I doubt anyone back then gave a crap about duty cycle correction, I have reason to believe the clock received by OPM is 40% duty cycle.
<cr1901_modern>
fseidel: What x68k version does your uni club have?
<whitequark>
cr1901_modern: re context: they should've qualified the chip from 3 to 4 mhz
<whitequark>
i mean, it's yamaha, so i'm willing to believe they didn't, but they should hav
<whitequark>
now, the question is, qualified how?
<cr1901_modern>
Let's be honest, neither of us would be surprised is more than half that datasheet is lies/inaccurate.
<cr1901_modern>
But it's the info I have right now, and "ppl in the 80s made do w/ it"
<whitequark>
for example, it would be one thing to run timing analysis once at ntsc colorburst freq, and then think "oh, uhhh, ±15% is within our mfg variation"
<whitequark>
or
<whitequark>
they could run the timing analysis at 3 mhz and 4 mhz
<whitequark>
and then consider worst case manufacturing variation
<whitequark>
and say "yeah, even in worst case variation + max freq this should still work"
<whitequark>
modern datasheets sometimes say what they mean exactly in cases like this
<cr1901_modern>
probably 3 mhz + x% and 4 mhz - x% variation to get the bounds that'll work regardless?
<whitequark>
yes. that is the sane thing to do. and why i said that running it at 4 mhz is not wrong.
<whitequark>
i'm not sure if the yamaha engineering is insane, or only their documentation department
<cr1901_modern>
I wonder if they said f*** it at the end of the day and determined "100ns" duty cycle is a conservative value that works regardless for worst case tolerances in the supported range
<cr1901_modern>
of input clocks
<cr1901_modern>
>i'm not sure if the yamaha engineering is insane
<cr1901_modern>
Would love to poke their brains, but they'll all retired by now almost certainly. And don't want to be found. And I can't speak Japanese.
<whitequark>
40-60% duty sounds just like 10% tolerance
<fseidel>
cr1901_modern: Expert HD
<whitequark>
cr1901_modern: i tried to poke some soundblaster people through a contact
<whitequark>
they have long lost all yamaha documentation they had
<whitequark>
several office moves prior
<whitequark>
could have worked 15 years ago
<cr1901_modern>
that is not comforting...
<whitequark>
so it seems like whatever we have through bitsavers is just about it
<cr1901_modern>
About 5 years ago, I was looking into the Matsushita CD ROM spec. This predates IDE. Most of the public docs were done by one person doing a Linux driver in 1996. On a lark, I emailed them... and I was able to get their source and docs. In 2014. I was dumbfounded this worked.
<cr1901_modern>
Never did much with it, but... it's like "what if I waited just a bit longer?"
<cr1901_modern>
fseidel: Is the YM2151 a discrete chip on the Expert HD?
<cr1901_modern>
(Answer: yes, but it appears the HD's peripherals use a separate 16MHz clock domain from the CPU in that model)
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
Lord_Nightmare: Maybe you know offhand, and this is SNES, so technically OT, but... how are echoes implemented? Is there a special filter for it like there is to implement BRR?
andlabs has joined ##yamahasynths
<interruptinuse>
cr1901_modern: see the latest glasgow commit
<interruptinuse>
that's basically it
<interruptinuse>
you hook each register write and bitflip the data occasionally
<cr1901_modern>
I look forward to trying it out
<whitequark>
you can also eat the writes
<whitequark>
and change the waits
<cr1901_modern>
changing the waits has the highest potential of hilarity
<cr1901_modern>
IME the best glitches are ones where the sound driver channels go out of sync
<cr1901_modern>
which in VGM land would be implemented as waiting the wrong time between sets of reg writes
ej5 has quit [Read error: Connection reset by peer]
<cr1901_modern>
one channel slows down while every other channel speeds up or goes to hell. It's beautiful :'D!
<whitequark>
it'd be pretty challenging to get channels out of sync if all you have is an incoming write stream
<whitequark>
i mean
<whitequark>
you basically have to buffer the writes separately and then reemit them
<whitequark>
which the current API is totally unsuitable for
<cr1901_modern>
Well I'm sure I'll get something amusing out of the current API for my own twisted pleasure :)
<whitequark>
i mean
<whitequark>
i could just change the API
<cr1901_modern>
(Idk anything about Sonic 3's sound driver, but in the context of that linked corruption, what's probably happening is that when Sonic enters the water, the ROM corrupted the global wait timers that control when the next "change the note reg writes" should occur.)
<whitequark>
ok so i just realized a way to make the applet simpler *and* more reliable
<cr1901_modern>
?
<whitequark>
only run the clock during OP_WRITE and OP_WAIT
mewtrino has joined ##yamahasynths
mewtrino was banned on ##yamahasynths by cr1901_modern [*!mewtrinoma@gateway/shell/matrix.org/x-frgykimpdrbzaedj]
mewtrino was kicked from ##yamahasynths by cr1901_modern [mewtrino]
<cr1901_modern>
3rd time...
<whitequark>
should probably ban by nick instead of full mask
<cr1901_modern>
Like "/mode +b *!mewtrino*"?
<whitequark>
i don't remember how exactly it works
<cr1901_modern>
Can't remember if I gave balrog the ability to op himself (I think I did- he's the actual competent IRC admin, not me)
<superctr_>
<cr1901_modern> Like "/mode +b *!mewtrino*"? <- that's the username, nickname comes before the !
<cr1901_modern>
If I ban by nickname, then they'll just use a new one
<cr1901_modern>
and I don't really want to go back to "only registered can speak"
<KitsuWhooa>
You're going to need to ban by as many things as possible :p
<superctr_>
it's possible to change the username just as easily as the nickname
<superctr_>
especially if you have an identd running
<KitsuWhooa>
I mean
<KitsuWhooa>
it's literally a setting in the client
<KitsuWhooa>
:p
<KitsuWhooa>
also, morning ctr :p
<superctr_>
i'm going to work in a few minutes :P
<KitsuWhooa>
I gathered, yeah
<cr1901_modern>
Well (I mean, clearly they're reading the logs so who cares if they see), I think they're taking advantage of the fact that I really am not good at IRC adminning.
<cr1901_modern>
They've been banned from multiple other channels for stalking, but it seems this is the only one they keep coming back to. So I'm doing something wrong (tm).
<KitsuWhooa>
not really, unless you force accounts, that's how it is
<KitsuWhooa>
*force an account requirement
<cr1901_modern>
account requirement? You mean "only regs can speak"?
<superctr_>
i wonder if the hash at the end of the matrix hostmask is based on the IP
<KitsuWhooa>
yeah, nickserv account
<superctr_>
in that case you could maybe use that
<superctr_>
if it's just random letters then it would unfortunately be super easy to ban evade
<KitsuWhooa>
not speak, join in general
<cr1901_modern>
I don't like that either. None of the other channels that I've known them to be banned from enforce that either
<KitsuWhooa>
then it's a game of cat and mouse, really
<cr1901_modern>
Guess I'll live with that then, and perhaps add a third mod for when neither balrog and I are around (same time zone)
<superctr_>
i once banned an entire ISP due to an extremely annoying user
<KitsuWhooa>
I can help if you want :p
<KitsuWhooa>
but yeah, it helps having different mods in different timezones
* cr1901_modern
nods I'll look into that tomorrow if you don't mind, because I completely forget how to add a mod that can give themselves ops
<Stilett0>
<whitequark> cr1901_modern: i tried to poke some soundblaster people through a contact
<Stilett0>
<whitequark> several office moves prior
<Stilett0>
<whitequark> could have worked 15 years ago
<Stilett0>
<whitequark> they have long lost all yamaha documentation they had
<KitsuWhooa>
sure
<cr1901_modern>
Let's not forget about Stilett0's contribution to saving docs :P
<Stilett0>
whitequark - indeed! 15 years ago was when I was most active hitting up packrat engineers :)
<whitequark>
hahaha
<Stilett0>
well, 15-18-years ago
<Stilett0>
I am curious what Yamaha documentation you thought they might have beyone the datasheet and application manual?
<cr1901_modern>
I think most of agree the Yamaha docs are... well, they kinda bite, but are better than nothing.
<Stilett0>
<cr1901_modern> About 5 years ago, I was looking into the Matsushita CD ROM spec. This predates IDE. Most of the public docs were done by one person doing a Linux driver in 1996. On a lark, I emailed them... and I was able to get their source and docs. In 2014. I was dumbfounded this worked.
<Stilett0>
I have built my whole "career" on this :D :D :D
<cr1901_modern>
Stilett0: While it's on my mind, has there _ever_ been an indication that Yamaha produced a manual for YM2612 that wasn't bastardized once when creating the Japanese Sega Genesis manual, and then bastardized a second time when translating to English?
<cr1901_modern>
I.e. Perhaps FM towns got a manual for the 2612 as well?
<andlabs>
if it's not, DM Sik on Twitter and ask them
<andlabs>
(do so anyway)
<andlabs>
anyway good night
<cr1901_modern>
night
<Stilett0>
cr1901: I've been asked that frequently if there's an official one, most recently by R. Belmont who felt that it must exist somewhere. I haven't ever heard of such a thing but that doesn't mean that it never existed
<Stilett0>
after all, I am not an ex-Yamaha JP engineer... or know any :)
<cr1901_modern>
My guess at this point is that _similar to_ Broadcom's shitty business practices, Yamaha wouldn't give you a programmer's manual/datasheet for the budget parts unless you had a MOQ. >>
<cr1901_modern>
And back then, the way Yamaha gave you documentation was to work w/ the vendor to integrate the programmer's model into the vendor manual from their internal specs.
<cr1901_modern>
from Yamaha's internal specs*
<cr1901_modern>
TLDR: Plausible a manual never existed for the budget parts and any programming info was based on internal design specs Yamaha shared w/ on a vendor basis.
<cr1901_modern>
Also, that FM Towns manual isn't loading. But that's okay I couldn't read it anyway lmao
<whitequark>
are there any info at all on how to write fm patches
<whitequark>
is there*
<cr1901_modern>
VGM Music Maker's help file attempts a mini tutorial, but my own experience is that writing patches is trial and error until it sounds the way you want.
<cr1901_modern>
And over time you get better at mimicking others patches and being able to predict how changing one register slightly changes the timbre of the output sound.
<whitequark>
hmm
<whitequark>
should we make some kinda GUI for defining those, maybe
<cr1901_modern>
There are a few... none that are cross platform AFAIK
<cr1901_modern>
Some random YM2151 patch editor I have around that has basically no documentation, I forget the author offhand, and last I checked he's been inactive for years
<cr1901_modern>
(I'll find a link tomorrow)
<cr1901_modern>
The videos of it in action are still up w/ download link, I just don't remember it offhand
<cr1901_modern>
This isn't a fun patch editor to use, btw :P
<cr1901_modern>
There's another one andlabs told me about recently that's new. Seems to be pretty promising. I'll ask him for the link
<cr1901_modern>
whitequark: For some instruments, there are good rules of thumb. E.g. for a percussion snare, you want a very noisy beginning (high attack, high self-feedback on operator 1) that dies down quickly (high decay/release, no sustain).
<whitequark>
cr1901_modern: hey i have an idea
<whitequark>
can OPN2 somehow use one of its timers to output an IRQ every 72 cycles?
* cr1901_modern
is trying to remember how the timers work
Xyz_39808 has joined ##yamahasynths
<cr1901_modern>
t = 18 × (1024 - Timer A) µs
<cr1901_modern>
t = 288 × (256 - Timer B) µs
<whitequark>
oh hm
<whitequark>
they aren't self-reloading are they
<cr1901_modern>
Too fast I believe
<cr1901_modern>
and afaik, no
<whitequark>
kinda thinking about connecting ym2612 to glasgow
<cr1901_modern>
72 cycles at 7.68 MHz is 9.375 us
<cr1901_modern>
that's about twice as fast as timer A counts
<Stilett0>
oh yeah that FM TOWNS manual, I forgot about that! there's YM2612 info from pages 190-214 (PDF pages 218-242)
<whitequark>
so they divide sample clock by 2 and 32
<whitequark>
i was thinking maybe i could get it to effectively output sample clock
<cr1901_modern>
(Note: to be able to vectorize well I zoom in about one level further in inkscape than Group XIV allows)
<cr1901_modern>
whitequark: ^^
<whitequark>
we could relax the groupxiv restriction on that btw
<cr1901_modern>
Oh, I thought the limit was based on "that's the deepest level of tiles that were created for the die"
<cr1901_modern>
Stilett0: Do you know whether we have a copy of a Japanese Sega Genesis programmer's manual. And if so, do we know how accurate the YM2612 programmer's model is in the _Japanese_ copy?
<cr1901_modern>
(meaning perhaps all the horrible mistakes occurred between Sega of Japan and America, not Yamaha and Sega of Japan)
<whitequark>
cr1901_modern: no, it already zooms past that
<whitequark>
just only one level
<whitequark>
that register file (?) is massive
<Stilett0>
cr1901: I don't think we have one? but I will double check
<Stilett0>
that's a sensible theory at least
<Stilett0>
anyhow bedtime :)
<cr1901_modern>
whitequark: Yea, I don't get it either re: the reg file (well, yet, anyway). OPM functionality is almost a subset of OPN
<cr1901_modern>
(I love how the "giant" image is 2MB)
<cr1901_modern>
whitequark: I am sleeping for a few hours. If you have q's, leave them here and I'll get back to you.
<whitequark>
oh seanriddle does delayer too
<whitequark>
maybe my yamaha decap/delayer project is obsolete then
<cr1901_modern>
I recognize the name, digshadow and Lord_Nightmare speak highly of him. But if I were doing vectorization of 2612, can't use those images as-is I don't think.
<whitequark>
hm alright
<cr1901_modern>
(Also observation: I can't remember which family each chip belongs to, but I remember random 4-digit number. On the other hand, you remember the family name before the 4-digit number)
<whitequark>
yeah, i'm not sure which to use in glasgow, too
<cr1901_modern>
My gut says family member is more useful. Would like a second opinion, since every time we name a "new" chip, two more warp into existence behind someone's desk or something.
<whitequark>
lol
<Sarayan>
sean is rather good but does not have the hardware for high-res die shots that could be used for RE
<Sarayan>
that 2612 is really nice, I'd love a high res of it
<Sarayan>
very clean decap
<whitequark>
ahh
<Sarayan>
he's done a lot of G&W decaps which are big enough to visual rom dumping at the res he can get
<Sarayan>
s/to/for/
<Sarayan>
I really need to send you the votrax. I think I'll be able to do it tomorrow
<whitequark>
cool!
<whitequark>
g&w?
protosphere has quit [Quit: WeeChat 2.3]
<Sarayan>
game&watch, the game handhelds
<ValleyBell>
whitequark: OPN2 Timer A can expire once for each output sample (sample rate is clock / 144, which is also the fastest Timer A setting)
<ValleyBell>
However, you need to manually reset the IRQ by writing to register 27h.
<whitequark>
ValleyBell: right, so it wouldn't work, because then 100% of bus bandwidth (if not more) would be taken by IRQs
<cr1901_modern>
G&W is very very strange internally. I really don't understand it, but there's no actual CPU in those modules- just a custom ASIC implementing a hardcoded FSM w/o any program store.
<cr1901_modern>
I know, I'm being cheeky. I think it's a cool CPU
<balrog>
or yeah, unidasmk
<balrog>
-k
<ValleyBell>
oops, sorry, it's P8098
<balrog>
oh that's mcs-96
<balrog>
ida pro has INTEL 80196 which might be close enough
<balrog>
ghidra has mcs-96
<Sarayan>
you data bitswap still has issues, at least on ic20
<Sarayan>
unless it's log
<Sarayan>
and since there's text, you don't have issues
<Sarayan>
so it much be log
<ValleyBell>
yeah, probably
<ValleyBell>
I'm really glad they put the instrument table in IC18.
<ValleyBell>
It made it so much easier to figure out the lower bits.
<Sarayan>
need moar stats
* Sarayan
catenates romz
<Sarayan>
yup, nicer with moar data
<Sarayan>
so so yeah, a little log, not too much
<Sarayan>
so, it's 2's complement, but the compression works on the absolute value
<Sarayan>
e.g. get the sign, get the abs, do the ramp, put the sign back in
<Sarayan>
0..31 stays 0..31
<Sarayan>
32..63 is 32..94
<Sarayan>
64..95 is 96..124
<Sarayan>
96..127 is 128..376
<Sarayan>
there's no -128 in the data, so whatever
<cr1901_modern>
balrog: Thanks. KitsuWhooa has offered to be a mod when we aren't around as well. Could you add them (with allowing them to op themselves) while you're at it?
<Sarayan>
okay, I'm wrong
<Sarayan>
after 32 is doubles the step every 16, not 32
<Sarayan>
so, as a formula, it's ((v & 0x0f) << shift[v >> 4]) + base[v >> 4]
<balrog>
KitsuWhooa: are you familiar with ChanServ etc?
<ZirconiumX>
balrog: KitsuWhooa runs #ckb-next, so yes
<ZirconiumX>
Source: I'm his other half
<balrog>
ah nice
<Sarayan>
hey cool
<ZirconiumX>
KitsuWhooa also has a bot, if really necessary.
<balrog>
hopefully those bans are still effective :|
<balrog>
ZirconiumX: probably not necessary on freenode; on efnet it would be a must
<ZirconiumX>
I like how my client highlights your mod status whenever you highlight me
<balrog>
probably won't anymore :)
<ZirconiumX>
Indeed
<ZirconiumX>
:P
<balrog>
IRC services are nice. As is not having to have a good internet connection to keep your username
<cr1901_modern>
heh
<balrog>
around 2016 someone stole my username on efnet for, from what I could best tell, an anti-Hillary bot channel
<balrog>
KitsuWhooa: you should be able to give yourself ops/voice when needed etc
<balrog>
via chanserv
<balrog>
maybe earlier than that, thinking back to it was more likely 2011-2012
<balrog>
at the same time I had shitty DSL internet that would cut out all the time
<Lord_Nightmare>
yeah it was way old
<Lord_Nightmare>
i think it was an early ?eastern-european? anti-us troll channel, used as a command and control channel for something, likely not actually IRC based
<cr1901_modern>
balrog: Is your current name a Tolkein or Street Fighter reference?
<Lord_Nightmare>
the bots all had tolkien names
<balrog>
cr1901_modern: originally was the former
<balrog>
but it stuck lol
<balrog>
I don't use it for new stuff and I don't use IRC much anymore
<balrog>
I'm on now mainly for #yahoosucks (on efnet)
<balrog>
(yahoogroups archival)
<cr1901_modern>
haha, indeed
<cr1901_modern>
yahoo are boneheads
<balrog>
is anyone here on yahoo groups they need archived?
<balrog>
if so, please make a list of groups and of who is a member
<balrog>
since to capture everything a group member needs to run the script — even for groups that are public-read, you need to be a member to access files etc.
<Sarayan>
I think I'm a member on some synth-related groups
<cr1901_modern>
This is gonna be sadly be harder than archiving geocities
<balrog>
ideally the people who are on the groups will have to run the archiving script (atm it's a python2 script that requires `requests`) with their cookies
<Sarayan>
balrog: I'm on casio_keyboards CybikoDev CZsynth Moog_Source oberheim YamahaDX YamahaDXfiles need any?
<balrog>
yes we'll need a few of those
<balrog>
I'll poke you when the scripts have some more fixes
<balrog>
of those — I'm on CZsynth YamahaDX YamahaDXfiles
<cr1901_modern>
What is CZsynth?
<balrog>
casio cz-1
<balrog>
casiokeyboards probably has more, I have a VZ-1 and a VZ-10M
<Lord_Nightmare>
so we need to capture both using the main grabber AND using the frank fork? when is that going to get resolved?
<balrog>
it sounds like I need to get around to manually merging shit
<Lord_Nightmare>
the yahoo grabber devs are running around like headless chickens
<Lord_Nightmare>
nobody's collaborating, it was driving me nuts
<Lord_Nightmare>
did philpem add you as a contributor to his tree?
<Lord_Nightmare>
that would work, if he does that...
Xyz_39808 has joined ##yamahasynths
<balrog>
there's some collaboration
<cr1901_modern>
>This is a very good take and I wish to subscribe to your newsletter
<cr1901_modern>
Is this in reference to txtfiles' project?
<ValleyBell>
okay, the CM-32P driver works - except that apparently the RAM is mapped differently and thus it crashes early
<ValleyBell>
LD SP, #3FFE
<ValleyBell>
The MT-32 has RAM mapped to C000..FFFF.
<ValleyBell>
(actually ... this might be a better topic for #mamedev)
<Sarayan>
well, indeed that shows where some ram is
<Sarayan>
cr1901: that's a 25 years old expression
<emily>
it's a simpsons quote.
<emily>
22 years old, apparently.
<Sarayan>
oh well, I had the order of magnitude :-)
<KitsuWhooa>
So I guess the samples weren't spread across the roms
<KitsuWhooa>
I wonder why I was getting that result
<ValleyBell>
Also thanks to Sarayan for the sample decoding algorithm.
<KitsuWhooa>
ah, I missed it
<ValleyBell>
Maybe it was because it layered multiple instruments over each other.
<KitsuWhooa>
I guess, but I'm sure I had a single one selected only, when testing
* KitsuWhooa
shrugs
<ValleyBell>
fixed the tool and updated the archive
<ValleyBell>
aww... the CM-32P seems very different from the MT-32 in regards to memory layout
<balrog>
I'd expect it to be
<KitsuWhooa>
<ValleyBell> But, in IC18, at offset 0x80, it also says "CM32P 1.00" after descrambling. <-- that's also interesting /late
<KitsuWhooa>
Also, for anyone who doesn't want to bother, I took the three roms, decoded them using the tool and merged them using audacity https://tasossah.com/CM-32P-samples.flac
<KitsuWhooa>
link probably won't be up forever, but still :p
<ZirconiumX>
It's a bit surreal to listen to
<ValleyBell>
Okay, due to the completely different memory/IO layout, the CM-32P gets stuck in a loop at BB06 (waiting for the interrupt that never happens).
<ValleyBell>
I ... think I'll stop for today.
<KitsuWhooa>
indeed :p
<KitsuWhooa>
On the bright side, I'm glad my dumps are okay