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 has joined ##yamahasynths
andlabs has quit [Ping timeout: 246 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Lord_Nightmare>
kevtris wrote every one of his cores from scratch, using the same docs/decaps everyone else has, and his own hardware testing
<andlabs>
I dislike this market for other reasons
<andlabs>
but if they aren't violating the GPL then I can't call them out for this
<Ultrasauce>
one of the projects he mentions doesnt even have an explicit license....
<TD-Linux>
all of the kevtris based analogue consoles are great, and yeah his cores are all homebrew
<TD-Linux>
before fx68k there was no sufficiently accurate 68k core anyway so I don't see how that makes sense as an accusation
<TD-Linux>
the analogue nt (pre fpga) is terrible though
<TD-Linux>
Lord_Nightmare, also that's a mega old tweet did they do something new?
<Lord_Nightmare>
there was an accusation, now deleted, in june about kevtris stealing the ym2612 core because a bug (due to bad docs) existed both in the mister core and kevtris' core
<Lord_Nightmare>
the reason the bug existed is because the docs floating around all had the wrong info
<Lord_Nightmare>
I was told about this whole mess today, and it pisses me the hell off
<superctr_>
for being a "copyleft" license, GPL users like to throw around copyright violation accusations often
<whitequark>
that's a feature of GPL
<whitequark>
and one of the reasons i don't use it personally
<superctr_>
if you make a program and release it under the GPL, apparently it gives you exclusivity to make similar programs, like a patent
<TD-Linux>
I don't think this is a GPL users thing but is more common arcade "scene" mentality
<superctr_>
arcade scene, hm most of MAME's code is not GPL'd, though it is as a whole (though ironically all FM emulation code is)
<TD-Linux>
people get butthurt all the time about stuff being cloned/leaked, which I find mega ironic because it's all copies of the original anyway
<superctr_>
you can 'steal' my MAME contributions like Hoot did, the only thing i would want is some credit
<superctr_>
which hoot did not, whatever...
<superctr_>
companies that break the GPL generally don't care about copyright anyway, so you will have to sue them for it anyway
<superctr_>
i think the only effect of GPL is that hobbyists and individuals (and honest companies...) get shamed into not using the code or treating it as lava
<superctr_>
and the rest will just steal it as if it was nothing anyway
<superctr_>
the purpose of the GPL to "honor their users freedom" becomes moot if it limits the developers freedom to actually use GPL code or portions of it. at least in libraries
<superctr_>
i can see the point of GPL for complete programs, as it could prevent closed source forks or whatever, but for libraries i think it is too restrictive, and really reminds me of software patents
<TD-Linux>
too late at night for me to have a GPL argument tbh
<whitequark>
the effect of GPL is that someone at Facebook gets paid to rewrite your library but slightly shittier
<superctr_>
or, in the case of complete applications like the GCC, companies like Apple spend money into developing a competitor like LLVM instead
<superctr_>
which by this point is superior in many ways to GCC, while at the same time having a more liberal (and still free software) license
<whitequark>
and which forced GCC to improve in many aspects!
<Lord_Nightmare>
there are important libraries which i never understood why they were gpl rather than lgpl other than seemingly to discourage people from rewriting them publically or using them
<Lord_Nightmare>
notable examples are libreadline, libfftw, libffte
<whitequark>
there's libedit
<whitequark>
regarding libreadline: stallman makes it an example, you might want to read that
<whitequark>
tl;dr he thought that the allure of being able to use libreadline would make people GPL their entire program
<whitequark>
this is basically vendor lock-in
<andlabs>
almost
<andlabs>
he effectively muscled his favorite common lisp implementation into being GPL by making libreadline GPL
<andlabs>
and is coasting on that personal victory
<whitequark>
oh.
<whitequark>
well that's even more depressing
<andlabs>
that's why he holds it up as an example
<andlabs>
anyway the GPL can do a lot of good if people didn't severely misunderstand it
<Lord_Nightmare>
yep technically clisp was bsd at first but used libreadline so stallman rather than giving him the option of removing it forced him to gpl it instead
<whitequark>
libreadline isn't even good
<Lord_Nightmare>
however at this point i think CMUCL and SBCL are superior to clisp, though they don't have as large a repertoire of programs
<andlabs>
stallman is an extremely paranoid individual who is often detached from reality
<Lord_Nightmare>
i was also wondering about forking the very first version of clisp and replacing libreadline with bsdreadline
<Lord_Nightmare>
but i can't find it
<andlabs>
to the point that even other members of the FSF have to knock him down a peg
<Lord_Nightmare>
lost usenet/mailing list stuff
<andlabs>
see also: his claims that adding LLVM lldb support to emacs constitutes a takeover of free software
<Lord_Nightmare>
<whitequark> tl;dr he thought that the allure of being able to use libreadline would make people GPL their entire program - why the fuck would anyone want to do that?
<andlabs>
because it was 1985 and people were still used to paper-roll terminals
<Lord_Nightmare>
the ONLY code i release as gpl is mostly code i truly don't WANT people to use in their stuff, because its preliminary and buggy
<andlabs>
the only code I release as GPL is code that I feel would be too high-risk of abuse
<whitequark>
it's interesting because gpl started as a legitimate labor dispute
<Lord_Nightmare>
like an old buggy fm patch converter, which i would release the preview as agplv3 for the sole purpose of dissuading people from embedding it in their shit and causing problems later on
<andlabs>
for instance, reallymine, my hard drive decryption program, is GPL because the data recovery market is full of total monsters
<Lord_Nightmare>
once its debugged i'd release it as mit or bsd
<andlabs>
forcing knowledge to be shared is good
<andlabs>
and besides, now that the knowledge is out, anyone can go and write their own more liberally licensed implementation
<Lord_Nightmare>
this makes sense, but i'd prefer to write stuff that's good enough that anyone can use it and it will 'just work'
<andlabs>
(which is why I'm frustrated by one not existing for the YM2612 code in MAME)
<Lord_Nightmare>
blame jarek for that
<Lord_Nightmare>
also the ym2612 code in MAME is definitely not bug free
<andlabs>
no I mean an equivalent made by someone else
<andlabs>
heh
<Lord_Nightmare>
i think it may process operators in the wrong order, for instance
<Lord_Nightmare>
both plogue's core and kevtris' core do it right
<Lord_Nightmare>
no idea about jotego's mister core, and i don't care to look lest i 'infect myself with his ideas'
<Lord_Nightmare>
sort of like infecting ones self with head lice
<andlabs>
anyway I'm not a fan of what Analogue is doing because I'm not a fan of what any of these modern retro people are doing
<andlabs>
but I really don't want to get into that because it makes me angry and depressed about how much effort I spent into games ten years ago
<Lord_Nightmare>
there's no really good open source scan rate converter
<Lord_Nightmare>
the OSSC is buggy and violates the hdmi spec
<andlabs>
I have feared the situation we are in since super fighter fucking team
<andlabs>
could not have predicted what actually HAS happened since...
<Lord_Nightmare>
someone who actually knows what they're doing needs to make a scan converter that doesn't suck
<Lord_Nightmare>
what was super fighter team?
<andlabs>
the beggar prince guy
<Lord_Nightmare>
was that that commercial snes emulator circa 1998?
<whitequark>
sometimes it feels like the intersection of "people who know what they're doing" and "retro enthusiasts" is extremely slim
<andlabs>
Sik tells me that the C64 community appears to be starting to get tired of the re-commercialization of their platform
<andlabs>
I don't believe him, but I really want to
<andlabs>
in any event
<andlabs>
what really scares me about the GPL is shit like that recent CPAP hacking thing
<andlabs>
it was shut down because of some vague community drama and the guy there said "Friends don't let friends license things under the GPL"
<andlabs>
so I'm fearing it's someone trying to steal the glory, so to speak
<andlabs>
I had a friend who fell into that same trap - a glory seeker released friend's code as their own
<andlabs>
and if that alone is going to make people give up on free software...
<andlabs>
(because these kinds of people are likely not going to tolerate permissive licenses either)
<Lord_Nightmare>
the ossc has at least the following problems: insufficient/missing input overvoltage/ESD protection; improper timing of the hdmi signal (must be within 0.01fps of 60fps, so streaming snes at its native rate of 60.10fps requires buffering a frame over time and skipping one frame every 10 seconds or so)
<Lord_Nightmare>
it may also be sending bad stream metadata
<Lord_Nightmare>
a lot of tvs HATE the ossc
<Lord_Nightmare>
someone needs to debug it with one of those big expensive hdmi analyzer devices
<Lord_Nightmare>
basically a pc-sized unit with its own screen
<andlabs>
I have no idea what any of this even is
<andlabs>
my knowledge of how video displays work is basically imited to those videos ben eater did last month
<Lord_Nightmare>
that shows all the statistics of the hdmi signal/stream and will flag errors
<Lord_Nightmare>
also the ossc, if you connect it to a SNES' RGB out, and play ff4/ff5/ff6 and cast a spell which flashes the whole screen (pearl?) the ossc will LOSE SYNC
<Lord_Nightmare>
we don't know why
<andlabs>
oops
<andlabs>
is this the kind of losing sync that can damage CRTs?
<Lord_Nightmare>
i suspect the bg color being rapidly changed causes the AGC/dc level detection in the ossc to go crazy
<Lord_Nightmare>
i don't know if it is a digital problem or an analog issue
<andlabs>
huh
<Lord_Nightmare>
if its an analog issue it will require a board revision to fix
<Lord_Nightmare>
if it is a digital problem it requires verilog fixes
<TD-Linux>
the inaccurate timing of hdmi is intentional
<TD-Linux>
if it didn't do that it would need a framebuffer
<Lord_Nightmare>
and it should have one.
<Lord_Nightmare>
it doesn't usually need to buffer an entire frame
<Lord_Nightmare>
just part of one
<andlabs>
framebuffer for what
<TD-Linux>
ew no. use an xrgb if you want that
<andlabs>
going back from 59.97whatever to 60?
<Lord_Nightmare>
the idea is to have a MAXIMUM of 1 frame of lag
<andlabs>
[02:41:19] <+andlabs>ho, what demons shall I release (tomorrow, when I implement these)
<Lord_Nightmare>
for 60.10 to 60.00, your buffer will slowly grow larger and after 10 seconds the buffer will hold one entire frame, which will be thrown out rather tahn displayed
<Lord_Nightmare>
so every 10 seconds you fall behind then skip a single frame, repeat
<Lord_Nightmare>
imho that's tolerable
<whitequark>
that can be implemented with just a fifo, right?
<Lord_Nightmare>
yes, a long fifo
<Lord_Nightmare>
if you want to do clever stuff like upscaling with epx, hq2x/hq3x or xbr, you will need to buffer at least 3, 4 or 5 scanlines respectively
<Lord_Nightmare>
if you want to do scanlines from a 240p signal, you need to output in 480p or 720p; 1080p is not an even integer multiple of 240p
<Lord_Nightmare>
its 4.5 scanlines per source scanline
<Lord_Nightmare>
so if you output in 1080p you have to do some hacks for scaling, either blending every 5th scanline or nearest-ing every 5th
<Lord_Nightmare>
both look gross
<Lord_Nightmare>
if you want your upscaler to do deinterlacing, that REQUIRES a framebuffer holding one complete field
<Lord_Nightmare>
and if your device takes composite input, you will likely need to buffer an entire pair of fields to properly extract luma/chroma
<Lord_Nightmare>
using RTLSDR for that... might work.
<Lord_Nightmare>
the ossc i think wisely only takes rgb (or component, which is just rgb encoded with some matrix math to y cb cr, which can be undone by an fpga easily enough)
<Lord_Nightmare>
turning composite into rgb is a whole other can of worms that i'd really rather not deal with
<Lord_Nightmare>
the guys doing the domesday duplicator project have some really nifty ideas on how to do that, and they have extremely accurate pal decoding/chroma luma split done already
<Lord_Nightmare>
using 2d and 3d filtering
<TD-Linux>
<Lord_Nightmare> and if your device takes composite input, you will likely need to buffer an entire pair of fields to properly extract luma/chroma <- nope. most comb filters only operate on one or two scanline delay
<TD-Linux>
you can of course do temporal comb filters but it is not necessary
<Lord_Nightmare>
ah, 2d filter is one or 2 scanlines
<TD-Linux>
original ntsc decoders just did low pass
<Lord_Nightmare>
3d filter is 1 or 2 frames
<Lord_Nightmare>
and not fields, frames
<Lord_Nightmare>
though i think the 3d filters are smart enough to see whether they have a 240p vs 480i signal coming in
<Lord_Nightmare>
and buffer 2 frames instead of 4 when they have 240p
<Lord_Nightmare>
i wonder if this is what some of the 'movie' modes on flatscreen tvs do
<Lord_Nightmare>
3d filtering with some delay
<Lord_Nightmare>
i know some of them do motion smoothing using h.26x motion detection
<Lord_Nightmare>
which looks... ok sometimes, and really ugly other times
<Lord_Nightmare>
also that us a fuckload of ugly bodge wires
_whitelogger has joined ##yamahasynths
<cr1901_modern>
I'm very uncomfortable with the idea that storing a full frame to convert from psuedo-NTSC to (psuedo)-HDMI is going to be inevitable for accurate reproduction of console output.
<cr1901_modern>
Bad enough that software emulators are limited to 16.66ms of lag
<cr1901_modern>
TD-Linux: >original ntsc decoders just did low pass
<cr1901_modern>
Why are comb filters used instead today? Intuitively, low pass feels like it should get the job done (since the luma has symmetric freq response)
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 248 seconds]
andlabs has joined ##yamahasynths
<Lord_Nightmare>
cr1901_modern: the hdmi spec requires 60.00 fps +- 0.01fps, there's no getting around that
<Lord_Nightmare>
if you go outside that spec, some tvs just won't sync and others will randomly drop the signal
<Lord_Nightmare>
since actual consoles produce pretty much anything between ~58fps to ~62fps, this is a big problem
<Lord_Nightmare>
mostly its between 59.5fps and 60.5fps
<Lord_Nightmare>
but some arcade boards are much further out of spec than that
<Lord_Nightmare>
so for an upscaler, in order to remain within the hdmi spec and not cut corners like ossc does, has to buffer 1 frame AT MOST
<Lord_Nightmare>
if the input rgb signal is exactly 60.00fps, it won't buffer more than a few lines at most
<Lord_Nightmare>
if the input signal is 61fps, it will skip 1 frame every second
<Lord_Nightmare>
if the input signal is 59fps, it will duplicate 1 frame every second
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<TD-Linux>
cr1901_modern, if you assume neighboring lines are uncorrelated, a high quality low pass is ideal
<TD-Linux>
but turns out they usually are correlated, chroma especially so, so you can generally get more
<TD-Linux>
in addition, neighboring lines have their colorbursts out of phase so if chroma is actually the same, they totally cancel
<TD-Linux>
Lord_Nightmare, yes it is a rather complex and overkill midi uart
<TD-Linux>
which makes a bit more sense when you consider it was originally designed for z80
<Lord_Nightmare>
ntsc doesnt invert the colorburst every other line; pal does.
<TD-Linux>
sorry, neigbhoring frames
<Lord_Nightmare>
so its inverted every frame, or every field?
<TD-Linux>
frame
<TD-Linux>
which is why 3d comb filters are a frame, not field, delay
ej5 has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]