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>
(1:51:40 PM) cr1901_modern: I guess my question after all this is: I suspect dropping the LSB from the operator output when feeding it into the operator input was a deliberate design decision when planning out the silicon. Contrast to "dropping 4 MSBs".
<cr1901_modern>
Well, I've been playing around w/ z3 to answer that question for those interested: https://rise4fun.com/Z3/r6xW
<cr1901_modern>
(1:51:53 PM) cr1901_modern: I wonder why this choice was made.
<cr1901_modern>
"Why mathematically prove this by hand when I can ask the SMT solver to do it?"
<cr1901_modern>
From what I can gather... The desired output of an operator is always meant to be a 12-bit number (which is the number of bits in the sine table output)
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
adding 2 12-bit numbers and then shifting right once preserves the LSB, at the cost of halving the sin and envelope generator's contributions to attenuation.
<cr1901_modern>
I think this must be where the errors in the YM2608 manual come from re: envelope generator attenuation- the manual says 96dB, but it's actually 48dB
* cr1901_modern
/minddump... exhausted
andlabs has joined ##yamahasynths
ej5 has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
ej5 has quit [Read error: Connection reset by peer]
<futarisIRCcloud>
$5 for a board. $9.50 for shipping. (USD)
whitequark has quit [Ping timeout: 252 seconds]
whitequark has joined ##yamahasynths
SceneCAT has joined ##yamahasynths
<whitequark>
cr1901_modern: hey, can I ask you for a favor?
<whitequark>
i just discovered that the glasgow memory-floppy applet can handle ST-412 with minor modifications.
<whitequark>
can you expand/rewrite the docs in the applet to account for hard drives, too? i feel like you'd know this better than me
<whitequark>
i've ordered an ST-225, found a cheap one locally
<cr1901_modern>
It's MFM controller-specific what the data format is... I've only ever seen docs for Seagate's _recommended_ layout for their ST-506 drives
<whitequark>
this says "slightly modified system 34"
<cr1901_modern>
thanks
<whitequark>
cr1901_modern: oh, you linked to me some FDC controller doc
<whitequark>
that explained system 34
<whitequark>
can you link it again?
<whitequark>
i'll put it into the glasgow archive
<cr1901_modern>
Yea just let me remember the part number
<cr1901_modern>
Anyway, the track format described in the manual is a starting point. If the drive was ever formatted w/ a Western Digital or Xebec controller (my ST-506 was formatted using a WD controller), that track format probably won't apply
<cr1901_modern>
Oh right, your hard drive was almost certainly formatted w/ 512 byte sectors too (it's "just how things were done")
<whitequark>
cr1901_modern: updated, thanks
<cr1901_modern>
whitequark: So based on a quick comparison w/ System34, the Seagate variant did away w/ the C2 sync and there's no longer any "bytes/sector" data
<whitequark>
cr1901_modern: it's not like i have ever seen C2 sync on floppies either
<cr1901_modern>
I've seen it on mine, but that's 5.25". I also recall something about 3.5" floppies not bothering to align sector 0 w/ the index hole
<cr1901_modern>
so maybe it's "really old historical crap that doesn't matter for reading floppies in 2019".
* cr1901_modern
soaks in the irony of that statement
<cr1901_modern>
Anyways, I
<cr1901_modern>
'd be _really_ curious to see a raw dump of the waveforms on your ST-225 since afaik there's relatively little REing of those formats
<whitequark>
sure
<cr1901_modern>
balrog knows of someone who did a Beaglebone PRU driver to read MFM disks for... DEC machines? And that's about it
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ValleyBell>
DeltaRazero used to be in the #vgmrips channel, but I haven't seen him since January.
<cr1901_modern>
http://ix.io/1H5c I tried mimicking feedback in Python as if OPM were a perfect device... I have a waveform viewer for YM2151, but I think it's bugged for self-feedback (whereas it looks correct w/o self feedback)
<cr1901_modern>
Would be curious to get waveform traces of a single channel w/ no attentuation at various feedback levels.
<cr1901_modern>
Additionally I just had a thought... register contents are undefined on these chips at boot. You're expected to initialize them, which is all fine and dandy, but...
<l_oliveira>
no, that's what their reset pin is for :)
<l_oliveira>
it sets them up at a defined state
<cr1901_modern>
This didn't work properly when using JT51 then
<cr1901_modern>
(although I think in that case that might be due to using BRAM as a reg file)
<l_oliveira>
I had to actually study that with the guy from VGMPLAY-MSX because we can't physically reset the chips
<l_oliveira>
we had to soft reset them
<cr1901_modern>
Anyways, if you initialize self-feedback to anything other than 0, wouldn't garbage be continually circulated through operator 1, even if the key was off?
<l_oliveira>
it is possible to soft reset them but you need to know the supposed initial state the physical reset puts it in so you can do it properly
<cr1901_modern>
I guess TL=127 would eventually kill the garbage
<l_oliveira>
because that's the state VGMs expect it to be at
<cr1901_modern>
(unless KOFF _also_ flushes out garbage)
<l_oliveira>
if a music driver do a full setup (most do, actually) that's non issue
<l_oliveira>
but VGM is not a music driver, it is a stream lol
<whitequark>
that's why glasgow includes code to verify that the VGM is properly driving the chip
<whitequark>
and if not it fixes that
<l_oliveira>
yeah
<cr1901_modern>
>if a music driver do a full setup
<cr1901_modern>
I don't see how that flushes out garbage feedback values if you set FB > 0 after reset
<l_oliveira>
you have to nanny the darn thing because a lot of VGM dumps are crappy
<l_oliveira>
also you have to block writes to things like test registers, clock prescaler, timers and I/O ports
<whitequark>
timers?
<cr1901_modern>
Yea these chips have a few timers
<whitequark>
I can see clock prescaler and I/O ports
<l_oliveira>
only very specific uses (like mode enablers) should be allowed
<whitequark>
but what's wrong with writes to timers
<l_oliveira>
I have the timer hooked on the MSX
<whitequark>
they don't really do anything
<whitequark>
ahhh
<l_oliveira>
it will crash the computer if I let VGMs access that
<l_oliveira>
the timer is useful for other things like real music drivers
<l_oliveira>
so we choose to hook it up
<cr1901_modern>
Often used as an interrupt
<cr1901_modern>
except, moronically, on the Genesis
<cr1901_modern>
IRQ wasn't hooked up
<cr1901_modern>
Some timers can be used to turn all instruments on at once
<whitequark>
oh huh
<cr1901_modern>
It's a decent source of 50Hz and 60Hz
<whitequark>
the use of timers and I/O ports on the sound chip reminds me of shit like A20 gate
<whitequark>
*especially* IO ports
<cr1901_modern>
I mean, the SID had ADCs for paddles
<whitequark>
paddles?
<cr1901_modern>
game controllers*
<cr1901_modern>
like the ones you'd use for pong
<cr1901_modern>
Integration was "cute" back then
<cr1901_modern>
It's possible these chips were taking cues from the RAM I/O Timer (RIOT) produced by MOS
<cr1901_modern>
IIRC the Atari 2600 used that, and that was the sole source of RAM on the system
<whitequark>
ugh i hate the RTC RAM
<whitequark>
so incredibly ad-hoc
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
rtc ram?
<cr1901_modern>
Quick minddump for later: I guess my question is... assuming you _have_ to soft reset for whatever reason... >>
<cr1901_modern>
If you don't quash feedback completely by setting FB=0 before writing the FB value you actually want, does the chip have other mechanisms to prevent power-on-reset undefined behavior values from affecting operator output due to self-feedback?
<l_oliveira>
Actually the RTC on MSX and Amiga (Ricoh RP5C01) actually works like a nibble SRAM
<l_oliveira>
the one on PCs is 8bit, no?
<whitequark>
cr1901_modern: like a DS1307
<whitequark>
it has a ton of RAM inside
<l_oliveira>
A friend of mine discovered a new TMS9918 VDP variant from Yamaha being used on MSX computers, it seems to be a derivative of SEGA's 315-5066 (SG-1000 MK2)
<cr1901_modern>
ahhh I see
<whitequark>
64..192 bytes depending on the clone
<l_oliveira>
it's "YM2220"
<superctr>
<cr1901_modern> If you don't quash feedback completely by setting FB=0 before writing the FB value you actually want, does the chip have other mechanisms to prevent power-on-reset undefined behavior values from affecting operator output due to self-feedback? <- it does not matter because operator 1 does not output in algorithm 0
<l_oliveira>
that, yesterday
<l_oliveira>
he thought it was a V9938 and was trying to engage 80 columns text mode, which wasn't working at all
<superctr>
when reset all registers are initialized to their initial values, that would apply to accumulators too
<l_oliveira>
You can actually run a YM2608 without physically resetting it with the reset pin, it will work weird but if you init all registers manually you may get it to run okay
<l_oliveira>
the state the registers come out from power on are chaotic/random without the chip being reset first, though
<superctr>
as long as it doesn't hard lockup it would be fine
<l_oliveira>
Some of these chips seem to use dynamic cells as register storage, which could cause them to hard lock in some cases I suppose. But ... YM2608 didn't seem to suffer much from that if soft initialized right
<l_oliveira>
I don't think that would fly with the YM2151 (never tried, too)
<Lord_Nightmare>
someone did the MFMulator thing using a beaglebone pru
<Lord_Nightmare>
and philpem did some MFM(?) decoding using the discferret, but ran into issues where it couldn't sample fast or reliably enough
andlabs has joined ##yamahasynths
<cr1901_modern>
superctr: >it does not matter because operator 1 does not output in algorithm 0
<cr1901_modern>
If I said 0 I meant 7, but even so, operator 1 (1-based indexing) would still be feeding itself in algorithm 0 (0-based indexing) if TL wasn't 127
<superctr>
the operator only feeds itself as long as feedback is > 0
<superctr>
the moment you reset the feedback, all effects of it disappear too
<cr1901_modern>
right and I'm discussing the case where for whatever reason you can't use the reset pin, but you haven't explicitly set FB to 0
<superctr>
well, you can experiment with this using a real synth or any decent emulator
<cr1901_modern>
But that's work! :P
<superctr>
use algo 7, mute all operators except 1 and mess with TL and feedback
<superctr>
i like VOPM because it lets you set the operator mask
<superctr>
and it can export instruments to .OPM format for MML
<superctr>
you can hear effects of feedback on the sound all until the TL makes it inaudible
<superctr>
even then it might still have an effect but it's attenuated along with the volume, which you notice as lower FB values will have a lesser effect as TL is increased
<superctr>
single operator, FB=4 and sweeping the TL
<superctr>
TL=0 at the right edge
<superctr>
you can see the harmonics caused by feedback doesn't even appear until TL reaches a certain point
<cr1901_modern>
superctr: Cool image!
<cr1901_modern>
Two things are probably simultaneously true:
<cr1901_modern>
2. My feedback impl is wrong, and there's some nasty floating point crap causing it to oscillate w/ less feedback than a "real" chip
<cr1901_modern>
1. The waveform viewer I'm using is buggy
SceneCAT^APUG has joined ##yamahasynths
UnluckyPony has joined ##yamahasynths
SceneCAT has quit [Ping timeout: 255 seconds]
SceneCAT^APUG has quit [Ping timeout: 258 seconds]
<cr1901_modern>
whitequark: Potential feature request for glasgow OPL/M whatever... could you expose the "get the raw data" part of the HTTP API to the end user so I can do experiments like "create an instrument and hear how it sounds"?
<whitequark>
cr1901_modern: sure. how should this API look like?
<whitequark>
cr1901_modern: actually feel free to open a feature request on the glasgow repo
<cr1901_modern>
whitequark: Will do once I sketch it out
<cr1901_modern>
short version is: user either uploads a toy VGM or raw instr params, and then waits for the data payload in the http request, probably using something w/ good async/await support
<cr1901_modern>
I'm using VGMMM (closed source Windows tracker) to create the toy VGM, but at some point I'll move to writing the VGM file in Python or whatever
<whitequark>
cr1901_modern: python sounds good
<whitequark>
i think i will need to move the entire thing to websockets
<whitequark>
because uhhhhhhh streaming base64-encoded chunks of text gets *old*
<whitequark>
the python library i am using makes websockets easy. *claims* to make websockets easy.
<cr1901_modern>
can't say I know the first thing about websockets :P
<whitequark>
i don't know a lot tbh
<whitequark>
if it doesn't let me "replace Socket(x) with WebSocket(x)" i wouldn't use it probably
<cr1901_modern>
ValleyBell: Is there a VGM to RAW output tool, or do I have to write one?
<whitequark>
what's RAW?
<cr1901_modern>
err sorry, shouldn't be capitalized
<cr1901_modern>
raw output*
<whitequark>
do you just cut off the VGM header?
<cr1901_modern>
I created a VGM file to test feedback/how it would sound on nukeykt's emulator... I just want to capture the values the emulator generates and dump them to either a binary or text file
<cr1901_modern>
I found VGM2WAV, so I can use that
<whitequark>
oooh
<cr1901_modern>
That being said, there _is_ a RAW (Rdos Raw OPL Capture) converter to VGM... have no idea what that format is tho :P
<cr1901_modern>
oh... I should've looked harder
<cr1901_modern>
vgm2pcm
<superctr>
you can just run vgmplay with "-LogSound:1" too
<superctr>
to convert to raw, strip the first 40 bytes or so
<cr1901_modern>
oh I didn't know vgmplay had a command line
<cr1901_modern>
if you try doing "-h" it prompts for a file
<superctr>
well, there aren't many parameters apart from that
<superctr>
there's LogSound and there's one that i added to select the output device
<cr1901_modern>
Aaand somehow I lost some formatting
<cr1901_modern>
fixed
<cr1901_modern>
Yea my feedback impl stops matching nukeykt's core at about FB=4 or so... well, that's something I can solve later
<cr1901_modern>
Wonder if the ym2151 decap repo got shared again... been getting a number of stars on it lately...
<cr1901_modern>
The blog post that complements the repo got to the front page of HN briefly for a day- being seeing as I don't have an acct on that website (thank f***) it passed me by until someone pointed it out to me