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
<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
<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…]