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
<whitequark>
yeah it's been super useful for hooking up random shit to my PC and driving it
<cr1901_modern>
Once the model compare core is done, I'll likely take that and attach it to my Mercury dev board. Even if Glasgow exists, I still think board portability is important*
<cr1901_modern>
*where practical- most boards don't have a direct connection to a cypress or even an FT245
<whitequark>
most of the gateware is dealing with Glasgow stuff
<whitequark>
like there's the wire protocol
<whitequark>
I guess you could run register writes over serial
<cr1901_modern>
That was my idea
<whitequark>
yeah that'd work
<Wohali>
serial, or i2c?
<Wohali>
either or ig uess
<whitequark>
ew, i2c
<cr1901_modern>
serial... I dunno very good USB to I2C bridge
<whitequark>
who would volutarily use i2c
<Wohali>
fine, spi?
<whitequark>
sure
<Wohali>
i could have said i2s :P
<cr1901_modern>
E.g. if I want to make something really specific like "USB to ym3812" converter- I could use the "wire-protocol agnostic" part of the core, put that on FPGA, then connect that to my microcontroller of choice
<whitequark>
i2s could go the other way
<Wohali>
yes.
<Wohali>
better for audio
<cr1901_modern>
There's actually probably a market for a low cost "USB to OPL converter"
<whitequark>
hrm
<whitequark>
i mean glasgow costs only slightly more than that board
<whitequark>
so like
<whitequark>
make a small breakout PCB
<whitequark>
sell it as a bundle with glasgow? :P
<whitequark>
that board = lpt adlib
<cr1901_modern>
>that board <-- which board? Mercury?
<cr1901_modern>
I mean Glasgow bundle might work, but I was thinking something in the $30 range. Les
<cr1901_modern>
s if I can absorb the USB core into the FPGA*
<cr1901_modern>
whitequark: I want an excuse to design a single purpose board :P
<cr1901_modern>
Glasgow makes everything redundant if I try
<cr1901_modern>
DYNX86 crashes w/ "unable to execute code page" for me
<Wohali>
runs here
<cr1901_modern>
my dosbox must be too old
<Wohali>
i dont' have a ROM to run in it but it runs and the mneu works and drips
<cr1901_modern>
I use an old build b/c they _still_ won't add ethernet support into the main SVN tree *grumbles*
<cr1901_modern>
Wohali: That's fine. That's further than I get
<Wohali>
ethernet support as in tcpip? i see emulated serial-over-internet support
<Wohali>
and ipx
<Wohali>
you probably mean native ne2000 or 3c509 or similar
<cr1901_modern>
yes ne2000 support is what I meant
<cr1901_modern>
I want ethernet support explicitly for testing mTCP-based applications I sometimes write network code for DOS
<cr1901_modern>
although recently I've been writing code for wq on her DOS laptop... and we have a system where I access the laptop via CTTY COM1
<cr1901_modern>
and I use netcat to xfer my binaries
<cr1901_modern>
since it's not a telnet connection I'm free to use nc to xfer my binaries _and_ still test network code I wrote on a vintage machine
<cr1901_modern>
it's not a bad setup
<cr1901_modern>
whitequark: You've played Sanic 3, right?
<cr1901_modern>
and remember the music*
<cr1901_modern>
it's the only Sanic ROM I have on hand, so I'm gonna record music from it
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
<Lord_Nightmare>
whitequark: all tests pass
<Lord_Nightmare>
i'm sort of torn, although if we get the hd6301Y0 code out it would be possible to burn it to a blank chip and 'fix' the cannibalized unit
<cr1901_modern>
whitequark: Okay at present, OPN to OPL conversion is not possible; dro2vgm (DOSBOX to VGM converter) writes OPL3 commands as output
<cr1901_modern>
I contacted the person who wrote dro2vgm and am waiting to hear back
<cr1901_modern>
OPN to OPL2 conversion*
<mad>
cr1901_modern : how would you do the 4op patches?
<cr1901_modern>
mad: Checking something...
<cr1901_modern>
mad: The answer is "I don't", but I'm not certain whether Genecyst is emitting OPL3 commands or OPL2 compatible commands
<cr1901_modern>
yea it's OPL3 :(
<cr1901_modern>
ahhh well, it was worth a shot
<mad>
yeah I'm not surprised... opl2 is kinda far from doing the kinda stuff needed to be opn2 compatible
<cr1901_modern>
Basically, I bought this board, it doesn't work (it sounds awful). I remember linking this board in here and you critiquing it. Maybe your insight will help me debug why THE OUTPUT IS HORRIFICALLY CLIPPING EVEN when at low volume
<cr1901_modern>
Is LM386 known to be a bad amp
<ej5>
remove C5
<cr1901_modern>
doing now
<cr1901_modern>
of course the damn wick isn't working
<cr1901_modern>
still clipping badly
<cr1901_modern>
thinking of hooking up a jack directly to the DAC output
<ej5>
short pin 2 of IC4 to ground
<ej5>
hmm, also short across C9
<ej5>
C5 could have been causing the op amp to be unstable which would create oscillation
<cr1901_modern>
doing c9 first
<ej5>
yeah one at a time is fine
<ej5>
think the lm386 is what's causing the distortion
<ej5>
if you have a scope you could check the raw dac output
<cr1901_modern>
I don't have a scope :(
<cr1901_modern>
and I don't have a fast enough ADC to make one from FPGA
<cr1901_modern>
all the dev board ones are barely 100khz
<ej5>
remove c9, then wire the LM358 output up to some powered speakers?
<cr1901_modern>
that might work, as I am using headphones
<mofh>
Yuck, LM386
<mofh>
Yeah, that's likely going to cause distortion, bypass it if you can or replace with an op-amp that's not godawful.
<Wohali>
LM386 isn't even really an op-amp :P
<Wohali>
i bet a 741 would sound better :P
<Wohali>
but since you don't have a bipolar power supply...optoins are limited
<ej5>
chances are the supply rail doesn't give it enough headroom
<Wohali>
normally you'd run it off of more than +5, yeah
<ej5>
might be distorting because the volume is too high XD
<cr1901_modern>
I already managed to misplace c5
<cr1901_modern>
looking for that now
_whitelogger has joined ##yamahasynths
<mofh>
Wohali: hey the 741 actually makes a passable instrumentation op-amp in certain very restricted conditions :p
<Wohali>
sure!
<Wohali>
was mostly poking fun at the purists who insist on reproducing e.g. guitar pedals with ancient chips
<Wohali>
not that this channel would know anything about the charm of working with somewhat restricted chips :P
<cr1901_modern>
nope not at all... f*** all old chips and recycle them back into ingots :)
<cr1901_modern>
yea I'm not getting any sound output. W/o an oscilloscope (still too expensive and bulky) or LA (broke mine a few weeks ago), my debugging options are limited
<cr1901_modern>
bypassed the lm358 too... still sounds fucky
<cr1901_modern>
wonder if the DAC is bad
<cr1901_modern>
or the power supply is too noisy
<ej5>
yeah the power supply isn't filtered at all and very poorly bypassed
<cr1901_modern>
when I switch computers I still have the same problem
<cr1901_modern>
I wonder if the current draw of arduino and that board is too much
<ej5>
could be, you try powering the arduino with a wall wart?
<cr1901_modern>
I don't have one that fits an arduino. I'll try a USB breakout board to get an extra 500 mA tomorrow
<cr1901_modern>
Also I'm still pissed I lost c5... I'm gonna pay more for damn shipping just to replace a single cap!
<cr1901_modern>
Idk if I have one of the right voltage rating and arrrrrgh
<ej5>
c5 shouldn't be in that circuit anyway
<ej5>
it's destabilizing that op amp for sure
<cr1901_modern>
oh... well then why would one put it there?
<cr1901_modern>
what's the _intended_ rationale versus what's actually happening
<Lord_Nightmare>
was c5 a surfacemount cap?
<Lord_Nightmare>
is it on the soldering iron?
<Lord_Nightmare>
like, stuck to it
<cr1901_modern>
Thru hole ceramic
<Lord_Nightmare>
wait so how the heck could it have vanished?
<ej5>
probably tried to filter the output of the op amp
<Lord_Nightmare>
check your shoes and pants cuffs
<cr1901_modern>
Lord_Nightmare: I DON'T KNOW!
<Lord_Nightmare>
i had a resistor end up in pants cuffs once, took half an hour to find
<Lord_Nightmare>
and i lost a 74xx chip which ended up stuck, pins-up, in the bottom of my shoe
<cr1901_modern>
ej5: Maybe I'm having hard time visualizing it, but a single 10uF cap seems like it would be extreme to make the phase margin of the lm358 part negative
<Lord_Nightmare>
cr1901_modern: also retrace everywhere you've walked, i lost a component which ended up tracked into another room and on the floor there
<ej5>
most op amps can't tolerate even 1/10th of that tied directly to the output
<cr1901_modern>
but c5 isn't on the output of the lm358
<Lord_Nightmare>
also cr1901_modern do not ever power the arduino from both the usb port AND the 5v port simultaneously
<Lord_Nightmare>
you will have the two power supplies fight each other and may blow the usb fuse on the arduino
<Lord_Nightmare>
5v port being the barrel connector
<ej5>
schematic shows c5 going from ic3 pin 6/7 to ground, where pin 6 is in2- and pin 7 is out2.
<Lord_Nightmare>
if the usb connection is not powerful enough to drive the arduino, you will need to use a powered USB hub in between the computer and the device
<ej5>
unless the schematic doesn't match your board.
<cr1901_modern>
ej5: RB input is "high precision 1/2 Vdd voltage generated by ym3014"
<Lord_Nightmare>
the barrel connector is really meant for if you've already programmed the arduino as an external device and it isn't connected to a host anymore
<ej5>
correct, that's filtered by C4, which is just fine.
<cr1901_modern>
MP output is a bias that feeds back into the DAC
<ej5>
RB goes to pin 5 which is IN2+
<cr1901_modern>
which is used to generate the actual DAC output
<ej5>
the usual opl2 schematics have the 10uf filter cap on RB, then run it through the voltage follower op amp into MP
<cr1901_modern>
Took me more time than I'd like to realize MP was an output
<ej5>
also C5 should be a 10uf cap, is that what it was?
<cr1901_modern>
don't remember reading the label before I lost it
<ej5>
and MP is an input.
<cr1901_modern>
ej5: Yes, sorry. I was talking from the POV of the op amp
<cr1901_modern>
it is an output from op amp's POV
<ej5>
ok
<cr1901_modern>
that feeds into DAC input
<cr1901_modern>
Didn't find the cap, but I _did_ find my presumed-missing third YM2151 :)
<cr1901_modern>
ej5: Actually... if the buffer is a voltage follower, why wouldn't one just connect RB to MP directly?
<cr1901_modern>
Does the cap on RB really do that much?
<ej5>
RB probably can't source enough current
<cr1901_modern>
oh right, voltage follower is "common collector" of op amps
<cr1901_modern>
no V gain, lots of I gain
<cr1901_modern>
>ej5: also C5 should be a 10uf cap, is that what it was?
<cr1901_modern>
Were you meaning to ask about C4 (which _should_ be present on the schematic- and I have it still on my board)?
<cr1901_modern>
I'm gonna call it quits looking for c5 tonight LOL.
<cr1901_modern>
well I called it quits 30 mins ago
<whitequark>
Lord_Nightmare: so, you mentioned ontwitter that ym3812 application manual has never been found and scanned
<whitequark>
i was not aware of it, which is why i found it somewhere on the web
<whitequark>
absolutely no idea where
<whitequark>
but that's where the floating point decoding table comes from
<whitequark>
cr1901_modern: your "zero_wing.vgz" file is really strange
<whitequark>
it looks like it doesn't fully init the OPL2
<whitequark>
I get glitches at the start and the whole track sounds different depending on what was playing before
<whitequark>
and resetting every register to 0x00 at start makes it even weirder
<whitequark>
cr1901_modern: it works much better if i don't reset *every* register to 0x00, but every *defined* register
<whitequark>
still kind of weird tho
<whitequark>
but maybe I'm just accustomed to broken rendering
<cr1901_modern>
hmmm
<cr1901_modern>
strange... it worked fine (for some metric of fine- my board has always been busted) on my OPL2 board. That zero wing file was provided as a test file
<cr1901_modern>
I'll try it in vgmplay and see what happens
<whitequark>
cr1901_modern: compare the current rendering with vgmplay
<whitequark>
i think it is repeatable now
<cr1901_modern>
submitted
<cr1901_modern>
<html><head><title>500 Internal Server Error</title></head><body><h1>500 Internal Server Error</h1>Server got itself in trouble</body></html>
<whitequark>
it needs queues because FPGA has to be serviced really really quickly
<whitequark>
and you have to arm USB buffers in Python
<whitequark>
>Also, why does one await on a future that's already done
<whitequark>
if you didn't await on a future but it finished with an exception, that exception will not be reraised
<whitequark>
you have to add an explicit "synchronization point"
<cr1901_modern>
ahhh okay
<cr1901_modern>
>it needs queues because FPGA has to be serviced really really quickly <-- so the main functional change is that you add queues between each logical step that can be filled up/drained at different rates, instead of doing everything in a linear sequence?
<whitequark>
yes
<whitequark>
well, it has explicit queues exposed to asyncio
<whitequark>
as opposed to implicit queues that are just python arrays somewhere
<whitequark>
and usb buffers
<whitequark>
when asyncio can use that for scheduling it works much better
<cr1901_modern>
I need to finish reading that medium article that one python dev did on "async for idiots"
<whitequark>
asyncio is actually great
<whitequark>
it allowed me to handle concurrent connections effortlessly
<cr1901_modern>
Which files would be the proper place to find the code that actually starts the event loop for a given applet?
<whitequark>
glasgow.cli
<whitequark>
in the very end
<whitequark>
it's not for a given applet. the entire glasgow software is based on asyncio
<cr1901_modern>
I know, I said my question wrong :P
<whitequark>
cr1901_modern: i am really annoyed about VGM
<cr1901_modern>
You would not be the only one, though I imagine for different reasons
<whitequark>
it should let me position commands at exact master clock cycles
<whitequark>
at *least* it should let me specify a timebase
<cr1901_modern>
that's not what the format is meant for though
<whitequark>
which would be an integer divisor of all the chip frequencies
<whitequark>
so?
<whitequark>
it's meant for precise representation of music
<whitequark>
and right now it's... ambiguous
<whitequark>
because i have to convert delays from one samplerate to another
<whitequark>
this is dumb
<cr1901_modern>
Musicians didn't give a crap about exact timing when they wrote their pieces 20-30 years ago
<whitequark>
you could have solved this with ONE field
<cr1901_modern>
only the REs have to care
<whitequark>
VGM is not a format musicians use, is it?
<cr1901_modern>
no
<cr1901_modern>
and that leads into my own gripe about VGM
<whitequark>
so why would that matter? it's a format by RE people for RE people
<whitequark>
which would prob explain why it's so bad
<cr1901_modern>
VGM should be a format for musicians IMO. There should be a better format for REs
<whitequark>
mhm
<whitequark>
but you could do both by just
<whitequark>
adding a field for the timebase
<whitequark>
this is utterly trivial to do
<cr1901_modern>
Anyways, you might've noticed that SNES music is notably missing from the VGM spec
<whitequark>
what chip does SNES use?
<whitequark>
and lmao no i haven't noticed
<cr1901_modern>
Sony SPC700. It's a chip for samples
<whitequark>
i didn't even remember SNES exists until you mentioned
<cr1901_modern>
there's a reason for that- they haven't figured out a good way to repr SNES music that doesn't boil down to "emulate the whole damn 6502 dedicated to controlling the SPC700."
<cr1901_modern>
this includes including the 6502 program that controls the sound chip
<cr1901_modern>
I would've rather, for music/preservation purposes, that VGM was a format like that
<cr1901_modern>
but of course it's a lot more effort then "just record all the writes to the chip"
<cr1901_modern>
(most consoles from this era have a dedicated CPU for sound- z80, 8085, 6502)
<cr1901_modern>
> "emulate the whole damn 6502 dedicated to controlling the SPC700." <-- yea I fucked up here (SPC700 _is_ the CPU. I forget the sound chip's actual name)
<cr1901_modern>
It's a "me-too 6502", so I use them interchangeably
<whitequark>
huh
<cr1901_modern>
If you get a SNES sound file, you'll get the spc700/6502 program code embedded into the file that an emulated 6502 is supposed to run, along with some extra data that tells the CPU where to start; all the samples required to play the song will be stored in that file too.
<cr1901_modern>
And for composing/playing music, you're probably going to be sync'd to vblank (60 Hz/50 Hz) before doing your next _set of_ chip writes. With exceptions of course.
<cr1901_modern>
(You can make the YM3812 play sampled music by deeply abusing it)
<cr1901_modern>
(I'll try to explain YM3812 sampling if you want. Or you can wait for Lord_Nightmare to explain it since he can do it better than I can)
<whitequark>
i assume it involves setting up ADSR so that you can use the additive mode to produce specific output levels
<cr1901_modern>
nope! I have no idea if what you're describing works tho :P.
<whitequark>
wtf how does it work then
<cr1901_modern>
The idea is that if the frequency of a YM3812 operator is set to 0, the amplitude of the output operator is "frozen to the last value it took before the channel was disabled".
<cr1901_modern>
You can time writes such that you disable the operator when the amplitude reaches its peak value
<whitequark>
that's kind dof what i meant, actually
<whitequark>
well, same concept
<cr1901_modern>
okay fair
<cr1901_modern>
you can then spam writes to change the "Total Level" of the output (separate from ADSR). Those calculations still apply if a channel is disabled
<whitequark>
ahhhh
<whitequark>
yeah
<cr1901_modern>
it's of course a horrible idea, but it's the 80s. Any horrible idea is fair game
<whitequark>
seems reasonable to me
<whitequark>
it would be easier if it like... had a register... where you could put samples...
<whitequark>
did they run out of metal or something?
<cr1901_modern>
the Genesis sound chip allows you to do that
<cr1901_modern>
But notably, only one channel (I forget which) has that capability to be used as a sample register
<cr1901_modern>
without knowing internal details- there's only one physical operator on a given silicon- why restrict samples to a single channel?
<whitequark>
hrm
<whitequark>
interesting
<cr1901_modern>
Multichannel sampled music is possible on the Genesis through clever programming
<l_oliveira>
the closest to that I've ever seen was some Polish ZX-Spectrum custom hardware which used YM2203s
<cr1901_modern>
I thought 2203 _was_ an AY-3 clone
<cr1901_modern>
or one of the earliest YM chips were
<whitequark>
cr1901_modern: yeah, you can't set context sample rate
<l_oliveira>
it is, but not 1:1
<whitequark>
so i have to resample on the server
<whitequark>
thing is
<whitequark>
i *can* tell the browser to resample
<l_oliveira>
the way the chip strobes work on AY-3-8910 and YM2149 are meant to connect to the CP1600 GIC processor
<whitequark>
but the browser resampler does not keep the resampler state between different audio buffers
<whitequark>
so you hear clicks
<whitequark>
every 30 ms
<cr1901_modern>
clicks because you have to set the resampler state and that can't happen fast enough?
<cr1901_modern>
l_oliveira: ahhh
<l_oliveira>
so I use that 74LS86 to "translate" the CP1600 bus style chip enables to linear addressing the YM2203 needs
<l_oliveira>
that way the YM2203 appears to the MSX the same way the original AY would
<cr1901_modern>
GIC. GIC rhymes with PIC! Coincidence?! I think not!
<cr1901_modern>
(It isn't a coincidence)
<l_oliveira>
certainly like Atmel made their AVR MCU name a meme
<l_oliveira>
confusing acronyms are popular with engineering crowd, huh?
<whitequark>
GIC?
<whitequark>
gender identity council? :D
<l_oliveira>
General Instrument Corporation?
<l_oliveira>
I think people are better leaving gender discussions aside, because people can get angry about that stuff (lol)
<cr1901_modern>
l_oliveira: I really don't care, tbh
<cr1901_modern>
if they get angry that's not my problem
<l_oliveira>
wouldn't it be a pity if you would get to fight with someone who would otherwise have pleasant engineering discussions with you because you two disagree with politics?
<cr1901_modern>
l_oliveira: Yes, it would. But pleasant engineering discussions don't exist in a vaccuum
<whitequark>
l_oliveira: no, not really a pity
<l_oliveira>
well, it comes to what gets discussed first
<whitequark>
more of an early indicator that i don't want to have much to do with that person in depth
<cr1901_modern>
To reiterate, any homophobia, transphobia, etc == not welcome here.
<l_oliveira>
of course lol that's not humane
<l_oliveira>
any phobia
<cr1901_modern>
There are some ppl in synth community I've deliberately not invited for this reason
<cr1901_modern>
even though their technical input would be valuable :/
<l_oliveira>
we're getting to a point on the hysteria though, the other side is starting to harass cis people
<l_oliveira>
well, let's put this chat to rest
<whitequark>
l_oliveira: if someone tries to deny me medical treatment, i will harass the fuck out of them
<l_oliveira>
I'm just sad that people are fighthing instead of getting things done
<l_oliveira>
of course, that is a basic human right
<l_oliveira>
anyone regardless of what they are have rights to medical treatment
<cr1901_modern>
l_oliveira: I'm happy to discuss names in private of ppl I don't want in here, but I'm not about to air dirty laundry.
<l_oliveira>
good point
<whitequark>
yeah well once that's actually what's happening in the world i will be interested in "the other side harassing cis people" as a complaint
<whitequark>
until then? i will support that
<l_oliveira>
I absolutely don't support people harassing each other
<l_oliveira>
either sides
<whitequark>
"harass" is actually very mild, women's suffrage in the UK owes its existence to firebombings, which are also an acceptable response to injustice
* cr1901_modern
sighs
<cr1901_modern>
well I never said "no politics" in here lol
<cr1901_modern>
To add to wq's point, there's a power differential between "cis ppl getting their feelings hurt over uppity marginalized ppl" and "marginalized ppl being harrassed for things they can't control"
<cr1901_modern>
such as being trans, queer, etc
<whitequark>
by harassed you mean being actively murdered and denied medical treatment, which is being passively murdered
<whitequark>
call things what they are
* cr1901_modern
nods
<l_oliveira>
Well, the reality on my country might be a bit different than on yours
<l_oliveira>
here, if you need public healthcare you're fucked
<l_oliveira>
regardless what you are
<l_oliveira>
so it's not race/gender discrimination
<l_oliveira>
it's about class/having or not money
<whitequark>
the UK has 30+ month wait lists to even get HRT, which should not need prescription at all, or maybe at most a script from a GP
<whitequark>
that's systematic and not an accident
<whitequark>
the US, well, PP is one of the main providers of care through informed consent, and we all know how PP is treated
<l_oliveira>
here if you get to a hospital dying, the chances you will die are very high
<whitequark>
NL has VUC, which is an atrocious institution and is the final gatekeeper
<l_oliveira>
unless you can pay for private health care
<whitequark>
I am informed of a situation in a rather large amount of countries, because I've spent a nontrivial amount of time a) giving people consultations when that is deined by their state and b) distributing medication when that is denied by their state
<whitequark>
no country is good, although some are much worse
<whitequark>
for example, the situation in RU is much less bad than in the US in many ways, which is not what you'd expect
<l_oliveira>
Russia has some interesting stuff going on, but you know what works on one place not always work on others
<whitequark>
I know that very well
<whitequark>
public option can be quite bad if it is an enforced monopoly, like in the UK, because that concentrates power in the hands of a very few people, who are universally clueless and hostile
<whitequark>
the ideal situation is a combined public/private system with informed consent
<whitequark>
this is what happens in a few US states, and it would work great if it wasn't so bloody expensive
<l_oliveira>
that's exactly how I feel about it, WQ
<whitequark>
russia has a public/private system. it doesn't have informed consent, but also no one actually checks prescription for non-narcotic drugs, so you can just buy whatever you want. that... also works, i guess
<whitequark>
similar in ukraine
<l_oliveira>
here, you need a medic prescription for drugs that may cause addiction
<mad>
opl overclocked and voice count magically expanded 100-fold would be an equivalent
<cr1901_modern>
<shitpost>I'm pretty sure you'd set your OPL on fire running it at 3.2GHz</shitpost>
<whitequark>
i do want to overclock the OPL
<whitequark>
well i mean i laready do
<l_oliveira>
one thing you might find interesting
<whitequark>
i want to figure out how high can it go
<l_oliveira>
I think what keeps overclocking from working is mostly the hysteresis thing on the opamp circuitry at the DAC
<whitequark>
no DAC, i read samples with FPGA
<cr1901_modern>
there's no DAC here
<l_oliveira>
since you're not using the DAC, your chip has no issue with that
<whitequark>
right
<cr1901_modern>
How do you get "more notes in a given chunk of wall clock time" by overclocking the OPL2?
<whitequark>
you don't literally overclock it
<whitequark>
it's fully synchronous
<whitequark>
the idea is to compose music "as if" it was clocked such that you get e.g. 1 MHz sample rate
<l_oliveira>
it's about playing the music at twice the speed with twice the clock, no?
<whitequark>
the real chip would run much slower. you would capture the digital output and compress
<whitequark>
yes
<l_oliveira>
you then end with the same data as you would with the normal clock but in half the time
<whitequark>
so it is about composing different music, not so much different clocking
<l_oliveira>
after screwing around a lot of the OPN chip and it's prescaler thing
<cr1901_modern>
you're fundamentally limited by how fast you can spam write to 1/84th of the clock speed of the chip
<whitequark>
cr1901_modern: the chip in real life would be clocked at the same rate as usual
<whitequark>
3 MHz or whatever
<cr1901_modern>
3.58 MHz- colorburst
<whitequark>
but you would play it at 30 MHz
<whitequark>
it wouldn't be real time, not with real YM3812
<l_oliveira>
the argument is, the clock rate the chip runs so it is capable of producing sound waves that are suitable to human ears are somewhat limited
<cr1901_modern>
So if you play it at 30MHz, it would sound 2.5 times higher pitch
<l_oliveira>
outside of that range it's not that useful even if it could be clocked higher or lower
<whitequark>
10 times?
<cr1901_modern>
octave is base 2
<whitequark>
oh right
<whitequark>
cr1901_modern: right so now let's say it's 300 or 900 MHz instead
<l_oliveira>
what is the internal clock divider for OPL2?
<whitequark>
and instead of using the operators to synthesize waveforms directly
<whitequark>
you'd rely on beat frequencies between them or something like that
<whitequark>
l_oliveira: 72 between M and SH
<l_oliveira>
internally OPN operates at something like 700khz when clocked at 4.2Mhz
<cr1901_modern>
whitequark: hmmm, interesting idea
<whitequark>
l_oliveira: wait
<whitequark>
does OPL2 even have a prescaler like that?
<l_oliveira>
no it does not
<whitequark>
I thought it operates at фM directly
<whitequark>
right
<cr1901_modern>
OPM does
<cr1901_modern>
it divides by 2
<whitequark>
huh, why?
<cr1901_modern>
and you use the output clk to drive the DAC
<whitequark>
ah
<l_oliveira>
OPM has a divider but I don't think it has a prescaler
<l_oliveira>
OPN has a prescaler so it can be fed 1.7Mhz and operate as if it was 3.57Mhz I suppose
<whitequark>
cr1901_modern: even wilder idea
<whitequark>
make a die shrink of OPL2
<whitequark>
that physically runs at 3.2 GHz
<whitequark>
well ok that would be very expensive, but a 180 nm shrink should be fine
<cr1901_modern>
if your frequency was 300 to 900, the pitch of the output would be log2(900) times greater... that would make most waveforms unpleasant to listen to if listened to directly :P
<whitequark>
yes, you'd need to filter them
<cr1901_modern>
you could create a table of frequencies for 3.2GHz operation tho
<cr1901_modern>
err table of reg values*
<whitequark>
no, the *point* is to produce distortion
<whitequark>
of course we can make a faster OPL2, but that's not very interesting
<l_oliveira>
an FPGA implementation can be mate so it runs faster than the real chip, no?
<l_oliveira>
I can imagine the real chip has annoying constraints about how it's a dynamic memory design
<whitequark>
it is dynamic memory?
<l_oliveira>
let the clock stop, the registers contents fade away
<whitequark>
i thought it's SRAM
<whitequark>
really?
<l_oliveira>
yes
<cr1901_modern>
NMOS is dynamic
<cr1901_modern>
CMOS prob isn't
<whitequark>
but OPL2 is CMOS
<l_oliveira>
can you test that?
<cr1901_modern>
Just read the datasheet
<cr1901_modern>
what's the minimum operating freq?
<whitequark>
l_oliveira: sure, give me a moment
<l_oliveira>
not Yamaha datasheets, remember, datashits
<l_oliveira>
lol
<whitequark>
cr1901_modern: it says 2 MHz
<whitequark>
but that's not saying much
<ej5>
there is such a thing as dynamic CMOS.
<whitequark>
of course
<l_oliveira>
WQ: exactly
<whitequark>
but i looked at die shots
<whitequark>
and it looks like SRAM to me
<whitequark>
well
<whitequark>
i looked at the *die*, not die shots :P
<whitequark>
such a beautiful device
<l_oliveira>
the OPL4 has readable registers and it might be SRAM because it sure seems to support sleeping
<whitequark>
l_oliveira: let me try pausing the clock to it
<l_oliveira>
yeah please do
<l_oliveira>
for science!
<whitequark>
1 second enough?
<l_oliveira>
I think so
<mad>
they definitely changed the reg file between OPL2 and OPL3
<whitequark>
OPL3 has many more registers, no?
<l_oliveira>
older FM chips do crap out for much less time of clock anomality
<whitequark>
ej5: yeah those pics are not very good :S
<cr1901_modern>
whitequark: Can't speak for OPL2, but OPM has the same freq max/min/typical. It is actually normal to see boards run OPM at 4MHz. To get the intended pitch of a note, you of course have to write different values to the frequency register. >>
<mad>
but also most old fm chips don't really have reg files, they have loops of shift registers
<whitequark>
mine are slightly better
<whitequark>
and will be even better
<l_oliveira>
OPL3 has some special stuff going on too so it can do 4OP modes
<ej5>
whitequark, got any sample pics?
<cr1901_modern>
For your 1 MHz sample rate idea, you want a musician to program the frequency registers as if the chip is being run at 3.58 MHz, or 3.58 * 20 Mhz (to get a sample rate of 1 MHz)?
<mad>
writing to the reg file doesn't really directly write, it waits for the value to come up on the shift-register-loop and replaces it with the new value
<l_oliveira>
FM synths do sweep around the register array in a fixed/controlled way, being a shift register actually makes a lot of sense since it will be swept sequentially
<mad>
this is why the data sheets say "you must wait some time between register writes" (irl one sample, which is the time it takes for the shift register to cycle)
<whitequark>
ej5: the chromatic aberration is annoying but it will not be visible on stitched images
<whitequark>
so, only look at center top
<whitequark>
mad: OH
<whitequark>
thanks
<ej5>
not quite enough to make out diffusion areas
<whitequark>
ej5: i will delayer it
<ej5>
ok that should help
<mad>
whitequark : that scheme is in the original dx7 patent :D
<whitequark>
going to call my chemist tomorrow
<whitequark>
dx7?
<mad>
opl3 has a real register file instead (it's done on later tech, which is why it doesn't have the register write delay)
<ej5>
hmm, kinda looks like there are dynamic latches in there
<mad>
whitequark : yamaha dx7, the original FM keyboard
<cr1901_modern>
dx7 houses a very strange member of the synth family
<cr1901_modern>
it's also arguably the most complex
<l_oliveira>
you can still screw with the OPL3 if you abuse register writes
<whitequark>
ej5: i can take higher res pics if you want
<cr1901_modern>
algorithms w/ 6 operators
<whitequark>
just give me area of interest and some time to set up thescope
<cr1901_modern>
instead of 4 or 2
<l_oliveira>
but yes it takes a lot more abuse than older chips
<cr1901_modern>
what would cascading 6 operators in series even sound like (besides "bad")?
<mad>
whitequark : basically all the OPM-OPP-OPZ/OPN/OPL/OPLL/OPK chips are spinoffs of the tech in the dx7 :D
* whitequark
facedesk
<whitequark>
mad: i figured out the OPL2 timings finally
<whitequark>
the address latency is 12 MCLK and data latency is 84 MCLK
<whitequark>
this is because it is broken down into 12 MCLK latency for the data bus to latch, not sure why
<whitequark>
and 72 MCLK latency for one sample
<whitequark>
cr1901_modern: and this is why there is no need for explicit 1 sample delays in VGM player
<l_oliveira>
guys, the YM3438 have a weird problem, if you spam reads on the status register it glitches weirdly
<cr1901_modern>
9 channels, 8 cycles per channel
<l_oliveira>
only that chip has that problem
<mad>
yeah the 72 clock thing is waiting for the register loop to cycle through all 18 operators
<cr1901_modern>
4 cycles per operator
<l_oliveira>
any ideas?
<whitequark>
mad: yeah, i get that
<whitequark>
that's very clear
<whitequark>
what is not clear to me, is why 12 cycles
<mad>
hmm
<whitequark>
for the data bus to latch?
<ej5>
hmm wonder if theres a phase shift for each operator
<whitequark>
that seems high
<mad>
I'm suspecting that the whole chip has its clock divided by 4
<whitequark>
hm
<mad>
that would explain 4 cycles but not 12 cycles
<whitequark>
if it has a /4 prescaler
<whitequark>
then it needs 3 cycles to latch data bus
<whitequark>
the data bus is asynchronous
<whitequark>
maybe it has a 2FF on the input?
<l_oliveira>
if you write stuff too fast, writes may end on wrong registers
<whitequark>
yep
<l_oliveira>
does that make any sense?
<mad>
like I dunno but OPN is similar and can divide the clock by 6, 3 or 2
<whitequark>
i'm not sure exactly why
<whitequark>
i have observed it
<cr1901_modern>
whitequark: and this is why there is no need for explicit 1 sample delays in VGM player <-- I don't follow this train of logic
<l_oliveira>
OPN prescalers are 6/4 (default) 3/2 and 2/1
<whitequark>
cr1901_modern: any register write is implicitly a 1 sample delay plus a few more MCLK cycles
<l_oliveira>
FM/SSG
<cr1901_modern>
sure, I forget why you wanted 1 sample delay in the first place when the granularity of VGM commands is 1/44100 :P
<l_oliveira>
OPNA has it 12/8 (default) 6/4 and 4/2
<cr1901_modern>
which is far longer than 84 clks
<mad>
opn is designed do that you divide a 3.57mhz clock into 6 by default, but the fact that you can change the divider seems to say that it doesn't need the subclocks internally in the way it processes
<whitequark>
cr1901_modern: no it isn't
<whitequark>
3.57M/84 clks correspond to 42500
<l_oliveira>
I think OPNA exploits the fact that it has exactly twice the number of registers to sweep so it runs internally twice the clock as a regular OPN
<cr1901_modern>
... I can't divide
<cr1901_modern>
whitequark: Just to refresh my memory, what was the context of you wanting a single sample delay? Was it to force the correct amount of time to elapse before the next write? Or because you actually had a reason why you wanted to delay an reg write by one output sample latency?
<whitequark>
l_oliveira: seems to have no ill effect from stopping the clock
<l_oliveira>
good to know, thanks for testing
<l_oliveira>
YM2612 forgets what it was doing if clock stops
<whitequark>
huh
<l_oliveira>
which is one of the things people do while circuit bending it
<cr1901_modern>
2612 is also NMOS (well the DIP versions anyway)
<ej5>
only reason i'm familiar with it is that the 6502 (NMOS) is dynamic and uses a two phase non overlapping clock.
<ej5>
there were concerns the discrete version wouldn't work due to the big difference in capacitance between a discrete FET and an on-chip FET.
<l_oliveira>
you mean 6502 built with TTLs?
<ej5>
no, with discrete transistors.
<ej5>
monster6502.com
<l_oliveira>
ah I really enjoyed seeing that monster 6502 thing
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ej5 has quit [Ping timeout: 245 seconds]
<whitequark>
monster 3812 when :P
<l_oliveira>
up to you? (hehe)
andlabs has joined ##yamahasynths
<Lord_Nightmare>
ej5 ym2612 is not static, since i believe (but have not tested) someone mentioned if you slow the clock down enough everything except the PCM stops working
<Lord_Nightmare>
but ym2612 is NMOS
<whitequark>
are there even static nmos circuits?
<Lord_Nightmare>
i think its technically possible but power hungry, maybe?
<Lord_Nightmare>
ym3438 (OPN2C) is cmos, and that might be a static design
<Lord_Nightmare>
unclear
<Lord_Nightmare>
also, someone pointed out that there's 3 different ym2413 datasheets: a really old one, a new-digital-layout one, and a new digital layout one for YM2413B
<Lord_Nightmare>
the ym2413B uses 1/3 of the power of the older ones, so it is possible that YM2413B is CMOS
<Lord_Nightmare>
its also possible that it is HMOS-II or HMOS-III, which are fancier, less power hungry variants of NMOS that are still NMOS at heart
<whitequark>
what's HMOS?
<Lord_Nightmare>
afaik HMOS is NMOS with purer silicon done in thinner layers and doped differently
<Lord_Nightmare>
or something like that
<Lord_Nightmare>
it was basically an excuse for chip manufactureres to stick with 5 layer masks (NMOS tech) instead of upgrading to 7 or 8 layers (CMOS)
<whitequark>
oh huh
<Lord_Nightmare>
i believe commodore fell into that trap and only was producing CMOS chips for the last 2-3 years of their existence (1990-1992)
<Lord_Nightmare>
when everyone else started CMOS stuff in the mid 80s
<Lord_Nightmare>
at least i think nmos is 5 layers... window, polysilicon, n+ diffusuion, contact holes, and metal?
<l_oliveira>
I have a board with YM3438 I think I can test if it "degrades" with the clock removed
<whitequark>
oh
<whitequark>
i can just
<whitequark>
physically disconnect the clock
<l_oliveira>
yes
<whitequark>
for some reason it didn't occur to me
<whitequark>
lol
<l_oliveira>
have a pullup resistor connected to the pin so it stays on a fixed state
<l_oliveira>
or if you do it with the fpga just leave it high or low
<Lord_Nightmare>
cmos is another 2 layers, one for n-well (i think) and one for p+ ?
<l_oliveira>
glitching a pulse could whack the chip out and make you have errors introduced on the measurement
<Lord_Nightmare>
and dual-metal process chips like the FHB013 (YMF281) i think have 9 layers
<Lord_Nightmare>
or 10, if there's buried vias and stuff
<Lord_Nightmare>
i'm not sure
<Lord_Nightmare>
digshadow would know more about this
<whitequark>
yeah, glitching a pulse definitely does weird things to the chip
<whitequark>
let's see...
<mad>
the SID needed about 100ms of no clock to forget stuff
<l_oliveira>
hm, removing clock from the YM3438 disrupts the music playback (I.E.: it doesn't return to playing music when clock is returned)
<l_oliveira>
but if you stop the music player and start over it plays fine
<whitequark>
l_oliveira: just carefully checked with YM3812
<l_oliveira>
what happened?
<whitequark>
i stop the clock for exactly 1 second, keeping it high or low (whatever it was when it stopped)
<whitequark>
there is no difference in the output whatsoever
<l_oliveira>
are you freezing the player too?
<whitequark>
the player is clocked by the DAC clock, yes
<l_oliveira>
I kind of can't do that
<whitequark>
(and has internal buffering)
<whitequark>
well, the control logic and the DAC emulator live in a 30 MHz clock domain and use the YM3812 signals as strobes after an edge detector
<l_oliveira>
so the chip state will 'misalign' with the chip even if it keeps the state
<whitequark>
so this doesn't disrupt my FPGA at all
<l_oliveira>
er
<whitequark>
all timings, etc, are preserved
<whitequark>
both the control logic and the DAC logic are merely stopped
<l_oliveira>
so the player state will 'misalign' with the chip even if the chip keeps the state
<whitequark>
and i verified that samples stop going through the pipe back to USB
<whitequark>
it does not produce any output during the glitch
<l_oliveira>
you think you can obtain a YM3526?
<whitequark>
probably
<whitequark>
hm
<whitequark>
zero hits on ebay?
<l_oliveira>
that might be NMOS
<l_oliveira>
I've never seen a YM3526 IRL lol
<whitequark>
oh, the original OPL
<l_oliveira>
closest thing to that I got is the Y8950
<l_oliveira>
YM3526 (and YM3812) are almost 1:1 pinout with YM2151 and that is not a coincidence lol
<whitequark>
yes, very similar package, yamaha logo
<whitequark>
ok
<whitequark>
sure
<whitequark>
i can buy those
<l_oliveira>
that's a sharp package actually lol
<whitequark>
hm?
<l_oliveira>
be back in a hour, have errands
<l_oliveira>
Yamaha was fabless back then
<whitequark>
oh i know, that's not what i meant
<whitequark>
the aliexpress link has yamaha logo blacked out
<whitequark>
digitally
<l_oliveira>
oh I see
<l_oliveira>
be back in about a hour (or two if things go bad)
<whitequark>
nod
<Sarayan>
wq: log tables wouldn't work out because audio *also* wants lots of adds. Fused mul-add was inverted for (audio) filters initially
<Sarayan>
invented
<whitequark>
ahh
<Sarayan>
general form of linear filters (the ones we always use) is y[0] = - sum(b_i * y[i]) + sum(a_i * x[i]) where x is the input, y the output, and the indices are the values on previous samples
<Sarayan>
and 0 = now
<Sarayan>
so, mul-add all the time
<Lord_Nightmare>
comparing MAME's rendering of the YM3812 music from vimana vs the vgz played via whitequark's actual ym3812 shows MAMEs core is... well, its definitely got some issues, though i know MAMEs resampler is pretty awful
<Lord_Nightmare>
iirc MAME's resampler is simple linear interpolation with no filtering, and i don't know how it does decimation if the source sample rate is too high
<whitequark>
Lord_Nightmare: note that i also do resampling
<whitequark>
via libsamplerate
<Lord_Nightmare>
I assume what MAME SHOULD do is figure out the interpolation/decimation coefficients for each stream going to its 'mixer' then use init(or clock-change) generated kaiser windows for the antialias filter
<Lord_Nightmare>
if it can offload this computation to a DSP or GPU it would be even faster, but afaik the DSPs in the 'realtek' type hd audio stuff is pretty locked down and not user accessible
balrog has quit [Ping timeout: 250 seconds]
balrog has joined ##yamahasynths
<Stilett0>
oof, that was a long chat log, you guys had a busy Saturday :D
<Stilett0>
<cr1901_modern> >"YM3812 Application Manual" Could you please link me that, I'm having trouble finding it
<Stilett0>
ahhh, you found that! That was my scan from a bazillion years ago :D
<whitequark>
ha
<Stilett0>
some Internet guy sent me a photocopy of the manual in, like, 2002 or something, though it took me several years to get all my ducks in a row and finish up scanning everything
<whitequark>
that was super handy
<whitequark>
i still have no idea why they chose that DAC format, with the sign bit
<whitequark>
but it works well
<Stilett0>
checking my records: received photocopy of YM3812 Application Manual from oplx.com in October 2000, finally scanned and uploaded January 2007 after many years :P
* Stilett0
is either a slacker or very busy
<Lord_Nightmare>
Stilett0: wait, what? the ym3812 application manual is online? where?
<Lord_Nightmare>
whitequark: can you add caching of already played vgm files by md5, and then just stream an already rendered file if someone uploads the same vgm/vgz again?
<Lord_Nightmare>
whitequark: the new buffer code is VERY NICE! the beginning of the vimana theme is no longer cut off
<whitequark>
"can you add caching of already played vgm files by md5" i actually already compute an sha256 digest
<whitequark>
i did not do any caching because the whole system is only soft real time
<Lord_Nightmare>
waitasec... a bunch of the channels of the vimana vgm are not playing anymore
<Lord_Nightmare>
did someone make a vgm file which wrote random garbage to the test register
<Lord_Nightmare>
you might have to powercycle the chip
<whitequark>
Lord_Nightmare: wtf
<whitequark>
can you fuck it up with the test register?
<Lord_Nightmare>
i don't know
<Lord_Nightmare>
i don't think you can fuck it up PERMANENTLY
<whitequark>
yeah sure
<whitequark>
i mean
<ej5>
how can we find out?
<Lord_Nightmare>
you may just need to write 0x20 to the test reg
<Lord_Nightmare>
to reset it
<whitequark>
right now before i start playing any vgm, i expxlicitly zero out every single register
<whitequark>
is that why?
<whitequark>
wait
<whitequark>
could it be that some vgms don't write 0x20 to the test reg?
<whitequark>
and it remains in compatibility mode?
<Lord_Nightmare>
it may be
<whitequark>
every single *documented* register. the rest is left alone
<whitequark>
okay
<whitequark>
give me a sec
<Lord_Nightmare>
correct vgms should write 0x20 there
<Lord_Nightmare>
it played 'better' the second tiem i sent it
<Sarayan>
there's no non-volatile storage in the ym
<Lord_Nightmare>
there's something weird going on
<whitequark>
hmm
<whitequark>
yeah this is why there's no caching
<Lord_Nightmare>
now i'm hearing some notes out of tune
<whitequark>
yes, i have another vgm like that
<Lord_Nightmare>
like one of the patches got uploaded wrong
<whitequark>
it's very strange
<whitequark>
Lord_Nightmare: are there any timings i am not aware of?
<Lord_Nightmare>
i don't know
<whitequark>
beyond 12/84
<whitequark>
ok
<Lord_Nightmare>
vimana is an arcade game, and it uses an HD647180 (basically an almost-z180 with very slightly different peripherals) eprom MCU as its sound engine
<Lord_Nightmare>
which conects to a ym3812
<Lord_Nightmare>
superctr made a set of vgm files for it
<Lord_Nightmare>
i just hope he correctly captured the test 0x20 thing
<l_oliveira>
look what he writes to the OPL3 to get it to a sane state before starting a VGM
<whitequark>
OPL3_Reset?
<l_oliveira>
yes
<whitequark>
gah i hate assembly
<whitequark>
how does this work
<Lord_Nightmare>
also opl3 has 2 banks of registers while opl and opl2 have just one
<whitequark>
what architecture is that anyway
<Lord_Nightmare>
so ignore anything writing to the second bank
<l_oliveira>
Z80
<l_oliveira>
it just write to the two banks in parallel
<l_oliveira>
hence why the routine is called fill registers pairs
<whitequark>
so... it zeroes 20..F6?
<whitequark>
then it writes uh
<whitequark>
i don't know OPL3, too
<l_oliveira>
OPL3 is like two OPL2s in parallel
<l_oliveira>
at consecutive I/O addresses
<whitequark>
Lord_Nightmare: ok, i changed the reset routine
<whitequark>
it sounds ~identical now?
<Lord_Nightmare>
testing, one sec
<Lord_Nightmare>
YES! it sounds correct now! :)
<whitequark>
Lord_Nightmare: ahahaha
<whitequark>
do you wanna know what i did
<whitequark>
had to do some educated guesswork
<Lord_Nightmare>
the bass in MAME sounds wrong
<whitequark>
as far as i can tell, when it is in OPL1 mode, you can't access registers of OPL2
<whitequark>
BUT
<whitequark>
they will still influence output
<whitequark>
so i put it in OPL2 mode, then zero all, then back to OPL1
<whitequark>
at least i have no other guesses as to why my fix would help
<l_oliveira>
Yamaha chips will keep the state they're in even if you turn off the advanced features lol
<whitequark>
so this is known?
<l_oliveira>
if you for example change the waveform and put it back on OPL1 mode it will stay at the second waveform and you won't be able to change it unless you turn opl2 mode on again
<whitequark>
amazing
<l_oliveira>
yeah, turning features off just mask the new registers off
<Lord_Nightmare>
you could add a heuristic to check the vgm file first; if a vgm song ever writes to E0-F6, it *should* have written 0x20 to TEST/0x01 first, and if it didn't, you can write that for it and flag a warning to the user
<Lord_Nightmare>
that should work around bad rips of opl2 music
<whitequark>
Lord_Nightmare: let me add this
<l_oliveira>
that's a bright idea
<l_oliveira>
on OPNA you can you set OPNA mode on and then setup the LFO, turn the OPNA mode off and it will affect how the chip behaves while playing old YM2203 data
<l_oliveira>
or you could for example play around with the pan control registers, make specific channels pan for one side or another
<Lord_Nightmare>
so check vgm file for writes to 0x01. if it NEVER wrote to 0x01, check for writes to 0xe0-0xf6. if it DOES write to 0xe0-0xf6, then display a warning, and write 0x20 to 0x01 before starting the vgm
<l_oliveira>
some PC98 games actually do that if they detect OPNA even though they target the original OPN
<Lord_Nightmare>
some songs like the vimana song are deliberately running the OPL2 in OPL mode
<Lord_Nightmare>
why, i'm not sure
<Lord_Nightmare>
perhaps that song was composed for OPL, and the toaplan guys bought opl2 chips later
<l_oliveira>
look how Seibu likes to retrofit YM3014s on YM2151s
<l_oliveira>
the same boards can also work with YM3812 just swapping some jumpers around
<Lord_Nightmare>
whitequark: suggestion: can you add a pause button for the looped audio?
<l_oliveira>
Raiden2 comes with a YM2151 but it can use YM3812
<Lord_Nightmare>
(or better, a way to save the wave file it produces)
<Lord_Nightmare>
raiden2 sound code doesn't do 3812, does it?
<Lord_Nightmare>
speaking of raiden2, are you interested in helping me put the sets in MAME in chronological/code order?
<whitequark>
Lord_Nightmare: a pause button is... hard
<whitequark>
webaudio is shit
<whitequark>
it doesn't let me fill a ring buffer
<whitequark>
i have to place complete buffers on a virtual timeline
<ej5>
webaudio...did they take inspiration from pulseaudio?
<whitequark>
and then it doesn't even always fire a completion interrupt
<whitequark>
seemingly at random
<whitequark>
the entire thing is completely retarded and barely usable at all
<ej5>
sounds like the new thing everyone will start using
<whitequark>
Lord_Nightmare: re wave, i'll try
<whitequark>
no eta
<Lord_Nightmare>
webaudio was designed by an idiot who didn't know how modern audio works and pushed through by a group of corporate yes-men, even though a better interface had been proposed by people who knew what they were doing
<whitequark>
that is precisely my conclusion
<ej5>
so...webshit basically
<Lord_Nightmare>
the better interface had no corporate sponsorship so it died
<whitequark>
i resent it with a passion of a million suns
<Lord_Nightmare>
webaudio is now a w3c/html5 standard
<whitequark>
having to write javascript to work around its braindeadedness doesn't help
<ej5>
wtf...
* ej5
shakes his head
<Lord_Nightmare>
and its a giant flaming pile of shit which needs to be purged
<ej5>
naw they'll bandaid it until it sorta works
<ej5>
then call it good
<Lord_Nightmare>
i don't think its fixable
<Lord_Nightmare>
i think the other interface needs to be adopted ON TOP of it as an alternative
<Lord_Nightmare>
called something else
<Lord_Nightmare>
"ringAudio"
<Lord_Nightmare>
since its just a 'stupid' ring buffer, that's almost all it is
<Lord_Nightmare>
no funky object oriented hell
<ej5>
i'm calling it now, someone will try to write a cloud-based DAW using webaudio
<l_oliveira>
@LN no it doesn't but the physical board can use it if they wanted to
<Lord_Nightmare>
l_oliveira seibu actually made all the chips on raiden 2 etc have wonderful labels like "2" or "3"
<Lord_Nightmare>
which are the SAME on ALL REVISIONS
<Lord_Nightmare>
no revision markings
<Lord_Nightmare>
no REGION markings
<Lord_Nightmare>
nothing
<Lord_Nightmare>
its horrible
<Lord_Nightmare>
some of the sets in MAME were dumps of just a few chips so they're mixed up messes which never really appeared on PCBs
<l_oliveira>
I used that idea to make a board which can use either chips, I have a YM3012 as DAC, works fine with YM3812 if I tie SH1 and SH2 together
<Lord_Nightmare>
I *THINK* i have all the sound cpu revisions in order
<Lord_Nightmare>
some raiden 2 sound cpu revs have more songs or changed songs from others
<Lord_Nightmare>
the game code is trickier
<l_oliveira>
that's bizarre
<l_oliveira>
Seibu liked to be awkward, probably was how they kept their stuff hard to bootleg
cr1901_modern has quit [Read error: Connection reset by peer]
<Lord_Nightmare>
also seibu's sound cpu code DOES have a version number in it! which seems helpful until you realized that THE VERSION FIELD IS THE SAME ON ALL THE DIFFERENT VERSIONS
<ej5>
XD
<Lord_Nightmare>
its actually the same version FROM A PREVIOUS GAME
<l_oliveira>
like how Konami liked to play legos with a set of chips or NAMCO liked to make a ridiculous amount of different customs
<whitequark>
and i think that collection of info is unmatched elsewhere
<l_oliveira>
blast of the past haha
<cr1901_modern>
Yes, it probably is unmatched. You can find the pieces here and there, but I still assert that it's quite scattered besides the applet.
<l_oliveira>
reading the part about disk rotation speed made me remember of my old APPLE II
<cr1901_modern>
Sarayan disagrees w/ me, asserting the MAME impl of WD177x is enough :P
<l_oliveira>
and the stroboscopic sticker on the bottom of the drive rotor
<cr1901_modern>
or MAME impl of some floppy disk code*
<whitequark>
i don't think MAME anything is enough
<whitequark>
it is not gateware
<whitequark>
why isn't MAME written in verilog anyway?
<whitequark>
rhetorical question
ValleyBell has joined ##yamahasynths
<ej5>
FYI whitequark the amiga floppy format uses a track granularity write
<ValleyBell>
Hi. I got invited by cr1901_modern.
<whitequark>
TIL
<ej5>
which is how they get 880K onto a 720K PC format disk
<ej5>
no gaps.
<cr1901_modern>
whitequark: ValleyBell is the person I mentioned who plays a lot w/ VGM. Been talking to them re: OPN to OPL conversion
<cr1901_modern>
trying to make new VGMs for maximum hilarity
<cr1901_modern>
ej5: AFAIK the rest of the Amiga format is very similar to IBM disks?
<whitequark>
nice
<cr1901_modern>
aside from no gaps between sectors
<l_oliveira>
original shugart interface we had one motor on signal, if you had four drives, all four would spin on access
<cr1901_modern>
DOSBOX has an OPL2 mode I can enable. I'll try that next
<cr1901_modern>
l_oliveira: That was one reason IBM PC has the twist in the cable
<l_oliveira>
ya
<cr1901_modern>
it's design to only enable one motor at a time
<ej5>
hmm, 11 or 22 sectors of data per track with no gaps between sectors.
<l_oliveira>
it got rid of the four drives capability
<ej5>
checking the sector format now...
<l_oliveira>
MSX is older so it uses the old style of one motor on, four drive select pins
<ej5>
hmm, the sector format is quite different
<cr1901_modern>
ej5: Welp I'm wrong. In other news, water is wet :P.
<cr1901_modern>
Could've sworn it was very similar
<ej5>
it leaves out the head #, then it has additional data for OS recovery info as well as a separate header CRC
<whitequark>
Lord_Nightmare: WAV conversion likely needs to happen on client
<whitequark>
unless you want a WAV with a 49715 Hz sample rate anyway
<whitequark>
well
<Lord_Nightmare>
that's very much allowed by the wav spec
<whitequark>
that doesn't mean it works
<Lord_Nightmare>
client can convert to wav
<whitequark>
for example, the browser resamples
<whitequark>
but this is useless
<cr1901_modern>
it's wav dump as a stump as far as specs go?
<cr1901_modern>
dumb*
<whitequark>
because it does not keep resampler state between the buffers that i give it
<Lord_Nightmare>
if you need some example dumb wave header writing code, i have some written in c
<whitequark>
and my buffers are 30 ms long
<ej5>
totally off topic now, but the amiga HD floppies can store 1.76MB compared with the PC's 1.44MB.
<cr1901_modern>
Everything is on topic on IRC
<whitequark>
so each 30 ms you hear a faint click
<whitequark>
i had to resample on the server for the -client's preferred sample rate-
<whitequark>
the amount of hacks i had to do to get seamless playback and looping is depressing
<cr1901_modern>
whitequark: is the faint click due to taking too long to re-set up the new sample rate?
<whitequark>
no
* Wohali
buries ej5 in ls-120 floppies
<whitequark>
not exactly
<cr1901_modern>
I don't really get why there would be a click swapping buffers on a modern computer then
<whitequark>
if you feed a 48k client 49k rate buffers they will not match exactly
* ej5
prefers 21MB flopticals
<whitequark>
like the resampler is a filter of some sort
<whitequark>
and this filter has internal state that propagates into the next buffer
<whitequark>
from the previous one
<whitequark>
if you reset it there is a mismatch in the level
<whitequark>
a click
<whitequark>
it took me a while to figure out
<whitequark>
it's faint
<whitequark>
but it is there
<cr1901_modern>
ewww
<cr1901_modern>
that's gross
<whitequark>
i still support both modes
<whitequark>
so that libsamplerate is not a hard dependency of glasgow
<whitequark>
it will complain if you don't have it but still give you output
<whitequark>
damn, vimana has good music
<cr1901_modern>
yea a resample filter would keep around the last few samples or so... there's _gotta_ be a software solution to this.
<whitequark>
there is
<whitequark>
it's called not using webaudio
<whitequark>
and doing resampling yourself
<whitequark>
i almost want to say that using webaudio is harder than using the hardware
<whitequark>
but that is not true
<whitequark>
because the hardware is shit too
<whitequark>
intel hda is horrible
<whitequark>
and alsa is shit
<whitequark>
a proud tradition of shitty audio, you could say
<Wohali>
pulseaudio ain't much better :P
<Wohali>
in fact, i'd say decidedly worse...
<whitequark>
a proud tradition!
<Wohali>
indeed!!
<whitequark>
well, it is more useful in some aspects
<cr1901_modern>
whitequark: The problem you describe wrt lost state isn't unique to resampling. Ya know about the filtering technique of "take the FFT, multiply by FFT of filter, take IFFT"?
<whitequark>
pulseaudio lets me switch between bluetooth and laptop speakers dynamically
<Wohali>
i guess if you reeeallly like dbus and poettering
<whitequark>
alsa does not
<whitequark>
if i want that i'm just fucked
<Wohali>
<3 :D
<whitequark>
people tell me "use dmix" but no one has ever been able to produce an example of using dmix that would work
<whitequark>
so i just assume dmix doesn't actually work
<cr1901_modern>
Ehhh forget it, I just wonder if there's "overlap-add/save, except for resampling"
<whitequark>
I: glasgow.applet.yamaha_opl: web: 0364d75e3a52f258: VGM has commands for SN76489, YM2612
<whitequark>
W: glasgow.applet.yamaha_opl: web: 0364d75e3a52f258: broken upload: VGM file does not contain commands for YM3812
<whitequark>
i wonde rwhat this is for
<whitequark>
sega?
<cr1901_modern>
Genesis
<whitequark>
people upload so much weird shit
<whitequark>
also apparently no one knows that YM3812 is not OPL3
<cr1901_modern>
SN76489 is the _other_ sound chip on the Genesis. As it is not FM it is off-topic (j/k)
<ValleyBell>
I guess they didn't get what "OPL2" means.
<whitequark>
i still want to know where did the file for OPL2 with a 3.2 GHz master clock came from
<whitequark>
it validated as Vgm
<whitequark>
i actually check the signature and everything
<ej5>
3.2GHz? XD
<whitequark>
yes.
<cr1901_modern>
ahhh right, for GDPR compliance you can't keep the file around?
<whitequark>
0xc0xxxxxx
<ej5>
someone's trolling?
<whitequark>
cr1901_modern: i'm mostly just too lazy
<whitequark>
i am not subject to GDPR
<l_oliveira>
vgmrips discovered your device WQ
<cr1901_modern>
ahhh
<whitequark>
oh?
<whitequark>
really?
<cr1901_modern>
ValleyBell, was that you :P?
<l_oliveira>
:D
<ValleyBell>
I didn't upload anything yet.
<cr1901_modern>
No I mean the "vgmrips discovered your device" part
<whitequark>
link?
<cr1901_modern>
I don't actually know that many ppl from vgmrips
<whitequark>
does this mean i can never turn it off again? :D
<cr1901_modern>
I know _of_ them through their work
<ValleyBell>
About that 0xC0xxx - sorry about that. That means "Dual OPL2".
<whitequark>
ValleyBell: what.
<whitequark>
why the *fuck* is it stuffed into that field.
<ValleyBell>
In the chip clock, bit 30 is "dual mode" and bit 31 is a "special" flag.
<whitequark>
gaaaaaaaaah
<whitequark>
i'll go bash my head in
<whitequark>
ValleyBell: it's not in the doc
<whitequark>
not for ym3812
<ValleyBell>
It's in that field because I added NeoGeoPocket support (using 2x SN-PSG) in 2009 as some sort of "cheat mode".
<l_oliveira>
assumptions
<whitequark>
Note: Bit 31 (0x80000000) is used on combination with the dual-chip-bit
<whitequark>
to indicate that this is a T6W28. (PSG variant used in NeoGeo Pocket)
<l_oliveira>
that's yamaha for you
<ValleyBell>
and everyone liked it and somehow I kept it that way
<l_oliveira>
:D
<cr1901_modern>
I still say VGM should've been more like SPC format
<whitequark>
but that's for SN76489 clock, not YM3812 clock...
<whitequark>
why do people keep sending these things
<whitequark>
yes my error reporting works thank
<Sarayan>
bedtime for time, have fun folks
<ValleyBell>
I posted a link to the Twitter post in the #vgmrips channel. Maybe some people from the forum there are uploading random files.
<whitequark>
oh I see
<whitequark>
that's cool
<whitequark>
I did notice a flurry of activity recently
<cr1901_modern>
whitequark: yea I linked that in privmsg, should've asked before?
<whitequark>
nope, that's fine
<whitequark>
was just wondering
<whitequark>
it clearly says "yamaha" there in the title lol
<cr1901_modern>
Many systems have FM addons
<cr1901_modern>
like Sega Master System and C64
<cr1901_modern>
IIRC ValleyBell didn't you do a Master System hack that added FM music?
<ValleyBell>
OPLL -> OPL2 translation works really, really well.
<ValleyBell>
Yes, I hacked the sound driver in Sonic 1 SMS to support OPLL FM.
<cr1901_modern>
Sanic the Hedgie
<whitequark>
lol
<l_oliveira>
it's about the operators having the same data format
<l_oliveira>
I suppose
<ValleyBell>
The OPLL is just a OPL2 with hardwired instrument data.
<l_oliveira>
like grauw's translator plays OPN music on OPM almost perfectly in real time
<ValleyBell>
OPN <-> OPM works really as too, yeah.
<l_oliveira>
the operators are identical
<cr1901_modern>
mostly
<l_oliveira>
just the control registers for the chips are different
<cr1901_modern>
one of them has extra Detune/Decay
<l_oliveira>
and a few chip specific features like the OPM noise generator
<whitequark>
ValleyBell: question
<l_oliveira>
OPN has the SSG envelopes for FM EG and the special mode on channel 3 where you can set different frequencies on all four OPs
<whitequark>
in VGM, let's say I have one register write, followed by one sample delay, followed by another register write
<whitequark>
for YM3812 for example
<whitequark>
when precisely would the second register write scheduled?
<whitequark>
be*
<ValleyBell>
It would try to execute the write 1/44100 second after the first one.
<ValleyBell>
in software emulation
<whitequark>
right but writes take longer than 1/44100 of second
<whitequark>
about 1/42500
<ValleyBell>
When doing it in hardwrae, you just wait long enough so that it works.
<whitequark>
ValleyBell: the problem i have is
<ValleyBell>
DRO files record only with 1000 Hz, so OPL2 logs aren't really that accurate.
<whitequark>
the VGM total length field is I think the sum of all delays in the file
<ValleyBell>
yes
<whitequark>
but if I wait long enough that it works then each register write introduces an additional 1.1(6) sample delay
<ValleyBell>
You need to subtract the additional wait time from the next delay, yeah.
<whitequark>
what if the next delay is 0?
<whitequark>
or 1
<ValleyBell>
At some point, there will be a delay of like 600 samples.
<whitequark>
i have seen either
<whitequark>
so, basically, what you are saying is that VGM delay commands are not like delay
<ValleyBell>
and that's where everything can sync again.
<whitequark>
but something like "advance timeline"
<whitequark>
for abstract instant writes
<ValleyBell>
yes
<whitequark>
ok, i think this might be why the loops don't quite match up
<whitequark>
i need to fix that, hrm
<ValleyBell>
Each command it assumed to take 0 time.
<whitequark>
i'll need to add a phase accumulator and use the master clock counter in hardware
<whitequark>
but that's okay
<whitequark>
ValleyBell: you really ought to add this to the spec
<whitequark>
it is not obvious at all
<cr1901_modern>
>Each command it assumed to take 0 time. <-- is this _before_ bus cycle delay calculations begin?
<cr1901_modern>
i.e. the write is instant, and then you start counting up to 84 cycles
<cr1901_modern>
and then the write actually takes effect after 84 cycles
<ValleyBell>
You really overthink the complexity of the VGM format :P
<ValleyBell>
It started off as GYM for Sega Master System.
<l_oliveira>
Genesis
<ValleyBell>
Master System
<ValleyBell>
MegaDrive support was added later.
<cr1901_modern>
Really ._.?
<ValleyBell>
that's why its home is on "SMSPower!"
<l_oliveira>
I remember it started on genecyst, when people started dumping SMS it was already VGM
<l_oliveira>
GYM logs AY and YM2612
<l_oliveira>
SN sorry
<l_oliveira>
it had no header even, was very raw-ish
<ValleyBell>
Anyway, what I wanted to say: VGM started off as "something like GYM, but better" and for the SMS and Game Gear.
<l_oliveira>
yes it was a lot better than GYM from start
<whitequark>
cr1901_modern: 21:58 < cr1901_modern> and then the write actually takes effect after 84 cycles
<whitequark>
this doesn't matter a lot
<l_oliveira>
because GYM was too specific
<whitequark>
because this is at worst a fixed offset of 84 cycles
<whitequark>
but my current implementation has phase drift
<cr1901_modern>
There's a global state machine for register writes, so it won't be a fixed offset of 84 cycles when the write takes effect
<cr1901_modern>
it depends on when the write actually arrives
<cr1901_modern>
the 84 cycle is worst case
<ValleyBell>
In the beginning it just had a ocmmand for "PSG register write", "wait 60Hz frame" and "wait 50Hz frame".
<l_oliveira>
VB: gens started it, not genecyst actually D:
<l_oliveira>
sorry lol
<ValleyBell>
and "wait N samples" to allow logging PCM stuff
<cr1901_modern>
whitequark: AFAIK, GYM is the software version of "hooking up wires to the YM's data/adr bus and logging results as soon as /CS asserts
<whitequark>
but you can't do that
<whitequark>
you need log at /CS or /WE
<whitequark>
er
<cr1901_modern>
yea sorry
<whitequark>
invert this a few time
<l_oliveira>
yes, it logs only writes
<l_oliveira>
and store the intervals between them as wait commands
<ValleyBell>
vampirefrog at vgmrips once did a VGM log of the TG100 demo song by capturing the data/addr bus.
<l_oliveira>
that's a lot of willpower lol
<cr1901_modern>
I mean Glasgow could be a GYM writer already lol... more than enough I/O and bandwidth
<cr1901_modern>
Maybe a VGM writer too
<whitequark>
sure
<whitequark>
that'd be pretty trivial to do
<whitequark>
l_oliveira: i have an idea
<whitequark>
for the latency of register writes
<whitequark>
if i was implementing OPL, i would put the *entire* register file into a single giant shift register
<whitequark>
since there is more than one register per operator it would be necessary to have multiple MCLK cycles to align it with the read window
<whitequark>
that might explain why the multiple of 4 in the latency
<whitequark>
hm, there are 7 registers per operator
<whitequark>
wait, no
<whitequark>
there are indeed 4 registers per operator
<whitequark>
eh i guess we'll figure that out soon enough
<l_oliveira>
hehe
<l_oliveira>
that made me thought of something I was on the dark until recently
<cr1901_modern>
Why does OPL2 have room for 0x15 adsr registers, but only 18 (0x12) operators?
<l_oliveira>
why color carriers on video systems had a set frequency
<cr1901_modern>
cc: ValleyBell
<whitequark>
cr1901_modern: does it?
<l_oliveira>
it was about frequency spectral properties... >_<
<whitequark>
can you count the registers in the file?
<whitequark>
i mean on the die
<cr1901_modern>
whitequark: If you look at the datasheet, it gives a basic reg map divided into sections
<whitequark>
i know
<cr1901_modern>
whitequark: Oh I didn't count
<whitequark>
the datashit lies
<whitequark>
constnatly
<l_oliveira>
so the Yamaha engineer was on his table defining how that would work he would lay stuff the way it would be easiest for the chip design and still somewhat practical programming wise
<cr1901_modern>
this is a weird thing to lie about- it's such an odd number of registers
<cr1901_modern>
it offends my delicate sensibilities
<whitequark>
i just assume it hasn't been proofread period
<cr1901_modern>
about order in the universe
<cr1901_modern>
0x15 is such a weird number! :o
<l_oliveira>
@cr1901_modern It used to be much, much worse, we knew absolutely nothing about these chips 20 years ago
<cr1901_modern>
is that why Genecyst 0.2.0 was so bad :)?
<ValleyBell>
0x15 is weird, but the OPL can also switch between 9-channel (melody) and 6+5 channel (rhythm) mode.
<ValleyBell>
having 9 or 11 channels doesn't make it any less weird.
<cr1901_modern>
Oh maybe it's actually 0x16 registers and I have an off-by-one error
<cr1901_modern>
B/c 22 would be 11 channels, 2 regs per channel
<l_oliveira>
cr1901_modern: Sound on genecyst was bad because it was trying to pump 4OP instruments on a 2OP design/chip lol
<ValleyBell>
How well did MAME's OPM-on-OPL emulation work?
<cr1901_modern>
guessing not well
<cr1901_modern>
didn't know there _was_ such a thing
<l_oliveira>
OPN/OPM = 4OP OPL = 2OP
<cr1901_modern>
whitequark: I have an idea... add a "unreliable bus connection" mode that randomly flips bits of reg writes to your web interface. Create glitchy music
<l_oliveira>
that is the computer which is driving the chip
<l_oliveira>
noisy power supply noisy video chip, noisy bus
<ej5>
bad caps?
<l_oliveira>
no, actually 1985 tech
<l_oliveira>
It is a brazilian MSX clone
<l_oliveira>
with a bunch of non standard wires on top and an AT power supply power it up
<ValleyBell>
"The VGM file format assumes that writes happen instantaneously. They do not." <-- No one said that a format from 2001 would be accurately representing hardware behaviour :P
<ValleyBell>
Actually, I don't know any format that omits the delay enforced by the hardware.
<ValleyBell>
(I also don't think it would be practical to do so.)