in reply to Reverse Engineering a portable mp3 player
For details on this scheme, search for I2C or SMBus.
The problem with using Perl directly for this is that bit timing is often somewhat crucial: there may be lower limits on bit transmission speed before one end or the other decides there's been a problem.
If it won't work in Win2K, it's probably just wiggling the port bits directly using OUT instructions; this won't be easy to monitor without a VXD that traps the instructions. You may be able to find such a VXD, though, on the net.
My strategy would be to do this:
- Count the wires on the interface.
- Trace them back to the printer port to figure out which are inputs and which are outputs (this is probably obvious from the connection, as they probably didn't depend on having bidirectional printer ports).
- Use an oscilloscope to look at the signals on these wires to determine which is clock and which is data
- Connect my old HP1631D logic analyzer to the pins and watch all the bits at once
- Try to compare with I2C, SPI, OneWire, or other known serial standard
- Write pieces of C code using Inline to send and receive bytes and words. Make this run on another PC to monitor the data traffic (having made a Y-adapter cable) (it's unlikely you'll be able to do this on the same machine successfully)
Now, you may not have an oscilloscope or logic analyzer, which will make the job much harder. You can make a simple logic analyzer using the parallel port of another machine and a tight loop in C or assembly language where you repeatedly use inportb or whatever is appropriate for your compiler to read the parallel port lines. You can use a change in state as a trigger.
update: I've found DIY projects for parallel port logic analyzers at http://www.xs4all.nl/~jwasys/old/diy2.html and http://et.nmsu.edu/~etti/winter97/computers/logic/logic.html and http://www.alphalink.com.au/~kevbond/digcro2k.htm
Good luck in your quest!