9 Apr
2007
9 Apr
'07
4:15 p.m.
Jules Richardson wrote:
Hmm, that's interesting. Does it store fixed
length counts in the
buffer, or does it use variable-length counts with a couple of bits of
"header" to say how many bits the count takes up?
Here's the document that explains how the CW is programmed:
<http://www.schoenfeld.de/inside/Inside_CWMK3.txt>
AIUI, it goes something like this (with Counter=0 to start):
- Wait for transition
- Store contents of Counter in memory, MemAddr++, Counter=0
- Repeat until all the data has been read
Counter is incremented at the master clock rate -- 14, 28 or 56MHz (well,
actually 56.644MHz). Basically, what the Catweasel tells you is how much time
there was between the last flux transition and the current transition. From
that, you can regenerate the waveform, or do some (relatively) simple data
processing to get the original data back.
Either way, it got me wondering if there's some
really oddball stuff
that the CW can't read because the count between pulses is just too
long. It's too early here to reason it out :-)
The easy answer is to slow the clock down so the counter doesn't overflow :)
I was thinking the same thing with this concept of
over-sampling the
entire track into a buffer; it's going to be a heck of a lot easier to
decode the data while looking at a graphical utility.
I'm sketching out the UI for my drive reader at the moment. It'll probably have:
- A 'logic' display that shows the index pulse and data.
- A histogram display that shows where the timing values lie (may be useful
for giving encoding types a 'signature' and identifying them based on that)
- Standard read/write panel, track navigation, etc.
Maybe I'm getting a bit ahead of myself, seeing as the hardware isn't even
half done yet...
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.