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> that explains why the behringer mixer with motorized sliders my brother bought uses the exact same command protocol and layout as a product made by one of their competitors at like half the price
<Lord_Nightmare> it seemed pretty decent quality, though...
<cr1901_modern> >and also even in japan people didn't get fm
<cr1901_modern> Could've fooled me
<cr1901_modern> Anyways GEMS bugs me b/c- according to the Sega wiki- the speed is baked into the stream of data the music reads
<cr1901_modern> so changing the speed implies recreating the entire track
<fseidel> I don't know of a format where that isn't the case
<cr1901_modern> It's not how I'd write a driver
<fseidel> usually just a single byte changes though
<cr1901_modern> >While in games using other drivers, such Alien Soldier or Shinobi III basic behaviour such as playback speed is controlled by a single variable (which can be easly manipulated by an action replay or hex editor), GEMS has to change the data of the whole music track stored on the ROM for the same effect
<fseidel> not sure what GEMS looks like, but for most of the formats I've seen, there's a tempo byte specifying how many VSYNCs until advancing
<fseidel> OH that's waht you mean
<fseidel> yeah that is bad
<fseidel> I didn't realize it behaved like that
<cr1901_modern> Tbh, I'm not sure how GEMS implements this either such that "you have to change the whole track to change the speed"
<fseidel> that's really odd too, seeing as GEMS was designed to let the composer do dynamic music effecs
<fseidel> *effects
<fseidel> and tempo changes were bog standard
<fseidel> assuming they have the standard "count down every vsync and if counter hits 0, fetch next set of note data" setup
<fseidel> it may be that there's no global timer to set the update frequency for each of the per-channel counters
<fseidel> on most drivers I've seen, each channel has a delay for note length, but that only ticks down once every GLOBAL_TIMER frames
<fseidel> if you get rid of GLOBAL_TIMER, you have to bake an absolute number of frames into the per-channel timer values, which are baked into ROM all over
<cr1901_modern> even having a global timer will have "delays" backed into the ROM all over; that's not a problem IMO.
<cr1901_modern> The problem IMO is baking an absolute time reference into the ROM
<cr1901_modern> rather than having a layer of indirection that GLOBAL_TIMER gives you
<cr1901_modern> (anyway that's how I'd write a driver...)
<cr1901_modern> I imagine at a 10,000 ft view all the drivers look mostly the same, except with interpretation of bits swapped around :)
<cr1901_modern> (Just like RISC CPUs :D)
<fseidel> oh, so have an interface for the software to choose the tempo at runtime?
<cr1901_modern> Doesn't have to be at runtime... it can be hardcoded for NTSC, then you choose a different value for PAL
<cr1901_modern> or something like that
<cr1901_modern> the point is to keep the tempo info in one place
<cr1901_modern> But yes, it could be at runtime
<cr1901_modern> That's prob how Sonic 1-3 speeds up the music during speed shoes
<cr1901_modern> without knowing anything about Switching Mode Power Supply music driver
<cr1901_modern> All things being equal I would also write a Genesis sound driver for the 68k, so I can use C
<fseidel> lol, I knew about the driver first, so I think sonic music driver for a sec when I read the PSU abbreviation :-P
<fseidel> seems to indicate that they have a per channel tempo baked into the music data stream, and then a tempo divider that scales it
<fseidel> and the divider is adjustable I think
<cr1901_modern> Probably easier to do per-channel tempo. In my scheme, I would have to manually verify that each channel actually has the same length
<cr1901_modern> since tempo would be global
<Lord_Nightmare> if nukeykt is around can someone ask him what the vrc7 debug mode does? I need more information to duplicate it locally
<Lord_Nightmare> and how to probe it
_whitelogger has joined ##yamahasynths
<cr1901_modern> Lord_Nightmare: Fwiw, nukeykt has a twitter account at the expected handle. But he doesn't appear to check often.
<Wohali> cr1901_modern: what's our board count at
<cr1901_modern> 18 + 14 + 6 + 5 =43
* Wohali goes to chec prices
<Wohali> ok, so I'm looking at about $3.75 per board (USD) plus S&H
<Wohali> nice and cheap.
<cr1901_modern> Holy crap
<cr1901_modern> Woooooooow ._.
<cr1901_modern> That's so amaz
<cr1901_modern> Segmentation Fault
<cr1901_modern> $root@cr1901 ./irc
<cr1901_modern> ing
<Wohali> 1.6mm pcb thickness, blue, 2oz copper (fancy!), gold fingers with a 45 degree chamfered border, flying probe testes
<Wohali> i could bump it to a full board test and only increase hte per-board price to $4.30 each, I might do that
<cr1901_modern> Green has been winning the poll
<Wohali> oh? then it's even cheaper. sec
<Wohali> eh, about the same price actually
<cr1901_modern> Cool
<Wohali> somewhere between 3.75/board and 4.50/board
<Wohali> the higher end just being more board-level testing to ensure quality
<cr1901_modern> That is still amazing...
<Wohali> what's the poll at?
<cr1901_modern> you should have edit privs
<cr1901_modern> note: I haven't added myself to the list yet
<Wohali> wow, 68% to 32%
<Wohali> so yeah, clearly green over blue. fascinating.
<cr1901_modern> The populace has spoken
<Wohali> so i would say
<Wohali> tweet it one more time monday
* cr1901_modern nods
<Wohali> i am heading out to VCFPNW end of next week
<Wohali> i'll put the order in before i go
<Wohali> the boards should arrive around the time i get home
<Wohali> and I'll be able to start mailing them out the week after
<Wohali> so around apr 1
<cr1901_modern> Excellent... gives me time to start collecting parts off the BOM
<cr1901_modern> At some unspecified point in the future, I want to do a RISCV-based ISA card system. Nominally open source hardware. So snark barker provides the sound :3. Probably more than enough code online to siphon from to make it work.
<Wohali> <3 risc-v
<Wohali> you going to fpga it or use the SiFive silicon?
<cr1901_modern> former; I don't think sifive exposes enough of the addr/data bus to make an ISA system work
<cr1901_modern> RISC-V thoughts in < 10 words: Insn Encoding is wonderful, the privileged spec bites.
<cr1901_modern> thankfully I don't need the latter for an 8-bit ISA-bus based system
<cr1901_modern> Wohali: Another potential reason to use FPGA... add custom insns for doing port-mapped I/O
<cr1901_modern> just like old x86
<Wohali> whatever floats your boat, buddy
<cr1901_modern> I take it you like SiFive's offerings?
<cr1901_modern> I think they made a new version of the HiFive board
<cr1901_modern> that was _just_ released
<Wohali> it's on crowd supply, not yet shipping https://www.crowdsupply.com/sifive/hifive1-rev-b
<Wohali> shortly tho
<cr1901_modern> ahh oops
<Wohali> i know bunnie, he's a cool dude, crowd supply is basically his thing
<cr1901_modern> I don't see bunnie much on IRC these days... his partner on a bunch of projects (xobs) I talk to semi-regularly
<Wohali> mm
<Wohali> it's been like 10 years since we've connected tho
<cr1901_modern> very small world we live in
<cr1901_modern> I'm surprised how many ppl I know who also know other ppl who I met for unrelated projects/reasons :P
<cr1901_modern> I think I plan to get two snark barkers: One to put together, and the other for when I inevitably destroy a trace on the first one :)
<Wohali> heh
<cr1901_modern> ej5: Request... demo the snark barker, but replace tada.wav with this: https://www.youtube.com/watch?v=D-kVjGWq4L4
<TD-Linux> <cr1901_modern> Wohali: Another potential reason to use FPGA... add custom insns for doing port-mapped I/O <- no
<TD-Linux> you *should* make an x86 real mode emulator that talks to the native peripherals, though
<cr1901_modern> Well, there needs to be a way to distinguish address spaces. I guess I could just use the top two address bits to create separate addr spaces
<TD-Linux> yeah just map io space into mmio somewhere
<TD-Linux> it's just 64k
<Wohali> i wouldn't extend the ISA, but I could see FPGA to stick the riscv core in there, then extend the GPIOs
<Wohali> which is basically what td-linux is saying
<Wohali> i need to look at the FE310 specs a bit closer
<cr1901_modern> I'd need an FPGA anyway even if I were using SiFive; it's not like there's a huge market for "RISCV that understands the ISA bus cycle"
<cr1901_modern> So I'd have to convert (or use posted writes, which I don't want)
<Wohali> think you're overthinking it, but sure
<Wohali> (ironically, if we get >50 board orders, the price jumps a bit until we get cloesr to 75 board orders)
<Wohali> (but, no worse than ~$6/board)
<TD-Linux> what board house are you doing
<Wohali> himitsu
_whitelogger has joined ##yamahasynths
<ValleyBell> >GEMS has to change the data of the whole music track <-- this is nonsense
<ValleyBell> In GEMS sequences you have a "set tempo in BPM" command with 1-byte parameter.
<ValleyBell> Action Replay might be difficult due to everything being on the Z80
<ValleyBell> and IIRC the BPM value is converted into a 8.8 fixed point "frame step" value.
<ValleyBell> After each VSYNC it does FrameCounter += FrameStep and if FrameCounter is >= 0x100, it advances 1 tick. (which is 1/24 quarter note)
<ValleyBell> What GEMS can NOT do easily is the PAL adjustment. Due to that reason, they often adjusted the song tempo manually.
<ValleyBell> (Most SMPS drivers do the PAL speed fix by executing everything twice every 5th frame. Sonic 1 does not, btw.)
nukeykt has joined ##yamahasynths
<Lord_Nightmare> cr1901_modern: the 'nukeykt' twitter account appears very very dead
<Lord_Nightmare> ah and of course, as soon as i said that...
<Lord_Nightmare> hi
<Lord_Nightmare> nukeykt: i was trying to figure out how to contact you
<Lord_Nightmare> I wanted more details about how the vrc7 test mode works, since i'm trying to figure out how to duplicate it on breadboard
<nukeykt> In debug mode VRC7 is very similar to 2413 as. /IC, /CS, /WE, A0 pins are there. Connecting it like YM2413 is first important step. Try to connect GND, 5v, audio out and crystal like there https://wiki.nesdev.com/w/index.php/VRC7_pinout with pin 15 being exception. Pin 7-14->D0-D7, Pin 4 -> /CS, Pin 27 -> /IC, Pin 28 -> /WE, Pin 19 -> A0
<nukeykt> Pin 2 and 47 affect debug mode though i don't remember how exactly, need to check die shot
_whitelogger has joined ##yamahasynths
<nukeykt> CORRECTION: A0 mapped to pin 16, NOT 19
_whitelogger has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
l_oliveira has joined ##yamahasynths
andlabs has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<Lord_Nightmare> nukeykt: thanks!
nukeykt has quit [Quit: Page closed]