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> cr1901_modern: there's already rustls
<whitequark> which is pure rust so you don't need any bindings
andlabs has joined ##yamahasynths
<TD-Linux> I think rustls explicitly does not support nostd tho
andlabs has quit [Ping timeout: 245 seconds]
<cr1901_modern> (Don't tell whitequark, but I didn't actually know about rustls)
<TD-Linux> ah turns out I was thinking about ring. that looks way more hopeful
<cr1901_modern> anyways, I wanted to try bearssl because it has embedded in mind
<whitequark> TD-Linux: rustls does use ring though
<TD-Linux> also I googled more and I'm still wrong. I was thinking of https://github.com/briansmith/ring/pull/738
andlabs has joined ##yamahasynths
<cr1901_modern> And the minute money gets involved, the port dies :P
<cr1901_modern> I wish I had a wad of cash so I could support all the stupid shit I want to do
<cr1901_modern> anyways, looks like neither ring nor rustls is no_std, and so at that point it's a decision... do I want to attempt to make Rust code more portable or hate myself while I create Rust bindings to a C codebase that I already know can do what I want.
<cr1901_modern> Chose to hate myself for the time being, and I intend to get my money's worth :P
<whitequark> yeah I'd use bearssl in this situation I think
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern> https://youtu.be/MbhGQyVPG_c?t=128 I wonder what causes the music here to go completely to hell... I didn't think lag would take out the sound driver
andlabs has joined ##yamahasynths
<cr1901_modern> Foone: Do you know anyone who sells adapters that allow you to siphon power from the keyboard port for parallel port applications? I recall you discussing this once
<cr1901_modern> But maybe it wasn't a sold product, but rather something vendors sold as part of their proprietary dongles?
<cr1901_modern> s/sold/packaged/
ej5 has quit [Quit: Leaving]
<Foone> yeah, it was part of an existing product, not a separate thing
<Foone> you could build one pretty easily, though
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
kode54 has quit [Quit: The Lounge - https://thelounge.chat]
kode54 has joined ##yamahasynths
gruetzkopf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
gruetzkopf has joined ##yamahasynths
<Lord_Nightmare> need two mini-din6 PS/2 connectors one male one female, connect them together (solder the pin 1:1) for passthrough, but tap the 5v and gnd pins. adding some protection diodes (and fuses?) on the 5v line so your device doesn't draw so much current it burns out the PS/2 port is a good move too
<Lord_Nightmare> though it isn't strictly necessary
<Lord_Nightmare> maybe since you're not dealing with reverse polarity a diode isn't necessary except on your device itself
<Lord_Nightmare> but limiting the current somehow (resistors?) i think is a good idea
_whitelogger has joined ##yamahasynths
<cr1901_modern> Lord_Nightmare: I'm prob just gonna suck it up and use a battery and boost an STM32Lx to 3.3v
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 250 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern> Sarayan: Re: tagging you in, Damascus steel is my goto example for "once knowledge is lost, it's difficult to recreate it." But learning recently that the process was lost due to changes in environment, not lack of preserving methods, I've been more careful about using it.
<cr1901_modern> There's not much you can do about preserving an environment across time due to entropy (and it's not something I _like_ thinking about either in the context of preserving the past/old chips, so I don't :P)
andlabs has joined ##yamahasynths
<cr1901_modern> Thank goodness YM2151 is an easy chip in this whole "emulation vs real thing" argument.
<cr1901_modern> I can "just" say "the graph of state transitions within an emulation should be isomorphic to the state transitions allowable based on the NMOS technology at the time". And *cough* iterate *cough* on that statement.
<cr1901_modern> Then I can bullshit by saying "analog emulation is done on a best effort, I make no guarantees" :P
<cr1901_modern> Foone: Did anyone ever actually figure out what causes the PilotWings crash? A VERY long time ago, I started a DSP1 binary disassembly: https://code.google.com/archive/p/dsp1-disasm/source/default/source
<cr1901_modern> for the express purporse of figuring out that crash, but I never finished it
<Sarayan> ym2151 is 100% digital, that's the #1 thing that makes it "easy"
<cr1901_modern> Well I _think_ it's 100% digital- I haven't seen any indication of copy protection like you saw in 68k or z80, and other than the reg file, I think it's fully synchronous as well.
<Sarayan> what do you mean by "synchronous"?
<cr1901_modern> all state transitions happen with respect to the clock
<Sarayan> then I'm not sure why you'd exclude the register file
<cr1901_modern> Because as physically implemented, reg file RDs and WRs take effect after qualified with /CS /RD /WR
<Sarayan> really, it's not clock-synced?
<Sarayan> I'm kinda surprised
<cr1901_modern> The timing diagrams for RD/WR do not have a clk signal
<Sarayan> in fact, it's actually impossible since the reg file afaict is a bunch of clock-synchronized circular shift registers
<whitequark> ^
<Sarayan> so even if there's an async buffer the final write is sync
<whitequark> i think there is a pair of DFFs at the front of register file
<cr1901_modern> Perhaps there is a write/read buffer
<whitequark> that latch the address and data
<whitequark> but the actual write is definitely synchronous
<cr1901_modern> Wonder why they omitted that from the timing diagrams (don't answer this)
<whitequark> lol
<whitequark> so you'd have an exciting time figuring it out
<cr1901_modern> Sure, let's go with that :).
<Sarayan> they don't really document the write delays in the first place
<whitequark> and they change from mode to mode
<whitequark> OPL3-in-OPL2-compat has some really bizarre write latencies
<Sarayan> probably from register to register too, right? since it depends on the rotation width
<whitequark> not only they are different from OPL3 mode, but I also am not sure how they form in first place
<whitequark> hm
<whitequark> I mean maximum latency
<whitequark> I'm not sure if /IC even resets the register bucket brigade
<whitequark> probably does?
<Sarayan> well, we'll know once cr is finished :-)
<Sarayan> wq: it's enough if it resyncs the global position counters
<whitequark> yes, that's what i meant
<whitequark> speaking of which
<whitequark> I recall someone mentioned /IC resets everything *except* the register content
<whitequark> which I guess makes sense, it is a routing nightmare
<Sarayan> yeah
<whitequark> so I should wire /IC to Glasgow Yamaha applet and see if I get sample for sample identical files
<Sarayan> in what I've done of the 2203, there's no reset lines to the individual buckets
<whitequark> problem: OPL3 takes all 16 pinson Glasgow
<whitequark> solution: ditch /RD, who needs that anyway
<Sarayan> you need a bigger Glasgow
<whitequark> yes
<whitequark> that is called revD
<Sarayan> nice
<cr1901_modern> Why use /RD when you can count :D?
<cr1901_modern> Can your FPGA count up to 72? Congrats, you don't need /RD
<whitequark> you actually don't have the BUSY bit on OPL, OPL2 or OPL3
<whitequark> and I didn't even hook OPL4 yet because it is a giant ass SMT package
<whitequark> that needs extermal SRAM
<Sarayan> bedtime says the wife
<Sarayan> see you all
<cr1901_modern> sleep well
<whitequark> nini
<cr1901_modern> Ahhh the /RD line must be only used for timers and IRQs then in OPL?
<cr1901_modern> (won't matter for PC soundtracks; the IRQ was never connected, so the timers AFAIK aren't used except for detection of an Adlib card)
<whitequark> only timers, yes
<whitequark> oh
<whitequark> lol what
<cr1901_modern> One of the "suggested methods" by Adlib themselves to detect the presence of an Adlib card is to query the timers
<whitequark> no i meant the irq part
<cr1901_modern> Oh yes, that seems to be a common theme w/ old hardware using Yamaha chips. :/ It ticks me off.
<cr1901_modern> The IRQ is perfect for getting a time base- WHY DON'T YOU USE IT?!
<cr1901_modern> Genesis didn't connect it either (routing pressure?)
<cr1901_modern> In Genesis' case, you have a 50/60 Hz interrupt, but still...
<cr1901_modern> x68k connects the IRQ line
* cr1901_modern verified with schematics lol
<superctr_> you can still poll the timers
<superctr_> even if they are not connected to IRQ
<cr1901_modern> I don't think that's useful for a sound driver that has to coexist with the rest of a game
<superctr_> it does suck compared to IRQ since you can't get smooth sample playback for example
<superctr_> on the megadrive, it doesn't have to because it runs on its own CPU
<superctr_> actually you can get smooth playback with polling but it's a bigger CPU load
<cr1901_modern> I'm really not sure how, tbh... :(
<superctr_> one thing though, the Z80 is halted when it tries to access 68K ROM space while VDP is doing a DMA transfer
<superctr_> other than that, the Z80 is pretty much independent
<cr1901_modern> Alright, I think I can see that
<cr1901_modern> sample playback on Genesis already destroys performance, so I guess it's not a huge deal to poll as well. And perhaps write the rest of the driver on the 68k side
<superctr_> GEMS can do decent sample playback while already doing a shit ton of stuff on the Z80
<superctr_> sega were just really lazy when they wrote SMPS-Z80 and that gave the console a bad reputation for sample quality
<superctr_> SMPS-68K has OK sample quality but could be improved, just like with the SMPS-Z80, when the rest of the sound driver (in this case running on the 68k) is accessing the FM chip, the Z80 and thus sample playback is halted
<superctr_> SMPS-Z80 will only play samples when the rest of the sound driver is idle
<cr1901_modern> i.e. the "lowest priority task" in a task manager?
<superctr_> and they actually use a cycle-timed loop to time the samples, so the frequency fluctuates
<superctr_> the DualPCM Z80 driver has a few features to improve sample quality, for the 68k, instead of accessing the FM chip directly it can write to a command queue which the Z80 will read whne it is free
<superctr_> the 68K side needs to be modified for this of course
<cr1901_modern> Or make a totally new 68k sound driver that does everything except the actual register writes :P
<cr1901_modern> and talks to z80 via a queue like you said
<cr1901_modern> DualPCM reminds me of a cut down version of the MOD player from Toy Story
<cr1901_modern> (which did 4 PCM samples at once on the 68k side)
<superctr_> Stef has a 4 channel Z80 driver
<superctr_> it doesn't have any fancy queues or anything, but it does have volume control
<cr1901_modern> volume control is good :)
<cr1901_modern> Random thought I want interrogated/dissected... one could do a Yamaha sound driver on a laptop, and then use e.g. Glasgow iso xfers to do the actual chip writes. Iso xfers specifically because on a system w/ parallel buses already like ISA, you don't wait for ack of a write, and you sound is f***ed anyway if somehow a bus write is missed.
<whitequark> glasgow doesn't do iso
<whitequark> right now anyway
<whitequark> also you could still use bulk without ACK
<whitequark> i.e. bulk out only
<cr1901_modern> bulk without ACK? The device will need to send an ACK, NAK (or nothing) back, correct?
<cr1901_modern> Anyways that'll work too, was a random thought about how all those old sound driver writes had to "just work the first time" or things went to hell :P
<whitequark> i mean, it's transparent to software
<cr1901_modern> oh, right
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]