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 quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cr1901_modern1 has joined ##yamahasynths
cr1901_modern has quit [Ping timeout: 250 seconds]
<Xyz_39808>
I saw PLL and thought people were talking about speedcubing :?
<whitequark>
Lord_Nightmare: fwiw my current PLL is much better
<Lord_Nightmare>
if you are doing non-realtime PLL stuff (for data recovery from a flux dump of a floppy) you can do totally crazy stuff like windowed autocorrelation
<Lord_Nightmare>
in order to find the best fit for the pll tracking
<whitequark>
it is going to go onto the FPGA eventually
<whitequark>
my primary goal is to learn about CRs
<whitequark>
*CDRs
<Wohali>
i had to look up what speedcubing was
<Lord_Nightmare>
pitch detection from a voice signal and pll clock recovery for data separation on a floppy flux signal have a surprisingly large amount of overlap
<Lord_Nightmare>
both are attempts to recover a fundamental frequency from a noisy waveform
<Lord_Nightmare>
and many techniques which work on one also work on the other, like autocorrelation, and threshholding with holdoff
andlabs has joined ##yamahasynths
<whitequark>
hmm
ej5 has quit [Quit: Leaving]
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
<TD-Linux>
whitequark, do you know how well your pll currently works compared to e.g. an off the shelf disk controller?
<TD-Linux>
is that floppy readable in e.g. a usb disk drive?
<whitequark>
TD-Linux: pretty sure. let me try it
<whitequark>
yeah reads just fine
<TD-Linux>
do you have a fixed gain? e.g. by changing the number of fractional bits you're changing the gain?
<whitequark>
I am not sure what gain is in context of a PLL
<whitequark>
do you mean like using phase error as feedback to determine the amount of phase and frequency shift?
<TD-Linux>
yeah exactly
<TD-Linux>
basically how fast you're adjusting it
<whitequark>
oh
<whitequark>
after each data edge i'm adjusting it for 1 LSB
<whitequark>
bang-bang style
<TD-Linux>
ah okay. yeah I think very next step would just be to make your counter high resolution, and make it the adjustment configurable so you can adjust in increments smaller than 2x
<whitequark>
define high resolution
<TD-Linux>
a few more fractional bits than what gave you good results with just 1 LSB adjustment?
<whitequark>
oh sorry
<whitequark>
i mean i adjust by 1 smallest fractional bit
<whitequark>
otherwise they'd just all go unused
<TD-Linux>
well I mean then instead of adjusting by 1 you can adjust by e.g. 0.7
<whitequark>
oh i see
Xyz_39808 has quit [Quit: Leaving]
Xyz_39808 has joined ##yamahasynths
cr1901_modern has joined ##yamahasynths
cr1901_modern1 has quit [Ping timeout: 245 seconds]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
whitequark: Excellent! I want to see how it compares to my old version when I'm feeling up for it.
<whitequark>
i'm currently improving it even further
l_oliveira has joined ##yamahasynths
<cr1901_modern>
No loop filter?
<whitequark>
nope
<cr1901_modern>
Guess then I should've said "fuck it" and tried w/o a loop filter rather than get frustrated that the math didn't add up
<cr1901_modern>
back then*
<whitequark>
cr1901_modern: i have some very exciting improvement in the testing rn.
<whitequark>
yeppp
<whitequark>
cr1901_modern: so, i added proportional gain, but this time correctly
<whitequark>
now it can acquire lock from 0 if i do it on all 160 tracks and read the entire floppy correctly
<whitequark>
even better, if i actually tell it what i expect the period to be, then it only EVER loses lock twice on all 2880 sectors
<whitequark>
(the flux level reads have some redundancy so it's not a problem if the PLL isn't quite perfect)
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Lord_Nightmare>
whitequark: did you add a phase to the pll that syncs to the sync marks of an mfm or fm disk?
<Lord_Nightmare>
I assume that's how most floppy controllers actually do things
<Lord_Nightmare>
whitequark: i think some of the trickiest floppies to decode will be the amiga and especially apple2 ones where there were some rather insane protections involving skipping bits and non-standard raw flux on the disk
<whitequark>
Lord_Nightmare: nope. it is completely oblivious to the format of data.
<cr1901_modern>
to be fair, so is the IBM PC FDC PLL
<whitequark>
i thought about adding feedback from MFM demodulator, but it's cleaner this way and works really well in any case
<Lord_Nightmare>
i'd love to try this against some of the images i made of wabash disks as the last read before the disk media peeled off; i was never able to decode that properly
<Lord_Nightmare>
its in diskferret dfi1 format, which has a timing 'ghosting' problem which philpem later fixed, but it means that if a flux counter counted to EXACTLY 128 it would lose 128 clocks, and while this didn't happen often it makes some stuff very difficult to decode reliably
<Lord_Nightmare>
dfi2 format fixed this bug, it was an error in the fpga state machine
<Lord_Nightmare>
iirc if the counter was between 1 and 126 it would put 01 thru 7e in the stream, but if the count was exactly 127 it was supposed to put 7f 00 but instead just put 00 or 01, i forget
<Lord_Nightmare>
the 0x80 bit is used for index
<Lord_Nightmare>
or was, in dfi1
<Lord_Nightmare>
in dfi2 index is encoded a bit differently
<whitequark>
Lord_Nightmare: what's wabash?
<whitequark>
and is there a doc for dfi1?
<cr1901_modern>
whitequark: You have some _really_ fucking weird floppies
<whitequark>
cr1901_modern: roommate brought me these.
<Lord_Nightmare>
wabash was a manufacturer of extremely poor quality but inexpensive floppies in the late 70s and early 80s
<Lord_Nightmare>
the chemical mixture they used to attach the oxide to the disks is somehow unstable, and eventually the oxide sheds off
<cr1901_modern>
Definitely misread that as the side you typically get w/ sushi
<cr1901_modern>
Must be a fruedian slip...
<Lord_Nightmare>
wabash went out of business around 1984 I think, I'm GUESSING because nobody bought their stuff after a while because of how poor quality it was
<Lord_Nightmare>
sadly some software and games were distributed on wabash media
<whitequark>
ohhh
<cr1901_modern>
https://twitter.com/whitequark/status/1125448398402985985 <-- The first SNES emulator came out in 1994. It came w/ two homebrew demos, which were a single screen w/ text on them. One of them was an advertisement for the local KKK branch. I wish this were a joke.
<whitequark>
incredible
<fseidel>
wait, what the actual fuck
<fseidel>
what emulator was this?
<cr1901_modern>
fseidel: I'll see if I can find the video where I got this info
<cr1901_modern>
fseidel: VSMC
<whitequark>
Lord_Nightmare: so, is there any doc on dfi1?
<cr1901_modern>
fseidel: It couldn't play any official games, and the non-racist demo doesn't even work on real hardware.
<cr1901_modern>
The SNES fade register isn't implemented properly
<Lord_Nightmare>
whitequark: sadly i'm not sure. i know dfi1/2 are documented on philpem's mercurial repos on his site
<fseidel>
that's pretty bizarre
<Lord_Nightmare>
but the dfi1 docs might only be literally the source code if you go back to before the dfi2 stuff was committed
<cr1901_modern>
whitequark: philpem is in the sipr0n IRC channel or discferret if you wish to ask
<whitequark>
Lord_Nightmare: amazing
<whitequark>
this is almost identical to what i've implemented
<cr1901_modern>
err, appears to be offline
<whitequark>
in fact i might just adjust my code to be completely compatible
<Lord_Nightmare>
whitequark: what is?
<Lord_Nightmare>
the dfi format?
<whitequark>
dfi format
<Lord_Nightmare>
ah
<cr1901_modern>
fseidel: You can find homebrew for the SNES as early as Christmas 1991 (Anthrox). But it's clear from a bit of digging that they were a licensed third party from Nintendo and thus had a legal copy of the manual.
<Lord_Nightmare>
be warned: there is one case where dfiv2 might STILL fail, and that is if the flux counter overflows from writing a "7e" byte to a "7f 00" byte pair at EXACTLY the same time as an index sensor high-to-low or low-to-high transition happens AND a second flux transition happens 1 cycle later
<cr1901_modern>
More interested in homebrew efforts from ppl of that time frame who _didn't_ have the manual
<Lord_Nightmare>
since the device has to write something crazy like '7f 00 80 01' all within 2 cycles
<Lord_Nightmare>
in fact i forget how the index-active and index-inactive 80/81/etc commands work in dfi
<whitequark>
Lord_Nightmare: ugh
<fseidel>
wait, Anthrox were licensed?!
<whitequark>
that's why i record index position by starting at index
<whitequark>
might not use that then
<Lord_Nightmare>
whitequark: to be honest i don't remember if that's how philpem ended up doing index stuff
<Lord_Nightmare>
i think in dfiv1 index was just stored raw as the high bit
<cr1901_modern>
fseidel: The people who made up Anthrox were licensed devs. AIUI, Anthrox as a group wasn't licensed.
<cr1901_modern>
One of the members (Pan) used to have a blog about it
<Lord_Nightmare>
and 7f before any byte means 'add 127 to the next byte', so you can have long chains of 7f 7f 7f 03 which means 127*3+3
<Lord_Nightmare>
but what happens if the index goes inactive sometime during those counter delays?
<Lord_Nightmare>
that's where the whole 8x mess came from
<cr1901_modern>
I'm assuming Anthrox was just something they did in their spare time for fun, outside of their obligations as third party devs
<Lord_Nightmare>
since you can have index change independently of a flux transition
<Lord_Nightmare>
and this is very important to keep track of index for one reason: hard sectored floppy disks
<Lord_Nightmare>
these have, instead of one hole for the index, they have 17 holes
<Lord_Nightmare>
16 of the holes indicate the start of a given sector, and the final hole is in between the 16th and 1st sectors (or is it the 1st and 2nd sectors?) and indicates that the next (or previous?) sector hole was the index
<whitequark>
Lord_Nightmare: ohhhhh
<whitequark>
that makes sense
<whitequark>
Lord_Nightmare: i'd just use the top bit for the index
<Lord_Nightmare>
that works until you run into a case like this:
<Lord_Nightmare>
flux is N or S, transition happens on a flip between N and S
<Lord_Nightmare>
and lets say the index is I vs .
<Lord_Nightmare>
hold on i need to make an ascii diagram of this
<whitequark>
Lord_Nightmare: is it trying to correlate index position to below one transition length?
<Lord_Nightmare>
...........IIIIIIIIIII
<Lord_Nightmare>
SNNNNSSSSSSSSSSSSNNNNS
<Lord_Nightmare>
x 4 A 4
<Lord_Nightmare>
so you'd store 4 as 04 and A as 0x8A then 0x84
<Lord_Nightmare>
the problem is the index actually went active a little bit before the A transition
<Lord_Nightmare>
I forget how philpem dealt with this, there may have been a special mark he did on a rising and falling edge of index
<whitequark>
i thought the index location is too approximate to be correlated to anything useful anyway
<Lord_Nightmare>
so what he did MIGHT have been (I don't have his code in front of me), instead storing that stream as 04 8a 84 you'd store it as 04 86 86 84, and i guess the first byte that theres a transition low to high or high to low in bit 7 you do not reset the accumulator
<Lord_Nightmare>
er
<Lord_Nightmare>
no
<Lord_Nightmare>
so what he did MIGHT have been (I don't have his code in front of me), instead storing that stream as 04 8a 84 you'd store it as 04 86 86 84, and i guess the first byte that theres a transition low to high or high to low in bit 7 you do not count it as a flux transition
<cr1901_modern>
Lord_Nightmare: Any chance you could get him to log onto IRC?
<Lord_Nightmare>
you DO reset the accumulator
<Lord_Nightmare>
i'm not sure he actually did this though
<Lord_Nightmare>
and to be honest, the index sensor is usually so inaccurate (at least on floppy disks) that it doesn't matter if you quantize it to the next flux transition or not
<Lord_Nightmare>
as you pointed out
philpem has joined ##yamahasynths
<cr1901_modern>
that works :P
<cr1901_modern>
philpem: Welcome to yamahasynths, an IRC channel for discussing floppy disk formats :P
<philpem>
Odd name for a floppy disk discussion group ;)
<philpem>
Regardless - hello! :)
<cr1901_modern>
I'm not a stickler for on-topic
<Sarayan>
hey, my yamaha synth at home has a floppy drive
<Sarayan>
I should probably dump the floppy, but amusingly I have no idea how at that point
<Lord_Nightmare>
(offtopic) the format used by the dx7IIfd iirc depends on the /READY line like an amiga floppy drive does, so replacing the drive is a pain in the ass, iirc (/offtopic)
<cr1901_modern>
philpem: I skimmed the previous convo here, but the gist is: wq created a tool to dump floppy disk images via FPGA, a la diskferret, but using her own hardware. And the dump format ended up being nearly compatible w/ diskferret's
<cr1901_modern>
so might as well make it fully compatible, but there were some snags
<philpem>
re LN: "I forget how philpem dealt with this, there may have been a special mark he did on a rising and falling edge of index"
<philpem>
the Discferret stores on a bunch of events -- timer expiry causes a store, index causes a store, and obviously a flux transition does too
<philpem>
so if you see no flags - the timer rolled over. INDX flag with no FLUX is Index triggered, FLUX is flux triggered, both is they both happened together
<philpem>
the index varies from drive to drive (+/- tolerance basically), it's usually based on the hub position on 3.5in drives or an optical sensor on 5.25 and 8in
<cr1901_modern>
right, and AIUI on 3.5n drives, INDEX has no correlation w/ start of track
<philpem>
on Amiga? no. On PC? yes.
<cr1901_modern>
on 5.25 and 8" drives the controllers actually use index
<cr1901_modern>
on PC
<philpem>
the Intel PC controllers wait for index then write. Amiga just reads the whole damn track.
<cr1901_modern>
Amiga is "PC track format, except you rewrite the whole damn track each time" IIRC
<Sarayan>
amiga is not at all pc track format
<philpem>
not quite. AmigaDOS format is higher density. I can't remember the specifics.
<philpem>
same syncword but that's where the similarity stops
<Sarayan>
yep
<philpem>
with no index, PC controllers may-or-may-not work, or may error out because they think the drive is jammed
<Lord_Nightmare>
those wacky kodak 3.3MB 5.25 disks have NO index sensor
<Lord_Nightmare>
its sort of disturbing
<Sarayan>
cr: index *is* start of track by definition, not sure what you mean by non-correlation on 3.5
<philpem>
quantising +/- one flux won't really matter in practice, that's well within the fudge factor (mechanical tolerance if you prefer) and GAP time. I wanted absolute accuracy so that's why I did what I did
<Sarayan>
apple2 doesn't use the index at all
<cr1901_modern>
Sarayan: A 3.5" PC controller doesn't wait for index to start formatting sector 0, 1, 2,... etc
<philpem>
@Sarayan: if you're following the Shugart guidelines, yes. but Amiga, Apple2, etc don't use the index sensor. CBM 1541 may be the same (they costdowned those a lot, they have no trackzero sensor).
<Lord_Nightmare>
yes, but properly duplicating apple2 disks with track sync requires an index sensor, which is why the applesauce device comes with a magnetic sensor to hack into the drive with some foam tape
<Sarayan>
amiga uses the index sensor
<Sarayan>
apple2 doesn't
<philpem>
I never had an amiga to check so...
<Sarayan>
upd765 and derivatives start formatting at the index pulse, so, errr....
<whitequark>
Sarayan: i am looking at a bunch of floppies and right after the index there is sector 6.
<Lord_Nightmare>
apple2 disk][ early schematics had provisions for an index sensor (it was the 9th bit/shift in of the 8 bit shifter latch) but it was never implemented in the state machien proms or any shipping hardware
<Lord_Nightmare>
tbh i think woz would have had to use a larger state machine prom to handle index
<Sarayan>
wq: is there a bigger gap before/after the index than between other sectors, no matter the sector number?
<whitequark>
Sarayan: not that i can see
<cr1901_modern>
whitequark: So just as a recap, you were dumping the disks into your own custom diskferret-like format, before turning them into an image suitable for mounting as a loop device?
<Lord_Nightmare>
apple2 disks were often written in a drive which had an index sensor, i have some .pngs from applesauce dumps of commercial disks showing this. let me dig one out
<whitequark>
Sarayan: the bigger gap is after the 18th sector.
<Sarayan>
wq: weird
<whitequark>
cr1901_modern: correct
<whitequark>
i am thinking about making that format more flexible and useful for forensics such that it can store all intermediate products
* Lord_Nightmare
times himself out for 5 minutes to reduce channel noise
<whitequark>
ie: modulated output, PLL'd output, demodulated output, raw sectors
<cr1901_modern>
I like the idea of multiple impls of diskferret... well, anything except kyroflux :P
<whitequark>
i could probably make the flux level format aligned with diskferret
<Sarayan>
wq: I need to find a couple of patents for you
<Sarayan>
the amiga and the western digital plls
* philpem
wanders off for five minutes while the SNR improves
<Lord_Nightmare>
too many people talking in channel at once
<cr1901_modern>
whitequark: The IRC channel SNR. Anyways I have to take care of something myself, so I will be on standby if anyone needs me
<Lord_Nightmare>
I'm gonna shut up for now since I don't think I can contribute more to this discussion directly
<Lord_Nightmare>
One last thing: I just realized that that image I gave is completely meaningless, since the applesauce index sensor on the apple2 drive does NOT use the index hole at all, but a spindle magnet, so the rotation will be different depending on what position the disk was rotated to when the drive door was closed and the disk media was clamped. signing off for 10 mins.
<cr1901_modern>
Ahhh the same person who invented the Paula chip
<philpem>
anyways
<philpem>
@whitequark - what suggestions did you have for DFI?
<cr1901_modern>
Would this be considered as part of DFI "v3" or "v2.1"?
<whitequark>
philpem: i think i mostly am misunderstanding how exactly DFI encoding works
<whitequark>
you've said FLUX and INDEX but the wiki page only describes an index bit, i think...
<philpem>
A timer store without INDEX is implicitly a FLUX
<philpem>
I *think* an overflow is a special counter value
<philpem>
it's documented in the code and the Verilog
<whitequark>
I see
<whitequark>
ok, I think I understand this format now
<whitequark>
I see one major problem: the timebase is not stored in the format
<cr1901_modern>
Curious, why does this matter?
<TD-Linux>
cr1901_modern, the integrator plus proportinal gain *does* form a loop filter btw
<cr1901_modern>
there wasn't a loop filter when I asked that question
<whitequark>
there's no integrator, is there?
<cr1901_modern>
whitequark: Strictly speaking, the VCO is an integrator
* Lord_Nightmare
returns
<whitequark>
cr1901_modern: ahh
<cr1901_modern>
theres an 's' in the denominator of the transfer function of a VCO, and that by definition means its an integrator.
<cr1901_modern>
Idk if that's what TD-Linux meant tho
<Lord_Nightmare>
whitequark: the timebase not being stored in the format is a weakness of dfiv1/v2, i proposed a header field in dfiv3 which would have held the timebase (the discferret could clock at 100mhz, 50mhz, or 25mhz iirc?)
<Lord_Nightmare>
it never happened though, at least not yet
<whitequark>
Lord_Nightmare: what do you think about my idea of having one container format that stores data at multiple stages in pipeline
<Lord_Nightmare>
to work around this missing feature i would always name my disk images with the clock speed as part of the filename
<Lord_Nightmare>
whitequark: not a bad idea I don't think
<Lord_Nightmare>
There exists another floppy format called .fdi which allows tracks to be stored as raw flux, raw MFM bytes, or decoded sectors, or even files i think
<Lord_Nightmare>
per track
<Lord_Nightmare>
its a weird format, used by exactly one device
<TD-Linux>
yes that's what I meant, the integrator before the vco.
<Lord_Nightmare>
https://github.com/mamedev/mame/blob/master/src/lib/formats/dfi_dsk.cpp is sarayan and my code for doing dfi to mfi conversion, but i havent touched it in over 5 years and it may have some leftover crap in it related to combining multiple copies of sectors on an apple2 disk
<Lord_Nightmare>
one notable thing in there is dfiv1 disks have the magic number "DFER" dfiv2 disks have the magic number "DFE2"
<whitequark>
i see
<whitequark>
i might just make my own "gfi" and converters for mfi/dfi
<cr1901_modern>
gfdi
<whitequark>
lol
<Lord_Nightmare>
there's some gross code in there to guess the correct clock speed/rotation speed for dfe2 images, it doesn't even try to guess rotation speed right now
<Lord_Nightmare>
by timing the number of clocks betwene index pulses
<cr1901_modern>
TD-Linux: The literature I've read on PLLs, including Gardner's Phaselock techniques, don't count the VCO integrator as part of the loop filter, because steady state anaylsis becomes nicer if you don't
<cr1901_modern>
Remember "type 0, 1, 2, 3" control systems from Uni?
<Lord_Nightmare>
I remembered one thing: in order for a track to be complete, an image should at minimum be from the rising edge of the index (with detection of hard sectored disks so its the actual index hole and not a sector hole), one full rotation of the disk, and the entire index again and end on the falling index edge
<Lord_Nightmare>
storing several rotations of the disk (depending on how much memory your fpga has, the discferret had 512KB) is not a bad idea, in case one of the revolutions is a bad read you can try from one of the others
_whitelogger_ has joined ##yamahasynths
<Lord_Nightmare>
(semi-offtopic) i was talking to tony diaz about the mc3470 vs mc3470A on apple2, the latter works very unreliably even though its the same pinout and is rated for less noise, i'm wondering if apple2 stuff RELIES on the noise, beyond just copy protection stuff... (/off-topic)
Xyz_39808 has quit [Ping timeout: 248 seconds]
_whitelogger has quit [Ping timeout: 248 seconds]
<Lord_Nightmare>
i don't know of any decaps of the mc3470 or mc3470A, it would be sort of interesting to see exactly how it works
<Lord_Nightmare>
I believe its mostly analog, with two flipflops for the output section
<TD-Linux>
cr1901_modern, tbh no I don't remember such a classification of control systems :>
<cr1901_modern>
type 0 == "finite error in step response, unbounded error in ramp/parabola response", type 1 == "0 error in step response, finite error in ramp response, unbounded error in parabola response"
<whitequark>
Lord_Nightmare: (relies on noise) like sampling with it?
<cr1901_modern>
type 2 == "0 error in step, 0 error in ramp, finite error in parabola response". All PLLs, due to the (1/s) in the VCO, are at least type 1.
<cr1901_modern>
If you can deal w/ a small error in a ramp response, which corresponds to a linearly increasing phase (as in- a sinusoid!), you don't need a loop filter.
<cr1901_modern>
And it seems w/ wq's design, this works just fine
<cr1901_modern>
Notably, this is why proportional-only control systems aren't really a good idea. They are type 0, so the error will never actually become 0 :P
<whitequark>
i tried to do PI
<whitequark>
never got it to work at all
<cr1901_modern>
A PLL can't be proportional-only... if you put a gain on the input to the VCO, the whole PLL is still type 1.
<cr1901_modern>
Using a PI loop filter would make it type 2
<cr1901_modern>
(well, if you get it to work :P)
<whitequark>
yeah i mean the PI filter
<Lord_Nightmare>
whitequark: i'm trying to find 4am's writeup
<cr1901_modern>
whitequark: ahhh, join the club :P
<whitequark>
cr1901_modern: but i got it to work without the I part.
<cr1901_modern>
whitequark: I got a simulation of a PI filter PLL on FPGA to work compared to the theoretical analog output. However, >>
<cr1901_modern>
as I was not able to understand the math/the why behind it, I don't count that result :P
<whitequark>
so, i think a 'serious' flaw of my approach is that it can get destabilized if you get a lot of noise
<whitequark>
like milliseconds
<whitequark>
this is worked around by constraining the PLL to something close to the correct frequency
<cr1901_modern>
high loop bandwidth and noise is an inherent tradeoff. I wonder if this also applies to high locking range
<whitequark>
definitely
<whitequark>
but given that it affects less than 1% of sectors on a typical floppy that wasn't scratched to death...
<whitequark>
usually something like 0.2% at most
<whitequark>
i'm going to say my PLL is good enough
<whitequark>
also
<whitequark>
one problem there is with an approach that "stabilizes to zero" is
<Lord_Nightmare>
that protection relies on the mc3470 reading noise
<cr1901_modern>
RPM of a typical floppy will vary up to 10% from nominal
<cr1901_modern>
not including sudden changes due to disk jacket friction
<Sarayan>
not 10%, more like +/- 3%
<Sarayan>
sudden changes are pretty much impossible to distinguish from magnetic field migration anyway :-)
<whitequark>
Lord_Nightmare: yep, i know about that
<philpem>
Also not including random speed waver due to slipping belts (hello Amstrad...)
<TD-Linux>
8" floppies with a synchronous motor are clearly the best
cr1901_modern1 has joined ##yamahasynths
cr1901_modern has quit [Ping timeout: 246 seconds]
<Lord_Nightmare>
so the motor gets feedback to keep the speed consistent?
<TD-Linux>
on everything smaller than 8", yes
<TD-Linux>
old 5.25" drives have a dc motor, plus a single magnetic pickup that they use for feedback of speed
<TD-Linux>
new 5.25" drives and 3.5" drives have brushless motors where position and speed are already known from the needed feedback
cr1901_modern has joined ##yamahasynths
cr1901_modern1 has quit [Ping timeout: 250 seconds]
cr1901_modern has quit [Ping timeout: 248 seconds]
cr1901_modern has joined ##yamahasynths
<Lord_Nightmare>
Sarayan: there were some really badly warped trs-80 model 1 floppies i imaged (the wabash ones were in that batch) which were unreadably slow in the drive until i cut the disks out of their sleeves and transplanted them into other vinyl sleeves
<Lord_Nightmare>
those must have been way beyond 3%
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 252 seconds]
superctr_ has joined ##yamahasynths
superctr has quit [Read error: Connection reset by peer]
kode54 has quit [Quit: Ping timeout (120 seconds)]