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
<cr1901_modern>
fseidel brought that up. I think it would be a coincidence unless Umemoto saw the Second Reality demo
<cr1901_modern>
or Takami
<Xyz39808>
who didn't see second reality?
<cr1901_modern>
me
<Xyz39808>
pffffft
<cr1901_modern>
if I'm perfectly honest
<TD-Linux>
what would be an easy way to play a raw yamaha adpcm file
<Xyz39808>
audacity?
<andlabs>
superctr: what are you pointing out
<andlabs>
oh
<andlabs>
that was literally the question that fseidel was asking that started this conversation
<andlabs>
so.
<andlabs>
anyway yes it's a coincidence these are two different songs
<andlabs>
that four note stinger is literally the only thing that are the same
<andlabs>
and you probably can't claim theft on that
<andlabs>
anyway someone once linked me the video of the game's opening and that was an absolutely magical moment in my development of FM snobbery so
<cr1901_modern>
Everyone knows ZrX noms, but has anyone figured out what ZrX is nomming _on_?
ZrX-NoMs has joined ##yamahasynths
<cr1901_modern>
cc: Foone
<Lord_Nightmare>
I think it was originally ZrX-oMs and then one day ZrX decided to get something to eat and changed it to ZrX-NoMs and then never changed it back
<Lord_Nightmare>
like 6 or 7 years ago
<Lord_Nightmare>
i assume oMs stands for 'original media supplier' in a cracking group sense
<TD-Linux>
Lord_Nightmare, if I'm going to do that I'm just going to rip the adpcm decoder out of some vgm player
<Foone>
Lord_Nightmare: I talked with Brandon about their ActionReplay PC, and gave them an update on why we're stalled right now. Any chance that I might be able to get yours sometime relatively soon, now that it's looking like this virus mess is a long haul sort of thing?
<ZrX-NoMs>
Just some splits causing a nick collision...
ZrX-NoMs is now known as ZrX-oMs
<cr1901_modern>
So now you hibernate for another 6 or 7 years before getting something to eat?
<Lord_Nightmare>
TD-Linux: I could probably throw together a decoder, but which decoder variant should it be based on?
<Lord_Nightmare>
the windows acm codec uses... let me check again...
<cr1901_modern>
ZrX-oMs: Anyways, someone was discussing Kyroflux and apparently you worked on some visualization tool for it?
<TD-Linux>
2608 adpcm
<TD-Linux>
it's not super critical, I'm mostly just curious if I'm extracting this game's voices correctly. it has .SPX files and I can't imagine it being anything but 2608 adpcm
<Lord_Nightmare>
the coefficients for 0.9 0.9 0.9 0.9 1.2 1.6 2.0 2.4 are represented in fixed point with different notation in different decoders
<ZrX-oMs>
Yes the code still lives.
<Lord_Nightmare>
ZrX-oMs: mooglyguy/themogminer was also looking for you, I assume he got in contact with you
<cr1901_modern>
Foone: Do you still need that code? Idk the context of what you were trying to do
<ZrX-oMs>
Lord_Nightmare: Yes he did
<Lord_Nightmare>
awesome!
<andlabs>
moogle was here?
<andlabs>
since when
<cr1901_modern>
If he's on IRC, Idk his nick
<cr1901_modern>
he's never been here
<andlabs>
ok
<andlabs>
thought so =P
<Lord_Nightmare>
no, moogly was asking about 'zrx from old posts on the kryoflux forums' on the MAME discord
<Lord_Nightmare>
and i immediately said 'that's probably ZrX-oMs' and indeed it was
<Foone>
cr1901_modern: not particularly at the moment, no
<cr1901_modern>
Foone: Ahhh, well nevermind. I managed to get ZrX-oMs in here if you need to chat w/ them tho
<andlabs>
well cool that worked out
<cr1901_modern>
(w/ LN's help)
<Foone>
right now I'm trying to port Doom to a remote, because why not
<Lord_Nightmare>
zrx did a lot of stuff with die tracing of the commodore SID and other chips
<Foone>
ahh, cool!
<andlabs>
as for kryoflux I'm going all in on the flux engine
<andlabs>
still waiting for the drives to come in the mail >:|
<andlabs>
also yes good
<andlabs>
we need more die tracing
<cr1901_modern>
I'd personally like to see discferret revived
<cr1901_modern>
And SID is certainly close enough to on-topic
<Foone>
working on it
<Lord_Nightmare>
discferret needs WORK.
<andlabs>
I mostly just wanted to complain about the mail just now =P
<andlabs>
[01:45:35] <cr1901_modern>And SID is certainly close enough to on-topic
<andlabs>
sfx sound expander though
<andlabs>
or I guess mixing an SSI 2001 and an AdLib counts too
<Lord_Nightmare>
imho the pcb for the discferret needs a respin; the FPGA is EOL, it doesn't have enough RAM, and the interface MCU needs to be replaced with something which does usb 2.0 HS, or better yet usb 3.0 at this point
<cr1901_modern>
Well yes, that's definitely OT, but I think the two you own are the only two I've ever seen physically exist :P
<andlabs>
can someone make an SSI daughterboard for the SB?
<Foone>
ahh, neat!
<andlabs>
was the original Sound Blaster the one that supported daughterboards? or swas that only the 16?
<Lord_Nightmare>
uh... i don't see why not? it would need an MCU which converts midi to SID writes though
<andlabs>
then how was gameblaster compatibility done?
<andlabs>
not using a daughterboard?
<cr1901_modern>
Philips SAA chips
<andlabs>
oh, chips directly
<andlabs>
heh
<Lord_Nightmare>
i think the sb16 waveblaster daughterboard is pretty much just an mpu401 serial midi interface and two audio input pins back to the sound card
<andlabs>
oh yeah
<andlabs>
one of these days I need to look up what the waveblaster and videoblaster were
<Lord_Nightmare>
from the card perspective its just midi out audio back in
<andlabs>
but not right now
* cr1901_modern
reads RT
<cr1901_modern>
Okay Foone WTAF did you get yourself into ._.?
<cr1901_modern>
discferret is getting a new run. wq has a reader on her glasgow applet. There's that Cypress-based one
<cr1901_modern>
I can't remember the name
<Lord_Nightmare>
theres supercardpro and hxc(and its gotek clone)
<Foone>
flux engine
<andlabs>
flux engine
<cr1901_modern>
yes, thanks
<ZrX-oMs>
Also made my own disk reader recently out of STM32 with the purpose of reading user data to a disk image as fast as possible with several means of error recovery.
<andlabs>
which is the one I'm trying to build
<andlabs>
also I have a zoomfloppy and 1571
<andlabs>
so I'll be dumping C64 disks with both
<andlabs>
it'd be really really cool if I could use the 1571's MFM support to dump 5.25" PC disks
<andlabs>
but I don't think nibtools supports that
<cr1901_modern>
I have a stalled project to do my own. No particular impetus to finish it right now, but I do want to
<cr1901_modern>
just so I can say I finished it
<andlabs>
heh
<andlabs>
I do have impetus, alas
<andlabs>
I went on a collection spree :x
<Lord_Nightmare>
ZrX-oMs: interesting, that's a similar approach to applesauce, which is teensy 3.6 based
<andlabs>
also I need to write an Amiga disk so I can actually use my 1000
<andlabs>
because the seller's workbench disk was dying :(
<ZrX-oMs>
Applesauce does processing on the computer side. I do it on the MCU so it's running completely standalone.
<andlabs>
but I do want to start going into CD dumping next
<Lord_Nightmare>
applesauce i think does some and some, though the processing on the mcu is not complex
<andlabs>
and I am eyeing possibly using the Sega CD
<Lord_Nightmare>
maybe just RLE, i'm not sure
<ZrX-oMs>
Insert disk > hit a button > fast read, then retry for bad spots > asks if more retries is wanted.
<andlabs>
if we can avoid using the BIOS and controlling the disk controller directly
<cr1901_modern>
andlabs: If you can get me a dead Sega CD, let me know
<andlabs>
can we do the equivalent of fluxengine/nib flux dumps?
<cr1901_modern>
I want to extract the PCM chip
<andlabs>
the PCM chip was commercially available
<Lord_Nightmare>
i thought sega cd and the pc engine (and maybe the neogeo cd?) used a weird common cd controller chip?
<cr1901_modern>
sure, but I can't _find_ it on Ebay
<cr1901_modern>
otherwise I would buy it directly
<Lord_Nightmare>
TD-Linux: sorry for being sidetracked
<andlabs>
but yeah
<cr1901_modern>
Lord_Nightmare: That's a loliviera question
<andlabs>
can we do raw dumps of the binary data on CD or not
<andlabs>
including the raw TOC and raw subcarriers and what not
<Lord_Nightmare>
claunia and the domesday duplicator guys i think were discussing it
<andlabs>
the CD analogue of a flux dump of a floppy
<ZrX-oMs>
andlabs: Someone did experiment with raw CD bitstream dumping.
<Lord_Nightmare>
i expect it to happen within 2 years
<cr1901_modern>
Lord_Nightmare: simon already dumped a CD
<ZrX-oMs>
Was on hackaday maybe a year ago.
<andlabs>
yes I know wobble and PS1/Saturn copy protection will put a wrench in that
<TD-Linux>
btw segment registers are the spawn of satan
<Lord_Nightmare>
already a modded RF-port laserdisc player can dump a CD raw
<cr1901_modern>
just there's not much interest in following up on that
<Lord_Nightmare>
using a domesday duplicator
<andlabs>
ASSUME CS:Nothing, DS:TD-Linux
<Lord_Nightmare>
but i don't know if it reads it as a giant linear block or not
<andlabs>
I'm not sure if it even *can*
<andlabs>
is it a linear block of data?
<andlabs>
or multiple?
<andlabs>
I legit do not know
<andlabs>
cr1901_modern: which chips did you look for
<cr1901_modern>
RF5C68 and one of its siblings (don't remember the name)
<andlabs>
actually never mind both part numbers are currently unavialable
<andlabs>
RF5C164
<cr1901_modern>
I recall getting a hit for 164 but it was like a package of 100
<andlabs>
anyway there's a broken sega CD 1 going right now for under $40 as of writing
<andlabs>
but yes it's an auction
<andlabs>
power supply-related falure (worked once, then not again)
<cr1901_modern>
which is nice, but: 1. where do I store those?, 2. whose paying for the other 95?
<cr1901_modern>
b/c I'm not :)
_whitelogger has joined ##yamahasynths
<cr1901_modern>
I thought SimonInns was the domesday lead
<Lord_Nightmare>
claunia is from the AARU project, formerly DiskImageChef
<Lord_Nightmare>
she changed the name because someone complained about the "DIC" acronym
<Lord_Nightmare>
claunia has been working on raw CD imaging from the 'plextor drive debug mode' end
Ultrasauce has quit [*.net *.split]
<cr1901_modern>
Are they on IRC?
<Lord_Nightmare>
but since those drives are horrendously rare, i believe a better solution is being sought out
<Lord_Nightmare>
see #aaru
<Lord_Nightmare>
yes
<Lord_Nightmare>
though most stuff is on discord, there's a discord<->irc gateway bot
Ultrasauce has joined ##yamahasynths
<ZrX-oMs>
Just waiting for the times when raw harddrive dumping is a thing.
<cr1901_modern>
I'll eat my mattress if that happens for anything beyond MFM/RLL drives
<Foone>
Lord_Nightmare: does that old source you have include the advanced graphics TDK?
<Lord_Nightmare>
i don't know! doing too much at once
<Foone>
take your time! my shit is not remotely rushed
<cr1901_modern>
Foone: So what's wrong w/ the action replay project?
<cr1901_modern>
("wrong"*)
<Foone>
basically halted because I did 75% of the PCB reversing, then lost the rest because of a crash. with the potential for future use of a PAL decoder + just scanning the PCB directly, I don't have a lot of motivation to do the slow and tricky work on the one I can't disassemble
<ZrX-oMs>
Action Replay?
<Foone>
the cheat device: there's one for the IBM PC, and I'm working on reverse engineering it
<ZrX-oMs>
Ah
<Foone>
it's an ISA card that does memory manipulation
<cr1901_modern>
ISA cards are objectively good things.
<ZrX-oMs>
No idea if that's more or less complex than the Amiga variant.
<Foone>
it looks to be pretty similar.
<cr1901_modern>
68k bus doesn't strike me as much more complex than an 8088/386 bus. In fact, IIRC you only need one TTL chip to implement 8 interrupts on 68k (priority encoder).
<ZrX-oMs>
I have absolutely no clue about how much needs to be monitored on a PC to make that work. On the Amiga it keeps track atleast of all the custom chip and IO registers.
<Lord_Nightmare>
TD-Linux: do you want me to try to hack together a decoder quickly? I can't promise how accurate it will be though
<Lord_Nightmare>
ValleyBell: ooh, i should add one more to that decoder, IMA ADPCM, which is like a slightly fancier version of oki/vox
<Lord_Nightmare>
DVI adpcm (from the bluetooth spec) IIRC is basically IMA ADPCM but with the accumulator and step size index stored in the first 3 bytes (with the 4th byte always blank)
<Lord_Nightmare>
... i think ima adpcm might be the same in that regard to be honest
<Lord_Nightmare>
there's some really minor technical difference between DVI ADPCM vs IMA ADPCM
<Lord_Nightmare>
the actual algorithm is the same, but something with block sizes and whether the predictor/accumulator+step size is part of the block size or is outside it, and whether the total data size is an exact power of 2 long and has an even vs odd number of samples
<Lord_Nightmare>
is different
<Lord_Nightmare>
it might be that one of them has the accumulator/step size index stored as part of the .wav header or extended header structure and not inside the data block itself (meaning a data block of 64 bytes has 128 4-bit compressed samples) and the other stores the data as the first 3 or 4 bytes of the data block, so a data block of 64 bytes has 120 or 122 4-bit samples
<ZrX-oMs>
Kawai was something different I think... http://oms.wmhost.com/Kawai.txt - Can't remember where I found that formula when I decoded samples from R-50E and R-100 ROMs.
<Lord_Nightmare>
i know classic XBOX ADPCM works the latter way (not to be confused with the MSADPCM codec used on the XB360 and XNA, which is completely different)
<Lord_Nightmare>
i need to find a formal description of the DVI codec from bluetooth...
<Lord_Nightmare>
ZrX-oMs: if you (or anyone else) wants to join the MAME discord, there's some floppy related discussion in there in #development-help, the invite link is https://discord.gg/NN28xZU
<ZrX-oMs>
No discord here.
<Lord_Nightmare>
hmm. well, the MAME irc channel is on freenode in #mame-dev as well
<superctr>
Lord_Nightmare, feel free to send a pull request then
<Lord_Nightmare>
superctr: i will probably do that
<superctr>
i haven't added IMA myself because i haven't worked much with that personally and codecs for it are easily available, so i didn't feel a need
<Lord_Nightmare>
its just 'fancier oki' more or less.
<Lord_Nightmare>
some variants of it do not include an initial predictor(accumulator) and step size index
<Lord_Nightmare>
i wish there was a way to optionally state whether the first 3 or 4 bytes are the initial predictor and step size index (oki/ima)/initial predictor and step size (yamaha) on the decoder, or if it starts as data
<Lord_Nightmare>
for the yamaha chips i assume it always thinks the data starts with predictor at 0 and step size at... I think 1 or 4 or something? i forget
<Lord_Nightmare>
maybe 8
<Lord_Nightmare>
or maybe 14
<superctr>
well, if you use the code as a "library" you can do anything
<superctr>
it would be possible to add a C++ style default argument to set the initial parameters for example
<Lord_Nightmare>
i also don't know what precision the step size is kept at for yamaha adpcm inside the ym2608, ym2610, and AICA chips
<Lord_Nightmare>
and the YM-deltaT chip, whose number i forget, ymfsomething
<Lord_Nightmare>
and y8950
<Lord_Nightmare>
the accumulator i assume is 16 bits
<superctr>
read the datasheets?
<Lord_Nightmare>
doesn't say, i don't think. I'll have to check y8950 and ym2608J again, as those are the only two which actually do any sort of explanation of the algorithm
<Lord_Nightmare>
the ACM codec uses (starting at 0x474) the 16bit (stored LE) constants 0x00e6 0x00e6 0x00e6 0x00e6 0x0133 0x0199 0x0200 0x0266, which if divided by 256 (so they're stored in 8.8 fixed point notation), form 0.8984375, 0.8984375, 0.8984375, 0.8984375, 1.19921875, 1.59765625, 2.0000000, 2.3984375
<Lord_Nightmare>
which are i think the closest you can round to without exceeding the original jayant paper values of 0.9 0.9 0.9 0.9 1.2 1.6 2.0 2.4
<Lord_Nightmare>
superctr: that implies that inside the ym2608 at least, the notation is 10.6 fixed point
<Lord_Nightmare>
so a bit less accurate than the acm codec is
<superctr>
the AICA datasheet gives the same floating point values as you said
<Lord_Nightmare>
maybe the ACM codec matches the AICA
<Lord_Nightmare>
i'm assuming the y8950, the ym2608, ym2610 use the 10.6 (really 3.6) encoded version internally, and MAYBE the PCMD8 chip ymz280b (and the MMA ymz263B chip)
<superctr>
YMZ280B and AICA uses the same algorithm
<superctr>
only difference is that nibbles are swapped
<superctr>
YMZ263B should be same as YMZ280B
<Lord_Nightmare>
and the AICA and ACM codec and the SMAF chips MA-2, 3, 5 and 7 use the 8.8 (really 3.8) encoded version, which also supposedly has a different clamping logic for the accumulator
<Lord_Nightmare>
i remember discussing this before, that the sounds in shenmue on dreamcast will sound very wrong if decoded with the ym2608 style clamping
<superctr>
perhaps the other chips use similar clamping, but i haven't been able to test or verify that
<superctr>
yeah, i know about that
<Lord_Nightmare>
we need to make a test suite which will test the edge cases of clamping
<Lord_Nightmare>
literally force it to clamp by 1 over and over and over, and see when it finally overflows audibly
<Lord_Nightmare>
if it doesn't clamp immediatly it will start overflowing at a different point
<superctr>
the clamping is done after the input sample is multiplied with the step size, before it is accumulated to the sample output
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Lord_Nightmare>
ok Foone i'm caught up again. i hope.
<Lord_Nightmare>
i'm checking what qnx stuff i have