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>
does anyone know off-hand whether the YM2608's drum cahnnels have linear or logarithmic volume levels
<whitequark>
i feel like half of the altera primitives are fake
<whitequark>
ALTCLKCTRL is just some fabric junk
<whitequark>
what
<cr1901_modern>
whitequark: tyvm
_whitelogger_ has joined ##yamahasynths
emily_ has quit [Client Quit]
andlabs has quit [*.net *.split]
mz` has quit [*.net *.split]
Foone has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
ej5 has quit [*.net *.split]
mofh has quit [*.net *.split]
epsdelphi has quit [*.net *.split]
_whitelogger has joined ##yamahasynths
<andlabs>
MUCOM 88 is a Music Macro Language (MML) compiler and music creation tool for the NEC PC-8801 platform developed by Yuzo Koshiro in 1987. In addition to a compiler, MUCOM 88 provides an FM synthesis driver written in z80 machine code that understands the MML compiler output, giving an environment for playback and feedback for the composer.
<andlabs>
oh neat
<andlabs>
why did he need to write an FM emulator?
<cr1901_modern>
because openmucom88 is emulating the z80 driver in real time
<cr1901_modern>
on Windows/*nix machines
<andlabs>
oh
<andlabs>
this makes it sound like yuzo koshiro wrote a YM2203 emulator for the PC-88 =P
<cr1901_modern>
I mean, someone wrote an IBM PC emulator for IBM PC
<cr1901_modern>
it takes like an hour to get to a DOS prompt, but I am highly amused all the same
<andlabs>
D K0 t197C96l16o4 L q2[@3v13 M16,1,30,4,15<g4b-32&>c32de-fe-8dc8g8.f4.e-fd-96&c8.&c24&c96c8g8 >c4.de-d4<b-4 g1
<cr1901_modern>
yup, that is MML
<andlabs>
I did not know koshiro had 900 IQ
<cr1901_modern>
isn't it so readable :D?
<cr1901_modern>
err, it's quick to let me prototype crap, but yes the syntax bites
<andlabs>
either way, this is too specific to the PC-88 for me to consider using for my pieces of music hardware, but I'll keep the syntax in mind
<cr1901_modern>
tinymml is an alternative
<cr1901_modern>
but I don't like how it punts on chords
<cr1901_modern>
in that, it doesn't support them unless you do crappy tricks listed in the FAQ
Xyz_39808 has quit [Ping timeout: 276 seconds]
<Lord_Nightmare>
andlabs: the sanyo chip works basically the same way the tms5220 does
<Lord_Nightmare>
except with extra features
<Lord_Nightmare>
it directly accesses a hunk of its own ROM out a dedicated set of ports
<Lord_Nightmare>
but you can also slowly read ROM through it iirc by sending it specific commands
<Lord_Nightmare>
vlm5030 was used in nintendo's punch out and super punch out arcade machines, and arm wrestling, and was used in a bunch of konami things (mostly bubble system hardware and derivatives, but also double dribble hardware)
<Lord_Nightmare>
konami also used it in one, possibly two prototype/never released MSX cartridges; one of the two is dumped (keyboard master), the other one (magical tree) is not
<Lord_Nightmare>
its unclear if magical tree used it or not, but given that it was a game with letters hanging on a tree about presumably spelling, i'm assuming it did
<Lord_Nightmare>
only one or two screenshots of that game survive
<Lord_Nightmare>
and its ID number in the sequence of konami msx games is known
<Lord_Nightmare>
but that's about it
<cr1901_modern>
oh right, the bubble system. You had to wait a minute for the game to warm up
<cr1901_modern>
Gradius would play some music from the 1700s
<cr1901_modern>
while you wait
<andlabs>
we don't know who wrote the music, but it was likely Gradius's composer
<andlabs>
we do know it has a name (Morning Music)
<cr1901_modern>
oh it's not classical music?
<andlabs>
btw Gradius VGM pack when
<Lord_Nightmare>
the bubble system is really kinda neat, but the design was stupidly flawed
<Lord_Nightmare>
the system starts up with the 68k held with /BR and /RESET asserted by the bubble mcu, and the sound z80 getting vblank fed to its int pin; during this time the bubble mcu is waiting for some sort of 'ready' signal from the bubble memory module itself. during this time the sound z80 is playing a little countdown loop "getting ready... fifty... getting ready... forty nine..." etc
<Lord_Nightmare>
then once the bubble memory is warmed up/ready, the bubble mcu starts getting data shoved into it by the bubble memory and echoing/writing it back to the bubble memory. I believe each data word is stored twice, adjacently, so if one gets erased by a poorly timed power down, it won't render the cart unusable
<Lord_Nightmare>
then the bubble mcu writes a short bootloader to a 0x400 or 0x800-long chunk of shared ram with the 68k, and releases the /RESET and /BR lines
<Lord_Nightmare>
the 68k executes that bootloader, which tells it how to talk to the bubble mcu, and the bubble mcu starts copying packets to the latter half of the 0x800 long area
<Lord_Nightmare>
the 68k then stuffs them into SRAM or DRAM depending on whether that data is code or gfx data
<Lord_Nightmare>
and that's when the morning music plays and the countdown happens
<Lord_Nightmare>
during the copying of the data
<Lord_Nightmare>
apparently the data is copied in a weird striped format, so each byte is encoded by 4 bytes(?) on the bubble memory
<Lord_Nightmare>
one byte repeated twice and another byte repeated twice, but halfway around the 'loop'
<Lord_Nightmare>
and the two are combined somehow
<Lord_Nightmare>
you can see it if you watch the memory being filled
<Lord_Nightmare>
in a debugger in MAME
<cr1901_modern>
This seems beautifully fucked up :'D
<Lord_Nightmare>
oh its extremely fucked up
<Lord_Nightmare>
if the bubble mcu craps out and stops writing data back, the bubble memory will literally ERASE ITSELF as it plays itself back to nowhere
<Lord_Nightmare>
the whole design was a giant WTF
<Lord_Nightmare>
why was the bubble mcu on the mainboard rather than inside each cartridge?
<Lord_Nightmare>
that was the main flaw of the whole system afaict
<cr1901_modern>
cost?
<Lord_Nightmare>
maybe
<Lord_Nightmare>
also why does the bubble memory control chip on the bubble memory cart itself not handle rewrite/refresh?
<Lord_Nightmare>
i mean, i suspect it DOES do it, but the mcu STOPS it from doing so after warm-up and takes over?
<Lord_Nightmare>
why?
<cr1901_modern>
Maybe you can ask one of the retired ppl from Konami one day
<Lord_Nightmare>
the only thing i can think of is maybe there's some sort of ECC crap going on
<cr1901_modern>
What mcu was the bubble mcu?
<Lord_Nightmare>
where the bubble mcu reads two words, checks the ECC on both and only after fixing the ECC writes BOTH back
<Lord_Nightmare>
so if there was a corrupt word it will fix it
<Lord_Nightmare>
that actually makes some sense
<Lord_Nightmare>
we don't actually know
<Lord_Nightmare>
its an sdip64 chip
<Lord_Nightmare>
and may be completely custom
<Lord_Nightmare>
but its definitely an mcu inside
<Lord_Nightmare>
custom pinout?
<cr1901_modern>
Not decapped yet?
<Lord_Nightmare>
nope
<cr1901_modern>
Hrm
<Lord_Nightmare>
it could be a upd7800 series
<Lord_Nightmare>
i was also wondering whether that 0x400 bootloader actually exists on the bubble memory somewhere and the bubble mcu has to wait for it to loop around and find it first, then upload it
<Lord_Nightmare>
but i don't think that's the case
<Lord_Nightmare>
if konami had put the bubble mcu on the cart itself *OR* had the bubble mcu firmware or 68k firmware loaded directly from the bubble cart, that would have made replacing the unreliable bubble carts with ROM boards a lot easier
<Lord_Nightmare>
instead konami respun the whole gx400 pcb
<Lord_Nightmare>
so i assume they could not make an easy way to retrofit the bubble pcb without possibly replacing the bubble mcu itself too
<Lord_Nightmare>
another possibility would be to put a secondary bubble mcu inside the bubble cart which pretends its the 'dumb' bubble controller in there
<Lord_Nightmare>
but actually handles ecc/everything itself
<Lord_Nightmare>
again, more cost
<Lord_Nightmare>
there is a japan-made device to replace the bubble carts which uses an arm microcontroller and maybe an fpga
<TD-Linux>
bubbless
<Lord_Nightmare>
it requires you to 'dump your own carts' tho, and nobody is sharing dumps
<TD-Linux>
it's $$$$$
<Lord_Nightmare>
in fact the device may be designed to make it extremely hard to extract dumps from it, possibly encrypting them in flash
<Lord_Nightmare>
because japan
<cr1901_modern>
'dump your own carts'?
<cr1901_modern>
aren't there sets for Gradius?
<cr1901_modern>
so what's the problem?
<Lord_Nightmare>
arcadehacker and others managed to extract the bubble memory contents from gradius using a logic analyzer on the bubble mcu
<Lord_Nightmare>
but that's one of ?five? games
<Lord_Nightmare>
gradius, twinbee, rf, ... whats the other
<cr1901_modern>
is gradius the only bubble game with a MAME set?
<Lord_Nightmare>
ues
<Lord_Nightmare>
yes
<cr1901_modern>
ahhh
<Lord_Nightmare>
gradius, twinbee, galactic warriors, konami gt, and rf2
<Lord_Nightmare>
i think those were the 5 games on the bubble system
<cr1901_modern>
Welp, I guess they will be lost to time then :(
<cr1901_modern>
I wou;d've figured twinbee would be dumped
<Lord_Nightmare>
gradius won't, and twinbee probably won't
<Lord_Nightmare>
we know someone with a twinbee cart, but it may already be bad
<Lord_Nightmare>
however its only partly bad
<Lord_Nightmare>
fails checksum but loads
<Lord_Nightmare>
so that may be fixable using the rom-twinbee contents
<Lord_Nightmare>
assuming the bad page is something common