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
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Lord_Nightmare>
also that card uses an MC3418 CVSD chip
<Lord_Nightmare>
and is the origin of the Wavefile format IBM_CVSD
<Lord_Nightmare>
which get this: never had a proper ACM codec, it would LITERALLY USE THE CHIP ON THAT CARD FOR ENCODING/DECODING
<Lord_Nightmare>
also if you have the driver disk for that card PLEASE read it out
<Sarayan>
huhu, poor foone
<Lord_Nightmare>
that 33F4457 chip, is that a rom?
<Lord_Nightmare>
i guess it could be some other i/o chip
<Lord_Nightmare>
also does the manual which came with that card have a schematic
<Lord_Nightmare>
I believe that card could act as a DAC (and ADC?), or a CVSD codec (encode from mic and decode to speaker), or use the TSP5220C TI PE-LPC chip for speech
<Lord_Nightmare>
the pitch of the TI chip i believe is set by that blue potentiometer, if you get a chance please measure what pin 3 of the tsp5220c chip oscillates at, which will tell us what clock rate the tsp5220c is trimmed for
<Lord_Nightmare>
I suspect it will oscillate at either 160khz or 200khz which correspond to clock rates of 640khz or 800khz, which were the most commonly used clock rates for the tsp5220c
<Lord_Nightmare>
romclk is a clock out pin; trying to directly measure the osc (clock in) pin will throw off the r/c clock by a lot
<Lord_Nightmare>
romclk gives the clock in signal divided by 4 (or 2 for special tsp5220 mask revisions, but these are very rare)
<Lord_Nightmare>
I have a funny feeling btw that the street electronics echo2 card for apple2 may have used the funky mask rev
<Lord_Nightmare>
and if it did, i have to add a bunch more tms5200/5220/5220c revisions to mame... (the tsp5220c and tms5220c differ in one way: the printed silkscreen on top of the chip. that's it, apparently.
<Lord_Nightmare>
the number in the corner of the chip (3358) has to do with mask options and who the chip was manufactured for, so knowing that the PS/2 speech adapter uses 3358 is good
<Lord_Nightmare>
MAME doesn't actually emulate any of the mask options and to be honest i don't know what they actually do or where on die to look for them
<Lord_Nightmare>
I know of the clock divider one only
<Lord_Nightmare>
but clearly there must be others
<Lord_Nightmare>
Foone: ok, i'm done
* Sarayan
wipes LN's drool off the channel
<cr1901_modern>
So LN wants a chip dumped I see
<cr1901_modern>
Due to circumstances from this morning (biopsy/, it's unlikely I'm going to do any meaningful work today, so I'm gonna use the time to pose a q I was thinking about...
<cr1901_modern>
err s/biopsy//, but most ppl know already so *shrugs*
<cr1901_modern>
A few ppl, incl Foone, posed a q about "what is a minimal set of commands to drive a Yamaha chip and have it make sound".
<cr1901_modern>
Someone else (I think it was wq) proposed a small language for driving a chip and have the results play in an emulated environment. That was what I was trying w/ the Python experiment a few days ago.
<cr1901_modern>
I realized: "couldn't MML be used for that purpose like a REPL?"
<cr1901_modern>
But... MML kinda sucks to write if you're not used to the syntax
<cr1901_modern>
(And Xyz39808 hates it :P)
<cr1901_modern>
Which makes me think... whitequark, if you were designing a language that was meant to drive a sound chip, that was easy to play around and make sound in, what would it look like (to a first approximation)? No need to answer now. I just wanted to minddump while it's fresh in my head.
<Lord_Nightmare>
kevtris made his own scripting language for driving an allpro programmer
<Lord_Nightmare>
driving the various pins low/high/pullup/pulldown/high-z
<Lord_Nightmare>
and clock
<cr1901_modern>
Right I've seen that too
<Lord_Nightmare>
but this seems less relevant here
<cr1901_modern>
it compiles down to a FPGA CPU with instructions that were tailored for ROM programming
<cr1901_modern>
I think like a quarter of the address space is dedicated to that old Cortex-M feature where you can do atomic writes on GPIO
<cr1901_modern>
whatever it's called
<cr1901_modern>
Bit banding*, that's it
<Lord_Nightmare>
whitequark has nmigen, is that what you're talking about?
<cr1901_modern>
Lord_Nightmare: Honestly, I'm thinking I'm talking about something different that kevtris did
<cr1901_modern>
nmigen wasn't what I had in mind
<cr1901_modern>
I wanted something like MML but not terse
<cr1901_modern>
compiling down to a "VM" optimized for talking to a sound chip
mofh_ has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
andlabs has joined ##yamahasynths
_whitelogger has quit [Ping timeout: 248 seconds]
_whitelogger has joined ##yamahasynths
emily has quit [Ping timeout: 240 seconds]
andlabs has quit [Ping timeout: 248 seconds]
andlabs has joined ##yamahasynths
<ValleyBell>
andlabs: re vgmrips: I think one date is the "added to the site" date (2020-02-09) and the other dates (2019-xx) are either "last update of the pack by the author" or "initial submission date".
<ValleyBell>
I don
<ValleyBell>
't maintain the main page though, that's vampi's task.
emily has joined ##yamahasynths
<andlabs>
ok
<andlabs>
vampi as in ... uhhh I forget their username already
<andlabs>
trying to remember if I share any chat rooms with them
<ValleyBell>
vampirefrog / vampi-the-frog
mofh_ is now known as mofh__
<Lord_Nightmare>
foone: see backlog when you get back
<Xyz39808>
mml is love. mml is life
<Xyz39808>
despite having no arpegio envelope or forbidding the pitch down command on FM channels, mgsdrv is the most fun driver I've played with so far. XPMCK is the most programmer like and can be fun to play with parametered macros, but overall is a little too buggy.
<superctr>
basically ASM macros for a text-based tracker
<superctr>
you really don't need a lot of code to convert this to sound output in a sound driver
<superctr>
MML is nice though. I am working on a MML sound driver for MD. I have written a compiler and VGM output is working, but i've really been slacking on the actual sound driver implementation
<Xyz39808>
that said, I think mmldrv and whatever the fuck SPFM is
<Xyz39808>
is already what you're asking for.
<Xyz39808>
I _think_ MAmidiME might be able to output to hardware as well, but I'm not 100% sure. I believe for driving the hardware "GIMIC" they use popular driver filetypes like PMD's .m and whatever it is that NRTDRV outputs for the SharpX1 and other computers have simliar drivers
<Xyz39808>
kuma's mml2vgm might be a dead since all the vgm metadata would be included in the output and wouldn't be a "minimal set of commands to drive a Yamaha chip and have it make sound".
<superctr>
well, as for MML compilers. in this case you're mostly concerned about writing a program that takes some input (that is easy to generate, perhaps even directly in a text editor or hex editor) and outputs through an FM chip
<superctr>
so an MML compiler has to generate a good enough bytecode, as that is what your program will read in that case
<superctr>
VGM is best when it comes to versatility, as you can use a lot of different tools to generate VGM files. But it's not very size-efficient, and especially it's not easy to generate by hand
<Xyz39808>
just thinking on it, most existing compilers wouldn't quite be minimal since the expected users are going to be making music and full songs, not just a few register writes. So there'd always be extraneous data for getting that set up, like software vibrato or tables or software tempo.
<superctr>
you can of course read MML directly, but then you're writing your own MML compiler, unless you find something that's lightweight enough to run on whatever embedded system this is
<Xyz39808>
for small enough sounds, .vgm without header data would be sufficient I think
<Xyz39808>
don't need to worry about the ineffeciency of repeated data if the tiny test has no repetition
<superctr>
the file i linked gets converted to a bytecode format, which consists of handful of commands, that each takes a bitmask of FM channels affected by the command and then a number of bytes that each corresponds to the channels in the bitmask
<superctr>
unlike most MML bytecodes you don't need to worry about simultaneous streams, so it's closer to VGM. Except much more space optimized since it's a higher level
<superctr>
VGM is very low level since it's direct register writes. Especially if you _do_ use software envelopes the files will be very big
<superctr>
now that i think of it. MIDI can be an option too. Either streamed through serial the classic way or stored in memory. But it will likely involve more commands to parse
<Xyz39808>
in short, the minimalist way to do it is to read a datasheet with the sound registers and write a very short program in hexcodes just to make _a_ blip. Probably not a very good sounding blip, but a blip nonetheless
<superctr>
yeah, that's definitely the fastest way just to get sound
<superctr>
if you want to actually write a song it'll get annoying fast
<Xyz39808>
it's annoying even at just making a sound
<Xyz39808>
but it is minimal
<Lord_Nightmare>
Foone: you're in luck
<Lord_Nightmare>
foone: i have one of those action replay pc units, but it isn't mine; it was lent to me by the original owner, and has been sitting on a shelf here for almost a decade waiting for the surfacemount PALS to be desoldered/dumped
<Lord_Nightmare>
if you and the owner can get in contact, and are willing to dump the pals for preservation...