>  1 The PIC receives a START Condition... then
>  ...
>  7 The PIC has fulfilled the request and does not acknowledge so that
>    a STOP condition can be generated by the PC.

When reading, the master acks/no acks the slave, not the other way around
as in step 7.  I'm assuming the pc is the master and the pic is the
slave here.  Getting acks messed up can result in one of the devices
holding a line low forever.  As Andy mentioned, this can cause the low
voltage if something else is trying to drive the line up (although they
shouldn't be driving i2c lines high, they should be floating high).

You mentioned the pc program works with an eeprom, but I don't think
you can assume the pc side is working properly.  This is different
because of the customization.  If you were doing just a one byte read
without first setting the eeprom address, the sequence is:
  start
  send device address, bit set (slave acks)
  read the data (master no acks)
  stop

you've inserted a second send into this - so it can't really be tested
with an eeprom.

I would back up to the point where I got the pc to read one byte from
the pic, with the pic acting exactly like an eeprom.  Once that was
working, then extend to the other stuff.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics