For now, I hope this info is enough:
it's a normal V-USB connection for VCC=5V operation (pullup D- with 1.5kR; D+ and D- with 3.6V Zdiodes to ground and connected via 68R to DBx of ATTiny25). Please check the src to find out where to connect D+ and D- (usbconfig.h). I think D+ has to go to PB2 because of INT0, and D- was connected to pin3 (PB3?).

Connect the ATTiny10 so that S_HIGH and S_LOW trigger the /RESET line.
D_HIGH and D_LOW shall drive the PB that is connected to TPIDATA. Data-PB must be connected via 1kR to TPIDATA.
Q_READ shall read the PB that is connected to TPIDATA.
C_HIGH and C_LOW must drive the PB connected to TPICLK.
VCC and GND of the ATTiny10 are directly connected to VCC and GND of the USB. So the CPU will be running as soon as you plug it in.

I tried it in Virtalbox with Win XP guest and Linux host. I can see the device in lsusb (Bus 004 Device 013: ID 16c0:05df VOTI) and I can connect it to Win guest in Virtualbox. But the programming application doesn't work, when trying to read it just prints "Opening USB device failed". I don't know if it's due to the extra layer which goes through Linux first or if I miss something on the Windows side. I'll try it in native Win XP at work later.

do you haave VisualStudio? Then you can trace into the "connect()" function to check what's going wrong.
I'll upload a new version with faster programming/verifying this evening. I will add some error messages.

I'm sorry I had one miswiring to the tiny25, missed it by 1 pin. It's always good to recheck the wiring :) So it works fine now, reading and programming, with the RESET high active unchecked.

When I saw the Opening USB device failed, I thought it means problem in communication with tiny25 since it is the USB device, not the tiny10 target. It would be nice if you can print something like Connecting to programmer... OK/Failed and Connecting to target... OK/Failed. With that I could see where is the problem.

Some other suggestions:
-It's not obvious if the verify was succesful, it prints the result only when it fails.
-Add flash read option and possibly read calibration byte, but that's not so important, it just adds to the completeness.
-When you're deselecting the device at the end, can you make it run the program? I tried also the check RESET high active and that leaves the target running so it looks like it's inverted or maybe you wanted keep it in reset? If yes you could add checkbox for disconnect state. I tried disconnecting the reset line from tiny25 and adding pull-up but it still needs to be reset by briefly inputing low.
-Does the tiny25 keep all lines hi-Z when not programming?

It's still impressive how simple and easy to make is this programmer. Before this I saw everywhere that minimal AVR for USB was tiny45. Now I could grab the tiny25 which I happened to already have and make good use of it. Thank you for the project!

It's planned to implement all the tabs from the AVRdragon application. That includes a better fuse-selection dialog, reading/writing the calibration, etc. However calibration is not possible since we dont have a calibration-clock source.

The "RESET high active" option is for a different schematic: in my setup it drives a transistor that drives the 12V-reset voltage. So when I put high on the "S"-pin, it will apply 12V to the reset pin. This is needed because I programmed the RSTDBL fuse.

I had to heavily tweak the USB firmware (with OSCCAL self-calibration) in order to get it into 2048 bytes INCLUDING the bitbanger payload (it's 2044 bytes). That is why a lot of features are missing from the bitbanger side. The firmware was initially developed for flashing an AMIC A25L40P NOR flash - the class for that chip is included in the sources.

I think to truely restart the target, you need to cycle the power.
The "D"-pin is hardwired as output, there is always a signal on it. That is why it's connected via a resistor to the target.
I guess the "C"-pin should also be connected via resistor.
The state of the pins is simply the last value written to them.

What winavr version do you use? Which compiler and linker flags? I'm unable to build it with 2048 bytes (2050 right now), using winavr 20100110, linking libc and libm, and adding these compiler and linker options:

The "RESET high active" option is for a different schematic: in my setup it drives a transistor that drives the 12V-reset voltage. So when I put high on the "S"-pin, it will apply 12V to the reset pin. This is needed because I programmed the RSTDBL fuse.

can you add this transistor in the schematic as "optional"? Since the tiny10 only has 4 I/Os it might be nice to be able to use the RESET pin as an I/O pin with the option of being able to reprogram it.

Actually, the transistor drives the power supply for the 12V-circuit. I am using a "SIM1-0512" for this, but you can save about 1-2Euros by using the cheaper Maxim MAX662A as shown here:http://www.avrfreaks.net/index.p...

Please note that the RESET pin is a "weak" output pin. The LED is very dim compared to the other pins.

1. Is the 12V programmer used to revive "dead" ATTINY micro-controllers. I have a bunch of ATTINY45s that I accidentally enabled the RSTDISBL bit, and they are no longer responsive. I see that the 12V output applies to the /RESET pin of the target micro-controller.

2. Your PWM sound examples look very interesting. Would you kindly describe the methods on how that is worked? And would I need to wire the output to some sort of amplifier IC to an 8ohm speaker for better audio?

So I suggest that you use 5V from the USB cable.
I guess that the logic signals will work fine during TPI programming whether they are 3.3V or 5V.

Regarding zeners on the D+ and D- lines. It is very important to use the correct part number. The nominal 3.3V zener is only 3.3V at typical currents. If you only send 1mA through the zener, a 400mW device will probably be 3.0V, a 1.5W device will probably be 2.5V.

You have to check the data sheets of your particular zener diode.

I can't help feeling that a $3.60 Chinese usbasp is the easiest (and cheapest) way to do TPI.

The device reads signature properly, but at the programming attempt it says "Too many IDLE bits. Target is not responding" and waits for my decision to continue programming. I'll try to verify whether it programmes properly.