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
nukeykt has joined ##yamahasynths
<cr1901_modern>
Lord_Nightmare: It's not just discord... I just have a really bad time multiplexing a bunch of different chat protocols and communities, so I choose hellsite and IRC
ej5 has quit [Read error: Connection reset by peer]
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
nukeykt has quit [Remote host closed the connection]
<Lord_Nightmare>
cr1901_modern: is it ok if grauw came in here?
<Lord_Nightmare>
is it ok with everyone else?
<Lord_Nightmare>
they're in #openmsx
<KitsuWhooa>
I don't see why not :p
<cr1901_modern>
KitsuWhooa: There are a few ppl who are into Yamaha chips that I don't want in here.
<cr1901_modern>
Lord_Nightmare: I can't say I know them, so... seems fine to me?
<KitsuWhooa>
cr1901_modern: I mean, wouldn't it be fair to have them and if they start causing a mess, then ban them?
<KitsuWhooa>
They also (used to?) hang out in vgmrips, so I have talked to them before
<cr1901_modern>
Oh awesome. I do remember them and I use their website for datasheets. Yes, please invite them.
<Lord_Nightmare>
and msx is yamaha relevant because of SFG-01/05, MSX-MUSIC (ym2413) and MSX-AUDIO Y8950
<Lord_Nightmare>
ok, i pm'ed them
grauw has joined ##yamahasynths
<Lord_Nightmare>
hi grauw
<grauw>
hi
<KitsuWhooa>
'lo
<cr1901_modern>
KitsuWhooa: Re: your "wouldn't it be fair..." q... if they found this room, that is what I would do.
<cr1901_modern>
except in the case of stalkers
<grauw>
short introductions: I made VGMPlay MSX, maintain the MSX Assembly Page, and since last week I play samples on the YM2413
<cr1901_modern>
I use your website for YM2151 datasheets :P
<grauw>
:)
<KitsuWhooa>
cr1901_modern: I guess
<Lord_Nightmare>
I'm still trying to track down a paper copy of the YM2151 application manual
<superctr>
and scan it?
<grauw>
the ones out there now look a bit dodgy eh
<superctr>
:)
<Lord_Nightmare>
the scan that ilparatz0/neill corlett made back in 1999 is... really bad. and i emailed him and he no longer has the copy he scanned
<superctr>
even if it was in japanese, i wouldn't mind
<Lord_Nightmare>
its also missing the titlepage
<KitsuWhooa>
Yeah, that one is really bad
<KitsuWhooa>
but I guess better than nothing?
<Lord_Nightmare>
though i have a reproduction i made using the font from the ym2203 and ym2413 application manuals which is probably pretty close to what it would have looked like
<Lord_Nightmare>
is that the guy who blew up the vrc7 by poking it with a meter while it was on, on a video?
<cr1901_modern>
superctr: You can slaughter Tiny Toons carts too. No one is gonna miss those :P.
* cr1901_modern
is not being serious, btw
<Lord_Nightmare>
i think he actually blew up the little transistor/buffer epoxy module, not the vrc7 itself
<Lord_Nightmare>
and kevtris has a schematic of that module, you can easily make a repro of it
<superctr>
strobe is the guy who composed the titan overdrive demos
<Lord_Nightmare>
oh!
<cr1901_modern>
ahhh
<Lord_Nightmare>
i was in efnet #titan for a while, but that vaporware snes tracker never materialized :(
<superctr>
color me surprised
<cr1901_modern>
There was an efnet IRC channel dedicated to titan. I remember asking kabuto some questions about how the YM2612 worked in overdrive 2.
<superctr>
i guess that effort could be spent improving SNESMOD instead
<cr1901_modern>
He was very helpful, but I never followed up
<cr1901_modern>
b/c LAZY :/
<superctr>
kabuto wrote a document describing a bunch of bugs with the megadrive vdp
<superctr>
that helped get my software to work on real hardware
<superctr>
i was stuck for a moment
<Lord_Nightmare>
i think overdrive 2 was one of the single most tested against megadrive/genesis roms during development of the analogue mega sg since it exploits so many clock accurate edge cases and bugs
<KitsuWhooa>
superctr: and some LED blinking through the controller ports :p
<Lord_Nightmare>
even so there were still bugs with it on release of the mega sg, fixed in updated firmwares
<superctr>
yes, helps when the controller ports are bascially glorified GPIO
<cr1901_modern>
he also wrote some program using DSP to fine tune YM2612 parameters _just_ right, which is what I remember asking him about
<cr1901_modern>
But I imagine it's been too long to pick up that convo again
<Lord_Nightmare>
here's a weird one: supposedly the 3 controller ports on the genesis/megadrive have some sort of hardware serial UART, which was used on the master system for a modem horse racing thingy?
<superctr>
yes
<Lord_Nightmare>
but absolutely nothing uses it, nor is it documented properly afaik?
<superctr>
there's a serial uart available on each port
<superctr>
it's used by a modem afaik
<superctr>
but it's kinda useless for most purposes since it's max 9600 baud or something like that
<Lord_Nightmare>
it was used by a modem on the genesis/md?
<Lord_Nightmare>
i thought the x-band had its own modem/serial thingy?
<cr1901_modern>
Btw, is kabuto on Freenode or just efnet?
<superctr>
this connects to the expansion port on the back (the de-9 one, not the megacd expansion connector)
<superctr>
and uses the aforementioned serial uart mode to communicate
<Lord_Nightmare>
aha!
<superctr>
but you can enable uart on the controller ports too, if you really want
<Lord_Nightmare>
... i'm still hoping the ex-xband devs can find some of their game patches for genesis/md and snes games for modem play
<Lord_Nightmare>
but its looking less likely
<superctr>
i suppose it could be used for some kind of ring network multiplayer
<Lord_Nightmare>
the server with those on it got lost after xband dissolved i think
<cr1901_modern>
natarii: xband is your domain, right?
<Lord_Nightmare>
and the patches were stored in battery backed sram on the xband modems themselves
<KitsuWhooa>
just make a serial terminal on the megadrive and hook it up to something like a raspberry pi to browse the internet ;p
<Lord_Nightmare>
and the batteries they used were undersized for the ram current draw
<superctr>
at glorious 9600 baud :P
<Lord_Nightmare>
so they died after 5 years or so
<KitsuWhooa>
superctr: well, it'll only be the text
<KitsuWhooa>
I'm thinking running something like w3m
<KitsuWhooa>
just a dumb terminal
<cr1901_modern>
KitsuWhooa: I would like to see Genesis do SSL under its own power. Just because it would be hilarious
<KitsuWhooa>
ahahahahahaha :p
<cr1901_modern>
(and BearSSL would fit comfortable into a Genesis cart)
<KitsuWhooa>
at that point you need to implement TCP and Ethernet
<Lord_Nightmare>
they used cr2032s, and they needed somethng like cr2450
<cr1901_modern>
it sucks, but uip would do the job
<Lord_Nightmare>
much beefier batteri
<Lord_Nightmare>
speaking of tcp, mbbrutman just released a new build of mTCP for dos, and unlike the last release from 2015, this one is once again open source
<Lord_Nightmare>
I'm guessing he realized that by closing the source nobody was interested in using it anymore
<KitsuWhooa>
heh
<Lord_Nightmare>
or they used the 2013 open source version
<cr1901_modern>
FUCK YES
<cr1901_modern>
awesome
<cr1901_modern>
mbbrutman is a good guy
<superctr>
why did he close the source in the first place
<Lord_Nightmare>
my question is if mtcp is written in x86-16 asm, or in C, since if its in C its theoretically portable...
<cr1901_modern>
mtcp is written in C++
<Lord_Nightmare>
superctr: people were violating the license and selling it as part of other stuff
<cr1901_modern>
Or at least, he helped me immensely in getting my 286 up and running in 2010
<superctr>
now it's GPL
<Lord_Nightmare>
i think someone was using it as part of some package to sell to corporations to keep their old 1980s dos machines working in VMs or something like that
<Lord_Nightmare>
it was always GPLv3, well, the 2013 version was
<KitsuWhooa>
Time to release the source ;p
<Lord_Nightmare>
the 2015 version was closed source
<Lord_Nightmare>
and the 2020 version is GPLv3 again
<KitsuWhooa>
I meant the source of the legacy stuff
<KitsuWhooa>
the packages you were referring to
<Lord_Nightmare>
oh, that stuff
<superctr>
i mean it's acceptable to use GPLv3 in commercial software also, as long as you follow the license terms
<Lord_Nightmare>
i have no idea what happened with that
<KitsuWhooa>
yeah, there's nothing wrong with selling GPL software
<Lord_Nightmare>
that was mbbrutman vs gpl violators
<Lord_Nightmare>
whatever happend with that happened privately
<superctr>
there's one 10kb asm file in the archive
<KitsuWhooa>
rip
<superctr>
maybe there is more inline asm in the c functions, i dunno
<cr1901_modern>
it's C++- or "C with Classes".
<Lord_Nightmare>
i'd love to have c with classes, but no STL or necessarily ABI requirements
<superctr>
c++ is probably not a big hit on the megadrive
<Lord_Nightmare>
call it 'c+'
<superctr>
with big memory constraints
<Lord_Nightmare>
constructors/destructors and classes are just too useful
<cr1901_modern>
Oh I don't doubt that. And tbh, I don't remember if MTCP itself hardcodes anything about __near and __far
<superctr>
you'll probably need to double or triple the available RAM if you want to get a C++ application to work on MD
<superctr>
64kb is too little
<KitsuWhooa>
with or without RTTI :p
<cr1901_modern>
superctr: This doesn't use exceptions or any of the STL
<cr1901_modern>
or even virtual functions I think
<Lord_Nightmare>
what about rust? is there a rust backend for 68k?
<cr1901_modern>
Yes and no
<cr1901_modern>
Someone's working on it, it's not ready last I heard
<Lord_Nightmare>
i kinda like rust, or at least the idea of it. The coding style seemed kinda awkward
<cr1901_modern>
And the llvm backend for 68k will _not_ be accepted upstream
* KitsuWhooa
can't read rust code, let alone write it
<KitsuWhooa>
cr1901_modern: ouch
<superctr>
when i see a md game programmed in rust i will probably say "at least it's not BASIC"
<Lord_Nightmare>
there's also nim and crystal which each have advantages and disadvantages, i think those two are in the frontrunner for 'c replacement that isn't rust'
<superctr>
honestly there is a bit of effort in order to keep the 68k backend in GCC
<Lord_Nightmare>
nim is portable, crystal compiles to faster code but cannot run on windows at all
<Lord_Nightmare>
isn't llvm basically forked at this point, with the pre-9.0 forked by openbsd and wine guys, since it isn't compatible with lgplv2?
<Lord_Nightmare>
the llvm guys fucked that one up; they added an exception in the license for gplv2 but NOT lgplv2
<Lord_Nightmare>
in the new apache 2.0 + exceptions license
<Lord_Nightmare>
and wine needs llvm for mac 32 bit emulation stuff
<Lord_Nightmare>
and wine license is lgplv2
<superctr>
i was under the impression that llvm is used for a lot of different things
<cr1901_modern>
VAX was one backend w/ the mode-cc problem
<superctr>
like shader recompilation
<Lord_Nightmare>
there's one more smaller project which has the same problem with new llvm
<Lord_Nightmare>
whatever the case, there will just be 2 forks now
<superctr>
that is used by graphics API emulation layers
<cr1901_modern>
Lord_Nightmare: Realistically, I think an mtcp port to 68k might be feasible.
<superctr>
port to 68k is possible, sure
<cr1901_modern>
In my dream world, I'd be running Rust code on the Genesis and could port smoltcp
<superctr>
but to MD, maybe not
<Lord_Nightmare>
as long as people allow patches to upstream to be licensed under the old license for the other fork...
<superctr>
i think the biggest limitation is that you only have 64k ram
<Lord_Nightmare>
i know the big corporate patches that allow linux to compile with llvm will not be licnesed anything but apache2
<Lord_Nightmare>
since those big patches were the reason for the relicensing in the first place
<superctr>
you can easily fit a tcp/ip stack in the 64k of ram, but now you want SSL too
<Lord_Nightmare>
those patches sat for like 5 years waiting for the relicensing
<KitsuWhooa>
apparently linux compiles now under clang without patches
<KitsuWhooa>
haven't tried it
<Lord_Nightmare>
yes, but only clang 8.0+ which is under apache2
<Lord_Nightmare>
er
<KitsuWhooa>
ah, I see
<Lord_Nightmare>
9.0+
<superctr>
apache, the graveyard of open source software
<Lord_Nightmare>
8.xx and below clang is licnesed under a MIT-like license
<Lord_Nightmare>
and both openbsd and wine/valve forked llvm/clang at the last 8.xx version
<Lord_Nightmare>
wine since they can't include apache2 code due to license issues
<superctr>
who agreed on the apache2 license change?
<Lord_Nightmare>
and openbsd... it may be just one dev who forked it
<Lord_Nightmare>
apparently they had a big MAME-like relicensing thing
<superctr>
doesn't every contributor need to agree for something like that to happen
<Lord_Nightmare>
one major contributor did NOT agree to relicense initially
<Lord_Nightmare>
but the licnese change happened anyway
<Lord_Nightmare>
so either their code was purged or they were 'convinced' somehow
<Lord_Nightmare>
and yes all contributors need to agree
<Lord_Nightmare>
mozilla's relicensing lawyers came up with 'if 95% of code is relicensed go ahead'
<Lord_Nightmare>
i don't know what clang/llvm followed
<Lord_Nightmare>
i know with MAME, we had ~92% code relicensed with the last major contributor being jarek with his FM cores
<Lord_Nightmare>
once he relicensed his stuff gplv2, all the remaining code in MAME that wasn't license compatible was purged and rewritten and that was that
<Lord_Nightmare>
it was done in like a week, after he relicensed his stuff
<Lord_Nightmare>
there's still the occasional person who climbs out of the woodwork and points out their code wasn't attributed correctly, we haven't had any issues with them declining yet though
<Lord_Nightmare>
since some MAME code from back in the aaron giles, pre VCS days lost its proper attribution
<cr1901_modern>
Is it immoral to include a clause in your contributing guidelines such as:
<cr1901_modern>
"By submitting this code you agree to a potential OSI-compatible relicense in the future."
<KitsuWhooa>
I'm not sure I would agree to something like that
<cr1901_modern>
Sure, I'm asking if the clause in and of itself is immoral
<superctr>
well yeah
<superctr>
it means that the owner of the repository could at any time switch from for example GPL to BSD
<superctr>
so he can then use the code in a proprietary product without following the original GPL terms
<superctr>
essentially stealing the code
<cr1901_modern>
Ahhh
<natarii>
yeah xband patches were in battery backed sram. a few remain though
<natarii>
some came from the original devs, and i think one or two were dumped from modems that hadnt died yet
<cr1901_modern>
Didn't sonic 3 use nonvolatile long term R/W storage?
<cr1901_modern>
COuldn't xband have done the same or too expensive?
<natarii>
they probably didn't see the need
<KitsuWhooa>
Apparently the FRAM in the S3 cart is rated for 10 years of data retention without power
<superctr>
sram is a perfectly good fit for xband though
<superctr>
you typically can't run code off eeprom or flash, and for xband the game patch can be downloaded at anytime anyway
<superctr>
and sonic 3's eeprom is 1kb... which is basically nothing compared with the sram in the xband
<cr1901_modern>
ahh I didn't know that
<superctr>
sonic 3 uses a funny kind of non volatile DRAM called FeRAM, i'm not sure how access time compares with sram, but i know that in the 90s it was really low density, so unlikely ot be used to store patches
<KitsuWhooa>
it was 4kbit
grauw has quit [Read error: Connection reset by peer]