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
doppler has quit [Quit: doppler]
mrspicy224489 has quit [Remote host closed the connection]
futarisIRCcloud has joined ##yamahasynths
<andlabs>
five 6303 instructions in, already 2105 bytes -- out of 16128 I can fit in msx RAM bank 0
<andlabs>
or 32512 inb anks 0 and 1
SceneCAT has quit [Quit: *Mreow*]
SceneCAT has joined ##yamahasynths
doppler_ has joined ##yamahasynths
doppler_ is now known as doppler
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
<andlabs>
what's the best mid-90s PSU for driving both a 5.25 and a 3.5 FDD, I guess is my question now
<andlabs>
I need to stop having scattered questions that cycle between potential projects
<cr1901_modern>
Anything over 150W will be fine
<andlabs>
for some reason the idea of a used PSU that's isolated on its own makes me feel clueless for some reason
<andlabs>
even though I'm fine with PSUs that are still part of their components
<andlabs>
heh
<andlabs>
*their devices
_whitelogger has joined ##yamahasynths
Xyz39808 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
Xyz_39808 has quit [Read error: Connection reset by peer]
SceneCAT has quit [Read error: Connection reset by peer]
SceneCAT has joined ##yamahasynths
<whitequark>
150 W for a FDD?!
<whitequark>
andlabs: do you specifically need mid 90s?
<whitequark>
"picopsu" provides you with everything you might need from ATX except negative voltages, and most of the connectors you might find
<whitequark>
which is what i use for my FDDs and ST422
<whitequark>
er
<whitequark>
st412?
<cr1901_modern>
I interpreted the question as "what do I need to power a computer system with a 5.25" and 3.5" drive?".
<cr1901_modern>
63W power supply (original IBM PC) is enough for that, but 150W is the smallest PSU I've seen contemporaneous w/ 5.25" and 3.5" drive.
<cr1901_modern>
(shitty Packard Bell 486 that should've bit the dust years ago but I still keep alive somehow)
<cr1901_modern>
whitequark: You got an ST-412?
<whitequark>
uhhh let me dig it out
<whitequark>
it's some of those ancient drives
<cr1901_modern>
I remember you getting an MFM drive, but I thought it was ST-225 (half height)
<whitequark>
st225
<whitequark>
yes
<cr1901_modern>
ahhh cool. Thought you acquired another one from that Russian website that's like Ebay/Craig'slist, but not (I didn't dream that up, right?)
<whitequark>
yes
<whitequark>
it's a classifieds website. avito.ru
<whitequark>
absolutely nothing notable about it
<whitequark>
very useful for getting weird/ancient crap
<whitequark>
though the success is spotty. people have definitely caught up that 90s hardware is "vintage" now
<cr1901_modern>
Also, apropos of floppies, I just realized that in the past I've said "the earliest cd rom data xfer rates were slower than floppies". This is incorrect. >>
<cr1901_modern>
It's 150 KBYTES/sec for CDs and 250kBITS/sec for 5.25" MFM floppies
<cr1901_modern>
oops ._.
<whitequark>
huh
<whitequark>
what did you search for
<cr1901_modern>
"cd rom 1x speed", and I remembered the floppy disk rate from that Intel FDC datasheet.
<cr1901_modern>
Seems I subconciously replaces "bits" with "bytes", even though that makes no sense when I think about it.
<cr1901_modern>
(Or put another way, the write clock for 5.25" MFM floppies is 500 kHz. Since you can only do 250,000 transitions per sec, and one transition == 1 data bit in MFM, that means you encode 250kbits/sec
<whitequark>
no i mean on vito
<whitequark>
*avito
<whitequark>
also wait
<cr1901_modern>
Oh, I just went to "avito.ru", with nothing else. It was one of the top results.
<cr1901_modern>
And now my whole feed is filled with tires.
<whitequark>
ugh this makes me want to see how much data i can squeeze onto a floppy
<whitequark>
i should add write support to glasgow
<whitequark>
and see what is the resolution of domain sizes i can get
<cr1901_modern>
would be an interesting experiment w/ 3.5" disks. Spoiler alert: 360kB disks do not take a 1.2MB format reliably. Though maybe if it used, say 8b10b encoding, success rate would be better.
<whitequark>
well yes
<whitequark>
not 8b10b though
<whitequark>
8b10b achieves the goal of DC balance which is irrelevant for floppies
<whitequark>
in this case we are looking for transition density alone
<whitequark>
which means that of existing encodings, EFM would be appropriate
<whitequark>
i think zip drives used something not unlike EFM?
<cr1901_modern>
same one used on CDs?
<whitequark>
yes that's the red book one
<whitequark>
take a look at iomega's patents
<whitequark>
they use some other RLL encoding, maybe you've seen similar somewhere
<whitequark>
it doesn't remind me of anything
<Sarayan>
whitequark: magnetic domains migrate over time though, that's part of what was needed to understand and precompensate for to make DD/HD reliable
<cr1901_modern>
Ahh yes, 'cept I found the Europe version first.
<cr1901_modern>
RLL (besides 0,1- FMand 1,3- MFM and 1,4- variant of MFM that no one used) is still weird to me because you can no longer uniquely decode individual bits at a time.
<cr1901_modern>
But I guess that also makes it similar to 8b10b and friends
<cr1901_modern>
whitequark: I vaguely recall that you wanted to run an experiment to generate a bunch of xbyb encoding tables, and find the subset of tables that meet the requirements of an RLL code
<whitequark>
yes. but these days i would actually use an SMT solver to do it for me, i think.
<whitequark>
speaking of which, i'm incredibly bored.
<whitequark>
let's try that
<cr1901_modern>
hahaha
<whitequark>
i'm not totally sure it's a good fit yet
<whitequark>
or if i can actually write the problem in a nice way
<cr1901_modern>
One thing I've noticed about all the RLL codes compared to xbyb encodings... there are multiple bit groups that are encoded: https://en.wikipedia.org/wiki/Run-length_limited#(2,7)_RLL
<cr1901_modern>
whereas e.g. 8b10b will map all 256 possible combinations of 8 bits to a sequence of 10 bits.
<cr1901_modern>
Idk the criteria for choosing bit groups, but they look like a prefix-free code
<cr1901_modern>
err, scrap that. There's a pattern to the bit groups in the linked article but Idk how to describe it other than "zero-padding"
<whitequark>
i think it's "self-synchronizing"?
<cr1901_modern>
It may be- and that makes sense. I checked again- they are prefix codes*.
<cr1901_modern>
And self-synchronizing implies prefix code
<cr1901_modern>
it's not self synchronizing I don't think... in the bitstream 1110, the "11" in the middle is a valid code
<Sarayan>
I wonder of analog the output of a drive head actually is and whether probabilistic viterbi decoding would help
<Sarayan>
(yes, the decoding program would probably be bigger than what's storeable on the floppy)
<cr1901_modern>
Sarayan: It's semi-gaussian. Shugart has an internal memo from the late 70s describing it.
<Sarayan>
wq: if you're bored you have a sc01 waiting for you in a box ;-)
<cr1901_modern>
... that I can't find atm
<whitequark>
Sarayan: not currently capable of doing hardware work i think
<Sarayan>
ok, you're the best judge of that :-)
<whitequark>
viterbi would *definitely* help
<Sarayan>
iirc there's also a yamaha sound chip (forgot which) and a security cat701 which I'm curious what's inside
<whitequark>
in fct i think with an analog tap we could extract the actual channel bandwidth from the floppy
<whitequark>
hm
<whitequark>
dumb idea
<Sarayan>
I've already reversed the behaviour of the security chip from the outside, so it's just curiosity
<whitequark>
use hx711 for readout
<whitequark>
ok no it's dumb because the sample rate is very low
<whitequark>
i just hate the idea of doing any analog work whatsoever (because i'm not competent in it)
<Sarayan>
that's ok, I'm not competent for either analog *or* digital :-)
<whitequark>
cr1901_modern: semi-gaussian meaning it's a channel that injects white noise?
<whitequark>
or something close
<Sarayan>
it's supposed to be the derivative of the magnetic flux intensity
<whitequark>
yes, i know
<Sarayan>
which a pinch of ambiant electromagnetic noise added for extra fun
<whitequark>
the problem i have is it's a very small signal on a very noisy board (motors, etc)
<whitequark>
with my scope i can't detect *anything*
<cr1901_modern>
whitequark: Sorry I didn't mean Gaussian in a probabilistic sense, but literally the signal has the shape of a periodic Gaussian function
<whitequark>
oh
<whitequark>
ok but what about the *shifting*?
<Sarayan>
periodic gaussian is somewhat nonsensical
<cr1901_modern>
Like think of a sinusoid, but the voltage ramps up and down in the shape of a Gaussian
<cr1901_modern>
Sarayan ^
<cr1901_modern>
Idk what a floppy read signal looks like when the domain is shifted
<cr1901_modern>
Floppy controllers handle this during writes by writing early so the shift makes the data appear in the right place during read.
<cr1901_modern>
So it can't be that much different, otherwise the read signal wouldn't survive conversion to digital domain
<whitequark>
i'm referencing this: 11:47 < Sarayan> whitequark: magnetic domains migrate over time though
<whitequark>
shifting *during writes* are very easy to compensate for
<whitequark>
because i can just sample them and see what happens
<whitequark>
but shifting *over time* is much more nasty since i hve to do some long term storge experimetns
<cr1901_modern>
Not sure what that looks like, tbh
<cr1901_modern>
whitequark: Perhaps you should ask bitsavers since he's done analog captures of bad floppies
<cr1901_modern>
I _very_ vaguely recall that magnetic domain shifting also lengthens the time it takes for the signal to reach its final amplitude. Which == smaller derivative == less likely to be picked up by differentiator.
<whitequark>
individual bad floppies are not enough
<whitequark>
i need something like the research that floppy engineers surely did
<cr1901_modern>
I asked a related question a long time ago on vcfed. Lemme see if I can find it
<andlabs>
yeah that looks like the official website...
<Sarayan>
wq: iirc the precompensation information for the wd1772 is interesting in that it tells you what they do to compensate
<whitequark>
andlabs: there are no official picopsus that i know of
<whitequark>
as far as i'm concerned they are all clones, they're basically jellybean parts by this point
<whitequark>
oh, "pat pend"
<whitequark>
that might actually be the original?
<andlabs>
yeah, other websites seem to confirm that it is
<whitequark>
so that should definitely work. i have some random clone i bought because it was cheap and they had delivery
<whitequark>
bitcoin people use those a lot
<andlabs>
now I guess I need to ask not only which one is best but also whether I need one of these wall bricks as well
<andlabs>
lol
<whitequark>
so everyone clones them and they're cheap
<andlabs>
I should probably not be helpless
<whitequark>
wall brick: yes, it runs off an existing 12V dc barrel jack
<whitequark>
which i assume you already have somewhere
<whitequark>
half the routers use that
<whitequark>
except for adsl which seems to use 15Vac or something else equally obnoxious, not sure why
<Sarayan>
wq: specifically, if I understand correctly, they make pairs of flux changes closer, e.g. two flux changes at 4us from each other end up 3.85us
<whitequark>
Sarayan: yeah, i know about that effect
<whitequark>
this is not a huge problem as i would have to qualify the media myself and i'll pick it up regardless
<whitequark>
but you mentioned shifting *with time*
<whitequark>
now that is concerning
<Sarayan>
so I guess they expect uniform magnetic zones to push against each other, the smaller ones expanding and as a result the larger contracting
<Sarayan>
as far as I know precomp is for time stability
<andlabs>
misread: with ads!
<Sarayan>
ubt icbw
<Sarayan>
but
<andlabs>
so then the last question then is which one do I get
<whitequark>
Sarayan: ohhhhhhh
<andlabs>
I'm guessing that would depend on what the drives I want to use these with are rated for
<whitequark>
andlabs: i would find it unlikely and very concerning that an FDD could overpower a picopsu
<andlabs>
other way around
<whitequark>
hm?
<andlabs>
the psu overpowering the FDD
<whitequark>
how could that posssibly happen?
<andlabs>
I don't know
<andlabs>
but that's what I'm concerned about
<andlabs>
feeding too much wattage through
<andlabs>
the 3.5 drive I'm looking at right now is a FD1231T
<whitequark>
the psu provides a regulated voltage. regulated significantly better than contemporary psus, i must add
<andlabs>
ahhh
<andlabs>
so they why do they offer multiple wattages
<whitequark>
then it's up to the fdd to draw current (or not)
<whitequark>
yeah
<whitequark>
i think the last computer with an unregulated psu shipped before i was born
<whitequark>
or regulated poorly enough you had to take the load into account
<whitequark>
multiple wattages there mean that picopsu comes in multiple *maximum* wattages
<whitequark>
if you try to draw too much it'll just shut down
<andlabs>
ah ok
<whitequark>
(the 12V rail comes right to your wall adapter though)
<whitequark>
(which will also just shut down if it's not some bargain bin thing where they cut every last corner)
<Sarayan>
I'm utterly failing about finding decent information about the physical whys of precomp, gee
<whitequark>
FD1231T is a bog standard 3.5" floppy, right?
<andlabs>
yeah
<whitequark>
you should have no problems running that off the cheapest picopsu, or for that matter almost any 5V >=2A regulated supply you can find
<andlabs>
used by Compaq apparently
<andlabs>
ah
<whitequark>
i wouln't even bother with a picopsu as one, just grab the nearest 5V adapter that can provide enough current
<whitequark>
for the 5.25", yes, makes some sense
<whitequark>
since i believe those drives use both rails
<andlabs>
I might as well be safe here since I don't fully know what I'm doing here
<andlabs>
my plan now was to get the drives, these PSUs, and two separate enclosures
<andlabs>
which means yes, two glasgows or two fluxengines
<whitequark>
sure, if you hve the cash, you can just do that
<whitequark>
no reason not to do it other than "costs more"
<andlabs>
the soac in the fluxengine is only $10 lol
<andlabs>
not sure how much a glasgow costs to make
<andlabs>
*buy
<whitequark>
soac?
<andlabs>
whatever it was called
<whitequark>
what's a soac
<andlabs>
system on a chip
<andlabs>
okay PSoC here
<whitequark>
oh
<whitequark>
SoC
<whitequark>
is the general term
<andlabs>
heh.
<andlabs>
but yeah I can spare the expense
<andlabs>
5.25" isn't a high priority for me right now in any event
<whitequark>
the cost of a glasgow currently is about $200, but we successfully reduced it to less than $50 with some changes
<andlabs>
I do have a couple of PC programs and one PC-88 program on 5.25" disks but I have more 3.5" disks to preserve
<whitequark>
expect to pay $200 for each for now, though
<andlabs>
(and also most fo my 5.25" disks are C64 which fluxengine isn't guaranteed to work correctly with yet, but for now I have a zoomfloppy which'll suffice — not sure about glasgow, despite both using the same drives)
<whitequark>
glasgow (hardware and software driving that hardware) doesn't even try to interpret the data from the floppy
<whitequark>
it just saves it like a fast logic analyzer
<whitequark>
as long as the electrical interface is the good old shugart floppy, glasgow will do the job
<whitequark>
heck, with a differential receiver, it should even work on st-412 interface, with minor changes
<andlabs>
instead of listing hewlett-packard disk drives it just said "all models supported"
<andlabs>
and the only results I could find for htheir scsi enclosure swasn't a dual 5.25" enclsoure but rather high end server racks with like 50 slots
<Lord_Nightmare>
had an issue where this F***ING ISSUE FROM 2014 in udev's btrfs script in arch/artix linux has a race condition and NOBODY EVER FIXED THE DAMN THING
<Lord_Nightmare>
means on system update, dependent on moon phase, the system will refuse to reboot
<Lord_Nightmare>
there's simple hacks like changing the hooks order
<Lord_Nightmare>
and worse hacks like force-loading btrfs first always
<Lord_Nightmare>
the real solution is something nobody wants to get off their ass and do
<andlabs>
udev?
<andlabs>
pfft
<andlabs>
if Kay Sievers can't reproduce the issue it's, in lack of a better term, Fake News™
<andlabs>
the biggest problem with systemd is that the two people in charge (Sievers and Leonardt Poettering) are total assholes
<andlabs>
if it's not any of the limited range of hardware configurations they care about then you're fucked
<andlabs>
Sievers is one of the few people who justifiably received the worst of Linus Torvalds's bad behavior
<andlabs>
you may as well fix the issue yourself, sorry
<Lord_Nightmare>
i'm not using systemd, i'm using the 'excised' udev with openrc
<Lord_Nightmare>
imho openrc is a hell of a lot more secure than systemd, since its a monolithic init process which does one thing and doesn't have a friggin web server embedded in it like systemd does
<Lord_Nightmare>
(technically i'm overreaching there, the systemd web server i think is a module and isn't part of the main process)
<Lord_Nightmare>
(but still, systemd is way the hell too large and bloated for its own good)
<Lord_Nightmare>
imho systemd can retain every feature it has and improve security DRASTICALLY by separating pid1 into like 10 subprocesses/daemons
<Lord_Nightmare>
and having separate user perms for the daemons
<Lord_Nightmare>
so each is pigeonholed into doing specific things
<Lord_Nightmare>
iirc freebsd has a system call filter thing to allow even more restrictions, and that's a thing i think linux should steal
<Lord_Nightmare>
every daemon should have the minimum possible permissions necessary to do its work
<Lord_Nightmare>
reduction of attack surface
<Lord_Nightmare>
hacking a web service is pretty useless if all it can do is read the files in one directory and talk on port 8000
<KitsuWhooa>
sytemd has SystemCallFilter
<KitsuWhooa>
as well as all sorts of sandboxing
<KitsuWhooa>
and there's apparmor/selinux for additional protections
<Lord_Nightmare>
its still too chunky of a single process
<KitsuWhooa>
it makes managing my system not a nightmare, so *shrug* :p
<KitsuWhooa>
That, and all of it runs in pid 1
<KitsuWhooa>
*not all of it
glowcoil_ has joined ##yamahasynths
glowcoil has quit [Ping timeout: 246 seconds]
Sarayan has quit [Ping timeout: 246 seconds]
glowcoil_ is now known as glowcoil
<whitequark>
i honestly don't even care about security of systemd, can it please stop getting in my way?
Sarayan has joined ##yamahasynths
<cr1901_modern>
Lord_Nightmare: You may want to take a look at the s6 init system if you're test driving init systems... looks promising.
<cr1901_modern>
(it's not even Linux only in principle, though I don't imagine you'll see anyone on BSD using it soon)
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
mrspicy224489 has joined ##yamahasynths
<mrspicy224489>
So I'm suspicious that GEW10 and GEW12 are the same
<mrspicy224489>
*or very similar*
<mrspicy224489>
kode54 And is GEW9 the same as GEW8, but with a digital filter?
mrspicy224489 has quit [Remote host closed the connection]
<kode54>
I don't even know what GEW is
<kode54>
oh, whoever it was left
<superctr>
Generator of Waves
<kode54>
oh
<kode54>
I must have been a mistrigger then
<cr1901_modern>
GEnerator of Waves
SceneCAT has quit [Ping timeout: 256 seconds]
<kode54>
no, I mean telling me about it
<kode54>
I wouldn't know anything about a GEnerator of Waves
<cr1901_modern>
kode54: Well it's a digital circuit that generates sine waves. I hope this provides clarification :).
* cr1901_modern
has no idea if that's what GEW stands for