6 Dec
2006
6 Dec
'06
10:35 a.m.
Chuck Guzis wrote:
It just feels like it might get complex at that point - and costly. I suppose
you can put a header (or even just pads for one) on the main board for a cable
going to a second card, but not worry about the expense of adding a second
slot right now; sort of make it an optional extra. If CF is just IDE then it
should presumably be dead easy to support one or two cards on the same bus
anyway without additional logic.
Same deal on the floppy interface side - make it possible to hook it up as two
drives if someone wants to buy the extra cabling and relevant interface logic,
but don't actually provide that in the initial design (heck, don't even worry
about the firmware for it at this stage).
Later on it can then be done if people need it without a change of core design
or PCBs (just new firmware and additional hardware), but you're not worried
about every possible scenario from day 1.
On 6 Dec 2006 at 11:21, Jules Richardson wrote:
True. A link to a modern machine might be nice for transfer, though (to save
on swapping cards around). But I remember the lengthy discussions about what
the 'best' interface is in the past :-)
I was thinking that some sort of switch is a bit clunky - but with your
addition of the LCD the device would be able to display more information about
which file was selected (rather than having to rely on the user knowing that
the thing in 'slot' #0 was disk xyz etc.)
Darn interesting idea, though :) That implies
some intelligence controlling
the gadget 'remotely' though, or at the mickey-mouse end of the scale, a
rotary switch on top of the device to say which image to select. Perhaps a
version 2 thing?
Ideally, a couple of pushbuttons and a small LCD display, I'd think.
Floppy changing is a manual effort in the real world; no reason to do
it differently in the simulated world. Hmm, that
'feels' messy, somehow. Not sure why - but I think I'd prefer one
gadget per drive...
Yeah, it occurred to me that you'd get into the situation of "My A:
drive is on one CF card, but my B: drive is on another. What do I
do?" (2 CF slots, maybe?) Per-track access time from the CF shouldn't be
much of an issue. One
can always delay the index pulse until the data is ready (recall that
at 300 RPM, an index pulse occurs every 200 msec.).
True, but then wouldn't you have to buffer the entire written (computer to
device) and oversampled track of data in memory somewhere rather than spitting
it straight out to the CF card (via suitable serial ==> parallel conversion of
course)?
If there's a guarantee that the CF write speed is fast enough, then it should
make the device simpler as hopefully something like a PIC micro has enough
on-board RAM without worrying about external memory at all. Keeps costs down
too if you're not mucking around with things like SIMM sockets.
I think when I did some quick calculations a while back that CF write speed
should be good enough - but it was close on marginal CF cards (it seems like
write speed can vary a lot between manufacturers) when handling floppy drives
with high data rates (and assuming a reasonable level of oversampling).
Read speed (device to computer) shouldn't be an issue, I think.
For something like a 500Mbps/300rpm drive and 8x oversampling, I don't think
there'd be a problem at all, assuming that a disk surface can be stored on the
card as a raw linear sequence of blocks (worrying about handling of fragmented
files or encoding lots of metadata might screw things up).
It'd be a fun project, at any rate...
cheers
Jules
--
there's a carp in the tub
there's a carp in the tub
so nobody's taken a bath