> Or...People are reluctant to publish their source code on the internet
> because they could receive alot of flack from their employer, who the
> source code ultimately belongs to, atleast here anyway.
>
> I can't send source code but I can give a few tips,
> 1)Don't rely on the MC app notes.
> 4)Use the tris registers instead of the port registers to make the pins
> go high and low
> 7)The best advice is to forget i2c unless absolutely neccessary, use SPI
> if you can!

There's nothing wrong or particularly hard with using I2C; SPI can be a
little faster, but only if you're using a >4MHz CPU or one with built-in
SPI hardware; if you really need the speed in such a case, you could use
two or four EEPROM chips and read/write them in parallel (you'd have to
deal with data in 16 or 32 bit chunks, but that shouldn't be a problem).
Using two I2C EEPROMs would get you speed as good or better than SPI with
the same number of port pins.

Also, note that while I2C in the general case is quite complex the subset
of the protocol needed for one CPU "master" to talk to one or more EEPROM
chips is quite simple.  Although I2C generally requires the clock to be
open-collector, and for the master to wait if slaves hold the clock low,
I have never seen an EEPROM chip which required bit-level waiting.  I'd
therefore suggest treating the clock as a standard output, saving yourself
a pull-up resistor.

Additionally, the protocol will seem much simpler if you roll the "ack"
pulses into the start of the read-byte routine.  I don't have the exact
sequence handy, but if you use the proper definitions for "start", "stop",
"read", and "write", you can forget all about acking (even on multi-byte
reads).  This makes the main code MUCH easier to write and understand;
the only caveat is that after you send a byte the data line will be low
until you read a byte or send a stop/restart; if left in this state the
device will draw some extra power through the pullup.