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
doppler has joined ##yamahasynths
doppler has quit [Quit: doppler]
doppler has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<ValleyBell>
cr1901_modern: I'd probably just write a small C or Python program to parse the text file and convert it to VGM.
<ValleyBell>
I'd just hardcode the full VGM header.
<ValleyBell>
Then the only thing left to do is converting the timestamps into "VGM wait" commands.
<ValleyBell>
You can probably do that in 30 minutes.
<cr1901_modern>
ValleyBell: I have control over the raw data, so no parsing is needed. I was just wondering if a script already exists given a timestamp and reg reads/writes to convert to a VGM
<cr1901_modern>
Though I guess converting to timestamps isn't a huge deal (vgm's granularity is "a write/read can take place anywhere within 1/44100 seconds and they are all pooled together to the beginning of the 1/44100 second period", AIUI)
<cr1901_modern>
ValleyBell: Well, it was over an hour, rather than 30 mins, but: http://ix.io/2Lqn
<cr1901_modern>
It works
emeb has joined ##yamahasynths
<ValleyBell>
cool
<ValleyBell>
But no, there is no script for "turn X into VGM". You always start from scratch.
<ValleyBell>
... or you take the MAME VGM mod's "vgmwrite.c" code and adjust it until it fits your needs.
<ValleyBell>
That is what I do when I add VGM logging to another emulator.
<ValleyBell>
But I usually rewrite the timing code for every emulator and I also strip like 70% of all the code, because MAME supports 40 sound chips and in most emulators you need only 1 or 2.
<ValleyBell>
Regarding your dump_vgm() function: The header is actually 0x80 bytes in that case.
<ValleyBell>
The "data start offset" is placed at 0x34..0x37 (Little Endian) and the value is 0x4C -> 0x34+0x4C = 0x80
<Sarayan>
only 40? damn, we should do better
<ValleyBell>
So far I've been only adding the "more commonly used" chips
<ValleyBell>
because you 1) need to extend the header for every new chip, 2) assign a set of command bytes for data writes, 3) integrate it into the logger and 4) add it to the player
<Sarayan>
oh, you meant 40 chips actually useable in vgms
<Sarayan>
that is a good score
<cr1901_modern>
ValleyBell: Yup, vgmplay warned me about unknown command thanks to the bad header :P
<cr1901_modern>
Why is the op amp needed in the first place? Why is there a circuit required to connect RB to MP if RB is generated internally already? Current drive?
<cr1901_modern>
Or impedance transformation?
<Sarayan>
ej5: when you say C5, you mean C8?
<cr1901_modern>
10pF is small capacitor
<Sarayan>
C5 is a decoupling cap one the DAC exponential reference voltage input
<Sarayan>
ohhhhhh, the lm358 is a op-amb, I stupidly thought it was a voltage regulator
<cr1901_modern>
On the BUFF pin, the lm358 is being used as a buffer/impedance transformer: Vout "sees" a low output impedance..
<cr1901_modern>
MP is similar, but the 10uF cap on RB (page 3 of datasheet) changes things, and I forget how offhand
Patater has quit [Quit: Explodes into a thousand pieces]