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
<Lord_Nightmare>
also it turns out that the svg file is MUCH smaller, and easier to edit, so i'm moving all tracing over to that
<cr1901_modern>
tyvm :3
ej5 has quit [Read error: Connection reset by peer]
_whitelogger has joined ##yamahasynths
<cr1901_modern>
ValleyBell: Is there documentation on how to use libvgmplayer.a
<cr1901_modern>
?
<cr1901_modern>
I assume it's an embeddable vgmplayer?
linkmauve has quit [Ping timeout: 260 seconds]
<KillaMaaki2>
Oh my god I got it working lol. The funny thing was it was a simple typo in what function I was calling at one point (I forgot to set any operator regs, only set FB, RL, AMS, and PMS). But in the process I finally switched over to a HEX file for initializing my ROM (and enabled smart compile), as well as implemented a simple barebones printf over a sorta shitty hacked-together UART terminal output.
<KillaMaaki2>
But most importantly I got a little metallic bell arpeggio playing :D
<andlabs>
good
<cr1901_modern>
My God, why is vgmplay 6000 lines... all I wanted to do was make a twitch widget that displays info about the currently-playing VGM file...
<KitsuWhooa>
if you're on linux, you can use mpris :p
<Lord_Nightmare>
cr1901_modern: current list of identified cells:
<Lord_Nightmare>
F: 4-t cmos 2:1 MUX
<Lord_Nightmare>
H: 3-t cmos 2-input XOR
<Lord_Nightmare>
I: 2-t cmos inverter
<Lord_Nightmare>
G: 5-t cmos 4-input NAND
<Lord_Nightmare>
J: 3-t cmos 2-input NAND
<Lord_Nightmare>
K: 2-t cmos inverter with high drive power
<Lord_Nightmare>
L: 3-t cmos 2-input NOR
<Lord_Nightmare>
N: 5-t cmos 4-input OR
<cr1901_modern>
KitsuWhooa: windows has dbus too...
<KitsuWhooa>
good luck compiling vgmplay with dbus support on windows :p
<Lord_Nightmare>
C and D are nearly identical, so i'm doing those next since i suspect D is either C with an extra inverter on the output, or with a higher-drive power like K has vs I
<KitsuWhooa>
or I guess less compiling and running. It assumes '/' as dir separators
<Lord_Nightmare>
er, other way round: C has the extra/bigger gate
<KitsuWhooa>
*and more
<cr1901_modern>
good work, Lord_Nightmare :D
<KitsuWhooa>
Either way, you can have a look at my dbus code to see how to get metadata out of vgmplay
<Lord_Nightmare>
B, E and M are 5 terminal parts, and A is 6
<Lord_Nightmare>
i'm expecting things like R/S or J/K flipflops
<Lord_Nightmare>
M is weird; its a 5 t device, but the 4th terminal from the left is tied to VCC and it connects to a piece of poly which doesn't go anywhere, it just ends, it doesn't go between two pieces of metal with contacts at all
<Lord_Nightmare>
left over from another cell design perhaps
<Lord_Nightmare>
M is also one of the few gates which has just one single example on the die (the other being N)
<Lord_Nightmare>
I'd actually love to see a decap of an hc55532 to compare to the 55516, i have a suspicion the die is about 95% the same
<Lord_Nightmare>
the only functional difference is how the syllabic filter counts, the integrator is identical
<Lord_Nightmare>
the syllabic filter should have one extra (lsb) internal bit
<Lord_Nightmare>
which isn't used for anything except counting and delaying the rest from clocking for one extra cycle, so it could be done with a single D-latch
<Lord_Nightmare>
well, really a pair of them
<Lord_Nightmare>
gaah, M is very complex. somewhere around 21 transistors, while D has just 8 (4 pairs) which matter for the logic, and then four inverters for /A /B /S and /Y
<Lord_Nightmare>
so D has 16 transistors
<Lord_Nightmare>
some with 2 gates, which i guess count as two transistors connected in series
<Lord_Nightmare>
C has the same number as D, just the two for /Y->Y are more than double the size for the extra current drive (since it feeds the DAC fets)
<Lord_Nightmare>
... very interesting. M is not a CMOS gate. M is NMOS! and that explains that extra contact connecting VCC to the substrate
<Lord_Nightmare>
I wonder why they did this
<Lord_Nightmare>
wait, no. it IS CMOS, but its open collector
<Lord_Nightmare>
there's no gate which connects the output to VCC at all, but there are a few pmos gates
<Lord_Nightmare>
If I had to guess based on where M goes (to the digital output) and what M is probably doing, it is a M: 5-t (really 4-t) cmos d-latch with open collector outputs and inverted output
<Lord_Nightmare>
the inverted /Q output feeds back to a mux which feeds its input, the Q output goes to the digital out pin
<Lord_Nightmare>
presumably the mux gets set to the '/Q' one of its inputs when outputting the quieting pattern which inverts the digital output every clock
<Lord_Nightmare>
and during normal operation it gets set to the other input
<Lord_Nightmare>
I'm getting surprisingly close to being able to build a schematic of this thing and i'm getting excited
<Lord_Nightmare>
need to sleep, tho, its 5am
<Lord_Nightmare>
the next block i'm working on will be E, since with that I can reverse the entire syllabic filter part of the die, the dac/integrator needs A and B. g'night all.
<ValleyBell>
cr1901_modern: "libvgmplayer.a"? There is the GitHub repo "libvgm", which consists of multiple sub-components: libaudio, libemu and ... I think it's called "libplayer".
<ValleyBell>
But there is no documentation yet. The "player" part is also unfinished and may change a lot.
<ValleyBell>
VGMPlay.C (from the "vgmplay" repo) is 6400 lines, because it grew over time
<ValleyBell>
*VGMPlay.c
<ValleyBell>
It grew from "let's see ... how can I write a small VGM player?" into a large mess that needs a rewrite.
Xyz39808 has joined ##yamahasynths
Xyz_39809 has quit [Ping timeout: 260 seconds]
linkmauve has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<KillaMaaki2>
That's pretty relatable tbh haha
<cr1901_modern>
ValleyBell: Screw it, I'll just use the test player for my needs and cannibalize that
<ValleyBell>
make sure to use player.cpp
<ValleyBell>
and not vgmtest.c
<ValleyBell>
(in that case)
<ValleyBell>
libvgm, while not complete, is a lot tidier
<cr1901_modern>
Basically, I have to rewrite the player into a C++ class that's a QThread, remove the chipcontrol stuff, and rewrite kbhit to get keyboard events from the Qt thread
<cr1901_modern>
// Warning: This just serves as a tool for testing features.
<ValleyBell>
okay, yes, using that is fine
<ValleyBell>
Most of the stuff in there shouldn't be too complicated.
<ValleyBell>
You can probably remove the DiskWriter stuff as well.
<ValleyBell>
that would reduce the complexity a lot as well
<ValleyBell>
If you remove that and the ChipControlMode stuff, you can probably reduce the file to half the size.
<cr1901_modern>
I don't need seek and stuff for my app (or I can add it later). Just load an .m3u file, next song, and previous song. And player.cpp already supports the latter two!