I've seen programming languages and operating systems do all sorts of interesting things "on your behalf" that you really didn't want done. So my first guess would be that the language you are using is not really doing what you expect it to with the port. Knowing the development environment and seeing some of the code might allow us to help with that point. My second guess is that Windows doesn't like things other then VDX's monkeying with its ports in 32bit modes (it buffers DOS and 16 bit stuff) and is inserting its own signal changes which are interfering with yours. You might peruse one of the many books on writing device drivers. If you do, let me know if any are worth a damn . >From what I've seen, the number of people in the world who can write a parallel port device driver for anything other than SPP mode can be counted on your fingers and toes. Or at least that's all the people who will admit to it. And they aren't talking. EPP and ECP windows drivers (especially printer drivers) are apparently black art. You get this "we could tell you but then we would have to kill you", x-files feeling when you talk to these people. Someday, I'm going to learn how to do that and tell everybody if no one else has... wait! what's that sound? AHHHH! ITS THE BLACK HELECOPTERS!!!! Anyway, I have a bit of information about the hardware signals http://techref.massmind.org/io/parallel/port but nothing really about the software side except for a very good understanding of the PCL 5 printer language which doesn't relate to your project. I'd be very interested in working with you on this project if you don't mind the result being free source. --- James Newton mailto:jamesnewton@geocities.com 1-619-652-0593 http://techref.massmind.org NEW! FINALLY A REAL NAME! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Keith Burzinski Sent: Monday, February 28, 2000 22:29 To: PICLIST@MITVMA.MIT.EDU Subject: Re: [OT] Windows and the Parallel Port Okay... obviously I was not coherent enough when I made the original post. ;) I _AM_ using the PARALLEL PORT. It is in ECP mode. I am using the eight (8) data lines as OUTPUTS ONLY to the PIC that I have connected. There are two additional lines that a parallel port uses in ECP mode to accomplish hand-shaking (I pull my line, you pull yours, then we both reset). THAT IS ALL. It is intended (and used) for one-way communication. I am _not_ attempting to read anything from the PIC; I am only transmitting data TO the PIC. Next: The device is not experiencing (sp?) over-run. The communication works PERFECTLY when done in DOS. As was mentioned, over-run would result in the loss of random characters, not a complete halt in communications. Basiclly what I'm doing is porting a _working_ DOS program to Windows (98). I already know that accessing the parallel port will cause unpredictable results if I have anything else hooked up to it (printers, scanners, etc....); let's assume for now that MY device is the ONLY device physically connected to (and being accessed by) the parallel port. What is my device? A Parallel-Port to DMX-512 transmitter. I'm working on a PC lighting console for my smart lights. :) Here's exactly what happens: When my Windows application starts, I have it transmitting a "test pattern" to my device. Only the first 16 bytes arrive there, however. After that, no matter what I do, I can't get anything more out of the port. It just dies. If I want to use it again, I have to quit my application and start it again. Then I get 16 more bytes... So, like, what is going on? Why does it die after 16 bytes? :) Perhaps there is something I need to initialize (other than the port itself) before I can use it (the port)? Are there some API calls I should be placing? I know this has been done before... Why does it have to be so difficult? I'm seriously considering just writing this for X and leaving it at that. *smirk* Cheers, -- ~Keith tsk3000@Prodigy.Net http://pages.prodigy.net/tsk3000/ ICQ UIN 15590177