Philip Pemberton wrote:
Jules Richardson wrote:
but do you anticipate 16MHz being enough, or are
there likely to be
some things that it won't handle? (I kept all prior threads on this
kind of thing, but they're a bit lost amongst the noise right now!)
I'd think it'd be fine up to about 500kbps. I'm using a 40MHz clock on
mine because it's a multiple of most standard data rates. 1Mbps, 500kbps
and 250kbps are all integer multiples of 40MHz. This helps reduce timing
jitter -- the FPGA can't count fractions-of-a-clock. It also makes the
math a bit easier when you start decoding the data!
Yeah, that all makes sense, I think. I just have vague memories about
discussions as to how much over-sampling of the signal was beneficial so as to
perhaps recover marginal data that would be garbage on the 'native' hardware.
I like the
fact it's RS232. Like you say, it'd be easy to add a
converter to give USB functionality, but a bit more difficult to go
the other way.
The problem, of course, is the limited speed of RS-232...
Yep. I think I once raised the possibility of making the I/O to the "outside
world" a separate card to the rest of the system, so that different methods of
transfer could be used.
Of course at that point it's a shame not to split the floppy access logic from
the CPU, and to add a backplane and console board and stuff the whole lot in a
nice wooden case ;-)
Well, I assume
tools can be made to translate between formats, in
which case it should matter little how many of these projects there
are out there...
The issue is that already there are different sampling modes, and
different uses for the 'special 00' byte. For my hardware, it means "add
128 to the next sample byte"; for Chuck's it means "an index pulse
occurred here". IIRC on a Catweasel it means "a really short pulse was
detected".
However, if we could all agree on a standard interchange format for
raw-disc images, then this point would be more-or-less moot.
Why's that even needed (nice though it'd be)? Is there some reason that a
software util *can't* be written to translate between data dump formats?
The order of the blocks in the file determines the
interleave. Ideally
this would also be described in the track header...
Yes, lots of semantic type data seems good - so long as it doesn't lead to
ambiguity and potential conflict within the data...
cheers
Jules