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 has joined ##yamahasynths
<cr1901_modern> (6:04:32 PM) ***cr1901_modern contemplates starting on a personal project. His first one in months <-- Well, that went absolutely nowhere. How's _your_ personal project coming along, ej5?
<ej5> which one
<cr1901_modern> the MCA card
<ej5> so the guy who sent me the photos of the MCA adlib says it doesn't work in his model 80. and now i know why
<ej5> the timings don't match up, the YM3812 is too slow for the MCA bus in his model 80.
<ej5> it *should* work in my model 50 which has a 300ns I/O bus cycle time. but the model 80 has a 175ns cycle time!
<cr1901_modern> ahhh interesting
<ej5> well technically 200ns
<cr1901_modern> This sounds analogous to the problem w/ early ISA
<ej5> i guess the folks at ad lib didn't do all the engineering work to get MCA to work on all the machines
<ej5> because the model 80 was already out when they were working on the card.
<cr1901_modern> AIUI, on 8088 and 286 machines, ISA clock was synchronous to the CPU clock, up to 25MHz in the most extreme case. Then 386 and above chipsets pinned it to 8MHz (or 4.77MHz, I forget). I wonder if IBM made the same mistake with MCA?
<ej5> they did not, MCA could run pretty fast
<ej5> i think the peripheral makers messed up and assumed it wouldn't run that fast
<cr1901_modern> Damnit you're making me want to spend money (I don't have!)
<cr1901_modern> to get an MCA machine and some cards
<ej5> what ad lib should have done was use the extended asynchronous cycle which would have automatically added wait states
<ej5> block diagram of the model 80: https://cl.ly/d0c724043a4c
<ej5> you can see that main memory is on the MCA bus
<ej5> basically they'd add wait states to account for slower peripherals
<cr1901_modern> interesting, MCA has ISA-compatible bus signals (let me elaborate)?
<cr1901_modern> I consider the MCS-85 peripherals like the DMA controller, the PIC, the PIT, etc to be ISA-compat.
<cr1901_modern> It's possible to make them play nice w/ MCA bus signals?
<cr1901_modern> based on that block diagram
<ej5> hmm, someone has schematics of the model 50 and the model 80
<ej5> oh yeah and the ad lib card uses LS logic which is super slow, very bad
<ej5> they should have used F or HCT.
<cr1901_modern> F series is what I used for FPGA floppy disk experiments
<cr1901_modern> FPGA just can't sink the pure unalderated power of TTL without a nice buffer
<cr1901_modern> ej5: If you get the schematics, could you paste a link? I am now curious
* whitequark whispers: or a glasgow
<cr1901_modern> Oh, you no longer need a 74HC daughterboard?
<cr1901_modern> ej5: Tyvm
<cr1901_modern> whitequark ^^ (whoops)
<whitequark> cr1901_modern: absolutely not
<ej5> there are mistakes on those schematics fyi
<whitequark> revC interfaces with floppies directly
<whitequark> no pullups, no buffers
<whitequark> it's pretty neat how it works with anything from "floppies from 1980s" to "latest intel eSPI horror from 2010s"
<cr1901_modern> mmm what level shifters are used? I want to check the datasheet. Because my first attempt at doing TTL interfacing on floppies, even w/ a level shifter (some HC part?) sincerely did not work due to sink problems.
<cr1901_modern> I mean, if it works it works :P. Just surprised
<whitequark> SN74LVC1T45
<whitequark> I've specifically designed it to operate correctly with TTL levels
<whitequark> it's not a coincidence
<whitequark> we looked at the shifter impedance, inline resistors, and the TTL specs
<whitequark> it's not *completely* in-spec in that if you have a really huge TTL fanout it might go outside of the allowed zones, but it seems unlikely for any reasonable use
<whitequark> and it's certainly in-spec for floppies
<cr1901_modern> It says 32mA. Guess that's enough
<whitequark> it's more complex than that bc you have to consider the complete IOB impedance
<whitequark> but anyway
<whitequark> also, those shifters are monstrous
<whitequark> they can dissipate a *watt* for a *day* with no visible degradation of silicon
<whitequark> have you seen SOT-563? it's smaller than a matchhead.
<whitequark> considerably.
<whitequark> in fact, it's so small, it's the single finest pitch component on the board, including the BGAs...
<TD-Linux> the SN74LVC1T45 is excellent
<TD-Linux> I'm using the wider variants on GlasgISA
<TD-Linux> and use them on midiori and cbus-joystick as well
<andlabs> SN74LVC1T45
<andlabs> can the 74xx series part numbers get any more nonsensical
<TD-Linux> it's not 74xx. it's TI
<whitequark> yeah the only real problem with it is it's too fucking small
<andlabs> yes, and TI created the 74xx series
<cr1901_modern> SN is TI's code
<cr1901_modern> LVC- Low Voltage CMOS
<whitequark> oh wait, LVC1T45 *does* come in sane packages
<whitequark> oh it comes in WLCSP too.
<whitequark> clearly we should have used that.
<whitequark> for maximum photosensitivity
<whitequark> *flash* the board explodes
<TD-Linux> whitequark, yeah it comes in nice packages. the 8T variants comes in ezpz SOIC
<cr1901_modern> Grepping for SOT-563 in the datasheet returns nothing
<cr1901_modern> not that means much
<whitequark> page 27
<andlabs> the SN7400 quad NAND gate was so wildly successful that TI just reused SN74 as the prefix for their other logic chips
<whitequark> they call it SC70
<andlabs> and other manufacturers started cloning these logic chips to create the 74xx ecosystem
<andlabs> I wonder which is more resilient nowadays, the 54xx or the 74xx
<andlabs> (ceramic cap or plastic cap)
<cr1901_modern> Only the 1T45 is weird to me. But the "1" is called e.g. "8" on the equivalent part w/ 8 ports
<cr1901_modern> T45- who knows?
<cr1901_modern> Sorry, it's called 8T245*
<whitequark> T is for tristate i htink
<cr1901_modern> so my guess is TI wanted to derive a proper level shifter from the 245, which can also be used as a limited level shifter. And then tacked on some extra codes to synthesize a new 7400-series family member
<cr1901_modern> Ack re: tristate
* cr1901_modern needs a _modern_ TTL handbook. For modern people. Bastardizing retro hardware.
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern> andlabs I think 5400 is milit- oh, he's gone
Xyz_39808 has joined ##yamahasynths
andlabs has joined ##yamahasynths
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 276 seconds]
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 245 seconds]
Xyz39808 has quit [Ping timeout: 250 seconds]
<cr1901_modern> https://github.com/sikthehedgehog/Echo Open source z80-based Genesis sound driver- TIL
Xyz_39808 has joined ##yamahasynths
Xyz_39808 has quit [Client Quit]
<TD-Linux> cr1901_modern, not much has changed from ye olde TTL
<TD-Linux> for bidir translation use the *T245
<TD-Linux> for 3.3 to 5 use LV
<TD-Linux> for 5 to 3.3 use LVT
<TD-Linux> *LV1T for 3.3 to 5
<cr1901_modern> TD-Linux: I still manage to always screw it up. LVT was not enough for floppy experiments b/c of sink strength problems.
andlabs has joined ##yamahasynths
<Foone> apparently I'm blocked by them, but I was able to see it in incognito. weird!
<whitequark> huh, me too
<Foone> I mean the RAM chips are weird
<cr1901_modern> Oh dear ._.
<TD-Linux> tbh for several designs I just use 8T245's and hardcode the DIR pin
<cr1901_modern> oh sure. That's what I should use going forward.
<TD-Linux> LVT is 3.3v supply max. using it to drive 5V won't work
<cr1901_modern> TD-Linux: Replace with the part family I meant :P. It was one of the Low-Power-Schottky ones
<cr1901_modern> oh screw it... it was _a_ family
<cr1901_modern> And it didn't work
iwxzr has quit [Ping timeout: 246 seconds]
iwxzr has joined ##yamahasynths
Stilett0 is now known as Stilett0-out
<whitequark> OPL2 overclocked to 12 MHz produces absolutely *incredible* glitches on the output
<whitequark> it's like if a modem went to a music school
<whitequark> holy shit
<cr1901_modern> Didn't you already overclock opl3 to generate music for the webapplet and it worked fine (I'll listen in a minute)?
<whitequark> cr1901_modern: opl2
<whitequark> and it wasn't that far
<whitequark> in fact i could swear the opl2 was overclocking better before
<whitequark> i might have overvolted it too? not sure
<cr1901_modern> ahhh, well I propose an applet for glitch music with your new discovery :P.
<emily> whitequark you are making me stream a 25 megabyte wav from like
<emily> fucking hong kong
<whitequark> emily: singapore
<emily> singapore.
<whitequark> yes.
<whitequark> i am making you stream a 25 megabyte wav from singapore.
<emily> lee kuan yew would not approve of this inefficiency.
<emily> on the other hand this actually slaps
<whitequark> hahaha
<whitequark> so the thing is
<whitequark> i looked at encoding flac from python
<emily> you can literally just shell out to flac
<whitequark> and decided, fuck that
<emily> in like
<emily> one line
<whitequark> yeah no
<whitequark> gross
<emily> it's unix. you know this
<whitequark> it's portable!
<whitequark> glasgow runs on windows!!!
<emily> so does flac!
<whitequark> well fuck
<emily> it literally has a defined command-line interface!
<emily> people write batch scripts and shit
<whitequark> look. if i can't link to it it doesn't exist
<whitequark> next you'll tell me to shell out to ffmpreg.
<emily> what kind of "link to it"
* cr1901_modern looks for his headph- why did you say ffmpreg again?
<whitequark> emily: like. dlopen
<emily> you're literally using python and you want to use dlopen.
<emily> i mean, i think there's a libflac. you could use ctypes.
<whitequark> mhm
<whitequark> yes
<whitequark> but i don't wanna write it myself.
<emily> seriously I'm pretty sure the stable recommended interface to flac for basic encoding/decoding tasks is the command line :p
<emily> like it's how other tools use flac IME
<whitequark> this makes me not like flac a lot.
<whitequark> i should just encode to mp3
<emily> i mean, same with LAME?
<whitequark> ok let me rephrase
<whitequark> i fucking hate audio
<cr1901_modern> that's normal
<emily> gosh
<emily> just write your own flac encoder
<emily> how hard can it be
<emily> glasgow is going to grow one eventually i'm sure
<whitequark> ;w;
<cr1901_modern> compression is annoying
<emily> you can do it in gateware!
<emily> that actually sounds fun
<cr1901_modern> and the flac spec expects you to be an expert in iyt
<whitequark> compression in gateware is VERY hard.
<cr1901_modern> btw, whitequark, that link is beautiful
<whitequark> i'm pretty sure this FPGA isn't even remotely large enough
<emily> oh, yeah
<emily> i guess decoding is way easier
<cr1901_modern> I sometimes link one of the more popular streamers of this type in here; there is a popular genre of Twitch streaming where one takes games, randomly changes bytes in the .text/.data sections, and then observes the results. It's called "ROM corruption". >>
<cr1901_modern> FM music driver .text of FM parameter .data corruptions are absolutely hilarious/beautiful to me when done right. I think overclocking is a new genre
<whitequark> lol
<emily> whitequark: btw if you feel this way about audio i can't *imagine* what your feelings on video are
<whitequark> emily: video doesn't exist. end of story
<cr1901_modern> whitequark: Sonic 3 music driver has a bad day example https://www.youtube.com/watch?v=0LG9CT2nnv8
<cr1901_modern> One of my favorite is when one of the channels is modified to play slower, so the whole tune slowly goes out of sync- it's like the poor OPN chip is trying, but the bassist/drummer was drunk.
m4t has joined ##yamahasynths