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
<Lord_Nightmare>
whitequark: " - OPLL/OPL(?)/OPL2(?): address 12 cycles, data 84 cycles. (only documented for OPLL)" this is wrong, the OPL2 application manual also documents the 12/84 cycle thing
<Lord_Nightmare>
i suspect OPL is the same
<Lord_Nightmare>
OPL3 however i believe is much faster and doesn't have those same cycle requirements
<whitequark>
Lord_Nightmare: but not the datasheet
<whitequark>
and i wrote that when i didn't have the AM
<Lord_Nightmare>
ah
<Lord_Nightmare>
cr1901_modern: i may move that page to id=vendro:yamaha:opl-series
<Lord_Nightmare>
since the technical specs of the OPLL, OPL, OPL2, VRC7, and OPL3 are ALMOST the same
<Lord_Nightmare>
OPL3 inherits the 4-op stuff from the OPN series
<Lord_Nightmare>
OPL and OPN also both share the CSM mode stuff, but it behaves a little differently on OPN
<Lord_Nightmare>
i'd say OPL and OPN series, generation wise are most similar
<Lord_Nightmare>
OPM is weird, i'm guessing the odd way it does note frequencies is closer to the OPS/EGS but there's very little public RE work on the DX7 series chips
<Lord_Nightmare>
and OPZ from what little I know of it is bizarre, and is almost a hybrid of OPL3 and OPM, but is older than OPL3
<l_oliveira>
OPM and OPN share the same data format for instruments definitions
<l_oliveira>
can use instruments from one on the other almost verbatim (operator settings)
<ValleyBell>
And I can confirm that accesing the OPL3 on my SoundBlaster 16 with the times listed there worked.
<Lord_Nightmare>
my guess is opl3 has a state machine which buffers one or two writes, hence can get away with much shorter delays
<Lord_Nightmare>
while opl and opl2 did not have that
<Lord_Nightmare>
this would explain the long delay for writes, since it has to wait an entire 'loop' of everything serially through the operator unit to finish
<Lord_Nightmare>
while opl3 can buffer the write (or 2 writes, or more? it might have a 17-bit-wide fifo for address+a2 and data)?
<Lord_Nightmare>
and the data delay is just for stabilization
<Lord_Nightmare>
we'd need to decap an opl3 to see, the fifo, if it has one, should be pretty obvious
<l_oliveira>
maybe it could be like the OPNA and OPN2 which have twice the registers to sweep, it runs twice the clock
<whitequark>
we don't have an opl3 decap?
<Lord_Nightmare>
we have the one yehar did, not sure if dig did one
<whitequark>
ok i guess i'll order some opl3s too
<l_oliveira>
FA1006 or so it say
<l_oliveira>
weird codes Yamaha came up with
<whitequark>
i guess i can just order 5 of every yamaha chip i see
<l_oliveira>
these are already made on their own fab I suppose
_whitelogger has joined ##yamahasynths
<cr1901_modern>
Lord_Nightmare: Yes go for it
* cr1901_modern
was asleep again
<Lord_Nightmare>
whitequark: dig has at least 4 or 5 opl3 chips
<Lord_Nightmare>
i don't know if he's decapped any
<whitequark>
Lord_Nightmare: they aren't expensive at all i guess
<whitequark>
so i always wait exactly that many clocks
<cr1901_modern>
Okay. Internally, the data might be ready before 84 clks have elapsed depending on the state of the shift machinery
<cr1901_modern>
when the write is received
<cr1901_modern>
but since there's no busy bit just wait out the whole thing?
<Lord_Nightmare>
whitequark: if you WANT an opl3 to decap or to run HW tests on (or to connect to the internet with an FPGA!) then go right ahread and get one
<Lord_Nightmare>
opl3 is kinda neat in that it has 4 outputs
<Lord_Nightmare>
so it can do quadraphonic sound in theory
<Lord_Nightmare>
in practice i don't think i've ever seen anyone hook it up that way
<whitequark>
Lord_Nightmare: yeah i'll connect it to internet
<whitequark>
why the hell not
<Lord_Nightmare>
SaaS (synthesizer as a service)
<whitequark>
sure
<whitequark>
does anyone here want me to build a huge array of synth chips
<whitequark>
i can do that just not sure where to find motivation for it
<whitequark>
like i'd need to do it for something or someone
<cr1901_modern>
whenever I get a glasgow I'm likely to do my own private copy for OPM
<cr1901_modern>
well it'll be on the net too, but I don't think others'll want to use it if I'm spamming it w/ writes :P
<whitequark>
i think you can drive OPM from a revB
<whitequark>
like i can check that easily ig
<cr1901_modern>
revb/c isn't the problem. It's that I don't have a glasgow and revd isn't existing yet :).
* cr1901_modern
is still waiting patiently
<whitequark>
revD is prob half a year to mass production
<whitequark>
at least
<whitequark>
cr1901_modern: just tested
<whitequark>
revB works just fine with an OPL2
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
(or well it was a good asskicker since you had a concrete idea and went and implemented it)
ej5 has quit [Read error: Connection reset by peer]
_whitelogger has joined ##yamahasynths
* cr1901_modern
spent a while thinking
<cr1901_modern>
I know, dangerous idea
<cr1901_modern>
ValleyBell: Okay after thinking hard about it, I _think_ I get VGM now :)
<cr1901_modern>
(I think)
<cr1901_modern>
If/when you have time to chat, let me know (unless wq wakes up first)
<ValleyBell>
cr1901_modern: I just woke up.
<cr1901_modern>
Ahhh well that answers a follow up q I was gonna ask (what's your time zone)
<cr1901_modern>
I'm technically EST, but my sleep schedule doesn't honor normal rules
<ValleyBell>
My timezone is CET/CEST.
<cr1901_modern>
ValleyBell: Ack.
<cr1901_modern>
So... I think I understand VGM now. Let's pretend it only has YM3812 support for simplicity if that's okay?
<cr1901_modern>
* VGM is divided into 1/44100 units. It doesn't care what happens inside those units, all consecutive writes (writes not divided by a wait command) to the YM3812 are instantaneous. Is this correct?
<cr1901_modern>
I.e. all writes that are detected by a "VGM recorder" within a 1/44100th second unit are chained together followed by a "delay 1-16 sample" or "delay whatever" command
<ValleyBell>
yes, exactly
<cr1901_modern>
This also implies once the VGM recorder has detected 1/44100th of a second has elapsed, there is a "delay sample" command tacked on to the stream, correct? This is to force the passage of time to occur from the player's POV?
<ValleyBell>
yes
<cr1901_modern>
(And if there isn't any write commands in the _next_ 1/44100th unit, the delay sample becomes "delay 2 samples" command etc)
<cr1901_modern>
for compression purposes :P
<ValleyBell>
yes
<cr1901_modern>
Okay then I actually get it now. And I did some basic research. I like whitequark's idea for a timebase that's the least-common-multiple of 44100 and master_clock
<cr1901_modern>
it'll fit into a 64-bit int comfortably
<Sarayan>
meh
<Sarayan>
why so complicated?
<cr1901_modern>
Sarayan: The idea is to reuse VGM for cycle accurate writes
<cr1901_modern>
for RE purposes
<Sarayan>
then use nanoseconds
<cr1901_modern>
Sarayan: The reason I like the LCM approach is that timekeeping can be done in LCM units
<cr1901_modern>
and if you need _actual_ time you just do a constant multiple to convert to "VGM samples elapsed"
<cr1901_modern>
or "master clocks elapsed"
<cr1901_modern>
and it's always exact
<Sarayan>
you're going to love it when you have multiple different chips with different clocks in there
<cr1901_modern>
no floating point funny business when nanoseconds can't be exactly represented
<cr1901_modern>
screw those :)
<cr1901_modern>
:P
<Sarayan>
s/floating/fixed/
<ValleyBell>
Just use the S98 format if you want to be cycle accurate.
<Sarayan>
and you're going to have a problem with ym chips which do have a busy signal
<Sarayan>
because its timing is dependant on the internal chip phase, which makes a main program that takes it into account also dependant on the phase
<ValleyBell>
But yeah, the VGM format is pretty simple in general and people with no knowledge about sound chip hardware works (aside from register layouts) can work with it without screwing up too many things.
<cr1901_modern>
Why doesn't OPL2 have this same problem?
<cr1901_modern>
I would conjecture that 84 master cycles is an upper bound
<cr1901_modern>
i.e. the _maximum_ amound of time for a reg write to be honored
<Sarayan>
opl2 has the same problem but no busy flag so yeah, upper bound
<cr1901_modern>
So... use the upper bound for the other chips
<cr1901_modern>
they are given in the datasheets or application manual
<Sarayan>
why would the program you're recording the outputs of use the upper bound if there's a busy flag?
<Sarayan>
incidentally, *when* a register write is used in the oscillator loop is also chip phase dependant
<cr1901_modern>
Sarayan: Oh, the Yamaha chips do that "use both phases of the clk" bullshit?
<cr1901_modern>
that's what you're getting at :(?
<Sarayan>
the fm synth is a rotating <n> steps pipeline
<Sarayan>
where the registers are on shift register loops that rotate so that the correct value for the correct channel is visible when needed
<cr1901_modern>
So? Lots of shift registers don't use both clk phases
<cr1901_modern>
(SPI being a notable exception)
<Wohali>
yay hardware ring buffers
<Sarayan>
the write tap is of course at a fixed position in the shift register loop, so which sample your write is going to apply depends on the current phase of the loop
<cr1901_modern>
oh CHIP phase
<cr1901_modern>
not clock phase
<Sarayan>
yeah
<cr1901_modern>
parse fail
<cr1901_modern>
Sarayan: Yea I agree with everything you say. But I don't see how this throws a wrench into the "least common multiple" time base. You have access to both master clk and vgm sample granularity
<cr1901_modern>
master clk granularity is sufficient for knowing the chip phase in principle
<Sarayan>
it throws a wrench into "cycle exact for perfect reproducibility"
<cr1901_modern>
because you can reference it to a clk cycle where you _know_ the phase
<cr1901_modern>
after say IC
<Sarayan>
oh, how do you know the phase?
<cr1901_modern>
/IC*
<Sarayan>
I'm not at all certain rest actually reses the phase
<Sarayan>
reset
<cr1901_modern>
... which isn't going to normally be asserted, is it?
<cr1901_modern>
hrm... gotta be some way to figure out the phase of the chip
<Sarayan>
with luck you can sync on th dac output, on the digital ones
<cr1901_modern>
Well I assume you have access to the DAC output here
<Sarayan>
since I suspect that's synchronous with all the rest
<cr1901_modern>
Maybe reset all regs to 0, wait for a reasonable number of clk cycles
<cr1901_modern>
and then do a reg write and count the cycles elapsed to DAC output changing
<Sarayan>
then you have access to the dac output
<Sarayan>
or you're saying to analog ones?
<Sarayan>
s/to/on/
<cr1901_modern>
Either one should work (if you have a synchronous or constant-delayed ADC for the analog ones)
<cr1901_modern>
eventually the analog output will die, so you can use a sudden write to "lock onto" the internal phase
<ValleyBell>
off to work - don't expect replies for the next 9 hours or so
<cr1901_modern>
ValleyBell: Have fun, thanks for the help
<ValleyBell>
(I'm running WeeChat on a BananaPI, so I'll still be online.)
<cr1901_modern>
Oh cool I want one of those
<cr1901_modern>
Sarayan can keep me entertained by telling me how I'm wrong ;)
<Sarayan>
the ones with digital dac output, I'm pretty sure you can get the phase from when the data starts to be shifted out, since that's entirely chip-controlled
<cr1901_modern>
right. I'll need to mull this over
<cr1901_modern>
(valsound == takeshi abo. He has a wonderful repo of FM synth patches)
<cr1901_modern>
valsound: The user whitequark created this: http://188.166.218.19:17425. You can send OPL2 music over the Internet and an OPL2 chip will play it and send the music back to you.
<cr1901_modern>
It's like a GIMIC-mini :)
<valsound>
oh, I composed and programmed this data "StarFire".
<cr1901_modern>
Programmed the music driver, or did you write the whole game?
<valsound>
Most of OPL has not used it, but think that I can easily make a sound if I think that it is algorithm 4 of OPN.
<cr1901_modern>
I have to look up algorithm 4 :P
<cr1901_modern>
The only one I know from memory is algorithm 0 and 7
<valsound>
Originally a music driver is made in STARCRAFT which there was. I customed it.
<cr1901_modern>
b/c they are the easiest :)
<valsound>
STARCRAFT sound drive is 'MUSDRV'.
<cr1901_modern>
I've heard of that. I thought MUSDRV was an x68k driver :o
<cr1901_modern>
I guess I was wrong
<cr1901_modern>
hmmm looks like it was a PC-98 driver
<valsound>
In MUSDRV, PC98 is for exclusive use. I write direct binary data in DB sentence.
<cr1901_modern>
hahaha, wonderful XD. I bet that was fun.
<valsound>
Because it was difficult, in DB, I made for control MUSDRV in MML.
<cr1901_modern>
MML is a LOT of similar languages, right?
<cr1901_modern>
Like, the MML you write is different from the MML, say Yuzo Kashiro writes?
<cr1901_modern>
(except for MUCOM88)
<valsound>
MML has many specifications, but is the fundamentally same.
<l_oliveira>
ya, it is on the topic, but thank you again
<cr1901_modern>
I wish more people were awake for this
<l_oliveira>
that's incredible man
<cr1901_modern>
I have no idea how I pulled it off either, really. But we had been chatting for a few days now.
<l_oliveira>
have you seen how many VNs that guy made music for? lol
<l_oliveira>
pretty big ones btw
<cr1901_modern>
I didn't know he did Ever17 and S;G until a few days ago
<cr1901_modern>
I knew him through his FM library
<cr1901_modern>
which I've known about for years
<cr1901_modern>
but never made the connection w/ the Twitter account named "valsound"
<l_oliveira>
heh
<l_oliveira>
he used "val" as nickname on his PC98 works
<l_oliveira>
so valsound for his corporate name makes absolute sense
<cr1901_modern>
afaik, valsound is actually his personal Twitter acct
<l_oliveira>
it's his company name
<cr1901_modern>
but I may have misunderstood
<cr1901_modern>
oooooh
<cr1901_modern>
okay whoops
<l_oliveira>
like Hitoshi Sakimoto has Basiscape
<cr1901_modern>
Devilish is probably one of my favorite FM soundtracks period
<l_oliveira>
And you notice how the guys who dip deep on the engineering part of sound have much deeper reach than just musicians
<l_oliveira>
Masahiro Kajihara, coded his own driver/music engine... Yuzo Koshiro, too. Hitoshi Sakimoto, Takeshi Abo... All of them went deep into the engineering side of it
<l_oliveira>
having these guys pop here is incredible
<cr1901_modern>
Indeed, that was what me mostly talked about- file formats, and drivers. And I introduced him to tinymml
<cr1901_modern>
>having these guys pop here is incredible <-- I was extremely fortunate
<l_oliveira>
let's keep up the good work and more of them will pop in for sure
<cr1901_modern>
I've no plans to slide into the DMs of more composers atm :)
<cr1901_modern>
Would be highly enjoyable to see Glasgow advertised as a lower cost GIMIC
<l_oliveira>
just keep posting good stuff on twitter
<l_oliveira>
what I made on MSX is sort of a GIMIC thing
<l_oliveira>
a buffer cartridge which rises a smaller bus which you can connect to modular boards with music chips in them
<cr1901_modern>
Glasgow is (simplified) USB -> FPGA -> 16 pins
<cr1901_modern>
you could make it look like a MIDI device if you so choose (although I think you'd have to write custom fx2 firmware to do this)
<cr1901_modern>
AIUI, the default firmware just presents itself as "USB endpoints w/o any particular device class"
<l_oliveira>
MSX is a proper computer with pretty decent mass storage and memory capabilities
<l_oliveira>
it's just a 3.57Mhz Z80
<l_oliveira>
that's the only drawback
* cr1901_modern
isn't... actually a z80 fan
* cr1901_modern
hands his retro card in
<l_oliveira>
it's like a mini 8086 lol
<cr1901_modern>
The shadow register stuff and interrupt handling is irritating
<l_oliveira>
only thing that hurts it is that dump 4bit ALU
<l_oliveira>
makes it slow
<l_oliveira>
dumb*
<l_oliveira>
I have a MSX Turbo R which has a Z80 clone with 16bit ALU
<l_oliveira>
as CPU
<l_oliveira>
that thing is fast enough to play mega drive vgms with PCM streams in real time
* cr1901_modern
is distracted right now sorry
<cr1901_modern>
trying to close a bunch of tabs
<l_oliveira>
how I stop the log from scrolling when someone posts a line? lol
<cr1901_modern>
uncheck "live updates"
<l_oliveira>
that made me "oh"
<l_oliveira>
when it popped back to end
<l_oliveira>
thanks
<l_oliveira>
we use the busy flag on chips which have it in the MSX VGM player
<l_oliveira>
the original MSX is slow enough so it's not needed but the Turbo R tramples on the chips if we don't
<l_oliveira>
To make it efficient, we let the program write to the chip and resume processing for VGM. Then, there is a busy loop at the entry of the I/O routine which checks for the busy flag. That way the chance for the busy flag have already cleared is higher or the program will be held up for less time...
<whitequark>
cr1901_modern: adding MIDI support would be fairly easy i think
<l_oliveira>
morning WQ
<whitequark>
hi
<cr1901_modern>
whitequark: Wish you weren't asleep when valsound was here, I could've presented Glasgow better if you were there
<cr1901_modern>
:P
<whitequark>
it's alright
<whitequark>
so, hm
<whitequark>
i really want to play the supaplex theme
<whitequark>
but no one has ripped a vgm yet
<whitequark>
how do i do this
<cr1901_modern>
well, first off... what the hell is supaplex :P?
<whitequark>
DOS game
<whitequark>
really cool main theme that i remember well
<whitequark>
i only found a *remix* of this theme for *opn2*
<whitequark>
which is probably harder than just ripping it
<cr1901_modern>
Get the game to run in DOSBox (use a default build), CTRL+ALT+F7 to start capturing the raw opl2/3 trace
<cr1901_modern>
seems to do what you want as long as you record enough loops
<whitequark>
hmmm
<cr1901_modern>
"VGM loop find"
<cr1901_modern>
you will need to run dro2vgm beforehand
<whitequark>
hm
<whitequark>
it has an "ADLIB.SND" file
<whitequark>
shouldn't i be... using that?
<whitequark>
hm, probably not
<cr1901_modern>
my guess is that adlib.snd is just all the data that the music driver reads. If you want to RE the music driver to create a VGM, by all means :)
<whitequark>
the format is def not an OPL register dump
<whitequark>
fine
<cr1901_modern>
I'm not sure why DOSBox can't dump to vgm
<cr1901_modern>
probably legacy reasons and "no incentive to put dro2vgm into the binary"
<cr1901_modern>
aaand now the damn SNow Bros theme is stuck in my head