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
superctr has quit [Read error: Connection reset by peer]
superctr has joined ##yamahasynths
<cr1901_modern>
(Also is Twitter down or is it just me?)
<cr1901_modern>
ej5: Guess I'll ask here, since I can't ask on hellsite- did your data capture have any pulse widths of 533ns? That would be 7 zeros, 8 cells
<ej5>
no
<cr1901_modern>
I guess the data just didn't have the byte "0x33" then (or 0xcc, since I don't remember the bit order)
<andlabs>
it's back now
<andlabs>
"upstream connect error or disconnect/reset before headers. reset reason: connection failure"
<ej5>
since a '1' in that code represents a transition, and i'm only measuring the distance between transitions
<cr1901_modern>
if there are 7 0's in between two ones, you have traversed 8 cells between consecutive ones
<cr1901_modern>
101 => two bit cells between the ones
<cr1901_modern>
1001 => three bit cells between the ones*
<cr1901_modern>
At least, that's how I understand it your histogram
<cr1901_modern>
(Sorry, should've made clear- I'm looking at the histogram, and only see 200, 266, up to 466ns
<andlabs>
when I read between I think between
<andlabs>
so 101 would only have one 0
<andlabs>
*I think literally between
<ej5>
ahh yes you're right cr1901_modern
<cr1901_modern>
ej5: Would you like to help me set up some fenceposts later? :)
<ej5>
haha
<cr1901_modern>
andlabs: It helps with graphs/pictures, but my interpretation was: The transition (1) is detected in the middle of bit cell "0". Bit cell "1" starts 33ns after the transition is detected. All bit cells last 66ns. >>
<cr1901_modern>
So two bit cells w/ no transition later, bit cell "3" begins. A transition is detected 33ns later.
<cr1901_modern>
33 + 66 + 66 + 33 = 200
<cr1901_modern>
1001
<ej5>
yeah i just went back over the data and found 8 cell widths too
<ej5>
looks like i'm getting closer to decoding this thing!
<cr1901_modern>
Excellent work :D.
<cr1901_modern>
I was wrong about it being MFM, but I stand by my guess. I wouldn't have expected an MFM driver to be formatted w/ RLL. But it's def not unheard of.
<cr1901_modern>
(I've done it by accident before. The drive didn't work well.)
<andlabs>
oh
<andlabs>
ok
<andlabs>
I guess
<andlabs>
I don't know what any of this is I'm jumping in the middle
<andlabs>
=P
<cr1901_modern>
ej5: Any chance you could code an ASCII view for your decoder and try it on all 8 possible offsets * (msbit first, lsbit first)
<ej5>
i think the next step is to figure out the rough sector format. preamble, sync word, etc
<cr1901_modern>
I don't know any RLL coding violations offhand (but they must exist)
<ej5>
yeah the coding violation is typically done for the sync word
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<cr1901_modern>
ej5: I don't have it on me, I but vividly recall that one of the ST-506 manuals on bitsavers has a "suggested low level track format". Maybe it might be useful if you get stuck?
<ej5>
iirc that's MFM not RLL
<cr1901_modern>
Well, I've made many bad predictions tonight, so why not one more before bed :)? >>
<cr1901_modern>
I bet when you RE this, the track format is going to be similar to one you'd see on a floppy (or the ST-506 manual) minus the coding violations
<cr1901_modern>
which yes would be different
<cr1901_modern>
Also... that patent you linked is... something :D
* cr1901_modern
heads to bed for now... good luck!
andlabs has quit [Ping timeout: 258 seconds]
andlabs has joined ##yamahasynths
<ZrX-NoMs>
I recall RLL being fairly easy to decode, but didn't look into error correction.
<ZrX-NoMs>
Hmm, looking at my decoder, no. Not easy at all.
<ZrX-NoMs>
Even the CRC used might differ between controllers.