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
emeb has left ##yamahasynths [##yamahasynths]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined ##yamahasynths
<cr1901_modern>
whitequark: I put kyrandia in binja. Now, I'm not great at REing, but the binary looks obfuscated a bit. Segment:offset pairs are constructed on-the-fly. The first two insns write to the code segment. Fun stuff like that
<cr1901_modern>
I am about to cheat and run dosbox-debug for this
<whitequark>
huh
<andlabs>
binja?
<andlabs>
is that another disassembler?
<cr1901_modern>
Binary Ninja, and yes
<andlabs>
neat
<andlabs>
lots of disassemblers now
<cr1901_modern>
The first two insns are: "mov dx, 0x28e0;", then "mov word [cs:0x260], dx"
<cr1901_modern>
And sure enough at offset 0x260 in the code segment, there's two bytes of zeroes to be filled in
<cr1901_modern>
Anyways I'm having so much trouble because I can't find a place _after_ the music driver starts running to force a busy-loop, so I can effectively play all music during the intro
<sorear>
i have to wonder if that's part of a relocatable code scheme (does this run on an OS?)
<cr1901_modern>
It's a large real mode DOS app
<ValleyBell>
cr1901_modern: Why are you hacking the EXE file? Can you just swap pointers in the ADL file or so?
<cr1901_modern>
The game is hardcoded to cut the music and proceed to the next track once the intro scene changes
<ValleyBell>
Is there a screen where that doesn't happen?
<cr1901_modern>
Once the game is loaded I might be able to force it
<ValleyBell>
I'd probably try to start a new game and rip music from the first static screen there.
<ValleyBell>
I don't know how easy it is to skip the intro though.
<cr1901_modern>
ESC, wait 15 seconds for the game to load :P, then it prompts you to load a file
<cr1901_modern>
Anyways, I'll do that, this is kinda silly. I got nerdsniped b/c DOS binary. It's clearly written in a way to deter ppl like me from looking at it.
<cr1901_modern>
The usual tricks like using add/subs and multiple indirection to hide pointers to actual data
<whitequark>
hey, do we have any gateware model of an FM synth yet?
<cr1901_modern>
topapate on Twitter has done two- JT51 and JT12
<whitequark>
ooo
* whitequark
now has jt51.cc :)
<cr1901_modern>
hahaha, that should be interesting
<whitequark>
jt51.cc:5107:22475: fatal error: bracket nesting level exceeded maximum of 256
<whitequark>
ouch
<cr1901_modern>
I don't remember that much nesting looking at the source (it's a complex core)
<cr1901_modern>
oh... this is the generated C++
<whitequark>
indeed
<whitequark>
it turned a LUT into a ternary
<whitequark>
a very, very large ternary
* cr1901_modern
snickers
* whitequark
opens the compiled binary in binja
<whitequark>
pretty
<whitequark>
cr1901_modern: jt51 runs at almost exactly 1 MHz on cxxrtl
<cr1901_modern>
Wow ._. that's 1/4 (or 1/2, since the clk is divided by 2 immediately) of the way there
<whitequark>
it can almost certainly be improved
<whitequark>
there is a *lot* of math there, and cxxrtl translates it quite pathologically right now
<whitequark>
i picked not quite the right approach for bit vector operations
<cr1901_modern>
JT51 CXXRTL VGM core when :D?
<cr1901_modern>
VGM player emulating an FPGA core in real time to play music
<whitequark>
i mean what do you think i'm doing
<cr1901_modern>
Smoke testing CXXRTL :)
<cr1901_modern>
But that's pretty surreal tho
<whitequark>
i was going to compile it to wasm
<cr1901_modern>
Add the WASM code to the YM gateway as an option? (Note that I'm not actually sure if JT51 fits on even an ice408k)
<whitequark>
something like that
<cr1901_modern>
Oh and opened dosbox-debug and it's clear that somewhere along the lines I can't add segments/offsets together, b/c the values I'm seeing in the debugger actually point to crap that make sense.
<cr1901_modern>
ohhhh DAMNIT.
<cr1901_modern>
I've been forgetting to subtract the MZ header from all the raw address calculations I've been doing
<cr1901_modern>
THAT'S WHY nothing made sense
<ValleyBell>
I have a feeling that you're making things a lot more complicated then they should be.
<cr1901_modern>
ValleyBell: Oh no doubt. At this point I was looking into a debugger out of spite :P
<cr1901_modern>
Not because I think it'll be useful
<cr1901_modern>
It's too late to do real work anyway
<ValleyBell>
You're supposed to: 1. find a static screen where music plays (without fade in and without SFX)
<ValleyBell>
2. change all song offsets in the ADL file with the same offset (to guarantee that you play a certain song) - then save
<ValleyBell>
3. start the game and record the song from that static screen
<ValleyBell>
Point 2 could be done slightly more efficiently if you figure out, which song offset is used on the static screen.
<ValleyBell>
though I would do that by dummying out larger parts of the ADL file header at once
<ValleyBell>
(and not by disassembling the game EXE)
<cr1901_modern>
I feel like the minute I try to dummy out most of the ADL file I'm going to get a nice crash. But I'll try it
<ValleyBell>
Well, you can just "replace everything with the same song offset".
<ValleyBell>
and use one of the existing offsets from the song header
<cr1901_modern>
Ack... will do
<ValleyBell>
like ... if the first two bytes are "58 02", replace all offsets in the header with 58 02
<cr1901_modern>
It'd be nice if I didn't have to play the intro each time (lots of dead noise)
<cr1901_modern>
But I can trim that out
<ValleyBell>
You can just start logging after the intro.
<ValleyBell>
oh, btw, do you have your sound card set to OPL2?
<cr1901_modern>
Yes
<ValleyBell>
okay
<ValleyBell>
because if you have to set to SB16/OPL3, it will create OPL3 VGMs
<cr1901_modern>
Indeed, I ran into that problem yesterday
<ValleyBell>
and I'm pretty sure those Westwood games didn't use the OPL3 features
<ValleyBell>
It's the only drawback of DOSBox-VGM compared to DOSBox with DRO logs: for DRO you can switch between OPL2 and OPL3 by setting a single header byte
<cr1901_modern>
DOSBox-VGM also doesn't log based on exe
<ValleyBell>
and thus you can keep note of whether OPL2 or OPL3 is being used while logging and fix the header afterwards
<cr1901_modern>
while DRO does
<ValleyBell>
umm... it doesn't?
<cr1901_modern>
Not in my testing
<ValleyBell>
I guess I have to test this.
<ValleyBell>
Maybe it does and you're just starting logging before loading the exe?
<ValleyBell>
DOSBox-VGM doesn't wait for the first note to play.
<ValleyBell>
it just immediately starts logging
<ValleyBell>
which, IMO, is good, as the "start with first note" detection in DOSBox used to be buggy and miss rhythm sounds
<cr1901_modern>
Hmmm, well the DRO logging will create a dosbox_*.DRO, and then when I switch to e.g. RDOSPLAY, it creates an rdosplay_*.DRO log as well
<ValleyBell>
Oh, so it restarts logging when switching between executables.
<ValleyBell>
I didn't notice that before.
<cr1901_modern>
The VGM logging won't create the latter- when I start the logging at the DOSbox prompt, it keeps logging at the same file
<ValleyBell>
actually... that might be a DOSBox-X exclusive feature or so.
<ValleyBell>
I'm pretty sure the original DOSBox doesn't do that.
<cr1901_modern>
Oh, it's possible. I need the networking emulation, and since the HAL-9000 builds are LONG unmaintained, I switched to DOSBOX-X
<ValleyBell>
The "original" DOSBox generates the log's file name based on the currently running exectable and keeps logging to that file until you stop it manually.
<ValleyBell>
It never auto-restarts the log.
<ValleyBell>
I think I would also find that very annoying
<ValleyBell>
since there are some games that change executables when switching between levels.
<cr1901_modern>
Well, it was convenient for me b/c it meant "free trimming"
<cr1901_modern>
ahhh
<ValleyBell>
If you have 2 seconds of silence at the beginning, you can have free trimming by dropping the VGM on "vgm_sptd".
<ValleyBell>
(sptd = SPliT on Delay)
<cr1901_modern>
...
<cr1901_modern>
why did you wait to tell me this :P?
<ValleyBell>
i.e. it splits when there are no commands sent for more than 1 second (or whatever number of samples to tell the program)
<ValleyBell>
However this can go very wrong when there are long chords without any software envelopes.
<ValleyBell>
I mostly use this for logs where I record multiple songs into 1 VGM, each with 2-5 seconds of silence in between.
<cr1901_modern>
whitequark: Have you seen an error like this yet? http://ix.io/2J6u
<cr1901_modern>
gcc version 9.2.0
<whitequark>
turn off TCL
<cr1901_modern>
No change. Anything else I should remove? http://ix.io/2J6v
<cr1901_modern>
(sccache has no effect)
<whitequark>
oh wait
<whitequark>
windows, right?
<whitequark>
it #defines CONST to mean something
<whitequark>
probablyh uh... const... because who needs keywords...
<cr1901_modern>
#ifdef CONST
<cr1901_modern>
#undef CONST
<cr1901_modern>
#endif
<cr1901_modern>
^Yes, that was horrible but it worked :P
<whitequark>
lemme extract some VGM and stuff it into the model...
<cr1901_modern>
ERROR: Assert `arg->is_signed == sig.as_wire()->is_signed' failed in frontends/ast/genrtlil.cc:1737. (I will minimize this soon.) Swapping to Linux
<whitequark>
cr1901_modern: that's a bug in yosys head
<sorear>
"minerva at 2MHz" "YM2151 at 20% of real time speed" does the sound synthesizer need to run at >10MHz for some reason, or is it a much larger design / a much worse case for cxxrtl?
<whitequark>
it's a bit of everything
<whitequark>
ym2151 definitely does trigger some pathological cases in cxxrtl
<whitequark>
at the same time, iirc it has a clock divider right at the start?
superctr_ has quit [Ping timeout: 256 seconds]
<andlabs>
I was the only bidder on a copy of Thunder Force II but the X68000 system disks are undergoing a bidding war what garbage is this
<Sarayan>
wq: yeah, the fm chips have a divide by something between 4 and 8 at the start, sometimes a different divide for the psg part when there's one (there isn't in the 2151)
superctr has joined ##yamahasynths
<andlabs>
yep, already outbid, and because this has Automatic Extension this is going to be the world's most drawn out bidding war
<andlabs>
I'm not going above 25000 yen
<andlabs>
which is $250
<andlabs>
why the fuck are ***SYSTEM DISKS*** worth that much
<whitequark>
Sarayan: looks like 2151 divides by 2 for most (all?) components
<Sarayan>
Then maybe 2 :-)
<Sarayan>
it's a bunch of rotating pipelines, it's a funky structure
<andlabs>
also for context, Automatic Extension means every time I'm outbid the auction end time gets reset to "10 minutes from now"
<andlabs>
I'll be honest
<andlabs>
I don't really feel comfortable trying to do that whole jerry-rigging individual pins thing for the glasgow, because I'd have to do it each time I change drives and what not
<andlabs>
and I also can't solder so I wouldn't know how to make my own wires for it
<andlabs>
unless there are solder-free cable ends I can use like for DE-9...
<whitequark>
andlabs: yeah individual pins are error prone
<whitequark>
i crimped a cable
<whitequark>
no soldering
<andlabs>
hm?
<andlabs>
which cable
<andlabs>
also
<andlabs>
well I upped to 30000 and I won at 26600
<andlabs>
if these things arrive and it turns out they come from a smoker I swear to god
<andlabs>
also I'll calm down now
<andlabs>
whitequark: so what cables exist that have the different number of pins on either end?
<whitequark>
andlabs: ok so what i did was to use off the shelf IDC connectors and an IDE cable i had around
<whitequark>
wait, no, it must have been an actual floppy cable
<whitequark>
yeah, it is
<whitequark>
basically the idea is to take a normal PC floppy cable, cut off one end, and crimp connectors compatible with Glasgow after splitting it in 2
<whitequark>
the pin layout is actually surprisingly compatible all things considered, and you do not need to solder
<whitequark>
not even a crimp tool if you don't have one
<andlabs>
do you have any part numbers I can look up?
<whitequark>
yes, moment
<whitequark>
andlabs: TE Connectivity 1658622-4
<andlabs>
k
<andlabs>
ok
<cr1901_modern>
sorear: In my case, 20% is not quite a fair comparison, b/c I'm using older hardware
<cr1901_modern>
But FM synths are math-heavy even with doing everything in exp-space to avoid multiplies, and the FM synths are pipelined (32 slots for YM2151- 8 channels, 4 operators per channel).
<whitequark>
cr1901_modern: no i actually get exactly 20% realtime on coffeelake refresh
<whitequark>
or maybe not refresh? doesn't matter, intel cpus haven't changed for like five generations
<cr1901_modern>
oh, interesting. :D
<andlabs>
I ask again
<andlabs>
what is intel chip naming
<andlabs>
"coffee lake"
<whitequark>
andlabs: afaik the reason they use weird geographical sounding names is to eliminate any possibility of trademark issues
<whitequark>
either accidentally picking someone's name, or letting someone else pick theirs maliciously
<andlabs>
that makes sense but they have to know it sounds silly
<whitequark>
you can't really argue with that i think, if there is one property intel codenames have, blandness is definitely it
<whitequark>
oh, does it?
<whitequark>
to me it sounds extremely enterprisey
<whitequark>
but i may have been just conditioned by the industry to expect that heh
<whitequark>
cr1901_modern: i suspect perf is bottlenecked by some particularly egregious cxxrtl codegen bits
<whitequark>
maybe that genius way of translating the LUT as a perfectly unbalanced binary tree of ?: operators
<andlabs>
no I mean "coffee lake" specifically =P
<andlabs>
I mean sure I'll drink out of a coffee lake like a jungle animal
<whitequark>
andlabs: that just sounds like run of the mill weird american name to me
<whitequark>
there was like... Paradise, CA?
<whitequark>
now *that* sounds ridiculous
<cr1901_modern>
Super Dimension Fortress Coffee Lake
<andlabs>
heh
<cr1901_modern>
whitequark: At least it's a good test case, because it triggers said pathological behavior
<cr1901_modern>
The fact that it's an FM synth core is a bonus :P
<whitequark>
cr1901_modern: it's a bit of double edged case
<whitequark>
on one hand, yes. on the other, no other netlist i looked at was remotely like what comes out of yosys when it eats jt51
<whitequark>
like a tenth of the generated code looks like it's doing matrix transposition in the singular least efficient way
emeb has joined ##yamahasynths
Lofty has quit [Remote host closed the connection]
ZirconiumX has joined ##yamahasynths
ZirconiumX is now known as Lofty
<cr1901_modern>
https://youtu.be/htmZVXz4yg8?t=68 Hmmm, the prototype warp _sounds_ like pure FM synth (and sounds cooler, IMO). The final warp sounds like a mix of samples and FM synth. >>
<cr1901_modern>
Since the sampler chip and FM synth are under control of two different CPUs, are coordinating them to play a single track "best effort"?
<superctr>
Game Arts managed to do that in their games (Silpheed, Urusei Yatsura)
<cr1901_modern>
Ahhh, well one or two cycles jitter due to the CPUs not being async isn't going to matter
<cr1901_modern>
Thought maybe there was One Weird Trick to synchronize them exact
<superctr>
i think the final version of Sonic CD's warp sound is entirely redbook. A bit strange considering they were supposed to have used the warp sequence to load from the disc but whatever
<superctr>
actually no
<superctr>
The final version _does_ use entirely FM sound effects
<superctr>
but they kept the old version on the disc