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
<cr1901_modern>
nukeykt: 0x3D0900, so 4 MHz
<cr1901_modern>
But the pitch in your .ogg file is correct
<cr1901_modern>
If something between your core and the .ogg output was using 3.57 MHz, since the keycode regs were set assuming a 4MHz clk, I would expect the pitch to be altered
<nukeykt>
yeah, but I used 55930 as sound rate in vgmplay, thus output is resampled
<whitequark>
this reminds me
<whitequark>
i will possibly need to do something about rates in the web interface
<whitequark>
since iirc it will resample everything on the server at the moment
<whitequark>
anyway let me bring it up first
<cr1901_modern>
Tbh, I didn't know vgmplay accepted anything except 44100 Hz as output (or I since forgot). Do sound cards let you set weird sample freqs like that nowadays?
<cr1901_modern>
whitequark: Yea, changing the sample rate on the server would be useful for looking at raw output (if server ample rate == chip sample rate, no resampling needed). But Idk how it would be useful for listening purposes
<whitequark>
yes i mean for looking at raw output
<nukeykt>
reuploaded oggs with proper sample rate
<whitequark>
oh jesus christ
<whitequark>
i just looked at the code i had
<whitequark>
nevermind, i resample on the client
<whitequark>
but the way in which i do is *horrifying*
<whitequark>
wow
<whitequark>
wow this is so bad. i forgot how bad web audio was
<cr1901_modern>
Is this related to webaudio being braindead until a few weeks ago?
<whitequark>
// WebAudio API is designed by idiots and does not provide any way to keep resampler state
<whitequark>
// between buffers, so we have to approximate it ourselves, by sandwiching the samples we're
<whitequark>
// interested in between their preceding and following samples, and then cutting them out
<whitequark>
// after the resampler finishes.
* whitequark
stares
<whitequark>
i remember now, i even tried compiling libresample into wasm
<whitequark>
and i got a megabyte of wasm because it precomputes all the filter coefficients
<whitequark>
and stuffs them into a massive static float array
<whitequark>
ok let's just not look at this any more than is necessary
<cr1901_modern>
I am sorry I accidentally made you remember that :P
<whitequark>
cr1901_modern: bottom line: the WAVs will have the original chip sample rate
<whitequark>
or rather VGM sample rate because the chips are fully synchronous anyway
<cr1901_modern>
>The WAVs will have the original chip sample rate
<cr1901_modern>
I seem to vaguely recall this now, since you resample on the client
<cr1901_modern>
(But playing the actual song sounds correct, and I seem to recall you can save that as well)
<whitequark>
okay, i got the OPM pinout wrong
<cr1901_modern>
nukeykt: Drums sound a lot better to me
<cr1901_modern>
I know OPM worked in the past, because I remember playing at least one VGM on it.
<whitequark>
yes
<whitequark>
i connect it with breadboard wires
<whitequark>
and every time i do i get it wrong
<whitequark>
sometimes several times in a row
<nukeykt>
cr1901_modern after setting correct rate you mean?
<whitequark>
specifically i think i got the clocking wrong somehow
<cr1901_modern>
nukeykt: yes
<cr1901_modern>
there's two clock pins. One of them is the clk input, the other is an output that drives the DAC (or the FPGA in your case)
<whitequark>
yeah i know
<whitequark>
it's just that i connected them wrong somehow
<cr1901_modern>
Does initial clear need to be asserted first? I forget
<whitequark>
the specific problem i'm observing is that SH1 and SH2 are both always low
<whitequark>
what gives
<whitequark>
there's ФM, Ф1, and output on SO
<whitequark>
argh
<whitequark>
got two data bus pins swapped. fixed that, no change
<nukeykt>
did you connect /ic ?
<whitequark>
yeah to vdd
<cr1901_modern>
I think it needs to be an input that goes high
<cr1901_modern>
I _guess_ vdd works tho... not sure I ever tried it
<whitequark>
i've never had explicit /ic in glasgow
<whitequark>
for pin count reasons mostly
<whitequark>
i might have to add that for you though
<whitequark>
nvm there is signal on sh
<cr1901_modern>
You didn't accidentally connect /ic to GND did you?
<whitequark>
no, i had a weird trigger configured on my scope
<whitequark>
hmm
<whitequark>
i'm getting fairly reasonable waveforms on LA
<whitequark>
one moment, let me bisect the glasgow commit that kinda breaks usb
<cr1901_modern>
ack
<cr1901_modern>
nukeykt, superctr__: Gateway is ready, once USB stuff is fixed, I'll generate two wav files of raw output. These wav files will be sampled for a chip running at 4MHz (so 62,500 Hz). >>
<cr1901_modern>
If you want something pleasant to listen to on actual sound cards, resample the wavs to your desired sample rate
<whitequark>
just $ play x.wav works
<cr1901_modern>
or that (TIL)
<cr1901_modern>
whitequark: Lemme know when you're done bisecting
<cr1901_modern>
Correctly refuses to play the unpatched VGM file with "does not support OKI chip"
<whitequark>
where's the spec again...
<whitequark>
VGM commands 0x90 to 0x95 specify writes to the DAC Stream Control Driver. These are used to stream data from data blocks to the chips via chip writes.
<whitequark>
are you using this?
<whitequark>
and if yes wtf does that do
<cr1901_modern>
Not intentionally
<cr1901_modern>
cc: superctr__ Any ideas?
<whitequark>
let me make it show byte offset
<whitequark>
cr1901_modern: can you upload it again?
<whitequark>
it's kinda hard to show you a nice error for architecture reasons but i can at least look it up in the console
<cr1901_modern>
Done
<whitequark>
NotImplementedError: Unknown VGM command 0x90 at file offset 275
<whitequark>
actually hold on, can you give me the file? I'll make it show errors nicely
<cr1901_modern>
Indeed, there's a 0x90 byte at 274 (sic)
<whitequark>
cr1901_modern: what does okim6528 do anyway
<cr1901_modern>
It's a PCM chip
<whitequark>
is it simple
<cr1901_modern>
Meant to augment the YM2151 with samples. Similar to the Ricoh RF5C68 on the Sega CD augmenting the YM2612
<cr1901_modern>
I don't know
<whitequark>
Your search - okim6528 datasheet - did not match any documents
<whitequark>
well that is not encouraging lmao
<cr1901_modern>
Oh I have trouble finding them for sale by themselves
<whitequark>
i was wondering if maybe i could stuff a model of that into the gateware
<whitequark>
or software for that matter
<whitequark>
stuff it somewhere the sun doesn't shine basically, so people can play ym2151+okim6528 vgms
<cr1901_modern>
Well, for comparisons: the RF5C68 PCM chip is a very simple chip. I've meant to buy a dead Sega CD to scavenge one for timing analysis, simple as it is. So I would GUESS that OKI isn't much too complex
<cr1901_modern>
cc: Lord_Nightmare if you're around
<nukeykt>
don't hear any noticeable difference between real chip and emu
<whitequark>
nukeykt: is it the same bitstream and if no can we fix that?
<whitequark>
cr1901_modern: oh, 6258, not 6528
<nukeykt>
hmm, real chip sample plays a bit faster than vgmplay output
<cr1901_modern>
Have you hooked your core into vgmplay?
<cr1901_modern>
(or is this the MAME core?)
<nukeykt>
yeah, my core. I use it as testbench
<whitequark>
verilated or?
<cr1901_modern>
It's a C core
<whitequark>
ohh right
<cr1901_modern>
whitequark: > and if no can we fix that?
<cr1901_modern>
The counters would need to be sync'ed up. Idk if /IC resets global counters. It should be possible to figure out the global counter state tho
<whitequark>
alrighty
<whitequark>
well just tell me what to hook up and i can do it
<cr1901_modern>
I don't know _exactly_ how to do this offhand. I will give it some thought.
<nukeykt>
IC should clear everything afaik
<whitequark>
there's no reset register, right?
<nukeykt>
yeah
<cr1901_modern>
If /IC _doesn't_ clear everything, one could gleam at least the decay counter by playing a test signal that decays very slowly and seeing when the amplitude decreases by "1" unit. Like I assume there's tricks you can do to suss that info out.
<cr1901_modern>
(the decay table is periodic)
<cr1901_modern>
whitequark: >oh, 6258, not 6528
<cr1901_modern>
You found a datasheet? Also did the gateway go down?
<whitequark>
cr1901_modern: currently testing reproducibility with /IC
<cr1901_modern>
cool
<whitequark>
cr1901_modern: nukeykt: i get 100% reproducible bitstream with /IC
<cr1901_modern>
Nice!
<nukeykt>
whitequark: Is your vgm player code available?
<cr1901_modern>
whitequark: You should like this one too... either that or say "WTF?!" :P
<cr1901_modern>
(in the good way)
<nukeykt>
whitequark: thanks for the offer, I've read github page a bit, and it seems to be interesting
<whitequark>
nukeykt: yup. it is built to drive the maximum possible amount of electronics without requiring any sort of intermediate circuitry except wires
<whitequark>
indeed you can connect any standalone synth to it with just that
<whitequark>
or a floppy
<whitequark>
yes, it does have true TTL I/O if you configure it for 5 V. still does 1.8 V at the same time.
<whitequark>
the main obstacle to using it with retro tech still is that it doesn't have that many pins, so i fully reverse-engineered ATF15xx CPLD fuse map to turn them into pin expanders
<myon98>
Sorry about the joining I had things misconfigured for a sec
<myon98>
cr1901_modern: Yeah that is me but don't mind that twitter account because it's mostly dead at this point lol
<cr1901_modern>
No worries, IRC is dodgy. And ack re: acct. I just remembered your name from somewhere but couldn't remember if I saw you in here before
<ZrX-NoMs>
the owner had taped that 8" to a wall for yeaes.
<ZrX-NoMs>
years
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 260 seconds]
<ValleyBell>
cr1901_modern: VGMPlay adjusts the overall volume based on the amount of sound chips used by the VGM.
<ValleyBell>
It tries to go for a volume level that sounds good with *most* VGMs.
<cr1901_modern>
It started clipping a bit when I removed the OKI chip. I didn't like it :P
<ValleyBell>
which in case of the YM2151 means, that it can clip
<ValleyBell>
The YM2151 can play up to -2.0 .. +2.0 when VGMPlay covers +- 1.0.
<ValleyBell>
You can make up for this using the "volume gain" byte in the VGM header.
<ValleyBell>
It's at offset 0x7C. Value 0 = 0db, value 0x20 = +6 db (200%), value 0x40 = +12 db (400%), value 0xE0 = -6 db (50%)
<ValleyBell>
The range is 0xC1 (-12 db / 25%) ... 0x00 (100%) .. 0xC0 (+36 db)
<ValleyBell>
(Yes, I chose a weird range. Some OPL VGMs needed a very high volume gain.)
<cr1901_modern>
where does 2.0 come from?
<ValleyBell>
The sound core's signal is +- 8192 per channel, you have 8 channels = +-65536.
<ValleyBell>
That's 2x the signed 16-bit range +-32768.
<ValleyBell>
The YM2612 outputs +- 8192 with 6 channels, so it may clip, but the chance is lower.
<cr1901_modern>
ahh hrm
<ValleyBell>
(also, most songs don't use maximum volume on all channels)
<cr1901_modern>
This was an auto-generated VGM
<ValleyBell>
doesn't matter
<ValleyBell>
it matters what the composer did
<ValleyBell>
When the composer uses lower attenuation levels, it won't clip.
<cr1901_modern>
it looks like they somehow disassembled an MDX driver, emulate all the 68k code, and then every time a write to the chip occurs it dumps to a VGM
<ValleyBell>
When the composer insists on making everything as loud as possible, it clips by default.
<superctr__>
<ValleyBell> The YM2612 outputs +- 8192 with 6 channels, so it may clip, but the chance is lower. <- isn't it supposed to be +-256...
<superctr__>
Or maybe you've already multiplied the signal, in which case nevermind
<superctr__>
the best would be to somehow measure the signal voltage and impedance of every sound chip / DAC and then simulate a typical analog frontend for each of them. But that would require a lot of research... Not even MAME has that fully documented
<cr1901_modern>
ValleyBell: Thanks for the info. My head hurts now, so I'll mull this over while I try to sleep lmao
<Xyz39808>
basically, edit the volume gain byte and no more questions
<Xyz39808>
btw who tf is karinto, or rather, whose site is all these g0org backups on?
<cr1901_modern>
I have no idea... I found the site while trying to get more information on an MP3 by Utabi (the MDX file I originally linked) in 2015
<ValleyBell>
+-8192 is the "final" signal after all envelope and volume multiplications
<superctr__>
YM2612 has a 9-bit DAC though
<superctr__>
So all the lower bits of the envelope and phase output should be truncated
<superctr__>
though, I suppose, the NukedOPN2 core just sums and filters the average output over 24 cycles to emulate the DAC quirks, so the output is not the DAC direct out
<superctr__>
on a related note, I just tried integrating NukedOPM into QuattroPlay
<superctr__>
should be "if (!chip->eg_zr[1] && (chip->eg_clock & 2))
<superctr__>
"
<andlabs>
huh, did microsoft officially release windows 98 and 2000 for the PC-98? because that's what the neokobe archive makes it seem like
<superctr__>
yes
<andlabs>
well then
<superctr__>
I wanted to try installing it in NP21 and see how the default FM MIDI driver sounds like
<superctr__>
but never got around to doing it
<andlabs>
in b4 "requires a soundblaster"
<andlabs>
anyway win2000 requires a pentium but I could probably run win98 on the laptop I bought
superctr__ has quit [Ping timeout: 240 seconds]
Lord_Nightmare has quit [Ping timeout: 258 seconds]
<nukeykt>
superctr__: Thanks for report and for fix :) I've double checked ym2151 die and pushed fix that is a bit more "correct"
superctr has joined ##yamahasynths
Lord_Nightmare has joined ##yamahasynths
emeb has joined ##yamahasynths
<whitequark>
superctr: oh ok that's kinda complex
<whitequark>
nukeykt: i'm curious, have you tried comparing bitstreams from your core and real opm yet?
<superctr>
whitequark, I think the best would just be if you handle those chips just by skipping the appropriate number of bytes in the vgm file
<superctr>
(That way I won't have to do extensive editing to make your player accept the VGMs with extra chips lol)
<nukeykt>
whitequark: not yet, I'm thinking to build test board with real chip and perform some tests soon
<whitequark>
nukeykt: ah, so the idea behind my web interface was that you could send it a request and get waveform data
<whitequark>
i can add an endpoint that you can hit with curl or something. or not, it's not like i insist
<whitequark>
superctr: hm so the original idea was to make sure people listen to exactly what's in the vgm, which means rejecting weird vgms i can't play exactly
<whitequark>
but i can probably add it as an option
<Lord_Nightmare>
what did i miss? had a power failure here
<Lord_Nightmare>
is this about tests on the opll?
<Lord_Nightmare>
one sec
Lord_Nightmare has left ##yamahasynths [##yamahasynths]
Lord_Nightmare has joined ##yamahasynths
<Lord_Nightmare>
ah i missed just one line, nevermind
nukeykt has quit [Remote host closed the connection]
nukeykt has joined ##yamahasynths
<superctr>
whitequark, the YM2151 was very often accompanied by extra sound chips for PCM etc, I think that the tool would be more useful if if could play back those VGMs too. The extra sound chips could always be rendered and mixed separately
<superctr>
And you don't have to deal with those chips anyway, it's pretty easy for the user to do that (compared with stripping the extra chips from the VGM before uploading it)
<whitequark>
superctr: hmmm okay
<whitequark>
can you list the ones i have to implement?
<whitequark>
since i have my own VGM parser and i don't want to do *all* of them
<superctr>
basically you just have to skip the right number of bytes for certain ranges
<whitequark>
yeah i know how VGM commands work
<whitequark>
i'm just asking which chips i need to implement
<superctr>
I think the datablock (0x67) and PCM write (0x68) are the only commands you need to specifically handle. In that case you skip the length of the command + length of the datablock as specified in the command
<superctr>
For the other chips, it's 3 bytes for the ranges 0x51-0x5f and 0xa0-0xbf, 4 bytes for 0xc0-0xdf, 5 bytes for 0xe0-0xff. Including the command byte itself
<superctr>
if there are any chips in particular, I would say SegaPCM, uPD7759, MSM6295, MSM6258, GA20, K051649, K054539, C140, C352 (only for quattroplay)
<superctr>
or meant to say K053260 instead of K051649.
<whitequark>
ack
<whitequark>
i'll look into it, probably not right now
ej5 has joined ##yamahasynths
SceneCAT has joined ##yamahasynths
emeb has quit [Quit: Leaving.]
<cr1901_modern>
Foone: Oh... Pantera Bread is what you actually call it and wasn't a typo.
<Foone>
yeah.
<whitequark>
wait what
<Foone>
the bakery is called "Panera Bread", but I call it "Pantera Bread" after the 80s heavy metal band, because it amuses me. and the context was that I was ranting about their terrible website on twitter this morning
<whitequark>
oh
<cr1901_modern>
I thought it was an amusing typo- listen to "Cowboys From Hell" playing from the aether as you eat the sandwich. But it wasn't a typo :P
<Foone>
nope. just a dadjoke
<cr1901_modern>
(For the record, Panera is expensive as shit, but they make good Chipotle Chicken sandwiches)