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
<ej5>
yep
<balrog>
ej5: been out of the loop lately — where do we stand when it comes to soundblaster firmware?
* cr1901_modern
is not sure where the 8 Mhz decision came from
<ej5>
i sent it off to the mame tipline. never heard back.
<ej5>
was gonna hold off on releasing any reverse engineered versions until cr1901 here had a chance to make his own cleanroomed version
<ej5>
technically i still owe him the spec :o
<balrog>
mame tipline meaning code@? I know one got added
<balrog>
lemme see...
<ej5>
yeah code@
<balrog>
yeah you might not get a reply and might just see it appear in the code
<balrog>
I'll check the repo
<cr1901_modern>
ej5: At this point I am healthy enough to be able to solder, I haven't ordered the parts tho. I also need to set up a testing computer.
Xyz_39808 has quit [Ping timeout: 245 seconds]
<cr1901_modern>
in other words, take your time :P
<ej5>
ah ok, it's partly complete
<cr1901_modern>
I look forward to reading it, tbh. Should be fun. And I actually get to write asm (assuming sdcc's new assembler is pretty good) :P
<balrog>
ej5: I'll poke around
<balrog>
ej5: that said, I was curious as to other versions and such
* cr1901_modern
wish there were a digitally verifiable way to prove he hasn't seen the RE'd source while still allowing the source to be release
<ej5>
yeah i've completely disassembled the code. it would be interesting to compare it to later versions. i think the only later ones that have been dumped are from SB16s
<balrog>
yeah
<balrog>
3.x
<cr1901_modern>
ej5: Is it possible for you to upload the spec you've written so far out of curiosity? Or do you want to wait until it's all done?
<ej5>
guess i could, it's in markdown so i could put it up on the githubs
<cr1901_modern>
Whatever's most convenient for you, and markdown is good
<cr1901_modern>
you can run it thru pandoc to make a fancy-smanchy pdf
<cr1901_modern>
(No actually, as much as I hate that the effective BNF for markdown is ".*", I love it as a format)
<ej5>
hope you can brush up on your 8051 assembly hehe
<cr1901_modern>
it's been 7.5 years since I last used it. I'm sure I'll be fine lmao.
<cr1901_modern>
I remember it being less pleasant than 6502, but more pleasant than z80
<ej5>
is z80 more or less pleasant than x86? ;)
<cr1901_modern>
interesting question... z80 screws me over w/ its odd interrupt scheme (type 0, 1, 2, wtf?) and shadow registers. 8088 assembly sucks b/c I'm not convinced there's a good way to represent segments, overrides, and offsets in a plaintext syntax.
<cr1901_modern>
not necessarily b/c the idea behind 8086 suck (which I'm not sure they did for their time)
<cr1901_modern>
A late version of MASM is a pretty decent 8086 assembler. The problem is there really isn't a good FOSS equivalent, ever since japheth disappeared
<cr1901_modern>
NASM leaves a bunch of goodies to the macro system, but in practice I've found it too difficult to debug macros I've made in them (and the struct support is half-assed)
<cr1901_modern>
>and the struct support is half-assed <-- tbf, this is most assemblers. Nested struct fields should be supported.
<cr1901_modern>
at the end of the day it's still an offset from a base even if you support nesting
<cr1901_modern>
balrog: AFAIK, Baron-von-Riedesel isn't Japheth, Japheth just gave this person his blessing to host the source on Github, but he doesn't intend to work on it anymore.
<cr1901_modern>
"bugs are now features" is a humorous phrase to indicate "I'm not working on it anymore"
<balrog>
I think Baron-von-Riedesel may be Japheth
<cr1901_modern>
Oh?
<cr1901_modern>
Well that's good if true, though I wish more ppl were contributing
<balrog>
(partly because "Baron-von-Riedesel" is a historical name)
<cr1901_modern>
I've never heard of it before hand
Xyz_39808 has quit [Read error: Connection reset by peer]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
balrog has quit [Quit: Bye]
balrog has joined ##yamahasynths
SceneCAT has quit [Quit: *Mreow*]
<ZirconiumX>
I have no idea where to put this, but
<ZirconiumX>
> With a POWER play, it's possible they could get better performance but also run a higher power budget compared to their original 2.5 Watt target.
<ZirconiumX>
Forgive me if I'm missing something obvious, but why would switching ISA in any way affect the power budget?
<cr1901_modern>
ZirconiumX: Educated guess: economies of scale all them to put more transistors onto a POWER design, and believe it or not, more transistors _can_ actually mean power savings if the extra transistors control the existing core properly.
<cr1901_modern>
There's a thread between @rygorous and I about this some time ago on hellsite, but I can't really find it right now
<cr1901_modern>
allow POWER vendors*
<ZirconiumX>
Presumably you're talking about things like clock gating here to reduce power?
<cr1901_modern>
yes, or caching that allows other parts of the core to be turned off
<ZirconiumX>
Sure, but here Michael says that moving to Power increases performance but also power.
<ZirconiumX>
I can understand that a more complex encoding requires more power to do, but is Power really that complex to decode?
<ZirconiumX>
s/do/use/
<cr1901_modern>
I think the important point is "more money to spend == more transistors == more potential tricks to save power"
<Sarayan>
also more money for R&D == more results, most often
<cr1901_modern>
economies of scale the reason Intel can tolerate the complex encoding of base i686 and no one gives a shit in practice
<cr1901_modern>
(this is not to scoff at the academic and industry research on making fast and efficient RISCV designs, btw)
<ZirconiumX>
<cr1901_modern> I think the important point is "more money to spend == more transistors == more potential tricks to save power" <--- where's that money coming from? They've still got to add compiler support for their extensions
<cr1901_modern>
> With a POWER play, it's possible they could get better performance but also run a higher power budget compared to their original 2.5 Watt target.
<cr1901_modern>
Oh I glossed over that line
<cr1901_modern>
I was specifically thinking of how switching to POWER could _reduce_ power budget
<cr1901_modern>
so it uses less power (pun intended) than an equivalent RISCV core
<ZirconiumX>
And yet here, Michael says it will *increase* the power budget
<cr1901_modern>
Yea, Idk then. I was answer why a *decrease* in power budget may be true
<ZirconiumX>
I'm not actually sure why IBM chips draw more power than the equivalent (say) Intel Xeon. Heavy SMT?
<Sarayan>
if you want powerful, you go amd64, if you want low power or dirt cheap, you go arm, everything else is a rounding error :-)
<cr1901_modern>
Unless you're Apple, who someone found a way to compete arm w/ amd64 :/
<ZirconiumX>
The core of Apple's silicon team is still PA Semi, right?
<cr1901_modern>
I was under the impression that it was an in-house (fabless) design
<ZirconiumX>
Sure, but Apple bought PA Semi originally
<cr1901_modern>
Well, maybe then :). Not sure
SceneCAT has joined ##yamahasynths
<cr1901_modern>
>yall want to implement something fun on top of glasgyamaha or should i improve it further still
<cr1901_modern>
The below is me minddumping, not meant to be taken seriously unless I implement it myself for fun >>
<cr1901_modern>
A random "glitch mode" where Glasgow randomly corrupts bytes sent to the actual chips, to simulate "bus errors".
<cr1901_modern>
I've been watching too many corruption streams...
<cr1901_modern>
Actually Idk if that'll work- a VGM file loses information about which ROM addresses caused a write to the chip, and to simulate corruption, address/data bus info would need to be known.
<whitequark>
cr1901_modern: inty did that
<interruptinuse>
yeah
<cr1901_modern>
oh, is it private code, or just recently pushed?
<interruptinuse>
cr1901_modern: let me get back to you on that
* cr1901_modern
nods
<cr1901_modern>
take your time. I have plenty of vinesauce material to still go through (among others)
<ZirconiumX>
cr1901_modern: I very much *wish* I was making good progress on Mistral
<cr1901_modern>
well, progress is progress :P
<ZirconiumX>
I have the LUT bits in an ALM tile
<ZirconiumX>
But I don't have any routing bits
<cr1901_modern>
Oh for MachXO2, I have basically the opposite... mostly routing, the LUT bits, but not enough to connect registers to create a counter
<whitequark>
oh I just realized something
<whitequark>
if I want to run the OPx applet in actual honest realtime
<whitequark>
I don't need to clock it at exactly 49715*72 Hz or something
<whitequark>
I just need the average clock rate to be 49715, since it's fully synchronous and buffering is involved anyway
<whitequark>
moreover, clocking it based on feedback from host lets me genlock it to the host audio stack, which would be necessary -even if- I could synthesize 49715*72 Hz precisely
<cr1901_modern>
This is all in the context of "taking the output of the OPx, and having the host audio stack play it through your host's speakers", correct?
<whitequark>
yeah
<cr1901_modern>
I don't think I ever considered that use case for my own hypothetical designs. For playing from a DAW or whatever, my intent was always to treat the OPx as a MIDI out device and play to external speakers from my custom PCB
<cr1901_modern>
For capturing raw input, I never intended real time to be practical (one could resample after the fact if they wanted to hear the output)
<whitequark>
you can of course clock it at 44100 sample rate
<cr1901_modern>
My intent was that samples would be received at the host side at 62500 Hz (4 MHz clk)
<cr1901_modern>
I don't know what sampling at 44100 gains you
<cr1901_modern>
you would need to resample on FPGA
<cr1901_modern>
(or microcontroller implementing the USB connection)
<whitequark>
no
<whitequark>
you could just rescale the notes
<cr1901_modern>
Check the datasheet for your particular chip... in the OPM case, 3 MHz is the minimum clk.
<cr1901_modern>
3000000/64 > 44100
<cr1901_modern>
Might work tho
<cr1901_modern>
Fuck... I don't remember where "64" comes from, other than knowing a priori it's the correct divisor.
<cr1901_modern>
I need to write this shit down
<whitequark>
there is no minimum clock for a fully synchronous circuit like most yamaha synths
<whitequark>
for OPM 64 is the correct divisor, yes, based on glasgow code
<whitequark>
address_clocks = 12
<whitequark>
sample_clocks = 64
<whitequark>
data_clocks = 68
<whitequark>
i'm not sure where i got 12 and 68 from
<cr1901_modern>
I want to say "4 ops per channel * 8 channels = 32 slots. 32 slots* 2 clks per slot = 64". I'm _almost_ certain that the 64 divisor only accounts for one channel in stereo configuration.
<cr1901_modern>
Meaning for both channels you have 62500 samples for L/R = 125000 samples each second in OPM at 4 MHz.
<cr1901_modern>
>there is no minimum clock for a fully synchronous circuit like most yamaha synths
<cr1901_modern>
Yamaha is an NMOS design
<cr1901_modern>
err OPM*
<cr1901_modern>
if you don't clock it fast enough it'll lose its state. I don't remember the details.
<cr1901_modern>
I want to say it's because of all the depletion mode pullups eventually bringing the chip back to a default state.
<cr1901_modern>
^Ignore last message, it's wrong, and I'm confusing it with the reason that NMOS has high static power consumption.
<whitequark>
hm
<whitequark>
i should try stopping OPM clock
<cr1901_modern>
I'm not sure what's right anymore, tbh. We agree most of the chip is synchronous and pipelined like it would be on an FPGA. My experience w/ NMOS is that they have a minimum clk frequency to keep their state.
<cr1901_modern>
One of the selling points of e.g. the CMOS 286 is that it can be clocked down to 0 Hz and still works
<cr1901_modern>
s/is/was/
<cr1901_modern>
I'm not sure how the synchronous part of OPM is physically implemented right now; is it static or dynamic? Actually asynchronous storage elements like a latch, or synchronous like a flip-flop?
<cr1901_modern>
whitequark: >i should try stopping OPM clock Would appreciate those results if/when you get the chance.