--- a/light9/io/Makefile	Tue Mar 20 02:34:28 2007 +0000
+++ b/light9/io/Makefile	Fri Jun 16 16:57:33 2006 +0000
@@ -5,7 +5,7 @@
 	result="your modules and links are now up to date"
 
 _parport.so: parport_wrap.c
-	gcc -shared ${INC} parport_wrap.c parport.c -o _parport.so 
+	gcc -shared -g ${INC} parport_wrap.c parport.c -o _parport.so 
 
 parport_wrap.c: parport.c parport.i
 	swig -python parport.i

--- a/light9/io/parport.c	Tue Mar 20 02:34:28 2007 +0000
+++ b/light9/io/parport.c	Fri Jun 16 16:57:33 2006 +0000
@@ -7,6 +7,7 @@
 #include <Python.h>
 
 int getparport() {
+  printf("parport - ver 4\n");
     if( ioperm(888,3,1) ) {
       printf("Couldn't get parallel port at 888-890\n");
 
@@ -26,34 +27,26 @@
 }
 
 void outbyte( unsigned char val ) {
+  int i;
   // set data, raise clock, lower clock
   outdata(val);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
-  outcontrol(2);
+
+  /* this was originally 26 outcontrol calls, but on new dash that
+     leads to screwed up dmx about once a minute. I tried doing 26*4
+     outcontrol calls, but it still screwed up. I suspect the athlon64
+     or my new kernel version is sending the parport really fast,
+     sometimes faster than the pic sees the bits. Then I put a 1ms
+     sleep after the outcontrol(2)'s and that didn't help either, so
+     I'm not sure what's going on. Putting the parallel cable on miles
+     seems to work. 
+
+     todo:
+     try a little pause after outcontrol(3) to make sure pic sees that
+  */
+
+  for (i=0; i<26*4; i++) {
+    outcontrol(2);
+  }
   outcontrol(3);
 }
 void outstart() {