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
brendantcc has joined ##yamahasynths
<andlabs>
today on stupid ebay buyers
<andlabs>
for context, if an item is listed as both bid and buy it now and has no reserve, if someone bids, the buy it now option disappears
<andlabs>
today's idiot has chosen to go through a long, drawn-out auction that may end up with this thing selling for nearly a hundred bucks or more if they're lucky instead of getting this for a price so low that it will literally *never happen again*
<andlabs>
"get it for a steal? nah I'm cool"
<andlabs>
fwiw I only saw this because I had the auction page open to use its visited link color as a placeholder in the list of new vintage computing auctions and just happened to notice the transition to bid-only
<cr1901_modern>
Sarayan: Any indication from your WD controller REing that it can't distinguish a sync pattern in the data section?
<whitequark>
which of?
<cr1901_modern>
whitequark: C2 sync
<Sarayan>
cr1901: yes and no
<Sarayan>
specifically, it doesn't care about sync patterns when it has started reading sector data. It syncs to sync patterns anywhere when reading a raw track
<Sarayan>
there's a protection where they manage to have several hundred zero bits in a row (I think by having the flux modulated fast enough that the agc stays stable and the filter drops the fluxes out)
<Sarayan>
they check on the atari st that *both* data and clock bits are 0 by having to back-to-back sector header/sector data off by one bit where the sector size is big enough so that both cover the zero zone
<Sarayan>
which proves the second sector header/data header does not force a resync of the sector data read when youre trying to read the first
<cr1901_modern>
I think I need a diagram/picture to understand what you're talking about here :P. But I will file this away for a bit later
<Sarayan>
well, sector header = 00x6 4489x3 (sync) fe tr hd se sz crcx2
<Sarayan>
there's usually 4ex22 between the header and data
<cr1901_modern>
(Shouldn't the sector header be "A1" sync?)
<Sarayan>
they have sector header 1 4ex22 00x6 4489x3 fb 2us slip sector header 2 4ex22 sector data with data all zero
<Sarayan>
when you read sector 1 you end up reading the clock bits of the data of sector 2 after a while
<Sarayan>
4489 without the clock bits = a1
<cr1901_modern>
Then the sector data sync should be c2, no?
<Sarayan>
nope
<Sarayan>
c2 is IAM, the upd thing the wd does not use
<Sarayan>
at the start of the track, with I don't remeber which value behind and nothng else
<Sarayan>
well, the wd detects 5224 (aka c2) when reading a track, but is not otherwise using it
<cr1901_modern>
ahhh
<andlabs>
I'm starting to get tired of hearing that we *still* can't just dump CDs already
<Sarayan>
in any case, once the wd is in mode "I'm reading the sector data", it won't stop until it's done and won't care about the patterns coming or even if there's any kind of clock bit
<cr1901_modern>
That answers my question
<andlabs>
I've got soem CD base dprototypes I need to dump (and one GD based one too :eyes: ) but
<andlabs>
the section on GD dumping in this links to a forum post that contradicts it which is also helpful
<Sarayan>
andlabs: two difficulties, getting to the low-level data (which is actually simpler nowadays given domesday, but still) *and* getting the drive to actually read the disk from start to end
<Sarayan>
looking at old cdrom drive support chips, it's actually hard not to have it run the descrambling, error correction and stuff
<andlabs>
yes but why not just build our own drives
<Sarayan>
You know people competent for doing that?
<andlabs>
not necessarily but I can't imagine archival would require anything more complicated tha the average maker project, no?
<andlabs>
we don't need to build something functionally useful as a general pupose CD drive
<Sarayan>
well, there's multiple motors, dynamic track tracking, and the entire laser/lans assembly
<Sarayan>
lens
<Sarayan>
the average maker project usually doesn't have precision movement afaict
<andlabs>
maybe I'm misjudging how much hardware effort is needed specifically to read data
<andlabs>
I'm thinking that *for archival* we don't have to follow any particular speed requirements and would probably ideally go really slow or variable speed
<andlabs>
IDK
<andlabs>
it's not like analog data where I'm looking for a tape drive with absolutely zero wow and flutter
<Sarayan>
it's more analog than you think
<cr1901_modern>
Some early cheap CD drives had completely analog control systems- only the EFM decoding was digital
<andlabs>
so there is a possibility of accidentally turning a 1 transition into a 0 transistion then?
<andlabs>
cool
<andlabs>
but yeah I'm looking for the most perfect possible tape deck too, and ideally one that also doesn't require me to replace belts ... ever
<andlabs>
because I'm not going to be using them for long stretches of time
<andlabs>
so 0 wow and flutter and no belts, meaning ideally quartz lock direct drive, unless that has nonzero W&F???
<andlabs>
perfect is the enemy of good and I am rambo
<Sarayan>
I suspect it would be possible to do something with a random drive, a domesday for efm capture and a glasgow to control the servos
<Sarayan>
would be very rube goldberg though
<andlabs>
oh yeah my ideal CD capture would also record wobble
emeb has joined ##yamahasynths
<andlabs>
because that's data that's not in the data stream
<cr1901_modern>
Sarayan: What do you mean by "back-to-back sector header/sector data off by one bit"? In your example., the zero zone starts after the 2us slip _and_ after 4ex22
<andlabs>
and also ADIP and ATIP and other physical metadata that isn't part of the datastream
<cr1901_modern>
(Unless I misunderstand)
<Sarayan>
the 2us slip is the "off by one bit"
<Sarayan>
that means the first sector reads the clock bits of the sector sector header and data
<andlabs>
also I still don't understand how laserdisc quantization works or whether that means it's possible to have a bit depth that would capture all the analog data from laserdisc
<andlabs>
and I still haven't finished setting up a floppy dumping setup yet
<andlabs>
not sure when I'll ever actually get to archiving shit at this rate
<Sarayan>
laserdisc quantization has something to do with niquist and signal reconstruction, but I haven't yet been able to do the math
<cr1901_modern>
Sarayan: So after that 2us slip, is the floppy drive analog circuitry literally seeing "no flux transitions at all", as opposed to "a bunch of zeros encoded in MFM"?
<cr1901_modern>
Like, I don't see what the point of the 2us slip accomplishes in combination with "screw up the flux transitions on the floppy surface to fool the read/write head conditioning into thinking there are no transitions at all"
<cr1901_modern>
Either one seems like it could be used on it's own to do clever things
<cr1901_modern>
Why is combining them special?
<Sarayan>
2us is the size of a window
<Sarayan>
so it's reading a 0 clock bit, then continues reading the next data bit which happens to be the clock bit of the next byte
<Sarayan>
in other words, it's happily reading data/clock bits as ever, but it's opposite to what the second sector syncs as
<cr1901_modern>
So it's reading the clock bits as data, and the data bits as clock bits
<Sarayan>
yep
<cr1901_modern>
But all that gets you is that you can detect that the 8 clock bits are 0 (from the controller's POV)
<Sarayan>
since it really doesn't care about clock bits, it's not causing any problems (outside of a crc error at the end, but that doesn't matter)
<Sarayan>
you can detect by reading sector 1 that all the clocks bits in the special zone are 0, and using the sector 2 that all the data bits are *also* zero
<Sarayan>
hence, that you have a 100+ window zone with zero apparent flux change
<cr1901_modern>
Don't you have to also check for a sector number match (to find sector 2 to read it's data properly)? How does that not contradict the "all zero" region?
<Sarayan>
the all zero is only in the sector data 2 region
<Sarayan>
reading the sector 1 sees the non-zero clock bits up to there
<cr1901_modern>
>where the sector size is big enough so that _both_ cover the zero zone
<Sarayan>
just have to be big enough to reach over to the data region. 1024 bytes is plenty
<cr1901_modern>
Referring to this, emphasis on _both_
<Sarayan>
yeah, they have to both reach it, which is trivial for the second and requires a big enough sector size for the first
<cr1901_modern>
ohhh.. okay. Well sector header 1 + 22 4e's + sector 1 data start slip + sector header 2 + 22 4e's + sector 2 data start(from sector 1's POV) is close to 100 bytes?
<cr1901_modern>
Anyways I get it now
<cr1901_modern>
Also to be clear, "data slip" means "a properly-encoded dummy bit that shouldn't be there", correct?
<Sarayan>
well, it's half-a-bit
<Sarayan>
otherwise you wouldn't switch sync
<cr1901_modern>
yea, sorry. What I meant is "no analog shenanigans happening in that 2us bit cell"