I find myself wondering if PCMCIA, or IDE, would be easier to connect
to? {Or SCSI?} Or maybe one of those parallel port external drive
units like the ValueStor & H45 etc., that handle the interfacing to the
IDE drive for you?

Largest problem, as I see it, will be your file system handling code;
I've thought of just using an old AT or 386, running Dos (or Linux), as
a file interface, with a Parallel port interface to the PIC. That may
well be a lot easier way to do it, though physically larger, admittedly
(There are some small slim AT's around, though!) Though you could write
a custom filesystem, definitely.

I'd love to be able to do this, OTOH, there are some neat things I
could do if this is easily do-able; I'm NOT saying it's impossible
(should be even more do-able with the 17C series, I think!) as an XT
does have fewer MIPS than a typical PIC, just wondering about codespace.

And I'd love to play with it eventually, I do have a "spare" older
Valuestor (earlier model w/power switch) that I could see how badly it
gets destroyed by using that for a Linux EXT2FS IDE drive; And I have
source for the Linux "C" driver for the unit, for 386en etc.

Sounds tough but do-able, with some work. I think <G>

Another "Mark knows just enough about this area to be wrong" post,
brought to you by

PIC 16C64 as I have said in another message will do it. Once you get used
to the idea of having a streaming protocol that keeps no data in the PIC
(just in the sector buffer of the drive), you'll be fine.

I did almost all the design of a 5.3 GB serial storage data logger unit
like this... besides the C64 and a reset chip and a MAX 232 there was
nothing inside it. Serial was bit-banging. Once you get the drive to
initialize it is really easy to do this. If you use a laptop drive you can
have it power down by itself and live on miserly power almost forever, and
it will be near shock-proof when stopped ;) I feel that if one would use a
1.7 in drive it would almost fit in an old style RS232 plug cover with a
lithium battery (for photo use) <g>.

Obtain the ATA-3 protocol and read it thoroughly, then make the drive work
in interrupt-less mode (polling), possibly using an old computer's 2nd IDE
interface, then code this into the PIC. You will love to have LBA but it
also works without.

Note that I did the thinking in the same direction for ATAPI/EIDE CDROMs
to be able to make cheap background music players and came to the
conclusion that it can't be done easily as the PIC must compute the sector
offset/index of a piece of music and it can't store a sector buffer in its
RAM. If there was a command to re-read a sector from the controller buffer
however... ATA speccers, do you hear me ? Hey ? Hellooo ? On the other
hand, a PIC 17XX would be able to do it imho.

Peter L. Peres wrote:
>
> > IDE
>
> PIC 16C64 as I have said in another message will do it. Once you get used
> to the idea of having a streaming protocol that keeps no data in the PIC
> (just in the sector buffer of the drive), you'll be fine.
>
> <snipped>

Interesting. I'm working with the Atmel AT45D041 {or maybe the -081}
Flash EEProm on another project, it contains 2 264-byte data buffers
(along with 1/2 {or 1} megabyte of page-mode flash); You can clock the
data into or out of these buffers at up to 10 MHz (serial bit rate), you
can use the buffers as local "scratch" SRAM, it runs off 5VDC happily,
and you can control the chip with 6 PIC pins (plus 3 pins connected to
~MClr, Vcc, and Gnd, in an SOIC-28 or PLCC-32 or TSOP-28 package.) Lots
of "not care" pins, the PLCC-32 package has a few "do not connect" pins
<G>

The thoughts occur to me that 512 bytes = less than 2x264 bytes, so
that you could stow stuff into the Atmel part in 256-byte chunks & then
fast clock the data from the AT part to the PIC & on to the hard drive
once in a while to store the data (Could even do SCSI this way?) The
Atmel part isn't that horrid to interface to, & it's fast... $10 cost
isn't bad, as well <G>

One way to interface to a Laptop HD in a low-power manner, at least
<G>

(I forget how large a CD-Rom's sector is, it's crazy here right now
<G> but if it's 512 bytes, this approach might help!)