15 Mar
2005
15 Mar
'05
4:49 a.m.
On Mon, 2005-03-14 at 23:31 +0000, Philip Pemberton wrote:
Heh.
Actually, soldering SMT stuff isn't too bad given the right iron and
tip. So I'm game for anything there.
Is that bidirectional? Just a random thought, but the parallel port
interface is going to be an 8 bit bus and a handful of control wires
presumably (R/W, 'start', 'clock' etc.) (clock for clocking data
between buffer and parallel; board should have its own onboard clock for
data between buffer and floppy)
Anyway, my random thought was that an 8 bit bus and a few control lines
is probably right for interfacing to a USB chip too. So design a
parallel port version with space for a header on the board; if people
want a USB version they just plug a second board into the first that
taps into the parallel bus and control lines.
Likely no more expensive than designing a USB version from the ground
up, but you get a parallel port version for free (and at leass cost than
a USB version because you don't need the plug-in board)
Pretty much. See my other email to the list :)
See above :)
As Dwight says it's a bit harder for hard-sectored disks. I'd be tempted
to say that v1 is soft-sectored only though as it'd be quicker to get
something working as proof of concept; but v2 could follow on quickly
with some extra logic to handle hard sectored media.
But it can be done. And archival rather than decoding's the primary goal
anyway, so people can mess around with that once the basic hardware's
going. I'll definitely try hacking some code together to do decoding
when it gets to that stage; it'd be an interesting challenge.
In message <1110833470.10973.51.camel at
weka.localdomain>
Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
You know way more about this side of it than me. ?10 - ?20 seems like a
lot of money though, but as others said maybe us brits are being ripped
off and buying overseas is a lot cheaper.
I forsee four goals to make it useful:
o Cheap
CPLDs tend to cost between ?10 and ?20 each in 1-off, but you can stuff
nearly all of the logic into just one of them. You could even make the board
in-circuit reprogrammable if you wanted, but I'd be tempted to use an SRAM
FPGA instead of a CPLD if I did that, simply because most FPGAs have open
programming specs (it's something of a requirement - if you have to reload
the fusemap every time you powercycle the chip, you're not going to want to
drag the manufacturer's programmer around with you). o Simple to
build by anyone with a few electronics skills.
Can you solder a 0.1" pitch PLCC socket? :) o Easy /
quick connectivity
Parallel port then. I'd add "Portable across multiple platforms" which
basically means "parport or nothing". Every desktop and laptop machine
I've
seen has had an IEEE-1284-compliant (or compliant to a reasonable degree)
parallel port. at it yet, but
doubtless a bunch of us on this list could come up with
something that'd cater for all tastes (plus the really low-level
software would all be open source anyway!)
"Here's the CPLD sources, the schematic, and the interface spec. Go forth and
Have Fun." Personally
I'm not a fan of a USB version though; I'd rather have
parallel as pretty much any machine has a parallel port - USB limits me
to newer PCs and Macs (plus software interfacing *might* be harder).
Me neither - software interfacing for USB is a total pig, not to mention the
fact that you'll need some form of USB controller in the hardware. Priorities
seem to me to be (highest first):
o Reading disks
Easy - start when you get an index pulse, then stop when you get another
pulse. I'd be tempted to make the stop pulse lag a bit though, just to make
sure there's enough overlap to be reasonably sure that you've got all of the
data. o Decoding
disk data on host machine
Synchronisation would be the hardest part of that. If you know where the bit
boundaries are, you can just scan through the data and replace the
flux-reversal sequences with binary bits.
If you wanted to read an Amiga floppy, you'd have to use some form of
circular buffer, find the sync marker, then move the data around in the
buffer before decoding it. You could decode the images into whatever format you
wanted. It's just a
question of software.
Long way off (need working hardware first!) but if the catweasel
*drivers* are open source, it might make sense to have a software layer
that mimics the catweasel API and allows us to use catweasel drivers
reading / writing there; our software layer handles stuff like sync sep
(which I gather on the catweasel is done in the hardware)
I've got some digital design knowledge and
I've got four weeks spare starting
Friday - I might be able to look into designing something that would read
disks. There should be a spare 3.5" drive around here *somewhere*...
Go for it. If you happen to be local (I'm near Cambridge) I've got
access to many different types of drives and media. But yep, starting
with a single 3.5" drive (and assuming it's the *only* drive connected
to the hardware) would seem a good place to start.
cheers
Jules