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>
saa chips are like two sn76496 chips tied together (hence six squarewave channels and two noise channels) but using an ay-style address-select-write-then-data-write interface
<Lord_Nightmare>
they have a mixer matrix and master left/right volume controls on them which is very similar to the gameboy
<Lord_Nightmare>
creative labs using chips which are basically 'two of another type of chip tied together' seems to be a trend
<Lord_Nightmare>
cr1901_modern: ^
<cr1901_modern>
aren't there 2 saa chips on sound blaster?
<Lord_Nightmare>
yes
<Lord_Nightmare>
so they have 16 channels total, four of which are noise
<Lord_Nightmare>
can probably do some very sweet sounding drums with that by messing around a bit
<cr1901_modern>
hmmm
<cr1901_modern>
wonder how good they'd be at emulating VRC6 (sic)
<Lord_Nightmare>
the issue is the saw channel and pulse width
<Lord_Nightmare>
vrc6 has 8 widths
<Lord_Nightmare>
as comapred to 2a03/nes's 4
<Lord_Nightmare>
i don't know if the pulse width in the saa1099 is controllable at all
<Lord_Nightmare>
aha, you CAN do saw and tri on the saa1099, but only on two channels, and by abusing the envelope generator which is sort of similar to the ay-3-8910
<Lord_Nightmare>
the miniscribe drives in the SEs are probably dead or have the foam head thing disintegrated and siezed. I think someone on ccmp figured out how to fix that, I have two affected drives here
<Lord_Nightmare>
also test the batteries in the SEs (and dump the pram if you can?)
<Lord_Nightmare>
SEs use a varta barrel lithium battery which lasts an obscenely long time. the one in my SE was actually still good when i removed it 10 years ago
<Lord_Nightmare>
they're soldered down unlike later macs (but like the earliest mac II and earlier apple IIgs)
<Lord_Nightmare>
so you may need to find and install a socket for the battery
<Foone_>
definitely will do. I've got some similar macs so I'm hoping to combine them with these and get more working macs. these are known to be broken, so I'm hoping they're just broken in different ways
<cr1901_modern>
free macs? Anyone want to send a fat mac my way for shipping :P?
<cr1901_modern>
Actually I want one that can run NetBSD
<Foone_>
which ones are those?
<cr1901_modern>
Well a Quadra was the one I wanted
<andlabs>
oh speaking of old computers with weird disks
<andlabs>
I've got a sealed PC-88 game coming in the mail soon
<andlabs>
and I'm gonna have to figure out how to dump it
<TD-Linux>
nice
<TD-Linux>
PC-88 disks are pretty easy to dump
<TD-Linux>
should be able to use a normal IBM compatible drive to dump it
<andlabs>
assuming they don't have any weird stuff like commodore disks
<TD-Linux>
or use a pc-98
<andlabs>
or an entirely custom MFM or GRD thing
<andlabs>
the idea being it would be the first preservation-quality dump of a PC-88 game
<andlabs>
though as a rule for floppy games I would insist we dump from sealed copies
* cr1901_modern
's ears perk up
<cr1901_modern>
did... somebody say Em Eff Em?
<TD-Linux>
I have an applesauce and intend to get it working on PC-88/98/x68k but haven't yet
<TD-Linux>
but for the most part byte level copies are fine for that system
<andlabs>
also the start of a specific type of collection for me
<andlabs>
a specific company's body of work
<TD-Linux>
strip majong I assume
<andlabs>
now I will sleep
<andlabs>
lol
<andlabs>
I'm not on the PC-98 yet :V
<cr1901_modern>
You could play all the pc-98 games back to back for the rest of your life and you couldn't get through all that porn.
<andlabs>
and in fact I don't know if this company ever released anything PC-98
<andlabs>
but anyway as for fat macs
<andlabs>
good luck getting your mdoern SCSI devices working :D
<cr1901_modern>
Setting up a fat mac would be a frustrating experience for me I imagine
<andlabs>
apparently the SE does not like SCSI SD card readers
<cr1901_modern>
I mean I'd try to get spinning rust if possible
<andlabs>
if I were ever in the market for a 68k mac for any reason I would probably try to go for ... actually I'm not sure
<andlabs>
IIRC there's compatibility problems even between different 68k macs
<andlabs>
so
<andlabs>
but yes good night
<cr1901_modern>
good night
* cr1901_modern
gives andlabs a nightcap
<andlabs>
:3
<cr1901_modern>
now if only I could sleep and I wasn't running on "fuck you" hours :(
<andlabs>
I do have an iBook G4 though
<andlabs>
I plan on testing some things out on it
<andlabs>
mostly programming-related questions
<cr1901_modern>
68k before powerpc for me
* TD-Linux
uses a scsi mo drive for transferring files between pcs
<andlabs>
the fun of Cocoa
<cr1901_modern>
libui port when?
<andlabs>
not happening
<andlabs>
it requires 10.8
<cr1901_modern>
heh
<andlabs>
but I do need to find a few things that aren't well documented
<andlabs>
like how NSBitmapImageRep behaves on a big-endian system
<andlabs>
so I can fix this stupid alpha blending image bug
<andlabs>
also to see if I succeeded in writing a command-line program which as a challenge to myself I tried to write to run on as many versions of OS X as possible
<andlabs>
github.com/andlabs/macgetalbums
<andlabs>
if that succeeded then I'll probably just rewrite this for modern macs because it's mainly for my own purposes but still
<cr1901_modern>
I parsed that as "mac getal bums"
<andlabs>
sure thing sean connery
<cr1901_modern>
Bahahaha
<cr1901_modern>
HAHAHA *coughs*
<andlabs>
"getal bum covers"
<cr1901_modern>
potent potables
<andlabs>
(but yes afk for real now)
<cr1901_modern>
night!
<cr1901_modern>
For those who don't get the Sean Connery reference: https://youtu.be/PaFSkWfFhO0?t=117 (It _might've_ been a bit obscure)
<Xyz_39808>
SAA1099 is much more closer to dual AY than dual SN
<cr1901_modern>
That was my feeling from listening to a CMS demo
<Xyz_39808>
iirc, the sheet says it's got the same 32 noise freqs, and two hard env generators that are the same in function as AYs
<Xyz_39808>
btw I think the discord is Maj7 or something
<Xyz_39808>
no wait, that's the jazz one
<cr1901_modern>
How'd you find this channel out of morbid curiosity?
<cr1901_modern>
I advertise it sometimes on hellsite, but it's not like I have extensive reach
<Xyz_39808>
probably youtube
<cr1901_modern>
Oh right... there was a video doing a Snort Bopper build
<Xyz_39808>
oh wait, SAA noise freq is pretty much exactly like SN, 3 freqs, 4th is copy tone. I think the freq of the channel it's on or soething
<ValleyBell>
For each set of 3 channels, you can enable square and/or noise, similar to the AY. The noise frequency is taken from channel 0, the envelope generator is clocked by channel 1.
<ValleyBell>
something like that
<Xyz_39808>
the rules are kinda complicated and the block diagram is actually the best way to understand it. https://i.imgur.com/fAXy2jN.png
<Xyz_39808>
assuming an 8Mhz clock, the noise freqs are 31,300 Hz, 15,600 Hz, 7,600 Hz and Copy Ch0. Or copy Ch3 in the case of the 2nd noise gen
<Sarayan>
And Ch1 if mercury is in precession vs. neptune?
<ValleyBell>
It's some sort of mix between AY and SN PSG.
<Xyz_39808>
freqs in SAA are /256, /512 and /1024. In SN they're /512 /1024 and /2048
<Lord_Nightmare>
td-linux you need to talk to tony diaz on a2c.chat re: adding more features to the applesauce
<Lord_Nightmare>
iirc he's working on something relating to that
<Foone_>
is the applesauce guy open to expanding it to non-apple disks?
<Foone_>
I didn't realize that was a possibility
<TD-Linux>
I mean, I got one with the intention of doing it :)
<TD-Linux>
the A2R format should work with any disk encoding
<TD-Linux>
I also don't have a mac so I was going to write my own interface to get the A2Rs out
<Foone_>
that'd be handy
<Foone_>
I'm using os x in a vm with mine
<cr1901_modern>
So it's essential a super AY-3... so the snort blargher is a trifecta of super AY-3, FM synthesis, and PCM
<cr1901_modern>
(Well, short PCM snippets*)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
Sarayan: I can't sleep and I'm bored... is your PhD dissertation online to read anywhere in English?
<whitequark>
04:17 < cr1901_modern> I think whitequark _might_ do a set of traces
<whitequark>
yes i'll take photos of 2612
<cr1901_modern>
in this context I meant oscilloscope traces :P, which is why I included the next "cover my ass" clause that "I may be misremembering"
<ZirconiumX>
nukeykt: you should upload NukedOPL3 to GitHub too.
<cr1901_modern>
Seems to be afk, but at least they have this channel on autojoin :P
<nukeykt>
hi. I've already implemented ladder effect in my core, though my offset constant might be incorrrect
<cr1901_modern>
well I thought the CMOS core fixed ladder effect, so I was wondering if there were _other_ differences
<nukeykt>
It's fixed in YM3438. There are no any other differences besides reading from port other than 0, which is undefined behavior
<cr1901_modern>
Ahhh
<nukeykt>
I think there are some misinformation like timers or busy flag behaves differently in discrete YM3438 compared to YM2612 and asic variant
<cr1901_modern>
I'm under the impression that "nobody at present has gotten YM2612 100% right", but pretty close now
<cr1901_modern>
(feel free to correct me)
<ValleyBell>
I don't think you can get closer to an actual YM2612 than NukedOPN2.
<cr1901_modern>
At some point in the near-to-mid future, there will be some FOSS FPGA gateware that can run a YM-whatever chip in tandem w/ a software version. The idea is if there's ever a mismatch, stop the simulation and report back to the user.
<cr1901_modern>
If I ever get the damn YM2151 REing done, I'll test against that when developing my own core
<nukeykt>
Out of curiosity, are there any other die shots available besides siliconpr0n ones and 2612.
<cr1901_modern>
wq is making a set
<cr1901_modern>
Is the pipeline in ym2612 actually 12 cycles? Or is that just the maximum amount of cycles that must elapse before a write is honored?
<nukeykt>
pipeline is 24 cycles, ym2612 just has two parallel shift registers size of 12 for each operator parameter bits
<cr1901_modern>
So only one shift register is active at a time (alternating between the two every 12 cycles I guess), but since there are two of them it only takes 12 cycles maximum for any write to be honored?
<nukeykt>
yeah
<cr1901_modern>
wonder if 2151 does the same, except for 16 cycles (8 channels * 4 ops / 2 shregs)
<nukeykt>
Looks like not
<cr1901_modern>
Well, if I get off my rear end, I could figure it out soon
<cr1901_modern>
nukeykt: Do you use a bouncer out of curiosity?
<nukeykt>
what is it?
<cr1901_modern>
piece of software to stay connected to IRC when you're not at your computer
<cr1901_modern>
Asking mainly because activity in this channel happens in bursts, and the first time you logged on yesterday... there was none when you logged on :P
fseidel has quit [Ping timeout: 245 seconds]
fseidel has joined ##yamahasynths
<nukeykt>
I use webchat right now. I joined here just out of curiosity
<cr1901_modern>
ahhh okay. Main exciting thing that happened today is that we're doing a PCB run for Sound Blaster clone
<cr1901_modern>
And I should do some streaming of ym2151 vectorization if my laptop's up for it
<cr1901_modern>
whitequark: Is the OPL gateway down?
<cr1901_modern>
Now we all know Yamaha datasheets suck; the "wait 32 cycles" number they give only applies to "OPL3" mode, but the datasheet does a horrible job of explaining it
<cr1901_modern>
Experimentally, if you put the chip in OPL2 mode, you have to wait 36 cycles at 3.58MHz or 144 cycles at 14.3MHz
<cr1901_modern>
36 cycles makes sense for OPL2- 9 channels, 4 cycles per channel. Do you have any idea why the wait becomes 32 cycles in OPL3 mode
<nukeykt>
It's 32 external cycles, which equals to 4 internal cycles. Unlike earlier chips YMF262 does not use shift register
<nukeykt>
It uses RAM
<cr1901_modern>
But we experimentally verified that it requires 36 external cycles in OPL2 mode
<whitequark>
cr1901_modern: yes, it's down, i can bring it up
<cr1901_modern>
whitequark: Ahhh I was just wondering... I'm going to bed soon
<cr1901_modern>
nukeykt: >(7:05:27 AM) cr1901_modern: But we experimentally verified that it requires 36 external cycles in OPL2 mode <-- Ignore this message, I messed up
<nukeykt>
It also does not depend on OPL3 mode bit
<whitequark>
nukeykt: it does.
<cr1901_modern>
nukeykt: When the chip is in OPL2 mode, whitequark had to wait 144 cycles (36*4) between writes for music to play properly.
<whitequark>
nukeykt: if NEW=0, unless I wait exactly 144 cycles after address AND data, the chip ignores at least some writes.
<whitequark>
waiting 128 cycles after address and data is not enough. waiting 128 cycles after address and 144 cycles after data is not enough. waiting 136 cycles is not enough.
<whitequark>
I am completely confident in this findings as I've spent many hours figuring out what exact condition is required for correct OPL2 playback.
<nukeykt>
really? I dunno how it's possible given OPL3 uses RAM unlike OPL2
cr1901_modern1 has joined ##yamahasynths
<whitequark>
well check it yourself if you don't believe me
<cr1901_modern1>
Of course I would time out
<whitequark>
I use the exact same code for driving it in OPL2 mode and OPL3 mode
<whitequark>
in OPL3 mode, 32 cycles appears always enough
<whitequark>
32/32 for address/data
<whitequark>
in OPL2, that is definitely not the case.
<cr1901_modern1>
incidentally, 144 cycles at 14.3MHz is still less time than an actual OPL2 chip has to wait (84 cycles @ 3.58 MHz)
cr1901_modern has quit [Ping timeout: 252 seconds]
<cr1901_modern1>
Possible that the OPL2 portion checks the RAM less frequently?
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##yamahasynths
<cr1901_modern>
nukeykt: Was the opl3 code you linked also based on REing die images?
<cr1901_modern>
(It's gonna be a... huge mess if your opl3 takes 32 cycles regardless of mode while wq's opl3 takes 32/144 cycles)
<nukeykt>
v1.8 is partially based on die shor RE
<nukeykt>
EG and rhythm mode for example
<cr1901_modern>
I see... Is there any possibility you could test your own OPL3 in OPL2 mode for cycle counts? I'd like a point of comparison. >>
<cr1901_modern>
(And by that I mean "I pray to God they match")
<nukeykt>
Not soon. Last time i did Yamha FM RE work was about one year ago
<cr1901_modern>
I didn't mean die image RE :). I meant hooking it up your OPL3 to a microcontroller or FPGA and deliberately writing to it faster than 144 cycles and seeing what happens
<cr1901_modern>
(the rabbit hole never ends)
<nukeykt>
BTW last year i was REing vrc7 and found some interesting things about it
<nukeykt>
I recall if you connect pin 15 to ground VRC7 will enter to debug mode. In this mode VRC7 will have 9 voices and it's possible to dump internal ROM.
<cr1901_modern>
whitequark: thanks
<nukeykt>
in default mode vrc7 is hardlocked to rhythm mode and thus it's 6 channel only
<cr1901_modern>
nukeykt: We were going to do a ROM stain and/or delayer to get to the VRC instruments
<cr1901_modern>
if there's no need to do that, that's great
<l_oliveira>
I remember hacking some VRC2-4 games to MMC3 a couple years ago
<l_oliveira>
I had to "grow" the chr rom because the MMC3 bank granularity was worse (2KB) than the VRC mappers (1KB)
<l_oliveira>
had to repeat some banks D:
nukeykt has quit [Quit: Page closed]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 246 seconds]
<l_oliveira>
out of curiosity, a lot of the instruments on the VRC7 are identical to the OPLL, no? About half of them?
<ValleyBell>
whitequark: I agree with nukeykt that major differences between OPL3 NEW=0 and NEW=1 and very doubtful.
<ValleyBell>
Especially because it always renders all 18 FM channels.
<whitequark>
ValleyBell: then drive it yourself and see
<whitequark>
mine is datecode 9528 EAMC and i've personally desoldered it from a historical Aztech card
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 252 seconds]
<ValleyBell>
I'll try to do some checks with my SB16 when I have access to my old computer the next time.
<ValleyBell>
My main point against "the NEW bit modifies timing" is, that there is no reason to implement this additional "feature". From what we know about OPL and OPN chips, the compatibility flags are usually just simple address/data masks.
<cr1901_modern>
How do you know the OPL3 always processes all 18 channels if the upper channels are masked off?
<l_oliveira>
likely because it behaves like two OPL2 in that mode?
<l_oliveira>
someone mentioned it is not two physical OPL2s on the die, which makes sense. There's no point have two OPL2s in the die, one operator logic block can do all 18 channels in sequence
<l_oliveira>
so it just need to do 18 channels instead of nine (run twice the speed of the one on the original chip?)
<cr1901_modern>
Wohali: How long do you think we should accept new submissions on the form? Certainly we have more than enough... another 24 hrs maybe?
SceneCAT has quit [Quit: *Mreow*]
ej5 has joined ##yamahasynths
andlabs has joined ##yamahasynths
<cr1901_modern>
ej5: How much is a bracket hole punch again (No need for a db15 version)?
<cr1901_modern>
Aaaaanyways, personally GHIDRA being written in Java is not a dealbreaker for me
<Lord_Nightmare>
sarayan: the 2413 does have a test mode of sorts i've been told, but its less than useful for dumping the ROM
<cr1901_modern>
I've dealt w/ a few decent Java programs- Areca, jEdit
<cr1901_modern>
Better Java than being written in Electron >>
<cr1901_modern>
/me grumbles as Atom takes 20 minutes to update 4 packages
<TD-Linux>
cr1901_modern, I think it being in Java is a positive
<TD-Linux>
less likely to get pwned via your own debug tool :)
<cr1901_modern>
heh
<TD-Linux>
also it can be upgraded to scala later :^^)
<cr1901_modern>
scala insisted on including not only batteries, but also the kitchen sink, and the deed to that mansion that's been unused for 30 years
<TD-Linux>
that's kinda the point
<Lord_Nightmare>
ej5: if you install ghidra remember to disable the java debug thing they accidentally left enabled
<Lord_Nightmare>
ask balrog how to do it, they accidentally put a * in a file which should have had 'localhost' instead
<Lord_Nightmare>
so any computer on the local lan can connect as a java debugger to ghidra
<cr1901_modern>
Oh, balrog's used ghidra?
<balrog>
I’ve poked at it
<balrog>
No time to use it
<Lord_Nightmare>
once the full ghidra source gets posted, i wonder if we'll start seeing dev forks and stuff
<Lord_Nightmare>
adding more cpus to it would be extremely useful
<Lord_Nightmare>
it also has some bugs with a few cpus
<cr1901_modern>
I hope 68k isn't one of them
<cr1901_modern>
(it probably is one of them)
<Lord_Nightmare>
yes, it is. theres one bug in 68k which someone posted an issue about
<cr1901_modern>
since the encoding is utterly horrifying in exchange for everything else being great
<cr1901_modern>
Guess there had to be a tradeoff somewhere...
<Lord_Nightmare>
I think the 68k bug report even has a patch in it
<TD-Linux>
Lord_Nightmare, the java debug thing is off by default
<TD-Linux>
and you can't even enable it without fixing typos in the shell script :)
<cr1901_modern>
the best 68k disassembler I've ever used was posted in Dr. Dobb's in like 1994
<cr1901_modern>
written in C and is smart enough to detect basic blocks
<cr1901_modern>
I've done a bit of sleuthing to try and contact/thank the author, but he disappeared by 2002
<TD-Linux>
Lord_Nightmare, hopefully they will maintain upstream well enough that we can just send prs
<TD-Linux>
if they don't, another upstream will emerge