no worries about the delay. it is purely by chance i ended up checking back here myself.
here is the schematic:
the following explanation is recycled from postings i have made elsewhere:
the design uses TxD to create PGC pulses, so an output pin on the serial port is freed up. PGD and -MCLR are under software control. PGM is monitored (not directly controlled), with the user instructed to insert a programming jumper (or close switch) at the required point. the end result is that much of the 'magic' behind making a serial port programmer is eliminated.
there are no timing delays involved during programming, everything is interlocked with feedback from the serial port: RxD monitors TxD, DSR monitors DTR. with a PIC16F628A i reckon it should be possible to program a device in a couple of minutes (based on 1mS USB packet boundaries).
i expect speed to be somewhere in the region of 20 words per second, which is fine for downloading firmware once, or for a hobbyist. making a few assumptions about how the USB driver is implemented for a given bridge may enable this speed to be considerably improved upon, but that is getting a bit ahead of things.
the basic algorithm for writing a single bit will look something like:
1. set DTR to desired state (bit value inverted) using 'EscapeCommFunction'
2. wait for DSR to reflect the new state by checking with 'GetCommModemStatus'
3. send out character 0xFF over TxD using 'WriteFile'
4. wait for character 0xFF to be looped back on RxD using 'ReadFile'
5. ... go back to step 1. for the next bit
for consecutive bits of the same value, steps 1 and 2 do not need to be repeated and multiples of character 0xFF can be sent out at step 3 and read back in at step 4. this will effectively double the throughput.
if it can be assumed that order of events will be preserved when changing the state of DTR and sending a character out TxD, then steps 2 and 4 can be skipped while writing a string of bits, at the end of the string then reading back the n character 0xFF's with a single ReadFile. this assumption may only hold true for certain drivers.
the dotted connections in the schematic allow, once the PIC16 device has been programmed, for the serial port to be used to communicate with the just uploaded firmware. this firmware, itself, could then implement a 'stage-2' device programmer - my own specific application is for a firmware that assists in programming PIC32 devices (using a modified branch of pic32prog that i have already got up and running over the last few months).