I have been working on building a lpt based monitor in my spare time. I am just about ready to connect, and start delving into the programming side of things. I know there are commercial products out there, but that does not cut it for me. I really want to learn more than anything. As I start laying out the programming I have run into a few questions and I hope you guys can steer me in the right direction.

If we base the first question off of a EC command to the hard drive, I believe the process (at the physical level) would be:
This is what I am expecting to see as the activity on the pins.
1. Set the DIOW,CS0, and DA0-2
2. set dd0-7 as 11101100
3. set IORDY or INTRQ
4. DD0-15 set with each DWORD from the drive.
Rinse/repeat/etc.

Is this reasonably close?

My other question is pertaining to timing. As always, I am suffering through a .NET implementation. I have no access to interrupts, so I have to poll the port repetitively. If I am interested in monitoring just the commands, can I stay with DD0-7? I am thinking just to poll as fast as possible, and skip anything that does not contain data.

I have a CPLD dev kit on the way, and my intent is to use it to make an interface from the slave connector on one IDE port to the other IDE port. If I get that running, I can access all relevant ports without shifts. At least I hope.

Has anyone else run down this path? Advice? Doctor referral?

Thanks as always!

Doomer? Pepe?

Well now. Do you mean to say you are building an IDE sniffer for a printer port?

_________________
HWHacker
Smiles

Lets be 100% accurate and say that I am attempting to build

Ok, lets take a look at it. What do you already know about the IDE interface. You have the pinout, the data transfer rate, the protocol. Also do you have the pinout and maximum data rate on the lpt.

Now then the IDE is 16 bit wide so we need to double the date rate for the 8 bit lpt. BTW you will want to use (EPP) Enhanced Parallel Port.

Ok, so we buffer the IDE, funnel it into the EPP, and write some software that will DMA the data to a file. At the same time we see if we can use one of the normally unused in EPP handshaking lines to allow us to tell the software if the data being gathered was a "to" or a "from" the IDE device data word.

Please review these items and see if there are any show stoppers. The IDE has R/W signaling and buffering the data with a tag could be done with the correct hardware.

What say ye?

_________________
HWHacker
Smiles

Oops, almost forgot the AD0-2 and CS0-1 lines. So that makes a third data word. Thanks pepe

_________________
HWHacker
Smiles

You are going to need external hardware........
or at least something custom to sit on a high speed bus (possibly PCI/ ETHERNET/USB), or if you persist with the LPT a shit load of external ram.

A CPLD is a good start.. an FPGA would have been better, specifically because you are going to need RAM... lots of RAM buffers.

Any device is going to have to be capable of capturing edges at TWICE the speed you want to log at(just to catch the edges, this is standard signal processing info.), on top of that, you need enough consistent speed to store the log results OR some sort of hardware buffer independent of the code.

Also consider that:
On a modern PC you cannot stop the interrupts.
When an interrupt is triggered you only have 1 instruction stream, by default that means your capture code will be halted whilst the CPU processes its interrupt vector.

The normal solution for this sort of work is to have a very small section of the design over-clocked, convert serial to parallel via a shift system and then bring it out Shift*n slower.
Consider a signal at 80MHZ, you have a high speed input , which parallel shifts the signal by a factor of 10, the result is that you deal with final parallel data at 8MHZ-16MHZ, or well within the design specification of most PLD hardware, an inexperienced designer/ noob would try to run the whole design at 160MHZ.... and would then have problems with the internal silicon paths not meeting this timing.

Now the difficult bit......
Consider that the cable between 'your' hardware and the system you are monitoring, will delay the signals by 1ns-2ns per 3 inches of cable/tracking(and we won't even touch upon reflection matters), which means you will get signal shift across any wires/paths that are not exactly the same length, that may not seem like a "biggy" but inside your FPGA/CPLD , it is edge driven, so if your edges don't line up, you may well acquire wrong data, randomly....

Finally , just because your PLD/FPGA cannot meet the target frequency does not mean the job is hopeless, all you need to do is move the "serial2Parallel" section to a separate hi-speed chip that sits outside the device, parallel the info outside, then feed that into the CPLD/FPGA.

_________________
Universal Declaration of Human Rights: Article 19

Damn!!.
I forgot to ask, Which CPLD kit?

_________________
Universal Declaration of Human Rights: Article 19

XC9572XL is the dev kit.

Your fine but just wish you would have posted before getting the kit.........

this will be ok for simple logic terms, but is going to require additional infrastructure.

This may have been better:

http://apple.clickandbuild.com/cnb/shop ... SB+to+FPGA
you get a spartan3a+128k memory & a spare USB Channel+ lots of I/O

or something more cost effective with buffers:

http://www.seeedstudio.com/depot/preord ... l?cPath=75 (possibly JUST what you need)
http://www.gadgetfactory.net/gf/products/
http://www.gadgetfactory.net/gf/project/butterflylogic/

That way you have room for integral ram buffers+logic and a handy built in high speed USB interface

That would have tied into :

http://sourceforge.net/projects/jlac/
http://www.sump.org/projects/analyzer/


Or you could have gone the actel easy FPGA (pro asic3)range.


Which XILINX development software are you going to be using 9.x, 10.x or 11.x?

Personally I would recommend Xilinx 10.x SP3, using the 'latest& greatest' Xilinx software is usually a pain in the ass, and then there is the continual issue with the shit being locked with expiring keys.

_________________
Universal Declaration of Human Rights: Article 19

Here is an excerpt from T13/T14 that shows the programed I/O timing.

_________________
HWHacker
Smiles

The xilinx was mostly for fun outside of this. I have been working in v11. I have not had any license issues yet, but I am now wary. oh yeah and about this:
http://www.seeedstudio.com/depot/preord ... l?cPath=75
How i did not see that is beyond me... It is on its way now Thanks!

Glad i finally managed to be of assistance to someone:

I'm working with Vertex-II Pro & XUPV5, which I used during my predoctoral Thesis on Nand-Flash controllers. (forensics)

Even for fun always try to grab an FPGA over a CPLD, you can always compile "down" to a CPLD or multiple CPLD's.

I keep meaning to 'day trip' (They are in China, about 2 hrs away) and see Seed Studio & pick up one of these as a cheap Spartan3E boards, plus one of their "bus pirates"
(think CHEAP hard drive internal protocol hacking: 1-Wire, I2C, SPI, JTAG, asynchronous serial (UART) . also check out their single channel DSO)

http://www.seeedstudio.com/depot/bus-pi ... Path=61_68
http://www.seeedstudio.com/depot/dso-na ... th=104_108

The good thing with this Open Workbench Logic Sniffer, is that all the software for a 'basic' logic analyzer is written and mostly tested, and to top it off there is an Eagle file for the pcb layout and schematic.
I notice there are some "free" lines on the FPGA , so with a bit of skill it should be possible to add a secondary memory system.

_________________
Universal Declaration of Human Rights: Article 19

They should have named it the iScope