GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive:programming:gla-91o

From markb@tplrd.tpl.oz.AU Thu Oct 3 05:06:27 1991 Received: from metro.ucc.su.OZ.AU by karazm.math.UH.EDU with SMTP id AA12981

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 2 Oct 1991 21:12:00 -0500

Received: by metro.ucc.su.OZ.AU (5.61/1.34)

id AA02783; Thu, 3 Oct 1991 12:08:05 +1000

Received: by tpl68k0 (5.51/2.27); id AA11116; Thu, 3 Oct 91 10:06:37 EST From: markb@tplrd.tpl.oz.au (Elvis Presley) Message-Id: <9110030006.AA11116@tpl68k0> Received: by tpl68k5 (5.51/2.15); id AA09177; Thu, 3 Oct 91 10:06:27 EST Date: Thu, 3 Oct 91 10:06:27 EST To: glove-list@karazm.math.uh.edu Subject: Subscribe

SUBSCRIBE me please subscribe

mark

From dirtybob@janis.cac.washington.edu Sun Oct 6 12:38:18 1991 Received: from janis.cac.washington.edu by karazm.math.UH.EDU with SMTP id AA00263

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 6 Oct 1991 21:40:26 -0500

Received: by janis.cac.washington.edu (5.57/Ultrix3.0-C)

id AA15155; Sun, 6 Oct 91 19:38:18 -0700

Date: Sun, 6 Oct 91 19:38:18 -0700 From: dirtybob@janis.cac.washington.edu (Richard M. Nixon) Message-Id: 9110070238.AA15155@janis.cac.washington.edu To: glove-list@karazm.math.uh.edu Subject: PLEASE ADD ME TO THE MAILING LIST

Thanks!

From jdb9608@cs.rit.edu Mon Oct 7 08:43:19 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA02032

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 7 Oct 1991 11:46:29 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA02651; Mon, 7 Oct 91 12:42:36 -0400

Received: from lithium.CS (lithium.ARPA) by junior.rit.edu (4.1/5.17)

id AA01637; Mon, 7 Oct 91 12:32:14 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110071632.AA01637@junior.rit.edu Subject: C hires code for ATARI 1040 ST (fwd) To: glove-list@karazm.math.uh.edu Date: Mon, 7 Oct 91 12:43:19 EDT Cc: jxw1578@cs.rit.edu (John X Whitehurst), rwr9481@cs.rit.edu (Robert W Reay),

      rxc9885@cs.rit.edu (Robert X Costello)

X-Mailer: ELM [version 2.3 PL8]

HIRES HIRES HIRES HIRES HIRES HIRES HIRES HIRES HIRES HIRES

This is it, folks! I can't believe it.

It really works. I didn't do any of its development, but I have tested it with Sozoban C (with minor adjustments–changing "tos.h" to "osbind.h", and deleting two void's in forward function declarations).

Manfredo has tried posting it to the glove-list, but it's disappeared into some black hole somewhere, so he asked me to post it for him.

I've gotten the data packets in the right sequence, but not the right order. They've started with Z and ended with A0 X Y, so I don't have it all figured out yet, but that doesn't really matter since even if the data packet is out of order, I can still tell which byte is which by seeing where A0, 0, 0, 3F, FF, FF occur.

The problem with this program is that it uses busy loops for very long times (i.e., over 75,000 microseconds). That makes the sample rate a little slow (which is okay since my ST can't do much per second anyway), and—most importantly—it hogs all the CPU time. I'm working on a modification which uses the MFP's timer A to generate an interrupt after the appropriate long interval (D2SLOW) and then handle the rest of the protocol in an ISR. That should free up the CPU for graphics. I'll post it when I get it working.

I'll also put this source in karazm.math.uh.edu:pub/incoming/VR tonite when the anonymous ftp is allowed (Eric…). If anyone has special questions about how the ST works, for converting this code to other computers, I'll be happy to see what answers I can dig up.

Now, does anyone have freely–distributable source for a nice 3D graphics library (PHIGS, maybe?), before I go write my own?…

Forwarded message:

From manfredo@medap1.cs.tu-berlin.de Wed Oct 2 12:12:02 1991
From: manfredo@medap1.cs.tu-berlin.de (Manfred Krauss)
Message-Id: 9110021622.AA09307@medap1.cs.tu-berlin.de
Subject: C hires code for ATARI 1040 ST
To: jdb9608@rit
Date: Wed, 2 Oct 91 17:22:37 MET
X-Mailer: ELM [version 2.3 PL6]

Hi,

Following C program switches the glove into hi-res mode.
The protocol goes via latch. The code works very well.

Next project is to build a little controller with a 68HC11
processor to connect the glove to any? computer via RS232
interface. I've no experience in programming such a processor.
Is anyone out there who is familiar with the 68HC11?
I can send a complete timing diagramm and support the work
with my knowledge.

Waiting for hints and comments.

manfredo

——————– cut here ————————————–

/ power.c © manfredo 9/91 enjoy "HiRes" mode manfredo@opal.cs.tu-berlin.de This program is without any WARRANTY use at your OWN risk @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The code is very ugly, but it was the only way to get speed on this poor hardware in C. It was developed on an ATARI 1040ST with TC 1.1 using a logic analyzer to get the correct timings. connect NINTENDO POWERGLOVE to ATARI 1040ST parallel port PG ATARI +5V pin7 power supply +5V GND pin1 pin18 parallel port & power supply GND data pin4 pin1 parallel port latch pin3 pin2 parallel port clock pin2 pin3 parallel port Datapacket: (12 bytes) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. A0 X Y Z rot finger keys 00 00 3F FF FF /

#include <stdio.h> #include <tos.h>

/* PSG (Programable Sound Generator) */ #define PSG 0xff8800 /* sound chip read data */ #define PSGW 0xff8802 /* sound chip write data */

/* registers in PSG */ #define CONREG 7 /* read/write control reg */ #define AREG 14 /* port A */ #define BREG 15 /* port B */

/* read / write bits in PSG register 7 */ #define AREAD 0xbf /* A read bit in register 7 */ #define BREAD 0x7f /* B read bit in register 7 */ #define AWRITE 0x40 /* A write bit in register 7 */ #define BWRITE 0x80 /* B write bit in register 7 */

/* bits from parallel port */ #define GDATA 0x20 /* Strobe (Pin 1) PG data in */ #define GLATCH 0x01 /* bit1 (pin2) PG latch out */ #define GCLOCK 0x02 /* bit2 (pin3) PG clock out */ #define GCLOLAT 0x03 /* bit2 + bit 1 */

/* Delay timing */ #define delay(val) { \

                              register unsigned long i = val /7; \
                              for ( ;i-- > 0; ) \
                                    ; \
                         }

#define D2BYTES 192 /* delay between 2 bytes 96 us */ #define D2BITS 21 /* delay between 2 bits 22 us */ #define D2SLOW 32000 /* 4 slow bytes in packet 14720 us */

#define C0L0() *wr = 0 /* clock 0 latch 0 */ #define C0L1() *wr = GLATCH /* clock 0 latch 1 */ #define C1L0() *wr = GCLOCK /* clock 1 latch 0 */ #define C1L1() *wr = GCLOLAT /* clock 1 latch 1 */

#define setporta() *rd = CONREG; \

  • wr = *rd & AREAD; \
  • rd = AREG

#define setportb() *rd = CONREG; \

  • wr = *rd | BWRITE; \
  • rd = BREG

void Hires (void); unsigned char getbyte (void);

void main () {

long lola;
unsigned char buf[12];
register unsigned char *bp;
lola = Super (0L); /* set supervisor mode to access hardware
                      directly */
printf ("lola <0x%x>\n", lola);  /* satisfy TC compiler */                                                

Hires (); /* set PG into 'hires' mode */
for ( ; ; ) /* read 12 byte packets */
{
	bp = buf;
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2BYTES);
	*bp++ = getbyte ();
	delay (D2SLOW);
	*bp++ = getbyte ();
	delay (D2SLOW);
	*bp++ = getbyte ();
	delay (D2SLOW);
	*bp++ = getbyte ();
	delay (D2SLOW);
	*bp++ = getbyte ();
	delay (D2SLOW);
	printf ("Glove %-2x %-2x %-2x %-2x %-2x %-2x %-2x %-2x %-2x %-2x %-2x %-2x\n",
			buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
			buf[6], buf[7], buf[8], buf[9], buf[10], buf[11]);
}

}

unsigned char getbyte () {

register unsigned char *rd = (unsigned char *)PSG;
register unsigned char *wr = (unsigned char *)PSGW;
register int i;
register unsigned Glov = 0;	
/* prepare port b as output port */
setportb ();
      /* generate a reset (latch) pulse */
C1L0 ();
C1L1 ();
for (i = 1; i-- > 0; ); /* 5 us delay */
C1L0 ();
/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();
return Glov;  /* return the byte */

}

void Hires () {

register unsigned char *rd = (unsigned char *)PSG;
register unsigned char *wr = (unsigned char *)PSGW;
register unsigned char Glov = 0;
register int i;
/* read 4 bits from glove */
setportb ();
      /* generate a reset (latch) pulse */
C1L0 ();
C1L1 ();
for (i = 1; i-- > 0; );   /* 5 us delay */
C1L0 ();
/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* configure port a as input */
setporta ();
/* read a bit */
*rd &= GDATA;
Glov <<= 1;
Glov += *rd >> 7;
/* prepare port b as output port */
setportb ();
/* generate a clock pulse */
C0L0 ();
C1L0 ();

/* end of read 4 bits */
/* prepare port b as output port */
setportb ();
C1L0 ();
delay (16950);  /* 7212 us delay */
setportb ();
C1L1 ();
delay (4750);   /* 2260 us delay */
/* prepare port b as output port */
setportb ();
C1L0 ();	/* Start of 1. Byte */
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);	
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L1 ();
C0L1 ();
C1L1 ();
delay (D2BITS);

/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);	
/* prepare port b as output port */
setportb ();
C1L0 ();
C0L0 ();
C1L0 ();
delay (D2BYTES);		
/* prepare port b as output port */
setportb ();
C1L1 ();	/* Start of 2. Byte */
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L0 ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L1 ();
C0L1 ();
C1L1 ();
delay (D2BYTES);
/* prepare port b as output port */
setportb ();
C1L0 ();	/* Start of 3. Byte */
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);	
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);	
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);	
/* prepare port b as output port */
setportb ();
C1L1 ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L0 ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BYTES);
/* prepare port b as output port */
setportb ();
C0L0 ();	/* start of 4. byte */
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BYTES);
/* prepare port b as output port */
setportb ();
C0L0 ();	/* start of 5. byte */
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L1 ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L0 ();
C0L0 ();
C1L0 ();
delay (D2BYTES);
/* prepare port b as output port */
setportb ();
C1L1 ();	/* start of 6. byte */
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L1 ();
C1L1 ();
delay (D2BYTES);
/* prepare port b as output port */
setportb ();
C1L0 ();	/* start of 7. byte */
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C0L0 ();
C1L0 ();
delay (D2BITS);
/* prepare port b as output port */
setportb ();
C1L1 ();
C0L1 ();
C1L1 ();
delay (1090); /* 892 us delay (end of 7. byte) */
/* prepare port b as output port */
setportb ();
C1L0 ();
delay (60000);   /* some time for the glove controller
					to relax */

} ——————– cut here ————————————–


Manfred Krauss, manfredo@opal.cs.tu-berlin.de Dept of Computer Science, Technical University of Berlin, Franklinstr. 28-29, W-1000 Berlin 10, Sekr. FR3-3, Germany


– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From jdb9608@cs.rit.edu Mon Oct 7 10:03:51 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA02232

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 7 Oct 1991 13:05:38 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA05490; Mon, 7 Oct 91 14:01:50 -0400

Received: from argon.CS (argon.ARPA) by junior.rit.edu (4.1/5.17)

id AA01993; Mon, 7 Oct 91 13:51:35 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110071751.AA01993@junior.rit.edu Subject: test To: glove-list@karazm.math.uh.edu Date: Mon, 7 Oct 91 14:03:51 EDT X-Mailer: ELM [version 2.3 PL8]

testing…

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From nop@att1.Mankato.MSUS.EDU Mon Oct 7 11:42:29 1991 Received: from ATT1.Mankato.MSUS.EDU by karazm.math.UH.EDU with SMTP id AA03580

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 7 Oct 1991 16:49:47 -0500

Received: by att1.Mankato.MSUS.EDU (5.59/25-eef)

id AA28398; Mon, 7 Oct 91 16:42:29 CDT

Date: Mon, 7 Oct 91 16:42:29 CDT From: Jay A. Carlson nop@att1.Mankato.MSUS.EDU Message-Id: 9110072142.AA28398@att1.Mankato.MSUS.EDU To: jdb9608@cs.rit.edu Cc: glove-list@karazm.math.uh.edu, jxw1578@cs.rit.edu, rwr9481@cs.rit.edu,

      rxc9885@cs.rit.edu

In-Reply-To: John D Beutel's message of Mon, 7 Oct 91 12:43:19 EDT 9110071632.AA01637@junior.rit.edu Subject: C hires code for ATARI 1040 ST (fwd)

I have a fair amount of HC11 experience. I'm interested in doing the powerglove interpreter—but I don't have a glove any more. :-( I can look over code, and suggest design and strategies, however. If someone is doing the HC11 interpreter project, I'd love to provide support.

// Jay Carlson

\X/ nop@att1.mankato.msus.edu

To subscribe to the MC68HC11 list, email to mc68hc11-request@quack.sac.ca.us.

From jdb9608@cs.rit.edu Mon Oct 7 19:42:36 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA04638

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 7 Oct 1991 22:46:14 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA09181; Mon, 7 Oct 91 23:41:46 -0400

Received: from lithium.CS (lithium.ARPA) by junior.rit.edu (4.1/5.17)

id AA03667; Mon, 7 Oct 91 23:31:31 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110080331.AA03667@junior.rit.edu Subject: hires source (C Atari ST) via ftp To: glove-list@karazm.math.uh.edu, jet@uh.edu Date: Mon, 7 Oct 91 23:42:36 EDT X-Mailer: ELM [version 2.3 PL8]

Incase anyone missed it (I missed it myself at first; a delay in the mailers confused me), the C source code (Atari ST) for the hi-res mode is available via anonymous ftp (at nite) from karazm.math.uh.edu. It's pub/Incoming/VR/hires.src.ST (I think), and soon it may be in the pub/VR directory instead.

I can't wait to see what great software comes out of this!

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From jdb9608@cs.rit.edu Mon Oct 7 19:49:43 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA04655

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 7 Oct 1991 22:52:42 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA09253; Mon, 7 Oct 91 23:48:53 -0400

Received: from lithium.CS (lithium.ARPA) by junior.rit.edu (4.1/5.17)

id AA03682; Mon, 7 Oct 91 23:38:38 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110080338.AA03682@junior.rit.edu Subject: flaky lo-res To: glove-list@karazm.math.uh.edu Date: Mon, 7 Oct 91 23:49:43 EDT X-Mailer: ELM [version 2.3 PL8]

I noticed something about lo-res mode acting flaky. It's worked pretty well for me before, but just this month I've moved my computer into a smaller room. I tested it recently, for the first time, in the new room. Now lo-res is flaky. I get readings when I point the glove in ANY direction. I get changing readings when the glove is pointing away from the receivers and I just WALK thru the room between the glove and the mics. The sounds have got to be bouncing off the walls. This could be a cause of some of the problems people have had.

If you're glove acts flaky and adjusting your program's timing hasn't helped, you might want to try using it in a big room or wide open space.

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From yonder@netcom.netcom.com Mon Oct 7 22:55:28 1991 Received: from netcomsv.netcom.com by karazm.math.UH.EDU with SMTP id AA06611

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Tue, 8 Oct 1991 08:00:02 -0500

Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1)

id AA10740; Tue, 8 Oct 91 05:55:29 PDT

Received: by netcom.netcom.com (4.1/SMI-4.1)

id AA02449; Tue, 8 Oct 91 05:55:29 PDT

From: yonder@netcom.com (Christopher Russell) Message-Id: 9110081255.AA02449@netcom.netcom.com Subject: ST hi-res code! To: glove-list@karazm.math.uh.edu (Power Glove mailing list) Date: Tue, 8 Oct 91 5:55:28 PDT X-Mailer: ELM [version 2.3 PL11]

Could somebody give me some background on how the ST hi-res code was developed! I am an ST user so this is great. But I was just wondering how it was figured out!

– Christopher L. Russell (yonderboy) Phone: (408)378-9078 Campbell,CA yonder@netcom.COM or clr40@amail.amdahl.com or chrisr@leland.stanford.edu

From jet Tue Oct 8 05:42:12 1991 Received: by karazm.math.UH.EDU id AA07173

(5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 8 Oct 1991 10:42:12 -0500

From: J Eric Townsend <jet> Message-Id: 199110081542.AA07173@karazm.math.UH.EDU Subject: Re: hires source (C Atari ST) via ftp To: jdb9608@cs.rit.edu (John D Beutel) Date: Tue, 8 Oct 91 10:42:12 CDT Cc: glove-list@karazm.math.uh.edu, jet@uh.edu In-Reply-To: 9110080331.AA03667@junior.rit.edu; from "John D Beutel" at Oct 7, 91 11:42 pm X-Mailer: ELM [version 2.3 PL11]

you wrote:

karazm.math.uh.edu. It's pub/Incoming/VR/hires.src.ST (I think),
and soon it may be in the pub/VR directory instead.

It's in the pub/VR directory, compressed.

thanks.

– J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu

  1. - Vote Bart Stewart for Houston Mayor – "Why the Hell Not?" –

From squier@babbage.ecs.csus.edu Tue Oct 8 10:14:51 1991 Received: from babbage.ecs.csus.edu by karazm.math.UH.EDU with SMTP id AA09456

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Tue, 8 Oct 1991 19:19:41 -0500

Received: by babbage.ecs.csus.edu (5.61/1.34)

id AA06845; Tue, 8 Oct 91 17:14:54 -0700

From: squier@babbage.ecs.csus.edu (Anthony Squier) Message-Id: 9110090014.AA06845@babbage.ecs.csus.edu Subject: HiRes Mode To: glove-list@karazm.math.uh.edu Date: Tue, 8 Oct 91 17:14:51 PDT X-Mailer: ELM [version 2.3 PL0]

From eegeh@wrasse.jcu.edu.au Wed Oct 9 23:25:37 1991 Received: from wrasse.jcu.edu.au by karazm.math.UH.EDU with SMTP id AA09858

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Tue, 8 Oct 1991 22:29:30 -0500

Received: by wrasse.jcu.edu.au (5.57/1.34)

id AA07549; Wed, 9 Oct 91 13:25:37 +1000

Date: Wed, 9 Oct 91 13:25:37 +1000 From: eegeh@wrasse.jcu.edu.au (Glen Elliot Harris) Message-Id: 9110090325.AA07549@wrasse.jcu.edu.au To: glove-list@karazm.math.uh.edu Subject: please add me

please add me

From galt%peruvian@cs.utah.edu Tue Oct 8 15:50:49 1991 Received: from cs.utah.edu by karazm.math.UH.EDU with SMTP id AA09914

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Tue, 8 Oct 1991 22:54:40 -0500

Received: from peruvian.utah.edu by cs.utah.edu (5.65/utah-2.18-cs)

id AA03547; Tue, 8 Oct 91 21:50:52 -0600

Received: by peruvian.utah.edu (5.65/utah-2.12s-leaf)

id AA04800; Tue, 8 Oct 91 21:50:49 -0600

Date: Tue, 8 Oct 91 21:50:49 -0600 From: galt%peruvian@cs.utah.edu (Greg Alt) Message-Id: 9110090350.AA04800@peruvian.utah.edu To: glove-list@karazm.math.uh.edu Subject: PC hires source

I uploaded source code for a PC… I converted the ST code and fixed it up a little. I was thinking, we should probably have a standard interface of some sort so that our code will be relatively compatible. Here is my proposal:

typedef struct _glove_data {

 unsigned char dum0;
 signed   char x,y,z;
 unsigned char rot,fingers,keys,dum7,dum8,dum9,dumA,dumB;
 } glove_data;

void Hires(); void getglove(glove_data *);

possibly better function names would be glove_init() and glove_sample() Also, the byte that I called "dum9" seems to be used to tell if the glove is not aimed at the receivers.

One more thing I was wondering about… In the initialization function, it looks like 7 bytes are sent to the glove. I wonder what the significance of these is… The reading of the first few bits is probably to tell if a glove is really attached. The other thing to start brainstorming about is how to solve the problem of the 5 long pauses. Each one is 14 milliseconds, so you waste 70 milliseconds per sample. Surely something useful could be squeezed into that time somehow. Also, that only gives us 14 samples per second (assuming nothing else is done between samples).

Tonight I plan on experimenting with the finger input (I played around with x,y,z, moving a simulated 3D cursor around, and it was kind of interesting)

      Greg

From jdb9608@cs.rit.edu Tue Oct 8 22:04:57 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA10541

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 01:09:14 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA23462; Wed, 9 Oct 91 02:03:42 -0400

Received: from hendrix.CS (hendrix.ARPA) by junior.rit.edu (4.1/5.17)

id AA07963; Wed, 9 Oct 91 01:53:21 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110090553.AA07963@junior.rit.edu Subject: Re: glove HIRES source for Atari 1040ST To: djimenez@ringer.cs.utsa.edu (Daniel Jimenez) Date: Wed, 9 Oct 91 2:04:57 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110081846.AA16271@ringer.cs.utsa.edu.sunset; from "Daniel Jimenez" at Oct 8, 91 1:46 pm X-Mailer: ELM [version 2.3 PL8]

Great! I get the same problem with order, and so does Lance Norstrom. The packets start with Z, and end with A0, X, Y. Manfredo suggests pressing <center> several times and making fists to calibrate it. Galt suggests that it's a timing problem.

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From galt%peruvian@cs.utah.edu Tue Oct 8 18:01:00 1991 Received: from cs.utah.edu by karazm.math.UH.EDU with SMTP id AA10539

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 01:05:52 -0500

Received: from peruvian.utah.edu by cs.utah.edu (5.65/utah-2.18-cs)

id AA04860; Wed, 9 Oct 91 00:01:02 -0600

Received: by peruvian.utah.edu (5.65/utah-2.12s-leaf)

id AA05937; Wed, 9 Oct 91 00:01:00 -0600

Date: Wed, 9 Oct 91 00:01:00 -0600 From: galt%peruvian@cs.utah.edu (Greg Alt) Message-Id: 9110090601.AA05937@peruvian.utah.edu To: glove-list@karazm.math.uh.edu Subject: hires initialization

Well, if anyone is interested, the 7 bytes sent to init the glove seem to be: 0x06, 0xC1, 0x08, 0x00, 0x02, 0xFF, 0x01

It is hard to believe this is a whole program… Well, back to playing with the glove…

Oh, also, here's a list of all the finger positions that seem meaningful… First, only look at the high bit for each finger to get rid of noise, then look up in this chart:

0 open hand 1 double gun 2 middle finger bent 3 gun 4 fore finger bent 5 ?? 6 ?? 7 thumb up (or down depending on rotation) 8 thumb bent 9 double point (or peace sign) 10 ?? 11 point 12 O.K. sign 13 extended middle finger 14 extended ring finger (painful) 15 fist

Most of these are easily distinguished, so we have about 12 possible finger positions, and if you include orientation and possibly movement, that adds up to a lot of gestures.

Greg

From kskelm@uccs.edu Tue Oct 8 20:03:22 1991 Received: from GRUMPY (grumpy.uccs.edu) by karazm.math.UH.EDU with SMTP id AA10548

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 01:10:08 -0500

Received: by uccs.edu (MX V2.3-1) id 17473; Wed, 09 Oct 1991 00:03:22 EDT Date: Wed, 09 Oct 1991 00:03:22 EDT From: "NO, That's NOT a cord of wood in my pocket!" kskelm@uccs.edu To: glove-list@karazm.math.uh.edu Message-Id: 0094FD54.0F42E6E0.17473@uccs.edu Subject: Well……

So we've got an ST version and a PC version of the Hires code. Now…. what kind and brilliant soul will make a nice, timer-interrupt -based, multitasking version for the Amiga?? *with* a sample executable, preferrably?? :-)

From jdb9608@cs.rit.edu Tue Oct 8 22:14:56 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA10574

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 01:17:31 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA23550; Wed, 9 Oct 91 02:13:42 -0400

Received: from hendrix.CS (hendrix.ARPA) by junior.rit.edu (4.1/5.17)

id AA07970; Wed, 9 Oct 91 02:03:20 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110090603.AA07970@junior.rit.edu Subject: 3D graphics library To: glove-list@karazm.math.uh.edu Date: Wed, 9 Oct 91 2:14:56 EDT X-Mailer: ELM [version 2.3 PL8]

Lance Norskog mentioned:

You asked about 3D libraries. In uunet.uu.net:/usr/spool/ftp/graphics/vogle
there's a nice software-based clone of the SGI GL library, circa 1985.
It has 3D wire frame stuff, filled polygons, and vector fonts.
It has drivers for PC's, Suns, X windows, other workstations, and
PostScript (graphics commands, not bit maps). All public-domain.
I think I'll be rewriting the PC assembler video drivers into
386 assembler. It should howl.

(I'm really sorry about misspelling your last name a minute ago, Lance.)

Has anyone used this on the ST before? I'll be checking it out, but I'm mentioning it incase it needs porting and someone already has.

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From jdb9608@ultb.isc.rit.edu Tue Oct 8 23:42:27 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA10742

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 02:46:17 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA24537; Wed, 9 Oct 91 03:42:27 -0400

Date: Wed, 9 Oct 91 03:42:27 -0400 From: jdb9608@ultb.isc.rit.edu (J.D. Beutel) Message-Id: 9110090742.AA24537@ultb.isc.rit.edu To: glove-list@karazm.math.uh.edu Subject: vogle

I got the vogle 3D graphics library, and read its docs. It's supposed to be very similar to SGI's GL. Perhaps someone familiar with either could advise me.

I'm thinking of using it for virtual reality work with the glove. The library calls look just like CORE, which is an old standard I'm familiar with. Both are capable of 3D, but with CORE it translated the world coordinates to device coordinates immediately, which meant that every time you wanted to change perspective (i.e., move your point of view), you had to enter all the world coordinates again. That seemed real ugly for a world I may want to be flying thru. Does VOGLE require the same thing? CORE had one-level "segments", but not VOGLE's multi-level "objects" (which can call other objects). Does this make up for redrawing the world at every perspective change (e.g., define everything in terms of objects, define a root object containing every other object, and just redraw the root object each time you change perspective). Is this a nice way to do it? Is VOGLE quick enuf for real-time response?

Its source is available so I could try converting one of its many supported device drivers to one for the ST. It does double-buffering, which is probably good enuf in itself for shutter glasses. Quadruple-buffering would be needed for a head-mounted display with two screens, but since the source is there it shouldn't be too hard. It also supports a lot of hardware; that's very attractive. Does anyone have any comments on it?

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From giszter@ai.mit.edu Wed Oct 9 07:42:50 1991 Received: from life.ai.mit.edu by karazm.math.UH.EDU with SMTP id AA11688

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 10:47:15 -0500

Received: from cauda-equina (CAUDA-EQUINA.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12582; Wed, 9 Oct 91 11:43:13 EDT From: giszter@ai.mit.edu (Simon Giszter) Received: by cauda-equina (4.1/AI-4.10) id AA00432; Wed, 9 Oct 91 11:42:50 EDT Date: Wed, 9 Oct 91 11:42:50 EDT Message-Id: <9110091542.AA00432@cauda-equina> To: glove-list@karazm.math.uh.edu Subject: gloves supply

For those in NH: Toys Unlimited (toy surplus outlet) in Conway has L Power gloves bundled with SuperGlove Ball cartridges for $40.00 This was a good deal before the code was cracked or if you have a Nintendo. They also has NES infrared remotes and Sega stuff (but not the Head system) for cheap.

From squier@babbage.ecs.csus.edu Wed Oct 9 02:19:32 1991 Received: from babbage.ecs.csus.edu by karazm.math.UH.EDU with SMTP id AA11950

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 11:24:21 -0500

Received: by babbage.ecs.csus.edu (5.61/1.34)

id AA09435; Wed, 9 Oct 91 09:19:35 -0700

From: squier@babbage.ecs.csus.edu (Anthony Squier) Message-Id: 9110091619.AA09435@babbage.ecs.csus.edu Subject: HiRes To: glove-list@karazm.math.uh.edu Date: Wed, 9 Oct 91 9:19:32 PDT X-Mailer: ELM [version 2.3 PL0]

I'm not sure if this made it the first time, so I am trying again. Sorry if everyone gets it twice.

I am very interested in getting the timing diagrams from Manfred for the glove Hi-Res Mode. I am using the glove for part of a Master's Project(for the Amiga coding in C++) and would like to attempt to interface the glove via RS-232. I greatly apprecieate the work that Manfred Krauss has put into the glove. If I have success with the RS-232 interfacing I'll let everyone know. Also, what is the format of the data that is returned by the glove?

Tony… squier@babbage.ecs.csus.edu

From gbnewby@alexia.lis.uiuc.edu Wed Oct 9 06:17:07 1991 Received: from uxc.cso.uiuc.edu by karazm.math.UH.EDU with SMTP id AA11958

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 11:25:11 -0500

Received: from alexia.lis.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA00178

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 11:21:05 -0500

Received: by alexia.lis.uiuc.edu id AA11807

(5.61/ for glove-list@karazm.math.uh.edu); Wed, 9 Oct 91 11:17:07 -0500

Date: Wed, 9 Oct 91 11:17:07 -0500 From: Greg Newby gbnewby@alexia.lis.uiuc.edu Message-Id: 9110091617.AA11807@alexia.lis.uiuc.edu To: giszter@ai.mit.edu, glove-list@karazm.math.uh.edu Subject: Re: gloves supply Cc: gbnewby@alexia.lis.uiuc.edu

I tried to post a note earlier in the week, and it didn't get through. Now that the list is active again:

I phoned Mattel the other day. They say that they will be selling/ distributing the gloves (large only) for this christmas. So, if you don't have one and can't find one, you should be able to find one within the next few months. It sounded like they'd be pretty hard to find after December or January, though…

Update on the AGE box thing: Now I'm wondering if it's obsolete. It's not quite, because, among other things, the box can get data on demand, instead of in a stream. I'm not sure how sensitive the timing for the ST code will be when people port it to other platforms.

Anyway, I'm still battling the legal thing, to get an agreement w/ AGE and my employer. I'll take a final call for people interested when the time comes, should be (as usual) pretty soon. Thanks fo your patience.

Oh, while I'm rambling: standards for the glove drivers are a good idea. Once drivers get written for various platforms, real development can begin. – Greg

From dbarberi@mailbox.syr.edu Wed Oct 9 10:31:22 1991 Received: from mailbox.syr.EDU by karazm.math.UH.EDU with SMTP id AA12646

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 13:36:01 -0500

Received: from rodan.acs.syr.edu by mailbox.syr.edu (4.1/CNS)

id AA15265; Wed, 9 Oct 91 14:32:13 EDT

Received: by rodan.acs.syr.edu (4.1/Spike-2.0)

id AA21885; Wed, 9 Oct 91 14:31:24 EDT

Message-Id: 9110091831.AA21885@rodan.acs.syr.edu To: galt%peruvian@cs.utah.edu (Greg Alt) Cc: glove-list@karazm.math.uh.edu, dbarberi@mailbox.syr.edu Subject: Re: PC hires source In-Reply-To: Your message of "Tue, 08 Oct 91 21:50:49 MDT."

           <9110090350.AA04800@peruvian.utah.edu> 

Date: Wed, 09 Oct 91 14:31:22 -0400 From: dbarberi@mailbox.syr.edu

Greg Alt writes:

possibly better function names would be glove_init() and glove_sample() Also, the byte that I called "dum9" seems to be used to tell if the glove is not aimed at the receivers.


We use init_glove() and query_glove(), if we are comparing.  But I don't understand about the 'dum9'.. how does the glove know if it is not pointing to sensors?  I never knew it could do that.  Is that the same as receiving bad data?
David Barberi
Syracuse University Virtual Reality Lab

From jdb9608@cs.rit.edu Wed Oct 9 13:36:34 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA13401

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 16:38:30 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA14510; Wed, 9 Oct 91 17:34:34 -0400

Received: from chromium.CS (chromium.ARPA) by junior.rit.edu (4.1/5.17)

id AA10489; Wed, 9 Oct 91 17:24:08 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110092124.AA10489@junior.rit.edu Subject: Re: standard interface To: glove-list@karazm.math.uh.edu Date: Wed, 9 Oct 91 17:36:34 EDT X-Mailer: ELM [version 2.3 PL8]

I uploaded source code for a PC… I converted the ST code and fixed it up
a little.

Wonderful!

I was thinking, we should probably have a standard interface of
some sort so that our code will be relatively compatible. Here is my proposal:
typedef struct _glove_data {
unsigned char dum0;
signed char x,y,z;
unsigned char rot,fingers,keys,dum7,dum8,dum9,dumA,dumB;
} glove_data;

void Hires();
void getglove(glove_data *);


possibly better function names would be glove_init() and glove_sample()
Also, the byte that I called "dum9" seems to be used to tell if the glove
is not aimed at the receivers.

That sounds good to me. I would have favored the structure that already comes from the "black box", since it's already been around, but the data itself is exactly the same form so conversions should be trivial, and the "black box" has no specific structure defined (i.e., no names that I'm aware of). So, I'd say lets use these names. Should we define a whole .h file? (E.g., constants for the bits in keys, macros to mask and shift the two bits in fingers…) I hate to start a senseless meta-discusion, but I don't want to go to over-plan anything.

The other thing to start brainstorming about is
how to solve the problem of the 5 long pauses. Each one is 14 milliseconds,
so you waste 70 milliseconds per sample. Surely something useful could be
squeezed into that time somehow.

I'm trying to solve that on the ST by using an internal timer to generate an interrupt at the end of each long pause. An ISR would handle the protocol at each interrupt, and the CPU would be free to do other things in the mean time. Lately I've been talking about it more than trying it, but in theory I should get it working. I don't know if other computers have a similar capability, but probably they do.

So, for the sake of implementations that take this approach, I propose two more things:

void glove_pre(); /* call > 80 ms previous to glove_sample() */ int glove_pend; /* boolean flags glove data as pending */

The glove_pre() is a function which should be called 80 ms or more previous to glove_sample(). When the glove data is ready, the global glove_pend will be set = 0, and then glove_sample() may be called.

For implementations like mine, glove_pre() will start the protocol and set glove_pend = 1. When an ISR finishes the protocol, it will set glove_pend = 0, and glove_sample() will just be a dumby that copies the glove_data into the given structure.

For implementations using busy loops or external hardware (e.g., 68HC11), the glove_pre() will be a dumby function, glove_pend will always = 0, and glove_sample() will really go get the data each time.

This will allow people to write programs that work both ways. The code wouldn't be much more complicated than without glove_pre():

glove_data gd;

glove_init(); /* hi-res mode */ glove_pre(); /* start first sample if we need to */ while( 1) {

foo();			/* 80 ms worth of graphics stuff */
while( glove_pend);	/* wait if we need to */
glove_sample( &gd);	/* get the data (one way or the other) */
glove_pre();		/* start the next sample if we need to */

}

Also, shouldn't we allow glove_init(), glove_pre(), and glove_sample() to return error codes, at least for recognizable hardware errors?

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From motcsd!roi!lance@apple.com Sun Oct 9 10:23:38 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA14073

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 20:01:04 -0500

Received: by apple.com (5.61/1-Oct-1991-eef)

id AA15196; Wed, 9 Oct 91 17:37:13 -0700
for 

Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)

id <m0kUoFV-0001BsC@motcsd.csd.mot.com>; Wed, 9 Oct 91 17:27 PDT

Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)

id AA06559; 9 Oct 91 17:23:41 PDT (Wed)

To: glove-list@karazm.math.uh.edu, glove-list-request@karazm.math.UH.EDU Subject: Re: 3D graphics library Message-Id: 9110091723.AA06545@roi.ca41.csd.mot.com Date: 9 Oct 91 17:23:38 PDT (Wed) From: Lance Norskog lance@roi.ca41.csd.mot.com

I've seen a Mac port of vogle mentioned in the docs, but haven't seen it. There was no mention of amiga or ST support.

It would be pretty wimpy compared to the Amiga demos I've seen.

At $800 for a 4meg system (some ad I saw), an ST is attractive for a home toy. You can do some serious graphics in 4megs.

Lance Norskog

From motcsd!roi!lance@apple.com Sun Oct 9 10:19:45 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA14088

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 9 Oct 1991 20:06:54 -0500

Received: by apple.com (5.61/1-Oct-1991-eef)

id AA15140; Wed, 9 Oct 91 17:36:44 -0700
for 

Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)

id <m0kUoC0-0001CSC@motcsd.csd.mot.com>; Wed, 9 Oct 91 17:24 PDT

Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)

id AA06534; 9 Oct 91 17:19:45 PDT (Wed)

To: glove-list@karazm.math.uh.edu Subject: Re: vogle Message-Id: 9110091719.AA06530@roi.ca41.csd.mot.com Date: 9 Oct 91 17:19:45 PDT (Wed) From: Lance Norskog lance@roi.ca41.csd.mot.com

The VOGLE and VOGL libraries are on uunet.uu.net in /usr/spool/ftp/graphics/vogle. They're from an Australian university, and are copyright-but-free. They're a software version of SGI's GL core graphics library, written from scratch with drivers for lots of frame buffers: X windows, all PC adapters, a Mac version somewhere, Sun, Apollo, and postscript commands.

VOGLE is the main one. They were inspired to change a few things to make it exactly compatible with GL, and called that VOGL. If you want portability to SGI machines, stick with VOGL.

It has a lot of nifty calls, and an object data structure. Objects can have their own personal translation matrices. They can call other objects. All translations are applied to the current global matrix. Thus, a tree of objects can be defined, each with it's own matrix. You call the root object with a viewpoint and whatnot, and the resulting matrix bubbles down and each object is redrawn with its transform applied to it's inherited matrix; i.e. the parents matrix passed down on the matrix stack.

The source comes with a lot of demos, including how to use the polygon-filled fonts to draw on invisible planes criss-crossing the screen. It's fun, easy, and not a big mess like X windows.

Lance Norskog

From S.M.Clark@loughborough.ac.uk Thu Oct 10 08:39:25 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA16089

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 10 Oct 1991 08:39:25 -0500

Received: from loughborough.ac.uk by sun2.nsfnet-relay.ac.uk via JANET

        with NIFTP id <10276-0@sun2.nsfnet-relay.ac.uk>;
        Thu, 10 Oct 1991 12:25:14 +0100

Date: Thu, 10 Oct 91 12:25:19 bst Message-Id: 26893.9110101125@hpd.lut.ac.uk To: glove-list@karazm.math.uh.edu From: Sean Clark S.M.Clark@loughborough.ac.uk Subject: Hi-res for Mac?

All,

The 'discovery' of the hi-res mode for the glove is great news. Is anyone working on an interface for the Macintosh? I am considering converting the Joe Britt interface to handle hi-res data. Any other ideas?

Sean


Sean Clark, Tel: (0509) 263171x4166 ~~~~ LUTCHI Research Centre, Fax: (0509) 610815 ROCOCO Loughborough University, ~~~~ Leicstershire, LE11 3TU, UK Internet: S.M.Clark%lut.ac.uk@nsfnet-relay.ac.uk


From rparker@nike.calpoly.edu Thu Oct 10 01:51:33 1991 Received: from nike.calpoly.edu (demeter.calpoly.edu) by karazm.math.UH.EDU with SMTP id AA16451

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 10 Oct 1991 10:52:51 -0500

Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0)

id AA501206; Thu, 10 Oct 91 08:51:33 -0700

Date: Thu, 10 Oct 91 08:51:33 -0700 From: rparker@nike.calpoly.edu (Richard Parker) Message-Id: 9110101551.AA501206@nike.calpoly.edu To: glove-list@karazm.math.uh.edu Subject: Re: HiRes of for the Mac

Once I can get a glove and interface it to my mac se I will be trying to 

get the code together for LPC on the Mac. The only thing thats keeping me back, is this is not a cheap endevor. Rick

From rparker@nike.calpoly.edu Fri Oct 11 02:46:04 1991 Received: from nike.calpoly.edu (demeter.CalPoly.EDU) by karazm.math.UH.EDU with SMTP id AA22978

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 11 Oct 1991 11:47:22 -0500

Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0)

id AA516977; Fri, 11 Oct 91 09:46:04 -0700

Date: Fri, 11 Oct 91 09:46:04 -0700 From: rparker@nike.calpoly.edu (Richard Parker) Message-Id: 9110111646.AA516977@nike.calpoly.edu To: glove-list@karazm.math.uh.edu Subject: Re: LPC?

I can't believe I wrote that... sorry  I meant LSC (Lightspeed C 4.0 or later)

instead of LPC (a c variant for LP Muds ) See what sleep deprivation does to ya. The mac does have a parallel port along with 2 RS422 serial ports. Also a SCSI port which has the +5…. Maybe I could come up with a SCSI adapter for thething. I will try to look into it this weekend, and also get a glove now that payday has come around.

From jmunkki@hila.hut.fi Fri Oct 11 21:41:23 1991 Received: from hila.hut.fi by karazm.math.UH.EDU with SMTP id AA23172

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.UH.EDU>); Fri, 11 Oct 1991 12:45:17 -0500

Received: by hila.hut.fi (5.65c/7.0/S-TeKoLa)

id AA01040; Fri, 11 Oct 1991 19:41:23 +0200

Date: Fri, 11 Oct 1991 19:41:23 +0200 From: Juri Munkki jmunkki@hila.hut.fi Message-Id: 199110111741.AA01040@hila.hut.fi To: glove-list@karazm.math.UH.EDU Subject: Macintosh…

As far as I know, Macs do not have parallel ports. Of course it is possible to use a SCSI port as a parallel port, but it takes some logic and if you keep things simple, you have to forget about using a proper SCSI protocol.

The serial port should be quite adequate for the glove. The only problem is that there are only two serial ports. I already have a modem connected to the other and will soon have localtalk on the other. This still leaves the Sega 3D glasses and my audio sampler unconnected.

A 68HC11 board with a SCSI interface would probably be the optimal solution. I could connect the sega glasses and the powerglove to this hardware box. I assume that at least some versions of this processor have some EPROM and RAM, so the board would need a clock crystal, a SCSI-chip and a VIA. The 6522 VIA has a shift register that could easily be used to read the glove. The other I/O lines could be used to control the Sega glasses.

I know someone at Microsoft who has a small ADB box based on an Intel processor. I don't know how well his system works, but I do know that ADB provides +5V and it has some room for expansion.

 ____________________________________________________________________________
/ Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /

/ jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From motcsd!roi!lance@apple.com Tue Oct 11 04:06:18 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA23308

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 11 Oct 1991 13:32:45 -0500

Received: by apple.com (5.61/1-Oct-1991-eef)

id AA16222; Fri, 11 Oct 91 11:10:01 -0700
for 

Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)

id <m0kVRJq-0001C0C@motcsd.csd.mot.com>; Fri, 11 Oct 91 11:10 PDT

Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)

id AA17366; 11 Oct 91 11:06:19 PDT (Fri)

To: glove-list@karazm.math.uh.edu Subject: LPC? Message-Id: 9110111106.AA17362@roi.ca41.csd.mot.com Date: 11 Oct 91 11:06:18 PDT (Fri) From: Lance Norskog lance@roi.ca41.csd.mot.com

It also means Linear Predictive Coding, a data compression technique.

When you get a Power Glove, also hunt around for a soft cotton liner glove. The Glove is scratchy on the inside of the fingers. As for sensitivity to hard walls, I put the sensors on the floor and the carpet handles that problem. This also handles the problem of my arm getting tired.

Lance

From beeman@cats.UCSC.EDU Fri Oct 11 05:02:41 1991 Received: from cats.UCSC.EDU by karazm.math.UH.EDU with SMTP id AA23404

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 11 Oct 1991 14:07:09 -0500

Received: from am.UCSC.EDU by cats.UCSC.EDU with SMTP

id AA10581; Fri, 11 Oct 91 12:02:42 -0700

From: beeman@cats.UCSC.EDU Received: by am.ucsc.edu (5.65/4.7) id AA15568; Fri, 11 Oct 91 12:02:41 -0700 Date: Fri, 11 Oct 91 12:02:41 -0700 Message-Id: 9110111902.AA15568@am.ucsc.edu To: glove-list@karazm.math.uh.edu Subject: LPC!

Sleep deprivation produces miracles! Imagine being able to program objects in LPC on an LP-Mud with datagloves in mind! Of course, you would need to add graphics routines to the language, and you would need to change all the text output to graphic or audio output, and the resulting project would no doubt either swell up into several megs of code before there could even be two functional rooms…

Let me know if you are crazy enough to try this.

Adam

From S.M.Clark@loughborough.ac.uk Fri Oct 11 14:32:23 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA23475

(5.65c/IDA-1.4.4 for <glove-list@KARAZM.MATH.UH.edu>); Fri, 11 Oct 1991 14:32:23 -0500

Received: from loughborough.ac.uk by sun2.nsfnet-relay.ac.uk via JANET

        with NIFTP id <7608-2@sun2.nsfnet-relay.ac.uk>;
        Fri, 11 Oct 1991 12:11:30 +0100

Date: Fri, 11 Oct 91 10:35:24 bst Message-Id: 11277.9110110935@hpd.lut.ac.uk To: glove-list@KARAZM.MATH.UH.edu From: Sean Clark S.M.Clark@loughborough.ac.uk Subject: Hi-res for PC?

Hello,

I'm having problems in conecting to the EDU.UH.MATH.KARAZM FTP site. Could someone e-mail me a copy of the PC Hi-res code? This should keep me going until I can get a Mac version working!

Many thanks,

Sean


Sean Clark, Tel: (0509) 263171x4166 LUTCHI Research Centre, Fax: (0509) 610815 ROCOCO Loughborough University, Leicstershire, LE11 3TU, UK Internet: S.M.Clark%lut.ac.uk@nsfnet-relay.ac.uk


From MCARPENTER@HMCVAX.CLAREMONT.EDU Fri Oct 11 07:24:00 1991 Received: from FRIGGA.CLAREMONT.EDU by karazm.math.UH.EDU with SMTP id AA23795

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 11 Oct 1991 16:31:25 -0500

Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id 01GBMFNDMGIO9S3RO4@HMCVAX.CLAREMONT.EDU; Fri, 11 Oct 1991 14:24 PDT Date: Fri, 11 Oct 1991 14:24 PDT From: MATT CARPENTER MCARPENTER@HMCVAX.CLAREMONT.EDU Subject: Re: LPC! To: glove-list@karazm.math.uh.edu Message-Id: 01GBMFNDMGIO9S3RO4@HMCVAX.CLAREMONT.EDU X-Vms-To: IN%"glove-list@karazm.math.uh.edu"

In message 9110111902.AA15568@am.ucsc.edu beeman@cats.UCSC.EDU writes:

Sleep deprivation produces miracles! Imagine being able to program objects
in LPC on an LP-Mud with datagloves in mind! Of course, you would need to
add graphics routines to the language, and you would need to change all the
text output to graphic or audio output, and the resulting project would no
doubt either swell up into several megs of code before there could even be
two functional rooms…

Actually, I've been thinking about something like this for a while. If the user connects to the MUD from a personal computer, then the MUD wouldn't have to do much more than keep track of where the objects are (which is pretty much what they already do anyway, although it would also need to keep track of coordinates). All the graphics computations and stuff could be done by the user's computer. For instance, the MUD would just say something like "Object #1 has moved to x,y,z" and the user's computer, which already has the description data for object #1, generates the scene. Likewise, the user's computer translates the actions of the user (like moving a power glove around) into a similar form which is sent to the MUD. Of course this would all be rather crude, but it would be interesting to experiment with.

Let me know if you are crazy enough to try this.

Adam

Sure, I'm crazy enough. Anybody else interested, or have suggestions?

Matt

From nop@att1.Mankato.MSUS.EDU Fri Oct 11 11:28:11 1991 Received: from ATT1.Mankato.MSUS.EDU by karazm.math.UH.EDU with SMTP id AA23822

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.UH.EDU>); Fri, 11 Oct 1991 16:37:13 -0500

Received: by att1.Mankato.MSUS.EDU (5.59/25-eef)

id AA03981; Fri, 11 Oct 91 16:28:11 CDT

Date: Fri, 11 Oct 91 16:28:11 CDT From: Jay A. Carlson nop@att1.Mankato.MSUS.EDU Message-Id: 9110112128.AA03981@att1.Mankato.MSUS.EDU To: jmunkki@hila.hut.fi Cc: glove-list@karazm.math.UH.EDU In-Reply-To: Juri Munkki's message of Fri, 11 Oct 1991 19:41:23 +0200 199110111741.AA01040@hila.hut.fi Subject: Macintosh…

A 68HC11 board with a SCSI interface would probably be the optimal
solution. I could connect the sega glasses and the powerglove to this
hardware box. I assume that at least some versions of this processor
have some EPROM and RAM, so the board would need a clock crystal,
a SCSI-chip and a VIA. The 6522 VIA has a shift register that could
easily be used to read the glove. The other I/O lines could be used
to control the Sega glasses.

Unfortunately, the versions of the HC11 with EPROM instead of mask-programmed ROM are still quite pricey. If you plan on bringing out the bus to the SCSI chip anyway, hooking an external EPROM up is more cost-effective.

The HC11 also has a SPI, Serial Peripheral Interface, on-chip. It's a more general version of the shift register of the VIA. There also should be plenty of I/O lines on-chip left over to drive your glasses.

If we remove the VIA, the parts list is now an HC11, a crystal, a 2764, a latch and maybe a '138 to drive the bus, and the SCSI controller.

The same hardware, substituting an RS-232 line driver for the SCSI chip, could be used for a universal serial glove interface. I don't know that much about the Apple Desktop Bus, but I know that HC11 series chips live in some ADB devices. And finally, you can run data out the serial port at MIDI rates, making the hypothetical board of some interest to musical types.

I wonder how much demand there'd be for one of these boxes….

// Jay Carlson

\X/ nop@att1.mankato.msus.edu

To subscribe to the MC68HC11 list, email to mc68hc11-request@quack.sac.ca.us.

From awilliam@qucis.queensu.ca Sat Oct 12 09:29:27 1991 Received: from QUCDN.QueensU.CA by karazm.math.UH.EDU with SMTP id AA26299

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 12 Oct 1991 12:33:07 -0500

Received: from qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP V2R1) with TCP;

 Sat, 12 Oct 91 13:29:49 EDT

Received: from qusuna.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.1)

id AA18864; Sat, 12 Oct 91 13:29:30 EDT

From: awilliam@qucis.queensu.ca (Andrew Williams) Received: by qusuna.qucis.queensu.ca (4.1/SMI-4.0-qc1.1)

id AA06139; Sat, 12 Oct 91 13:29:27 EDT

Date: Sat, 12 Oct 91 13:29:27 EDT Message-Id: 9110121729.AA06139@qusuna.qucis.queensu.ca To: glove-list@karazm.math.uh.edu Subject: PC (386/486) version of Hires?

Reports that it has been placed on the archive are baffling me.. 'cause I can't seem to find it. (a very large and heartfelt *SIGH*)

If it is there can someone direct me.. if not can someone put it there OR E-mail me a copy of the source code?? (please .. PLEASE.. (thanks))

Andrew Williams (all suited up and the d*mn thing won't go!!)

From galt%peruvian@cs.utah.edu Sat Oct 12 16:40:41 1991 Received: from cs.utah.edu by karazm.math.UH.EDU with SMTP id AA27697

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 12 Oct 1991 23:44:36 -0500

Received: from peruvian.utah.edu by cs.utah.edu (5.65/utah-2.18-cs)

id AA22960; Sat, 12 Oct 91 22:40:42 -0600

Received: by peruvian.utah.edu (5.65/utah-2.12s-leaf)

id AA23053; Sat, 12 Oct 91 22:40:41 -0600

Date: Sat, 12 Oct 91 22:40:41 -0600 From: galt%peruvian@cs.utah.edu (Greg Alt) Message-Id: 9110130440.AA23053@peruvian.utah.edu To: glove-list@karazm.math.uh.edu Subject: simple code to get simple gestures

————- cut here for pwrglove.h —————- typedef struct _glove_data

  {
  signed char  dum0,x,y,z,rot,fingers,keys,dum7,dum8,dum9,dumA,dumB;
  } glove_data;

void init_glove (void); void query_glove (glove_data *); ————- end of pwrglove.h ———————- ————- cut here for fingers.c —————– #include <stdio.h> #include "pwrglove.h" #include "pwrglove.c"

#define F1(x) 1)

static char gesture[16][8]={

     "Open   ",
     "Dbl Gun",
     "0010   ",
     "Gun    ",
     "0100   ",
     "0101   ",
     "0110   ",
     "Thumb  ",
     "Three  ",
     "Dbl Pnt",
     "1010   ",
     "Point  ",
     "O.K.   ",
     "Birdie ",
     "1110   ",
     "Fist   "};

void main () {

glove_data   glov;
int          hand,dir;

init_glove();

while(1)
{
query_glove(&glov);
hand=HAND(glov.fingers);
printf("%s  (%x)  (%d,%d,%d)\n",
       gesture[hand],glov.rot,glov.x,glov.y,glov.z);
}

}

————- end of fingers.c ———————– I'm working on something that will strip some of the noise out of the positional data by possibly predicting movement. does anyone know if there are any books/papers that discuss a decent way of doing this without having a lag most of the time? My first goal is to make a game of rock/paper/scissors (once I get vogle up and running). Anyway, have fun with this code…

  Greg

From jdb9608@cs.rit.edu Sun Oct 13 12:34:51 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA29387

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 13 Oct 1991 15:35:31 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA12699; Sun, 13 Oct 91 16:31:30 -0400

Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17)

id AA22035; Sun, 13 Oct 91 16:20:46 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110132020.AA22035@junior.rit.edu Subject: Re: LPC! To: MCARPENTER@hmcvax.claremont.edu (MATT CARPENTER) Date: Sun, 13 Oct 91 16:34:51 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 01GBMFNDMGIO9S3RO4@HMCVAX.CLAREMONT.EDU; from "MATT CARPENTER" at Oct 11, 91 2:24 pm X-Mailer: ELM [version 2.3 PL8]

Sure, I'm crazy enough. Anybody else interested, or have suggestions?

I'm crazy enuf, too. That sounds like a really exciting approach to group communications and work environments, which has applications for reducing business travel (among other things). It was a MUD that got me interested in VR in the first place (altho it was text).

I have some experience with adventures, MUD's, and adventure languages. But, I don't have enuf. I.e., I don't feel like I know the perfect language to use, or the right combiniation of flexibility/power versus simplicity/usability for the user programming language within the MUD.

But, there are other people (somewhere) who may be interested in a project like this and have much more MUD programming experience, on both the system and user sides. Such a large part of this project would overlap the issues of a normal MUD, that we'd need people with lots of experience with MUD's.

The VR stuff would be fairly unknown to everyone, so that's okay, but I wouldn't want to stumble around making MUD mistakes that someone else could easily avoid.

So, are there MUD experts on this list?

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From crash!jester@nosc.mil Sun Oct 13 17:52:57 1991 Received: from trout.nosc.mil by karazm.math.UH.EDU with SMTP id AA29737

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 13 Oct 1991 17:52:57 -0500

Received: by trout.nosc.mil (5.59/1.27)

id AA13925; Sun, 13 Oct 91 15:49:02 PDT

Received: by crash.cts.com (/\==/\ Smail3.1.21.1 #21.3)

id <m0kWEN4-0000EeC@crash.cts.com>; Sun, 13 Oct 91 15:33 PDT

Message-Id: m0kWEN4-0000EeC@crash.cts.com From: jester@crash.cts.com (Ken Bibb) To: glove-list@karazm.math.uh.edu Subject: Muddy gloves Date: Sun Oct 13 15:33:18 1991

I'm not a MUD expert, but I've always been interested in implementing a real- time multi-user virtual reality dungeon. I've been involved with frp since 79 and had a campaign that lasted 7 years with a group of 14 players.

The important thing would be to provide the illusion–not to simulate–the experience. Too many programmers/researchers spend too much time trying to make microdetail simulations when crude simulations would be sufficient. I see the glove as a tool that could lead to some interesting games/work environments.

From kd4nc!km4ba!alan@gatech.edu Sun Oct 13 19:13:00 1991 Received: from gatech.edu by karazm.math.UH.EDU with SMTP id AA01176

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 13 Oct 1991 23:22:15 -0500

Received: from gatech.UUCP by gatech.edu (4.1/Gatech-9.1)

id AA26301 for glove-list@karazm.math.uh.edu.; Mon, 14 Oct 91 00:18:19 EDT

Received: from kd4nc.UUCP by gatech.UUCP (4.1/SMI-4.1)

id AA24860; Mon, 14 Oct 91 00:18:00 EDT

Received: by kd4nc (smail2.5)

id AA01256; 14 Oct 91 00:02:47 EDT (Mon)

Received: by km4ba.uucp (smail 3.1) id m0kWKbx-00000AC@km4ba.uucp; Sun, 13 Oct 91 23:13 EDT Message-Id: m0kWKbx-00000AC@km4ba.uucp Date: Sun, 13 Oct 91 23:13 EDT From: km4ba!alan@gatech.edu (Alan Barrow) To: km4ba!glove Subject: AGE kit under $50, sign me up!

I also would be interested in a "kit" of the AGE box. PC board and programmed micro would be fine, assuming no other unusual parts.

BTW, Walmart stores have large quan. of gloves (L) for $24.95 as well.

I may buy another!

I guess I need to dig up the old BYTE to wire mine up for the PC. Has the schematic been posted yet? If someone will fax it to me, I will try to make it available in PS, gif, etc format. (Assuming this has not been done by others.) Fax: 404/850-2703

See Ya!

Alan Barrow km4ba | I've seen things you people wouldn't believe. Attack jab@hpuerca.hp.com | ships on fire off the shoulder of Orion. I watched

                  | C-beams glitter in the dark near the Tannhauser gate.

..!gatech!kd4nc! | All those moments will be lost in time -

       km4ba!alan | like tears in rain. Time to die.          Roy Batty

From kovach%rtc.atk.com%nic@rtc.atk.com Mon Oct 14 04:07:30 1991 Received: from nic.rtc.atk.com (rtc.atk.com) by karazm.math.UH.EDU with SMTP id AA02729

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 09:11:46 -0500

Received: from hayward.rtc.atk.com ([138.64.16.55]) by nic with SMTP id <46119>; Mon, 14 Oct 1991 09:07:38 -0500 Received: by hayward.rtc.atk.com (4.1/SMI-4.1/RTC-1.1)

id AA02532; Mon, 14 Oct 91 08:59:04 CDT

From: kovach@rtc.atk.com To: jester@crash.cts.com Cc: glove-list@karazm.math.uh.edu In-Reply-To: Ken Bibb's message of Sun, 13 Oct 1991 10:33:18 -0500 m0kWEN4-0000EeC@crash.cts.com Subject: Muddy gloves Message-Id: <91Oct14.090738cdt.46119@nic> Date: Mon, 14 Oct 1991 09:07:30 -0500

Ken Bibb writes -

I'm not a MUD expert, but I've always been interested in implementing a real-
time multi-user virtual reality dungeon. I've been involved with frp since
79 and had a campaign that lasted 7 years with a group of 14 players.

Well, I've been into FRP since '72. Published and everything. :→

The important thing would be to provide the illusion–not to simulate–the
experience. Too many programmers/researchers spend too much time trying to
make microdetail simulations when crude simulations would be sufficient. I
see the glove as a tool that could lead to some interesting games/work
environments.

Got to agree. I`ve been looking at a glove based "sword" interface to a dungeon for quite a while. Multiplayer through computer networking/modem is a definite goal.

What we need is a group of folks in a small eough geographic area to get together and develop something. Considering how I've seen people jump as critters step around corners while playing a game like Dungeon Master, I can imagine this type game would be quite popular and addictive. I've just always been to busy to do it myself:→

From rparker@nike.calpoly.edu Mon Oct 14 02:18:05 1991 Received: from nike.calpoly.edu (demeter.CalPoly.EDU) by karazm.math.UH.EDU with SMTP id AA03267

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 11:19:26 -0500

Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0)

id AA510569; Mon, 14 Oct 91 09:18:05 -0700

Date: Mon, 14 Oct 91 09:18:05 -0700 From: rparker@nike.calpoly.edu (Richard Parker) Message-Id: 9110141618.AA510569@nike.calpoly.edu To: glove-list@karazm.math.uh.edu Subject: Re: Muddy Gloves (was VR and MUDS)

My senior project is a Mud system with 3-d rendering graphics.  Right now

I am just woried about cursor and key movements, but the next logical step is glove interface. Thats why I want to get a mac interface up and running so I can start working on it.

Just a note, there are some people that would hate a glove interface, same

as hating maouse input, as they feel it detracts their attention from the game and it takes too long ("I could do several keystrokes faster than what this is doing …. " is a common quote) So, if you come up with something, that will be very nice, you might want to incorporate keys too. (You could use it for debugging, so it wouldn't be a total waste. And hopefully, these archaic types will catch up with the real world and start using alternate input devices. Rick

From motcsd!roi!lance@apple.com Fri Oct 14 04:11:36 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA04334

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 13:36:59 -0500

Received: by apple.com (5.61/1-Oct-1991-eef)

id AA09655; Mon, 14 Oct 91 11:21:44 -0700
for 

Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)

id <m0kWWnB-0001C1C@motcsd.csd.mot.com>; Mon, 14 Oct 91 11:13 PDT

Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)

id AA08572; 14 Oct 91 11:11:36 PDT (Mon)

To: galt%peruvian@cs.utah.edu Subject: Re: simple code to get simple gestures Cc: glove-list@karazm.math.uh.edu Message-Id: 9110141111.AA08568@roi.ca41.csd.mot.com Date: 14 Oct 91 11:11:36 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com

Yes, Fred Brooks of the Pixel-Planes project said that predictive tracking should work best.

Graphics Gems II has a thing on predictive coding as compression technique. Here's the idea: you have a state machine which reads a sample stream and guesses the next sample, and output the difference between your guess and the actual sample. This should give you lots of samples with low values, suitable for Huffman or dictionary compression. I've been itching to try this on sound samples. The article does it on pictures, and shows the error output as a separate picture. It's an excellent demonstration of the principle.

A first attempt would track the slope of the last few samples, thus extending the first derivative out. If you assume that the input stream is delayed by X milliseconds, and it samples at half your update rate, you can create a separate one-dimensional tracker for each of (X, Y, Z, rot) and do a better job than drawing from raw input. You can also reject weird inputs, and average noisy ones.

If you move your hand fast and then stop, the predictive tracking will overshoot and come back to the resting place. Cest la vie.

I'd say it's time to sample movements, run the output through a statistics package, and figure out just what kind of error you need to deal with.

Lance Norskog

From jet Mon Oct 14 09:07:07 1991 Received: by karazm.math.UH.EDU id AA04448

(5.65c/IDA-1.4.4 for glove-list); Mon, 14 Oct 1991 14:07:08 -0500

From: J Eric Townsend <jet> Message-Id: 199110141907.AA04448@karazm.math.UH.EDU Subject: move to a newsgroup? To: glove-list Date: Mon, 14 Oct 91 14:07:07 CDT X-Mailer: ELM [version 2.3 PL11]

Any reason why this list shouldn't become a newsgroup? I'm more than willing to keep karazm as the ftp site for glove related sources..

I was thinking

comp.periphs.glove – since datagloves will fall in price over the

	      next few years.

Or perhaps: alt.power-glove – to test the waters and see what the response is like.

– J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu

From rparker@nike.calpoly.edu Mon Oct 14 06:07:50 1991 Received: from nike.calpoly.edu (demeter.CalPoly.EDU) by karazm.math.UH.EDU with SMTP id AA04894

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 15:09:11 -0500

Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0)

id AA514151; Mon, 14 Oct 91 13:07:50 -0700

Date: Mon, 14 Oct 91 13:07:50 -0700 From: rparker@nike.calpoly.edu (Richard Parker) Message-Id: 9110142007.AA514151@nike.calpoly.edu To: glove-list@karazm.math.uh.edu Subject: Re: Newsgroup

The idea of putting this into a newsgroup sounds like a good idea.  We would

get more input from people that don't know about the group, and possibly some different opinions. The name that sounds best so far is the comp.periph.glove as it stresses the technical aspect of the glove as an alternate input device vs. a game toy interface.

From jet Mon Oct 14 10:49:40 1991 Received: by karazm.math.UH.EDU id AA05027

(5.65c/IDA-1.4.4 for glove-list); Mon, 14 Oct 1991 15:49:40 -0500

From: J Eric Townsend <jet> Message-Id: 199110142049.AA05027@karazm.math.UH.EDU Subject: Re: Newsgroup To: glove-list Date: Mon, 14 Oct 91 15:49:40 CDT X-Mailer: ELM [version 2.3 PL11]

From: rparker@nike.calpoly.edu (Richard Parker)

The idea of putting this into a newsgroup sounds like a good idea. We would
get more input from people that don't know about the group, and possibly some
different opinions. The name that sounds best so far is the comp.periph.glove
as it stresses the technical aspect of the glove as an alternate input device
vs. a game toy interface.

– J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu

From jdb9608@cs.rit.edu Mon Oct 14 13:06:40 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA05146

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 16:09:42 -0500

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS))

id AA09776; Mon, 14 Oct 91 17:05:43 -0400

Received: from calcium.CS (calcium.ARPA) by junior.rit.edu (4.1/5.17)

id AA26349; Mon, 14 Oct 91 16:54:56 EDT

From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110142054.AA26349@junior.rit.edu Subject: Re: Newsgroup To: glove-list@karazm.math.uh.edu Date: Mon, 14 Oct 91 17:06:40 EDT X-Mailer: ELM [version 2.3 PL8]

It's a good idea to make the glove-list a newsgroup, depending on how many subscribers there are. How many are there?

Also, how about a mailing list or newsgroup for low-end VR? Sci.virtual-worlds doesn't seem appropriate for the noise that various colaborative efforts would require—it seems more for the high-end researchers who work on exotic machines and don't publish code. But, the glove-list doesn't seem right either, since many other issues besides the glove are involved.

– J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

From jet Mon Oct 14 11:33:30 1991 Received: by karazm.math.UH.EDU id AA05396

(5.65c/IDA-1.4.4 for glove-list); Mon, 14 Oct 1991 16:33:31 -0500

From: J Eric Townsend <jet> Message-Id: 199110142133.AA05396@karazm.math.UH.EDU Subject: re: newsgroup To: glove-list Date: Mon, 14 Oct 91 16:33:30 CDT X-Mailer: ELM [version 2.3 PL11]

It's a good idea to make the glove-list a newsgroup,
depending on how many subscribers there are. How many are there?

$ wc -l vr/glove-list/list 294 vr/glove-list/list

Almost 300, it would seem.

– J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from Apple press release

From gbnewby@alexia.lis.uiuc.edu Mon Oct 14 12:14:42 1991 Received: from alexia.lis.uiuc.edu by karazm.math.UH.EDU with SMTP id AA05803

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 17:18:56 -0500

Received: by alexia.lis.uiuc.edu id AA02728

(5.61/ for glove-list@karazm.math.uh.edu); Mon, 14 Oct 91 17:14:42 -0500

Date: Mon, 14 Oct 91 17:14:42 -0500 From: Greg Newby gbnewby@alexia.lis.uiuc.edu Message-Id: 9110142214.AA02728@alexia.lis.uiuc.edu To: glove-list@karazm.math.uh.edu, rparker@nike.calpoly.edu Subject: Re: Newsgroup Cc: gbnewby@alexia.lis.uiuc.edu

Hi, all. In order to form a non-alt group (one in the comp. hierarchy, for example), you need to take a vote. This is a fairly well-defined process, in which initial feedback and support is solicited.

Someone would have to volunteer for this (sorry, not me), keep track of votes, and then institute the group. I don't have the file containing details – I think news.admin or something like that has a FAQ on this topic. – Greg

From dstamp@watserv1.uwaterloo.ca Mon Oct 14 14:35:47 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA06017

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 17:41:36 -0500

Received: by watserv1.uwaterloo.ca

id <AA18567>; Mon, 14 Oct 91 18:35:47 -0400

Date: Mon, 14 Oct 91 18:35:47 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110142235.AA18567@watserv1.uwaterloo.ca To: galt%peruvian@cs.utah.edu, lance@roi.ca41.csd.mot.com Subject: Re: simple code to get simple gestures Cc: glove-list@karazm.math.uh.edu

From glove-list-request@karazm.math.UH.EDU Mon Oct 14 15:44:19 1991
To: galt%peruvian@cs.utah.edu
Subject: Re: simple code to get simple gestures
Cc: glove-list@karazm.math.uh.edu
From: Lance Norskog lance@roi.ca41.csd.mot.com


Yes, Fred Brooks of the Pixel-Planes project said that predictive
tracking should work best.

Graphics Gems II has a thing on predictive coding as compression technique.
Here's the idea: you have a state machine which reads a sample stream and
guesses the next sample, and output the difference between your guess
and the actual sample. This should give you lots of samples with low
values, suitable for Huffman or dictionary compression. I've been
itching to try this on sound samples. The article does it on pictures,
and shows the error output as a separate picture. It's an excellent
demonstration of the principle.

A first attempt would track the slope of the last few samples, thus
extending the first derivative out. If you assume that the input
stream is delayed by X milliseconds, and it samples at half your
update rate, you can create a separate one-dimensional tracker
for each of (X, Y, Z, rot) and do a better job than drawing
from raw input. You can also reject weird inputs, and average
noisy ones.

If you move your hand fast and then stop, the predictive tracking
will overshoot and come back to the resting place. Cest la vie.

I'd say it's time to sample movements, run the output through
a statistics package, and figure out just what kind of error
you need to deal with.

Lance Norskog

Sounds like a Kalman predictive filter. The question is, how much will the overshoots affect operator performance? If you're going to develop the code for such a filter, I hope you make several versions, using different delays. This would allow users to match the filter to their own system's video display, rendering and processing times. Isuggest multiples of 33 mS. Also, it would be interesting to set up a simple system using a "bar" cursor or other easy-to-draw symbol, and try out the effect of changing the filter coefficients. After all, we're getting into psychophysics here, and that is *not* an easy field to predict. I've noticed weird "viscous" effects using head-position to cursor feedback with a system delay of 50 mS or less. Addition of hysterisis of 1/6 visual degree stopped that, and reduced noise, but at the cost of some of the "reality" feel of the system. It's amazing how little it takes to make such feedback feel like a "tool" rather than an extension of the body.

Dave Stampe

From motcsd!roi!lance@apple.com Fri Oct 14 10:15:36 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA06436

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 19:40:02 -0500

Received: by apple.com (5.61/1-Oct-1991-eef)

id AA25749; Mon, 14 Oct 91 17:21:03 -0700
for 

Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)

id <m0kWcTV-0001BVC@motcsd.csd.mot.com>; Mon, 14 Oct 91 17:17 PDT

Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)

id AA12566; 14 Oct 91 17:15:40 PDT (Mon)

To: galt%peruvian@cs.utah.edu, lance@roi.ca41.csd.mot.com,

      dstamp@watserv1.uwaterloo.ca

Subject: Re: simple code to get simple gestures Cc: glove-list@karazm.math.uh.edu Message-Id: 9110141715.AA12550@roi.ca41.csd.mot.com Date: 14 Oct 91 17:15:36 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com

> 
Sounds like a Kalman predictive filter.  The question is, how much will
the overshoots affect operator performance?
If you're going to develop the code for such a filter, I hope you make
several versions, using different delays.  This would allow users to
match the filter to their own system's video display, rendering and
processing times.  Isuggest multiples of 33 mS.
Also, it would be interesting to set up a simple system using a "bar"
cursor or other easy-to-draw symbol, and try out the effect of changing
the filter coefficients.  After all, we're getting into psychophysics
here, and that is *not* an easy field to predict.  I've noticed weird
"viscous" effects using head-position to cursor feedback with a system
delay of 50 mS or less.  Addition of hysterisis of 1/6 visual degree
stopped that, and reduced noise, but at the cost of some of the 
"reality" feel of the system.  It's amazing how little it takes to 
make such feedback feel like a "tool" rather than an extension of
the body.

Sounds like you know what you're talking about and I don't.

Yes, this needs a lot of experimentation, and preferably a menu and calibration system. I don't believe in canned software. "I know what you need. Trust me!"

References, please? Should I look for books by Kalman at the Stanford CS library? References in CACM year-end indices?

Thanks,

Lance Norskog

From dstamp@watserv1.uwaterloo.ca Mon Oct 14 17:58:04 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA06855

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 21:05:44 -0500

Received: by watserv1.uwaterloo.ca

id <AA23815>; Mon, 14 Oct 91 21:58:04 -0400

Date: Mon, 14 Oct 91 21:58:04 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110150158.AA23815@watserv1.uwaterloo.ca To: dstamp@watserv1.uwaterloo.ca, galt%peruvian@cs.utah.edu,

      lance@roi.ca41.csd.mot.com

Subject: Re: simple code to get simple gestures Cc: glove-list@karazm.math.uh.edu

A "Kalman filter" refers to any of a class of predictive filters. The simplest predictive filter is just a "highpass" type. What I gather from your talk of "states" is that you are referring to a "state-variable" type of filter.

OK, enough of the technical terms. Basically, what you need to do is to look up some signal-processing or control textbooks. Alternatively, there should be some software available to generate your filter code given delays, etc.

Now the bad news. This type of filter will always have overshoots and delays at any change of velocity of the glove. This means that the image of the glove will play catch-up when motion starts, and will continue moving after motion ceases, then go backwars to correct itself. This can be disconcerting to the user!

The predictive filters also tend to increse noise in position. The "jitter" in the hi-res mode (if it is just a quick jump to the wrong position and back) can be removed at the cost of more delay– just add a glitch detector to the glove data output. Alternatively, the derivative or highpass terms of the predictive filter can be limited, but this might cause weird effects during fast motions.

From what I've read about flight simulators, the best way to find the correct filter coefficients is to compute them as usual, then get into an interactive program (using the glove to move a cursor), and test the "feel" of the system. Try several different sets of coefficients, then use the intuition you'll develop to tweak the program.

Hope you can find some references that are more CS based, or sample code. All the stuff I have assumes familiarity with Laplace transforms and other scary stuff (typical engineering overkill).

Dave Stampe

From giszter@ai.mit.edu Mon Oct 14 19:07:26 1991 Received: from life.ai.mit.edu by karazm.math.UH.EDU with SMTP id AA07093

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 14 Oct 1991 22:12:01 -0500

Received: from cauda-equina (CAUDA-EQUINA.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA19676; Mon, 14 Oct 91 23:07:38 EDT From: giszter@ai.mit.edu (Simon Giszter) Received: by cauda-equina (4.1/AI-4.10) id AA02969; Mon, 14 Oct 91 23:07:26 EDT Date: Mon, 14 Oct 91 23:07:26 EDT Message-Id: <9110150307.AA02969@cauda-equina> To: glove-list@karazm.math.uh.edu Subject: PC Hi Res Cc: giszter@ai.mit.edu

I played with the Hi Res mode on a 25MHz 386 tonight. I found much of the jitter in values disappeared when I added in a small delay in the readbit macro.

namely:

#define readbit(x) for(i=0;i<5;i++); rd=inportb(0x379); …

I still couldn't push the thing beyond the 4/21 for constants N & D which Greg Alt found. It was actually most stable a little below that speed (i.e. the dummy values were all stable). I didn't have obvious echo problems unless I shielded the glove with my hand. If your glove is skittish it may help to add this delay.

ciao, Simon

From paulg@tplrd.tpl.oz.AU Tue Oct 15 19:49:41 1991 Received: from metro.ucc.su.OZ.AU by karazm.math.UH.EDU with SMTP id AA07603

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Tue, 15 Oct 1991 00:20:57 -0500

Received: by metro.ucc.su.OZ.AU (5.61/1.34)

id AA11324; Tue, 15 Oct 1991 15:16:21 +1000

Received: by tpl68k0 (5.51/2.27); id AA21792; Tue, 15 Oct 91 09:48:52 EST From: paulg@tplrd.tpl.oz.au (Paul Gittings) Message-Id: <9110142348.AA21792@tpl68k0> Received: from loopback by sydrd15 (4.1/2.14); id AA23086; Tue, 15 Oct 91 09:49:43 EST To: glove-list@karazm.math.UH.EDU Subject: RE: move to a newsgroup? Date: Tue, 15 Oct 91 09:49:41 +1000

——- Forwarded Message

Or perhaps:
alt.power-glove – to test the waters and see what the response is like.

A newsgroup may be a good idea, but please don't make it an "alt" group this site does not receive any of the "alt" groups. Maybe the group should be a bit more general to cover things like: head mounted tracking devices, sega specs etc??

Cheers, Paul Gittings Telectronics Pacing Systems - 7 Sirius Rd, Lane Cove, NSW 2066, Australia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 _              | paulg@tplrd.tpl.oz.au     | What's a Welsh/Canadian

_ Amiga users | 61-2-4136963 (voice: work)| doing in Oz? Looking for \X/ make it happen| 61-2-4136868 (fax) | the Wizard of course! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No matter how much I beg, Telectronics will not allow me to express any opinions on its behalf. From "Marshall_Robin"@NESTOR10.ceo.dg.com Tue Oct 15 07:40:14 1991 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by karazm.math.UH.EDU with SMTP id AA08965 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 10:55:13 -0500 Received: from rtp40.rtp.dg.com by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA10380; Tue, 15 Oct 1991 11:51:09 -0400 Received: by rtp40.dg.com (1.00/2.1) id AC00033; Tue, 15 Oct 91 11:40:14 edt Date: Tue, 15 Oct 91 11:40:14 edt Message-Id: 9110151640.AC00033@rtp40.dg.com From: Marshall_Robin@CEO_SWD.ceo.dg.com To: glove-list@karazm.math.uh.edu Subject: CHEAP source of gloves in Central MA area X-Ceo_Options: Short_message Anyone know where I can get a PowerGlove in the central MA area for around $25 (the price it is at Wal-Mart)? Thanks… -marsh From schildba@spot.Colorado.EDU Tue Oct 15 05:26:04 1991 Received: from spot.Colorado.EDU by karazm.math.UH.EDU with SMTP id AA09295 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 12:30:01 -0500 Received: by spot.Colorado.EDU id AA24142 (5.65b+/IDA-1.4.3/CNS-2.0 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 91 11:26:04 -0600 Date: Tue, 15 Oct 91 11:26:04 -0600 From: SCHILDBACH WOLFGANG schildba@spot.Colorado.EDU Message-Id: 9110151726.AA24142@spot.Colorado.EDU To: glove-list@karazm.math.uh.edu Subject: LPC vs. polynomial predicting Is it really a good idea to use Linear Predictive Coding for the glove? From what I understand LPC works with fourier coefficients of the data given, or, in other words, it tries to model the data as a sum of sines and cosines. Now I would guess that most movements you make are not sinu- soidal but rather polynomial (i.e. the velocity should go like a parabola). (Of course, some research has to be done at that, but it shouldn't be to hard for those of you who have gloves to write a little hack that records your glove movements on time and display this data.) Now if the velocity is mainly polynomial, wouldn't it be better to model it as a polynomial? For references on Kalman filters, LPC etc. try Teukolsky, Vetterling, Press, Flannery: Numerical Recipes in (C|FORTRAN|PASCAL) which is technical (the matter is, after all) but easy to understand. It contains a lot of sources that might help. For filtering the glove output, I would suggest what I would call a "plausibility filter": If the (pos,vel) measurement at time 0 is (x0,v0) and time t is x1, solve x1=x0+v0 t+1/2 a t^2 for a (the acceleration) and check if it gives a reasonable value. If not, reject the measurement and predict it in- stead. Ciao Wolfgang From jdb9608@cs.rit.edu Tue Oct 15 08:28:34 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA09315 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 12:39:09 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA20933; Tue, 15 Oct 91 12:25:04 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA28947; Tue, 15 Oct 91 12:14:13 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110151614.AA28947@junior.rit.edu Subject: Re: Newsgroup To: glove-list@karazm.math.uh.edu Date: Tue, 15 Oct 91 12:28:34 EDT X-Mailer: ELM [version 2.3 PL8] Greg's right; there are well-established procedures for normal hiearchy newsgroups. So, a comp. group would take some time to make (something like a week of discussion period plus a month of voting period, or more). An alt. group takes no time to make, because there are no such rules for them, but not everyone can get the alt. groups. We get the alt. groups here. Is there anyone who can't get them? If not, an alt. group could be made right away, and then after the appropriate procedures are followed it could move to a comp. group. Eric, do you have software that will automatically gateway between a newsgroup and a mailing list? I haven't seen any, but I'm sure it exists. Would that be defeating the point of making it a newsgroup? – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From motcsd!roi!lance@apple.com Sat Oct 15 03:26:01 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA09377 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 12:55:06 -0500 Received: by apple.com (5.61/1-Oct-1991-eef) id AA06533; Tue, 15 Oct 91 10:34:05 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kWsYq-0001BkC@motcsd.csd.mot.com; Tue, 15 Oct 91 10:28 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA17786; 15 Oct 91 10:26:01 PDT (Tue) To: giszter@ai.mit.edu, glove-list@karazm.math.uh.edu Subject: Re: PC Hi Res Message-Id: 9110151026.AA17781@roi.ca41.csd.mot.com Date: 15 Oct 91 10:26:01 PDT (Tue) From: Lance Norskog lance@roi.ca41.csd.mot.com > I played with the Hi Res mode on a 25MHz 386 tonight. I found much of the > jitter in values disappeared when I added in a small delay in the > readbit macro. Yes, the PC parallel port has data input lines and control input lines. The data input lines are, in fact, 2-way, and they have some settling time. The control input lines are one-way, and are faster. Lance Norskog From jdb9608@cs.rit.edu Tue Oct 15 10:14:51 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA09477 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 13:15:21 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA24521; Tue, 15 Oct 91 14:11:22 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA29369; Tue, 15 Oct 91 14:00:29 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110151800.AA29369@junior.rit.edu Subject: sega glasses available? To: glove-list@karazm.math.uh.edu Date: Tue, 15 Oct 91 14:14:51 EDT X-Mailer: ELM [version 2.3 PL8] Does anyone know where Sega 3D glasses are available (and $)? (Or another type, I guess, and cost?) – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From motcsd!roi!lance@apple.com Sat Oct 15 03:53:17 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA09475 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 13:15:13 -0500 Received: by apple.com (5.61/1-Oct-1991-eef) id AA10508; Tue, 15 Oct 91 10:59:42 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kWszJ-0000poC@motcsd.csd.mot.com; Tue, 15 Oct 91 10:55 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA18005; 15 Oct 91 10:53:18 PDT (Tue) To: dstamp@watserv1.uwaterloo.ca, galt%peruvian@cs.utah.edu Subject: Re: simple code to get simple gestures Cc: glove-list@karazm.math.uh.edu Message-Id: 9110151053.AA18001@roi.ca41.csd.mot.com Date: 15 Oct 91 10:53:17 PDT (Tue) From: Lance Norskog lance@roi.ca41.csd.mot.com Now the bad news. This type of filter will always have overshoots and delays at any change of velocity of the glove. This means that the image of the glove will play catch-up when motion starts, and will continue moving after motion ceases, then go backwars to correct itself. This can be disconcerting to the user! This follows the signal-processing paradigm. An extensions of the mouse-cursor paradigm is another possibility. If you're willing to forgo the direct mapping concept, prediction from the glove inputs can just "push" a 3D position around. Changes in direction and speed can be handled as special cases to avoid the overshoot/correction effect. Being 31 (as of this weekend) instead of 12 years old, I don't plan to hold my hand up to the screen for several hours at a time anyway. I've been testing with the sensors arranged on the floor and letting my hand hang down. I don't see that I need direct mapping to use the glove in this mode, and so the 3D-cursor-pushing scheme should work fine. Lance Norskog From aaronp@narrator.pen.tek.com Tue Oct 15 04:33:36 1991 Received: from relay.tek.com by karazm.math.UH.EDU with SMTP id AA09588 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 13:43:54 -0500 Received: by relay.tek.com id AA02013@relay.tek.com; Tue, 15 Oct 91 11:33:40 -0700 Received: from tekig7.map.tek.com by tektronix.TEK.COM (4.1/7.1) id AA18129; Tue, 15 Oct 91 11:33:18 PDT Received: from narrator.PEN.TEK.COM (narrator.TEK) by tekig7.map.tek.com (4.1/7.1) id AA25497; Tue, 15 Oct 91 11:33:36 PDT Received: by narrator.PEN.TEK.COM (4.1/7.1) id AA01622; Tue, 15 Oct 91 11:33:36 PDT Date: Tue, 15 Oct 91 11:33:36 PDT From: aaronp@narrator.pen.tek.com (Aaron Pulkka) Message-Id: 9110151833.AA01622@narrator.PEN.TEK.COM To: glove-list@karazm.math.uh.edu Subject: Low-end VR Newsgroup (was Re: move to a newsgroup?) If this list truly has about 300 participants, I think now is a reasonable time to consider moving to a newsgroup. If this list does move to a newsgroup, I suggest that its scope be expanded to include all types of low-end (read: cheap) VR solutions. From reading resent submissions on this topic I get the impression that there are others who agree with this approach. Now comes the tough part: What should the newsgroup be named and who will organize its creation? I suggest that the newsgroup should not be part of the 'alt' hierarchy, since many sites don't carry it; either the 'comp' or 'sci' hierarchy would work. If the discussions are only going to be about peripherals like the power glove and the Sega glasses, then it would make sense to tag onto the end of 'comp.periphs' (something like 'comp.periphs.virtual')If people want to also talk about rendering 3-D graphics or creating 3-D sound with a PC, then 'periphs' wouldn't be quite as appropriate (maybe 'comp.sys.virtual' or 'sci.virtual-worlds.low-end'). Can anyone think of a more flattering tag then 'low-end'? I would be willing to administrate the Call For Votes if there is some kind of consensus about what the scope and name of the newsgroup should be. Another question comes to mind…should the newsgroup be moderated? The answer to that is usually "yes it should, but no one wants to do it." I might be willing to moderate such a group as well (depending mainly on what the scope will be). Please e-mail me (or this list, if you prefer) any ideas or suggestions about the scope and name of this proposed newsgroup. Consider these names: comp.periphs.glove (previously proposed to discuss only the glove) comp.periphs.virtual comp.sys.virtual sci.virtual-worlds.low-end +————–\ | Aaron Pulkka > aaronp@narrator.PEN.TEK.COM +————–/ "when there is no answer, we are free to think." – 1991 Portland Creative Conference From dstamp@watserv1.uwaterloo.ca Tue Oct 15 10:47:19 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA09615 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 13:51:31 -0500 Received: by watserv1.uwaterloo.ca id <AA05571>; Tue, 15 Oct 91 14:47:19 -0400 Date: Tue, 15 Oct 91 14:47:19 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110151847.AA05571@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, schildba@spot.Colorado.EDU Subject: Re: LPC vs. polynomial predicting I think one of the problems with ANY predictive filtering of the poer glove is going to be the sparseness of the data (that is, the wide spacing of the samples). These methods work best with finer data. BTW, an idea about speeding the glove's readout: from my fooling around, the glove's computer reads the receivers after pulsing the two transmitters (20 mS each) then reads the fingers with an RC circuit and comparator for each finger. This takes the remaining 35 mS of the 75 mS glove cycle: in fact, when you bend the fingers, you can *hear* the transmitter's click rate change, showing that the finger read cycle gets shorter. SO: why not "hardwire" the finger sensor RC circuits low (or high, I forget which) and cut 35 mS off the sample period? An external A/D converter could read the finger positions with at least 4 bits of precision. Of course, there are obvious disadvantages here, but it might push the sample rate up to 25 Hz, which is much better than the current 13.3 Hz -Dave Stampe From brownp@dg-rtp.dg.com Tue Oct 15 10:34:54 1991 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by karazm.math.UH.EDU with SMTP id AA09703 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 14:07:08 -0500 Received: from stuff.rtp.dg.com by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA25398; Tue, 15 Oct 1991 14:36:07 -0400 Received: by stuff (5.4/rtp-s04) id AA05236; Tue, 15 Oct 1991 14:34:55 -0400 From: brownp@dg-rtp.dg.com (Peter Brown) Message-Id: <9110151834.AA05236@stuff> Subject: sega glasses available? (fwd) To: glove-list@karazm.math.uh.edu Date: Tue, 15 Oct 91 14:34:54 EDT X-Mailer: ELM [version 2.3 PL11] Please tell me too! I've been loking around, but no luck yet. I think I remember someone saying something about Toy Liquidators, but I didn't see any at the local one. > > Does anyone know where Sega 3D glasses are available (and $)? > (Or another type, I guess, and cost?) > > – > J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." > – Peter Brown — brownp@stuff.rtp.dg.com — x6009 – hall 123 office 10 From burgess@warhol.cc.gatech.edu Tue Oct 15 11:11:31 1991 Received: from gatech.edu by karazm.math.UH.EDU with SMTP id AA09790 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 14:26:28 -0500 Received: from cc.gatech.edu (hermes.cc.gatech.edu) by gatech.edu (4.1/Gatech-9.1) id AA20086 for glove-list@karazm.math.uh.edu; Tue, 15 Oct 91 15:22:23 EDT Received: from warhol.cc.gatech.edu by cc.gatech.edu (3.2/SMI-3.2) id AA08626; Tue, 15 Oct 91 15:21:43 EDT Received: by warhol.cc.gatech.edu (NeXT-1.0 (From Sendmail 5.52)/SMI-4.1) id AA08238; Tue, 15 Oct 91 15:11:31 EDT Date: Tue, 15 Oct 91 15:11:31 EDT From: burgess@cc.gatech.edu (David Burgess) Message-Id: 9110151911.AA08238@warhol.cc.gatech.edu Received: by NeXT Mailer (1.62) To: glove-list@karazm.math.uh.edu Subject: Re: LPC vs. polynomial predicting I normally just listen to this list, but since I'm up to my neck in filters and predictors right now, I couldn't help but run my mouth: Linear predictive coding predicts with a linear filter: a differential equation, or, in the digital domain, a difference equation. Implementation is easy: you just feed the signal into the filter and take the result. The trick is picking the right filter. Low pass filters will control jitter, but may give sluggish response. A properly tuned second order filter is good for many control/conditioning applications, like the suspension system of your car. It will reduce jitter, but still can be tuned to give a quick response. A second order difference equation looks like: y[n] = x[n] + ax[n-1] + bx[n-2] + cy[n-1] + dy[n-2] where x is the input, y is the output, n is the time index, any all the other things are coefficiants. choose a,b,c,d carefully, because bad choices will give unstable filters that can oscillate uncontrolably or go racing off into infinity. I once experimented with polynomial prediction on my mouse driver, and found the first order prediction was ok, but higher order (quadratic, cubic, etc.) resulted in really bad overshoot. Disclaimers: I've never used a power-glove. I'm not a professional DSP engineer. –david From robichau@lambda.msfc.nasa.gov Tue Oct 15 09:54:44 1991 Received: from lambda.msfc.nasa.gov by karazm.math.UH.EDU with SMTP id AA10181 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 14:58:56 -0500 Received: by lambda.msfc.nasa.gov (4.0/SMI-4.0) id AA11591; Tue, 15 Oct 91 14:54:44 CDT Date: Tue, 15 Oct 91 14:54:44 CDT From: robichau@lambda.msfc.nasa.gov (Paul Robichaux) Message-Id: 9110151954.AA11591@lambda.msfc.nasa.gov To: aaronp@narrator.pen.tek.com Cc: glove-list@karazm.math.uh.edu In-Reply-To: Aaron Pulkka's message of Tue, 15 Oct 91 11:33:36 PDT 9110151833.AA01622@narrator.PEN.TEK.COM Subject: Low-end VR Newsgroup (was Re: move to a newsgroup?) Perhaps "sci.virtual-worlds.small?" I think that the new group would work best as a discussion area for inexpensive VR systems; thus, it should permit discussion of peripherals, software techniques, and interface issues (although the last should probably be in sci.virtual-worlds.) I'm willing to help in the c.f.v, or to serve as moderator if necessary. -Paul From crash!jester@nosc.mil Tue Oct 15 15:10:49 1991 Received: from trout.nosc.mil by karazm.math.UH.EDU with SMTP id AA10345 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 15:10:49 -0500 Received: by trout.nosc.mil (5.59/1.27) id AA09481; Tue, 15 Oct 91 13:06:51 PDT Received: by crash.cts.com (/\==/\ Smail3.1.21.1 #21.3) id m0kWv0r-0000KDC@crash.cts.com; Tue, 15 Oct 91 13:05 PDT Message-Id: m0kWv0r-0000KDC@crash.cts.com From: jester@crash.cts.com (Ken Bibb) To: glove-list@karazm.math.uh.edu Subject: newsgroups Date: Tue Oct 15 13:05:13 1991 Why not have two groups? comp.periphs.glove and sci.virtual-worlds.entry to cover the concerns that have been discussed? The first would be glove only stuff (the equivalent of this group) and the second could be for low end virtual reality work. From dstamp@watserv1.uwaterloo.ca Tue Oct 15 12:15:07 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA10520 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 15:19:20 -0500 Received: by watserv1.uwaterloo.ca id <AA11950>; Tue, 15 Oct 91 16:15:07 -0400 Date: Tue, 15 Oct 91 16:15:07 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110152015.AA11950@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Lance Norskog lance@roi.ca41.csd.mot.com says: >If you're willing to forgo the direct mapping concept, >prediction from the glove inputs can just "push" a 3D >position around. Changes in direction and speed can >be handled as special cases to avoid the overshoot/correction >effect. > >Being 31 (as of this weekend) instead of 12 years old, >I don't plan to hold my hand up to the screen >for several hours at a time anyway. >I've been testing with the sensors arranged on the >floor and letting my hand hang down. I don't see that >I need direct mapping to use the glove in this mode, >and so the 3D-cursor-pushing scheme should work fine. This is, of course, true. How critical the read rate of the Glove is depends on the application. As a mouse, it's OK, but I wouldn't try drawing with it (B-{) ! The type of application where the delay is critial is VR (virtual reality). Here, any mapping errors or delay between glove movement and the video seen by the user's eyes results in wear and tear on the user, and in extreme cases destroys the VR illusion ("That can't be MY hand unless I have a rubber arm!") Of course, in VR the video usually takes a long time to draw too. This can add up to 200 mS to the glove's own 75 mS data delay. This is bad: the rule of thumb for aircraft simulators is 200 mS maximum, and a 300 mS delay completely destroys coordination. 100 mS delay is enough to make handwriting difficult, according to one experiment. (This one used delayed video from a camera: how much better "rendering" can you get?) If you're interested in other uses for hi-res, how about a TSR or adapter to replace a joystick for video games? Shouldn't be too hard, esp. if the game is key-driven (Tetris looks like an easy one, and it's PD). -Dave Stampe From jim@kaos.stanford.edu Tue Oct 15 06:43:15 1991 Received: from fou-local (fou.Stanford.EDU) by karazm.math.UH.EDU with SMTP id AA10642 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 15:46:45 -0500 Received: from localhost.Stanford.EDU by fou-local (4.1/inc-1.0) id AA24072; Tue, 15 Oct 91 13:43:16 PDT Message-Id: <9110152043.AA24072@fou-local> To: glove-list@karazm.math.uh.edu Subject: Re: newsgroups In-Reply-To: Your message of "Tue, 15 Oct 91 13:05:13." m0kWv0r-0000KDC@crash.cts.com Date: Tue, 15 Oct 91 13:43:15 -0700 From: James Helman jim@kaos.stanford.edu How about a slightly more general group name that could encompass other 3D input devices, e.g. ultrasonic trackers, flex sensors, flying mice, etc., and perhaps even "output" devices, e.g., display and feedback devices. Basically, the group would a way to disseminate information about rolling your own devices for VR. I'd propose: comp.periphs.vr or sci.virtual-worlds.periphs. -jim Jim Helman Lab: (415) 723-9127 Stanford University FAX: (415) 591-8165 (jim@KAOS.stanford.edu) Home: (415) 593-1233 "The power of the computer is locked behind a door with no knob." -B. Laurel From motcsd!roi!lance@apple.com Sat Oct 15 07:06:52 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA11088 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 16:41:24 -0500 Received: by apple.com (5.61/1-Oct-1991-eef) id AA05691; Tue, 15 Oct 91 14:19:09 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kWw0Z-0001DjC@motcsd.csd.mot.com; Tue, 15 Oct 91 14:08 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA20735; 15 Oct 91 14:06:53 PDT (Tue) To: dstamp@watserv1.uwaterloo.ca, glove-list@karazm.math.uh.edu Subject: Separate finger readout Message-Id: 9110151406.AA20731@roi.ca41.csd.mot.com Date: 15 Oct 91 14:06:52 PDT (Tue) From: Lance Norskog lance@roi.ca41.csd.mot.com This does require cutting up the glove, which I am loath to do. The fingers range from 100k to 500k ohm in flexing. The PC joystick port has four a-d integrators which measure 0 ohms right away and are recommended to range from 0 to 100kohm. The hardware works by polling, so the smaller the range, and the lower the low-end value, the faster it works. So, if you put 1megohm across the finger, you can drop the input range to a small, quickly readable value using the formula for parallel resistance which I have forgotten. You'll read from 10-100 with this stratagem. Being clever, you could integrate the Power Glove value sampling code and the polling of the joystick ports. You then need to do a calibration system to make the glove useable. Lance Norskog From S.M.Clark@loughborough.ac.uk Tue Oct 15 16:59:33 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA11510 (5.65c/IDA-1.4.4 for glove-list@KARAZM.MATH.UH.edu); Tue, 15 Oct 1991 16:59:33 -0500 Received: from loughborough.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id 12860-0@sun2.nsfnet-relay.ac.uk; Tue, 15 Oct 1991 15:32:34 +0100 Date: Tue, 15 Oct 91 15:33:01 bst Message-Id: 27143.9110151433@hpd.lut.ac.uk To: glove-list@KARAZM.MATH.UH.edu From: S.M.Clark@loughborough.ac.uk Subject: Re: Hi-res for PC? Thanks to those of you who sent me a copy of the PC Hi-res code. However, I have recently had a *serious* e-mail problem and all copies have been lost :-( Could someone (Greg Alt?) re-send it for me? Thanks again, Sean Clark —————————————————————————- Sean Clark, Tel: (0509) 263171x4166 LUTCHI Research Centre, Fax: (0509) 610815 ROCOCO University of Technology, Loughborough, Leicestershire, LE11 3TU, UK Internet: S.M.Clark%lut.ac.uk@nsfnet-relay * Due to e-mail problems I have lost some messages. If I have not * * replied to your e-mail please re-submit your message. * —————————————————————————- From jmunkki@hila.hut.fi Wed Oct 16 02:00:02 1991 Received: from hila.hut.fi by karazm.math.UH.EDU with SMTP id AA11568 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 17:06:05 -0500 Received: by hila.hut.fi (5.65c/7.0/S-TeKoLa) id AA24024; Wed, 16 Oct 1991 00:00:02 +0200 Date: Wed, 16 Oct 1991 00:00:02 +0200 From: Juri Munkki jmunkki@hila.hut.fi Message-Id: 199110152200.AA24024@hila.hut.fi To: brownp@dg-rtp.dg.com, glove-list@karazm.math.uh.edu Subject: Re: sega glasses available? (fwd) The Sega glasses are available directly from Sega USA. They used to sell them for about $50. The shutters are not of high quality, but the interface is simple to build and the shutters are good enough to produce a good 3D effect. (I highly recommend playing with Sega glasses: it's FUN!) Juri From com2serv.c2s.mn.org!craig%tcnet.uucp@jhereg.osa.com Tue Oct 15 11:02:55 1991 Received: from jhereg.osa.com by karazm.math.UH.EDU with SMTP id AA11916 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Tue, 15 Oct 1991 17:27:38 -0500 Received: by jhereg.osa.com with UUCP id <46745>; Tue, 15 Oct 1991 17:08:01 -0500 Received: by tcnet.MN.ORG (smail2.5 (MN.ORG)) id AA17517; 15 Oct 91 17:09:22 EDT (Tue) Received: by com50.c2s.mn.org (5.51/6.8 JRC0225) id AA25412; Tue, 15 Oct 91 16:02:51 CDT Received: by com2serv.c2s.mn.org (4.1/SMI-3.2) id AA07327; Tue, 15 Oct 91 16:02:57 CDT From: craig@com2serv.c2s.mn.org (Craig S. Wilson) Message-Id: 9110152102.AA07327@com2serv.c2s.mn.org Subject: Re: Low-end VR Newsgroup (was Re: move to a newsgroup?) To: glove-list@karazm.math.UH.EDU Date: Tue, 15 Oct 1991 16:02:55 -0500 In-Reply-To: 9110151954.AA11591@lambda.msfc.nasa.gov; from "Paul Robichaux" at Oct 15, 91 2:54 pm X-Mailer: ELM [version 2.3 PL7] In a message Paul Robichaux stated: > > Perhaps "sci.virtual-worlds.small?" > Yea. And I can just hear the theme song running endlessly through my head: "It's a small world, virt–u–al; it's a small world, virt–u–al; it's a small, small world. Sorry. I couldn't help myself. /craig From ifat423@ccwf.cc.utexas.edu Tue Oct 15 12:40:48 1991 Received: from minnie.cc.utexas.edu by karazm.math.UH.EDU with SMTP id AA12134 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Tue, 15 Oct 1991 17:44:47 -0500 Received: by minnie.cc.utexas.edu (5.61/1.34/CCWF 1.16) id AA17613; Tue, 15 Oct 91 17:40:48 -0500 Date: Tue, 15 Oct 91 17:40:48 -0500 From: ifat423@ccwf.cc.utexas.edu (yo'man) Message-Id: 9110152240.AA17613@minnie.cc.utexas.edu To: glove-list@karazm.math.UH.EDU Subject: low-end VR. I personally prefer "sci.virtual-worlds.homebrew." It has a nice earthy feel to it. just my 2 mil specs Andrew From cdshaw@cs.ualberta.ca Tue Oct 15 10:59:27 1991 Received: from scapa.cs.ualberta.ca by karazm.math.UH.EDU with SMTP id AA12407 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 18:03:52 -0500 Received: by scapa.cs.ualberta.ca id <42506>; Tue, 15 Oct 1991 16:59:50 -0600 Subject: Re: Low-end VR Newsgroup From: Chris Shaw cdshaw@cs.ualberta.ca To: glove-list@karazm.math.uh.edu Date: Tue, 15 Oct 1991 16:59:27 -0600 In-Reply-To: 9110151833.AA01622@narrator.PEN.TEK.COM; from "Aaron Pulkka" at Oct 15, 91 12:33 pm Organization: U of Alberta, Dept of Computing Science Address: 713D General Services Building, U of A, Edmonton, Alberta, T6G 2H1 X-Mailer: ELM [version 2.3 PL11] Message-Id: 91Oct15.165950mdt.42506@scapa.cs.ualberta.ca > comp.periphs.virtual > sci.virtual-worlds.low-end I woould support the above two newsgroups. Volume is a bit much now. – Chris Shaw University of Alberta cdshaw@cs.UAlberta.ca CatchPhrase: Bogus as HELL ! From molly@cs.uq.oz.au Wed Oct 16 19:21:58 1991 Received: from uqcspe.cs.uq.oz.au by karazm.math.UH.EDU with SMTP id AA12799 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 18:26:04 -0500 Received: from pansy.cs.uq.oz.au by uqcspe.cs.uq.oz.au id AA23131@uqcspe.cs.uq.oz.au; Wed, 16 Oct 91 09:21:59 +1000 Date: Wed, 16 Oct 91 09:21:58 +1000 From: molly@cs.uq.oz.au Message-Id: <9110152321.AA06243@client> To: glove-list@karazm.math.uh.edu comp.sys.virtual I prefer this group name. Mark. From nop@att1.Mankato.MSUS.EDU Tue Oct 15 16:11:44 1991 Received: from ATT1.Mankato.MSUS.EDU by karazm.math.UH.EDU with SMTP id AA13320 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 15 Oct 1991 21:19:55 -0500 Received: by att1.Mankato.MSUS.EDU (5.59/25-eef) id AA29570; Tue, 15 Oct 91 21:11:44 CDT Date: Tue, 15 Oct 91 21:11:44 CDT From: Jay A. Carlson nop@att1.Mankato.MSUS.EDU Message-Id: 9110160211.AA29570@att1.Mankato.MSUS.EDU To: cdshaw@cs.ualberta.ca Cc: glove-list@karazm.math.uh.edu In-Reply-To: Chris Shaw's message of Tue, 15 Oct 1991 16:59:27 -0600 91Oct15.165950mdt.42506@scapa.cs.ualberta.ca Subject: Low-end VR Newsgroup » comp.periphs.virtual » sci.virtual-worlds.low-end > > I woould support the above two newsgroups. > Volume is a bit much now. I support sci.virtual-worlds.low-end, and suspect it should be unmoderated. People are less afraid to post to unmoderated groups, and I think we'd like to encourage the shy to post their new use for surplus laptop screens, or whatever. (sci.virtual-worlds.actually-doing-something-now comes to mind too, but I don't think the sci.virtual-worlds moderator would be amused.) From cdshaw@cs.ualberta.ca Tue Oct 15 17:56:34 1991 Received: from scapa.cs.ualberta.ca by karazm.math.UH.EDU with SMTP id AA14068 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Wed, 16 Oct 1991 01:02:04 -0500 Received: by scapa.cs.ualberta.ca id <42521>; Tue, 15 Oct 1991 23:57:59 -0600 Subject: Re: Low-end VR Newsgroup From: Chris Shaw cdshaw@cs.ualberta.ca To: glove-list@karazm.math.UH.EDU Date: Tue, 15 Oct 1991 23:56:34 -0600 In-Reply-To: 9110160211.AA29570@att1.Mankato.MSUS.EDU; from "glove-list-request@karazm.math.UH.EDU" at Oct 15, 91 8:11 pm Organization: U of Alberta, Dept of Computing Science Address: 713D General Services Building, U of A, Edmonton, Alberta, T6G 2H1 X-Mailer: ELM [version 2.3 PL11] Message-Id: 91Oct15.235759mdt.42521@scapa.cs.ualberta.ca By the way, I'm definitely against comp.sys.virtual, because the comp.sys hierarchy is for machines from a particular manufacturer, or a manufacturer's product line. Hence c.s.mac, c.s.sgi, c.s.dec, etc. There is no standard "virtual" system, nor is there a manufacturer called "virtual", so comp.sys.virtual is out. > (sci.virtual-worlds.actually-doing-something-now comes to mind too, > but I don't think the sci.virtual-worlds moderator would be amused.) Actually, it seems to me that the only purpose for moderation of that group is to get U of Washington's name in lights on a permanent basis. I happen not to like the stuff in that group right now, but on the other hand, the philosophizing does not seem inappropriate. The fact of the matter is that almost everyone who is doing work in this field can't be bothered to post to that group. This is due mainly to the high "fluff" level, but also because most labs out there are extremely busy getting their labs up & running. Most people are starting from scratch, building things using the first technique that comes to mind. As a result, nobody talks to each other because everyone thinks they have "the best answer". Face it, reporting your hot new result to sci.virtual-worlds is worth absolutely nothing. Better to get it in a conference or a journal, and get credit for it. When these projects finally get published, the seriousness level on sci.virtual-worlds will increase, because people won't be so worried about proving themselves. I hope. – Chris Shaw University of Alberta cdshaw@cs.UAlberta.ca CatchPhrase: Bogus as HELL ! From rrr@aberystwyth.ac.uk Wed Oct 16 12:59:43 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA15181 (5.65c/IDA-1.4.4 for glove-list@KARAZM.MATH.UH.edu); Wed, 16 Oct 1991 09:16:24 -0500 Received: from aberystwyth.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id 9191-0@sun2.nsfnet-relay.ac.uk; Wed, 16 Oct 1991 12:00:10 +0100 Received: by uk.ac.aber.aberda (5.57/aberclient-4.0) id AA05378; Wed, 16 Oct 91 11:59:43 +0100 Date: Wed, 16 Oct 91 11:59:43 +0100 From: rrr@aberystwyth.ac.uk Message-Id: 9110161059.AA05378@uk.ac.aber.aberda To: dstamp@WATSERV1.UWATERLOO.ca, glove-list@KARAZM.MATH.UH.edu Subject: TSR >If you're interested in other uses for hi-res, how about a TSR or adapter to replace a joystick for video games? Shouldn't be too hard, esp. if the game is key-driven (Tetris looks like an easy one, and it's PD). > Ive written a TSR for low res use og PowerGlove, it works for most applications. I dont have time to rewrite my basic IO stuff for hi res, but the TSR should work fine, Ill post the source if anybodys interested. Ronan R M Ruairi, UCW Aberystwyth, rrr@UK.AC.Aber ps the code interprets data from PG as keystrokes and stuffs the standard buffer. Its written in Turbo Pascal v6. From elci@BUGS.gs.com Wed Oct 16 08:44:00 1991 Received: from CCA.CAMB.COM by karazm.math.UH.EDU with SMTP id AA15851 (5.65c/IDA-1.4.4 for GLOVE-LIST@KARAZM.MATH.UH.EDU); Wed, 16 Oct 1991 11:55:54 -0500 Received: from olymps.gs.com by camb.com (PMDF #12148) id 01GBTBUQQJN495N415@camb.com; Wed, 16 Oct 1991 12:51 EDT Received: from DECNET-MAIL by gs.com (PMDF #12282) id 01GBTBLNKZO08WWFR8@gs.com; Wed, 16 Oct 1991 12:44 EDT Date: Wed, 16 Oct 1991 12:44 EDT From: Reha Elci elci@BUGS.gs.com Subject: hi-res rs232? To: GLOVE-LIST@KARAZM.MATH.UH.EDU Message-Id: 01GBTBLNKZO08WWFR8@gs.com X-Organization: Goldman, Sachs & Co. X-Vms-To: olymps::in%"glove-list@karazm.math.uh.edu" Does anyone know if someone is selling a high-res rs232 interface to the glove. It seems like people are experimenting with micro-controllers; maybe there already is some general product out there that outputs to an rs-232. Thanks for the info. Reha Elci Email: elci@bugs.gs.com From motcsd!roi!lance@apple.com Sun Oct 16 03:54:50 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA17143 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Wed, 16 Oct 1991 13:51:33 -0500 Received: by apple.com (5.61/1-Oct-1991-eef) id AA15368; Wed, 16 Oct 91 11:14:29 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kXFUZ-0001RtC@motcsd.csd.mot.com; Wed, 16 Oct 91 10:57 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA03292; 16 Oct 91 10:54:51 PDT (Wed) To: glove-list@karazm.math.UH.EDU Subject: Re: Low-end VR Newsgroup Message-Id: 9110161054.AA03288@roi.ca41.csd.mot.com Date: 16 Oct 91 10:54:50 PDT (Wed) From: Lance Norskog lance@roi.ca41.csd.mot.com sci.virtual-worlds.homebrew captures the essence of this list. Or alt.cyberspace.homebrew, although, yes, lots of geek administrators don't take alt groups. If you promise there will not be 5 megs of bad porno every day, you may be able to change this. If you think sci.v-w has fluff, go check out comp.graphics. Sci.v-w doesn't have people posting for GIF viewers every damn day. Moderation is a good thing, except that you can't involve two groups in a jointly interesting topic. I'd like to start a conversation between sci.v-w and comp.simulation on the topic "how do I simulate recombinant objects and substances?" but I can't because they're both moderated. "I have two pieces of clay. I slap them together and make one big piece. What data structures should I use? Are objects appropriate?" I've been told that few people in industry post to sci.v-w because they don't want to leak proprietary secrets. The computer biggies (SUN Dec IBM etc.) are putting large budgets behind VR groups. Lance Norskog From agodwin@acorn.co.uk Wed Oct 16 10:52:37 1991 Received: from eros.uknet.ac.uk by karazm.math.UH.EDU with SMTP id AA17502 (5.65c/IDA-1.4.4 for glove-list@KARAZM.MATH.UH.edu); Wed, 16 Oct 1991 15:08:16 -0500 Received: from acorn.co.uk by eros.uknet.ac.uk with UUCP id 7227-0@eros.uknet.ac.uk; Wed, 16 Oct 1991 21:04:25 +0100 Received: from snark.acorn.co.uk by acorn.co.uk (4.1/Am31) id AA18236; Wed, 16 Oct 91 09:52:33 BST From: agodwin@acorn.co.uk (Adrian Godwin) Date: Wed, 16 Oct 91 09:52:37 +0100 Message-Id: 9110160852.AA00837@snark.acorn.co.uk To: cdshaw@CA.UALBERTA.cs, glove-list@KARAZM.MATH.UH.edu Subject: Re: Low-end VR Newsgroup > > I happen not to like the stuff in that group [ sci.virtual.worlds] right now, > but on the other hand, the philosophizing does not seem inappropriate. > I agree : that group doesn't have much hardware discussion (except to say 'buy an SGI' !), and the hardware threads that do appear don't last long. I think there's a need for a general purpose hardware group, and the existence of such a group would make a glove-only one rather pointless. …periphs seems too limited (I think of peripherals as parts very distinct from the host, and some possible video adapters aren't really that. We might even develop a complete host, specifically for VR). How about sci.virtual-worlds.hardware ? I don't much care whether it's moderated or not, as long the moderator is welded to it's keyboard :-). -adrian From dstamp@watserv1.uwaterloo.ca Wed Oct 16 13:34:28 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA18002 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 16 Oct 1991 16:38:29 -0500 Received: by watserv1.uwaterloo.ca id <AA22998>; Wed, 16 Oct 91 17:34:28 -0400 Date: Wed, 16 Oct 91 17:34:28 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110162134.AA22998@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu I've been experimenting with the hi-res mode, and I want to compare my results with others. I have found a way to read the glove as fast as possible. Simply read the 6 data bytes from the glove, then 2 more at the fast speed (discard these). Now read a byte from the glove every 2 to 4 millisecond (with an interrupt?). If the read returns $A0, read the next data set. If 500 reads pass without $A0, repeat the hires setup sequence. This can run in the background while graphics are drawn. This results in speeds of 17 samples/sec (fingers open) to 12.5 (fist). It appears that up to 25 samples/sec could be achieved by disabling finger reads by the glove controller, and reading finger positions externally as I suggested earlier. (Lance Norskog suggested using an IBM PC's game port as an analog input for this. Sounds feasible, and could be made fast). The data etc. read from the glove is in 6 bytes: 1) X (side-to side) 2) Y (up and down) 3) Z (distance) 4) rot (turning wrist) 5) fingers (2 bits for each finger) 6) keys on glove For X and Y, the glove seems to return differences in distances to receiver pairs from the transmitters. This implies that the X and Y scaling to position gain changes with position, being greatest closer to and centered on the receiver array. At 300 cm (10') the resolution is 3 mm per count. Right and up are positive, left and down are negative. Range is +/- 127, which is achived at 45 degrees from and outside the receiver array (!). Z resolution seems disappointingly low, being 1.6 cm (0.65") per step. I KNOW that the internal resolution is 2 mm for this one! Away is positive, toward is negative. Rotation is also low resolution, and seems quite nonlinear. This could be caused by the room I'm in, though. The values increase with clockwise rotation, palm down being 0. Steps are (about) 30 to 40 degrees, with a range of 0 to 13. Sensitivity seems greatest in palm-up position (6 to 9). Finger positions are packed into 1 byte, with 2 bits per finger. The format is: T t I i M m R r for thumb, index, middle and ring fingers. Open hand is 0, fist is 3. Capital is MSB, lowercase is LSB. The key byte can accept all number keys (0 to 9) and returns their number codes (0-9). If no key is pressed, this byte is $FF. Other key codes are: SEL $83 START $82 A $0A B $0B UP $0D DOWN $0E LEFT $0C RIGHT $0F Codes are returned as long as the key is held down. NOTE ON NOISE: I have found the glove position data tends to take jumps of about 6 to 8 units in X and Y position (about an inch). This is NOT a glitch or a misread, but a position-related discontinuity. The reason for this can be seen by scoping the receiver detector inputs and outputs (in the small box joining the receivers and the glove). These are peak detectors, and respond when the sound pulse has been received. However, the glove uses piezoelectric transducers in its transmitters and receivers, which have a VERY high Q. This means that a 12-cycle pulse driving the transmitter is stretched to several hundred pulses at the receiver detector. Also, the "rising edge" of the received envelope increases linearly for at least 20 cycles before stablizing. This means that 3 to 6 pulses actually arrive at the receivers before the detector is tripped. The detection point is always near the peak of one of the 45 KHz wave cycles, and this adds a quantized offset to the delay. The power glove seems to use a delay resolution of 2 microseconds. However, if the strength of the pulse at the receiver changes ( or if a reflection of the pulse interferes) the detector will trigger on an earlier or later cycle than it did on the last pulse. This causes a +/- 20 microsecond change in the delay time, or about 8 mm of distance. Thus, the glove can resolve about 1.3 mm of distance, but with errors of +/- 8 mm superimposed! See this diagram for a possible result: / \ / \ / \ ^ | | ←- GLITCH! | | | | / \ | / \_ position time—> This problem is built into the design, and can't be fixed. If the user moves the glove slowly enough, these glitches might be filterable by software. Have to try it, though. -Dave Stampe From dstamp@watserv1.uwaterloo.ca Wed Oct 16 16:48:34 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA20065 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 16 Oct 1991 19:52:33 -0500 Received: by watserv1.uwaterloo.ca id <AA00603>; Wed, 16 Oct 91 20:48:34 -0400 Date: Wed, 16 Oct 91 20:48:34 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110170048.AA00603@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu K. C. Lee (LEEK@QUCDN.QueensU.CA) replies: >I suspect the sampling rates of the glove can go much faster if the >glove CPU don't have to process the 6 sets of distances into (X,Y,Z,Rotation). >In that case the only limitation would be how fast can the receivers settle > so that the transmitter can send another ping. I don't believe the CPU is doing any special processing. I did some work on an implementation using an 80C196, and the math required a lot of 32-bit multiplications, divisions and roots, about 4 mS worth on that processor and out of the question for an 8-bit processor in any reasonable time. Also, if you compute the distortion that would be caused by just using the difference in delay between horizontal and vertical receiver pair response times, you get a response very like the one I've measured: about 50% better resolution at 100 cm distance as compared to 200 cm. I've also scoped the unit in operation and there isn't any extra time for calculations. The CPU waits for incoming pulses for 20 mS times 2 trans- mitters, for a total of 40 mS. This corresponds to the 25 Hz read rate seen if the finger timing circuit is defeated. BTW, 20 mS corresponds to a maximum echo path of 6.8 m (22'), which seems reasonable to me. Any less, and you could only use it in a padded cell! (B-{) Of course, the processor COULD attempt to do the math while it's waiting for the receivers to respond, but I don't think it is. -Dave Stampe From jdb9608@cs.rit.edu Thu Oct 17 17:06:04 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA24731 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 17 Oct 1991 20:09:08 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA06230; Thu, 17 Oct 91 21:05:04 -0400 Received: from gallium.CS (gallium.ARPA) by junior.rit.edu (4.1/5.17) id AA10376; Thu, 17 Oct 91 20:54:02 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110180054.AA10376@junior.rit.edu Subject: Re: sega glasses available? To: gbnewby@alexia.lis.uiuc.edu (Greg Newby) Date: Thu, 17 Oct 91 21:06:04 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110152112.AA24605@alexia.lis.uiuc.edu; from "Greg Newby" at Oct 15, 91 4:12 pm X-Mailer: ELM [version 2.3 PL8] I called Sega USA tonite (1-800-USA-SEGA) and the guy I asked said that they would sell the 3D glasses by themselves, over the phone with a credit card or thru the mail by check. 34.95 3D glasses +2.80 postage & handling ATTN: Parts and Orders Dept. Sega America 3375 Arden Rd. Hayward, CA 94545 I haven't ordered one yet, but that's probably the way I'll do it. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From dstamp@watserv1.uwaterloo.ca Thu Oct 17 17:47:39 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA24854 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 17 Oct 1991 20:51:46 -0500 Received: by watserv1.uwaterloo.ca id <AA12204>; Thu, 17 Oct 91 21:47:39 -0400 Date: Thu, 17 Oct 91 21:47:39 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110180147.AA12204@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Program: PWRFILT.C This is a new HIRES glove driver program that includes NOISE REDUCTION! I hung the receiver array in the *worst* corner of my room, and got almost no glitches and rock-solid operation. It's hard to believe it's the same system! And the NR adds no delay, and is invisible to the user. This driver rolls up some of the loops in the original HIRES driver, exchanging speed in unimportant areas for much smaller code. It was written to use a PC-LabCard I/O device, since I happened to have one. Someone else will have to change the port addresses, bit masks, etc. so it's usable with the printer port. Interrupt polling of the Glove should be easy, given this code. One warning: don't test the power glove too often (I recommend about 2-4 mS between pollings) or the Glove will start trashing data severely. You non-PC users will want to transplant the NR code at least, so go ahead. ————————- cut here ———————————– / Originally "power.c" © manfredo 9/91 (manfredo@opal.cs.tu-berlin.de) Developed on an ATARI 1040ST with TC 1.1 using a logic analyzer to get the correct timings. / /* ported to PC compatibles by Greg Alt 10/91 galt@peruvian.utah.edu or galt@es.dsd.com / /* Substantially rewritten by Dave Stampe © 1991: PWRFILT.C No cash, no warranty, no flames. This stuff works great, so gimme credit. Goals <achieved> were: Higher speed, smaller code. Polled operation is now possible. Graphics test (VGA) Noise reduction added, gets rid of 99.5% of noise with NO DELAY! This runs on a 486/25 with an i/o card. Someone should adapt it for the usual printer port adapter. It was compiled with Turbo C++ 2.0 but will probably work on any Turbo C directly. MSC will need library calls checked. dstamp@watserv1.uwaterloo.ca 17/10/91 / #include <dos.h> #include <bios.h> #include <stdio.h> #include <conio.h> #include <graphics.h> int gdriver = VGA; /* for graphics plot and cursor */ int gmode = VGAHI; #define XHYST 2 /* hysterisis for X, Y low noise reduction */ #define YHYST 2 /* 2 eliminates +/-3 quanta of noise */ #define XACC 8 /* X, Y maximum accel/decel level. Should */ #define YACC 8 /* be 6-10, but too high limits gesturing */ #define XXTEND 2 /* stretches deglitching time */ #define YXTEND 1 #define N 1 /* delay scaled by N/D <CHANGED> */ #define D 1 /* these are 1,1 for 486 PC with i/o card */ #define INPORT 0x2A0 /* i/o port addresses <CHANGED> */ #define OUTPORT 0x2A0 /* bits for i/o ports <CHANGED> */ #define GDATA 0x01 /* PG data in */ #define GLATCH 0x02 /* PG latch out */ #define GCLOCK 0x01 /* PG clock out */ #define GCLOLAT 0x03 /* clock + latch */ /* delay values for sending and sampling data <CHANGED> */ #define D2BYTES 150 /* delay between 2 bytes = 96 us */ #define D2BITS 6 /* delay between 2 bits = 3 us */ #define D2SLOW 8000 /* intertest delay = 2000-4000 us */ /* Delay timing: may not work in some IBM C's due to problems with LONGs */ void fdelay(unsigned int val) { register long i=N*val; for(;i>0;i-=D); } /* defines for output line pair control */ #define C0L0() outportb(OUTPORT, 0) /* clock 0 latch 0 */ #define C0L1() outportb(OUTPORT, GLATCH) /* clock 0 latch 1 */ #define C1L0() outportb(OUTPORT, GCLOCK) /* clock 1 latch 0 */ #define C1L1() outportb(OUTPORT, GCLOLAT) /* clock 1 latch 1 */ /* prototypes */ void Hires (void); /* puts glove in hires mode */ void getglove (unsigned char *); /* get data packet from glove */ int glove_ready(); /* returns 0 if not ready */ /* delay repeats by 2-4 ms */ unsigned char getbyte (void); /* read byte from glove */ /* GLOVE DATA SPECIFICATIONS The glove_data array has been simplified. These are its functions: x = X position, 3mm per number y = Y position, 3mm per number z = distance, 14mm per number rot = wrist twist. 0 is up 1 is slightly CW, 5 is down, 11 is slightly CCW. About 30 to 40 degrees per count. Note: exact scaling of all above change with distance! Closer is higher res. fingers = packed 2-bit values, 0 is open, 3 is (tight) fist: Bit format: TtIiMmRr for Thumb, Index, Middle, and Ring fingers. keys: $FF or $80 is no key. Responds with 0 to 9 for keys "0" thru "9" $82 = START, $83 = SEL, $0A = "A", $0B = "B", 0 is "Center" Up,down,left,right are $0D,$0E,$0C,$0F respectively. */ typedef struct glove_data { signed char x,y,z,rot,fingers,keys; } glove_data; /*/ void main () { unsigned char buf[12]; glove_data *glov; unsigned unready; /* number of unsuccessful tries to read glove */ glov=(glove_data *)buf; initgraph(&gdriver, &gmode, ""); /* VGA graphics, 640x480 */ cleardevice(); /* begin again here if glove crashes */ restart: Hires (); /* set PG into 'hires' mode */ while(!kbhit()) { unready = 0; /* start polling glove */ fdelay(D2SLOW); while(glove_ready()==0) /* wait for glove to become ready */ { if (unready++>500) goto restart; /* reset mode if dead glove */ fdelay(D2SLOW); } getglove(buf); /* read 6 byte packet */ gotoxy(1,1); /* print xyz at scrren top */ printf("% 4d % 4d % 4d ", 255&glov→x, 255&glov→y, 255&glov→z); /* print rot, fingers, keys */ printf("%-2x %-2x %-2x ", buf[3],buf[4],buf[5]); deglitch(glov); /* remove spikes and jumps */ dehyst(glov); /* add hysteresis to remove LL noise */ drawp(glov); /* plot x,y positions */ drawthing(glov); /* animate glove cursor */ } getch(); /* exit when keyboard hit */ C0L0(); /* release glove on exit */ } void getglove(buf) /* read 6 byte data packet */ unsigned char *buf; { register unsigned char *bp; bp = buf; *bp++ = getbyte (); /* read data */ fdelay(D2BYTES); *bp++ = getbyte (); fdelay(D2BYTES); *bp++ = getbyte (); fdelay(D2BYTES); *bp++ = getbyte (); fdelay(D2BYTES); *bp++ = getbyte (); fdelay(D2BYTES); *bp++ = getbyte (); fdelay(D2BYTES); /* throwaways (speeds up polling later) */ getbyte (); fdelay(D2BYTES); getbyte (); } int glove_ready() /* returns 1 if glove ready, 0 otherwise */ { int f; f = getbyte(); return( (f==0xA0) ? 1 : 0); } unsigned char getbyte () /* read a byte from glove <rolled code> */ { register int i; register unsigned char x = 0; C1L0 (); /* generate a reset (latch) pulse */ C1L1 (); fdelay(D2BITS); /* hold for 5 us */ C1L0 (); for(i=0;i<8;i++) { x=x«1; x+=inportb(INPORT)&GDATA; C0L0 (); C1L0 (); /* pulse */ } return(x); /* return the byte */ } /* HIRES ENTRY CODES byte: 1- any value between $05 and $31 2- only $C1 and $81 work OK 3- no effect 4- no effect 5- no effect 6- only $FF works 7- seems to affect read rate slightly, 1 fastest */ int hires_code[7] = { 0x06, 0xC1, 0x08, 0x00, 0x02, 0xFF, 0x01 }; void Hires () /* enter HIRES mode <rolled code- speed unimportant> */ { int i,j,k; /* dummy read 4 bits from glove: */ C1L0 (); C1L1 (); /* generate a reset (latch) pulse */ fdelay(D2BITS); C1L0 (); fdelay(D2BITS); C0L0 (); C1L0 (); /* pulse clock */ fdelay(D2BITS); C0L0 (); C1L0 (); /* pulse clock */ fdelay(D2BITS); C0L0 (); C1L0 (); /* pulse clock */ fdelay(D2BITS); C0L0 (); C1L0 (); /* pulse clock */ /* handshake for command code? */ C1L0 (); fdelay(16950); /* 7212 us delay */ C1L1 (); fdelay(4750); /* 2260 us delay */ for(i=0;i<7;i++) /* send 7 bytes */ { k=hires_code[i]; for(j=0;j<8;j++) /* 8 bits per byte, MSB first */ { if(k & 0x80) { C1L1(); C0L1(); C1L1(); } else { C1L0(); C0L0(); C1L0(); } k=k«1; fdelay(D2BITS); } fdelay(D2BYTES); } fdelay(1090); /* 892 us delay (end of 7. byte) */ C1L0 (); /* drop the reset line */ fdelay(30000); /* some time for the glove controller to relax */ fdelay(30000); } glove_data oldbuf; /* used to store old state for drawing */ int drawn = 0; /* set if cursor to be erased */ drawthing(glove_data *g) /* draw square cursor */ { if(g→keys==2) return; /* hold down "2" to stop drawing */ if(drawn) /* erase old box */ { setcolor(0); drawit(&oldbuf); } setcolor(15); /* draw new box */ drawit(g); drawn = 1; oldbuf.x = g→x; /* save pos'n for next erase */ oldbuf.y = g→y; oldbuf.z = g→z; } drawit(glove_data *g) /* draw/erase box cursor */ { int x = 320+2*(g→x); /* compute X,Y center */ int y = 240-2*(g→y); int z = 30+(g→z); /* size prop. to Z */ rectangle(x-z,y-z,x+z,y+z); } int xx = 0; /* plot position */ drawp(glove_data *g) /* plot X,Y data to test smoothing */ { if(g→keys==4) /* restart at left edge if "4" pressed */ { cleardevice(); xx=0; } setcolor(0); line(xx,0,xx,479); line(xx+1,0,xx+1,479); setcolor(15); line(xx,240-2*g→x,xx+1,240-2*g→x); setcolor(12); line(xx+1,240-2*g→y,xx+2,240-2*g→y); xx++; xx++; if(xx>639)xx=0; } int ox = -1000; /* last x,y for hysterisis */ int oy = -1000; dehyst(glove_data *g) /* hysterisis deglitch (low noise removal) */ { int x = g→x; int y = g→y; if(g→keys==0) ox = oy = 0; /* handle recentering ("0"key or "Center") */ if(x-ox>XHYST) ox = x-XHYST; /* X hysterisis */ if(ox-x>XHYST) ox = x+XHYST; if(y-oy>YHYST) oy = y-YHYST; /* Y hysterisis */ if(oy-y>YHYST) oy = y+YHYST; g→x = ox; /* replace present X,Y data */ g→y = oy; } int x1 = 0; /* delayed 1 sample (for smoothed velocity test) */ int y1 = 0; int x2 = 0; /* delayed 2 samples */ int y2 = 0; int lx = 0; /* last good X,Y speed */ int ly = 0; int lax = 0; /* bad data "stretch" counter */ int lay = 0; int lsx = 0; /* X,Y "hold" values to replace bad data */ int lsy = 0; int lcx = 0; /* last X,Y speed for accel. calc. */ int lcy = 0; deglitch(glove_data *g) { int vx, vy; int x = g→x; int y = g→y; if(g→keys==0) /* reset on recentering ("0" or "Center" key) */ { x1 = x2 = y1 = y2 = 0; lx = ly = lax = lay = 0; lsx = lsy = lcx = lcy = 0; } vx = x-2) wrote: …deleted… >Has anyone made an Amiga cable yet? Did you have the same wiring as the >Byte Article, except that +5 volts could be taken from pin 14 on the parallel >port?? > >Is there any Amiga code out there that would point me in the right direction >of talking to the glove through the parallel port (just in regular mode)? and "NO, That's NOT a cord of wood in my pocket!" kskelm@uccs.edu wrote: > Is anybody working on an Amiga version of the glove Hires code? >I sure hope so… 'cuz I know *I* don >oops …don't fully understand its function. Last night I downloaded the original ST code and reworked my lores code for the Amiga and achieved mixed results – partially due to an AND instead of an OR (it was late :) In any case, contrary to my initial expectation, the glove (in HIRES) seems to work off of the JOYMOUSE ports on the A3000. This is, IMO, greatly preferable to a serial or parallel solution and has the additional benefit of letting me use my lores cable :) As to code, I think karazm.math.uh.edu has the Amiga lores code that I wrote for the JOYMOUSE ports (be warned, it was a quick hack – but it does multitask :). QUESTION for those with HIRES working: is the glove supposed to click audibly in HIRES? Les Extraordinary crimes against the people and the state have to be avenged by agents extraordinary. Two such people are John Steed – top professional, and his partner, Emma Peel – talented amateur; otherwise known as "The Avengers." INTERNET: leh@ufl.edu UUCP: …!gatech!uflorida!leh BITNET: vishnu@UFPINE From dstamp@watserv1.uwaterloo.ca Fri Oct 18 10:10:33 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA28677 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Fri, 18 Oct 1991 13:15:15 -0500 Received: by watserv1.uwaterloo.ca id <AA24742>; Fri, 18 Oct 91 14:10:33 -0400 Date: Fri, 18 Oct 91 14:10:33 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110181810.AA24742@watserv1.uwaterloo.ca To: gbnewby@alexia.lis.uiuc.edu, jdb9608@cs.rit.edu Subject: Re: sega glasses available? Cc: glove-list@karazm.math.uh.edu > From glove-list-request@karazm.math.UH.EDU Fri Oct 18 13:25:24 1991 > From: Greg Newby gbnewby@alexia.lis.uiuc.edu > To: jdb9608@cs.rit.edu > Subject: Re: sega glasses available? > Cc: glove-list@karazm.math.uh.edu > > For the circuit, has anyone tested it out? It appears that > you hook in the Sega glasses, and then send a signal to switch > the LCDs (from left-on, right-off to left-off, right-on). > > The signal is sent via pin 4, which is not the regular pin > for reading or writing data. > > So, the question is, what's involved in switching the signal? > If it's a call to termio() or somesuch, what sort of speed > limitations are we talking about? I didn't check the > RS232 standard just now, but I wonder about the +/- 10V switching > signal – isn't that rather 0-12V? (effectively, probably > +/-3 to 8-12V). > > Finally, does anyone have the tech specs on the glasses (or > an estimate, as I suspect Sega doesn't include such things > with the glasses)? Switching speed, %dark, etc… > > With the brain trust we have on this list, I'm not too worried > that someone will figure out how to hook in the glasses. I'm > just wondering in advance if performance (especially switching > speed) will be up to snuff. > (For example, to give some numbers, we need a minimum > of about 10 frames per second to perceive continuity > between frames of a moving scene. That means the glasses > need to switch 20 times per second, right? A left-right > sequence for each frame. > If there's more than a few u-second lag for the > glasses to switch, we'll have to compensate in the > display program. Being that we're usually using all > the computing power we have just to keep the graphic > images coming fast enough, incorporating some sort > of delay for the glasses would be undesirable.) > > Oh, BTW: I've done a bit of experimenting (back at Syracuse) with > some Tektronics shutter glasses – a very similar beast, tho > presumably higher performance. I found that the flicker was > perceivable at 30Hz (60 switches / second), and intolerable > (read, "doesn't work") at about 7-15 Hz. I didn't experiment > with the full range….this was because the software-driven > switching circuit never operated more quickly than about 15Hz. > > Ok, I'm rambling now: the alternative, to get 30Hz, is to > NOT switch the glasses via software. Just let them operate > at the frequency of the power supply (60Hz in the US, which, in > the circuit we used @ Syracuse, was run through a rectifier). > Then, no coordinating between your graphics program and the > glasses are necessary, PROVIDED that your program is able to > operate at "top-speed," switching the image on the screen > as often as possible (as in, the speed of the power supply). > I don't know if this technique works for all platforms, > but it worked on the Amiga and Iris we used at Syracuse. I even > synched the glasses off of a Sony VCR/editor to look at > the display on the Iris. > > 'Nuff said. > – Greg > gbnewby@alexia.lis.uiuc.edu > Here's the EXACT driving specs on the Sega, Haitex, and X-Spec glasses. These all use the same type of LCD pi-cell. They are normally fairly dark (30% transmissive) and drop to 1% transmissive (very dark) when sent a 24V. 2 KHz signal (square wave). Do not accept drivers that use lower frequencies or voltages, as these will not become fully opaque! I spent several month designing drivers for these things about a year ago. We used both computer and video (alternating-field) signals to drive them. I have the following designs: - A 5V supply design with a flyback power supply - A 12V supply design using push-pull drive - A (theoretical) design using the RS232 port of a computer and 4 components. This last design has not been built or tested yet, as I temporarily do not have access to glasses. However, if you want to try it, go ahead. Just tell me it it works. Basically, you hook the outside (common) of the glasses connector (use a Walkman-type stero phone jack) to the ground pin of the RS232 port. Connect 2 of 2.2K resistors to the TX pin. Connect a 1N914,1N4005, etc. diode's cathode to the DTR and another to the RTS pin. Connect one anode of diode and one of the resistors to each of the pins on the glasses jack. THAT'S IT. The software is a bit complex. Basically, you have to set up an interrupt to keep the TX buffer of the serial port stuffed with $55's. Set the baud rate to 4800 baud, and voila! a 24V 2200 Hz output. Raise and lower the DTR and RTS pins (via the UART in the PC) to turn the pulses to each eye on and off. This should work on any PC that supplies at least +/-10V (the RS232 standard is +/- 12V). Interrupt loading is not terribly high: about 5-10%. No guarantees that this will work, but it would be pretty easy to try. -Dave Stampe From dstamp@watserv1.uwaterloo.ca Fri Oct 18 10:49:30 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA28759 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Fri, 18 Oct 1991 13:54:04 -0500 Received: by watserv1.uwaterloo.ca id <AA27819>; Fri, 18 Oct 91 14:49:30 -0400 Date: Fri, 18 Oct 91 14:49:30 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110181849.AA27819@watserv1.uwaterloo.ca To: dstamp@watserv1.uwaterloo.ca, galt@dsd.es.com, glove-list@karazm.math.uh.edu Subject: Re: noise-free glove software > From galt@dsd.es.com Fri Oct 18 13:01:46 1991 > From: galt@dsd.es.com (Greg Alt - Perp) > To: dstamp@watserv1, glove-list@karazm.math.uh.edu > Subject: noise-free glove software > > Hey, that looks great. I'm glad someone went to the trouble of > rolling up the init routine into a loop… I'll try out it out > this weekend. That noise-reduction part sounds pretty impressive. > Here's my plan for what we need to do to make the whole package > (close to) perfect: > > 1) convert the function names to some standard > 2) separate the glove driver in its own .c file > 3) use compiler directives to allow use of the same code on several machines > e.g. #define PC_PRINTER would make it compile for a > PC using the printer port. > This shouldn't be too difficult since the code is basically the > same with only a few minor differences for each machine. > > > This is all pretty amazing… before we got our first hi-res code, > nobody was very interested in the glove, now people everywhere are > getting excited about it. I've already gotten mail from people from > Korea to the U.K. > Greg > THe first step in developing the standard will have to be the development of functioning code for each machine. The IBM PC's can be made self- calibrating pretty easily, and the use of defines for I/O port is a good idea. I would like to define the minimum functionality as: - initialize with one call, which enters hi-res mode, sets up a timer interrupt every 4 mS, and initializes the code. - an interrupt handler which: - polls the glove for $A0 start code, exits if not ready - if the glove was not ready after 500 tries, resets the glove mode - reads the 6-byte data packet, and 2 more throwaway bytes - deglitches and denoises the X and Y data (deglitches Z???) - stores the data int the glove_int_data buffer - sets the glove_int_data.new flag - a glove_read routine which: - disables interrupts - copies the glove_int_data (including .new flag) to buffer - clears the glove_int_data.new flag - enables interrupts - a reset routine (onexit(?)) which resets the timer interrupt It is probably worthwhile to have a LORES and HIRES mode set on initialization, which means that only the .keys data field is valid. The timer interupt would happen less often, to reduce CPU interrupt load. Total CPU load on a 386 looks to be about 3%. Proposed names for routines: int init_glove(int mode) #define LORES 0 #define HIRES 1 void reset_glove() int glove_read(glove_data *) /* returns 0 if old, 1 if new data */ If we try to keep some interface stuff the same, everyone can develop code for their machine that meets the specs. Then they can either be combined or distibuted seperatly. Any comments? - Dave Stampe From gibsonm@u.washington.edu Fri Oct 18 04:50:05 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA28766 (5.65c/IDA-1.4.4 for glove-list@KARAZM.MATH.UH.edu); Fri, 18 Oct 1991 13:54:32 -0500 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA03678; Fri, 18 Oct 91 11:50:05 -0700 Date: Fri, 18 Oct 91 11:50:05 -0700 From: Michael Gibson gibsonm@u.washington.edu Message-Id: 9110181850.AA03678@milton.u.washington.edu Sender: gibsonm@milton.u.washington.edu To: agodwin@acorn.co.uk, glove-list@KARAZM.MATH.UH.edu, nik@BU-IT.BU.edu Subject: Re: PG locations, NC-1 cables, and Amiga hookup. Could you please mail me the amiga code that you mentioned? I would sure appreciate it. My name is Michael Gibson and my e-mail addess is : gibsonm@milton.u.washington.edu Thanks. From jdb9608@cs.rit.edu Fri Oct 18 10:52:18 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA28773 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Fri, 18 Oct 1991 13:55:47 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA05145; Fri, 18 Oct 91 14:51:32 -0400 Received: from aluminum.CS (aluminum.ARPA) by junior.rit.edu (4.1/5.17) id AA13024; Fri, 18 Oct 91 14:40:20 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110181840.AA13024@junior.rit.edu Subject: Re: Sega circuit To: cci632!ccicpg!sun!apple!well!gregk@isc.rit.edu (Greg Kaiser) Date: Fri, 18 Oct 91 14:52:18 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110180455.AA26212@well.sf.ca.us; from "Greg Kaiser" at Oct 17, 91 9:55 pm X-Mailer: ELM [version 2.3 PL8] > I did not catch a copy of the cicuit to hook up sega glasses to the VGA > on an IBM PC. I saw you post about how to buy the glasses, do you happen > to have a copy of the cicuit you could send me? I'd appreciate it. Here is the schematic and C source (for IBM PC) for the Sega 3D glasses that was posted on sci.virtual-worlds a while ago. Using this circuit seems simpler than generating a square wave with 0x55 at 4800 baud; I'm not certain, but I think the outportb(0x3fc, 1) and outportb(0x3fc, 3) commands in the WaitForVerticalRetrace() function alternately set and reset the RTS line on the RS-232 port, while keeping the DTR line constant as a power supply. Could someone with PC docs confirm whether bit 0 is the DTR line and bit 2 is the RTS line at port 0x3fc on a PC? I know next to nothing about circuits, and I haven't tried to make this one (yet), so I can't say much about it. I just hope it works and that it's controled by the DTR line being constantly on, and the RTS line causing one eye's view when set and the other eye's view when reset. Can someone confirm this or add advice? I'll put this on karazm.math.uh.edu tonite for those with ftp, too. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From rit!rochester!udel!wupost!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!hlab Tue Sep 10 14:02:24 EDT 1991 Article 1626 of sci.virtual-worlds: Path: ultb!rit!rochester!udel!wupost!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!hlab >From: frank@cavebbs.gen.nz (Frank van der Hulst) Newsgroups: sci.virtual-worlds Subject: Sega Glasses / RS-232 interface circuit Message-ID: 1991Sep9.155236.6358@milton.u.washington.edu Date: 9 Sep 91 09:49:38 GMT Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab) Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ Lines: 77 Approved: cyberoid@milton.u.washington.edu Circuit to connect SEGA 3D glasses to RS-232 port. ————————————————– RS-232 DB25 / DB9 10K RTS 4 7 Switching signal +/- 10V ——–vvvvv–+ | | GND 7 5 Ground —-+————-+–+———+–|—-+ | | | | | | | | +-|>|–+ | | | +–|>|–+ — | | | | Transistor | — 22 uF | | | | 2N2222 | | | | | +-+———+ | | | | | | Emitter | | | | | | | | DTR 20 4 Vdd +10V –|>|—–+—–+ +–|–+–+ Base | | | | | +–+–+–+-+-vvvvv—+–|—–+ Collector | | | | | 10K | | | | | | | | | | +———–+ +——-+–+–+–+———–+–+–+ | 1 9 13 14 5 7 | | | | RCA CD 4030 Quad XOR gate | | | | 2 11 12 3 6 8 10 4 | +-+–+—+——-+–+–+—-+—+–+ | | | | | | | | +–+ | +–+–+ | +— Outside of jack | | | | | +-vvvvv-+ | +——- Middle of jack | 22K | | | | +———— Centre of jack +-vvvvv—–+ | 22K | | — | .01 uF — | | | +—–+ Diode: –|>|– Resistor: –vvvvv– Capacitor: | — — | This is my best attempt at a rendition of the circuit which connects my SEGA glasses to my AT. I didn't design the circuit – I'm a software rather than hardware person. In fact I barely understand it – as far as I can tell, the .01uF capacitor & the 22K resistors act as a delay. The outputs of the XOR gates feed back into their own inputs, thus producing an oscillator. The "jack" mentioned in the diagram is the mini-jack which is connected as standard to the glasses. "Centre", "middle", and "outside" relate to the external connections, looking at the thing end-on. Disclaimer: The circuit diagram above may be entirely wrong. My description may be wrong. Caveat emptor… to paraphrase the standard software licence agreement: It's as good as I can get it. If it doesn't work or blows up your computer or your glasses and blinds you for life, I'll give you back all the money you paid me. Good Luck… Frank. – Take a walk on the wild side, and I don't mean the Milford Track. Kayaking: The art of appearing to want to go where your boat is taking you. From rit!rochester!udel!wupost!sdd.hp.com!spool.mu.edu!agate!bionet!raven.alaska.edu!milton!hlab Fri Sep 27 18:40:47 EDT 1991 Article 1742 of sci.virtual-worlds: Path: ultb!rit!rochester!udel!wupost!sdd.hp.com!spool.mu.edu!agate!bionet!raven.alaska.edu!milton!hlab >From: frank@cavebbs.gen.nz (Frank van der Hulst) Newsgroups: sci.virtual-worlds Subject: Sega glasses & VGA (C source code) Message-ID: 1991Sep25.022127.27830@milton.u.washington.edu Date: 23 Sep 91 08:42:28 GMT Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab) Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ Lines: 200 Approved: cyberoid@milton.u.washington.edu Several people requested info on how to display 3D images, after my post of the circuit to hook up Sega glasses to the PC. Following is source code to do that. Frank. /* VGA 320 * 400 * 256 * 2 frames routines. Written by: F van der Hulst, 20/2/91 These routines display pixels in 320*400 mode by modifying the VGA registers, as outlined in Programmer's Journal V7.1 (Jan/Feb '89) article, pages 18-30, by Michael Abrash. The advantage of 320 * 400, is that it gives two separate video pages, which can be displayed on the screen independently. These can contain two views of a scene, taken from slightly different viewpoints. These are displayed alternately on the screen, in sync with a pair of "chopper glasses", to give a 3D effect. */ #include <conio.h> typedef unsigned char DacPalette[256][3]; /* Setvgapalette sets the entire 256 color palette */ /* PalBuf contains RGB values for all 256 colors */ /* R,G,B values range from 0 to 63 */ /* Taken from SVGA256.H, by Jordan Hargraphix Software */ void setvgapalette(DacPalette *PalBuf) { struct REGPACK reg; reg.r_ax = 0x1012; reg.r_bx = 0; reg.r_cx = 256; reg.r_es = FP_SEG(PalBuf); reg.r_dx = FP_OFF(PalBuf); intr(0x10,&reg); } unsigned int act_page = 0; /* Current page being written to */ #define VGA_SEGMENT 0xa000 #define SC_INDEX 0x3c4 #define GC_INDEX 0x3ce #define CRTC_INDEX 0x3d4 #define DISPIO 0x3DA #define MAP_MASK 2 #define MEMORY_MODE 4 #define GRAPHICS_MODE 5 #define MISCELLANEOUS 6 #define VRT_bit 8 #define MAX_SCAN_LINE 9 #define START_ADDRESS_HIGH 0x0c #define UNDERLINE 0x14 #define MODE_CONTROL 0x17 void writepixel(int x, int y, unsigned char colour) { long addr; addr = 3) id AA17898; Sat, 19 Oct 91 19:49:54 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA16333; Sat, 19 Oct 91 19:38:43 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110192338.AA16333@junior.rit.edu Subject: ST timing? To: glove-list@karazm.math.uh.edu Date: Sat, 19 Oct 91 19:53:32 EDT X-Mailer: ELM [version 2.3 PL8] I'm working on a timer/interrupt driven hi-res interface for the ST, to free up the CPU. I've got the timer/interrupt part working (finally…), but the data packet from the glove is sometimes out of sync. Specifically, it sometimes shifts so that A0 and X are the last bytes of the packet, sometimes A0 is the last byte, and sometimes A0 is the first byte (like it should be). Manfredo's suggestion of quickly making a fist or pressing the center button both work to bring A0 back to the first byte, but it goes out of whack too frequently (about once per minute) to rely on that manual solution. I suspect it's a timing problem, as Greg Alt mentioned when he did the PC version, but I tried changing the /7 to a /5 and /6 in the delay() macro (as he did) and it didn't help. Has someone gotten the ST source to give them the packet in the proper order? I know it DOES work for Manfred Krauss, and it doesn't work for several other people on this list who've tried it on their ST's. Who else with an ST is getting the packets in the right order? Did you change the code? Did it just work? Is there some timing difference in the hardware between different types of ST's? I'll try changing the times of various parts of the protocol, (especially reducing the delay times, since Greg's machine is faster than mine), but I'd rather not guess. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From dstamp@watserv1.uwaterloo.ca Sat Oct 19 17:04:46 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA03969 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sat, 19 Oct 1991 20:08:49 -0500 Received: by watserv1.uwaterloo.ca id <AA23683>; Sat, 19 Oct 91 21:04:46 -0400 Date: Sat, 19 Oct 91 21:04:46 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110200104.AA23683@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, jdb9608@cs.rit.edu Subject: Re: ST timing? > From glove-list-request@karazm.math.UH.EDU Sat Oct 19 20:21:47 1991 > From: jdb9608@cs.rit.edu (John D Beutel) > Subject: ST timing? > To: glove-list@karazm.math.uh.edu > > I'm working on a timer/interrupt driven hi-res interface for the ST, > to free up the CPU. I've got the timer/interrupt part working > (finally…), but the data packet from the glove is sometimes > out of sync. > > Specifically, it sometimes shifts so that A0 and X are the > last bytes of the packet, sometimes A0 is the last byte, > and sometimes A0 is the first byte (like it should be). > Manfredo's suggestion of quickly making a fist or pressing > the center button both work to bring A0 back to the first > byte, but it goes out of whack too frequently (about once > per minute) to rely on that manual solution. I suspect > it's a timing problem, as Greg Alt mentioned when he did > the PC version, but I tried changing the /7 to a /5 and /6 > in the delay() macro (as he did) and it didn't help. > > Has someone gotten the ST source to give them the packet > in the proper order? I know it DOES work for Manfred Krauss, > and it doesn't work for several other people on this list > who've tried it on their ST's. Who else with an ST is > getting the packets in the right order? Did you change > the code? Did it just work? Is there some timing difference > in the hardware between different types of ST's? > > I'll try changing the times of various parts of the protocol, > (especially reducing the delay times, since Greg's machine > is faster than mine), but I'd rather not guess. > > – > J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." > Look at the code I posted a few days ago for the IBM PC. Basically, what you must do is: 1) Read from the glove until a $A0 is received. Try every 3 or 4 mS, or the glove will start trashing data if you interrupt it too often (do this via an interrupt.) 2) Immediately read 8 bytes, discarding the last 2– this is the REAL glove data packet. 3) Return to step 1 If the glove hasn't responded after 500 tries of step 1, reset it into the hires mode (is crashed or the user changed the program). The code I posted also contains noise reduction routines. If you don't use these, your cursor will jump aruond a lot. The above procedure is FASTER than the fixed timing reads. What happens is that the glove takes longer to finish reading the finger positions when you make a fist. Hand open, you get 17 samples/sec, hand closed, you get 12.5 samples/sec. - Dave Stampe From narf@u.washington.edu Sat Oct 19 11:53:53 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA04000 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sat, 19 Oct 1991 20:57:54 -0500 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA10780; Sat, 19 Oct 91 18:53:53 -0700 Date: Sat, 19 Oct 91 18:53:53 -0700 From: Francis Taylor narf@u.washington.edu Message-Id: 9110200153.AA10780@milton.u.washington.edu Sender: narf@milton.u.washington.edu To: glove-list@karazm.math.uh.edu Subject: Interfaces to VR devices Reply-To: narf@hitl.washington.edu Hi. I'm hacking interfaces to user interface devices at the HIT Lab in Seattle, and I've been watching this list with great interest. Lately I've seen interface software going by, and I figured I should get in my two cents' worth (I'm optomistic). There should be a standard for the software interfaces to devices like the PowerGlove, the DataGlove, the Exos DHM, the Polhemus and Bird position sensors… so we can all run the same software, whether we use a $50 Mattel PowerGlove or a $5000 VPL Dataglove. And, of course, who knows what wonderful sensors the future will bring. Won't it be nice to buy that great new device, plug it in, and get all its functionality, even using the same software you've worked with so much. The precision, range, and units of data from the sensors will be different. Also, people with floating-point processors will want to work with floats, and others may want fixed-point numbers for speed. In any event, efficiency is paramount. If a standard interface introduces significant overhead into a system, speed freaks won't use it, and we VR hackers certainly qualify as speed freaks. If you show me a computer made today that's 'fast enough' for VR, I'll buy it (I'm broke, but I'm confident). My solution to this problem (encompassing the famous Media-Lab "all of the above" attitude) is that the interface provides the data in as many different formats as suitable, and also provides the relative costs of the different formats. The application decides which formats it wants, and informs the interface, which provides exactly what is needed. The concept is similar to that of an Internet Telnet connection; each figures out what the other's got so the most featureful connection possible is established. If the interface library can provide this kind of functionality by clever use of preprocessor macros, then very efficient code can be produced for a variety of different situations. For example, I've written an RS-232 library that works with POSIX, BSD, System V, and Macintosh systems. Thanks to clever and careful use of macros, the application code is generic, and the implementations are optimal. If you're interested in pursuing these goals with me, or if you have an idea, please send me e-mail. All HIT Lab software carries the GNU Copyleft Notice, in case you're concerned about proprietary ideas. From jdb9608@cs.rit.edu Sat Oct 19 19:22:16 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA04174 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sat, 19 Oct 1991 22:22:45 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA22805; Sat, 19 Oct 91 23:18:40 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA16559; Sat, 19 Oct 91 23:07:27 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110200307.AA16559@junior.rit.edu Subject: sampling techniques and response time To: glove-list@karazm.math.uh.edu Date: Sat, 19 Oct 91 23:22:16 EDT X-Mailer: ELM [version 2.3 PL8] I've been thinking about continuous polling (via interrupts) versus polling on demand. There may be a problem with synchronizing. The way to increase the sample rate that Dave Stampe found (thru excellent investigation–you're really helping, Dave!) was by polling a byte every 2 to 4 ms, and watching for the A0. (I haven't tried it yet.) The samples per second range from 17 (= 58 ms) for open hand to 12.5 (= 80 ms) for closed hand. The more samples per second, the better. The problem may be the increase in time from when the sample is taken to when the glove_data is utilized. Someone mentioned a figure like 100 ms as the maximum response time for coordinating motion and vision. Can anyone elaborate (I know there was an expert on this out there…)? If the calculation and rendering of the cursor is not synchronized with the sampling of the glove, then in the worst case with continuous polling the data could come in just after the program begins to calculate the cursor's position, and sit around for 79 ms before being used to calculate the cursor's next position. If the cursor's something complicated (like a picture of a glove), or if the glove's own sample time (40 ms) gets in the way, or especially if the data is used for something more complicated like rendering the whole viewpoint (e.g., homemade eyephones), then that pushes the delay way beyond the 100 ms limit. On the other hand, if the glove can be polled on demand (within certain constraints, like at least every 100 ms), or even if the graphics are synchronized to the continuous polling, then that eliminates the 79 ms lag time and brings the picture that much closer to the motion. The trick to the polling on demand (theoretically) is to not sample the glove until you're ready to use the glove_data, and then return as soon as you've got the important data. The juicy part of the packet is the first 7 bytes (if the packet is in the right order), which take less than 1 ms to sample! The last 4 bytes of the standard 12 byte packet take about 70 ms to sample, but they're not needed and can be handled by an ISR following the return of the main call, just to keep the timing right. Whether the data was freshly sampled when it comes from the glove is another important question. I'm assuming that the CPU time needed to handle the graphics will expand to approximate whatever sample time is achieved with the glove. Any slower frame update rate than 13 fps will look choppy, and any faster would be pointless since if there's no new input sample then the picture won't need to change anyway. So, if it is possible to do the graphics faster than the input sample rate then the programmer will just make the graphics more complicated (hidden line removal, polygon filling, polygon shading, more polygons… ad infinitum). Since each graphics cycle will take about as long as each glove sample, it'll be important to synchronize them and avoid a doubling of the best-case delay time. Whether to sync the glove to the code or the code to the glove depends on how the glove makes its clicks. I suppose the glove must start its sample click 40 ms before it sends the data to the computer, which means it must do so 39 ms before the computer asks for it, which means that it must do so whether the computer asks or not. In that case, continuous sampling would be best and the code must be sync'ed to the glove (which is a pain, considering that there may be other devices also being delt with, including another glove). On the other hand, if the glove always starts its clicks approximately 30 ms after the last time the computer asked it for data, then sampling on demand is best so the glove will be syncronized to the code. Can a hardware guru look into this, please (Dave Stampe?)? The time it takes to do the graphics rendering each frame is independent of whether the glove's fingers are open or closed. So, if continuous sampling is used and the graphics rate is not syncronized to the glove, then as the glove sample rate varies from 58 ms to 80 ms the graphics routines will get out of sync and introduce an additional 80 ms lag time (at worst) between movement and feedback (which is probably unacceptable). If the graphics rate IS synchronized to the glove, the graphics routines will have to be designed to the shortest interval (58 ms) and the additional 22 ms which may or may not be there will be wasted every frame (i.e., wasting 27% of the CPU time). On the other hand, if the glove times its clicks according to when the on-demand sample is made, then the graphics code can be designed to the worst-case time (75 ms or however long it is), the CPU will be fully utilized, and an additional 17 ms lag time (at worst) will be the cost. But, if the glove clicks away at its own speed regardless of when on-demand samples are made, then the lag time will be occuring as the data sits around in the glove's internal buffer instead of in the computer's, but the results will be the same (up to 80 ms as the glove and computer become unsynchronized at their worst). I think this would be a big performance problem. I don't know enuf to find out myself which way the glove works. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From dstamp@watserv1.uwaterloo.ca Wed Oct 19 21:11:49 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA04583 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 00:15:52 -0500 Received: by watserv1.uwaterloo.ca id <AA00440>; Sun, 20 Oct 91 01:11:49 -0400 Date: Sun, 20 Oct 91 01:11:49 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110200511.AA00440@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, jdb9608@cs.rit.edu Subject: Re: sampling techniques and response time John D Beutel (jdb9608@cs.rit.edu) sends a message on: - sampling rates on powerglove and delays of data - motion-to-video delays - polling of glove vs. interrupt delays in data First, the REAL sampling rate for data is set by the powerglove itself, and depends on the sum of all of its sample periods (thus its dependance on the finger position). If you wait longer than the sampleing period before you read the glove, you just get older data. Second, the interrupt-driven method I proposed (use an interrupt every 3-4 mS to poll the glove) actually results in the freshest possible data. Your software can sit in a loop calling get_glove_data() and checking the .new flag in the result: the glove doesn't care, and you're just looking at the buffer contents until the interrupt gets new data and updates the buffer. BTW, there's a good reason for using an interrupt instead of having your program poll the glove directly… actually, two. First, this ensures the glove is polled with proper spacing (if you see evenly spaced glitches in the glove XY data, you're talking to the glove too often. Second, the interrupt ensures that you're getting every sample: otherwise the deglitch() noise reduction won't work properly. The only way I can figure to speed up the glove sample rate (potentially to 25 Hz) is to disconnect the fingers, short them out (or ground the CPU sample pin) and connect the finger sensors to an A/D converter (such as a modified PC game port card). Seems like a lot of work. The motion-to-video delay problem IS serious, and isn't going to get any better. If we assume an average of 60mS/2=30mS delay in the glove, 30 mS in the transfer, 100 mS in rendering, and 16 mS in the display, we have about 180 mS altogether. Now, I know of commercial aircraft simulators that have that kind of delay, and they DON'T use eyephone-type displays– but their performance make experienced pilots run, not walk, to the nearest washroom. Of course, in our systems the field of view won't be so big, and the amount of "motion sickness" should be less. Also, if you're just moving objects with your hand, you can learn to slow down a bit. The problem is with eyephone displays– picture movements won't match head movements very well, so the user will experience dizzying effects as the scene lags head movements. (BTW, I have an idea how to partially fix this, involving some tomfoolery with the sync for the displays, that I'd like to discuss with someone who has a working system with a head position sensor and good hardware experience). The usual method for fixing delay is a Kalman or predictive filter, but I don't think this will work with the power glove. The noise filters I wrote work on the position data, but don't affect velocity noise at all. This means the Kalman filter would add significant noise. I think this might be a good time to point out a couple of interesting points that I think were'nt clear from past postings. First, saying that a 100 mS delay can cause "oscillation" by feedback thru the user doesn't imply that the system is oscillating at 10 Hz. The human nervous system contains its own adaptive predictive filters with 100-300mS predictive power. Add these to the 100 mS delay and you get an unstable system that can oscillate at <1 Hz. This is worst in aircraft simulators where the simulator adds more lowpass stuff, or when the user is trying for fine positioning. Second… Hmm, can't remember now, so you KNOW I'm typing this inside of mail! (B-{) - Dave Stampe From dstamp@watserv1.uwaterloo.ca Wed Oct 19 21:43:00 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA04863 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 00:47:03 -0500 Received: by watserv1.uwaterloo.ca id <AA02928>; Sun, 20 Oct 91 01:43:00 -0400 Date: Sun, 20 Oct 91 01:43:00 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110200543.AA02928@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu I'd like to try something on for _size_ here, having to do with the number of polys in a low-end VR database versus rendering capacity. This means that mail and postings are solicited, on opinions, facts, or whatever. I'm trying to get a feel for the whole subject, as the VR graphics project seems to be of interest right now. First, I'm looking at the followup to Fundamentals of Interactive Computer Graphics, which is titled Computer Graphics: Principles and Practice by James Foley et al. It seems pretty decent, if you avoid the inevitable IRIS bias. It has good stuff on transformations and a whole chapter on various visible-surface determination algorithms. I think I see a fast way way to do the scan-line algorith that would take less than 25% of the rendering time, and would result in each screen pixel being written to once (i.e 10 frames per second, 320x200x256 colors on a 386/25 IBM PC). Have to check further, though. Now, the main event. I am proposing a top-down clipping sequence for a 10,000 polygon database (world, that is), that goes as follows: database: 10,000 polys, arranged as objects with some extra fields clipping 1: 4,000 polys, by known hidden objects (i.e behind user) clipping 2: 2,000 polys, by quick plane tests to see if in viewport backside: 1,000 polys, by removing polys on back of objects. All this clipping can be done BEFORE converting the polys to viewport (X,Y,depth) coordinate system. Most of this is easily done during the transversal of the database (i.e. movong the world model to the renderer). 1000 polys is a lot to have to draw, but it's within a factor of 3 of what my proposed renderer *may* be able to do at 10 frames/sec. SO… Any comments? Is the 10,000 poly database unrealisticly big? Is my clipping estimate overoptimistic? If so, how many polys SHOULD I count on getting thru to the renderer? All suggestions welcome. - Dave Stampe From jim@kaos.stanford.edu Sun Oct 20 04:27:27 1991 Received: from fou-local (fou.Stanford.EDU) by karazm.math.UH.EDU with SMTP id AA06189 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 13:31:17 -0500 Received: from [127.0.0.1] by fou-local (4.1/inc-1.0) id AA01566; Sun, 20 Oct 91 11:27:41 PDT Message-Id: <9110201827.AA01566@fou-local> To: glove-list@karazm.math.uh.edu Subject: Re: trying something on for _size_ In-Reply-To: Your message of "Sun, 20 Oct 91 01:43:00 EDT." 9110200543.AA02928@watserv1.uwaterloo.ca Date: Sun, 20 Oct 91 11:27:27 -0700 From: James Helman jim@kaos.stanford.edu 1) Since Andy Van Dam was associated with Stellar and PHIGS/PHIGS+ (competitors to SGI & GL), I don't think that Foley+Van Dam+Feiner+Hughes has an IRIS bias. A high-end bias, perhaps. 2) Your proposed clipping is a first step, but if you want to maintain anything resembling a constant frame rate in a complex world, consider using multiple resolution models and switching between them depending on their apparent size and scene complexity. 3) Texture mapping is the only way to make scenes with few polys look halfway decent. See Sense8's software running on ActionMedia cards in a PC or on a vanilla SPARCStation GX. Gullichsen has done a good job, mostly in software. Even the IRIS Indigo does texture mapping in software. The poly count / texture tradeoff is worth considering. -jim Jim Helman Lab: (415) 723-9127 Stanford University FAX: (415) 591-8165 (jim@KAOS.stanford.edu) Home: (415) 593-1233 "The power of the computer is locked behind a door with no knob." -B. Laurel From wb1j+@andrew.cmu.edu Sun Oct 20 10:32:14 1991 Received: from PO5.ANDREW.CMU.EDU by karazm.math.UH.EDU with SMTP id AA06205 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 13:38:15 -0500 Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA07909> for glove-list@karazm.math.uh.edu; Sun, 20 Oct 91 14:34:07 EDT Received: via switchmail; Sun, 20 Oct 1991 14:34:05 -0400 (EDT) Received: from pcs8.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.cd0Qilq00WBM80aUR9>; Sun, 20 Oct 1991 14:32:18 -0400 (EDT) Received: from pcs8.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr21/wb1j/.Outgoing/QF.Ed0Qijm00WBMA1VW0o>; Sun, 20 Oct 1991 14:32:15 -0400 (EDT) Received: from mms.0.1.871.EzMail.NeXT.2.0beta.2.CUILIB.3.45.SNAP.NOT.LINKED.pcs8.andrew.cmu.edu.pmax.ul4 via MS.5.6.pcs8.andrew.cmu.edu.pmax_ul4; Sun, 20 Oct 1991 14:32:14 -0400 (EDT) Message-Id: 0d0Qiiy00WBMQ1VVow@andrew.cmu.edu Date: Sun, 20 Oct 1991 14:32:14 -0400 (EDT) From: "William M. Bumgarner" wb1j+@andrew.cmu.edu To: glove-list@karazm.math.uh.edu Subject: DataGlove 2 & NeXT Cc: Seems I have come up w/access to a DataGlove 2. I am going to use it w/a NeXT ('040). Anyone have any experience doing this? BTW: I'm going to write an IB palette for the glove. If you want to use the glove in a NeXTStep app, you can just drag an instance of the glove off the palette and make a few connections…. It will be free and source code will be included. b.bum b.bumgarner | Disclaimer: All opinions expressed are my own. wb1j+@andrew.cmu.edu | I officially don't represent anyone unless I NeXT Campus Consultant | explicity say I am doing so. So there. <Thpppt!> "I ride tandem with the random/Things don't run the way I planned them.." From jim@kaos.stanford.edu Sun Oct 20 05:02:17 1991 Received: from fou-local (fou.Stanford.EDU) by karazm.math.UH.EDU with SMTP id AA06295 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 14:06:04 -0500 Received: from LOCALHOST.Stanford.EDU by fou-local (4.1/inc-1.0) id AA01759; Sun, 20 Oct 91 12:02:19 PDT Message-Id: <9110201902.AA01759@fou-local> To: narf@hitl.washington.edu Cc: glove-list@karazm.math.uh.edu Subject: Re: Interfaces to VR devices In-Reply-To: Your message of "Sat, 19 Oct 91 18:53:53 PDT." 9110200153.AA10780@milton.u.washington.edu Date: Sun, 20 Oct 91 12:02:17 -0700 From: James Helman jim@kaos.stanford.edu Francis- At least the Ascension, Polhemus and Logitech devices do roughly the same thing: measure position and orientation of one or more sensors. But providing a common interface to all the different gloves on the market (Mattel PowerGlove, VPL DataGlove, Exos DHM, Virtex CyberGlove) is another matter. They all have different numbers and locations of sensors, ranging from the PowerGlove on the low end to the 22 sensor CyberGlove on the high end. Combine this with varying built in abilities to do gesture recog, internal calibration and force/tactile feedback and the MIT "all of the above" strategy becomes, well, challenging. The application decides which formats it wants, and informs the interface, which provides exactly what is needed. A good idea in principal, but it would require the interface software to do things like building a 22 degree-of-freedom hand model from PowerGlove input (map all to high-end strategy) or only providing a minimal PowerGlove hand model to all apps (lowest common denominator strategy). In the former case, many apps will behave strangely with the low-end device guessing (better though than not behaving at all), in the latter, you're throwing away $6K worth of hardware. A more complex negotiation between the application's requests and the device's capabilities would be possible, but increases (probably unacceptably) the complexity both of the interface software and the app. I'd love to hear any ideas or progress the HIT lab makes on any of this. -jim Jim Helman Lab: (415) 723-9127 Stanford University FAX: (415) 591-8165 (jim@KAOS.stanford.edu) Home: (415) 593-1233 "The power of the computer is locked behind a door with no knob." -B. Laurel From yanek@mthvax.cs.miami.edu Sun Oct 20 12:11:32 1991 Received: from mthvax.cs.miami.edu by karazm.math.UH.EDU with SMTP id AA06503 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 15:15:51 -0500 Received: by mthvax.cs.miami.edu id AA16502 (5.65+/IDA-1.3.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 91 16:11:34 -0400 From: Yanek Martinson yanek@mthvax.cs.miami.edu Message-Id: 9110202011.AA16502@mthvax.cs.miami.edu Subject: Re: Interfaces to VR devices To: jim@kaos.stanford.edu (James Helman) Date: Sun, 20 Oct 91 16:11:32 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: <9110201902.AA01759@fou-local>; from "James Helman" at Oct 20, 91 12:02 pm X-Mailer: ELM [version 2.3 PL11] > But providing a common interface to all the different gloves on the > market (Mattel PowerGlove, VPL DataGlove, Exos DHM, Virtex CyberGlove) > is another matter. They all have different numbers and locations of > sensors, ranging from the PowerGlove on the low end to the 22 sensor > CyberGlove on the high end. Combine this with varying built in > abilities to do gesture recog, internal calibration and force/tactile > feedback and the MIT "all of the above" strategy becomes, well, > challenging. We could have some set of operations/functions that all interfaces should support, either using the hardware feature or simulating it in software. Then any application that uses only that basic set of operations will work with any device. Then, there would be options unique to a specific device. These interfaces would still support the basic standard, but add on some new function calls. Then a program may be written that requires a specific device. Something like we have with modems. There is a basic command set (hayes AT set) for neccessary things like RESET, DIAL, ANSWER, HANGUP, etc. Any software that uses only these commands will work with most modems. Then there are optional things some modems have, like MNP COMPRESSION, protocols, interface speed locking, buffers, etc. A program can use these features but then it will not work with other modems. From tolman%asylum@cs.utah.edu Sun Oct 20 09:38:01 1991 Received: from cs.utah.edu by karazm.math.UH.EDU with SMTP id AA06740 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 16:42:08 -0500 Received: from asylum.utah.edu by cs.utah.edu (5.65/utah-2.18-cs) id AA23819; Sun, 20 Oct 91 15:38:04 -0600 Received: by asylum.utah.edu (5.65/utah-2.12-leaf) id AA17900; Sun, 20 Oct 91 15:38:01 -0600 Date: Sun, 20 Oct 91 15:38:01 -0600 From: tolman%asylum@cs.utah.edu (Kenneth Tolman) Message-Id: 9110202138.AA17900@asylum.utah.edu To: glove-list@karazm.math.uh.edu Subject: Dataglove 2 and the SGI I also have gotten hold of some Dataglove 2's and I am trying to write a driver for them, but on the Silicon Graphics workstations (the PI's for now). Is anyone else working on this or interested? I'll be happy to give away any code once it gets working. For now I am seeking a manual called "using the 6 port RS-232 option" to help work out the definition of this new peripheral device. thanks tom tolman at the virtual virtual reality lab at University of Utah From jdb9608@cs.rit.edu Sun Oct 20 18:28:39 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA07428 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 21:29:32 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA27903; Sun, 20 Oct 91 22:25:02 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA18542; Sun, 20 Oct 91 22:13:44 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110210213.AA18542@junior.rit.edu Subject: Re: sampling techniques and response time To: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) Date: Sun, 20 Oct 91 22:28:39 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110200511.AA00440@watserv1.uwaterloo.ca; from "Dave Stampe-Psy+Eng" at Oct 20, 91 1:11 am X-Mailer: ELM [version 2.3 PL8] > First, the REAL sampling rate for data is set by the powerglove itself, and > depends on the sum of all of its sample periods (thus its dependance on the > finger position). If you wait longer than the sampleing period before you > read the glove, you just get older data. That's what I'm wondering. If the samples are made at a constant rate (like by the original hi-res routine), then are the samples that the glove makes itself limited by this? I've listened to the clicks that the glove makes while being sampled at a constant speed, and I can't hear any difference between open and closed fingers. I'm not sure I can tell the difference between 13 and 17 Hz, but I suspect the glove has a constant sample rate when polled with the original method, independent of finger position. > Second, the interrupt-driven method I proposed (use an interrupt every 3-4 mS > to poll the glove) actually results in the freshest possible data. Your > software can sit in a loop calling get_glove_data() and checking the .new > flag in the result: the glove doesn't care, and you're just looking at > the buffer contents until the interrupt gets new data and updates the buffer. I agree; the quick-polling method you discovered should get the data the fastest possible way. I'm worrying about the graphics routines and how much time they take. However long it is, it won't vary according to the polling rate of the glove. So, there's a trade-off involved with quick-polling. To keep the response time as fast as possible, the graphics must be synchronized with the glove polling. But, if the fingers are open and there's only 58 ms between polls, then that's all the time the graphics routines will have, so they must be able to do their job in 58 ms. If the fingers are closed and there's 80 ms between polls, then the extra 22 ms will be wasted (unless the graphics can be written to do the minimum rendering in 58 ms and some worthwhile extra rendering if more time (up to 22 ms) happens to be available). Wasting the CPU time on the long intervals is the trade-off for having a quicker response time. If the glove sync's itself to the rate it's polled (as it seems to when polled with the old method) then the graphics can be written to take a constant CPU time (e.g., 80 ms), fully utilize the CPU, and still stay in sync with the glove. However, the whole point to sync'ing the code and the glove is to avoid an average 30 ms extra lag time, so if the original polling method adds any extra lag time to the quick-polling method, then it may not be worth sync'ing (or it may be worth accepting the wasted CPU time). Maybe I think about this too much. It shouldn't be really important unless the glove is being used on eyephones, and in that case the fingers would be off anyway, so the sample rate would be constant regardless of method. I haven't gotten your quick-polling method working (yet) (I haven't even gotten the original working in the right order all the time yet), but I'm a little worried about the "reset after 500 polls of no A0". That sounds like a 1 or 2 second interruption of data; how often does it happen? When and why? – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From DAVID@asgard.clare.tased.edu.au Sun Oct 20 21:43:13 1991 Received: from diemen.utas.edu.au by karazm.math.UH.EDU with SMTP id AA07497 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.EDU); Sun, 20 Oct 1991 21:43:13 -0500 Received: from ecc.tased.edu.au by diemen.utas.edu.au with SMTP id AA18964 (5.65b/IDA-1.4.3 for glove-list@karazm.math.uh.EDU); Mon, 21 Oct 91 13:39:01 +1100 Received: from slick.clare.tased.edu.au by ecc.tased.edu.au (PMDF #12099) id 01GC0CZ7BIPS94E63S@ecc.tased.edu.au; Mon, 21 Oct 1991 13:38 +1000 Received: from charon1.clare.tased.edu.au by slick.clare.tased.edu.au (4.1/SMI-4.1) id AA02089; Mon, 21 Oct 91 14:44:48 EST Received: From ASGARD/WORKQUEUE by charon1.clare.tased.edu.au via Charon 3.4 with IPX id 100.911021133945.336; 21 Oct 91 13:39:59 -0500 Date: 21 Oct 91 13:03:38 From: david DAVID@asgard.clare.tased.edu.au Subject: subscibe me please To: glove-list@karazm.math.uh.EDU Message-Id: MAILQUEUE-99.911021130337.336@asgard.clare.tased.edu.au X-Envelope-To: glove-list@karazm.math.uh.EDU X-Mailer: Pegasus Mail v2.1b. Please subscribe me to the list - I'm very interested in both it and 6811 technology. Thankyou _ David Ford Voice : +61 02 49 6887 Claremont College Fax : +61 02 49 1984 Link Rd email : david@slick.clare.tased.edu.au Claremont TAS 7011 AUSTRALIA The Internet : "Wherever you go… There you are…" Buckaroo Banzai From jdb9608@cs.rit.edu Sun Oct 20 19:44:51 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA07612 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 22:45:18 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA02939; Sun, 20 Oct 91 23:41:13 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA18621; Sun, 20 Oct 91 23:29:56 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110210329.AA18621@junior.rit.edu Subject: Re: Interfaces to VR devices To: yanek@mthvax.cs.miami.edu (Yanek Martinson) Date: Sun, 20 Oct 91 23:44:51 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110202011.AA16502@mthvax.cs.miami.edu; from "Yanek Martinson" at Oct 20, 91 4:11 pm X-Mailer: ELM [version 2.3 PL8] > We could have some set of operations/functions that all interfaces > should support, either using the hardware feature or simulating it in > software. It's difficult to plan the union of these fundamental functions when constraints like speed are so important and most of these devices are unknown. Take the PowerGlove, for example. I have to take back my suggestion of a standard interface function called pre_glove(). Originally it was for the interrupt driven version of the hi-res driver I was working on, to free up the CPU for graphics. I thought that starting the glove poll about 70 ms before the data was needed would be a crucial optimization, before it occured to me that the important data should be gotten in the first 1 ms so the poll could be started and the important data returned in one function call. Now, pre_glove() isn't needed. Since we're just starting to learn how to interface with the glove, there may be more fundamental changes in the way we do it. So, we shouldn't make a standard yet. On the other hand, if we could nail down a standard interface before we had much experience making programs for it, then the programs would be compatable, which is desirable. It's a catch-22. The various techniques of using the PowerGlove have differences which must be small compared to the ones of different devices, and I've never used any of the other VR input devices, so I can't suggest what the fundamentals should be. Judging by the PowerGlove so far, I do expect more differences than there at first seems to be. Francis, I second the request for more info on what the HIT Lab has learned on standards for the variety of VR devices. Without practical experience with these other devices, I think making a standard for their use would be largely a waste of time. I'd really like to see a nice PowerGlove standard, at least on the fundamentals like how it'll be polled or interrupt driven. For example, people using fast polling with interrupts, or especially people who get 68HC11 boards working and send serial data only when it's ready, will probably want a standard function that will be called by an interrupt whenever the next data packet arrives. That hasn't been mentioned for the glove standard yet because nobody's implemented that kind of interface yet. But they will… – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From SAACC@CUNYVM.CUNY.EDU Sun Oct 20 19:56:51 1991 Received: from cunyvm.cuny.edu by karazm.math.UH.EDU with SMTP id AA07736 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 23:03:46 -0500 Message-Id: 199110210403.AA07736@karazm.math.UH.EDU Received: from CUNYVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4795; Sun, 20 Oct 91 23:59:32 EDT Received: by CUNYVM (Mailer R2.08) id 7607; Sun, 20 Oct 91 23:59:31 EDT Date: Sun, 20 Oct 91 23:56:51 EDT From: Shermane Austin SAACC@CUNYVM.CUNY.EDU Subject: please change my address To: glove-list glove-list@karazm.math.uh.edu Please change my mailing address FROM saacc@cunyvm.cuny.edu TO saasci@sci.ccny.cuny.edu. I am losing mail because my reader is swamped. Also is there an archive site, digest or summary for this list? If so, please let me know where it is. Thanks. From dstamp@watserv1.uwaterloo.ca Sun Oct 20 20:28:38 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA07850 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 23:32:43 -0500 Received: by watserv1.uwaterloo.ca id <AA14274>; Mon, 21 Oct 91 00:28:38 -0400 Date: Mon, 21 Oct 91 00:28:38 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110210428.AA14274@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu jdb9608@cs.rit.edu (John D Beutel) replies: >That's what I'm wondering. If the samples are made at a constant >rate (like by the original hi-res routine), then are the samples that >the glove makes itself limited by this? I've listened to the clicks >that the glove makes while being sampled at a constant speed, >and I can't hear any difference between open and closed fingers. >I'm not sure I can tell the difference between 13 and 17 Hz, >but I suspect the glove has a constant sample rate when polled >with the original method, independent of finger position. Quite possible: I have'nt scoped the transmitter and glove read lines in the glove myself. I suspect that there *is* a small effect even if you read th glove at a constant rate, in terms of how often the glove is readable. What may happen is that the glove finishes reading the fingers ahead of time if the hand is open, then starts the next cycle either when the cycle timer expires (internal to the glove CPU) or it's asked for the data. This explains why you trash data if the glove is read too soon: there's nothing in the buffer yet to read, and the glove starts its next conversion cycle too soon. >must be synchronized with the glove polling. But, if the >fingers are open and there's only 58 ms between polls, >then that's all the time the graphics routines will have, >so they must be able to do their job in 58 ms. If the >fingers are closed and there's 80 ms between polls, then >the extra 22 ms will be wasted (unless the graphics can >be written to do the minimum rendering in 58 ms and some >worthwhile extra rendering if more time (up to 22 ms) happens >to be available). > >However, the whole point to sync'ing the code and the glove >is to avoid an average 30 ms extra lag time, so if the >original polling method adds any extra lag time to the >quick-polling method, then it may not be worth sync'ing >(or it may be worth accepting the wasted CPU time). > >– >J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." True, but the AVERAGE delay is reduced by reading the glove as fast as possible. In all likelihood it's going to be difficult to lock the video rendering to the glove read rate anyway, and the system will be asynchronous. If you double-buffer the video, the renderer ends up syncronized with the vertical sync of the video card (16.7 mS), so you have to choose between 4 (66.6mS) and 5 (83.3mS) display periods anyway. The REAL problem is going to be doing a decent job of rendering in the available time. It takes 82mS just to access each pixel once on a 320x200x256 color IBM PC mode picture in assembly language (some cards may be faster) although clearing it can be done in 22mS by reprogramming the hardware. THat means that unless wireframe graphics are used, we may have to use a lower resolution mode such as 320x200x16 color. Of course, partial screen updates reduce the time, but if the system uses eyephones, pretty much the whole scene must be redrawn when the user's head moves. In case you're not using an IBM, video access is less of a problem. However, the problem now becomes the other stages of rendering: deciding what gets shown and what is hidden. Assuming a "world" database of 3000 polygons, at LEAST 90% may have to be eliminated before rendering starts, so CPU power comes into the picture. Object-level clipping, partial screen updates, and scan-line drawing algorithms are just some of techniques that will be needed. (Scan-line algorithms attempt to access each pixel on the screen once per drawing.) As you can see, I'm thinking mostly about graphics problems right now. Issues such as how to represent polys, how many colors to use, Gorand shading and texturized objects (and other future considerations) depend on the type of rendering system chosen, as well as processor power and graphics hardware of the computer. BTW, using Gourand shading and textureing are practical, but both take a 30-40% "hit" in rendering performance. I'll try to throw up test ideas every now and then… I REALLY appreciate the feedback I'm getting on this. - Dave Stampe From sck@watson.ibm.com Sun Oct 20 19:38:47 1991 Received: from watson.ibm.com by karazm.math.UH.EDU with SMTP id AA07870 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Sun, 20 Oct 1991 23:43:12 -0500 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 3794; Mon, 21 Oct 91 00:38:59 EDT Received: from YKTVMZ by watson.vnet.ibm.com with "VAGENT.V1.0" id 1512; Mon, 21 Oct 1991 00:39:00 EDT Received: from cyst.watson.ibm.com by yktvmz.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Mon, 21 Oct 91 00:38:57 EDT Received: from biko.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA39032; Mon, 21 Oct 91 00:38:51 -0400 Received: by biko.watson.ibm.com (AIX 3.1/UCB 5.61/900524) id AA03471; Mon, 21 Oct 91 00:38:49 -0400 Message-Id: 9110210438.AA03471@biko.watson.ibm.com To: Shermane Austin SAACC@CUNYVM.CUNY.EDU Cc: glove-list glove-list@karazm.math.uh.edu, sck@biko.watson.ibm.com Subject: Re: please change my address In-Reply-To: (Your message of Sun, 20 Oct 91 23:56:51 EDT.) 199110210403.AA07736@karazm.math.UH.EDU Date: Mon, 21 Oct 91 00:38:47 -0500 From: Scott C. Kennedy (914) 945-1992 sck@watson.ibm.com from: Shermane Austin SAACC@CUNYVM.CUNY.EDU Please change my mailing address FROM saacc@cunyvm.cuny.edu TO saasci@sci.ccny.cuny.edu. I am losing mail because my reader is swamped. Also is there an archive site, digest or summary for this list? If so, please let me know where it is. Thanks. don't know of the archive list but, I have all the mail (minus the "subscribe-me") messages since it started. How much do you need? Scott From broehl@sunee.waterloo.edu Mon Oct 21 05:35:03 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA09531 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 08:39:16 -0500 Received: by sunee.waterloo.edu id <AA28796>; Mon, 21 Oct 91 09:35:05 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110211335.AA28796@sunee.waterloo.edu Subject: Revised code To: glove-list@karazm.math.uh.edu Date: Mon, 21 Oct 91 9:35:03 EDT X-Mailer: ELM [version 2.3 PL11] As promised, here's my (slight) revision to Dave Stampe's code. There are four files included below: glove.h – a header file newglove.c – the revised glove routines glovgraf.c – the (very simple) graphics demo makefile The latest version of these will always be available for anonymous ftp from sunee.waterloo.edu, in the pub/glove directory. ——————– CUT HERE – glove.h ——————————- /* GLOVE DATA SPECIFICATIONS The glove_data array has been simplified. These are its functions: x = X position, 3mm per number y = Y position, 3mm per number z = distance, 14mm per number rot = wrist twist. 0 is up 1 is slightly CW, 5 is down, 11 is slightly CCW. About 30 to 40 degrees per count. Note: exact scaling of all above change with distance! Closer is higher res. fingers = packed 2-bit values, 0 is open, 3 is (tight) fist: Bit format: TtIiMmRr for Thumb, Index, Middle, and Ring fingers. keys: $FF or $80 is no key. Responds with 0 to 9 for keys "0" thru "9" $82 = START, $83 = SEL, $0A = "A", $0B = "B", 0 is "Center" Up,down,left,right are $0D,$0E,$0C,$0F respectively. */ typedef struct glove_data { signed char x,y,z,rot,fingers,keys; } glove_data; /* prototypes */ void Hires (void); /* puts glove in hires mode */ void getglove (glove_data *); /* get data packet from glove */ int glove_ready(void); /* returns 0 if not ready */ void init_glove(int); /* puts glove into mode */ int read_glove(glove_data *); /* reads glove data, with de-glitching */ void reset_glove(void); /* release the glove */ /* Modes passed to init_glove(mode) */ #define LORES 0 #define HIRES 1 /* End of glove.h */ ———————– CUT HERE – newglove.c ————————– / Originally "power.c" © manfredo 9/91 (manfredo@opal.cs.tu-berlin.de) Developed on an ATARI 1040ST with TC 1.1 using a logic analyzer to get the correct timings. / /* ported to PC compatibles by Greg Alt 10/91 galt@peruvian.utah.edu or galt@es.dsd.com / /* Substantially rewritten by Dave Stampe © 1991: PWRFILT.C No cash, no warranty, no flames. This stuff works great, so gimme credit. Goals <achieved> were: Higher speed, smaller code. Polled operation is now possible. Graphics test (VGA) Noise reduction added, gets rid of 99.5% of noise with NO DELAY! This runs on a 486/25 with an i/o card. Someone should adapt it for the usual printer port adapter. It was compiled with Turbo C++ 2.0 but will probably work on any Turbo C directly. MSC will need library calls checked. dstamp@watserv1.uwaterloo.ca 17/10/91 / /* Re-converted to use printer port by Dave Stampe and Bernie Roehl. October 18, 1991. I also split off Dave's graphics code into a separate file, and put some of the stuff that was shared between the two into glove.h I also added a little judicious whitespace here and there to enhance readability, and made a whole bunch of globals static. I also added init_glove(mode) and glove_read(glov), the latter of which calls getglove(glov), deglitch(glov) and dehyst(glov). –Bernie, October 18-19 1991 / #define PC_PRINTER 1 /* use the PC Printer port for i/o */ #include <stdio.h> #include <dos.h> #include "glove.h" #define XHYST 2 /* hysterisis for X, Y low noise reduction */ #define YHYST 2 /* 2 eliminates +/-3 quanta of noise */ #define XACC 8 /* X, Y maximum accel/decel level. Should */ #define YACC 8 /* be 6-10, but too high limits gesturing */ #define XXTEND 2 /* stretches deglitching time */ #define YXTEND 1 #ifdef PC_PRINTER #define N 1 /* delay scaled by N/D */ #define D 2 #define INPORT 0x379 /* i/o port addresses */ #define OUTPORT 0x378 /* bits from parallel port */ #define GDATA 0x10 /* PG data in */ #define GLATCH 0x02 /* PG latch out */ #define GCLOCK 0x01 /* PG clock out */ #define GCLOLAT 0x03 /* clock + latch */ #define SHIFTVAL 4 /* shift data right 4 bits */ /* delay values for sending and sampling data */ #define D2BYTES 192 /* delay between 2 bytes 96 us */ #define D2BITS 10 /* delay between 2 bits 22 us */ #define D2SLOW 32760 /* 4 slow bytes in packet 14720 us */ #endif #ifdef DSTAMPE /* stuff from here down to #else is i/o card-specific */ #define N 1 /* delay scaled by N/D */ #define D 1 /* these are 1,1 for 486 PC with i/o card */ #define INPORT 0x2A0 /* i/o port addresses */ #define OUTPORT 0x2A0 /* bits for i/o ports */ #define GDATA 0x01 /* PG data in */ #define GLATCH 0x02 /* PG latch out */ #define GCLOCK 0x01 /* PG clock out */ #define GCLOLAT 0x03 /* clock + latch */ #define SHIFTVAL 0 /* don't shift */ /* delay values for sending and sampling data */ #define D2BYTES 150 /* delay between 2 bytes = 96 us */ #define D2BITS 6 /* delay between 2 bits = 3 us */ #define D2SLOW 8000 /* intertest delay = 2000-4000 us */ #endif /* Delay timing: may not work in some IBM C's due to problems with LONGs */ static void fdelay(unsigned int val) { register long i = N*val; for(; i > 0; i -= D) ; } void slowdelay() { fdelay(D2SLOW); } /* defines for output line pair control */ #define C0L0() outportb(OUTPORT, 0) /* clock 0 latch 0 */ #define C0L1() outportb(OUTPORT, GLATCH) /* clock 0 latch 1 */ #define C1L0() outportb(OUTPORT, GCLOCK) /* clock 1 latch 0 */ #define C1L1() outportb(OUTPORT, GCLOLAT) /* clock 1 latch 1 */ static unsigned char getbyte () /* read a byte from glove <rolled code> */ { register int i; register unsigned char x = 0; C1L0 (); /* generate a reset (latch) pulse */ C1L1 (); fdelay(D2BITS); /* hold for 5 us */ C1L0 (); for(i = 0; i < 8; i++) { x = x«1; x += 4) { unsigned long n; /* calibrate timing loop; note that instead of dividing by 18.2, we multiply by 5 now and divide by 91 later */ n = biostime(0, 0L); fdelay(1000000); /* divide by a milllion to get microfactor */ microfactor = (biostime(0, 0L) - n) * 5; if (mode == HIRES) Hires(); upcall = function; return HIRES; /* returns mode actually set */ } int glove_read(glove_data *glov) { getglove(glov); deglitch(glov); /* remove spikes and jumps */ dehyst(glov); /* add hysteresis to remove LL noise */ return 1; /* for now */ } void reset_glove() { upcall = NULL; } ——– glovgraf.c —————- /* Graphics-mode demonstration code for PowerGlove */ /* Written by Dave Stampe, Modified by Bernie Roehl, October 1991 */ #include <dos.h> #include <bios.h> #include <stdio.h> #include <conio.h> #include <graphics.h> #include "glove.h" int gdriver = DETECT; /* for graphics plot and cursor */ int gmode = VGAHI; void main() { glove_data glov; /* glove data */ unsigned unready; /* number of unsuccessful tries to read glove */ void drawp(), drawthing(); initgraph(&gdriver, &gmode, ""); if (graphresult() < 0) { printf("could not initialize graphics\n"); exit(1); } cleardevice(); restart: init_glove(HIRES, NULL); while(!kbhit()) { unready = 0; /* start polling glove */ slowdelay(); while(glove_ready()==0) /* wait for glove to become ready */ { if (unready++>500) /* reset mode if dead glove */ goto restart; slowdelay(); } glove_read(&glov); /* read 6 byte packet */ #ifdef DEBUG drawp(&glov); /* plot x,y positions */ #endif drawthing(&glov); /* animate glove cursor */ } getch(); /* exit when keyboard hit */ reset_glove(); textmode(LASTMODE); } static void drawit(glove_data *g) /* draw/erase box cursor */ { int x = 320+2*(g→x); /* compute X,Y center */ int y = 240-2*(g→y); int z = 30+(g→z); /* size prop. to Z */ rectangle(x-z,y-z,x+z,y+z); } static glove_data oldbuf; /* used to store old state for drawing */ static int drawn = 0; /* set if cursor to be erased */ void drawthing(glove_data *g) /* draw square cursor */ { if(g→keys==2) return; /* hold down "2" to stop drawing */ if(drawn) /* erase old box */ { setcolor(0); drawit(&oldbuf); } setcolor(15); /* draw new box */ drawit(g); drawn = 1; oldbuf.x = g→x; /* save pos'n for next erase */ oldbuf.y = g→y; oldbuf.z = g→z; } static int xx = 0; /* plot position */ void drawp(glove_data *g) /* plot X,Y data to test smoothing */ { if(g→keys==4) /* restart at left edge if "4" pressed */ { cleardevice(); xx=0; } setcolor(0); line(xx,0,xx,479); line(xx+1,0,xx+1,479); setcolor(15); line(xx,240-2*g→x,xx+1,240-2*g→x); setcolor(12); line(xx+1,240-2*g→y,xx+2,240-2*g→y); xx++; xx++; if(xx > 639) xx = 0; } ————- test.c —————- #include <stdio.h> #include "glove.h" void main() { glove_data glov; /* glove data */ unsigned unready; /* number of unsuccessful tries to read glove */ restart: init_glove(HIRES, NULL); while(!kbhit()) { unready = 0; /* start polling glove */ slowdelay(); while(glove_ready()==0) /* wait for glove to become ready */ { if (unready++>500) /* reset mode if dead glove */ goto restart; slowdelay(); } glove_read(&glov); /* read 6 byte packet */ printf("%3.3d %3.3d %3.3d %2.2d %02.2X %02.2X \r", glov.x, glov.y, glov.z, 255&glov.rot, 255&glov.fingers, 255&glov.keys); } reset_glove(); } ——— makefile ———- test.exe: test.obj newglove.obj tcc test.obj newglove.obj glovgraf.exe: glovgraf.obj newglove.obj tcc glovgraf.obj newglove.obj graphics.lib glovgraf.obj: glovgraf.c glove.h tcc -c glovgraf newglove.obj: newglove.c glove.h tcc -c newglove test.obj: test.c glove.h tcc -c test From dstamp@watserv1.uwaterloo.ca Mon Oct 21 14:08:26 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA13428 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 17:12:57 -0500 Received: by watserv1.uwaterloo.ca id <AA13846>; Mon, 21 Oct 91 18:08:26 -0400 Date: Mon, 21 Oct 91 18:08:26 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110212208.AA13846@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu I am posting this as a word of encouragement to garage VR folk, and as a benchmark to judge prospective equipment against. I apologize in advance if I seem to be disparaging about equipment or performance of software: I am stating numbers as I have them (mostly from the source below, and some from assorted research, technical documents too long misplaced to give references to, and personal experience). Feel free to correct me, but be sure you are looking at the same aspects I am (i.e average case vs. worst/best case). The following is from "Reality Built for Two: A Virtual Reality Tool" in Computer Graphics journal by C. Blanchard et al from VPL. It is a 2 page article, and the 2 most relevant paragraphs are quoted here in full, with some of the other equipment mentioned summarized later on. *>The Eyephone: *> *>The Eyephone consists of 2 color LCD monitors viewed using a LEEP optical *>system. Proprietary diffusion techniques are used to merge the distinct *>pixels od the LCD into a continuous image. and to reduce conflicts between *>depth of field and stereo cues. A high resolution dot pattern is *>superimposed over the image to improve percieved resolution. *> *>Each monitor is driven by the image rendered by one of the Irises. *>(Silicon Graphics 4D-80 GT, 2 per user). The monitors and optics are *>mounted in a soft, counterweighted headdress which has physical and *>psychological advantages over the more rigid and intimidating helmet *>mounted displays. I've had the opportunity to work with the LEEP optical systems. They give a WIDE (90 degrees is possible, 100 degrees is *quoted*) field of view, but distort the image. The distortion is fixed by using an undistorting lens and camera mounted on the IRIS monitor. Now, maybe VPL has gotten around this somehow, but they don't say… The pixels in a LEEP display look about as big as the nail on your pinky at arm's length. (1/2 to 1/3 of a visual degree) The resolution (actually USED area) of the LCD in the Eyephone is 280 by 240 pixels at most. The "proprietary diffusion" seems to be a rather simple diffuser, needed to smear the RGB bands in the LCD panel out, and to prevent contrast band effects having to do with the limited view angle of the LCD panels. The stereo conflict stuff just means that the diffused picture ALWAYS looks out-of-focus. Those dots will probably cause the problem all over again. As for the headband, when I worked with these displays I discarded it because it couldn't hold the displays steady enough, and replaced it with a frame and a pilot's helmet. Worked great, but was a little hard to get on and off. If I'm working with a $18,000 ($24,000 color) set of displays, I don't want them falling off my head! *>System Performance: *> *>Using Silicon Graphics 4D-80 GT's as rendering engines we are currently able *>to render worlds with approximately 1400 simultaniously viewable polygons, *>including a high percentage of many-sided and concave polygons, at *>interactive rates of 10 Hz or greater. The total number of polygons in *>a virtual world may exceed this limit when you break the world into *>visibly discreet chambers limiting the number of polygons you can see at *>one time. Hmm, that poly count is hard to interpret. If we translate it into 2000 quadrilaterals, we probably are not underestimating things. The "simultaneously viewable" phrase either means the *possible* viewable set of objects from any position (i.e the "chambers" mentioned later) or the number of polys not clipped by viewpoint and sent to the Irises to be rendered. I suspect it is the former, so the number of polys actually sent to the Iris for rendering might be 1000 or so. The idea of "chambers" is a primitive way of pruning the rendering input. I suspect that the 1000-poly count is *way* higher than what the renderer in a well-designed 3D video game would have to handle, given the same world to draw. (No solid data on this, but Jez San claims to handle a 20,000 poly world on a 386 PC at a goodly frame rate…). Also, by reducing the viewport size from 80 by 100 degrees down to a garage-VR size viewport (suitable for simple eyephone optics) of 40 by 50 degrees, the area (and number of polys) is reduced by a factor of 4. So, 300 polys MIGHT be a good upper-limit for the renderer. That still means we need good "front-end" software to tell the renderer what to draw. I believe this number is quite achievable on a home system. A SUMMARY OF OTHER EQUIPMENT MENTIONED: The DataGlove, of course. Its problems and frailty has been summarized by others. The world model is updated by a Mac II (sorry, no info on what model) which talks to the Irises by Ethernet. The glove position (palm and tip of index finger) and the Eyephone unit angle and position are returned by a Polhemus Isotrak magnetic tracking system. As I recall, the sampling rate on an Isotrak is 80/(# inputs) so that's about 26 samples/sec, assuming 1 isotrak per user. The Pohemus sensors suffer from some of the same noise and glitch problems as the Powerglove's sensors. They don't have to be pointed at the receiver array, but they suffer from distortion from any nearby metal object (screws, desks, you name it). CONCLUSION In relation to these numbers, achievable results from the garage VR project don't look terribly bad. I think the point is that any system has its drawbacks and tradeoffs, and current high-end VR systems have their share. The difference is that they can throw money at a problem and buy off-the-shelf equipment to save time, whereas the "garage" VR folk have to make do. In the end, I think we will compare well. DISCLAIMER: Consider this a first draft, shown to collegues for criticism and evaluation. There is NOTHING implied about the companies mentioned here: just an evaluation from my POV. Discussion invited. -Dave Stampe From cit@comp.vuw.ac.nz Mon Oct 21 18:05:20 1991 Received: from mailhost.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz) by karazm.math.UH.EDU with SMTP id AA15148 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 18:05:20 -0500 Received: from cit by mailhost.comp.vuw.ac.nz with 5.65cVUW/4.59 id AA10366@mailhost.comp.vuw.ac.nz; Mon, 21 Oct 1991 19:01:09 -0400 Received: from cit1.cit.ac.nz by cit2.cit.ac.nz id aa00944; Mon, 21 Oct 91 17:38:40 NZT From: frankv@cit.ac.nz (Tutor) X-Mailer: SCO System V Mail (version 3.2) To: glove-list@karazm.math.uh.edu Date: Mon, 21 Oct 91 17:41:29 NZT Message-Id: 9110211741.aa05529@cit1.cit.ac.nz Commenting on Dave Stampe's suggestions for a standard PowerGlove interface: > I would like to define the minimum functionality as: > - initialize with one call, which enters hi-res mode, sets up a timer interrupt every 4 mS, and initializes the code. > - an interrupt handler which: > - polls the glove for $A0 start code, exits if not ready > - if the glove was not ready after 500 tries, resets the glove mode > - reads the 6-byte data packet, and 2 more throwaway bytes > - deglitches and denoises the X and Y data (deglitches Z???) > - stores the data int the glove_int_data buffer > - sets the glove_int_data.new flag > - a glove_read routine which: > - disables interrupts > - copies the glove_int_data (including .new flag) to buffer > - clears the glove_int_data.new flag > - enables interrupts > - a reset routine (onexit(?)) which resets the timer interrupt > It is probably worthwhile to have a LORES and HIRES mode set on > initialization, which means that only the .keys data field is valid. > The timer interupt would happen less often, to reduce CPU interrupt > load. Total CPU load on a 386 looks to be about 3%. > Proposed names for routines: > int init_glove(int mode) > #define LORES 0 > #define HIRES 1 > void reset_glove() > int glove_read(glove_data *) /* returns 0 if old, 1 if new data */ > If we try to keep some interface stuff the same, everyone can develop > code for their machine that meets the specs. Then they can either be > combined or distibuted seperatly. I think this is a great idea. Here's my $0.02 worth: 1. Define what each function must do, not how to do it – leave it as a black box. I intend to communicate with a glove-controller built here (when its done) via an RS-232 interface. In which case all this talk about interrupts is irrelevant. 2. I'd rather call change the name of reset_glove() to glove_quit() – reset implies to me get ready to start, not get ready to exit the program. Frank. From cit@comp.vuw.ac.nz Mon Oct 21 18:05:23 1991 Received: from mailhost.comp.vuw.ac.nz (kaukau.comp.vuw.ac.nz) by karazm.math.UH.EDU with SMTP id AA15149 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 18:05:23 -0500 Received: from cit by mailhost.comp.vuw.ac.nz with 5.65cVUW/4.59 id AA10361@mailhost.comp.vuw.ac.nz; Mon, 21 Oct 1991 19:01:02 -0400 Received: from cit1.cit.ac.nz by cit2.cit.ac.nz id aa00942; Mon, 21 Oct 91 17:38:22 NZT From: frankv@cit.ac.nz (Tutor) X-Mailer: SCO System V Mail (version 3.2) To: glove-list@karazm.math.uh.edu Date: Mon, 21 Oct 91 17:41:11 NZT Message-Id: 9110211741.aa05523@cit1.cit.ac.nz > Hey, thanks for the 320x400x256 code fragment! I had already figured out how > get that resolution, and how to get 2 pictures, but I couln't figure out how > to write the pictures without leaving the mode. (A bit misleading, calling > SC#4 bit 3 "odd/even"!) A bit expensive in time, constantly changing the plane > write register, though. Guess I'll have to figure out another damn 4-pass > write algorithm. (B-{) You don't think I actually write stuff using that display_pixel() routine, do you ;-) That was just an example showing how to calculate addresses, etc. The following fragment reads a file (produced by a ray-tracer followed by quantising) which contains the four "planes" in order. Note that setting the mask variable to F00, E00, C00, 800 writes the first "plane" to all 4 planes in the VGA, the 2nd to planes 2-4, etc. That fills the screen with a chunky image, then progressively neatens it up. Alternatively you could initialise mask to 100, which gives a vertical stripe effect. void display_320x400() { int plane, mask; char far *base; setvgapalette(&palette, colours); base = (char far *)0xa0000000L; mask = 0xf00; for (plane = 0; plane < 4; plane++, mask «= 1) { outport(SC_INDEX, (mask & 0xf00) | MAP_MASK); fread(base, 400 * (320/4), 1, fp); } } > I think that VR applications would be better served by using 4 pages of > 200 lines, as that cuts down the rendering time and allows double buffering. I'm coming to the same conclusion: 320*200 gives a single-plane memory map with corresponding benefits. Also, the size of the image is less than 64K, giving benefits in address calculations.. I'm not sure whether double-buffering of both images is needed – update the right-eye view while displaying the left-eye view may work. > Any comments on using 16-color modes for even faster rendering? Is there > ANY way that so few colors is sufficient for filled-poly VR work? I think that 16-colour (sorry to correct you spelling here :-) would be worse, since each pixel (as far as I can tell) is represented by 1 bit in each of 4 bytes (remember the planes). Lots of bit-shuffling and ANDing and ORing required too. Unless you're just flipping entire frames up, 1 byte/pixel has to be better. I can't comment on how many colours are needed for "filled-poly VR" – I'm not familiar with that area. However, MS Flight Simulator does a respectable job of displaying 3D material using only 16 colours. > Which brings up the topic of reprogramming VGA cards to achieve new > resolutions and timings. Cheap LCD displays are going to need this to > work properly. I did some work last summer on getting NTSC timings to > run Sharp LCD panels, but I had to add a new clock source via the VGA > feature connector. Any idea how cards from different manufacturers > handle radical reprogramming of the registers? Is the timing (i.e. > blanking period) and "screwy" video modes reliable across all cards? I don't know much about LCDs and VGAs. "My" 320x400 routine was simply translated from assembler written by Michael Abrash in Programmers Journal. He commented there that 320x400 should work on all VGA cards. Frank. From motcsd!roi!lance@apple.com Fri Oct 21 04:50:21 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA15316 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 19:06:55 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA00684; Mon, 21 Oct 91 16:02:05 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZ4lO-0001FJC@motcsd.csd.mot.com; Mon, 21 Oct 91 11:54 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA07291; 21 Oct 91 11:50:22 PDT (Mon) To: glove-list@karazm.math.uh.edu Subject: Re: Dataglove 2 and the SGI Message-Id: 9110211150.AA07287@roi.ca41.csd.mot.com Date: 21 Oct 91 11:50:21 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com Get the Graphics Interface '90 proceedings. Chris Shaw and his cohort whose name I've forgotten have a lot of sage advice on this in "The DataPaper". They also have a toolkit they're planning to release soon. Shaw posts here and on sci.v-w a lot. Lance Norskog From motcsd!roi!lance@apple.com Fri Oct 21 08:14:42 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA15332 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 19:15:29 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA04114; Mon, 21 Oct 91 16:20:29 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZ7xE-0001FYC@motcsd.csd.mot.com; Mon, 21 Oct 91 15:18 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA10177; 21 Oct 91 15:14:45 PDT (Mon) To: jdb9608@cs.rit.edu Subject: Re: sampling techniques and response time Cc: glove-list@karazm.math.uh.edu Message-Id: 9110211514.AA10165@roi.ca41.csd.mot.com Date: 21 Oct 91 15:14:42 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com I think the amount of time control that you want to achieve in glove interaction will only be available with an outboard CPU controlling the glove. The XYZ numbers are inaccurate, and the finger resistors are useless for gesture recognition. With an outboard CPU hooked directly to the cable between the glove box and the hand stuff, you can trigger the spatial sensors for your schedule, and get several bits' resolution out of the fingers. Lance Norskog From motcsd!roi!lance@apple.com Fri Oct 21 06:54:28 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA15367 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Mon, 21 Oct 1991 19:18:21 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA03823; Mon, 21 Oct 91 16:18:52 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZ6hQ-0001QyC@motcsd.csd.mot.com; Mon, 21 Oct 91 13:58 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA09357; 21 Oct 91 13:54:29 PDT (Mon) To: dstamp@watserv1.uwaterloo.ca Subject: IBM graphics performance Cc: glove-list@karazm.math.uh.edu, glove-list@karazm.math.UH.EDU Message-Id: 9110211354.AA09353@roi.ca41.csd.mot.com Date: 21 Oct 91 13:54:28 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com > I think I see the problem here. The difference is between the IBM and Amiga > designs. Any real graphics work on the IBM PC requires multiple I/O space > accesses with inportb() and ouportb() type routines. Since most of the > available C compilers do not replace these with inline code, this results > in much slower operation than with assembly code. Also, many of the good > instructions on the 80x86 (such as LOOP or REP STOSB) are not used by > compilers. Again, assembly code is the only solution. Nope! The IBM PC bus was designed to be cheap, and support text. It was not designed with NTSC video bandwidth in mind, while the Amiga was. The hardware is at fault, not the software. The Toaster people said they can't port to the PC because it's 7 times too slow. The PC VR software is going to have use scan-line techniques, or paint in real RAM and copy that into the VGA frame buffer. Multiple touches of the same pixel would be the kiss of death. Actually, the 8514/A clone cards are appearing mass-market for $500 from Western Digital etc. These things include a raft of 2D graphics commands which you just poke at it and go away. They have a limited range of RAM buffering techniques, and thus can possibly do double buffering for animation but can't do quad-buffering for stereo animation. This is why I don't have one. But for high-res non-stereo work, they might make the nut. Also, they might support two cards in one machine but I don't think so. One of these cards might supply a very nice environment for stop-motion stereo or monoscopic animation. Lance Norskog From motcsd!roi!lance@apple.com Fri Oct 21 09:49:43 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA15446 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 19:34:29 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA11160; Mon, 21 Oct 91 17:07:40 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZ9R4-0000ZCC@motcsd.csd.mot.com; Mon, 21 Oct 91 16:53 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA12016; 21 Oct 91 16:49:46 PDT (Mon) To: menelli@tellabs.com Subject: PG controller board Cc: glove-list@karazm.math.uh.edu Message-Id: 9110211649.AA12004@roi.ca41.csd.mot.com Date: 21 Oct 91 16:49:43 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com This is excellent! The software interface provided in high-res mode is pretty weak. For serious work I would much prefer your outboard controller. I have some software that does continuous gesture recognition for mice, based on characterizing two single input streams. It mentions something about doing gloves via multiple streams. I can't use it with the glove because it only does 2 bits. (The software is on emsworth.andrew.cmu.edu in /gestures. It's by Dean Rubine, see the SIGGRAPH '91 proceedings.) A point: the serial port approach does involve delays. A parallel port version would cut that down even farther. Does the Motorola evaluation board include enough parallel lines to make this possible? A parallel version would only involve one interrupt per sample, and short polling loops. Another point: I would want a mode where the controller board did as little interpretation as possible. Just feed the raw counters in and let the big CPU with floating point handle X,Y,Z,rot issues. A third point: does the Motorola chip include timers? A global timestamp, based on the start of the sample cycle in the board, would be very useful for doing synchronization work. There are algorithms for dealing with irregularly spaced input streams; a prediction algorithm would need accurate timestamps to operate properly. Lance Norskog From motcsd!roi!lance@apple.com Fri Oct 21 09:25:01 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA15462 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Mon, 21 Oct 1991 19:37:14 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA11117; Mon, 21 Oct 91 17:07:18 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZ93F-0000XzC@motcsd.csd.mot.com; Mon, 21 Oct 91 16:28 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA11601; 21 Oct 91 16:25:03 PDT (Mon) To: dstamp@watserv1.uwaterloo.ca Subject: Re: IBM graphics performance Cc: glove-list@karazm.math.UH.EDU Message-Id: 9110211625.AA11595@roi.ca41.csd.mot.com Date: 21 Oct 91 16:25:01 PDT (Mon) From: Lance Norskog lance@roi.ca41.csd.mot.com Dave Stamp says: > I think I see the problem here. The difference is between the IBM and Amiga > designs. Any real graphics work on the IBM PC requires multiple I/O space > accesses with inportb() and ouportb() type routines. Since most of the > available C compilers do not replace these with inline code, this results > in much slower operation than with assembly code. Also, many of the good > instructions on the 80x86 (such as LOOP or REP STOSB) are not used by > compilers. Again, assembly code is the only solution. Nope! The IBM PC bus was designed to be cheap, and support text. It was not designed with NTSC video bandwidth in mind, while the Amiga was. The hardware is at fault, not the software. The PC VR software is going to have use scan-line techniques, or paint in real RAM and copy that into the VGA frame buffer. Multiple touches of the same pixel would be the kiss of death. Actually, the 8514/A clone cards are appearing mass-market for $500 from Western Digital etc. These things include a raft of 2D graphics commands which you just poke at it and go away. They have a limited range of RAM buffering techniques, and thus can possibly do double buffering for animation but can't do quad-buffering for stereo animation. This is why I don't have one. But for high-res non-stereo work, they might make the nut. Also, they might support two cards in one machine but I don't think so. One of these cards might supply a very nice environment for stop-motion stereo or monoscopic animation. I remember now. They do one buffer in 256-color mode and two buffers in 16-color mode. Classic IBM stupidity. Lance Norskog From dejavu!salnick@tau-ceti.isc-br.com Sun Oct 20 22:36:16 1991 Received: from tau-ceti.isc-br.com by karazm.math.UH.EDU with SMTP id AA15807 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 21:00:36 -0500 Received: by tau-ceti.isc-br.com (/\==/\ Smail3.1.21.1 #21.13) id m0kZAQg-0000dwC@tau-ceti.isc-br.com; Mon, 21 Oct 91 17:57 PDT Received: by dejavu.spk.wa.us (V1.13/Amiga) id AA05682; Mon, 21 Oct 91 06:36:16 PST Date: Mon, 21 Oct 91 06:36:16 PST Message-Id: 9110211436.AA05682@dejavu.spk.wa.us From: salnick@dejavu.spk.wa.us (Bob Salnick) To: glove-list-request@karazm.math.uh.edu Cc: glove-list@karazm.math.uh.edu Subject: Re: Interfaces to VR devices > We could have some set of operations/functions that all interfaces > should support, either using the hardware feature or simulating it in > software. Then any application that uses only that basic set of > operations will work with any device. Then, there would be options > unique to a specific device. These interfaces would still support the > basic standard, but add on some new function calls. Then a program may > be written that requires a specific device. > > Something like we have with modems. There is a basic command set (hayes > AT set) for neccessary things like RESET, DIAL, ANSWER, HANGUP, etc. > Any software that uses only these commands will work with most modems. > Then there are optional things some modems have, like MNP COMPRESSION, > protocols, interface speed locking, buffers, etc. A program can use > these features but then it will not work with other modems. A greate analogy might be the input equivalent to the way the Amiga handles the printer: There is one device which all software talks to: the PRT: device. This device is able to handle what ever printer is attached - to take advantage of whatever functions the printer contains. Software which wants to print graphics, for example, will be told that this capability does not exist if a daisy wheel printer is attached. To work in this faxhion, the software has to be broken into two parts - the GLOVE: device, and the driver for the particular glove attached. (In general, I would suggest that the device be called INPUT: since assuming a glove may be inappropriate for the future.) bob Bob Salnick, Spokane,WA | USENET: oliveb!isc-br!tau-ceti!DejaVu!salnick Amiga 1000, WB 1.3 | INTERNET: salnick@DejaVu.spk.wa.us WA9BVE | (FireStorm '91 survivor) From dstamp@watserv1.uwaterloo.ca Mon Oct 21 19:04:44 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA16056 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 22:08:50 -0500 Received: by watserv1.uwaterloo.ca id <AA01211>; Mon, 21 Oct 91 23:04:44 -0400 Date: Mon, 21 Oct 91 23:04:44 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110220304.AA01211@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Lance replied to a lot of my postings, so instead of a lot of little postings, I'll try to handle them in one loner one: From: Lance Norskog lance@roi.ca41.csd.mot.com >Dave Stamp says: > » I think I see the problem here. The difference is between the IBM and Amiga » designs. Any real graphics work on the IBM PC requires multiple I/O space » accesses with inportb() and ouportb() type routines. Since most of the » available C compilers do not replace these with inline code, this results » in much slower operation than with assembly code. Also, many of the good » instructions on the 80x86 (such as LOOP or REP STOSB) are not used by » compilers. Again, assembly code is the only solution. >Nope! The IBM PC bus was designed to be cheap, and support text. >It was not designed with NTSC video bandwidth in mind, while the >Amiga was. The hardware is at fault, not the software. I was referring to programming style as dictated _by_ the hardware, not the hardware per se. >The PC VR software is going to have use scan-line techniques, or >paint in real RAM and copy that into the VGA frame buffer. Multiple >touches of the same pixel would be the kiss of death. Exactly what I plan to do: use scan-line algorithms. They have a big advantage over other methods in that they write each pixel once and degrade gracefully with increasing numbers of polys. The amount of optimization possible is pretty awesome. Also, since you're drawing each poly once, Gourand shading and texture mapping become less expensive. Copying a buffer to the VGA card wastes more time than it saves unless you're doing really wierd things that require multiple accesses to each pixel. In this case, it's not warranted. >Actually, the 8514/A clone cards are appearing mass-market for $500 >from Western Digital etc. These things include a raft of 2D graphics >commands which you just poke at it and go away. There are a couple of problems with the 8514/A cards. First, using new hardware violates the cheapness constraint on the system: less people can get involved. Second, as you pointed out, flexibility is less: video modes can't be chosen easily. Third, when you consider the time used up stuffing the command FIFO versus the draw time, the performance advantage for a scan-line renderer is pretty low, as you're just drawing horizontal line segments. Of course, if you're doing wireframe… <in reference to my clipping message, which proposes a drawing rate of >300 polys in 100 mS… or was it my database size of 10,000 polys?> >I think you're off by an order or two of magnitude. >But I have no hard numbers. No, that's the beauty of the algorithm I'm working on! I should get AT LEAST 200 polys per rendering cycle, and if I use 320x200x16 mode, it takes about 50 mS– plenty of time for the poly database processing. I'm off by AT MOST a factor of 2. >You should also consider that background walls and floors can be done >by pre-rendering them onto pixmaps, then resampling the pixmaps >onto the screen first. Then, start drawing your wire-frames or >filled polygons. Yes, it is a possibility, IF you're using textures. But this requires "touching" each pixel twice… Perhaps these areas could be copied out of a buffer by the scan-line renderer where no polys cover. >Again, check out BSP in the Computer Graphics book, and >the ASP in Graphics Interface '90. These are the front-runners >for repetitive polygonal database update methods. I have checked out these methods and, IMHO, they are not as useful as they appear. They are best used to depth-sort polys for schemes that draw ALL the polys over and over again. They can help with object- level rejection in the "front end" of the renderer, but no further. The keyword is "repetitive" and we can't afford that on this machine. I suspect even the Amiga starts getting into problems, as drawing a poly takes significant CPU intervention to keep the hardware fed with all those horizontal line commands that the Amiga's hardware supports. Plus, as soon as you go to Gourand shading or texture mapping, it all has to be done by the CPU anyway. < a comment on the proposed glove interface > >A tip: it will be much easier to get this stuff working right if >you encode the whole process, both hi-res-mode-init and the >polling loop, into a finite state machine. Your TSR can then >just do a case statement to decide what to do. It's a little >tougher to code than by hand, but it's the only way to fly >in an interrupt-driven environment. This isn't TSR code though: nor is it a device driver. This is to be linked into a C program. There really IS only one path through interrupts, with early termination if the glove isn't ready yet. I don't understand _why_ a state machine should be tougher– it's just an implementation decision after all. Thanks for the feedback. Can you please include at least the gist of the original message? I had trouble figuring out which one you were replying to. Ahh, the perils of asynchrony (B_{). ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From corp@gargoyle.uchicago.edu Mon Oct 21 18:15:12 1991 Received: from gargoyle.uchicago.edu by karazm.math.UH.EDU with SMTP id AA16323 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 23:19:17 -0500 Received: by gargoyle.uchicago.edu (4.0/1.14) id AA29037; Mon, 21 Oct 91 23:15:12 CDT Date: Mon, 21 Oct 91 23:15:12 CDT From: E. Corp Reed corp@gargoyle.uchicago.edu Message-Id: 9110220415.AA29037@gargoyle.uchicago.edu To: glove-list@karazm.math.uh.edu Subject: Long Postings. Could people with long postings please put Control-L's in their postings. It saves the lives of those (like me) who have real fast ™ modems and don't want to make coffee during source listings. -C Reed e-reed@uchicago.edu From ralph@aplcen.apl.jhu.edu Mon Oct 21 20:17:19 1991 Received: from aplcen.apl.jhu.edu by karazm.math.UH.EDU with SMTP id AA16357 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 23:21:25 -0500 Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA26638; Tue, 22 Oct 91 00:17:19 -0400 Date: Tue, 22 Oct 91 00:17:19 -0400 From: ralph@aplcen.apl.jhu.edu (Ralph Roland) Message-Id: 9110220417.AA26638@aplcen.apl.jhu.edu To: glove-list@karazm.math.uh.edu Subject: Question about the PG Bieng new to this group, I was hoping somebody could answere a question for me… I just purchased a PowerGlove, and have been playing around with the Hires Code made available on this list, and have been experiencing the following problem: When the Glove is centered and held at arms length pointing toward the center of the 'sensor-array' x-y-z are reading 0,0,0 (close enough anyway). If I then bend my arm at the elbow (towards the left), rotating the glove around the z-axis (theoretically keeping the glove 'on' the x-y plane), the x-coord decreases (as it should), the z-cooord increases (as it should), but the y-coord also increases. The y-coord increases to about 0x30 by the time the sensors are out of the Field-of-View of the glove. If the same procedure is followed, except the rotation is to the right (much harder on the elbow I might add), the y-coord decreases in a similar manner. This finally brings me to my question: Does the PowerGlove *ALWAYS* screw-up the Y-coordinate, or did I just manage to purchase a flakey unit? Thanks in Advance for any light you may be able to shed… Ralph Roland From LEEK@QUCDN.QueensU.CA Mon Oct 21 19:44:00 1991 Received: from QUCDN.QueensU.CA by karazm.math.UH.EDU with SMTP id AA16629 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 23:48:58 -0500 Message-Id: 199110220448.AA16629@karazm.math.UH.EDU Received: from QUCDN.QueensU.CA by QUCDN.QueensU.CA (IBM VM SMTP V2R1) with BSMTP id 6898; Tue, 22 Oct 91 00:45:27 EDT Received: by QUCDN (Mailer R2.08) id 2997; Tue, 22 Oct 91 00:45:25 EDT Date: Mon, 21 Oct 1991 23:44 EDT From: LEEK@QUCDN.QueensU.CA To: glove-list@karazm.math.uh.edu Subject: Re: Power glove standardization Here is my 2 pennies worth of ideas on standardization of similiar glove inputting device… I think standardization is a good thing. I would like to suggest to move away from the powerglove data structure as it seriously limits the possible type of performance for future devices. Some obvious limitations is the # of bits per finger and the rotational angle resolution. One can easily get 6-7 bit of resolution if one simply replaces the Glove CPU and add $3.00 worth of hardware. At the moment, the glove data structure might seem more convient. I just think it is worth while to set a proper standard. I would also like to add a new function for the glove. This function is to be called after initialization. This informs the host program of the capabilities of the input device. The host program can then perform the necessary transformation(s) required to the input packet stream. Inquire_Glove(); This function returns a pointer to a structure that contains the following: count - this tell the program how many words are there in a packet wordsize - the word size used in packet:byte,int,long tags - this points to an array of tags that describe what each of the words in the packet are for and what is the maximum ranges of data to be expected. Tags array: Name - a char string with ASCII text identifying the corresponding word in the packet eg. "Finger 1", "Receiver 1", "Distance X", "Rotation" The ASCII text would have to be standardized. New tags can be added for future devices as they becomes 'available'. Programs would only read off tags that they understands and ignore the rest. Try to make it obvious and understandable by someone else. Avoid using obscure short form for tags as they make guess at it difficult and some programmers (like me) likes to use the tag as part of the items on menus (when they make sense) Max - The maximum upper limit of the corresponding word in the packet. (eg. Max = 12 for the rotation from the glove. For others, it might be 360 for 1 degree resolution. ) The function Read_Glove() would now return a pointer to a packet of size count*wordsize bytes. If any of the data in the packet is > than their corresponding Max values, that means that piece of data is unavailable for the current sample. (eg. One of the receiver misses) It might also be possible to have the inquire function return a second tags array describing the possible operating modes available from the glove. eg. possible modes: "Joystick", "X,Y,Z,Rot,Fingers", "Raw", "Sample on demand", "Sample rate". An extra function is used to set the glove into one or more operating modes. The program might also ask the glove to only include a selected list of data in each packet. (ie. The program get what it wants, not everything the glove gets. This is to lower the overhead of data communication between the host and the glove.) I hope I have not gone way of tangent here. I feel if we are going to have a standard here, then we should do it right ie. not to limit ourselves to a particular product or model (eg to save 5 machine cycles) , allow for expansion in terms of new devices and/or higher resolution. Some of the hard coder there might want to argue efficiency with me about the extra processing required… To me programming in bare metal refers to laying out the transistor connections in a custom chip that performs the equivalent software function. :) If I want speed, I'll build some hardware for the task. As for the interrupt/poll, leave it to the particular machine. I like the device model on my Amiga that provides both sync & async I/O. Why force your particular model (TSR, Interrupt, Polling, Multitasking) on others ??? K. C. Lee Elec. Eng. Grad. Student From dstamp@watserv1.uwaterloo.ca Mon Oct 21 21:22:52 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA17189 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 00:26:58 -0500 Received: by watserv1.uwaterloo.ca id <AA09387>; Tue, 22 Oct 91 01:22:52 -0400 Date: Tue, 22 Oct 91 01:22:52 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110220522.AA09387@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Lance replied to a lot of my postings, so instead of a lot of little postings, I'll try to handle them in one loner one: From: Lance Norskog lance@roi.ca41.csd.mot.com >Dave Stamp says: > » I think I see the problem here. The difference is between the IBM and Amiga » designs. Any real graphics work on the IBM PC requires multiple I/O space » accesses with inportb() and ouportb() type routines. Since most of the » available C compilers do not replace these with inline code, this results » in much slower operation than with assembly code. Also, many of the good » instructions on the 80x86 (such as LOOP or REP STOSB) are not used by » compilers. Again, assembly code is the only solution. >Nope! The IBM PC bus was designed to be cheap, and support text. >It was not designed with NTSC video bandwidth in mind, while the >Amiga was. The hardware is at fault, not the software. I was referring to programming style as dictated _by_ the hardware, not the hardware per se. >The PC VR software is going to have use scan-line techniques, or >paint in real RAM and copy that into the VGA frame buffer. Multiple >touches of the same pixel would be the kiss of death. Exactly what I plan to do: use scan-line algorithms. They have a big advantage over other methods in that they write each pixel once and degrade gracefully with increasing numbers of polys. The amount of optimization possible is pretty awesome. Also, since you're drawing each poly once, Gourand shading and texture mapping become less expensive. Copying a buffer to the VGA card wastes more time than it saves unless you're doing really wierd things that require multiple accesses to each pixel. In this case, it's not warranted. >Actually, the 8514/A clone cards are appearing mass-market for $500 >from Western Digital etc. These things include a raft of 2D graphics >commands which you just poke at it and go away. There are a couple of problems with the 8514/A cards. First, using new hardware violates the cheapness constraint on the system: less people can get involved. Second, as you pointed out, flexibility is less: video modes can't be chosen easily. Third, when you consider the time used up stuffing the command FIFO versus the draw time, the performance advantage for a scan-line renderer is pretty low, as you're just drawing horizontal line segments. Of course, if you're doing wireframe… <in reference to my clipping message, which proposes a drawing rate of >300 polys in 100 mS… or was it my database size of 10,000 polys?> >I think you're off by an order or two of magnitude. >But I have no hard numbers. No, that's the beauty of the algorithm I'm working on! I should get AT LEAST 200 polys per rendering cycle, and if I use 320x200x16 mode, it takes about 50 mS– plenty of time for the poly database processing. I'm off by AT MOST a factor of 2. >You should also consider that background walls and floors can be done >by pre-rendering them onto pixmaps, then resampling the pixmaps >onto the screen first. Then, start drawing your wire-frames or >filled polygons. Yes, it is a possibility, IF you're using textures. But this requires "touching" each pixel twice… Perhaps these areas could be copied out of a buffer by the scan-line renderer where no polys cover. >Again, check out BSP in the Computer Graphics book, and >the ASP in Graphics Interface '90. These are the front-runners >for repetitive polygonal database update methods. I have checked out these methods and, IMHO, they are not as useful as they appear. They are best used to depth-sort polys for schemes that draw ALL the polys over and over again. They can help with object- level rejection in the "front end" of the renderer, but no further. The keyword is "repetitive" and we can't afford that on this machine. I suspect even the Amiga starts getting into problems, as drawing a poly takes significant CPU intervention to keep the hardware fed with all those horizontal line commands that the Amiga's hardware supports. Plus, as soon as you go to Gourand shading or texture mapping, it all has to be done by the CPU anyway. < a comment on the proposed glove interface > >A tip: it will be much easier to get this stuff working right if >you encode the whole process, both hi-res-mode-init and the >polling loop, into a finite state machine. Your TSR can then >just do a case statement to decide what to do. It's a little >tougher to code than by hand, but it's the only way to fly >in an interrupt-driven environment. This isn't TSR code though: nor is it a device driver. This is to be linked into a C program. There really IS only one path through interrupts, with early termination if the glove isn't ready yet. I don't understand _why_ a state machine should be tougher– it's just an implementation decision after all. Thanks for the feedback. Can you please include at least the gist of the original message? I had trouble figuring out which one you were replying to. Ahh, the perils of asynchrony (B_{). ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From dstamp@watserv1.uwaterloo.ca Mon Oct 21 21:30:55 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA17225 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 00:35:01 -0500 Received: by watserv1.uwaterloo.ca id <AA09571>; Tue, 22 Oct 91 01:30:55 -0400 Date: Tue, 22 Oct 91 01:30:55 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110220530.AA09571@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu < I think the mailer barfed this back at me: if you got it already, please ignore…> I am posting this as a word of encouragement to garage VR folk, and as a benchmark to judge prospective equipment against. I apologize in advance if I seem to be disparaging about equipment or performance of software: I am stating numbers as I have them (mostly from the source below, and some from assorted research, technical documents too long misplaced to give references to, and personal experience). Feel free to correct me, but be sure you are looking at the same aspects I am (i.e average case vs. worst/best case). The following is from "Reality Built for Two: A Virtual Reality Tool" in Computer Graphics journal by C. Blanchard et al from VPL. It is a 2 page article, and the 2 most relevant paragraphs are quoted here in full, with some of the other equipment mentioned summarized later on. *>The Eyephone: *> *>The Eyephone consists of 2 color LCD monitors viewed using a LEEP optical *>system. Proprietary diffusion techniques are used to merge the distinct *>pixels od the LCD into a continuous image. and to reduce conflicts between *>depth of field and stereo cues. A high resolution dot pattern is *>superimposed over the image to improve percieved resolution. *> *>Each monitor is driven by the image rendered by one of the Irises. *>(Silicon Graphics 4D-80 GT, 2 per user). The monitors and optics are *>mounted in a soft, counterweighted headdress which has physical and *>psychological advantages over the more rigid and intimidating helmet *>mounted displays. I've had the opportunity to work with the LEEP optical systems. They give a WIDE (90 degrees is possible, 100 degrees is *quoted*) field of view, but distort the image. The distortion is fixed by using an undistorting lens and camera mounted on the IRIS monitor. Now, maybe VPL has gotten around this somehow, but they don't say… The pixels in a LEEP display look about as big as the nail on your pinky at arm's length. (1/2 to 1/3 of a visual degree) The resolution (actually USED area) of the LCD in the Eyephone is 280 by 240 pixels at most. The "proprietary diffusion" seems to be a rather simple diffuser, needed to smear the RGB bands in the LCD panel out, and to prevent contrast band effects having to do with the limited view angle of the LCD panels. The stereo conflict stuff just means that the diffused picture ALWAYS looks out-of-focus. Those dots will probably cause the problem all over again. As for the headband, when I worked with these displays I discarded it because it couldn't hold the displays steady enough, and replaced it with a frame and a pilot's helmet. Worked great, but was a little hard to get on and off. If I'm working with a $18,000 ($24,000 color) set of displays, I don't want them falling off my head! *>System Performance: *> *>Using Silicon Graphics 4D-80 GT's as rendering engines we are currently able *>to render worlds with approximately 1400 simultaniously viewable polygons, *>including a high percentage of many-sided and concave polygons, at *>interactive rates of 10 Hz or greater. The total number of polygons in *>a virtual world may exceed this limit when you break the world into *>visibly discreet chambers limiting the number of polygons you can see at *>one time. Hmm, that poly count is hard to interpret. If we translate it into 2000 quadrilaterals, we probably are not underestimating things. The "simultaneously viewable" phrase either means the *possible* viewable set of objects from any position (i.e the "chambers" mentioned later) or the number of polys not clipped by viewpoint and sent to the Irises to be rendered. I suspect it is the former, so the number of polys actually sent to the Iris for rendering might be 1000 or so. The idea of "chambers" is a primitive way of pruning the rendering input. I suspect that the 1000-poly count is *way* higher than what the renderer in a well-designed 3D video game would have to handle, given the same world to draw. (No solid data on this, but Jez San claims to handle a 20,000 poly world on a 386 PC at a goodly frame rate…). Also, by reducing the viewport size from 80 by 100 degrees down to a garage-VR size viewport (suitable for simple eyephone optics) of 40 by 50 degrees, the area (and number of polys) is reduced by a factor of 4. So, 300 polys MIGHT be a good upper-limit for the renderer. That still means we need good "front-end" software to tell the renderer what to draw. I believe this number is quite achievable on a home system. A SUMMARY OF OTHER EQUIPMENT MENTIONED: The DataGlove, of course. Its problems and frailty has been summarized by others. The world model is updated by a Mac II (sorry, no info on what model) which talks to the Irises by Ethernet. The glove position (palm and tip of index finger) and the Eyephone unit angle and position are returned by a Polhemus Isotrak magnetic tracking system. As I recall, the sampling rate on an Isotrak is 80/(# inputs) so that's about 26 samples/sec, assuming 1 isotrak per user. The Pohemus sensors suffer from some of the same noise and glitch problems as the Powerglove's sensors. They don't have to be pointed at the receiver array, but they suffer from distortion from any nearby metal object (screws, desks, you name it). CONCLUSION In relation to these numbers, achievable results from the garage VR project don't look terribly bad. I think the point is that any system has its drawbacks and tradeoffs, and current high-end VR systems have their share. The difference is that they can throw money at a problem and buy off-the-shelf equipment to save time, whereas the "garage" VR folk have to make do. In the end, I think we will compare well. DISCLAIMER: Consider this a first draft, shown to collegues for criticism and evaluation. There is NOTHING implied about the companies mentioned here: just an evaluation from my POV. Discussion invited. -Dave Stampe From dstamp@watserv1.uwaterloo.ca Mon Oct 21 21:36:49 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA17270 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 00:40:55 -0500 Received: by watserv1.uwaterloo.ca id <AA09869>; Tue, 22 Oct 91 01:36:49 -0400 Date: Tue, 22 Oct 91 01:36:49 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110220536.AA09869@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu < I think the mailer barfed this back at me: if you got it already, please ignore…> I am posting this as a word of encouragement to garage VR folk, and as a benchmark to judge prospective equipment against. I apologize in advance if I seem to be disparaging about equipment or performance of software: I am stating numbers as I have them (mostly from the source below, and some from assorted research, technical documents too long misplaced to give references to, and personal experience). Feel free to correct me, but be sure you are looking at the same aspects I am (i.e average case vs. worst/best case). The following is from "Reality Built for Two: A Virtual Reality Tool" in Computer Graphics journal by C. Blanchard et al from VPL. It is a 2 page article, and the 2 most relevant paragraphs are quoted here in full, with some of the other equipment mentioned summarized later on. *>The Eyephone: *> *>The Eyephone consists of 2 color LCD monitors viewed using a LEEP optical *>system. Proprietary diffusion techniques are used to merge the distinct *>pixels od the LCD into a continuous image. and to reduce conflicts between *>depth of field and stereo cues. A high resolution dot pattern is *>superimposed over the image to improve percieved resolution. *> *>Each monitor is driven by the image rendered by one of the Irises. *>(Silicon Graphics 4D-80 GT, 2 per user). The monitors and optics are *>mounted in a soft, counterweighted headdress which has physical and *>psychological advantages over the more rigid and intimidating helmet *>mounted displays. I've had the opportunity to work with the LEEP optical systems. They give a WIDE (90 degrees is possible, 100 degrees is *quoted*) field of view, but distort the image. The distortion is fixed by using an undistorting lens and camera mounted on the IRIS monitor. Now, maybe VPL has gotten around this somehow, but they don't say… The pixels in a LEEP display look about as big as the nail on your pinky at arm's length. (1/2 to 1/3 of a visual degree) The resolution (actually USED area) of the LCD in the Eyephone is 280 by 240 pixels at most. The "proprietary diffusion" seems to be a rather simple diffuser, needed to smear the RGB bands in the LCD panel out, and to prevent contrast band effects having to do with the limited view angle of the LCD panels. The stereo conflict stuff just means that the diffused picture ALWAYS looks out-of-focus. Those dots will probably cause the problem all over again. As for the headband, when I worked with these displays I discarded it because it couldn't hold the displays steady enough, and replaced it with a frame and a pilot's helmet. Worked great, but was a little hard to get on and off. If I'm working with a $18,000 ($24,000 color) set of displays, I don't want them falling off my head! *>System Performance: *> *>Using Silicon Graphics 4D-80 GT's as rendering engines we are currently able *>to render worlds with approximately 1400 simultaniously viewable polygons, *>including a high percentage of many-sided and concave polygons, at *>interactive rates of 10 Hz or greater. The total number of polygons in *>a virtual world may exceed this limit when you break the world into *>visibly discreet chambers limiting the number of polygons you can see at *>one time. Hmm, that poly count is hard to interpret. If we translate it into 2000 quadrilaterals, we probably are not underestimating things. The "simultaneously viewable" phrase either means the *possible* viewable set of objects from any position (i.e the "chambers" mentioned later) or the number of polys not clipped by viewpoint and sent to the Irises to be rendered. I suspect it is the former, so the number of polys actually sent to the Iris for rendering might be 1000 or so. The idea of "chambers" is a primitive way of pruning the rendering input. I suspect that the 1000-poly count is *way* higher than what the renderer in a well-designed 3D video game would have to handle, given the same world to draw. (No solid data on this, but Jez San claims to handle a 20,000 poly world on a 386 PC at a goodly frame rate…). Also, by reducing the viewport size from 80 by 100 degrees down to a garage-VR size viewport (suitable for simple eyephone optics) of 40 by 50 degrees, the area (and number of polys) is reduced by a factor of 4. So, 300 polys MIGHT be a good upper-limit for the renderer. That still means we need good "front-end" software to tell the renderer what to draw. I believe this number is quite achievable on a home system. A SUMMARY OF OTHER EQUIPMENT MENTIONED: The DataGlove, of course. Its problems and frailty has been summarized by others. The world model is updated by a Mac II (sorry, no info on what model) which talks to the Irises by Ethernet. The glove position (palm and tip of index finger) and the Eyephone unit angle and position are returned by a Polhemus Isotrak magnetic tracking system. As I recall, the sampling rate on an Isotrak is 80/(# inputs) so that's about 26 samples/sec, assuming 1 isotrak per user. The Pohemus sensors suffer from some of the same noise and glitch problems as the Powerglove's sensors. They don't have to be pointed at the receiver array, but they suffer from distortion from any nearby metal object (screws, desks, you name it). CONCLUSION In relation to these numbers, achievable results from the garage VR project don't look terribly bad. I think the point is that any system has its drawbacks and tradeoffs, and current high-end VR systems have their share. The difference is that they can throw money at a problem and buy off-the-shelf equipment to save time, whereas the "garage" VR folk have to make do. In the end, I think we will compare well. DISCLAIMER: Consider this a first draft, shown to collegues for criticism and evaluation. There is NOTHING implied about the companies mentioned here: just an evaluation from my POV. Discussion invited. -Dave Stampe From dirish@math.utah.edu Tue Oct 22 02:23:37 1991 Received: from math.utah.edu (csc-sun.math.utah.edu) by karazm.math.UH.EDU with SMTP id AA18794 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 09:27:46 -0500 Received: from alfred.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25185; Tue, 22 Oct 91 08:23:40 MDT Received: by alfred.math.utah.edu (5.57/Ultrix3.0-C) id AA10244; Tue, 22 Oct 91 08:23:37 -0600 Date: Tue, 22 Oct 91 08:23:37 -0600 From: dirish@math.utah.edu Message-Id: 9110221423.AA10244@alfred.math.utah.edu To: glove-list@karazm.math.uh.edu Subject: RE: PG controller board Given the very experimental tendancy of this group I have a sugestion for the people designing outboard controller cards. I would love to have one which I could down load the code to. In my experience, being able to down load a new version of the controller code, rather than having to burn another prom is a big win. Especially for those of us who would have to burn the proms at work then bring them home to work on. Also, in terms of lower cost, such a system would let someone with considerably less equipment start experimenting with a controller card. I haven't looked, but surely we can find a simple monitor for one of these controllers which will allow down loading? Dudley Irish Dudley Irish / dirish@math.utah.edu / Manager Computer Operations Center for Scientific Computing, Dept of Mathematics, University of Utah The views expressed in this message do not reflect the views of the Dept of Mathematics, the University of Utah, or the State of Utah. From williams_stephen_d@ae.ge.com Tue Oct 22 07:06:25 1991 Received: from CRDGW1.GE.COM by karazm.math.UH.EDU with SMTP id AA18955 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 10:11:46 -0500 Received: by crdgw1.ge.com (5.57/GE 1.114) id AA24840; Tue, 22 Oct 91 11:07:33 EDT Message-Id: 9110221507.AA24840@crdgw1.ge.com Received: from hp600.ae.ge.com by hpmail.ae.ge.com with SMTP (15.11.1.6/15.6) id AA05319; Tue, 22 Oct 91 11:06:25 -0400 Received: by hp600.ae.ge.com (15.11.1.6/15.6) id AA02543; Tue, 22 Oct 91 11:06:27 -0400 From: U-E99999-Stephen Williams williams_stephen_d@ae.ge.com Subject: 68hc811…. To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 11:06:25 EDT Mailer: Elm [revision: 64.9] The 68hc811 has 2k of eeprom and 6-800bytes of ram. It has a mode where it downloads a program from the serial port and then executes it. The ideal setup is to have the public domain/portable assembler on a PC (generic in this sense) with a serial cable. Run the chip in single chip mode with a toggle for bootstrapping. I would suggest that someone (with more experience and time than I) do the following: Get together the simplest circuit possible for single chip mode or a mode with some more ram. Pinouts of an appropriate cable (serial and PG). Re-distribute one of the portable assemblers and the PG source. Provide a simple bootstrap that loads the executable image into eeprom. Coordinate PC software to interpret the data coming in from serial/parallel port. I believe this could be done with no evm/evb or eprom burner/eraser and would cut the cost tremendously. I am thinking of eventually selling a kit like this, but have a very long queue of projects. If anyone's interested, I also know how to interface switches, relays, stepper motors, etc. very simply to a standard parallel port. I had a stepper spinning in either direction with 4 transistors and a Basic program. I have been looking at the 68hc811, but havn't had time to actually do anything. I have a lot of professional experience in many areas of software, including industrial robotics, but I am hobbyist level in electronics. If anyone would help me with the circuit and software initially, we could produce these as a design, kit, and/or box. Thanks. sdw – Stephen D. Williams SDW Systems (513) 439-5428 GE AEG (513) 552-5237 ICBM: 39 34N 85 15W Internet: williams_stephen_d@ae.ge.com CIS 76244,210 sdw@world.std.com Prodigy TPGR01A Object Oriented R&D By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342 From broehl@sunee.waterloo.edu Tue Oct 22 07:10:39 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA18969 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 10:14:47 -0500 Received: by sunee.waterloo.edu id <AA19958>; Tue, 22 Oct 91 11:10:40 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110221510.AA19958@sunee.waterloo.edu Subject: Standards To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 11:10:39 EDT X-Mailer: ELM [version 2.3 PL11] Some micellaneous thoughts on standards: After some careful thought, I've come to the conclusion that the various VR input devices will be too varied to make a single, universal interface practical. What I suspect we'll see are increasing levels of data abstraction; the glove routines we have now well work as currently defined, and a higher-level routine will map glove movements, gestures and buttons to a more generic form. Don't make the lower levels more complex; instead let them do what they do well and let the higher levels process the results. Since we wll probably have a set of routines for each VR input device we develop, I would propose a naming convention: all the routines related to the glove we love will have names prefixed with "glove_". Thus our initialization routine would be glove_init(), our reading routine would be glove_read(), and our wrapup routine would be called glove_quit() (which, as an earlier poster pointed out, is probably more meaningful than "glove_reset()"). As to the issue of external microcontrollers… I think it would be nice to standardize a protocol for talking to them. Even though I don't have one (yet; we have a 68HC11, and I'm just waiting for the person who has the code to post it), here is what I propose: Host sends 'H' to board to put glove in hi-res mode Host sends 'P' to board to poll it for a 6-byte packet Host sends 'C' to board to tell it to send full 12-byte packet continuously Host sends 'S' to board to stop continuous sending Host sends 'D' to board, followed by a 1-byte byte count, followed by that number of bytes of data to load into a buffer and execute – Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] From ejdavies@watcgl.waterloo.edu Tue Oct 22 08:11:20 1991 Received: from watcgl.waterloo.edu by karazm.math.UH.EDU with SMTP id AA19428 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 11:15:27 -0500 Received: by watcgl.waterloo.edu id <AA26376>; Tue, 22 Oct 91 12:11:20 -0400 Date: Tue, 22 Oct 91 12:11:20 -0400 From: Eric Davies ejdavies@watcgl.waterloo.edu Message-Id: 9110221611.AA26376@watcgl.waterloo.edu To: glove-list@karazm.math.uh.edu Subject: standards and alternative position tracking schemes One thought on standards: while the powerglove only gives you data about a finger as a whole, I would expect more sophisticated gloves (if not now, then in the future) to offer information about individual finger joints. [Allowing sign language, more involved puppetry?] Likely there are other options envisionable as well. Perhaps we could have a device driver which we pass a set of atoms (to use the Xwindows terminology) to indicate which data items we are interested in and a buffer to store that information in. Data items that aren't supported by the driver are simply ignored. When the buffer got filled, the device driver would store the atom next to the data item to identify it. Ideally, access to the driver would be a set of machine specific routines, to hide whether the driver was a library being linked in or a genuine honest-to-goodness device driver. Given somebody/group willing to coordinate the allocation of atom values, (the way Commodore coordinates IFF chunk names) integer atoms should be sufficient. Position tracking schemes: does anybody have any references to infrared position tracking schemes? It looks like you need to solve a nonlinear system of equations, making the math a bit uglier and probably slower, but removes a few other constraints. Eric Davies From SHEKOSKI@vx.acs.umn.edu Tue Oct 22 06:49:00 1991 Received: from vx.acs.umn.edu by karazm.math.UH.EDU with SMTP id AA19552 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 11:48:42 -0500 Date: Tue, 22 Oct 91 11:49 CDT From: "Paul Shekoski,931-4333,Alliant" SHEKOSKI@vx.acs.umn.edu Subject: Help in Getting Started To: glove-list@karazm.math.uh.edu, Paul_Shekoski@Atk.Com Message-Id: F812253C24FF81106A@vx.acs.umn.edu X-Envelope-To: glove-list@karazm.math.uh.edu X-Vms-To: IN%"glove-list@karazm.math.uh.edu" X-Vms-Cc: SHEKOSKI Can someone supply me with some information about getting started constructing my own input devices, programs, interfaces, etc…? I am very interested in some opinions about which hardware platform I should start from, how I go about getting started on that platform, and what things I can purchase on a very limited budget(e.g. my own). I do have access to silicon graphics machines as well as other types of systems. Paul From agodwin@acorn.co.uk Tue Oct 22 18:26:02 1991 Received: from eros.uknet.ac.uk by karazm.math.UH.EDU with SMTP id AA20184 (5.65c/IDA-1.4.4 for glove-list@KARAZM.MATH.UH.edu); Tue, 22 Oct 1991 12:19:09 -0500 Received: from acorn.co.uk by eros.uknet.ac.uk with UUCP id 1291-0@eros.uknet.ac.uk; Tue, 22 Oct 1991 18:05:32 +0100 Received: from snark.acorn.co.uk by acorn.co.uk (4.1/Am31) id AA17116; Tue, 22 Oct 91 17:26:04 BST From: agodwin@acorn.co.uk (Adrian Godwin) Date: Tue, 22 Oct 91 17:26:02 +0100 Message-Id: 9110221626.AA03672@snark.acorn.co.uk To: glove-list@KARAZM.MATH.UH.edu Subject: ACCESS.bus specs I'm still waiting for Digital to send me specs on the ACCESS.bus standard : can anyone here tell how it's related to the IIC bus ? Will the IIC devices work with it ? -adrian From german@cgrg.ohio-state.edu Tue Oct 22 09:37:28 1991 Received: from sap.cgrg.ohio-state.edu by karazm.math.UH.EDU with SMTP id AA20332 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 12:41:35 -0500 Return-Path: german@cgrg.ohio-state.edu Received: by sap.cgrg.ohio-state.edu (5.64/900625.02) id AA16482; Tue, 22 Oct 91 13:37:28 -0400 Date: Tue, 22 Oct 91 13:37:28 -0400 From: german@cgrg.ohio-state.edu (German Bauer) Message-Id: 9110221737.AA16482@sap.cgrg.ohio-state.edu To: glove-list@karazm.math.uh.edu Subject: ftp access Could you pls mail me the number of karazm.math.uh.edu, since my host does not "know" karazm.math.uh.edu. I would like to ftp the hires-code from there. Thanks in advance, German B. From gbnewby@alexia.lis.uiuc.edu Tue Oct 22 07:55:23 1991 Received: from alexia.lis.uiuc.edu by karazm.math.UH.EDU with SMTP id AA20556 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 13:10:08 -0500 Received: by alexia.lis.uiuc.edu id AA20679 (5.61/ for jdb9608@cs.rit.edu); Tue, 22 Oct 91 12:55:23 -0500 Date: Tue, 22 Oct 91 12:55:23 -0500 From: Greg Newby gbnewby@alexia.lis.uiuc.edu Message-Id: 9110221755.AA20679@alexia.lis.uiuc.edu To: glove-list@karazm.math.uh.edu, jdb9608@cs.rit.edu Subject: Re: ST timing? Cc: gbnewby@alexia.lis.uiuc.edu Hi. I was out of town for a few days, so I hope no one already responded to David's comments about synch. problems. My response: Isn't there a header byte somewhere? As in, instead of sampling in a "fixed loop," why not read when you can, and then dynamically decide what sort of data you're reading? If the datum is wrong (out of sync), transfer to a loop that waits until the data are back in sync – then return to the main loop. Sorry this is vague right now. The idea is that if you skip one measly transmission of position, at least you can get the next one after resynchronizing. There are some header bytes or whatever that I believe are now being skipped in the code. Sorry for brevity, I gotta go teach in a few minutes…. Later. – Greg gbnewby@alexia.lis.uiuc.edu From dstamp@watserv1.uwaterloo.ca Tue Oct 22 11:56:26 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA21298 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 15:00:41 -0500 Received: by watserv1.uwaterloo.ca id <AA24923>; Tue, 22 Oct 91 15:56:26 -0400 Date: Tue, 22 Oct 91 15:56:26 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110221956.AA24923@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Replying to Lance Norskog lance@roi.ca41.csd.mot.com »>You should also consider that background walls and floors can be done »>by pre-rendering them onto pixmaps, then resampling the pixmaps »>onto the screen first. Then, start drawing your wire-frames or »>filled polygons. » >The VGA hardware is terminally weird. It has this mode where you >can copy from one part of card RAM to another faster than from >main RAM. This makes pre-rendered textures interesting, since 320x200 >is only 64k, and the VGA boards now support 1meg of RAM. Well… that IS true, and you can copy 4 bytes with 2 CPU accesses, or fill all 4 with 1 CPU access. The 1 meg cards are'nt that good, though, as accessing that extra RAM is highly card- and mode- specific. So the software will have to assume a 256K VGA card. Now, the most memory used is for double-buffered 320x200x256 color mode in stereo (4 pages) which eats up all but 1536 pixels worth of memory.. Still possible, I guess. But if we drop down to 320x200x16 colors, we get 8 pages so it's quite possible there, and the copy takes less than 10 mS. Quite possible. Except any major viewpoint shift wrecks your background… < discussing BSP and ASP algorithms> >You'll want four or five different polygon database management >algorithms to handle different parts of the scene: walls&furniture, >moving hard objects, moving flexible objects, glove cursor, etc. >BSP and ASP help with models for moving hard objects and furniture. > >A once-every-time sort must be done on the database of large moving >and still objects, then each object must itself be added to the >polygon list, then you do a scan-line render on a small polygon >list. This gets very complex, and may be slow. In fact, this >method may only get used when you're rendering animations in >batch mode of fly-throughs which you've logged. Autodesk animator >does 320x200x256 colors, and of course you'll want to share >your demos :-) Hmm, are we discussing the same algorithms? As I read Foley's latest book "Computer Graphics: principles and practice" the BSP seems to help with 2 things: - eliminating polys that fall outside the viewport efficiently - generating an ordered list of polys so that masking is done by _drawing_ the polygons. Now I am aware that the conversion from an object tree to a poly list (hopefully ordered in some way) is expensive and the BSP and ASP help here, but there are other ways to optimize this. I am proposing a simple set of "enclosing" points for each object that would control the sorting, masking and clipping of each object. This would reduce computations by 90% during list transversal. Let me know what you think. A technical point about BSP: what happens if another object intrudes into a concave object? Is this a problem, or not? IMHO, Foley does not cover the BSP that thoroughly. Any other references? CAN the BSP be used to eliminate polys inside the viewport BEFORE rendering (no z-buffer here– just draw and draw…) ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From jdb9608@cs.rit.edu Tue Oct 22 12:14:00 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA21584 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 15:17:09 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA13267; Tue, 22 Oct 91 16:12:35 -0400 Received: from cobalt.CS (cobalt.ARPA) by junior.rit.edu (4.1/5.17) id AA26701; Tue, 22 Oct 91 16:01:11 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110222001.AA26701@junior.rit.edu Subject: Re: ST timing? To: gbnewby@alexia.lis.uiuc.edu, glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 16:14:00 EDT X-Mailer: ELM [version 2.3 PL8] Greg has a good idea for re-sync'ing the packet by simply reading a whole packet whenever an A0 comes in (i.e., when it comes in as the 10'th byte, consider it the 1st byte instead). I'll probably wind up doing something like that. I was hoping that if I could get the packet order rock-solid, then I could sync the glove to the program. Skipping the last few D2SLOW bytes will throw off the sync by 15 or 30 ms each time it happens. I don't know why it happens. Maybe if it's unavoidable I could just re-sync the program at those points (costing that one frame but not the following frames). If this sync-the-glove-to-the-program stuff doesn't improve the response time then I'll probably just use the method Dave Stampe discovered, since it's faster. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From broehl@sunee.waterloo.edu Tue Oct 22 12:25:52 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA21658 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 15:30:04 -0500 Received: by sunee.waterloo.edu id <AA26957>; Tue, 22 Oct 91 16:25:54 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110222025.AA26957@sunee.waterloo.edu Subject: clippin To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 16:25:52 EDT X-Mailer: ELM [version 2.3 PL11] > Now I am aware that the conversion from an object tree to a poly list > (hopefully ordered in some way) is expensive and the BSP and ASP help > here, but there are other ways to optimize this. I am proposing a > simple set of "enclosing" points for each object that would control > the sorting, masking and clipping of each object. This would reduce > computations by 90% during list transversal. Let me know what you think. Sounds like a good idea; assign each object a bounding box and then clip by objects before even worrying about polygons. – Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] From jdb9608@cs.rit.edu Tue Oct 22 12:52:53 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA21789 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 15:55:44 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA14838; Tue, 22 Oct 91 16:51:27 -0400 Received: from cobalt.CS (cobalt.ARPA) by junior.rit.edu (4.1/5.17) id AA26923; Tue, 22 Oct 91 16:40:03 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110222040.AA26923@junior.rit.edu Subject: karazm's internet number To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 16:52:53 EDT X-Mailer: ELM [version 2.3 PL8] From here, karazm.math.uh.edu seems to be 129.7.7.6. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From gbnewby@alexia.lis.uiuc.edu Tue Oct 22 10:55:17 1991 Received: from alexia.lis.uiuc.edu by karazm.math.UH.EDU with SMTP id AA21809 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 15:59:49 -0500 Received: by alexia.lis.uiuc.edu id AA27246 (5.61/ for glove-list@karazm.math.uh.edu); Tue, 22 Oct 91 15:55:17 -0500 Date: Tue, 22 Oct 91 15:55:17 -0500 From: Greg Newby gbnewby@alexia.lis.uiuc.edu Message-Id: 9110222055.AA27246@alexia.lis.uiuc.edu To: dstamp@watserv1.uwaterloo.ca, glove-list@karazm.math.uh.edu Subject: Specifics on VPL's Mac Cc: gbnewby@alexia.lis.uiuc.edu Thanks for the summary, Dave. You mentioned that you didn't have the specs for the Mac VPL uses for it's virtual reality setup: They use a high-end model (Mac II cx or fx), 16 Meg ram. The Mac runs a proprietary program (set of programs, really), called "Body Electric." I only used this a little bit, but it was basically an object definition language – the programmer would specify objects and give them characteristics. The programming language didn't seem much different from Hypercard, or maybe a database definition language. Things such as: define ball can move has gravity size = 10 shape = round initial position.. etc. That's not how the language looked, but those are the types of characteristics that were defined. The rumor is that they are now trying to remove the Mac from the picture altogether – with today's Iris', there's really no need (older Iris' were a different story….). Didn't VPL have a demonstration at SIG/GRAPH with only one Iris? Or was it an Iris and a Mac… Anyway, that fills in a few details… – Greg gbnewby@alexia.lis.uiuc.edu From dstamp@watserv1.uwaterloo.ca Tue Oct 22 13:54:20 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA22143 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 16:58:40 -0500 Received: by watserv1.uwaterloo.ca id <AA02549>; Tue, 22 Oct 91 17:54:20 -0400 Date: Tue, 22 Oct 91 17:54:20 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110222154.AA02549@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Here's a "weird" proposal. Read it and think about it before you reply… Using Amiga 500's as graphics accelerators for IBM PC's ???? The idea is to interface (cheaply) 1 or 2 A500's to a 386 PC. The output of the A500's is NTSC video, perfect for driving those cheap Eyephone displays. The 386 supplies the processing power for modelling, list transversal and I/O; the A500 supplies faster low-level rendering. The BIG advantage here is that binocular 3-D is almost as fast as monocular video. Now, the cost of an A500 without monitor is under $500: about the cost of a very cheap graphics coprocessor card for the PC. Some sort of interface has to be implemented that can transfer data FAST without significant loading of the CPU at either end of the link. The A500 boots and runs off a floppy automatically. I'm not sure where the best place to interrupt the rendering chain for division of labor is. The A500 is capable of 3 or 4 times the graphics performance of the PC in squirting stuff onto the screen; the PC is about 6-10x faster on the database and pre-rendering stuff. Whether to use a repetitive-drawing algorithm using tha A500's faster drawing speed or a scan-line algorithm with the PC passing the A500 shading, texture, and horizontal line segments to draw is another guestion. My answer to "Why not just go with an A3000 right away" is that it's not really a good idea for IBM PC programmers who have a big investment in their environments, etc. Besides, see how VPL has been using a MAC to drive their IRIS workstations: it's a case of software environment in many cases. Anyway, let's discuss it. Is it cost-effective? How much of a speedup will it make? (Oh, come on now. Just think about for 15 seconds or so…) ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From jdb9608@cs.rit.edu Tue Oct 22 14:01:57 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA22192 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 17:04:50 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA17678; Tue, 22 Oct 91 18:00:36 -0400 Received: from cobalt.CS (cobalt.ARPA) by junior.rit.edu (4.1/5.17) id AA27119; Tue, 22 Oct 91 17:49:11 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110222149.AA27119@junior.rit.edu Subject: standard objectives To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 18:01:57 EDT X-Mailer: ELM [version 2.3 PL8] There are great ideas on standards flying around. I'm going to try to summarize them later, but at the moment see how you like this attempt to list and prioritize the objectives of the standard: 1. allow programs to run independent of hardware (i.e., ST, PC, Amiga…) 2. the interface the programmer needs is already written 3. allow glove interfaces to be upwardly compatable (i.e., the old features always remain so old programs will always work). This is pretty easy if people choose to use the standard, but the longer there is no standard the more programs can't use it. 4. allow glove interfaces to be downwardly compatable (i.e., if the interface can't handle some option, it knows how to do something almost as good or at least it can gracefully inform the user about what it can't handle). This is more difficult because it involves substituting functions and predicting the future demands of applications and future capabilities of interfaces. There are two main, opposing constraints: hiding implementation details is good (here's what it does, nevermind how) reducing functionality is bad (this one can do it, but that one can't) (e.g., some people will want the 17 Hz sample rate, but that forces an implementation using timers, which some hardware may lack. That extra speed is worth the inconsistency of the uncommon hardware that can't do it; that hardware's interface will just have to do the next best thing, because the absolute lowest common denominator is too low. This is the downward compatability problem again.) I've seen some great ideas for solutions; let's talk about them, put together what we know we've got, and try to nail it down even tho we can't predict the future. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From cdshaw@cs.ualberta.ca Tue Oct 22 10:41:25 1991 Received: from scapa.cs.ualberta.ca by karazm.math.UH.EDU with SMTP id AA22445 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 17:47:36 -0500 Received: by scapa.cs.ualberta.ca id <42377>; Tue, 22 Oct 1991 16:42:51 -0600 Subject: Re: Dataglove 2 and the SGI From: Chris Shaw cdshaw@cs.ualberta.ca To: lance@roi.ca41.csd.mot.com (Lance Norskog), glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 1991 16:41:25 -0600 In-Reply-To: 9110211150.AA07287@roi.ca41.csd.mot.com; from "Lance Norskog" at Oct 21, 91 12:50 pm Organization: U of Alberta, Dept of Computing Science Address: 713D General Services Building, U of A, Edmonton, Alberta, T6G 2H1 X-Mailer: ELM [version 2.3 PL11] Message-Id: 91Oct22.164251mdt.42377@scapa.cs.ualberta.ca > Get the Graphics Interface '90 proceedings. Chris Shaw and > his cohort whose name I've forgotten have a lot of sage advice > on this in "The DataPaper". They also have a toolkit they're > planning to release soon. Shaw posts here and on sci.v-w a lot. > > Lance Norskog Thank for the references! My cohort = my boss = Mark Green. We'll be releasing a beta version of the toolkit sometime this month. Includes a version of our updated glove server, and our updated isotrak server, plus our VR toolkit. – Chris Shaw University of Alberta cdshaw@cs.UAlberta.ca CatchPhrase: Bogus as HELL ! From LEEK@QUCDN.QueensU.CA Tue Oct 22 14:51:00 1991 Received: from QUCDN.QueensU.CA by karazm.math.UH.EDU with SMTP id AA22487 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 17:59:19 -0500 Message-Id: 199110222259.AA22487@karazm.math.UH.EDU Received: from QUCDN.QueensU.CA by QUCDN.QueensU.CA (IBM VM SMTP V2R1) with BSMTP id 8322; Tue, 22 Oct 91 18:55:47 EDT Received: by QUCDN (Mailer R2.08) id 8328; Tue, 22 Oct 91 18:55:46 EDT Date: Tue, 22 Oct 1991 18:51 EDT From: LEEK@QUCDN.QueensU.CA To: glove-list@karazm.math.uh.edu Subject: Standardization Ideas…. Here is my 2 pennies worth of ideas on standardization of similiar glove inputting device… I think standardization is a good thing. I would like to suggest to move away from the powerglove data structure as it seriously limits the possible type of performance for future devices. Some obvious limitations is the # of bits per finger and the rotational angle resolution. One can easily get 6-7 bit of resolution if one simply replaces the Glove CPU and add $3.00 worth of hardware. At the moment, the glove data structure might seem more convient. I just think it is worth while to set a proper standard. I would also like to add a new function for the glove. This function is to be called after initialization. This informs the host program of the capabilities of the input device. The host program can then perform the necessary transformation(s) required to the input packet stream. Inquire_Glove(); This function returns a pointer to a structure that contains the following: count - this tell the program how many words are there in a packet wordsize - the word size used in packet:byte,int,long tags - this points to an array of tags that describe what each of the words in the packet are for and what is the maximum ranges of data to be expected. Tags array: Name - a char string with ASCII text identifying the corresponding word in the packet eg. "Finger 1", "Receiver 1", "Distance X", "Rotation" The ASCII text would have to be standardized. New tags can be added for future devices as they becomes 'available'. Programs would only read off tags that they understands and ignore the rest. Try to make it obvious and understandable by someone else. Avoid using obscure short form for tags as they make guess at it difficult and some programmers (like me) likes to use the tag as part of the items on menus (when they make sense) Max - The maximum upper limit of the corresponding word in the packet. (eg. Max = 12 for the rotation from the glove. For others, it might be 360 for 1 degree resolution. ) The function Read_Glove() would now return a pointer to a packet of size count*wordsize bytes. If any of the data in the packet is > than their corresponding Max values, that means that piece of data is unavailable for the current sample. (eg. One of the receiver misses) It might also be possible to have the inquire function return a second tags array describing the possible operating modes available from the glove. eg. possible modes: "Joystick", "X,Y,Z,Rot,Fingers", "Raw", "Sample on demand", "Sample rate". An extra function is used to set the glove into one or more operating modes. The program might also ask the glove to only include a selected list of data in each packet. (ie. The program get what it wants, not everything the glove gets. This is to lower the overhead of data communication between the host and the glove.) I hope I have not gone way of tangent here. I feel if we are going to have a standard here, then we should do it right ie. not to limit ourselves to a particular product or model (eg to save 5 machine cycles) , allow for expansion in terms of new devices and/or higher resolution. Some of the hard coder there might want to argue efficiency with me about the extra processing required… To me programming in bare metal refers to laying out the transistor connections in a custom chip that performs the equivalent software function. :) If I want speed, I'll build some hardware for the task. As for the interrupt/poll, leave it to the particular machine. I like the device model on my Amiga that provides both sync & async I/O. Why force your particular model (TSR, Interrupt, Polling, Multitasking) on others ??? K. C. Lee Elec. Eng. Grad. Student From cliff@jarthur.Claremont.edu Tue Oct 22 09:24:06 1991 Received: from JARTHUR.CLAREMONT.EDU by karazm.math.UH.EDU with SMTP id AA22612 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 18:28:55 -0500 Message-Id: 199110222328.AA22612@karazm.math.UH.EDU Date: Tue, 22 Oct 91 16:24:06 PDT From: Clifford Stein cliff@jarthur.Claremont.edu To: glove-list@karazm.math.uh.edu Subject: standardization I've been reading about all of the recent mail about standardization ideas and want to express my concerns. Standardization is fine and I would like some sort of hardware device as long as it would be guaranteed to work on my machine (an ST). Most importantly, though, I want any hardware developed to be cheap. I'm a student and I don't have any full time jobs, tools, or lots of free time to build/test/finance complex circuits. I bought myself a glove because a friend told me of "karazm" and Toys R Us was having a sale on them. A simple hardware thingie that just converts the bit stream into a byte stream for the printer port would be easy to do (just a clock and a serial-in/parallel-out circuit pretty much, right?). I think I could even design something like that myself, if I knew the timing schematics (i.e. for how many usecs the latch/clocks/data lines stay on/off and such). Or, perhaps a little hardware interface that lets me plug it into my RS232 port and let the computer read the bits coming in. Either of these would leave the CPU more free to do other things without worrying about dropping bits. It would be, most importantly to me, cheap. I don't particularly care about standardization, i.e. upwards/backwards compatibility between different devices and such. Why not just wait to see if anything else comes out instead of planning for something that mightn't happen, unless you are thinking of existing devices like the "U-force" hand thingie? Also, I've been working on an interrupt-driven assembly version of "manfredo's" Hires source code for the ST. Has anyone done this? (I don't really want to duplicate the effort). I don't know if I will ever finish because I do have classes to worry about over here. However, I wouldn't mind suggestions, advice, comments or criticism from those who have done things like this before. –Cliff Stein ————- cliff@jarthur.claremont.edu | "Ted Striker? Never heard of him. Wait! cliff@jarthur.uucp | That's not exactly true. We were like …uunet!jarthur!cliff | brothers." cstein@hmcvax.bitnet | –Buck Murdoch From motcsd!roi!lance@apple.com Sat Oct 22 10:09:19 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA22763 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 19:52:29 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA02350; Tue, 22 Oct 91 17:25:16 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZWEV-0001QSC@motcsd.csd.mot.com; Tue, 22 Oct 91 17:14 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA22034; 22 Oct 91 17:09:26 PDT (Tue) To: menelli@tellabs.com Subject: Re: PG controller board Cc: glove-list@karazm.math.uh.edu Message-Id: 9110221709.AA22019@roi.ca41.csd.mot.com Date: 22 Oct 91 17:09:19 PDT (Tue) From: Lance Norskog lance@roi.ca41.csd.mot.com Handshaking. There's no built-in hardware handshake from the PC parallel port side. The only dumb thing is that the parallel port has no 5V output. You have to assign an output line as the 5V reference and leave it up all the time, and hope it doesn't source much current. What else can you do with the outboard CPU box? If you leave the power glove control code to the dumbest possible, there may be enough RAM left over for the cpu could to control a chord (one-handed) keyboard. This is just a pet project of mine. The PC joystick interface is really crummy: it forces you to poll the hardware card. But the hardware is real potentiometers. So being able to put a bunch of pots on the analog inputs of the 6811 would also be handy. Also, a plug for regular Nintendo joysticks would be nice. (Where you buy these plugs I don't know). There are some ergonomic ones appearing in the toy stores. There was even a chest-mounted one (controlled by your chin or something) announced by Nintendo two years ago and never sold. Lance Norskog From newton@neworder.ils.nwu.edu Tue Oct 22 14:40:55 1991 Received: from casbah.acns.nwu.edu by karazm.math.UH.EDU with SMTP id AA22771 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 19:54:37 -0500 Received: from neworder.ils.nwu.edu by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03) id AA25265; Tue, 22 Oct 91 19:50:27 CDT Return-Path: newton@neworder.ils.nwu.edu Received: by neworder.ils.nwu.edu (4.0/SMI-4.0) id AA00261; Tue, 22 Oct 91 19:40:56 CDT From: newton@neworder.ils.nwu.edu (Dave Newton) Message-Id: 9110230040.AA00261@neworder.ils.nwu.edu Subject: Transputers… To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 19:40:55 CDT X-Mailer: ELM [version 2.3 PL11] Howdy… I'm trying to figure out why nobody on here has proposed using those $400 T400 transputer cards hooked into a slave-PC to use for rendering… My idea was basically have a T400 card w/ 1Meg ($396) and perhaps a few slave cards ($296?). Each transputer has 10Mips sustained, 20 Mips peak. The C compiler will automagically take advantage of other processors if the code is set up in a parallel fashion. Now, color me stupid, but wouldn't this be a cheap way to get a whole bunch of power? The transputers could either be used in the main PC or put out in a slave PC somewhere. I was planning on getting two dirt-cheap PC boards, three transputer boards (one for the main CPU, one for each slave) and communicate to the slave T400 boards using the on-board 20M data link… Let the slave boards handle the image calculation and spit it out via J. Random NTSC-board. From dstamp@watserv1.uwaterloo.ca Tue Oct 22 18:53:13 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA23037 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 21:57:26 -0500 Received: by watserv1.uwaterloo.ca id <AA18321>; Tue, 22 Oct 91 22:53:13 -0400 Date: Tue, 22 Oct 91 22:53:13 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110230253.AA18321@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, newton@neworder.ils.nwu.edu Subject: Re: Transputers… > From glove-list-request@karazm.math.UH.EDU Tue Oct 22 21:09:29 1991 > From: newton@neworder.ils.nwu.edu (Dave Newton) > Subject: Transputers… > To: glove-list@karazm.math.uh.edu > > Howdy… > > I'm trying to figure out why nobody on here has proposed using those $400 > T400 transputer cards hooked into a slave-PC to use for rendering… > > My idea was basically have a T400 card w/ 1Meg ($396) and perhaps a few > slave cards ($296?). Each transputer has 10Mips sustained, 20 Mips > peak. The C compiler will automagically take advantage of other processors > if the code is set up in a parallel fashion. > > Now, color me stupid, but wouldn't this be a cheap way to get a whole bunch > of power? The transputers could either be used in the main PC or put out > in a slave PC somewhere. I was planning on getting two dirt-cheap PC boards, > three transputer boards (one for the main CPU, one for each slave) and > communicate to the slave T400 boards using the on-board 20M data link… > Let the slave boards handle the image calculation and spit it out via > J. Random NTSC-board. > Yep.. that would give you power. But what has to be considered is cost for the power, and software development. I wouldn't take on the task myself, because I have little experience in programming the Transputer systems. You'd have to do at least the rendering stuff in assembly, too. Have you got cost quotes on the video cards? Do they double buffer? Eventually we'll have to get renderers on all sorts of platforms. The Amiga, Atari, IBM PC etc. are being considered first because they're the most common. The Amiga-IBM idea was suggested because of the dedicated hardware in the Amiga for graphics. If you can get some estimates on how fast the Transputer can do graphics, it might be worth discussing it. Possible problems: If the 20M(bit) transputer link is used to talk to the video buffer, how much overhead is there (i.e. do you have to send both address ans data, or is there a burst mode)? How many units can talk to the video board at once? etc. etc. I used to have access to the data on this stuff, but not currently. Hope you can fill me in again. - Dave Stampe From squier@babbage.ecs.csus.edu Tue Oct 22 12:53:18 1991 Received: from babbage.ecs.csus.edu by karazm.math.UH.EDU with SMTP id AA23044 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 21:58:33 -0500 Received: by babbage.ecs.csus.edu (5.61/1.34) id AA17216; Tue, 22 Oct 91 19:53:21 -0700 From: squier@babbage.ecs.csus.edu (Anthony Squier) Message-Id: 9110230253.AA17216@babbage.ecs.csus.edu Subject: Glove Problems To: glove-list@karazm.math.uh.edu Date: Tue, 22 Oct 91 19:53:18 PDT X-Mailer: ELM [version 2.3 PL0] Subject: Glove Problems To: karazm.math.uh.edu@glove-list From: squier@babbage.csus.ecs.edu Date: Tue, 22 Oct 91 19:50:22 PDT X-Mailer: ELM [version 2.3 PL0] I am not sure if I have a glove that has gone bad or somthing else. I was successful in using the software from either Amazing Computing or Amiga World to get the glove to work in lores on my Amiga. I've also written my own code as well. But, when I moved the glove to the parallel port (from the game port originally used for lores), it is now not working. I've not been able to get the hires Amiga code to work that was posted earlier. The glove will start to work, then hang. If I unplug the glove from the box and re-run the program, it runs, then hangs again. Why can this happen. Could the glove be defective or is it a timing problem? (Come to think of it, lores code that I've written for the parallel port doesn't work either.) Thanks Tony… From texsun!sunbird!tellab5!sunJe!menelli@Moxie.Hou.TX.US Tue Oct 22 10:38:09 1991 Received: from Menudo.UH.EDU by karazm.math.UH.EDU with SMTP id AA23231 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 22 Oct 1991 23:18:34 -0500 Received: from Moxie.Hou.TX.US by Menudo.UH.EDU with UUCP id AA11264 (5.65c+/IDA-1.4.4 for karazm.math.uh.edu!glove-list); Tue, 22 Oct 1991 23:14:27 -0500 Received: by moxie.hou.tx.us (Smail3.1.19) id m0kZUjc-0002vVC@moxie.hou.tx.us; Tue, 22 Oct 91 17:38 CDT Received: from sunbird.Central.Sun.COM by texsun.Central.Sun.COM (4.1/SMI-4.1) id AA24361; Tue, 22 Oct 91 17:20:46 CDT Received: from tellab5.UUCP by sunbird.Central.Sun.COM (4.1/SMI-4.1-900117) id AA29385; Tue, 22 Oct 91 17:20:35 CDT Received: from sunJe.TELLABS.COM by tellab5.tellabs.com (4.1/smail2.5/10-21-91) id AA09170; Tue, 22 Oct 91 15:38:12 CDT Received: by sunJe.TELLABS.COM (4.0/4.7) id AA02225; Tue, 22 Oct 91 15:38:09 CDT Date: Tue, 22 Oct 91 15:38:09 CDT From: menelli@sunje.tellabs.com (Ron Menelli) Message-Id: 9110222038.AA02225@sunJe.TELLABS.COM To: glove-list@karazm.math.uh.edu Subject: More info on 68HC11 controller Some notes on the 68HC11 power glove controller: The interface is working better thanks to the addition of Dave Stampe's hysterisis code (the other deglitching code will be coming soon). I also have a program similar to the VGA/PG test code that works on the Amiga with the 68HC11 board interface. Lance Norskog sent me a number of suggestions, which I plan to incorporate in one way or another into the design: - Add a parallel port interface for added speed. - This should be no problem at all if I make sure that only internal processor memory is required. (Adding external memory uses up all of the useful ports that do handshaking). The only issue here is what type of handshaking should be used (I don't know what the IBM parallel port is capable of). - Don't do deglitching on the microcontroller. - I think since it seems to work so well, and it really doesn't take *that* long, I'll keep it in and include an option to turn it off. - Include a timestamp based on the start of the sample cycle. This would be used for synchronization on the receiving side. - This shouldn't be much of a problem, except for potential hardware counter limitations, which I'll look into. Another plus to the 68HC11 approach is that it has a number of A/D converters on board which could potentially be used to read the fingers, so we can disconnect them from the CPU for a faster sample rate. From a quick look at the HC11 reference manual, it says it can continuously cycle through 4 A/D inputs and store the digitized values into four registers. The amount of time it takes to read all four inputs is 64us from start to finish. The process will run automatically with no software assistance - pretty ideal, if you ask me. Now we just need to figure out an easy to interface to the sensors… Last but not least, if anyone has a 68HC11 evaluation board handy, I could send you the current version of the code - the more people that use this, the better we can make it due to all of the suggestions that will be generated. I should be able to get a schematic made up soon so more people can try putting it together. Any more suggestions? -Ron Menelli menelli@tellabs.com From jcross@ecel.uwa.oz.au Wed Oct 23 01:42:45 1991 Received: from decel.ecel.uwa.oz.au by karazm.math.UH.EDU with SMTP id AA24018 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 01:42:45 -0500 Received: from accfin.ecel.uwa.oz.au by decel.ecel.uwa.oz.au with SMTP (5.61+IDA+MU) id AA17208; Wed, 23 Oct 1991 14:40:59 +0800 From: jcross@ecel.uwa.oz.au (Jennifer Cross - pgmr) Message-Id: 9110230650.AA17992@accfin.ecel.uwa.oz.au Subject: Re: Standards To: glove-list@karazm.math.uh.edu Date: Wed, 23 Oct 91 14:50:15 WST X-Mailer: ELM [version 2.3 PL11] Forwarded message: > From: Bernie Roehl broehl@sunee.waterloo.edu > Subject: Standards > Some micellaneous thoughts on standards: > > After some careful thought, I've come to the conclusion that the various > VR input devices will be too varied to make a single, universal interface > practical. Depends at which level of abstration you use. SGI have a neat tool called "ConMan" which uses a pipe type metaphor to "connect" processes. With this, you could "connect" each of the PG output steams to various functions and customise the interface without any programming. (each process specifies it's input and output sockets to ConMan, and it manages the data flow). […] > Since we wll probably have a set of routines for each VR input device we > develop, I would propose a naming convention: all the routines related to > the glove we love will have names prefixed with "glove_". Thus our ^^^^^^^^ no no no! Suffixed! hence init_glove() (perhaps open_glove() might be better) read_glove() reset_glove() (Still has a place in life - to reset glove parameters!) close_glove() (alternative to quit_glove) This allows like routines to be grouped by function (again abstracting from the specific). This would also make (next level up) routines like init(GLOVE) reasonable. > initialization routine would be glove_init(), our reading routine would > be glove_read(), and our wrapup routine would be called glove_quit() > (which, as an earlier poster pointed out, is probably more meaningful > than "glove_reset()"). Alternatively, would using a "standard" nameing, like those in X <sadness> or Silicon Graphics GL standard (now being adopted by several major vendors) be better? > > As to the issue of external microcontrollers… I think it would be nice > to standardize a protocol for talking to them. Even though I don't have > one (yet; we have a 68HC11, and I'm just waiting for the person who has > the code to post it), here is what I propose: > > Host sends 'H' to board to put glove in hi-res mode > Host sends 'P' to board to poll it for a 6-byte packet > Host sends 'C' to board to tell it to send full 12-byte packet continuously > Host sends 'S' to board to stop continuous sending > Host sends 'D' to board, followed by a 1-byte byte count, followed by > that number of bytes of data to load into a buffer and execute Single byte char command sequences will prove limiting very quickly (esp. if you want to stick to "meaningful" assignments ?What does D stand for anyway Debug/Dump/Directly exec?) use numeric commands and reserve (top?) bit for "extended command" - 127 "risc" standard commands and 127 _Groups_ of additional commands. so a command like "init" might use a group - init/all, init/fingers, init/pos, etc. but a command like poll current position might be 82 (hex 0x52) anyone know the char? :-) > – > Bernie Roehl, University of Waterloo Electrical Engineering Dept > Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca > BangPath: watmath!sunee!broehl > Voice: (519) 885-1211 x 2607 [work] > Great Job - managed to provoke me to submit! (No I dont have a PG yet, just can't afford a DG!) – _ ( > /) (voice) +61 9 362 6680 /_/> o _ (home) cjcross@DIALix.oz.au / / (/ / <_/ / <_<_</_/ (_ @ Beautiful Perth, Western Australia <_/ /> (work) jcross@ecel.uwa.oz.au </ (voice) +61 9 380 3879 From madsax@u.washington.edu Tue Oct 22 16:46:45 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA24037 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 01:50:53 -0500 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA00500; Tue, 22 Oct 91 23:46:45 -0700 Date: Tue, 22 Oct 91 23:46:45 -0700 From: Mark A. DeLoura madsax@u.washington.edu Message-Id: 9110230646.AA00500@milton.u.washington.edu Sender: madsax@milton.u.washington.edu To: glove-list@karazm.math.uh.edu Subject: Re: Specifics on VPL's Mac Greg Newby says: > They use a high-end model (Mac II cx or fx), 16 Meg ram. The Mac runs > a proprietary program (set of programs, really), called "Body > Electric." I only used this a little bit, but it was basically > an object definition language – the programmer would specify > objects and give them characteristics. The programming language > didn't seem much different from Hypercard, or maybe a database > definition language. Things such as: > define ball > can move > has gravity > size = 10 > shape = round > initial position.. > etc. That's not how the language looked, but those are the types > of characteristics that were defined. Actually, that's just the scripting language– the main part of the program consists of what looks amazingly like LogicWorks– a circuit-building program. You drag a "+" object, connect it to a constant and some other things, dee da dee da. So, it's a dataflow language, essentially. Which causes some problems…variables are a total pain to try to work with (*WHAT* variables?), and the latest version I worked with didn't have much support for floating point. Anyway, I'm not very fond of it. :) Nice concept, though. > > Didn't VPL have a demonstration at SIG/GRAPH with only one Iris? Or > was it an Iris and a Mac… We've got ours running on a Mac and an SGI, now– using a splitter board to get the stereo. I hear that they're planning on creating a combination of Swivel-3D (the modeller), Body Electric (the dataflow language), and extra tools– all in one package, and running on the SGI platform. Sounds promising. > Anyway, that fills in a few details… > – Greg > gbnewby@alexia.lis.uiuc.edu And, a few more details. —Mark =============================================================================== Mark A. DeLoura madsax@milton.u.washington.edu University of Washington "…the paneled room folded itself through a dozen impossible angles, tumbling away into cyberspace like an origami crane." –William Gibson, _Neuromancer_ From nik@bu-it.bu.edu Wed Oct 23 04:02:35 1991 Received: from BU-IT.BU.EDU by karazm.math.UH.EDU with SMTP id AA24527 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 07:06:58 -0500 Received: from BUITC.BU.EDU by bu-it.bu.edu (5.61+++/Spike-2.1) id AA29509; Wed, 23 Oct 91 08:02:39 -0400 From: nik@bu-it.bu.edu (Nik Conwell) Received: by buitc.bu.edu (5.61+++/Spike-2.0) id AA19091; Wed, 23 Oct 91 08:02:35 -0400 Date: Wed, 23 Oct 91 08:02:35 -0400 Message-Id: 9110231202.AA19091@buitc.bu.edu To: ccnc@buacca.bu.edu, glove-list@karazm.math.uh.edu, squier@babbage.ecs.csus.edu Subject: Re: Glove Problems squier@babbage.ecs.csus.edu (Anthony Squier) writes: >I am not sure if I have a glove that has gone bad or somthing else. >I was successful in using the software from either Amazing Computing >or Amiga World to get the glove to work in lores on my Amiga. I've written >my own code as well. But, when I moved the glove to the parallel port (from >the game port originally used for lores), it is now not working. I've not >been able to get the hires Amiga code to work that was posted earlier. The >glove will start to work, then hang. If I unplug the glove from the box and >re-run the program, it runs, then hangs again. Why can this happen. >Could the glove be defective or is it a timing problem? (Come to think of it, >lores code that I've written for the parallel port doesn't work either.) I tried my glove last night using the hires hack (from mab@druwy.att.com). (On a 2000 w/ 1.2 (soon to be 2.0 once I can find it somewhere…..)). That code as supplied won't work with a glove wired in the Byte hack way (Alan Bland used pin 4 where the byte hack uses pin 13). My glove is also wired the Byte hack way. I looked at the code, and determined that to get pin 13 data, you have to use cia b, instead of cia a (for the getbit() function in glovehack/glove.c). Looking the the manuals it appears that the & of 0x04 will mask out the correct bit (it's called select) and the » 2 will shift it to the rightmost bit. When I start the code up, I get values for the x y z rot finger (etc) stuff. I'm not sure if this stuff is valid or not, not knowing what a valid run has in it. Then, after a few seconds, all I seem to be getting in is 0xff, and other runs of the characters. The glove still works ok, and the directional leds light up occasionally. That's another problem. Sometimes the directionals seem to be lighting up totally randomly. I point the glove down, and sometimes the up and right ones will light up. The finger ones seem to behave (after I've made a fist a few times). Also, when I run program 2, and center the glove, it still keeps on beeping as though it wasn't at the center. Is this an indication of noise, and bad placement as others indicated before? (My computer is placed in a corner, and I wasn't in the mood to unplug it, and move it all around yesterday just to test this out). Any insight is welcome. Thanks. -nik – nik@bu-it.bu.edu From cygnus@wpi.WPI.EDU Wed Oct 23 05:34:23 1991 Received: from wpi.WPI.EDU by karazm.math.UH.EDU with SMTP id AA24774 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 09:38:43 -0500 Received: from yaya.WPI.EDU by wpi.WPI.EDU (5.65/4.7) id AA23665; Wed, 23 Oct 91 10:34:25 EST From: cygnus@wpi.WPI.EDU (Marshall Robin) Received: by rugsucker (5.65/CCC-2.0) id AA23321; Wed, 23 Oct 91 10:34:23 EST Date: Wed, 23 Oct 91 10:34:23 EST Message-Id: <9110231434.AA23321@rugsucker> To: glove-list@karazm.math.uh.edu, madsax@u.washington.edu Subject: Re: Specifics on VPL's Mac Hello. I am looking at graduate schools to find one with a program in VR (or whatever the new and trendy term for it is). Many people have mentioned University of Washington, and I was wondering if you knew who would be the person to contact with respect to that program/project. I have already contacted graduate admissions, and received the admissions packet. I am looking for in-depth information regarding the VR research program at UWashington. Thank you in advance for your help. Marshall Robin From cygnus@wpi.WPI.EDU Wed Oct 23 05:45:45 1991 Received: from wpi.WPI.EDU by karazm.math.UH.EDU with SMTP id AA24885 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 09:49:55 -0500 Received: from yaya.WPI.EDU by wpi.WPI.EDU (5.65/4.7) id AA01390; Wed, 23 Oct 91 10:45:47 EST From: cygnus@wpi.WPI.EDU (Marshall Robin) Received: by rugsucker (5.65/CCC-2.0) id AA23421; Wed, 23 Oct 91 10:45:45 EST Date: Wed, 23 Oct 91 10:45:45 EST Message-Id: <9110231445.AA23421@rugsucker> To: glove-list@karazm.math.uh.edu Subject: Oops! Sorry….please ignore that…. -marshall From dstamp@watserv1.uwaterloo.ca Wed Oct 23 06:57:32 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA25063 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 10:01:47 -0500 Received: by watserv1.uwaterloo.ca id <AA21945>; Wed, 23 Oct 91 10:57:32 -0400 Date: Wed, 23 Oct 91 10:57:32 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110231457.AA21945@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Subject: eyephone projects I would be interested to hear descriptions of any homebrew eyephone projects that have been completed. What diplays are you using? Monochrome or color? Binocular or monocular? Field of view? Optics? Are you monitoring the user's head positon? Weight? I'm trying to get an idea of the level of sophistication that is currently being used, for use in future postings. Please post to the list, as I'm sure others care too! - Dave Stampe From nik@bu-it.bu.edu Wed Oct 23 07:48:34 1991 Received: from BU-IT.BU.EDU by karazm.math.UH.EDU with SMTP id AA25266 (5.65c/IDA-1.4.4 for glove-list@karazm.math.UH.EDU); Wed, 23 Oct 1991 10:53:05 -0500 Received: from BUITC.BU.EDU by bu-it.bu.edu (5.61+++/Spike-2.1) id AA02209; Wed, 23 Oct 91 11:48:38 -0400 From: nik@bu-it.bu.edu (Nik Conwell) Received: by buitc.bu.edu (5.61+++/Spike-2.0) id AA21674; Wed, 23 Oct 91 11:48:34 -0400 Date: Wed, 23 Oct 91 11:48:34 -0400 Message-Id: 9110231548.AA21674@buitc.bu.edu To: glove-list@karazm.math.UH.EDU, squier@babbage.ecs.csus.edu Subject: Re: Glove Problems AND ALT.POWER-GLOVE anyone?? Cc: ccnc@buacca.bu.edu squier@babbage.ecs.csus.edu (Anthony Squier) writes: >nik@bu-it.bu.edu (Nik Conwell) writes: » When I start the code up, I get values for the x y z rot finger (etc) stuff. » I'm not sure if this stuff is valid or not, not knowing what a valid run has » in it. Then, after a few seconds, all I seem to be getting in is 0xff, and » other runs of the characters. The glove still works ok, and the directional » leds light up occasionally. >My lights don't appear to be acting normally, but the glove does start giving >data for a few seconds then hangs with 0xff like you described. I have to >unplug it and start over. Did you also try glove stuff? I found that pressing start, and then making a fist a few times, and then centering the glove, and pressing center seems to help sometimes. Perhaps the glove 'times out' or something like that, when you don't make a fist (or something) within a short amount of time. What does everyone else do when they fire it up?? Also: Does anybody have any software, or knowledge of how to relay a mailing list to a newsgroup (and the other way too). As has been mentioned before, the traffic seems to warrant a newsgroup. Why not make an alt.power-glove (we can vote on a decent name if need be), and also mirror it to the mailing list, so that non alt sites can get at the info too. Can this relaying from list to newsgroup be done anywhere or does it have to be done at the site where the mailing list is done from?? If not, and this software works with NNTP, without needing news admin, etc. stuff, then I guess I'm willing to run it here. Getting all this stuff in mail is a bit of a pain, when it seems to be more newsgroup related. Any comments?? -nik – nik@bu-it.bu.edu From jxw1578@cs.rit.edu Wed Oct 23 07:44:53 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA25330 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 11:00:38 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA14935; Wed, 23 Oct 91 11:56:21 -0400 Received: from aird.CS (aird.ARPA) by junior.rit.edu (4.1/5.17) id AA29640; Wed, 23 Oct 91 11:44:53 EDT Date: Wed, 23 Oct 91 11:44:53 EDT From: jxw1578@cs.rit.edu (John X Whitehurst) Message-Id: 9110231544.AA29640@junior.rit.edu To: glove-list@karazm.math.uh.edu Subject: addition to the list I'd like to be added to the power glove mailing list John Whitehurst jjw1578@ultb.isc.rit.edu From dirish@math.utah.edu Wed Oct 23 04:22:20 1991 Received: from math.utah.edu (csc-sun.math.utah.edu) by karazm.math.UH.EDU with SMTP id AA25508 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 11:26:38 -0500 Received: from alfred.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06306; Wed, 23 Oct 91 10:22:23 MDT Received: by alfred.math.utah.edu (5.57/Ultrix3.0-C) id AA28492; Wed, 23 Oct 91 10:22:20 -0600 Date: Wed, 23 Oct 91 10:22:20 -0600 From: dirish@math.utah.edu Message-Id: 9110231622.AA28492@alfred.math.utah.edu To: glove-list@karazm.math.uh.edu In-Reply-To: Dave Stampe-Psy+Eng's message of Tue, 22 Oct 91 22:53:13 -0400 9110230253.AA18321@watserv1.uwaterloo.ca Subject: Transputers… I have also considered transputers for high speed rendering. I was interested in complex scenes with thousands of polygons rather than stereo, but they should work for either. My idea was one transputer with lots of ram to store the display list and n transputers suitably connected to video ram to do the rendering. Then the PC would be used to control the whole system and to talk to the user. After seeing the specs on the new T9000 (Byte, August 1991) I realized that these would make a very powerful system. However, at this point in time I don't have the money to buy a bunch of transputers. (Just an aside, there really isn't an assembly language for the transputer. If the C compiler doesn't generate fast enough code for you then you would write in OCCAM. However, from what I have heard of the quality of the C compiler, you are unlikely to need to do this.) However, I haven't given up on the transputer. If you have addresses for companies which are selling PC transputer cards I would love it if you sent them to me. I really think that people who are interested in VR are going to have to look at some kind of parallel architecture. It is very unlikely that you will be able to get a single serial CPU that is fast enough. Also, VR is quite amenable to parallelizing. A cpu for input devices, a cpu (or more) for stereo output, a cpu for sound, a cpu for the motion platform, a big cpu to coordinate things, and a collection of cpu's to model objects. The only question is whether 100Mbps interconnect is fast enough. Anybody know of a transputer board that has NTSC output and another with a/d and parallel inputs? Dudley Irish Dudley Irish / dirish@math.utah.edu / Manager Computer Operations Center for Scientific Computing, Dept of Mathematics, University of Utah The views expressed in this message do not reflect the views of the Dept of Mathematics, the University of Utah, or the State of Utah. From jim@kaos.stanford.edu Wed Oct 23 03:28:31 1991 Received: from fou-local (fou.Stanford.EDU) by karazm.math.UH.EDU with SMTP id AA25989 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 12:32:13 -0500 Received: from localhost.Stanford.EDU by fou-local (4.1/inc-1.0) id AA18945; Wed, 23 Oct 91 10:28:32 PDT Message-Id: <9110231728.AA18945@fou-local> To: glove-list@karazm.math.uh.edu Subject: Re: Transputers… In-Reply-To: Your message of "Wed, 23 Oct 91 10:22:20 MDT." 9110231622.AA28492@alfred.math.utah.edu Date: Wed, 23 Oct 91 10:28:31 -0700 From: James Helman jim@kaos.stanford.edu A cpu for input devices, a cpu (or more) for stereo output, a cpu for sound, a cpu for the motion platform, a big cpu to coordinate things, and a collection of cpu's to model objects. This is very close to what Division Ltd. system does. Their ProVision system even uses transputers (Iann Barron from Inmos is Division's chairman) with a couple i860's thrown in for FP speed. MP systems can provide better price/performance. The big question is whether the general purpose MP's (off the shelf PCs, Suns or SGIs) will get cheap enough, fast enough. If not, special purpose systems whether home brewed or off-the-shelf like PROVision look attractive. -jim Jim Helman Lab: (415) 723-9127 Stanford University FAX: (415) 591-8165 (jim@KAOS.stanford.edu) Home: (415) 593-1233 "The power of the computer is locked behind a door with no knob." -B. Laurel From newton@neworder.ils.nwu.edu Wed Oct 23 07:22:17 1991 Received: from casbah.acns.nwu.edu by karazm.math.UH.EDU with SMTP id AA26037 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 12:36:00 -0500 Received: from neworder.ils.nwu.edu by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03) id AA22344; Wed, 23 Oct 91 12:31:49 CDT Return-Path: newton@neworder.ils.nwu.edu Received: by neworder.ils.nwu.edu (4.0/SMI-4.0) id AA00815; Wed, 23 Oct 91 12:22:18 CDT From: newton@neworder.ils.nwu.edu (Dave Newton) Message-Id: 9110231722.AA00815@neworder.ils.nwu.edu Subject: Re: Transputers… To: glove-list@karazm.math.uh.edu Date: Wed, 23 Oct 91 12:22:17 CDT In-Reply-To: 9110231622.AA28492@alfred.math.utah.edu; from "dirish@math.utah.edu" at Oct 23, 91 10:22 am X-Mailer: ELM [version 2.3 PL11] In a previous message, dirish@math.utah.edu said: > (Just an aside, there really isn't an assembly language for the transputer. That strikes me as odd, since the $396 T400 board I mentioned comes with C, Occam, and assembly. > However, I haven't given up on the transputer. If you have addresses > for companies which are selling PC transputer cards I would love it if > you sent them to me. > The only question is whether 100Mbps interconnect is fast enough. Um, I would certainly hope so. That two-page article about the VPL thing was using straight ethernet for their interconnects. If 100M isn't fast enough, there's a serious software problem, I'd have to say. From jet Wed Oct 23 08:00:54 1991 Received: by karazm.math.UH.EDU id AA26256 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 13:00:54 -0500 From: J Eric Townsend <jet> Message-Id: 199110231800.AA26256@karazm.math.UH.EDU Subject: Re: Transputers… To: newton@neworder.ils.nwu.edu (Dave Newton) Date: Wed, 23 Oct 91 13:00:54 CDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110231722.AA00815@neworder.ils.nwu.edu; from "Dave Newton" at Oct 23, 91 12:22 pm X-Mailer: ELM [version 2.3 PL11] » The only question is whether 100Mbps interconnect is fast enough. > Um, I would certainly hope so. That two-page article about the VPL thing >was using straight ethernet for their interconnects. If 100M isn't fast >enough, there's a serious software problem, I'd have to say. Ether isn't fast enough for parallel computing.. Intel found this out with the iPSC/1. The iPSC/2 and iPSC/860 use proprietary "Direct Connect" technology that runs dedicated bit-stream lines w/ almost no protocol from one node to the next. – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From jdb9608@cs.rit.edu Wed Oct 23 11:28:07 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA26638 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 14:28:33 -0500 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA23732; Wed, 23 Oct 91 15:24:19 -0400 Received: from texas.CS (texas.ARPA) by junior.rit.edu (4.1/5.17) id AA00679; Wed, 23 Oct 91 15:12:53 EDT From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110231912.AA00679@junior.rit.edu Subject: Re: Standardization Ideas…. To: LEEK@qucdn.queensu.ca Date: Wed, 23 Oct 91 15:28:07 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 199110222259.AA22487@karazm.math.UH.EDU; from "LEEK@QUCDN.QueensU.CA" at Oct 22, 91 6:51 pm X-Mailer: ELM [version 2.3 PL8] > I hope I have not gone way of tangent here. I feel if we are going > to have a standard here, then we should do it right ie. not to limit > ourselves to a particular product or model (eg to save 5 machine > cycles) , allow for expansion in terms of new devices and/or higher > resolution. Some of the hard coder there might want to argue > efficiency with me about the extra processing required… I agree! A few microseconds every loop, much longer once in the initialization, or more complex implementations of the standard interface are all worth it. > As for the interrupt/poll, leave it to the particular machine. I like the > device model on my Amiga that provides both sync & async I/O. Why force > your particular model (TSR, Interrupt, Polling, Multitasking) on others ??? > > K. C. Lee I think it would be good to have the standard provide both, too. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From dstamp@watserv1.uwaterloo.ca Wed Oct 23 11:31:19 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA26668 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 14:35:29 -0500 Received: by watserv1.uwaterloo.ca id <AA19069>; Wed, 23 Oct 91 15:31:19 -0400 Date: Wed, 23 Oct 91 15:31:19 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110231931.AA19069@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, newton@neworder.ils.nwu.edu Subject: Re: Transputers… > From glove-list-request@karazm.math.UH.EDU Wed Oct 23 13:50:33 1991 > From: newton@neworder.ils.nwu.edu (Dave Newton) > Subject: Re: Transputers… > To: glove-list@karazm.math.uh.edu > > In a previous message, dirish@math.utah.edu said: > > (Just an aside, there really isn't an assembly language for the transputer. > > That strikes me as odd, since the $396 T400 board I mentioned comes with > C, Occam, and assembly. > > > However, I haven't given up on the transputer. If you have addresses > > for companies which are selling PC transputer cards I would love it if > > you sent them to me. > > > The only question is whether 100Mbps interconnect is fast enough. > > Um, I would certainly hope so. That two-page article about the VPL thing > was using straight ethernet for their interconnects. If 100M isn't fast > enough, there's a serious software problem, I'd have to say. > Actually, VPL is just sending world database updates by Ethernet, which is OK. But we're talking about sending rendered pixels to the video board, which, for a 500x500x24 bit picture, needs 6 Mbits/sec times the frame rate! Can the video board handle this data rate??? If ypu use 4 transputers, can they SEND this rate??? For our purposes, I think the world database could reside on one transputer, which does preliminary clipping and sends polygon and attribute lists to the other transputers. IF the video board can handle the input speed, this idea will work. But not if you have to design a custom video buffer… Or, how about using 4 video boards, genlocking them, and switching between them as their video segments occur??? Will I run out of "?????"'s??? - Dave Stampe From motcsd!roi!lance@apple.com Sun Oct 23 05:50:27 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA27121 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 15:33:00 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA08528; Wed, 23 Oct 91 13:21:16 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kZofP-00010pC@motcsd.csd.mot.com; Wed, 23 Oct 91 12:55 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA07488; 23 Oct 91 12:50:29 PDT (Wed) To: jim@KAOS.stanford.edu Subject: transputers and division Cc: glove-list@karazm.math.uh.edu Message-Id: 9110231250.AA07476@roi.ca41.csd.mot.com Date: 23 Oct 91 12:50:27 PDT (Wed) From: Lance Norskog lance@roi.ca41.csd.mot.com Division's PC product board pair is one 860 on one card and two Toshiba 3d rendering chips on the other. I got Toshiba to send me glossies on the chips. They do 20k gouraud-shaded tris a second, and I don't remember if they actually do 3d projection matmuls or not. Toshiba (San Jose) refused to send chip spec sheets, claiming that the chip was only for very high-volume customers who sent their engineers to Toshiba Chip U in Japan to learn how to design with the sucker. Sounded like a shuck but you never know… Lance Norskog From narf@u.washington.edu Wed Oct 23 06:41:57 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA27154 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 15:46:08 -0500 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA03324; Wed, 23 Oct 91 13:41:57 -0700 Date: Wed, 23 Oct 91 13:41:57 -0700 From: Francis Taylor narf@u.washington.edu Message-Id: 9110232041.AA03324@milton.u.washington.edu Sender: narf@milton.u.washington.edu To: glove-list@karazm.math.uh.edu In-Reply-To: Lance Norskog's message of 22 Oct 91 17:09:19 PDT (Tue) 9110221709.AA22019@roi.ca41.csd.mot.com Subject: PG controller board Reply-To: narf@hitl.washington.edu Regarding getting +5 from signal lines on the printer port: you really don't want to drag on the output lines in this way, unless you're going to consume close-to-zero current. Look at the high-level current output ratings for an LS244 and you'll see what I mean. My favorite hack is to connect to a disk drive power supply connector (the 4 pin white plastic guys). You get lots of regulated +5 and +12. It's usually pretty easy to snake an extra floppy cable out through a hole in the back of the machine. If you don't have an extra power connector, you can get a Y-adapter at any half-decent computer store. If you can't et to a floppy power cable, then you can use a plug-mount power supply, and put the floppy power connector on the end of it, so the interface can run from either. From narf@u.washington.edu Wed Oct 23 06:49:33 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA27172 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 15:54:13 -0500 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA06378; Wed, 23 Oct 91 13:49:33 -0700 Date: Wed, 23 Oct 91 13:49:33 -0700 From: Francis Taylor narf@u.washington.edu Message-Id: 9110232049.AA06378@milton.u.washington.edu Sender: narf@milton.u.washington.edu To: dstamp@watserv1.uwaterloo.ca Cc: glove-list@karazm.math.uh.edu In-Reply-To: Dave Stampe-Psy+Eng's message of Wed, 23 Oct 91 10:57:32 -0400 9110231457.AA21945@watserv1.uwaterloo.ca Subject: eyephone projects Reply-To: narf@hitl.washington.edu The folks at Reflection Technology are showing a gizmo with a welder's helmet and two Private Eyes. They stuck a Polhemus on top, and they're running a flight simulator game. It's pretty neat. It's featherweight compared to VPL Eyephones. The contrast is AWESOME, but the resolution and field-of-view are so-so. Disclaimer: I used to work at Reflection Technology and I worked on it before I left. From aaronp@narrator.pen.tek.com Wed Oct 23 08:32:04 1991 Received: from relay.tek.com by karazm.math.UH.EDU with SMTP id AA28685 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 17:52:41 -0500 Received: by relay.tek.com id AA27160@relay.tek.com; Wed, 23 Oct 91 15:32:12 -0700 Received: from tekig7.map.tek.com by tektronix.TEK.COM (4.1/7.1) id AA25853; Wed, 23 Oct 91 15:32:00 PDT Received: from narrator.PEN.TEK.COM (narrator.TEK) by tekig7.map.tek.com (4.1/7.1) id AA11478; Wed, 23 Oct 91 15:32:05 PDT Received: from localhost.TEK by narrator.PEN.TEK.COM (4.1/7.1) id AA07268; Wed, 23 Oct 91 15:32:05 PDT Message-Id: 9110232232.AA07268@narrator.PEN.TEK.COM To: glove-list@karazm.math.uh.edu Subject: Moving List to Newsgroup Date: Wed, 23 Oct 91 15:32:04 -0700 From: aaronp@narrator.pen.tek.com Creating a new newsgroup is a good idea, but there are some hard questions that must be answered first. I am going to pose these questions along with some personal comments. 1. Why don't people just start posting to sci.virtual-worlds? The moderators (Bob Jacobson and Mark DeLoura) have indicated that they would love to have posts on the topics presented here. Although that newsgroup is moderated, it is by no means heavily filtered, all posts that are not blatent flames get through. Discussions about high and low end technical issues are encouraged as well as the more phisosphical issues that seem to dominate. 2. If a new newsgroup is created, what should it be called? The discussions have gone beyond the glove, peripherals, and even low-end solutions; the discussions here are simply technical exchanges about virtual interface technology. This is somewhat different from sci.virtual-worlds only because most of the posts are announcements or philosphical in nature – but please refer to question #1, we could change that. Last week I received alot of mail on the naming subject, so I will try to summarize: alt.<anything>: Not enough sites get alt groups so this would require a list to mirror the newsgroup as Nik Conwell describes. Has the advantage of not requiring the lengthy newsgroup creation process. comp.periphs.glove or comp.periphs.virtual: Scope is not as broad as the discussions which take place here. As stated in the preface to this summary, the discussions here have simply gone beyond peripherals. comp.sys.virtual: comp.sys.* groups are for computer manufacturers, not broad application categories. sci.virtual-worlds.low-end or sci.virtual-worlds.homebrew: Those doing 'serious' research are working with both high and low end solutions, so it is difficult to draw an arbitrary line between what is homebrew and what is not; as the price of computer technology is always dropping, what was high-end yesterday will be low-end tommorow. Besides, even if we can make a clear distinction, should we? We have alot to learn from each-other and splitting our efforts could be counter-productive. sci.virtual-worlds.tech: Again, refer to question #1. This name covers the scope of these discussions most completely. It does not, however, inhibit high-end discussions as '.low-end' would. The recent discussions on standardization across the high/low 'boundary' would fit in nicely. 3. If a new newsgroup is created, should it be moderated? Many people feel that moderation inhibits people from posting. Others stress that moderation provides a clean way to archive and produce FAQ answer lists. Another concern is that all the virtual-worlds traffic will go to the un-moderated (un-archived?) newsgroup, leaving the other in the cold. Several people, including myself, have volunteered to moderate if the consensus leans towards this option. I will post a straw-poll next so that I can easily tally up people's feelings on the name and moderation issues; I will also be interested in hearing what people have to say about these questions and my comments. – "when there is no answer, we are free to think." – 1991 Portland Creative Conference – +————–\ | Aaron Pulkka > aaronp@narrator.PEN.TEK.COM +————–/ From aaronp@narrator.pen.tek.com Wed Oct 23 09:03:35 1991 Received: from relay.tek.com by karazm.math.UH.EDU with SMTP id AA28826 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 18:18:23 -0500 Received: by relay.tek.com id AA27284@relay.tek.com; Wed, 23 Oct 91 16:03:44 -0700 Received: from tekig7.map.tek.com by tektronix.TEK.COM (4.1/7.1) id AA26999; Wed, 23 Oct 91 16:03:32 PDT Received: from narrator.PEN.TEK.COM (narrator.TEK) by tekig7.map.tek.com (4.1/7.1) id AA12323; Wed, 23 Oct 91 16:03:34 PDT Received: from localhost.TEK by narrator.PEN.TEK.COM (4.1/7.1) id AA07302; Wed, 23 Oct 91 16:03:37 PDT Message-Id: 9110232303.AA07302@narrator.PEN.TEK.COM To: glove-list@karazm.math.uh.edu Subject: STRAW-POLL: New Newsgroup Name Date: Wed, 23 Oct 91 16:03:35 -0700 From: aaronp@narrator.pen.tek.com Please reply directly to me, rather than the glove-list, with 'STRAW-POLL' somewhere in the subject line. In the body of the message indicate your choice for the name and whether or not you think the group should be moderated. NAME (choose one): alt.glove comp.periphs.glove comp.periphs.virtual sci.virtual-worlds.homebrew sci.virtual-worlds.low-end sci.virtual-worlds.tech Other _ MODERATION: Yes No Don't Care Thank you for your input :) +————–\ | Aaron Pulkka > aaronp@narrator.PEN.TEK.COM +————–/ From cliff@jarthur.Claremont.edu Wed Oct 23 09:18:16 1991 Received: from JARTHUR.CLAREMONT.EDU by karazm.math.UH.EDU with SMTP id AA28847 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 18:23:50 -0500 Message-Id: 199110232323.AA28847@karazm.math.UH.EDU Date: Wed, 23 Oct 91 16:18:16 PDT From: Clifford Stein cliff@jarthur.Claremont.edu To: glove-list@karazm.math.uh.edu Cc: cliff@jarthur.Claremont.edu Subject: [manfredo: Re: standardization] Manfred Krauss asked me to forward this to the list: There's a PostScript PowerGlove timing thing at the end of this, so don't nuke this message yet. —– Forwarded message # 1: Received: from opal.cs.tu-berlin.de by jarthur.Claremont.edu id aa09760; 23 Oct 91 12:39 PDT Received: from medap1.cs.tu-berlin.de by opal.cs.tu-berlin.de with SMTP id AA06367 (5.65c/IDA-1.4.4 for cliff@jarthur.claremont.edu); Wed, 23 Oct 1991 20:36:42 +0100 Received: by medap1.cs.tu-berlin.de (4.1/SMI-4.1) id AA01135; Wed, 23 Oct 91 20:36:31 +0100 From: manfredo@medap1.cs.tu-berlin.de (Manfred Krauss) Message-Id: 9110231936.AA01135@medap1.cs.tu-berlin.de Subject: Re: standardization To: glove-list-request@karazm.math.UH.EDU (Clifford Stein) Date: Wed, 23 Oct 91 20:36:30 MET Cc: cliff@jarthur.claremont.edu In-Reply-To: 199110222328.AA22612@karazm.math.UH.EDU; from "Clifford Stein" at Oct 22, 91 4:24 pm X-Mailer: ELM [version 2.3 PL6] […stuff deleted…] Last week I've ported my power.c code to a quad i860 graphics hardware. After I inserting a delay of 3us after every register access on this fast hardware, the code works very well. Delays are made using a timer. The solution of some jitter problems on the ST should be to use a timer to get constant delays. For me the ST was only a tool to prove hires. My aim is to use a 68HC11 evaluation board which I ordered from a local dealer here in Berlin. Prices are as follows: $55 Qty. of 1 $43 Qty. of 5 $39 Qty. of 10 Development $162.5 kit for IBM-PC with: 68HC11 evaluation board RS232 interface module serial cable to PC documentation (in german) terminal program to communicate with 68HC11 ev. board eeprom burning software for 68HC11 X-assembler some tools Board dimension is 51x54mm The prices are are with german tax so outside of germany the prices are lower I think. All boards come up with a little monitor inside the eeprom to make first steps. BTW. I've drawn the PG timing (in POSTSCRIPT). Cliff could you please forward this mail to the glove-list, I can't get through and get no bad message from my mailer so jet what's on ??? Thanks in advance manfredo To extract the drawing, cut, uudecode, uncompress, print …. Hope there is no bug in it. ———————- cut here —————————- begin 664 pgtiming.ps.Z M'YV0)4" @/)F#ITI8^2D@4.G19(V8<Z4T2&PC!P]9>J<H0.B31J.0M*P(6.Q M!10Y;\[("=.F#0@K%N>D»,&A)TW+D'(R.$"1 T7.65)"-/!A <6?W8$'MHNU\+'M\8K4- X'AB":Z\HY>CSVWZ?-;%6FK YD+6# M2 HNF2 CO\@RXN2@O*X"&JZ,5)1T;0!>3JFUX@=;&RT:A3BI-3)JF>%58AX. MCI /(K;UW7OFM2E?6K-S4J96Z<"'9B/B\^6N 6-+X+5F7@M9"C8>-R/^(;?7 M5C?FZI7F)&E6'5QX,UFW*<C5.%#B./A&&)%8JD^-S$TBN"-'-_JP==?5?5?0 MI]@^6>Z.O!&@^JQ41E[C+'@D>I:=XG7QW >XS75VX100P@LM*J"H.X(,=HGW M=#42F\J, .,.^,J V=H.?'C-YXS7L-_A-?Z+]]_TT&=+9/HE@V2GRHFOUFBO M.'Z)+^.0^/QHVHY]W>[P"ZTFJU[7F?*#U ]82=NZC>?<&N0Z[O;IJXHX/IZG MN24+QL-%HR(-[L4[OK!.Q:KX:/LUV+9%9I>AE;3<@%9@\O+RI;'&PP&T"B9\ MR</[G '""7F'\-M"%Q5?MQC<4";2Q80;'XC@,2*:ZYC X:\(<NO4\GD&QV4] M6,KDJ;<#]E4O543LQ:!"47?0[0I9OZZ>/_GU;5OWY/QN4%Y_BY@ ^'>]A7/2 MZ] H5Y3<DA YYRV %^#8=_<MB%_E]C?WG91SX_SW_ZV -^#(-U9^E-/?9+E5 MGI4+Y>FX'.Y^H][F]_L=EI_EWK=6_I4_X%-YUMV5!^,&^/:-EM?E4CG[/7X; MT@<V7ZYZI^4<^%;NE4?CA?E<KI;SN?TAFZ#_YF(=X+'«\ )]>_Y&P&*@"%@ M^[NI !WO+R\&_U* E7F= DO@OZ0Y,F::KV+(]5BN^/[$G@X5K)1!XRX01O84 M*\I1\9#LW<C"DS*&-@$?WD("[9+8]&_B:8A P_3*K7"@/ %)RN\QI=R62R?% MLHZLN_#<>S%Q#LI@R6(U<BX8=\DY@RVLD(;)+,4N/$,VYYKR:]Z6.\K3L7J< MB2/D1')RON'P43XN-%P?+T"JA7;Z!H/GKOES/H0S"M*YFXS7$ F?\'.M&E,S MK/%#W-PA@ZIHKB WI,._SOM&'M_&+PMLWC'DYPTQ-MB?[W-LL?26'3L)B/3_ MTB@D&.[I_.5R*.@LL '\ACCHU4-TW+%YRL8YA6X=X\!T\I&\^07%W3%17$:K M&NK8>(P!ES(D.GX^ Q;!4#&P/(&UQ^Y8BXX2 [4P>DBA0[G$"?JUT1K+@XY9 MCNZK0.AS<%JL!:_(N;F+7HJ'(M8'2URM%L6]#GV^H(LUNFUN!Z4+91,Z@&B= M<\D_,0CV&L←<_&"S+J Z+BR?<Z4E^@G,HK>&ZO(_SD*T[?\P:[Q?,&F.^+1 MJY=^HQO"FZIP/J9S;KZ@CPXGI^<]FI$\I.N%\T6 P!6/N8T.G&X;2\G7J:%> MI\=FG;"$CHD;/Z$PMS(J*^<IR&:L?,S%([&@SAL[QTXZUK9;GLI"<G5L]@3I MA+*5OA::ZG\Z D2B5S/I"W#.8:M/;[-9#*L;*^LQ1\RHH^F%LC\^SLQ0QS$" M%(77)5M:L.*K.^C<\*9>GL?J#?.9/JHGZZIT.XY6T,<TZF:Y)PCJ<7J#?@>2 MY\7YFYR0:^MM<8S&3W#'1GHTS/0]"N0ZJFR/=1.JLK6>KDLWKK*L#BO3R;,R M>UX2/A/.%T6\J2;$];J#;)>UZG&;X?8K2^G^NK!,N1#+@S&/H"%KI8)5AXQV M?^BL.<MRN<GIYO&F[JA3YQ'[>=83G\1+.EKW,UH7\02-'$#A&^;:,NBY,>SQ MVFR>$:?H=,TKO017Z8^Z/6M%#%1+\F;!L>=C]-JT3A:3;;KQS:ZN*T_L^BAL MJ]?D2P:<TEOGPDG4F.R47^A,NGA.(*+KT_DWO"XW[3T;=FZ"K^:DL'-NKG/3 M7+M^CJW?YQ6RD)ZQ9,8+4\*^*.LJB5V'D+:/P?NYHNZ?B\JS2X NK<.+<GN9 MUJC=#C3[-DB5K>IKNXI^K..$>GK%+EC+[4B:,ERX%\1Z<M<.*2ON,<QU[+8+ MZ'OYA6ZCE^NMR.1^'O/HM+G>SK$ Z;BY>OZT$^8GDF::LC?&K+HT<K='Z2M+ M"'PTYND^,;<N9P<I@?O,'L;.[F0Z>1TI@.V→Y,&VO7N:[ F12H [SDQ<+JH M_^NU^L3UMV]8R#M@W(MKZE5R0-RY0>S/N\0."0<)Q7(/6;V7*IAZ<!ZR9^^R M6Z<.NY?ILV&H?IV3Z@>XJHXFB^AT>T?,W+3)>'OBGK/'R;0ZS_ZZJ^9F&_P, MXM3G9_OYWBP(Z[>R»Y$$.^Y^^JNK%,)HD&_H\(]AA*<"&?!EUDHN7%]PE7+ MR[*R7,&[←RR«O>CO#4\B)++G?P1<Z5ZUUSY:S[8?Z6 _"*>6*.F+/P@OD7 M_L#;Y2T\7EZ5&^8Z_%VNE\?EG?M:/H #YJ3WE6[#\^9#?%0^F-?P?[D2?\1# M[?EW#$_#^^51_ SOPN?E]S<37\6_\&4Y##B^5=O!1_Q>_P8GP/G\-_\7 Y M&&^6P_!6O!FOQ4OA5#P<+\13Y3Y\%A_'+^!<_!H?QK?Q:'R$\"4 '><U0-,U M4U=OWE+.QEM":;5N*% CERFU%\\[)O*!]B+OQ%^C85:@",DOYX%T#>WT<M23 M_-A[R:/7F?P='TD7T6-[MN%3=^O/-<WW1 <*-'D9WX*6="4U&G*3;T"-O!PO M;GSR1I(D'V_6\D!\(HG+%YZZ_ W?&-W1I3P#&$^+U,$\*K_>L4+RXR_?D8?R M?#Q+ET\6\U#C04,[HTJVLY>=5FO.%#5&_0O]T:(T\'QGIQ+"BQ(=/KNQWOS& M6/"4SE!)*X]P.\^"S;MKSJ/2NZ7)D<Q#D+R\L*T^_PS?LWT\^#'5%M8]G_KF M\XX\/&FWKL\WQET)0_-] OV<CA&5X/;" ,T36A,&="-]T0;S.P-!K\RG3!+] MQ(9T9])7WA^9Y"W4??=^1(Z?Y^GS3T) VS&G-.@\QX^(4^+\W#35SQ[TAEZN MSO,N_3.OSK/'*[-&K\I"T"WTVV",)X\(-'G4T!^=/KT:KT,']1)T=.3,1YY' MO5R=U+_Q%<(1;=-7%"'T_GS,KYQ1/=N^D5;R0BR0V[%1T4V]15_1"M3IM$/M MT#]77G22 T8STG"T*R_CB?6) ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From chrisl@cbmvax.cbm.commodore.com Fri Oct 25 12:02:43 1991 Received: from RUTGERS.EDU by karazm.math.UH.EDU with SMTP id AA08995

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 25 Oct 1991 15:58:07 -0500

Received: from cbmvax.UUCP by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with UUCP

id AA23339; Fri, 25 Oct 91 16:05:10 EDT

Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore 2/8/91)

id AA13682; Fri, 25 Oct 91 16:02:44 EDT

From: chrisl@cbmvax.cbm.commodore.com (Christian Ludwig - CATS) Message-Id: 9110252002.AA13682@cbmvax.cbm.commodore.com Subject: Re: why 30hz flickers and movies don't To: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) Date: Fri, 25 Oct 91 16:02:43 EDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110251847.AA19649@watserv1.uwaterloo.ca; from "Dave Stampe-Psy+Eng" at Oct 25, 91 2:47 pm X-Mailer: ELM [version 2.2 PL0]

>Been following the thread on Sega LCD glasses.
>
>Why does 30hz to each eye cause a flicker, when 24hz (Film) does not?
>

I believe the reason is that the Sega glsses give you 50% duty cycle
on the images to each eye, and a movie projector gives over 90%.
This results in 5 times the 24 Hz/30Hz flicker (at least). You can
see the flicker in movies if you have a fast-moving white object on
a dark background– just look at the edges.

Also… movies are filmed at 24fps, but when projected, each frame is shown TWICE in that 1/24sec bit of time. This approximates the effect of 48fps, hence, no (or at least far less) flicker. Chris Ludwig From dstamp@watserv1.uwaterloo.ca Fri Oct 25 13:38:14 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA09338

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 25 Oct 1991 16:42:40 -0500

Received: by watserv1.uwaterloo.ca

id <AA29851>; Fri, 25 Oct 91 17:38:14 -0400

Date: Fri, 25 Oct 91 17:38:14 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110252138.AA29851@watserv1.uwaterloo.ca To: chrisl@cbmvax.cbm.commodore.com, dstamp@watserv1.uwaterloo.ca Subject: Re: why 30hz flickers and movies don't Cc: glove-list@karazm.math.uh.edu

From glove-list-request@karazm.math.UH.EDU Fri Oct 25 17:01:23 1991
From: chrisl@cbmvax.cbm.commodore.com (Christian Ludwig - CATS)
Subject: Re: why 30hz flickers and movies don't
To: dstamp@watserv1 (Dave Stampe-Psy+Eng)
Cc: glove-list@karazm.math.uh.edu

> >Been following the thread on Sega LCD glasses.
> >
> >Why does 30hz to each eye cause a flicker, when 24hz (Film) does not?
> >
>
> I believe the reason is that the Sega glsses give you 50% duty cycle
> on the images to each eye, and a movie projector gives over 90%.
> This results in 5 times the 24 Hz/30Hz flicker (at least). You can
> see the flicker in movies if you have a fast-moving white object on
> a dark background– just look at the edges.
>

Also… movies are filmed at 24fps, but when projected, each frame is shown
TWICE in that 1/24sec bit of time. This approximates the effect of 48fps,
hence, no (or at least far less) flicker.

Chris Ludwig

Depends on HOW you're showing the movie! The film has to move SOMETIME, and be blanked during the motion. So you've got a MINIMUM blanking interval. Adding TWICE the amount of TWICE the frequency (do a Fourier analysis of the brightness versus time) will result in the same level of error thru a first-order lowpass filter, which the human eye is. Showing the same frame twice won't help that much. - Dave Stampe From nstar!bluemoon!moonhawk@iuvax.cs.indiana.edu Wed Oct 23 13:33:55 1991 Received: from RUTGERS.EDU by karazm.math.UH.EDU with SMTP id AA09405

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 25 Oct 1991 16:49:44 -0500

Received: from PORTAL.BCM.TMC.EDU by rutgers.edu (5.59/SMI4.0/RU1.4/3.08)

id AA01421; Fri, 25 Oct 91 17:45:28 EDT

Received: from GAZETTE.BCM.TMC.EDU by portal.bcm.tmc.edu id aa07325;

        25 Oct 91 15:58 CDT

Received: from bcm.tmc.edu by gazette.bcm.tmc.edu (AA05698); Thu, 24 Oct 91 02:30:48 CDT Received: from lib.tmc.edu by bcm.tmc.edu (AA23055); Thu, 24 Oct 91 02:30:45 -0500 Received: by lib.tmc.edu; Thu, 24 Oct 91 02:33:32 CDT Received: by iuvax.cs.indiana.edu Received: by nstar.rn.com (/\==/\ Smail3.1.20.1 #20.1)

id <m0kZyyt-0002nXC@nstar.rn.com>; Thu, 24 Oct 91 01:55 EST

Received: by bluemoon.uucp (/\=-/\ Smail3.1.16.1 #16.27)

id <m0kZqD6-0003Z8C@bluemoon.uucp>; Wed, 23 Oct 91 17:33 EDT

To: glove-list@karazm.math.uh.edu Subject: Hey… From: David Culberson moonhawk@bluemoon.rn.com Comments: Life's good as long as there's a McDonalds! Message-Id: 9qHaaB1w164w@bluemoon.rn.com Date: Wed, 23 Oct 91 17:33:55 EDT Organization: Blue Moon BBS ((614) 868-998[024])

      I would like taken off the glove list; how do I go about doing so? 

thanks. moonhawk@bluemoon moonhawk@bluemoon.rn.com From tinman%agora.rain.com@m2xenix.psg.com Fri Oct 25 15:17:00 1991 Received: from m2xenix.psg.com by karazm.math.UH.EDU with SMTP id AA12078

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 00:23:06 -0500

Received: by m2xenix.psg.com (/\==/\ Smail3.1.22.1 #22.3)

id <m0kagPz-000EEkC@m2xenix.psg.com>; Fri, 25 Oct 91 22:18 PDT

Received: by agora.rain.com (/\==/\ Smail3.1.21.1 #21.6)

id <m0kagOK-0001dSC@agora.rain.com>; Fri, 25 Oct 91 22:17 PDT

Message-Id: m0kagOK-0001dSC@agora.rain.com Date: Fri, 25 Oct 91 22:17 PDT From: tinman@agora.rain.com (David Tinnyo) To: glove-list@karazm.math.uh.edu Subject: Amiga Hires Code Please? Could someone with the Amiga hires code please mail it to me. I'm a poor boy with no FTP access. Thanks! BTW, I've been trying to use the IBM code with no luck… Maybe my timer routines are inaccurate? What kind of tolerances are there for the delays? Maybe the Amiga code answers these questions? –David TinNyo tinman@agora.rain.com From stm@sequent.com Fri Oct 25 15:22:05 1991 Received: from gateway.sequent.com ([138.95.19.12]) by karazm.math.UH.EDU with SMTP id AA12087

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 00:27:19 -0500

Received: from time1.sequent.com by gateway.sequent.com (5.61/1.34)

id AA00953; Fri, 25 Oct 91 22:23:57 -0700

Received: by time1.sequent.com (5.61/1.34)

id AA09587; Fri, 25 Oct 91 22:22:06 -0700

From: Scott "Worf" MacQuarrie stm@sequent.com Message-Id: 9110260522.AA09587@time1.sequent.com Subject: Re: Oops! To: Date: Fri, 25 Oct 91 22:22:05 PDT Cc: glove-list@karazm.math.uh.edu Priority: normal In-Reply-To: <9110231445.AA23421@rugsucker>; from "Marshall Robin" at Oct 23, 91 10:45 am X-Mailer: ELM [version 2.2 CRG PL14c] PLease remove me from this list. Thanks, – Scott T. MacQuarrie Marketing Training Developer

                                     Sequent Computer Systems   
   stm@sequent.com                Beaverton, OR      503-578-5456 

"Life is Good!" From stm@sequent.com Fri Oct 25 15:22:57 1991 Received: from gateway.sequent.com ([138.95.19.12]) by karazm.math.UH.EDU with SMTP id AA12094

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 00:28:10 -0500

Received: from time1.sequent.com by gateway.sequent.com (5.61/1.34)

id AA00960; Fri, 25 Oct 91 22:24:48 -0700

Received: by time1.sequent.com (5.61/1.34)

id AA09599; Fri, 25 Oct 91 22:22:58 -0700

From: Scott "Worf" MacQuarrie stm@sequent.com Message-Id: 9110260522.AA09599@time1.sequent.com Subject: URGT* Removal from list To: glove-list@karazm.math.uh.edu Date: Fri, 25 Oct 91 22:22:57 PDT Priority: urgent X-Mailer: ELM [version 2.2 CRG PL14c] Please remove me from this list. Thanks, – Scott T. MacQuarrie Marketing Training Developer

                                     Sequent Computer Systems   
   stm@sequent.com                Beaverton, OR      503-578-5456 

"Life is Good!" From arellano@jetson.csc.ti.com Fri Oct 25 20:58:28 1991 Received: from TI.COM by karazm.math.UH.EDU with SMTP id AA12268

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 02:03:57 -0500

Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com id AA24151; Sat, 26 Oct 1991 01:59:13 -0500 Received: from jetson.dsg.ti.com (jetson) by tilde.csc.ti.com id AA27100; Sat, 26 Oct 1991 01:58:43 -0500 Received: by jetson.dsg.ti.com (4.1/SMI-4.1)

id AA05908; Sat, 26 Oct 91 01:58:28 CDT

Date: Sat, 26 Oct 91 01:58:28 CDT Message-Id: 9110260658.AA05908@jetson.dsg.ti.com To: glove-list@karazm.math.uh.edu From: arellano@itg.ti.com Sender: arellano@jetson.csc.ti.com Subject: remove from list Please remove me from this list. Many thanks. From gibsonm@u.washington.edu Fri Oct 25 17:45:18 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA12314

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 02:54:44 -0500

Received: by milton.u.washington.edu

(5.65/UW-NDC Revision: 2.1 ) id AA27223; Sat, 26 Oct 91 00:45:18 -0700

Date: Sat, 26 Oct 91 00:45:18 -0700 From: Michael Gibson gibsonm@u.washington.edu Message-Id: 9110260745.AA27223@milton.u.washington.edu Sender: gibsonm@milton.u.washington.edu To: glove-list@karazm.math.uh.edu Subject: Power Glove - Amiga - Interface hints please. I've been following this list for a while, and I finally got a glove to try and hook to my Amiga. I have never really played around with hardware, so I am not quite sure how to go about making a connector for the glove. I think I can handle the amiga side, but what I am not sure about is how to wire the connector to the powerglove side. Do I have to solder it to the nintendo connector or something? Please help me with this, and when you explain, please be very clear and explicit. I tried to get the amiga hires code working, but I think that my interface to the nintendo side was very bad. While I'm at it, I noticed that there is only one piece of code availiable for the Amiga and glove on the archive at karazm.math.uh.edu I'm sure there must be more out than this. If you have any code for the Amiga at all, including older lores code, please post it to the karazm archive (in /pub/VR/Sources I think) or mail it to me. I would sure appreciate it. My friend has the Amazing Computing powerglove article, but neither of us has a modula-2 compiler. Can someone who has that code either post it or mail it to me? Thank you very much for the help. Looking forward to 3-d input,

			Michael
			gibsonm@milton.u.washington.edu

From sjs@stekt.oulu.fi Sat Oct 26 11:00:06 1991 Received: from ousrvr.oulu.fi by karazm.math.UH.EDU with SMTP id AA12369

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 03:03:12 -0500

Received: from stekt.oulu.fi by ousrvr.oulu.fi (4.0/SMI-4.0)

id AA19607; Sat, 26 Oct 91 09:58:54 +0200

Received: by stekt.oulu.fi (4.1/SMI-4.1)

id AA27241; Sat, 26 Oct 91 10:00:06 +0100

Date: Sat, 26 Oct 91 10:00:06 +0100 From: sjs@stekt.oulu.fi (Sami Sallinen) Message-Id: 9110260900.AA27241@stekt.oulu.fi To: glove-list@karazm.math.uh.edu

Howdy!
I am an undergraduate student of computer engineering at the university
of Oulu, Finland. I have a burning desire to get me a PoverGlove (primarily)
and/or a pair of Sega LCD glasses, but the only supplier that i found for 
the glove wouldnt deliver overseas. So I wonder if anybody on this list 
would happen to have a glove to sell or would be as kind as to buy one for
me and send it to me (after feceiving the money from me, of course).
I am willing to pay some extra in the latter case.
If anybody feels intrested, please e-mail me.
Sami Sallinen    sjs@stekt.oulu.fi

Tel +358-81-339179 (Voice)
  1. Thanks in advance!

From mab@druwy.att.com Sat Oct 26 03:08:00 1991 Received: from att.att.com by karazm.math.UH.EDU with SMTP id AA13173

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 10:14:25 -0500

Message-Id: 199110261514.AA13173@karazm.math.UH.EDU From: mab@druwy.att.com Date: Sat, 26 Oct 91 09:08 MDT To: att!glove-list In-Reply-To: 9110260745.AA27223@milton.u.washington.edu Subject: Power Glove - Amiga - Interface hints please. The common method of glove-interface requires you to find a Nintendo extender cable. That's about the only way to find those funky 7-pin connectors. You need to hook up your computer to the short glove cable that normally plugs directly into the nintendo joystick port. Of course, nobody around here carries extender cables anymore. When I asked around at toy stores, they suggested I use the new wireless extenders, heh heh. My actual interface hack on the glove side is just a bunch of wires that I plug directly into the holes in the female glove connector. I used non-stranded wires of the correct guage (I dunno which guage I use) and they just insert into the nintendo connector and fit snugly. I color-coded them so I know how to re-insert them if I ever remove them. So I as able to do the interface without destroying the glove connector and without finding an extender cable. From mab@druwy.att.com Sat Oct 26 03:23:00 1991 Received: from att.att.com by karazm.math.UH.EDU with SMTP id AA13192

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 10:29:22 -0500

Message-Id: 199110261529.AA13192@karazm.math.UH.EDU From: mab@druwy.att.com Date: Sat, 26 Oct 91 09:23 MDT To: att!glove-list Subject: Amiga Hires Code Attention everyone who wants the Amiga hi-res code but still doesn't have it…. I have been *swamped* this week at work and hence have been ignoring my e-mail. There have been *many* more requests for the Amiga glove code than I had anticipated. I sent out about twenty copies last weekend shortly after posting the initial announcement. There have been lots more requests since then, and combined with all the VGA scan-line trash that's been appearing on the list, I've been pretty-much ignoring the glove-list. (side note: please stay on the topic of gloves *only*) If you want the Amiga code and don't have it, it should be available at the ftp site. If you are *unable* to use ftp (i.e. your site doesn't allow it, as opposed to you don't know how to use ftp) then send me your request again specifically mentioning that you cannot get ftp access, and I'll e-mail it to you. I apologize to anyone whose requests for code I've ignored, but I just can't keep up with the e-mail this week. From mab@druwy.att.com Sat Oct 26 03:32:00 1991 Received: from att.att.com by karazm.math.UH.EDU with SMTP id AA13216

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 10:39:23 -0500

Message-Id: 199110261539.AA13216@karazm.math.UH.EDU From: mab@druwy.att.com Date: Sat, 26 Oct 91 09:32 MDT To: att!glove-list Subject: Amiga Hires Code - Timing For those of you who have asked, the timing in my Amiga hi-res code was determined by trial-and-error one Saturday morning. It started working on my A500, and it worked on a friend's A2000. It doesn't work as-is on my A3000 simply due to the timing loops not being right. I get some flakey behavior on my setup too. About half the time I run it, I get all FF's or various bit patterns that don't correspond to the glove protocol. Stopping it and re-running it usually causes the glove to beep and then it starts working. The correct way to get the Amiga code to work would be to do the kind of timing calibration done in one of the PC versions posted this week. I was working on a similar calibration last weekend when trying to get the glove to work on my A3000. I wasn't having much success, and now that the PC code is available, maybe I'll get time to port it instead. The postscript timing diagrams that appeared on the list should help too. If anyone else has done any Amiga code for the glove, even lo-res, I'd appreciate seeing it. From timd@twaddle.dell.com Fri Oct 25 03:52:26 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA13381

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 11:21:41 -0500

Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G)

   id AA10950; Sat, 26 Oct 91 10:50:13 CDT

Received: by twaddle.dell.com. (4.1/SMI-4.1)

id AA27044; Fri, 25 Oct 91 08:52:26 CDT

Date: Fri, 25 Oct 91 08:52:26 CDT From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110251352.AA27044@twaddle.dell.com.> To: glove-list@karazm.math.uh.edu Subject: State machine boxes Even though I already made loud noises that the 8051 was a great choice for a pglove → serial box, I have been thinking about how simple a state machine without a microp could be. Has anybody out there tried burning a EPROM or E2PROM to deliver the hires start sequence? In the same way that audio samples are "pseudo-digitized" and burned onto a PROM then clocked out directly to a speaker to give a reasonable reproduction, any digital sequence can be burned and reproduced at a consistent rate. A xtal, a PROM, a MAX232 for serial output and assorted glue ought to put the glove in hires and deliver the 12 byte packet to the serial port. It could have a reset button on the box. This would still leave noise reduction and such to software, but timing would no longer be an issue. Good start for a MIDI controller box too… More from less. –Tim timd@twaddle.dell.com From timd@twaddle.dell.com Thu Oct 24 08:35:15 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA13388

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 11:21:56 -0500

Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G)

   id AA10968; Sat, 26 Oct 91 10:50:28 CDT

Received: by twaddle.dell.com. (4.1/SMI-4.1)

id AA25495; Thu, 24 Oct 91 13:35:15 CDT

Date: Thu, 24 Oct 91 13:35:15 CDT From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110241835.AA25495@twaddle.dell.com.> To: glove-list@karazm.math.uh.edu Subject: 8051s !!! I'm suprised that there aren't scads of 8051 developers working on a PGlove box. I am! The 8051 beats the 68HC11 for a couple of reasons in my book. 1) Lots of PD assemblers, dissassemblers, simulators 2) Reasonably priced pseudo-ICEs (approx $200) 3) Cheese-whiz Assembly code (includes such commands

   as ANL and ORL, gotta love it!)

Anyways the point is that it's a great hombrew platform. I've built a bunch of MIDI boxes at home with nothing but a scope. They also have a 8032AH with on-board BASIC, who could ask for more? I am trying as fast as I can to whip up a MIDI box for the glove, I want to map my MIDI drum machine to the joystick space as a start. Hires mode makes LOTS of stuff possible, especially if you include one of those NINTENDO twister board things (power-pad?) that you can walk around on and use as an input device. Realistically it's probably easier to run the glove into a PC with a MIDI card and develop SW there, but maybe not. Have any of you homebrewers looked at C&T's PC on a chip with SUPERSTATE? LOTS and LOTS of potential for low cost-high result development. Forget the 68HC11, the 8051 is the industry workhorse for good reason. Sorry if I'm stepping on any toes, but discourse is the soul of reason, or something. –Tim timd@twaddle.dell.com From james@panix.com Sat Oct 26 14:53:58 1991 Received: from cmcl2.NYU.EDU (NYU.EDU) by karazm.math.UH.EDU with SMTP id AA14107

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 18:08:56 -0500

Received: by cmcl2.NYU.EDU (5.61/1.34)

id AA27808; Sat, 26 Oct 91 19:04:37 -0400

Received: by panix.com (5.64/A/UX-2.01-AMR)

id AA07269; Sat, 26 Oct 91 18:53:58 EDT

Date: Sat, 26 Oct 91 18:53:58 EDT From: james@panix.com (James Britt) Message-Id: 9110262253.AA07269@panix.com To: glove-list@karazm.math.uh.edu I finally got a glove; Toys R Us in Manhattan, $30.00. Could somebody summurize what are the current options for interface to an IBM? Thanks! James Britt, NYC :w From nop@att1.Mankato.MSUS.EDU Sat Oct 26 11:57:16 1991 Received: from ATT1.Mankato.MSUS.EDU by karazm.math.UH.EDU with SMTP id AA14143

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 18:36:40 -0500

Received: by att1.Mankato.MSUS.EDU (5.59/25-eef)

id AA02078; Sat, 26 Oct 91 16:57:16 CDT

Date: Sat, 26 Oct 91 16:57:16 CDT From: Jay A. Carlson nop@att1.Mankato.MSUS.EDU Message-Id: 9110262157.AA02078@att1.Mankato.MSUS.EDU To: timd@twaddle.dell.com Cc: glove-list@karazm.math.uh.edu In-Reply-To: Tim Deagan's message of Thu, 24 Oct 91 13:35:15 CDT <9110241835.AA25495@twaddle.dell.com.> Subject: 8051s !!!

I'm suprised that there aren't scads of 8051 developers
working on a PGlove box. I am! The 8051 beats the 68HC11
for a couple of reasons in my book.

I'm not going to get into a my-controller-is-better-than-your- controller thread, as the glove-list is not the place to do it. However, I don't want the list to be mislead too far by either the Intel or the Motorola partisans.

1) Lots of PD assemblers, dissassemblers, simulators

Motorola distributes a freeware assembler for the HC11 (and in fact, their entire 8-bit processor line) with source. It's nothing fancy, but it gets the job done. If you need a macro assembler, I can heartily recommend Matt Dillon's freeware DASM. I've used it for several projects targeted to the HC11 and the 6502. The PD MS-DOS program SIM68 does a good job of simulating an HC11. I don't have much use for it as I use an Amiga for all my development stuff (and find that I don't *usually* make mistakes that are easily solved with a simulator. :-)

2) Reasonably priced pseudo-ICEs (approx $200)

The HC11 was designed with cheap development tools in mind. Motorola's 68HC11 EVB will do pseudo-ICE of the single chip modes for $88.11. Expanded mode pseudo-ICE can be done with Motorola's EVM, or third-party products in the $300 range. Real ICE's are simpler due to a number of other features in the chip.

3) Cheese-whiz Assembly code (includes such commands
as ANL and ORL, gotta love it!)

No comment.

Anyways the point is that it's a great hombrew platform.
I've built a bunch of MIDI boxes at home with nothing but
a scope. They also have a 8032AH with on-board BASIC, who could
ask for more?

How 'bout a freeware BASIC that can run on any of the processor line? Motorola distributes a multitasking real-time executive (MCX) for the HC11, incidentally. Is there anything like this available for the Intel controllers? Just off the top of my head, here are a few reasons to prefer the HC11: fully static CMOS design, more orthagonal instruction set, cleaner bus, not Intel. :-/

I am trying as fast as I can to whip up a MIDI box for the glove,
I want to map my MIDI drum machine to the joystick space as a start.
Hires mode makes LOTS of stuff possible, especially if you include
one of those NINTENDO twister board things (power-pad?) that you
can walk around on and use as an input device.

Just mapping the glove to continuous controllers would interest a lot of my musician friends. There are so many possibilities of things to do with the glove that it's hard to come up with a single really concrete ones. Lemme know what you get working.

Forget the 68HC11, the 8051 is the industry workhorse for good reason.
Sorry if I'm stepping on any toes, but discourse is the soul of reason,
or something.

Or something. :-)

–Tim
timd@twaddle.dell.com
// Jay Carlson

\X/ nop@att1.mankato.msus.edu To subscribe to the MC68HC11 list, email to mc68hc11-request@elden.cse.nau.edu. From dstamp@watserv1.uwaterloo.ca Sat Oct 26 17:08:52 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA14354

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 26 Oct 1991 20:13:05 -0500

Received: by watserv1.uwaterloo.ca

id <AA27676>; Sat, 26 Oct 91 21:08:52 -0400

Date: Sat, 26 Oct 91 21:08:52 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110270108.AA27676@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Subject: VGA: 6400 polys/sec OK: so I finally sat down and wrote some polygon (actually, triangle) drawing code for the VGA card. The code spends 70% of its time waiting on the VGA card, so processor speed isn't a big factor. On a 486/25, and a Paradise VGA card, I get 6400 polys/sec, or 156 uS per poly. This is on a 320x200x16 color screen (same as most 3D video games use). I'm not going to post the code now (maybe later) suffice to say, it's assembler embedded in a Turbo C++ program. Uses 32-bit math, so it'll run on 386 and 486 IBM PC's only. This is still borderline for a VR program using BSP-tree techniques: Assume 50% of the time is used for poly drawing, and the polys are 3 deep on the screen on average (this is the usual statistic in the literature) Now, that means 3200 polys/sec (300/sec with interface code) so we can draw 300 polys per frame at 10 frames/sec. This may be somewhat optimistic, as it takes 10.4 mS just to clear the screen and 300 polys will cover less than half the screen (3 deep). More later. Oh, BTW, the benchmark was done with 24x24 triangular shaded polys. - Dave Stampe From ecl6gum%sun.leeds.ac.uk@VTVM2.CC.VT.EDU Sun Oct 27 12:40:05 1991 Received: from vtvm2.cc.vt.edu by karazm.math.UH.EDU with SMTP id AA00582

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 27 Oct 1991 12:08:47 -0600

Received: from UKACRL.BITNET by VTVM2.CC.VT.EDU (IBM VM SMTP V2R1)

 with BSMTP id 6935; Sun, 27 Oct 91 09:02:33 EST

Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 6098; Sun, 27 Oct 91 14:03:28 GMT Received:

         from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 7250; Sun, 27
          Oct 91 14:03:28 GMT

Via: UK.AC.LEEDS.MAILER; 27 OCT 91 14:03:25 GMT Received:

         from sunserv1_ie0 by mailer.leeds.ac.uk; Sun, 27 Oct 91 12:42:30 gmt

Received: from sun030.sun.leeds.ac.uk by sun.leeds.ac.uk; Sun, 27 Oct 91

          12:40:00 GM

From: ecl6gum@sun.leeds.ac.uk Date: Sun, 27 Oct 91 12:40:05 GMT Message-Id: 1096.9110271240@sun030.sun.leeds.ac.uk To: glove-list@karazm.math.uh.edu Subject: Using the PowerGlove on a SG PI This is my first post to the Glove-list, so please excuse any lack of protocol! I've recently started (ie a week ago) my PhD study at the University of Leeds, England, and am looking into developing a VR system for use in CAD/Scientific Visualisation. I'll be using a SG PI machine, and am looking to connect the PowerGlove to it. I've ftp'd Greg Newby et al.'s code for using the PowerGlove on the PI, but have no details on how to physically connect the PowerGlove and what is involved. Could someone on the list please enlighten me? Thanks. Gurm Bacchus, e-mail: ecl6gum@uk.ac.leeds.sun University of Leeds, voice : (+UK) 0532-335406. England. From jet Sun Oct 27 06:53:48 1991 Received: by karazm.math.UH.EDU id AA01453

(5.65c/IDA-1.4.4 for glove-list); Sun, 27 Oct 1991 12:53:50 -0600

From: J Eric Townsend <jet> Message-Id: 199110271853.AA01453@karazm.math.UH.EDU Subject: ping/test pls ignore To: glove-list Date: Sun, 27 Oct 91 12:53:48 CST X-Mailer: ELM [version 2.3 PL11] boo. – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 AMA# I-forget PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From tinman%agora.rain.com@m2xenix.psg.com Sun Oct 27 04:34:00 1991 Received: from m2xenix.psg.com by karazm.math.UH.EDU with SMTP id AA02707

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 27 Oct 1991 14:40:04 -0600

Received: by m2xenix.psg.com (/\==/\ Smail3.1.22.1 #22.3)

id <m0kbHCi-0006DCC@m2xenix.psg.com>; Sun, 27 Oct 91 12:35 PST

Received: by agora.rain.com (/\==/\ Smail3.1.21.1 #21.6)

id <m0kbHBL-0001dbC@agora.rain.com>; Sun, 27 Oct 91 12:34 PST

Message-Id: m0kbHBL-0001dbC@agora.rain.com Date: Sun, 27 Oct 91 12:34 PST From: tinman@agora.rain.com (David Tinnyo) To: glove-list@karazm.math.uh.edu Subject: Help with amiga Hi-res Okay, so I've got the amiga hi-res code, but it doesn't work. I've an Amiga 2000HD with 3Megs. The code says its tested on a 2000, and I'm sure my connections are sound. What gives? Anyone have any tips on massaging the timing so it works on my machine? By the way I think there's an error in the pinouts of the glove in /glovehack/glove.c. It says pin 7 of the glove is +5, an I'm quite sure its pin 5. –David Tin Nyo, tinman@agora.rain.com From blossom-jonathan@CS.YALE.EDU Sun Oct 27 11:47:07 1991 Received: from SUNED.ZOO.CS.YALE.EDU (ZOO-GW.CS.YALE.EDU) by karazm.math.UH.EDU with SMTP id AA03071

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 27 Oct 1991 15:51:21 -0600

Received: by SUNED.ZOO.CS.YALE.EDU; Sun, 27 Oct 91 16:47:07 EST Date: Sun, 27 Oct 91 16:47:07 EST From: Jonathan Blossom blossom-jonathan@CS.YALE.EDU Message-Id: 9110272147.AA24006@SUNED.ZOO.CS.YALE.EDU Received: by suned (suned)

        via WIMP-MAIL (Version 1.3/1.7) ; Sun Oct 27 16:47:06

To: glove-list@karazm.math.uh.edu Subject: Mac interfaces and hi-res

It sounds like most people are using the glove on IBMs and Amigas, but

I'd like to connect my glove to my Mac IIci. The interface designed by Joe Britt may be a good idea, but it's limited to low-res mode. Can anyone direct me to more information about connecting the glove to a Macintosh serial port, activating and reading hi-res mode, and reading the glove from within THINK C or MPW C??

Thanks a lot!
      -Jon Blossom

From ralph@aplcen.apl.jhu.edu Sun Oct 27 11:58:16 1991 Received: from aplcen.apl.jhu.edu by karazm.math.UH.EDU with SMTP id AA03149

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 27 Oct 1991 16:02:30 -0600

Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg)

id AA08507; Sun, 27 Oct 91 16:58:16 -0500

Date: Sun, 27 Oct 91 16:58:16 -0500 From: ralph@aplcen.apl.jhu.edu (Ralph Roland) Message-Id: 9110272158.AA08507@aplcen.apl.jhu.edu To: glove-list@karazm.math.uh.edu Subject: connection suggestion, and other questions mab@druwy.att.com writes :

My actual interface hack on the glove side is just a bunch of wires
that I plug directly into the holes in the female glove connector.
I used non-stranded wires of the correct guage (I dunno which guage I
use) and they just insert into the nintendo connector and fit snugly.
I color-coded them so I know how to re-insert them if I ever remove them.
So I as able to do the interface without destroying the glove connector
and without finding an extender cable.

If you can't find an extender cable, a more permanent solution would be to open the interface box (the one with the telephone number on it) and solder a new cable directly to the PCB. All five wires from the seven pin connector attach directly to the nine pin connector, and right next to the 9Pin connector is an unused hole-pattern for another 9Pin wired in parallel. It seems almost like it was made for this. BTW, does anybody have details on how the sonics in the glove work (i.e. Schematics, Theory of Operation, etc)? Has anybody considered seperating the receiver(?) boxes by more than the 1.5' to see if a larger 'field of view','range of motion',etc can be achieved (without replacing the glove controller itself)? Has anyone considered any mods that could be done to the glove to allow multiple gloves to be used in the same room? So many questions so little time… Ralph Roland /RER/ From dstamp@watserv1.uwaterloo.ca Sun Oct 27 12:16:18 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA03241

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 27 Oct 1991 16:20:32 -0600

Received: by watserv1.uwaterloo.ca

id <AA05992>; Sun, 27 Oct 91 17:16:18 -0500

Date: Sun, 27 Oct 91 17:16:18 -0500 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110272216.AA05992@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, ralph@aplcen.apl.jhu.edu Subject: Re: connection suggestion, and other questions

From glove-list-request@karazm.math.UH.EDU Sun Oct 27 17:02:19 1991
From: ralph@aplcen.apl.jhu.edu (Ralph Roland)
To: glove-list@karazm.math.uh.edu
Subject: connection suggestion, and other questions


mab@druwy.att.com writes :

>My actual interface hack on the glove side is just a bunch of wires
>that I plug directly into the holes in the female glove connector.
>I used non-stranded wires of the correct guage (I dunno which guage I
>use) and they just insert into the nintendo connector and fit snugly.
>I color-coded them so I know how to re-insert them if I ever remove them.
>So I as able to do the interface without destroying the glove connector
>and without finding an extender cable.

If you can't find an extender cable, a more permanent solution would
be to open the interface box (the one with the telephone number on it)
and solder a new cable directly to the PCB. All five wires from the
seven pin connector attach directly to the nine pin connector, and
right next to the 9Pin connector is an unused hole-pattern for another
9Pin wired in parallel. It seems almost like it was made for this.

BTW, does anybody have details on how the sonics in the glove work
(i.e. Schematics, Theory of Operation, etc)? Has anybody considered
seperating the receiver(?) boxes by more than the 1.5' to see if a
larger 'field of view','range of motion',etc can be achieved (without
replacing the glove controller itself)? Has anyone considered any
mods that could be done to the glove to allow multiple gloves to be
used in the same room? So many questions so little time…

Ralph Roland
/RER/

Yep… Look in the glovelist archives, if you can FTP karazm.math.uh.edu. They're in he PUB directory. I think the June archive has wiring guides and even a (low resolution hardware circuit for measuring distances. If you spread the receiver boxes apart, you'll get less resolution but a larger range. If you're putting the receivers on the floor and hanging your arm down over them, Isuggect moving them closer together, as this allows you to bring the glove closer to the receivers, as they have trouble seeing the glove if it's more than 30 degrees off their face directions (or, tilt the receivers toward the center…) As for multiple gloves, you can choose one of: Slowing down the data rate of each glove (just add a couple of transistors to alternate use of the glove's transmitters) or find some good 25 or 100 KHz ultrasonic units. I haven't been able to find any, and i'd LOVE to have them for a head-angle sensor. - Dave Stampe From exv2447@ultb.isc.rit.edu Sun Oct 27 17:31:54 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA04226

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sun, 27 Oct 1991 22:26:22 -0600

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA01092; Sun, 27 Oct 91 22:31:54 -0500 Date: Sun, 27 Oct 91 22:31:54 -0500 From: exv2447@ultb.isc.rit.edu (E.X. Vanhensbergen ) Message-Id: 9110280331.AA01092@ultb.isc.rit.edu To: glove-list@karazm.math.uh.edu Subject: A Few Questions Cc: emr4510@ultb.isc.rit.edu My friends and I are working on the power glove to try to connect it to the PC based on the byte magazine. However, we've just recently begun monitoring this confrence and virtual worlds and found out about hi-res mode (which I assume is an analog interface bypassing the box). I have looked over the earlier messages of the last message archive and it seemed no-one had cracked the encryption of the data. So I pose the following questions: 1) Is hi-res mode an analog mode of the glove? 2) Does someone have plans & source for hires on the PC? 3) Does anyone have any detailed PowerGlove schematics (how it actually works)? 4) I read something about external 5V power supplies not working and if this is true what is suggested to use for a power suppy for a laptop with only a serial, parrellel, modem, and VGA port and no other easy access to other sources internal (drive power, etc.)? Thanks in advance for your help, Eric Van Hensbergen R.I.T. From ecl6gum%sun.leeds.ac.uk@VTVM2.CC.VT.EDU Mon Oct 28 13:03:24 1991 Received: from vtvm2.cc.vt.edu by karazm.math.UH.EDU with SMTP id AA05774 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 07:32:10 -0600 Received: from UKACRL.BITNET by VTVM2.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 7559; Mon, 28 Oct 91 08:26:50 EST Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 9278; Mon, 28 Oct 91 13:27:39 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 0369; Mon, 28 Oct 91 13:27:38 GMT Via: UK.AC.LEEDS.MAILER; 28 OCT 91 13:23:12 GMT Received: from sunserv1_ie0 by mailer.leeds.ac.uk; Mon, 28 Oct 91 13:05:46 gmt Received: from sun031.sun.leeds.ac.uk by sun.leeds.ac.uk; Mon, 28 Oct 91 13:03:08 GM From: ecl6gum@sun.leeds.ac.uk Date: Mon, 28 Oct 91 13:03:24 GMT Message-Id: 4227.9110281303@sun031.sun.leeds.ac.uk To: glove-list@karazm.math.uh.edu Subject: PowerGlove availablity in the UK After a number of replies to my previous query about linking the PowerGlove to a SG PI machine, most wanted to know where to get the 'Glove from in the UK. The details are listed below: item : PowerGlove price : 49.95 english pounds (inc p+p) Company: Medlantic Hi-Tec (UK) Ltd., Dept GX, Church Street, Market Bosworth, Warwickshire, CV130LG, UK. phone : (+UK) 0455-291865 (general enquiries) (+UK) 0455-292405 (credit card orders) I rang them this morning just to make sure, and they are still selling the 'Glove (their sales will no doubt greatly shoot up now !!). Delivery time is about two days with credit card orders. Can someone still *please* tell me how wire this 'Glove up to a SG PI machine? Gurm From DAVID@asgard.clare.tased.edu.au Mon Oct 28 09:04:29 1991 Received: from diemen.utas.edu.au by karazm.math.UH.EDU with SMTP id AA05954 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.EDU); Mon, 28 Oct 1991 09:04:29 -0600 Received: from ecc.tased.edu.au by diemen.utas.edu.au with SMTP id AA29851 (5.65b/IDA-1.4.3 for glove-list@karazm.math.uh.EDU); Tue, 29 Oct 91 02:00:09 +1100 Received: from slick.clare.tased.edu.au by ecc.tased.edu.au (PMDF #12099) id 01GCAUWJ11XS9GVCSW@ecc.tased.edu.au; Tue, 29 Oct 1991 01:59 +1000 Received: from charon1.clare.tased.edu.au by slick.clare.tased.edu.au (4.1/SMI-4.1) id AA03183; Tue, 29 Oct 91 03:04:23 EST Received: From ASGARD/WORKQUEUE by charon1.clare.tased.edu.au via Charon 3.4 with IPX id 100.911029015916.448; 29 Oct 91 02:00:16 -0500 Date: 29 Oct 91 01:58:43 From: david DAVID@asgard.clare.tased.edu.au Subject: ping - ignore To: glove-list@karazm.math.uh.EDU Message-Id: MAILQUEUE-99.911029015843.432@asgard.clare.tased.edu.au X-Envelope-To: glove-list@karazm.math.uh.EDU X-Mailer: Pegasus Mail v2.1b. Thankyou _ David Ford Voice : +61 02 49 6887 Claremont College Fax : +61 02 49 1984 Link Rd email : david@slick.clare.tased.edu.au Claremont TAS 7011 AUSTRALIA The Internet : "Wherever you go… There you are…" Buckaroo Banzai From wb1j+@andrew.cmu.edu Mon Oct 28 05:37:54 1991 Received: from ANDREW.CMU.EDU by karazm.math.UH.EDU with SMTP id AA06036 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 09:43:25 -0600 Received: by andrew.cmu.edu (5.54/3.15) id <AA06748> for glove-list@karazm.math.uh.edu; Mon, 28 Oct 91 10:38:58 EST Received: via switchmail; Mon, 28 Oct 1991 10:38:57 -0500 (EST) Received: from pcs12.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.wd32vVa00iUyA0bFBl>; Mon, 28 Oct 1991 10:38:10 -0500 (EST) Received: from pcs12.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr21/wb1j/.Outgoing/QF.sd32vOS00iUyQ1ql8R>; Mon, 28 Oct 1991 10:38:04 -0500 (EST) Received: from mms.0.1.871.EzMail.NeXT.2.0beta.2.CUILIB.3.45.SNAP.NOT.LINKED.pcs12.andrew.cmu.edu.pmax.ul4 via MS.5.6.pcs12.andrew.cmu.edu.pmax_ul4; Mon, 28 Oct 1991 10:37:54 -0500 (EST) Message-Id: od32vGy00iUy01qkxO@andrew.cmu.edu Date: Mon, 28 Oct 1991 10:37:54 -0500 (EST) From: "William M. Bumgarner" wb1j+@andrew.cmu.edu To: glove-list@karazm.math.uh.edu Subject: Low Priced Gloves Cc: In-Reply-To: 4227.9110281303@sun031.sun.leeds.ac.uk References: 4227.9110281303@sun031.sun.leeds.ac.uk For those living in CA (specifically, near the valley), Fry's Electronics has PowerGloves for $20. They don't do mail order, but they do supply everything else you would need to build an interface. b.bum b.bumgarner | Disclaimer: All opinions expressed are my own. wb1j+@andrew.cmu.edu | I officially don't represent anyone unless I NeXT Campus Consultant | explicity say I am doing so. So there. <Thpppt!> "I ride tandem with the random/Things don't run the way I planned them.." From ecl6gum%sun.leeds.ac.uk@VTVM2.CC.VT.EDU Mon Oct 28 16:17:55 1991 Received: from vtvm2.cc.vt.edu by karazm.math.UH.EDU with SMTP id AA06254 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 10:23:26 -0600 Received: from UKACRL.BITNET by VTVM2.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 7843; Mon, 28 Oct 91 11:18:06 EST Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 4176; Mon, 28 Oct 91 16:18:49 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 8814; Mon, 28 Oct 91 16:18:48 GMT Via: UK.AC.LEEDS.MAILER; 28 OCT 91 16:18:31 GMT Received: from sunserv1_ie0 by mailer.leeds.ac.uk; Mon, 28 Oct 91 16:20:15 gmt Received: from sun031.sun.leeds.ac.uk by sun.leeds.ac.uk; Mon, 28 Oct 91 16:17:38 GM From: ecl6gum@sun.leeds.ac.uk Date: Mon, 28 Oct 91 16:17:55 GMT Message-Id: 4532.9110281617@sun031.sun.leeds.ac.uk To: glove-list@karazm.math.uh.edu Subject: UK PowerGlove users It seems that my query of interfacing the PowerGlove onto an SG PI has been answered by reading the archives of the list. Has anyone in the UK managed to get hold of the AGE box? I don't particularily relish the thought of having to build a serial device (my background isn't in h/w), and would much rather pay Xpounds, fire the glove up and get writing some software. Does anyone know of a UK or European supplier of such a device? Gurm. e-mail: ecl6gum@uk.ac.leeds.sun University of Leeds. From timd@twaddle.dell.com Mon Oct 28 06:42:29 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA07703 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 13:42:47 -0600 Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G) id AA13837; Mon, 28 Oct 91 13:11:27 CST Received: by twaddle.dell.com. (4.1/SMI-4.1) id AA03324; Mon, 28 Oct 91 12:42:29 CST Date: Mon, 28 Oct 91 12:42:29 CST From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110281842.AA03324@twaddle.dell.com.> To: hucaby@mri.uky.edu (David Hucaby) Cc: glove-list@karazm.math.uh.edu Subject: Re: 8051s A lovely variety of 8051 development tools (most for DOS) are available on the Circuit Cellar BBS 24 hours 300/1200/2400 bps 8N1 (203)871-1988 This is a great BBS and an even better magazine for homebrew types. they also sell a variety of premade 8051 boards & plans for ICE's and emulators and such. –Tim timd@twaddle.dell.com From newton@neworder.ils.nwu.edu Mon Oct 28 07:55:36 1991 Received: from casbah.acns.nwu.edu by karazm.math.UH.EDU with SMTP id AA07862 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 14:09:29 -0600 Received: from neworder.ils.nwu.edu by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03) id AA13873; Mon, 28 Oct 91 14:05:12 CST Return-Path: newton@neworder.ils.nwu.edu Received: by neworder.ils.nwu.edu (4.0/SMI-4.0) id AA05050; Mon, 28 Oct 91 13:55:37 CST From: newton@neworder.ils.nwu.edu (Dave Newton) Message-Id: 9110281955.AA05050@neworder.ils.nwu.edu Subject: Re: 8051s To: glove-list@karazm.math.uh.edu Date: Mon, 28 Oct 91 13:55:36 CST In-Reply-To: <9110281842.AA03324@twaddle.dell.com.>; from "Tim Deagan" at Oct 28, 91 12:42 pm X-Mailer: ELM [version 2.3 PL11] SHould also probably add the Signetics BBS number to that list, as they make a swell line of 8051-type parts. 1-800-451-6644, 1200/2400-N-8-1 It's an 800 number, so go easy on it, they're nice to have it set up like that. From timd@twaddle.dell.com Mon Oct 28 10:27:40 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA09057 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 17:28:20 -0600 Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G) id AA14120; Mon, 28 Oct 91 16:57:04 CST Received: by twaddle.dell.com. (4.1/SMI-4.1) id AA03673; Mon, 28 Oct 91 16:27:40 CST Date: Mon, 28 Oct 91 16:27:40 CST From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110282227.AA03673@twaddle.dell.com.> To: glove-list@karazm.math.uh.edu Subject: COP888 sort of Netlist Here's my handmade netlist for the COP888 as used in the Nintendo PowerGlove. It's very primitive but hopefully of use to someone. COP888 - (port,type,alt. fun.1,alt. fun.2, MUX mode) pin # cop888 PowerGlove ———————————————– 1 C2,I/O, , , INPUT C on 4021 2 C3,I/O, , , INPUT D on 4021 3 G4,I/O,SO, , ? 4 G5,I/O,SK, , DATA LATCH 5 G6,I,SI, ,ME DATA CLOCK 6 G7,I/CKO,HALT RESTART, , XTAL 7 CKI, , , , XTAL 8 Vcc +5VDC 9 I0,I, , , R1 pullup,SW8(Bdn),SW0,RGHT 10 I1,I, , , R2 pullup,SW9(Boff),SW1(Aup),LEFT 11 I2,I, , , R3 pullup,SW2(Aon),ENTER,DOWN 12 I3,I, , , R4 pullup,SW3(Bup),PROG,UP 13 I4,I, , , R5 pullup,SW4(Bon),START 14 I5,I, , , R6 pullup,SW5(SloMo),SELECT 15 I6,I, , , R7 pullup,SW6(Adn),B 16 I7,I, , , R8 pullup,SW7(Aoff),A 17 L0,I/O,MIWU, , R26 gnd,THUMB 18 L1,I/O,MIWU, , R27 gnd,INDEX 19 L2,I/O,MIWU, , R28 gnd,MIDDLE 20 L3,I/O,MIWU, , R29 gnd,RING 21 C4,I/O, , , ? 22 C5,I/O, , , SW0-7 & CENTER 23 C6,I/O, , , ENTER 24 C7,I/O, , , GND 25 L4,I/O,MIWU,T2A, CLK on 4021 26 L5,I/O,MIWU,T2B, RC net to LBlu,→|- red finger wires 27 L6,I/O,MIWU, , ? 28 L7,I/O,MIWU, , GRY from top of glove (XMTR2 ?) 29 D0,O, , ,I/O BIT 0 YEL from top of glove (XMTR1) 30 D1,O, , ,I/O BIT 1 GRN from top of glove (XMTR2) 31 D2,O, , ,I/O BIT 2 BLU from top of glove (BEEPER) 32 D3,O, , ,I/O BIT 3 PUR from top of glove (XMTR1 ?) 33 D4,O, , ,I/O BIT 4 INPUT E on 4021 34 D5,O, , ,I/O BIT 5 INPUT F on 4021 35 D6,O, , ,I/O BIT 6 INPUT G on 4021 36 D7,O, , ,I/O BIT 7 INPUT H on 4021 37 GND GND 38 RESET# ? 39 G0,I/O,INT, ,ALE ? 40 G1,WDOUT, , , ? 41 G2,I/O,T1B, ,WR# BRN to junct box (pin1 LM324 near rcvrs) 42 G3,I/O,T1A, ,RD# ORG to junct box (RCs to LM324 nr rcvrs) 43 C0,I/O, , , INPUT A on 4021 44 C1,I/O, , , INPUT B on 4021 Disclaimer - NONE of this has ANYTHING to do with where I work!! My opinions and posts are MINE and MINE alone. My employer does NOT assume responsibility for what I write or say (unless I start making money off it, in which case they'll probably get interested quick :-) –Tim Tim Deagan US Snail- 2506 Lehigh Dr. timd@twaddle.dell.com Austin, TX. 78723 ~. From timd@twaddle.dell.com Mon Oct 28 11:03:41 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA09304 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 28 Oct 1991 18:03:54 -0600 Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G) id AA14183; Mon, 28 Oct 91 17:32:38 CST Received: by twaddle.dell.com. (4.1/SMI-4.1) id AA03751; Mon, 28 Oct 91 17:03:41 CST Date: Mon, 28 Oct 91 17:03:41 CST From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110282303.AA03751@twaddle.dell.com.> To: glove-list@karazm.math.uh.edu Subject: More on COP888 (w/ important note) Here's more on the COP888 NOTE!!!- The pinouts listed in my previous message are for the COP888CLMH. There is a VERY good possiblity that the powerglove is using a different varient. If someone can FOR SURE identify the varient used in the glove I'll find the GARONTEED pin outs. SORRY!! :-( 8 bit microP CMOS IDLE mode, IDLE timer to maintain real-time HALT mode w/ low standby power Memory mapped architecture 32K of Program mem and 32K of Data mem 1 ms instruction cycles MICROWIRE/PLUS ™ 3-wire serial, allows programming via serial lines Pglove uses this!! DATA CLOCK and DATA LATCH are wired to these directly. 3 or 4 timers (16 bit), microP independent PWM MIWU - Multi-Input Wake Up from halt and IDLE w/ interrupts Watchdog feature Clock monitor 2 NMIs 14 maskable interrupts XTAL or R/C osc single pin 5 8-bit I/O ports one w/high sink drive (D) Lots of groovy registers 4Kbyte ROM 128-192 Kb RAM (depends on actual model) more available on request DISCLAIMER - My employer assumes NO RESPONSIBILITY for ANYTHING I write. The info is from me as culled from the world around us. –Tim timd@twaddle.dell.com From ecl6gum%sun.leeds.ac.uk@VTVM2.CC.VT.EDU Tue Oct 29 09:49:55 1991 Received: from vtvm2.cc.vt.edu by karazm.math.UH.EDU with SMTP id AA12709 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 29 Oct 1991 03:58:54 -0600 Received: from UKACRL.BITNET by VTVM2.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 9102; Tue, 29 Oct 91 04:53:33 EST Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 7781; Tue, 29 Oct 91 09:54:30 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 2195; Tue, 29 Oct 91 09:54:07 GMT Via: UK.AC.LEEDS.MAILER; 29 OCT 91 9:50:36 GMT Received: from sunserv1_ie0 by mailer.leeds.ac.uk; Tue, 29 Oct 91 09:52:21 gmt Received: from sun031.sun.leeds.ac.uk by sun.leeds.ac.uk; Tue, 29 Oct 91 09:49:40 GM From: ecl6gum@sun.leeds.ac.uk Date: Tue, 29 Oct 91 09:49:55 GMT Message-Id: 410.9110290949@sun031.sun.leeds.ac.uk To: glove-list@karazm.math.uh.edu Subject: Are these micro-controller devices available in the UK? reply to max@alias.com: Max - thanks for the reply. I came to this conclusion after going through the archives of the power-glove list. From what I can gather, there aren't any outlets for such devices in the UK - we're only just getting shipments of the PowerGlove !!. If anyone knows of a dealer willing to ship such devices to the UK can they mail the address to the list? I'm sure there are many people in the UK waiting for them! Gurm From petersc@stallion.oz.au Tue Oct 29 19:50:36 1991 Received: from bunyip.cc.uq.oz.au by karazm.math.UH.EDU with SMTP id AA03120 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 29 Oct 1991 19:50:36 -0600 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id 17799-0@bunyip.cc.uq.oz.au; Wed, 30 Oct 1991 12:44:03 +0000 Received: from cluster.stallion.oz.au by stallion.stallion.oz.au id aa12106; Wed, 30 Oct 91 12:19:54 AEST From: Peter Calvert petersc@stallion.oz.au X-Mailer: SCO System V Mail (version 3.2) To: glove-list@karazm.math.uh.edu Subject: subscribe Date: Wed, 30 Oct 91 11:41:05 AEST Message-Id: 9110301141.aa17347@cluster.stallion.oz.au Sender: petersc@stallion.oz.au subscribe please subscribe me, thankyou From aaronp@narrator.pen.tek.com Tue Oct 29 09:56:16 1991 Received: from relay.tek.com by karazm.math.UH.EDU with SMTP id AA03279 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Tue, 29 Oct 1991 20:03:37 -0600 Received: by relay.tek.com id AA15564@relay.tek.com; Tue, 29 Oct 91 17:56:20 -0800 Received: from tekig7.map.tek.com by tektronix.TEK.COM (4.1/7.1) id AA22972; Tue, 29 Oct 91 17:56:18 PST Received: from narrator.PEN.TEK.COM (narrator.TEK) by tekig7.map.tek.com (4.1/7.1) id AA27171; Tue, 29 Oct 91 17:56:17 PST Received: from localhost.TEK by narrator.PEN.TEK.COM (4.1/7.1) id AA12468; Tue, 29 Oct 91 17:56:17 PST Message-Id: 9110300156.AA12468@narrator.PEN.TEK.COM To: glove-list@karazm.math.uh.edu Subject: Results of STRAW-POLL Date: Tue, 29 Oct 91 17:56:16 -0800 From: aaronp@narrator.pen.tek.com The following represents the results of the straw-poll which I conducted last week. The purpose of the straw-poll was to determine the 'best' name to use as a newsgroup to move the discussions which are now taking place on the glove-list. A total of 71 votes were received. If anyone voted for two names I did the following: if one of the names was an 'Other' or the two names seemed to have equal weight I gave them both a half vote, whereas if one was clearly marked a first choice I gave that a full vote and ignored the other name. Sorry if this bothers anyone, but I did clearly state 'choose one' and I had to do something. The results are as follows: 35.5 sci.virtual-worlds.tech 17.5 sci.virtual-worlds.homebrew 10.0 comp.periphs.virtual 3.5 comp.periphs.glove 2.0 sci.virtual-worlds.low-end 1.0 comp.invisible.touch 0.5 sci.virtual-worlds.glove 0.5 comp.periphs.vr 0.5 comp.virtual-worlds.interface 0.0 alt.glove 27.0 Moderated 25.0 Un-moderated 19.0 Don't care about moderation Several people suggested that people simply begin posting to sci.virtual-worlds and not create a new newsgroup… Several others suggested not moving the mailing-list because they don't have access to the Usenet newsgroups… Conclusion: sci.virtual-worlds.tech is the obvious leader, whether or not to moderate it is still unclear. All comments and suggestions are welcome; I will probably post a RFD (Request for Discussion) in about a week. +————–\ | Aaron Pulkka > aaronp@narrator.PEN.TEK.COM +————–/ From DAVID@asgard.clare.tased.edu.au Tue Oct 29 22:25:36 1991 Received: from diemen.utas.edu.au by karazm.math.UH.EDU with SMTP id AA04221 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.EDU); Tue, 29 Oct 1991 22:25:36 -0600 Received: from ecc.tased.edu.au by diemen.utas.edu.au with SMTP id AA03473 (5.65b/IDA-1.4.3 for glove-list@karazm.math.uh.EDU); Wed, 30 Oct 91 15:21:06 +1100 Received: from slick.clare.tased.edu.au by ecc.tased.edu.au (PMDF #12099) id 01GCD15ZJEG09GVG4C@ecc.tased.edu.au; Wed, 30 Oct 1991 15:21 +1000 Received: from charon1.clare.tased.edu.au by slick.clare.tased.edu.au (4.1/SMI-4.1) id AA03481; Wed, 30 Oct 91 16:26:46 EST Received: From ASGARD/WORKQUEUE by charon1.clare.tased.edu.au via Charon 3.4 with IPX id 100.911030152158.336; 30 Oct 91 15:22:11 +1100 Date: 30 Oct 91 14:12:45 From: david DAVID@asgard.clare.tased.edu.au Subject: IBM hires code To: glove-list@karazm.math.uh.EDU Message-Id: MAILQUEUE-99.911030141245.480@asgard.clare.tased.edu.au X-Envelope-To: glove-list@karazm.math.uh.EDU X-Mailer: Pegasus Mail v2.1b. Has anyone done a machine code version of the IBM hires code (including special timing tricks ?) If they have, I'd appreciate a copy of the code - I still (even with better timing tricks) have not had the HIRES code going on an AT in TC. Thankyou _ David Ford Voice : +61 02 49 6887 Claremont College Fax : +61 02 49 1984 Link Rd email : david@slick.clare.tased.edu.au Claremont TAS 7011 AUSTRALIA The Internet : "Wherever you go… There you are…" Buckaroo Banzai From broehl@sunee.waterloo.edu Wed Oct 30 02:11:44 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA05749 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 06:16:02 -0600 Received: by sunee.waterloo.edu id <AA10597>; Wed, 30 Oct 91 07:11:45 -0500 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110301211.AA10597@sunee.waterloo.edu Subject: Results of STRAW-POLL (fwd) To: glove-list@karazm.math.uh.edu Date: Wed, 30 Oct 91 7:11:44 EST X-Mailer: ELM [version 2.3 PL11] > Several people suggested that people simply begin posting to > sci.virtual-worlds and not create a new newsgroup… > > Several others suggested not moving the mailing-list because > they don't have access to the Usenet newsgroups… I would suggest that any newsgroup we set up be bi-directionally gatewayed to the existing glove-list, so that people in the mailing-list-only situation can still participate fully in the discussion. (No, I'm not in that situation myself… I just would hate to lose any of the contributors to the list). Software exists to do the gatewaying. > whether or not to moderate it is still unclear. Bear in mind that (a) moderation means tedious work for someone, and (b) it makes the list sluggish. – Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] From jet Wed Oct 30 04:49:22 1991 Received: by karazm.math.UH.EDU id AA06524 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 10:49:22 -0600 From: J Eric Townsend <jet> Message-Id: 199110301649.AA06524@karazm.math.UH.EDU Subject: Re: Results of STRAW-POLL (fwd) To: broehl@sunee.waterloo.edu (Bernie Roehl) Date: Wed, 30 Oct 91 10:49:22 CST Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110301211.AA10597@sunee.waterloo.edu; from "Bernie Roehl" at Oct 30, 91 7:11 am X-Mailer: ELM [version 2.3 PL11] >Software exists to do the gatewaying. Oh really? Where can I get a copy? » whether or not to moderate it is still unclear. >Bear in mind that (a) moderation means tedious work for someone, and >(b) it makes the list sluggish. However, it filters out the non-glove stuff that has caused at least 6-8 people to drop off the list. If somebody could point me to moderation software, I'd be very happy to moderate this list and/or a newsgroup. However, I still think that comp.periphs.glove is the logical place for the group. It's a peripheral, and there's a peripheral heirarchy. Let the discussion of the ethics of teledildonics and presidential campaigns stay in sci.v-w. If not that, how about: comp.virtual.glove comp.virtual.goggles comp.virtual.mouse (for flying meeces) comp.virtual.rendering etc etc etc – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 AMA# I-forget PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From jdb9608@cs.rit.edu Wed Oct 30 07:32:26 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA06943 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 11:36:28 -0600 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA26196; Wed, 30 Oct 91 12:32:03 -0500 Received: from doha.CS (doha.ARPA) by junior.rit.edu (4.1/5.17) id AA24743; Wed, 30 Oct 91 12:20:02 EST From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110301720.AA24743@junior.rit.edu Subject: Re: Results of STRAW-POLL To: broehl@sunee.waterloo.edu (Bernie Roehl) Date: Wed, 30 Oct 91 12:32:26 EST Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110301211.AA10597@sunee.waterloo.edu; from "Bernie Roehl" at Oct 30, 91 7:11 am X-Mailer: ELM [version 2.3 PL8] > I would suggest that any newsgroup we set up be bi-directionally gatewayed > to the existing glove-list, so that people in the mailing-list-only > situation can still participate fully in the discussion. (No, I'm not > in that situation myself… I just would hate to lose any of the contributors > to the list). True. However, the newsgroup we make should be for more than just the glove. I'm really interested in implementing graphic techniques (altho not VGA), eyephones, MUDs, VR operating systems, etc… Eric has mentioned that he doesn't really want all that stuff on the glove-list, so maybe someone should make another mailing list for the other-than-glove stuff? > Software exists to do the gatewaying. Does anyone know where this software is? > > whether or not to moderate it is still unclear. > > Bear in mind that (a) moderation means tedious work for someone, and > (b) it makes the list sluggish. I agree. Plus, I don't like to lose the feeling of autonomy. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From jdb9608@cs.rit.edu Wed Oct 30 08:02:25 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA07370 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 12:06:20 -0600 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA28090; Wed, 30 Oct 91 13:02:03 -0500 Received: from doha.CS (doha.ARPA) by junior.rit.edu (4.1/5.17) id AA24868; Wed, 30 Oct 91 12:50:02 EST From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9110301750.AA24868@junior.rit.edu Subject: scope of newsgroup To: glove-list@karazm.math.uh.edu Date: Wed, 30 Oct 91 13:02:25 EST X-Mailer: ELM [version 2.3 PL8] Should the various VR discussions stay together in one newsgroup or mailing list? Or, should they be separated? Separating them has the advantage of letting the readers easily avoid subjects that aren't of interest. Less readers quit because there's too much stuff they don't care about. But, keeping them together has the advantage of keeping the critical mass of ideas flowing when some topics aren't hot. And, the cross-fertilization of ideas, and the consideration of ideas from many viewpoints, makes them stronger. I'd prefer to keep it all together unless the traffic continues or grows from what it is now. Then, we could split into specifics. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From madsax@u.washington.edu Wed Oct 30 02:05:36 1991 Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA07388 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 12:09:51 -0600 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA28398; Wed, 30 Oct 91 10:05:36 -0800 Date: Wed, 30 Oct 91 10:05:36 -0800 From: Mark A. DeLoura madsax@u.washington.edu Message-Id: 9110301805.AA28398@milton.u.washington.edu Sender: madsax@milton.u.washington.edu To: glove-list@karazm.math.uh.edu Subject: Re: Results of STRAW-POLL (fwd) J Eric Townsend JET@UH.EDU said: > > If somebody could point me to moderation software, I'd be very happy to > moderate this list and/or a newsgroup. > I've got moderation software. Anyone wants it, let me know– it will do archival, a mailing-list and posting to a newsgroup. All you have to do is say "postit <filename>". It's juuuuuuust that easy! :) —Mark =============================================================================== Mark A. DeLoura madsax@milton.u.washington.edu University of Washington sci.virtual-worlds co-moderator/librarian From wombat@key.amdahl.com Wed Oct 30 02:10:47 1991 Received: from CHARON.AMDAHL.COM by karazm.math.UH.EDU with SMTP id AA07423 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 12:15:26 -0600 Received: from kilimanjaro.key.amdahl.com by charon.amdahl.com (4.0/SMI-4.1/DNS) id AA21816; Wed, 30 Oct 91 10:10:15 PST Received: by kilimanjaro.key.amdahl.com (4.0/SMI-4.1/DNS) id AA19519; Wed, 30 Oct 91 10:10:48 PST Message-Id: 9110301810.AA19519@kilimanjaro.key.amdahl.com To: glove-list@karazm.math.uh.edu Reply-To: glove-list Subject: Re: Results of STRAW-POLL In-Reply-To: Your message of Wed, 30 Oct 91 12:32:26 EST. 9110301720.AA24743@junior.rit.edu Date: Wed, 30 Oct 91 10:10:47 PST From: Joan Eslinger wombat@key.amdahl.com Since there are some folks interested in just the glove traffic, if we go with a broader-based newsgroup like "comp.virtual.tech" we could adopt a convention of putting a keyword in the title so everyone can use auto-kill / auto-select features in their news readers to see just the stuff they're interested in; Subject: (GLOVE) Amiga hi-res code available Subject: (GLASSES) Source for SEGA and X-Specs in Australia Subject: (3D-GRAPHICS) (GLOVE) 3-d drawing application using glove and so on. Could be tough to enforce without a moderator, but it might work. From jet Wed Oct 30 06:35:44 1991 Received: by karazm.math.UH.EDU id AA07575 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 12:35:45 -0600 From: J Eric Townsend <jet> Message-Id: 199110301835.AA07575@karazm.math.UH.EDU Subject: Re: Results of STRAW-POLL To: jdb9608@cs.rit.edu (John D Beutel) Date: Wed, 30 Oct 91 12:35:44 CST Cc: broehl@sunee.waterloo.edu, glove-list@karazm.math.uh.edu In-Reply-To: 9110301720.AA24743@junior.rit.edu; from "John D Beutel" at Oct 30, 91 12:32 pm X-Mailer: ELM [version 2.3 PL11] you wrote: >True. However, the newsgroup we make should be for more than >just the glove. I'm really interested in implementing graphic techniques Then why not have a newsgroup for what you're discussing *and* a series of technical newsgroups for the devices themselves. Again, comp.virtual.homebrew comp.virtual.talk comp.virtual.glove comp.virtual.goggles .. etc etc etc .. >(altho not VGA), Nyuk >Eric has mentioned that he doesn't really want all that stuff >on the glove-list, so maybe someone should make another >mailing list for the other-than-glove stuff? Subdividing into specific topics makes things much easier for the non-engrossed-in-the-subject. Look at comp.sys.amiga.*. Total posting is *up*, and there's a lot of discussion about specific ideas as opposed to everybody fighting in one newsgroup. (And it gets the "This is a stupid idea" people out of the technical groups, usually.) – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 AMA# I-forget PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From wombat@key.amdahl.com Wed Oct 30 04:18:39 1991 Received: from CHARON.AMDAHL.COM by karazm.math.UH.EDU with SMTP id AA08447 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 14:23:17 -0600 Received: from kilimanjaro.key.amdahl.com by charon.amdahl.com (4.0/SMI-4.1/DNS) id AA24774; Wed, 30 Oct 91 12:18:08 PST Received: by kilimanjaro.key.amdahl.com (4.0/SMI-4.1/DNS) id AA19596; Wed, 30 Oct 91 12:18:40 PST Message-Id: 9110302018.AA19596@kilimanjaro.key.amdahl.com To: glove-list@karazm.math.uh.edu Subject: amiga hi-res on ab20 Date: Wed, 30 Oct 91 12:18:39 PST From: Joan Eslinger wombat@key.amdahl.com I was having trouble ftp'ing the hi-res amiga code from karazm.math.uh.edu, so I requested it via e-mail. For others in the same boat, I placed a copy on ab20.larc.nasa.gov in the incoming/amiga directory as "pglovehires.lzh". From timd@twaddle.dell.com Wed Oct 30 08:16:22 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA08810 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 15:16:30 -0600 Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G) id AA16780; Wed, 30 Oct 91 14:45:21 CST Received: by twaddle.dell.com. (4.1/SMI-4.1) id AA07691; Wed, 30 Oct 91 14:16:22 CST Date: Wed, 30 Oct 91 14:16:22 CST From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110302016.AA07691@twaddle.dell.com.> To: glove-list@karazm.math.uh.edu Subject: Re: Results of STRAW-POLL The only thing I'm not interested in is high-dollar gear I'll never get to use. I'd like to find out about any VR homebrew activities involving PCs and low-cost (under $200) gear. (PCs can include Amiga's, Macs, etc. but I like DOS boxes cuz their cheap and very functional. I also like microC's.) The big expensive stuff is lovely to read about in sci.v-w, but the revolution will be feuled from below… Okay, there's $.02 worth. Basically I'd hate to miss a goodie about goggles or Nintendo twister boards cause I missed subscribing but frankly I'm grateful this exists at all and I don't mind a little responsibility for meeting my own needs. ($.02 more for free!) done now –Tim timd@twaddle.dell.com From yonder@netcom.netcom.com Wed Oct 30 06:45:50 1991 Received: from netcomsv.netcom.com by karazm.math.UH.EDU with SMTP id AA11203 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 17:44:14 -0600 Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA28965; Wed, 30 Oct 91 15:38:56 PST Received: by netcom.netcom.com (4.1/SMI-4.1) id AA23182; Wed, 30 Oct 91 14:45:52 PST From: yonder@netcom.netcom.com (Christopher Russell) Message-Id: 9110302245.AA23182@netcom.netcom.com Subject: 68hc11 EVB vs. EVBU… To: glove-list@karazm.math.uh.edu (Power Glove mailing list) Date: Wed, 30 Oct 91 14:45:50 PST X-Mailer: ELM [version 2.3 PL11] I want to order myself one of the 6811 evaluation boards. My problem is that now there are two to choose from the EVB and the EVBU. I'm wondering if all of the tools developed for the EVB (PD assemblers, compilers, etc.) will work for the EVBU. Also from what I've gathered so far the new EVBU has pluses and minuses. For example, how much modification would the code that was posted to control the glove need before it could be used with the new board… It seems like the new board has more up-to-date components, but less of them: for example less external RAM and only one serial port. Well, any info would be appreciated… – Christopher L. Russell (yonderboy) Phone: (408)378-9078 Campbell,CA yonder@netcom.COM or clr40@amail.amdahl.com or chrisr@leland.stanford.edu From rick%hci.heriot-watt.ac.uk@cs.heriot-watt.ac.uk Wed Oct 30 17:03:12 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA11700 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 18:33:15 -0600 Received: from cs.heriot-watt.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id 15135-0@sun2.nsfnet-relay.ac.uk; Wed, 30 Oct 1991 17:51:21 +0000 Received: from glenlivet.hci.hw.ac.uk by helios.cs.hw.ac.uk; Wed, 30 Oct 91 16:52:50 GMT Received: from mortlach.hci.hw.ac.uk by glenlivet.hci.hw.ac.uk; Wed, 30 Oct 91 16:45:34 GMT Date: Wed, 30 Oct 91 17:03:12 GMT Message-Id: 975.9110301703@mortlach.hci.hw.ac.uk From: Rick Innis rick@hci.heriot-watt.ac.uk Subject: UK users To: glove-list@karazm.math.uh.edu X-Organisation: Big Yellow Bulldozer X-Mailer: ream v4.15a - more a mail program than a way of life Out of curiousity, how many of us are there and what are we hoping to achieve? I'm hoping to use mine in my MSc thesis, probably part of some work on either visualisation or animation - not fully decided yet, and it depends on what facilities I can get access to as well. What of the rest of you? –Rick. From taihou@iss.nus.sg Wed Oct 30 19:08:37 1991 Received: from nuscc.nus.sg by karazm.math.UH.EDU with SMTP id AA11775 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 19:08:37 -0600 Received: from bochap.iss.nus.sg by nuscc.nus.sg (5.65/1.34) id AA29512; Thu, 31 Oct 91 09:04:16 +0800 Received: from suliman.iss.nus.sg by bochap.iss.nus.sg (4.1/SMI-4.1) id AA06596; Thu, 31 Oct 91 09:04:32 SST Date: Thu, 31 Oct 91 09:04:32 SST From: taihou@iss.nus.sg (Tng Tai Hou) Message-Id: 9110310104.AA06596@bochap.iss.nus.sg To: glove-list@karazm.math.uh.edu Subject: PowerGlove and Mac Hello folks. I am new to this list. I have just received my Mattel PowerGlove. Now I intend to connect and use it with my Mac IIfx. Can someone please guide me? I have heard about the Age box and the GoldBrick hardware. I am using ThinkC 5.0 and would like to use the Glove in hires-mode. If there are public domain circuits, all the more better for me. Thanks in advance for your help. Tai Hou Singapore (please note this location). From taihou@iss.nus.sg Wed Oct 30 19:11:11 1991 Received: from nuscc.nus.sg by karazm.math.UH.EDU with SMTP id AA11788 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 19:11:11 -0600 Received: from bochap.iss.nus.sg by nuscc.nus.sg (5.65/1.34) id AA00727; Thu, 31 Oct 91 09:06:52 +0800 Received: from suliman.iss.nus.sg by bochap.iss.nus.sg (4.1/SMI-4.1) id AA06599; Thu, 31 Oct 91 09:07:08 SST Date: Thu, 31 Oct 91 09:07:08 SST From: taihou@iss.nus.sg (Tng Tai Hou) Message-Id: 9110310107.AA06599@bochap.iss.nus.sg To: glove-list@karazm.math.uh.edu Subject: ftp at karazm I can't seem to ftp to karazm. Is there some special tricks I need to know? From motcsd!roi!lance@apple.com Sun Oct 30 08:29:47 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA12793 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 21:30:16 -0600 Received: by apple.com (5.61/18-Oct-1991-eef) id AA17811; Wed, 30 Oct 91 19:13:16 -0800 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id m0kcQK9-0001HbC@motcsd.csd.mot.com; Wed, 30 Oct 91 16:31 PST Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA07942; 30 Oct 91 16:29:48 PST (Wed) To: glove-list@karazm.math.uh.edu Subject: Frequently Asked Questions Message-Id: 9110301629.AA07938@roi.ca41.csd.mot.com Date: 30 Oct 91 16:29:47 PST (Wed) From: Lance Norskog lance@roi.ca41.csd.mot.com Hello- I'm compiling an FAQ posting. I've got most of the pertinent stuff (and wrote some of it). How do you order the 6811 evaluation stuff, and where is the free assembler available? Lance Norskog From dstamp@watserv1.uwaterloo.ca Wed Oct 30 19:11:25 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA13239 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 23:15:59 -0600 Received: by watserv1.uwaterloo.ca id <AA19267>; Thu, 31 Oct 91 00:11:25 -0500 Date: Thu, 31 Oct 91 00:11:25 -0500 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110310511.AA19267@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu I've had quite a few requests to look at the fast VGA poly blitter code. I'ts not done by any means, but this is what I have so far. You'll notice that poly timing is done by subtracting a dummy call time from that of the poly drawing call: this gives a better estimate of the poly code speed without the C call, procedure and test parameter generation time. Obviously a general poly blitter with clipping will run a bit slower because of added interface code, but right now fine timing is critical, as this part of the blitter is called many times. Timing as of now (on my Paradise VGA card (pretty slow one) and a 486/25 is 6400 24x24 triangles or 4800 24x24 trapezoids per second. Thus, trapezoids are about 50% faster per pixel than the triangles. THe code is compiled with Borland C++ or Turbo C++ (others may need rewrites). Note the inline assembler: this will be moved to a seperate .asm file in the future, but this style seems to work well for development. Please contact me if you have any questions. More later. ——————— fpoly.c ————————– #pragma inline #include <bios.h> #include <dos.h> #include <stdio.h> #include <conio.h> #include <graphics.h> union REGS regs; #define PUT 0 /* defines of write modes */ #define AND 1 #define OR 2 #define XOR 3 int gdriver = VGA; int gmode = VGAHI; #define VGA 0x3CE /* VGA controller port address */ int vmode = 0x0d; /* 320x200x16 colors */ unsigned char stmask[320]; /* start, end mask fast lookup arrays */ unsigned char fnmask[320]; unsigned char smask[] = { 0xFF, 0x7F, 0x3F, 0x1F, 0x0F, 0x07, 0x03, 0x01 }; unsigned char emask[] = { 0x80, 0xC0, 0xE0, 0xF0, 0xF8, 0xFC, 0xFE, 0xFF }; make_data() /* fill mask arrays */ { /* wd. be code segment tables in assembler */ int i,j; for(i=0;i<320;i++) { stmask[i] = smask[i&7]; fnmask[i] = emask[i&7]; } } main() { long btime; float mtime; int i,j,k; initgraph(&gdriver,&gmode,""); regs.h.ah = 0; /* set video mode */ regs.h.al = vmode; /* as driver doesn't sppt 320x200 */ int86(0x10,&regs,&regs); make_data(); /* create dummy asm tables */ btime = biostime(0,0L); /* dummy timer to find interface time */ for(i=0;i<290;i++) for(k=0;k<170;k++) dpoly(i+20, i+20, i, i+24, k, 24+k, (i+k)%16); mtime = (float)(biostime(0,0L)-btime)/18.2; setup_hdwe(PUT); /* setup VGA hardware */ btime = biostime(0,0L); /* draw 49300 24x24 triangles */ for(i=0;i<290;i++) /* of 288 pixels ea. */ for(k=0;k<170;k++) trpoly(i+20, i+20, i, i+24, k, 24+k, (i+k)%16); reset_hdwe(); /* reset VGA hardware */ printf("Triangle blits: %f\n", (float)(biostime(0,0L)-btime)/18.2-mtime); setup_hdwe(PUT); btime = biostime(0,0L); /* draw 49300 24x24 trapezoids */ for(i=0;i<290;i++) /* of 576 pixels each */ for(k=0;k<170;k++) trpoly(i+7, i+30, i, i+25, k, 24+k, (i+k)%16); reset_hdwe(); printf("Trapezoidal blits: %f\n", (float)(biostime(0,0L)-btime)/18.2-mtime); getch(); textmode(-1); } setup_hdwe(int mode) /* set VGA to draw in desired mode */ { /* do ONCE for all polys */ asm { mov dx,VGA mov ah,BYTE PTR mode sal ah,1 sal ah,1 sal ah,1 mov al,03h /* set mode */ out dx,ax /* assumed PUT by BIOS */ mov ax,0B05h /* write mode 3, read mode 1 */ out dx,ax mov ax,0007h /* 0 to CDC for 0xFF read */ out dx,ax mov ax,0FF08h /* bit mask = all */ out dx,ax /* assumed 0xFF by BIOS */ mov ax,0FF01h /* ESR = 0x0F */ out dx,ax } } reset_hdwe() /* reset VGA to expected state after drawing */ { asm { mov dx,VGA mov ax,0000 out dx,ax mov ax,0001 out dx,ax mov ax,0003 out dx,ax mov ax,0005 out dx,ax } } /* 1 2 */ /* draw trapezoid: horizontal top, bottom */ /* */ /* do it as simply as possible: stack these to get */ /* 3 4 */ /* any 2 or 3-sided poly: quad is 50% faster per */ /* pixel for 24x24 than triangles */ /* just make 2 points the same for triangle draw. */ trpoly(int x1,int x2, int x3, int x4, int y1, int y3, int color) { unsigned int vline = y1*40; /* video line: offset in buffer */ long l_incr, r_incr; /* side slopes (16-bit underflow */ int lines = y3-y1; /* line counter */ if(lines<1)return; asm { .386 mov dx,VGA xor al,al mov ah,BYTE PTR color /* set color */ out dx,ax cld mov ax,0a000h /* set segment */ mov es,ax } asm { xor ecx,ecx /* compute left incrementer */ mov ax,x3 sub ax,x1 cwd movsx eax,ax movsx edx,dx /* (x3-x1)/(y3-y1) */ shl eax,16 mov cx,lines idiv ecx cmp eax,0 /* round up if + ( - already done) */ jle rnd1 inc eax } rnd1: asm { mov l_incr,eax mov ax,x4 /* compute right incrementer */ sub ax,x2 cwd movsx eax,ax /* (x4-x2)/(y4-y2) */ movsx edx,dx shl eax,16 mov cx,lines idiv ecx cmp eax,0 /* round up */ jle rnd2 inc eax } rnd2: asm { mov r_incr,eax mov dx,x1 /* set start of left/right */ mov si,x2 shl edx,16 /* add zero frac. part */ shl esi,16 add edx,08000h /* add 0.5 to left, so it rounds up */ mov bx,x1 /* faster to load reg's than to shift */ mov cx,x2 } nextline: /* bx=left side, cx=right side, vline=line start */ asm { mov al,[bx+stmask] /* compute left side */ shr bx,3 mov di,cx /* compute right side */ mov ah,[di+fnmask] /* lookup 350 nS faster than shift */ shr cx,3 mov di,vline add di,bx /* compute start byte */ sub cx,bx /* number of bytes - 1 */ jz onebyte jc doneline /* skip if L>R */ and es:[di],al /* mask start byte */ inc di dec cx /* cx==0 test not worth it: */ mov al,0ffh /* faster to let REP handle 0's */ rep stosb /* fill center bytes */ and es:[di],ah /* mask end byte */ } goto doneline; onebyte: asm { and al,ah /* only 1 byte to mask */ and es:[di],al /* combine start, end mask */ } doneline: asm { dec WORD PTR lines jz donetri mov ax,40 add vline,ax add edx,l_incr /* add in slope */ add esi,r_incr mov ebx,edx /* throw away fraction: lt rounded up */ sar ebx,16 mov ecx,esi sar ecx,16 cmp cx,0 /* clip to 0 on left: */ jge nextline /* code auto-clip rt to 0 */ xor cx,cx jmp nextline } donetri: ; } dpoly(int x1,int x2, int x3, int x4, int y1, int y3, int color) { unsigned int vline = y1*40; long l_incr, r_incr; int lines = y3-y1; if(lines<1)return; asm { .386 mov dx,VGA xor al,al mov ah,BYTE PTR color /* set color */ out dx,ax cld mov ax,0a000h /* set segment */ mov es,ax } } ———————- ends ———————– ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From jet Wed Oct 30 17:37:05 1991 Received: by karazm.math.UH.EDU id AA13313 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 30 Oct 1991 23:37:05 -0600 From: J Eric Townsend <jet> Message-Id: 199110310537.AA13313@karazm.math.UH.EDU Subject: Re: UK users To: rick@hci.heriot-watt.ac.uk (Rick Innis) Date: Wed, 30 Oct 91 23:37:05 CST Cc: glove-list@karazm.math.uh.edu In-Reply-To: 975.9110301703@mortlach.hci.hw.ac.uk; from "Rick Innis" at Oct 30, 91 5:03 pm X-Mailer: ELM [version 2.3 PL11] you wrote: >Out of curiousity, how many of us are there and what are we hoping to $ wc -l vr/glove-list/list 302 vr/glove-list/list – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 AMA# I-forget PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From DAVID@asgard.clare.tased.edu.au Thu Oct 31 01:24:47 1991 Received: from diemen.utas.edu.au by karazm.math.UH.EDU with SMTP id AA14178 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.EDU); Thu, 31 Oct 1991 01:24:47 -0600 Received: from ecc.tased.edu.au by diemen.utas.edu.au with SMTP id AA27317 (5.65b/IDA-1.4.3 for glove-list@karazm.math.uh.EDU); Thu, 31 Oct 91 18:20:20 +1100 Received: from slick.clare.tased.edu.au by ecc.tased.edu.au (PMDF #12099) id 01GCELPKXB5S9GVL0Q@ecc.tased.edu.au; Thu, 31 Oct 1991 18:20 +1000 Received: from charon1.clare.tased.edu.au by slick.clare.tased.edu.au (4.1/SMI-4.1) id AA03866; Thu, 31 Oct 91 19:26:01 EST Received: From ASGARD/WORKQUEUE by charon1.clare.tased.edu.au via Charon 3.4 with IPX id 100.911031182115.416; 31 Oct 91 18:21:28 +1100 Date: 31 Oct 91 18:20:44 From: david DAVID@asgard.clare.tased.edu.au Subject: IBM Hires code To: glove-list@karazm.math.uh.EDU Message-Id: MAILQUEUE-99.911031182041.400@asgard.clare.tased.edu.au X-Envelope-To: glove-list@karazm.math.uh.EDU X-Mailer: Pegasus Mail v2.1b. Greetings from sunny Tassie ! I've produced yavotpgc - Yet Another Version Of The Power Glove Code, and I'll be posting it in the next few days. Advantages : o No assembler has own hi resolution timing in C only. o Autocalibrating timing [works on XT and AT so far - 486 code is already available] o works on slow machines XT (even 4.77Mhz) and AT (16 M) Also - the hardest part is to get the glove into hires mode - actually reading the glove is no real strain - So just use either a TSR which you slap with an INT to fire up hires mode, then use your favourite language from there, or - as I do, execute a hires exe at the beginning of the entire session. PS Does anybody have any autocalibrating "read byte" code in turbo pas 6.0 ? This is for a student "toy", and they only know turbo pas - but I can exchange you for a drawing program one of then did which uses the glove, but which has hardcoded timing built into the glove unit. Thankyou _ David Ford Voice : +61 02 49 6887 Claremont College Fax : +61 02 49 1984 Link Rd email : david@slick.clare.tased.edu.au Claremont TAS 7011 AUSTRALIA The Internet : "Wherever you go… There you are…" Buckaroo Banzai From dbarberi@sugrfx.acs.syr.edu Wed Oct 30 23:41:06 1991 Received: from sugrfx.acs.syr.EDU by karazm.math.UH.EDU with SMTP id AA15000 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 31 Oct 1991 03:44:15 -0600 Date: Thu, 31 Oct 91 04:41:06 EST From: dbarberi@sugrfx.acs.syr.edu (..Iris Freak..) Received: by sugrfx.acs.syr.edu (4.1/2.1-Advanced Graphics Research Lab. - Syracuse University) id AA12376; Thu, 31 Oct 91 04:41:06 EST Message-Id: 9110310941.AA12376@sugrfx.acs.syr.edu To: glove-list@karazm.math.uh.edu Hey ! Is it just me or has this list been REALLY quiet? Anyways.. anyone out there ever chop off all the plastic from the Powerglove and make a small kid size glove? You'd be amazed at just how much extra material is used to make the PowerGlove ! –=——————————————–. _ _ _ David Barberi |
||—
————- |

 \\      //    ||    ||               dbarberi@sugrfx.acs.syr.edu         |
  \\    //     ||___//                                                    |
   \\  //      ||---\\          Syracuse University Virtual Reality Lab   |
    \\//       ||    \\                 Syracuse, New York, USA           |
     \/        ||     \\            "Bringing cyberspace to the masses"   |
                           --=--------------------------------------------'

From motcid!zeus!smithju@uunet.UU.NET Thu Oct 31 09:16:22 1991 Received: from relay1.UU.NET by karazm.math.UH.EDU with SMTP id AA15080

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 31 Oct 1991 04:47:41 -0600

Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP

(5.61/UUNET-internet-primary) id AA29064; Thu, 31 Oct 91 05:43:24 -0500

Received: from motcid.UUCP by uunet.uu.net with UUCP/RMAIL

(queueing-rmail) id 054245.22218; Thu, 31 Oct 1991 05:42:45 EST

Received: from zeus.swindon.rtsg.mot.com (hera) by rtsg.mot.com (4.0/SMI-4.1)

id AA11827; Thu, 31 Oct 91 03:14:40 CST

Received: from mamba. by zeus.swindon.rtsg.mot.com (4.0/SMI-4.0)

id AA19760; Thu, 31 Oct 91 09:16:22 GMT

Date: Thu, 31 Oct 91 09:16:22 GMT From: motcid!zeus.swindon.SUBDOMAIN!smithju%zeus@uunet.UU.NET (Justin Smith) Message-Id: 9110310916.AA19760@zeus.swindon.rtsg.mot.com To: glove-list@karazm.math.uh.edu Subject: FAQ Hi,

I have some info on PD 6811 tools, and here it is.....

at SIMTEL20: Directory PD1:<MSDOS.CROSSASM> MOTOASMS.ZIP B 92103 900314 Motorola 6800/01/04/05/09/11 cross assemblers ASREF.ZIP B 22588 900314 Reference manual for MOTOASMS cross assembers also theres the moto BBS in Texas, the number is 512 891 3733. the BBS has the above files, bug fixes, a PD kernel, a 6811 simulator for the PC and a C compiler. I have most of these files from when i used to run a BBS, if theres enough interest i could post them to the list or mail to individuals, or perhaps we could put them on the archive site (although i dont have FTP) I'll dig out what i`ve got……. as far as EVBs go I dont know anything about them, although i'm trying to find out where I can get one from. Justin Smith From nfotis@theseas.ntua.gr Thu Oct 31 06:05:57 1991 Received: from ariadne.csi.forth.gr by karazm.math.UH.EDU with SMTP id AA15249

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 31 Oct 1991 06:05:57 -0600

Received: from theseas.ntua.gr by ariadne.csi.forth.gr via ITEnet with SMTP;

id AA07893 (5.61++/FORTH-CSI-2.21); Thu, 31 Oct 91 13:58:09 +0200

Received: by theseas.ntua.gr; Thu, 31 Oct 91 13:58:21 +0200 Received: by phgasos.ntua.gr ; Thu, 31 Oct 91 14:00:44 +0200 From: Nick (Nikolaos) C. Fotis nfotis@theseas.ntua.gr Message-Id: 9110311200.AA12837@phgasos.ntua.gr Subject: Re: Results of STRAW-POLL To: glove-list@karazm.math.uh.edu (Power Glove Mailing List) Date: Thu, 31 Oct 91 14:00:43 EET X-Mailer: ELM [version 2.3 PL11]

From: J Eric Townsend JET@uh.edu
Subject: Re: Results of STRAW-POLL (fwd)

However, I still think that comp.periphs.glove is the logical place for
the group. It's a peripheral, and there's a peripheral heirarchy. Let
the discussion of the ethics of teledildonics and presidential campaigns
stay in sci.v-w.

If not that, how about:
comp.virtual.glove
comp.virtual.goggles
comp.virtual.mouse (for flying meeces)
comp.virtual.rendering
etc etc etc

Personally, I would prefer the creation of a comp.periphs.glove group, because: The comp. hierarchy is much more widely distributed in the Internet/EUnet, and I want a distribution scheme that arrives at all places without trouble. If we want a more general newsgroup?? I think that the volume of glove-list is enough to maintain a comp.periphs.glove group, and cluttering with irrespective material will be rather harmful. Moderation?? I don't care too much, since I can select what to read with the newsreader I use. I agree that moderation is useful, though. (I'm on Eunet's borderline, and only the comp. hierarchy arrives here unschatched.) The gyus that aren't on the Internet/uucp and cannot get news are going to be hurt badly. Do we want such a thing??? alt. hierarchy?? Forget it. We don't get alt.sex.*, so we shall not get glove-related material either ;-) ;-) ;-) Greetings, and have a nice day, Nick. (WOW!! My first posting in the glove-list!! ;-) ) – Nikolaos Fotis National Technical Univ. of Athens, Greece 16 Esperidon St., UUCP: mcsun!ariadne!theseas!nfotis Halandri, GR - 152 32 or InterNet : nfotis@theseas.ntua.gr Athens, GREECE FAX: (+30 1) 77 84 578 From broehl@sunee.waterloo.edu Thu Oct 31 05:52:36 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA15810

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 31 Oct 1991 09:57:06 -0600

Received: by sunee.waterloo.edu

id <AA12211>; Thu, 31 Oct 91 10:52:37 -0500

From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110311552.AA12211@sunee.waterloo.edu Subject: Re: Results of STRAW-POLL (fwd) To: glove-list@karazm.math.uh.edu Date: Thu, 31 Oct 91 10:52:36 EST X-Mailer: ELM [version 2.3 PL11]

> comp.virtual.mouse (for flying meeces)

Perhaps comp.virtual.bats? :-)

Personally, I would prefer the creation of a comp.periphs.glove group

The thing is, once we've got the PowerGlove software fully operational on a range of platforms, there really isn't much need for either a group or a mailing list. Now, a mailing list fading away once its job is done is no problem, but newsgroups tend to be longer-lived. I'd like a name that reflects a broader-based (and longer-duration) area of interest. Perhaps something about 3-D pointing devices in general? Gloves, head- mounted displays that track your head movements, datasuits, etc etc. –

Bernie Roehl, University of Waterloo Electrical Engineering Dept
Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
BangPath: watmath!sunee!broehl
Voice:  (519) 885-1211 x 2607 [work]

From shrchin%susssys1.reading.ac.uk%subnode.susssys1.rdg.ac.uk@susssys1.reading.ac.uk Thu Oct 31 04:53:25 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA15869

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 31 Oct 1991 10:02:30 -0600

Received: from susssys1.reading.ac.uk by sun2.nsfnet-relay.ac.uk via JANET

        with NIFTP id <29774-0@sun2.nsfnet-relay.ac.uk>;
        Thu, 31 Oct 1991 04:51:35 +0000

From: Jonathan "H." "N." Chin shrchin@susssys1.reading.ac.uk Via: subnode.susssys1.rdg.ac.uk (shsscsc1); Thu, 31 Oct 91 04:53:19 GMT Date: Thu, 31 Oct 91 04:53:25 GMT Message-Id: 777.9110310453@subnode.susssys1.rdg.ac.uk To: glove-list@karazm.math.uh.edu I've been watching this list for a little while, having started wondering about the suitability of a power-glove for use in my research. I would appreciate answers to a few questions that spring to mind. I have never seen a power-glove (PG) except in pictures in the Byte article and in the CHI'91 conference proceedings. (1) where can I get them in UK? (I've taken note of Medlantic Hi-Tec's address posted by ecl6gum) (2) Would it be advantageous to get from US, considering postage and such,

  seeing as how it seems to be so much cheaper there?

(3) If yes to previous question, how do I go about it? (4) What kind of resolution can I expect to get from it? (in terms of joint angle, position, orientation, number of samples per second, etc. In short, where's the spec sheet?) (5) How obstructive is the PG? (in terms of restricting freedom of movement of the fingers, etc.) On related note: (6) What am I doing wrong when I try to ftp from karazm.math.uh.edu? (It responds erratically to any commands, initially rejecting "anonymous" as a login, but allowing it after USER, and typically responding to about the third or fourth command *previous* to the current one. I tried mailing the ftp-person but have received no reply.) Finally, a PostScript file of glove timing was posted (from Manfred Krauss). The top of my copy shows:

% PostSaript-Image: erzeugt mit Bilder-Programm Version vom 29. 5.91 UJ
% am 0. 0.2028 um 0: 2: 2
% K:\MEGPAINT\PGTIMG11.PS

/Bild 166 string def

20 20 translate
510 780 scale
larotnge
          ^^^^^^^^what is this?

>
1328 2032 1 [ 1328 0 0 -2032 0 2032]
{ currentfile Bild readhehstring pop ]

                   ^^^^^^^^^^^^^what is this?

> image

and, after the (presumably hex) data that follows, the file ends with:

/#copies 1 def
^^^^^^^^where is this defined?

> showpage

(7) Has the file been trashed in transit? If not, would somebody please supply me

  with the translations necessary to make it printable?

Thank you, Jonathan Chin shrchin@uk.ac.rdg.susssys1 Department of Cybernetics, University of Reading, England. From jet Thu Oct 31 04:28:01 1991 Received: by karazm.math.UH.EDU id AA16086

(5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 31 Oct 1991 10:28:01 -0600

From: J Eric Townsend <jet> Message-Id: 199110311628.AA16086@karazm.math.UH.EDU Subject: Re: Results of STRAW-POLL (fwd) To: broehl@sunee.waterloo.edu (Bernie Roehl) Date: Thu, 31 Oct 91 10:28:01 CST Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110311552.AA12211@sunee.waterloo.edu; from "Bernie Roehl" at Oct 31, 91 10:52 am X-Mailer: ELM [version 2.3 PL11] you wrote:

The thing is, once we've got the PowerGlove software fully operational
on a range of platforms, there really isn't much need for either a group
or a mailing list. Now, a mailing list fading away once its job is done

There are other gloves, and there will continue to be other gloves… – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 AMA# I-forget PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From agodwin@acorn.co.uk Thu Oct 31 13:20:00 1991 Received: from eros.uknet.ac.uk by karazm.math.UH.EDU with SMTP id AA17462

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 31 Oct 1991 13:05:45 -0600

Received: from acorn.co.uk by eros.uknet.ac.uk with UUCP

        id <27341-0@eros.uknet.ac.uk>; Thu, 31 Oct 1991 13:41:47 +0000

Received: from snark.acorn.co.uk by acorn.co.uk (4.1/Am32) id AA21854;

        Thu, 31 Oct 91 13:20:11 GMT

From: agodwin@acorn.co.uk (Adrian Godwin) Date: Thu, 31 Oct 91 13:20:00 GMT Message-Id: 9110311320.AA13185@snark.acorn.co.uk To: JET@UH.edu, rick@hci.hw.ac.uk Subject: Re: UK users Cc: glove-list@karazm.math.uh.edu you wrote:

you wrote:
>Out of curiousity, how many of us are there and what are we hoping to

$ wc -l vr/glove-list/list
302 vr/glove-list/list

But I think what was wanted was :

$ grep uk vr/glove-list/list | wc -l

I'm interested in all the discussions that occur here, and enjoy thinking about various possible developments in both hardware and software. However, I'm over-committed to a whole bunch of other work and non-work projects and suspect that I'll never find the time to do anything concrete. I'm a virtual-virtual-reality person :-). I have a particular interest in platform-independent developments (especially non-PC developments). This was a reason for joining my present employer (a small UK hardware manufacturer, for those not familiar with Acorn) rather than a consequence of working here. -adrian From exv2447@ultb.isc.rit.edu Thu Oct 31 09:37:06 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA17667

(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 31 Oct 1991 13:41:28 -0600

Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA18979; Thu, 31 Oct 91 14:37:06 -0500 Date: Thu, 31 Oct 91 14:37:06 -0500 From: exv2447@ultb.isc.rit.edu (E.X. Vanhensbergen ) Message-Id: 9110311937.AA18979@ultb.isc.rit.edu To: glove-list@karazm.math.uh.edu, yonder@netcom.netcom.com Subject: Re: 68hc11 EVB vs. EVBU… Cc: emr4510@ultb.isc.rit.edu Where are you ordering the 6811 from? Eric -RIT From jdb9608@cs.rit.edu Thu Oct 31 18:32:52 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA20066 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 31 Oct 1991 22:34:38 -0600 Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS)) id AA13870; Thu, 31 Oct 91 23:30:18 -0500 Received: from boron.CS (boron.ARPA) by junior.rit.edu (4.1/5.17) id AA03666; Thu, 31 Oct 91 23:18:09 EST From: jdb9608@cs.rit.edu (John D Beutel) Message-Id: 9111010418.AA03666@junior.rit.edu Subject: glove interface standard To: glove-list@karazm.math.uh.edu Date: Thu, 31 Oct 91 23:32:52 EST X-Mailer: ELM [version 2.3 PL8] I hope there are at least a few people still interested in this. I'd like the standard to do as much as it possibly can. I suggest we make the glove interface standard complex and smart. Normally I would prefer something simple and elegant, but since we don't have diffinitive specs on the glove and we don't really know what we'll figure out how to make it do next, we shouldn't make a standard that will become obsolete in a few months. The key is to abstract the glove functionality, so what the glove does (and what the program expects it to do) is not linked to a particular method. Different machines and different schemes will use different methods, which will yield different capabilities, but if the standard can put those capabilities in abstract terms then the program can ask for what it needs and the interface can worry about how to do it. See how you like this for abstraction (any additions?): sample rate (Hz) x, y, z resolution each finger, w/ resolution response time (from physical sample to availability of data) synch glove to computer (or not) buttons, pad, and lo-res joystick data call a user function when data arrives (or not) It's not easy to know how the abstraction should be done. For example, should the X, Y, and Z values be handled seperately or together? Seperately makes more complexity, but e.g. if someone invents a way of getting better Z resolution than X & Y resolution then seperate would be better. It's not just a question of the absolute capabilities of the interface (software or hardware)—there are tradeoffs. For example, what if we find a way to turn off the fingers and get a faster sample rate? If the app just wants a 3D coordinate, then this is a good tradeoff. If the app needs the fingers too, then it isn't. This futuristic interface could do either faster sampling or finger data, but not both. So, it can't simply report its sampling rate or finger resolution because it depends. That's why I think a negotiation with the interface would be a great way to do it (as someone already suggested). Of course, it can't be too complicated, or who'd want to use it? One function call would be best. The application could give the interface its requirements for each abstraction: minimum acceptable value maximum acceptable value prefered value priority The interface resolves conflicts the best it can, making tradeoffs in order of priority, and returns what it can do. (E.g., you prefered a sample rate of 30 Hz but the best I can do is 17 Hz. It's within your acceptable range, so here it is.) If the application doesn't care about an abstraction (e.g., doesn't care what the X, Y, Z resolution is) it can say so (e.g., specify -1 as its value requirements). Likewise, if the app doesn't need an abstraction at all (e.g., doesn't want any lo-res data) then it can say so (e.g., specify 0 as its priority). The interface sorts the abstraction requirements in order of priority, and then attempts to grant each its prefered value. If that becomes impossible, then it tries to get it within the acceptable value range. If that is still impossible, then the interface could either do its best, or sort the requirements in a different order than their priority and try again. The prefered value of a high priority may make impossible the acceptable value of a lower priority, but if the lower priority is satisfied first then the higher priority may still be able to be within the acceptable range. For 7 abstractions, the 7! possible orders of priority are about 3000. For 9 abstractions, the 9! orders go up to the impractical area of 350,000. So, doing all possible orders of priority may be impossible, but it may be easy to swap a few of the ones that the standard knows will make a difference. Whether or not the interface implementation is smart enuf to do this doesn't really matter. If the interface doesn't try different orders, or if it does but it still can't satisfy the application's request, then it just returns what it can do. The skill of the tradeoffs that the interface makes—and its raw capability—will increase with time, but at least right now if the interface can't do it, it can say so thru the standard, and the app can decide for itself whether it's good enuf or not. If the interface can't satisfy the app's request, the app can always make another request with looser constraints. I doubt that app's will do this very often—that's the idea of specifying an acceptable range and priority; let the interface do all the work trying to get it right. In most cases, the app makes one call to the interface, and the it does the best that it can, (initializes the glove?), and returns what it's going to do (e.g., the finger data will range from 0 to 3). The app uses the return values (instead of constants) to interpret the data. So, if you wire your glove's fingers directly to an IO port to get faster sampling and better resolution, the interface you write returns that its finger data will range from 0 to 255, and the application that only needs 0 to 3 will work just as well with your better data. Passing the abstraction requests via dynamic means (i.e., "tags") also sounds like a good idea (someone else suggested earlier). That way, if other abstractions are added later (e.g., a glove with two X,Y,Z coordinates) then programs could request these new abstractions from old interfaces and still compile. If we put the standard names in a datastructure, then the compiler won't work with the older .h interface files, or the function call's arguments will be wrong. If we use "tags", then the interface can ignore the things it doesn't know, or act intelligently by telling the app that it can't do those things. The app can decide for itself whether it really needs that extra X,Y,Z coordinate or not. Some apps may really need it, and won't be written to be downwardly compatable. Other apps may not need it—it may be strictly an option or a fringe. For those apps, it would be a shame to not be able to use them with older interfaces or simpler hardware just because the names were hardcoded and the compiler won't compile the new names. Using tags will make the interface a little more complicated, but not significantly so, especially considering that the support functions only need to be written once. I wouldn't mind writing them for the ST, and they'd be practically the same on any computer. Here's an example of what the code might look like: ————————– in stdglove.h ————————- struct negotiate_glove { char *name; /* the tag, standardized */ long minimum, /* acceptable range, std bit length */ preference, /* prefered value */ maximum; /* acceptable range */ int priority; long offer; /* return value of what interface can do */ /* 0 == not available */ /* double the number of elements here to allow for signed ranges? */ /* e.g., -127..128 instead of just 255? */ } ————————— in app.c —————————— struct negotiate_glove gn[6] = { {"rate", 1, 14, 30, 1, 0}, {"sync", 1, 1, 1, 2, 0}, {"xyz", 10, 255, 1000, 3, 0}, {"finger1", -1, -1, -1, 4, 0}, {"lores", 0, 0, 0, 0, 0}, /* actually, maybe for those */ /* things we don't want it would */ /* be easier to just not ask for */ /* them. */ {"end"} } main() { init_glove( gn); if( get_offer( gn, "rate") != 14) fprintf( stderr, "warning: optimum sample rate unavailable"); /* etc… */ } We could include an option to init_glove so that if it can't satisfy the app's request within the given acceptable values, then it prints a nice error message and aborts, so the app doesn't even have to worry about checking the return values if it doesn't want to. The tags do make the interface more complicated, but not significantly so. They will slow the initialization a little, but it's not noticable. They will slow the retrieval of the sample data a little, but only a few microseconds (unless someone can come up with a clever macro for this? I haven't thought much about it.) Milliseconds are significant, but what's a few microseconds at 30 Hz? Please think about whether a complex standard like this would be good for this glove environment, and express your opinion. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am."

1)
x»6)&3) #define F2(x) ((x»4)&3) #define F3(x) ((x»2)&3) #define F4(x) (x&3) #define HAND(x) (((x&2)»1)|((x&8)»2)|((x&32)»3)|((x&128)»4
2)
x1+x2)»1); /* smoothed velocity */ vy = y-((y1+y2)»1); x2 = x1; /* update last values */ x1 = g→x; y2 = y1; y1 = g→y; if(abs(lcx-vx)>XACC) lax = XXTEND; /* check for extreme acceleration */ if (lax == 0) lx=vx; /* save only good velocity */ lcx = vx; /* save velocity for next accel. */ if(abs(lcy-vy)>YACC) lay = YXTEND; /* same deal for Y accel. */ if (lay == 0) ly=vy; lcy = vy; if(lax!=0) /* hold X pos'n if glitch */
{
 g->x = lsx;
 lax--;
}
if(lay!=0) /* hold Y pos'n if glitch */
{
 lay--;
 g->y = lsy;
}
lsx = g→x; /* save position for X,Y hold */ lsy = g→y; /* g→y = x;*/ } From kskelm@uccs.edu Thu Oct 17 16:58:06 1991 Received: from happy (happy.uccs.edu) by karazm.math.UH.EDU with SMTP id AA25307
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 17 Oct 1991 22:39:55 -0500
Received: by uccs.edu (MX V2.3-1) id 9694; Thu, 17 Oct 1991 20:58:06 EDT Date: Thu, 17 Oct 1991 20:58:06 EDT From: "NO, That's NOT a cord of wood in my pocket!" kskelm@uccs.edu To: glove-list@karazm.math.uh.edu Message-Id: 0095044C.AC4DE760.9694@uccs.edu Subject: Amiga version of Hires code?
Is anybody working on an Amiga version of the glove Hires code?
I sure hope so… 'cuz I know *I* don oops …don't fully understand its function. Kevins From nik@bu-it.bu.edu Fri Oct 18 03:50:19 1991 Received: from BU-IT.BU.EDU by karazm.math.UH.EDU with SMTP id AA26700
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.UH.EDU>); Fri, 18 Oct 1991 06:54:26 -0500
Received: from BUITC.BU.EDU by bu-it.bu.edu (5.61+++/Spike-2.1)
id AA25694; Fri, 18 Oct 91 07:50:22 -0400
From: nik@bu-it.bu.edu (Nik Conwell) Received: by buitc.bu.edu (5.61+++/Spike-2.0)
id AA08066; Fri, 18 Oct 91 07:50:19 -0400
Date: Fri, 18 Oct 91 07:50:19 -0400 Message-Id: 9110181150.AA08066@buitc.bu.edu To: glove-list@karazm.math.UH.EDU Subject: PG locations, NC-1 cables, and Amiga hookup. Cc: nik@bu-it.bu.edu A few things: 7 gloves spotted at Toys'R'Us in Framingham Ma (on Route 9). 508 872-6242 Marked at $49, but rang up for about $30. Curtis NC-1 Super Extendo cable, mentioned in the Byte Article (Byte, July 1990 page 288), found at that toy store in the Natick Mall on Route 9. $9.99/pair. Has anyone made an Amiga cable yet? Did you have the same wiring as the Byte Article, except that +5 volts could be taken from pin 14 on the parallel port?? Is there any Amiga code out there that would point me in the right direction of talking to the glove through the parallel port (just in regular mode)? Any info is greatly appreciated. Thanks -nik – nik@bu-it.bu.edu From druwy!mab@att.att.com Fri Oct 18 01:30:00 1991 Received: from att.att.com by karazm.math.UH.EDU with SMTP id AA26978
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.UH.EDU>); Fri, 18 Oct 1991 08:39:22 -0500
Message-Id: 199110181339.AA26978@karazm.math.UH.EDU From: druwy!mab@att.att.com Date: Fri, 18 Oct 91 07:30 MDT To: att!glove-list Subject: Amiga hi-res glove code available Last weekend I got the hi-res code working on the Amiga with my own custom hookup. I don't have ftp access. Anybody who wants a copy, send me e-mail and I'll send you source and executables. I ultimately plan to do a nice multi-tasking-friendly version, but for now you'll have to make do with a busy-wait version. My glove hooks to the parallel port. It's *almost* the BYTE hack. I moved the data line from pin 13 to pin 4, and of course hooked up the +5V line to pin 14. Alan Bland mab@druwy.att.com From agodwin@acorn.co.uk Fri Oct 18 15:31:23 1991 Received: from eros.uknet.ac.uk by karazm.math.UH.EDU with SMTP id AA27065
(5.65c/IDA-1.4.4 for <glove-list@KARAZM.MATH.UH.edu>); Fri, 18 Oct 1991 08:54:15 -0500
Received: from acorn.co.uk by eros.uknet.ac.uk with UUCP
        id <10436-0@eros.uknet.ac.uk>; Fri, 18 Oct 1991 14:39:11 +0100
Received: from snark.acorn.co.uk by acorn.co.uk (4.1/Am31) id AA11208;
        Fri, 18 Oct 91 14:31:21 BST
From: agodwin@acorn.co.uk (Adrian Godwin) Date: Fri, 18 Oct 91 14:31:23 +0100 Message-Id: 9110181331.AA00911@snark.acorn.co.uk To: glove-list@KARAZM.MATH.UH.edu, nik@BU-IT.BU.edu Subject: Re: PG locations, NC-1 cables, and Amiga hookup.

Is there any Amiga code out there that would point me in the right direction
of talking to the glove through the parallel port (just in regular mode)?

Any info is greatly appreciated.
Thanks
-nik
There's some Amiga code around for a 'learning remote control' - it's incomplete, but since it operates by polling the parallel port direct it might give you some guidelines. It's also covered in both the CBM and Abacus books, but sample code always makes it easier .. The code I have was on comp.sources.amiga; I can send a copy if you don't have a local archive. -adrian From galt@dsd.es.com Fri Oct 18 05:01:05 1991 Received: from orca.es.com (ES.COM) by karazm.math.UH.EDU with SMTP id AA28398
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 12:05:41 -0500
Received: from dsd.ES.COM ([130.187.100.101]) by orca.es.com (4.1/SMI-4.1)
id AA08987; Fri, 18 Oct 91 11:01:06 MDT
Received: by dsd.ES.COM (4.0/SMI-4.1/e&s_server-2.1/dsd)
id AA05304; Fri, 18 Oct 91 11:01:05 MDT
Date: Fri, 18 Oct 91 11:01:05 MDT From: galt@dsd.es.com (Greg Alt - Perp) Message-Id: 9110181701.AA05304@dsd.ES.COM To: dstamp@watserv1.uwaterloo.ca, glove-list@karazm.math.uh.edu Subject: noise-free glove software Hey, that looks great. I'm glad someone went to the trouble of rolling up the init routine into a loop… I'll try out it out this weekend. That noise-reduction part sounds pretty impressive. Here's my plan for what we need to do to make the whole package (close to) perfect: 1) convert the function names to some standard 2) separate the glove driver in its own .c file 3) use compiler directives to allow use of the same code on several machines
e.g. #define PC_PRINTER would make it compile for a
     PC using the printer port.
This shouldn't be too difficult since the code is basically the
same with only a few minor differences for each machine.
This is all pretty amazing… before we got our first hi-res code, nobody was very interested in the glove, now people everywhere are getting excited about it. I've already gotten mail from people from Korea to the U.K.
     Greg
From gbnewby@alexia.lis.uiuc.edu Fri Oct 18 07:05:21 1991 Received: from alexia.lis.uiuc.edu by karazm.math.UH.EDU with SMTP id AA28422
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 12:09:41 -0500
Received: by alexia.lis.uiuc.edu id AA15909
(5.61/ for glove-list@karazm.math.uh.edu); Fri, 18 Oct 91 12:05:21 -0500
Date: Fri, 18 Oct 91 12:05:21 -0500 From: Greg Newby gbnewby@alexia.lis.uiuc.edu Message-Id: 9110181705.AA15909@alexia.lis.uiuc.edu To: jdb9608@cs.rit.edu Subject: Re: sega glasses available? Cc: glove-list@karazm.math.uh.edu For the circuit, has anyone tested it out? It appears that you hook in the Sega glasses, and then send a signal to switch the LCDs (from left-on, right-off to left-off, right-on). The signal is sent via pin 4, which is not the regular pin for reading or writing data. So, the question is, what's involved in switching the signal? If it's a call to termio() or somesuch, what sort of speed limitations are we talking about? I didn't check the RS232 standard just now, but I wonder about the +/- 10V switching signal – isn't that rather 0-12V? (effectively, probably +/-3 to 8-12V). Finally, does anyone have the tech specs on the glasses (or an estimate, as I suspect Sega doesn't include such things with the glasses)? Switching speed, %dark, etc… With the brain trust we have on this list, I'm not too worried that someone will figure out how to hook in the glasses. I'm just wondering in advance if performance (especially switching speed) will be up to snuff.
(For example, to give some numbers, we need a minimum
 of about 10 frames per second to perceive continuity
 between frames of a moving scene.  That means the glasses
 need to switch 20 times per second, right?  A left-right
 sequence for each frame.
	If there's more than a few u-second lag for the
 glasses to switch, we'll have to compensate in the
 display program.  Being that we're usually using all
 the computing power we have just to keep the graphic
 images coming fast enough, incorporating some sort
 of delay for the glasses would be undesirable.)
Oh, BTW: I've done a bit of experimenting (back at Syracuse) with some Tektronics shutter glasses – a very similar beast, tho presumably higher performance. I found that the flicker was perceivable at 30Hz (60 switches / second), and intolerable (read, "doesn't work") at about 7-15 Hz. I didn't experiment with the full range….this was because the software-driven switching circuit never operated more quickly than about 15Hz. Ok, I'm rambling now: the alternative, to get 30Hz, is to NOT switch the glasses via software. Just let them operate at the frequency of the power supply (60Hz in the US, which, in the circuit we used @ Syracuse, was run through a rectifier). Then, no coordinating between your graphics program and the glasses are necessary, PROVIDED that your program is able to operate at "top-speed," switching the image on the screen as often as possible (as in, the speed of the power supply). I don't know if this technique works for all platforms, but it worked on the Amiga and Iris we used at Syracuse. I even synched the glasses off of a Sony VCR/editor to look at the display on the Iris. 'Nuff said. – Greg gbnewby@alexia.lis.uiuc.edu From leh@manatee.cis.ufl.edu Fri Oct 18 08:14:13 1991 Received: from manatee.cis.ufl.edu by karazm.math.UH.EDU with SMTP id AA28603
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 12:52:58 -0500
Received: from localhost by manatee.cis.ufl.edu (5.61ufl/4.12)
id AA29184; Fri, 18 Oct 91 12:14:14 -0400
Message-Id: 9110181614.AA29184@manatee.cis.ufl.edu To: glove-list@karazm.math.uh.edu Subject: Re: PG locations, NC-1 cables, and Amiga hookup. In-Reply-To: Your message of "Fri, 18 Oct 91 07:50:19 EDT."
           <9110181150.AA08066@buitc.bu.edu> 
Date: Fri, 18 Oct 91 12:14:13 EDT From: leh@manatee.cis.ufl.edu In another life you (nik@bu-it.bu.edu (Nik Conwell
3)
x » 2) + 320/4 * y + act_page);
      addr = ((addr & 0xffff0000l) << 4) + (addr & 0xffffL) + ((long) VGA_SEGM
ENT « 16);
      outport(SC_INDEX, (0x100 << (x & 3)) | MAP_MASK);
      *(char far*)addr = colour;
} void set320x400mode(void) { struct REGPACK regs; unsigned char x;
      regs.r_ax = 0x13;                               /* Set 320*200*256 graph
ics mode via BIOS */
      intr(0x10, &regs);
/* Change CPU addressing of video memory to linear (not odd/even, chain, or
      chain 4), to allow access to all 256K of display memory. Each byte will 
now
      control one pixel, with 4 adjacent pixels at any given address, one pixe
l
      per plane. */
      outportb(SC_INDEX, MEMORY_MODE);
      x = inportb(SC_INDEX+1);
      x &= 0xf7;                                                              
      /* Turn off chain 4  */
      x |= 4;                                                                 
      /* Turn off odd/even */
      outportb(SC_INDEX+1, x);
      outportb(GC_INDEX, GRAPHICS_MODE);
      x = inportb(GC_INDEX+1);
      x &= 0xef;                                                              
      /* Turn off odd/even */
      outportb(GC_INDEX+1, x);
      outportb(GC_INDEX, MISCELLANEOUS);
      x = inportb(GC_INDEX+1);
      x &= 0xfd;                                                              
      /* Turn off chain */
      outportb(GC_INDEX+1, x);
/* Now clear the whole screen, since the mode 13h set only clears 64K. Do this
      before switching CRTC out of mode 13h, so that we don't see grabage on t
he
      screen. */
      outport(SC_INDEX, 0x0f00 | MAP_MASK);                   /* Write to 4 pl
anes at once */
      setmem(MK_FP(VGA_SEGMENT, 0), 0xffff, 0);
/* Change mode to 320*400 by not scanning each line twice. */
      outportb(CRTC_INDEX, MAX_SCAN_LINE);
      x = inportb(CRTC_INDEX+1);
      x &= 0xe0;                                                              
/* Set maximum scan line to 0 */
      outportb(CRTC_INDEX+1, x);
/* Change CRTC scanning from doubleword to byte mode, allowing the CRTC to
      scan more than 64K */
      outportb(CRTC_INDEX, UNDERLINE);
      x = inportb(CRTC_INDEX+1);
      x &= 0xbf;                                      /* Turn off doubleword *
/
      outportb(CRTC_INDEX+1, x);
      outportb(CRTC_INDEX, MODE_CONTROL);
      x = inportb(CRTC_INDEX+1);
      x |= 0x40;                                      /* Turn on the byte mode
bit, so memory is linear */
      outportb(CRTC_INDEX+1, x);
} void end320x400mode(void) { struct REGPACK regs;
      regs.r_ax = 3;                          /* Return to text mode */
      intr(0x10, &regs);
} /* Set visible page */ void setvispage(int page) {
      outport(CRTC_INDEX, (page << 15) | START_ADDRESS_HIGH);
} /* Set active page (page being written to */ void setactpage(int page) {
      act_page = page ? 0x8000 : 0;
} void WaitForVerticalRetrace(void) { static char chopper = 1;
      while (inportb(DISPIO) & VRT_bit) /* wait */ ;
      while ((inportb(DISPIO) & VRT_bit) == 0) /* wait */ ;
      if ((chopper++ & 1)== 0)                outportb(0x3fc, 1);
      else                                                                    
outportb(0x3fc, 3); } void main(int argc, char *argv[]) {
 set320x400mode();
/* Now fill the rgb_palette structure in memory with colour info */
 setvgapalette(&rgb_palette);
 setactpage(0);
/* Now call writepixel to put stuff on page 0 */
 setactpage(1);
/* Now call writepixel to put stuff on page 1 */
 while (!kbhit()) {
         WaitForVerticalRetrace();
         setvispage(0);
         WaitForVerticalRetrace();
         setvispage(1);
 }
 getch();
 end320x400mode();
} – Take a walk on the wild side, and I don't mean the Milford Track. Kayaking: The art of appearing to want to go where your boat is taking you. – J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." From jmunkki@hila.hut.fi Fri Oct 18 23:39:28 1991 Received: from hila.hut.fi by karazm.math.UH.EDU with SMTP id AA28966
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 14:43:40 -0500
Received: by hila.hut.fi (5.65c/7.0/S-TeKoLa)
id AA16262; Fri, 18 Oct 1991 21:39:28 +0200
Date: Fri, 18 Oct 1991 21:39:28 +0200 From: Juri Munkki jmunkki@hila.hut.fi Message-Id: 199110181939.AA16262@hila.hut.fi To: glove-list@karazm.math.uh.edu Subject: Re: sega glasses available? The Sega glasses really do operate with +/- 10 V. I haven't tried anything higher, but I do know that they work with +/- 9V. You have to be particularly careful not to feed any DC to the glasses, because it will break the shutters. The % darkness is supposedly around 60%. On the Macintosh it's not a problem to switch the glasses at vertical blanking time (the operating system has support for installing tasks to run at VBL time), so on my monitor at home, I get 66 switches per second (a frame rate of 33 Hz). The new 21" monitor from Apple uses 75 Hz, so there should be almost no flicker. I hope all Mac users on this list are aware of the Macintosh-compatible interface and the sample application that I wrote for it. I don't know if it is any longer possible to connect the glasses and the glove to the same serial port now that we know how to access the hi-res mode. (I haven't looked at the code, but I expect someone to come up with a Mac version really soon now.) Juri From motcsd!roi!lance@apple.com Tue Oct 18 06:25:25 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA29470
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 15:56:47 -0500
Received: by apple.com (5.61/18-Oct-1991-eef)
id AA27173; Fri, 18 Oct 91 13:30:44 -0700
for 
Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)
id <m0kY0nt-0001QuC@motcsd.csd.mot.com>; Fri, 18 Oct 91 13:28 PDT
Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)
id AA15238; 18 Oct 91 13:25:27 PDT (Fri)
To: glove-list@karazm.math.uh.edu, jdb9608@cs.rit.edu Subject: Re: sega glasses available? Message-Id: 9110181325.AA15226@roi.ca41.csd.mot.com Date: 18 Oct 91 13:25:25 PDT (Fri) From: Lance Norskog lance@roi.ca41.csd.mot.com Another source of glasses is a product from Haitex (inc. or something) in Charleston, S. Carolina. These are surplus Nintendo glasses packaged with a box half the size of a cigarette pack. The box takes 5V, Ground, and a control line and controls one or two goggles. These are built for the Amiga and should be available from a hip Amiga dealer near you. The Haitex BBS had the pinouts for the 9-pin Amiga joystick connector; I've got them stashed somewhere. The things list for $110 and are built and solidly packaged. A deal for we non-electronics types. The Nintendo goggles (welder's helmet actually) were never marketed in the states. Lance Norskog From dstamp@watserv1.uwaterloo.ca Fri Oct 18 13:01:17 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA29697
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 16:05:22 -0500
Received: by watserv1.uwaterloo.ca
id <AA08021>; Fri, 18 Oct 91 17:01:17 -0400
Date: Fri, 18 Oct 91 17:01:17 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110182101.AA08021@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Hey, thanks for the 320x400x256 code fragment! I had already figured out how get that resolution, and how to get 2 pictures, but I couln't figure out how to write the pictures without leaving the mode. (A bit misleading, calling SC#4 bit 3 "odd/even"!) A bit expensive in time, constantly changing the plane write register, though. Guess I'll have to figure out another damn 4-pass write algorithm. (B-{) I think that VR applications would be better served by using 4 pages of 200 lines, as that cuts down the rendering time and allows double buffering. Any comments on using 16-color modes for even faster rendering? Is there ANY way that so few colors is sufficient for filled-poly VR work? Which brings up the topic of reprogramming VGA cards to achieve new resolutions and timings. Cheap LCD displays are going to need this to work properly. I did some work last summer on getting NTSC timings to run Sharp LCD panels, but I had to add a new clock source via the VGA feature connector. Any idea how cards from different manufacturers handle radical reprogramming of the registers? Is the timing (i.e. blanking period) and "screwy" video modes reliable across all cards? About the Sega driver: looks a lot like the push-pull driver I developed a while ago. I didn't consider using the RS232 port as a power source then as I wasn't sure of the current capacity. Using a CMOS part as an oscillator makes it draw a LOT more current than the spec sheet suggests. It DOES get the needed 20-24V signal output that the glasses need for full shuttering, though. -Dave Stampe From motcsd!roi!lance@apple.com Tue Oct 18 06:40:03 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA29733
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 16:09:35 -0500
Received: by apple.com (5.61/18-Oct-1991-eef)
id AA28855; Fri, 18 Oct 91 13:45:43 -0700
for 
Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)
id <m0kY124-0001FVC@motcsd.csd.mot.com>; Fri, 18 Oct 91 13:43 PDT
Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)
id AA15364; 18 Oct 91 13:40:05 PDT (Fri)
To: glove-list@karazm.math.uh.edu Subject: Sega driving Cc: gbnewby@alexia.lis.uiuc.edu, jdb9608@cs.rit.edu Message-Id: 9110181340.AA15352@roi.ca41.csd.mot.com Date: 18 Oct 91 13:40:03 PDT (Fri) From: Lance Norskog lance@roi.ca41.csd.mot.com If you were clever, you could drive the Sega and the glove off the same 68C11 evaluation board. No! No! Stop hitting me! Lance Norskog From dstamp@watserv1.uwaterloo.ca Fri Oct 18 14:02:00 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA00339
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 18 Oct 1991 17:06:10 -0500
Received: by watserv1.uwaterloo.ca
id <AA10961>; Fri, 18 Oct 91 18:02:00 -0400
Date: Fri, 18 Oct 91 18:02:00 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110182202.AA10961@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu
This debate went through the Amiga newsgroups recently, and I will quickly
point out the conclusion reached there: many good C compilers, with the
optimizer turned on, come close enough to a good assembler programmer as
to be indistinguishable. This came out after assembly programmers posted
an assembly algorithm as they would do it, and the C programmers ran the
same thing through their C compilers, and the two were nearly identical!
Was this graphics code or was it something else? Was it programming the
Amiga hardware or was it doing the tight loops we know and ?love???
There was a small cycle-count difference (something like 2 cycles in
a 100-cycle loop) in that particular loop, so you are right – assembly
programmers can get every last cycle, but they're not winning by much.
And as has already been pointed out here, the high-level programmer can
spend more time refining the algorithm, and thus maybe execute the
loop fewer times. Conclusion: Assembly programmers make each iteration
of the loop slightly faster, but high-level programmers iterate it
less.

– Greg Stelmack (stelmack@eggo.csee.usf.edu)
I think I see the problem here. The difference is between the IBM and Amiga designs. Any real graphics work on the IBM PC requires multiple I/O space accesses with inportb() and ouportb() type routines. Since most of the available C compilers do not replace these with inline code, this results in much slower operation than with assembly code. Also, many of the good instructions on the 80x86 (such as LOOP or REP STOSB) are not used by compilers. Again, assembly code is the only solution. Conversely, the Amiga's 68000 processor accesses its graphics hardware's registers as memory-mapped, so C tends to work well here. There are very few special instructions on the 68K processor that are good for graphics. Also, on the Amiga, the graphics hardware makes the need for tight, fast graphics loops less. When it comes to higher-level stuff like handling data structures and calculating stuff, I agree that C is better than assembler. My code usually consists of 90% C and 10% embedded assembly code for the graphics kernals. I usually gain 300-1000% in performance of the graphics sections of my code by converting selected sections to assembler. The low-level VR thread portion which is also taking place via the powerglove mailing list seems to be showing that there is at LEAST a 50-50 split between graphics and database manipulation/sorts/etc in a VR system. This indicates that C code is going to be VERY useful. Conversely, the need for assembly code (machine-specific) in the actual poly-rendering drivers is especially great on the IBM PC machines (see above). - Dave Stampe From dstamp@watserv1.uwaterloo.ca Fri Oct 18 18:12:28 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA01189
(5.65c/IDA-1.4.4 for <glove-list@KARAZM.MATH.UH.edu>); Fri, 18 Oct 1991 21:16:38 -0500
Received: by watserv1.uwaterloo.ca
id <AA20225>; Fri, 18 Oct 91 22:12:28 -0400
Date: Fri, 18 Oct 91 22:12:28 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110190212.AA20225@watserv1.uwaterloo.ca To: dstamp@WATSERV1.uwaterloo.ca, glove-list@KARAZM.MATH.UH.edu,
      rrr@aberystwyth.ac.uk
Subject: Re: TSR From dstamp@watserv1.uwaterloo.ca Fri Oct 18 18:14:59 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA01196
(5.65c/IDA-1.4.4 for <glove-list@KARAZM.MATH.UH.edu>); Fri, 18 Oct 1991 21:19:04 -0500
Received: by watserv1.uwaterloo.ca
id <AA20259>; Fri, 18 Oct 91 22:14:59 -0400
Date: Fri, 18 Oct 91 22:14:59 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110190214.AA20259@watserv1.uwaterloo.ca To: dstamp@WATSERV1.uwaterloo.ca, glove-list@KARAZM.MATH.UH.edu,
      rrr@aberystwyth.ac.uk
Subject: Re: TSR
From glove-list-request@karazm.math.UH.EDU Wed Oct 16 10:29:06 1991
From: rrr@aberystwyth.ac.uk
To: dstamp@WATSERV1, glove-list@KARAZM.MATH.UH.edu
Subject: TSR


>If you're interested in other uses for hi-res, how about a TSR or adapter to
replace a joystick for video games? Shouldn't be too hard, esp. if the
game is key-driven (Tetris looks like an easy one, and it's PD).
>

Ive written a TSR for low res use og PowerGlove, it works for

most applications. I dont have time to rewrite my basic IO

stuff for hi res, but the TSR should work fine, Ill post the source

if anybodys interested.

Ronan

R M Ruairi, UCW Aberystwyth, rrr@UK.AC.Aber

ps the code interprets data from PG as keystrokes and stuffs the standard
buffer. Its written in Turbo Pascal v6.

Sure, send me a copy of the code. I need something to look at for future TSR endeavors. I'm working with C, but the sequence and BIOS/DOS calls should be clear. -Dave Stampe From druwy!mab@att.att.com Sat Oct 19 04:23:00 1991 Received: from att.att.com by karazm.math.UH.EDU with SMTP id AA02793
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 19 Oct 1991 11:35:05 -0500
Message-Id: 199110191635.AA02793@karazm.math.UH.EDU From: druwy!mab@att.att.com Date: Sat, 19 Oct 91 10:23 MDT To: att!glove-list Subject: Amiga Hi-res code has been sent I've sent copies of the PG Amiga hi-res code to everyone who asked me for it. There are more Amiga users on the list than I expected! I've also sent a copy to Eric to be placed in the ftp archive. I won't be following up on mailer problems, so if your copy doesn't arrive in a reasonable amount of time, you can ftp it. Please request it from me only if you don't have access to ftp. For the copies I sent out individually, you'll need to uudecode the mail, and then use LZ or LHARC to extract the files. One thing I didn't mention in the "readme" file is that I used SAS/C 5.10A. You may need to do some rework to port it to any other compiler. Currently the code only runs on unaccelerated Amigas. I plan on fixing that soon. The "readme" contains other details about what may or may not work, so please read it. Happy VR-ing! Alan Bland mab@druwy.att.com From jdb9608@cs.rit.edu Sat Oct 19 15:53:32 1991 Received: from ultb.isc.rit.edu by karazm.math.UH.EDU with SMTP id AA03829
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Sat, 19 Oct 1991 18:53:58 -0500
Received: by ultb.isc.rit.edu (5.57/5.3 (Postmaster DPMSYS
4)
inportb(INPORT) & GDATA) » SHIFTVAL);
	C0L0 ();
	C1L0 ();  /* pulse */
	}
return(x);  /* return the byte */
}
void getglove(buf) /* read 6 byte data packet */
glove_data *buf;
{
register unsigned char *bp = (unsigned char *) buf;
  • bp++ = getbyte (); /* read data */
fdelay(D2BYTES);
  • bp++ = getbyte ();
fdelay(D2BYTES);
  • bp++ = getbyte ();
fdelay(D2BYTES);
  • bp++ = getbyte ();
fdelay(D2BYTES);
  • bp++ = getbyte ();
fdelay(D2BYTES);
  • bp++ = getbyte ();
fdelay(D2BYTES);
		/* throwaways (speeds up polling later) */
getbyte ();	
fdelay(D2BYTES);
getbyte ();
}
int glove_ready() /* returns 1 if glove ready, 0 otherwise */
{
return (getbyte() == 0xA0) ? 1 : 0;
}
/* HIRES ENTRY CODES byte: 1- any value between $05 and $31 2- only $C1 and $81 work OK 3- no effect 4- no effect 5- no effect 6- only $FF works 7- seems to affect read rate slightly, 1 fastest */ static int hires_code[7] = { 0x06, 0xC1, 0x08, 0x00, 0x02, 0xFF, 0x01 }; void Hires () /* enter HIRES mode <rolled code- speed unimportant> */
{
int i,j,k;
	      /* dummy read 4 bits from glove:  */
C1L0 (); C1L1 ();    /* generate a reset (latch) pulse */
fdelay(D2BITS);
C1L0 ();
fdelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
fdelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
fdelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
fdelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
	 /* handshake for command code? */
C1L0 ();
fdelay(16950);  /* 7212 us delay */
C1L1 ();
fdelay(4750);   /* 2260 us delay */
for (i = 0; i < 7; i++)   /* send 7 bytes */
	{
	k=hires_code[i];
	for (j = 0; j < 8; j++)     /* 8 bits per byte, MSB first */
		{
		if (k & 0x80) 
			{
			C1L1(); 
			C0L1();
			C1L1();
			}
		else
			{
			C1L0(); 
			C0L0();
			C1L0();
			}
		k = k<<1;
		fdelay(D2BITS);
		}
	fdelay(D2BYTES);
	}
fdelay(1090);    /* 892 us delay (end of 7. byte) */
C1L0 ();         /* drop the reset line */
fdelay(30000);   /* some time for the glove controller to relax */
fdelay(30000);
}
static int ox = -1000; /* last x,y for hysterisis */ static int oy = -1000; static void dehyst(glove_data *g) /* hysterisis deglitch (low noise removal) */
{
int x = g->x;
int y = g->y;
if(g->keys==0) ox = oy = 0;	/* handle recentering ("0"key or "Center") */
if(x-ox>XHYST) ox = x-XHYST;	/* X hysterisis */
if(ox-x>XHYST) ox = x+XHYST;
if(y-oy>YHYST) oy = y-YHYST;	/* Y hysterisis */
if(oy-y>YHYST) oy = y+YHYST;
g->x = ox;			/* replace present X,Y data */
g->y = oy;
}
static int x1 = 0; /* delayed 1 sample (for smoothed velocity test) */ static int y1 = 0; static int x2 = 0; /* delayed 2 samples */ static int y2 = 0; static int lx = 0; /* last good X,Y speed */ static int ly = 0; static int lax = 0; /* bad data "stretch" counter */ static int lay = 0; static int lsx = 0; /* X,Y "hold" values to replace bad data */ static int lsy = 0; static int lcx = 0; /* last X,Y speed for accel. calc. */ static int lcy = 0; static void deglitch(glove_data *g) {
int vx, vy;
int x = g->x;
int y = g->y;
if(g->keys == 0)		/* reset on recentering ("0" or "Center" key) */
	{
	x1 = x2 = y1 = y2 = 0;
	lx = ly = lax = lay = 0;
	lsx = lsy = lcx = lcy = 0;
	}
vx = x-((x1+x2)>>1);		/* smoothed velocity */
vy = y-((y1+y2)>>1);
x2 = x1;			/* update last values */
x1 = g->x;
y2 = y1;
y1 = g->y;
if (abs(lcx-vx) > XACC) lax = XXTEND;	/* check for extreme acceleration */
if (lax == 0) lx = vx;                   /* save only good velocity        */
lcx = vx;                              /* save velocity for next accel.  */
if (abs(lcy-vy) > YACC) lay = YXTEND;	/* same deal for Y accel. */
if (lay == 0) ly=vy;
lcy = vy;
if (lax != 0)		/* hold X pos'n if glitch */
	{
	g->x = lsx;
	lax--;
	}
if (lay != 0)             /* hold Y pos'n if glitch */
	{
	lay--;
	g->y = lsy;
	}
lsx = g->x;		/* save position for X,Y hold */
lsy = g->y;
/* g->y = x;*/
}
void init_glove(int mode)
{
if (mode == HIRES) Hires();
}
int glove_read(glove_data *glov)
{
getglove(glov);
deglitch(glov);		/* remove spikes and jumps */
dehyst(glov);  		/* add hysteresis to remove LL noise */
return 1;			/* for now */
}
void reset_glove()
{
}
———————— CUT HERE – glovgraf.c ————————- /* Graphics-mode demonstration code for PowerGlove */ /* Written by Dave Stampe, Modified by Bernie Roehl, October 1991 */ #include <dos.h> #include <bios.h> #include <stdio.h> #include <conio.h> #include <graphics.h> #include "glove.h" int gdriver = DETECT; /* for graphics plot and cursor */ int gmode = VGAHI; void main()
{
glove_data glov;		/* glove data */
unsigned unready;       /* number of unsuccessful tries to read glove */
void drawp(), drawthing();
initgraph(&gdriver, &gmode, "");
if (graphresult() < 0) {
	printf("could not initialize graphics\n");
	exit(1);
	}
cleardevice();
restart:
init_glove(HIRES);
while(!kbhit())
	{
	unready = 0; 			/* start polling glove */
	slowdelay();
	while(glove_ready()==0)              /* wait for glove to become ready */
		{
		if (unready++>500) 			 	/* reset mode if dead glove */
			goto restart;
		slowdelay();
		}
	glove_read(&glov);	 	/* read 6 byte packet */
#ifdef DEBUG
	drawp(&glov);  			/* plot x,y positions */
#endif
	drawthing(&glov);  		/* animate glove cursor */
	}
getch();			/* exit when keyboard hit */
reset_glove();
textmode(LASTMODE);
}
static void drawit(glove_data *g) /* draw/erase box cursor */
{
int x = 320+2*(g->x);		/* compute X,Y center */
int y = 240-2*(g->y);
int z = 30+(g->z);		/* size prop. to Z */
rectangle(x-z,y-z,x+z,y+z);
}
static glove_data oldbuf; /* used to store old state for drawing */ static int drawn = 0; /* set if cursor to be erased */ void drawthing(glove_data *g) /* draw square cursor */
{
if(g->keys==2) return;		/* hold down "2" to stop drawing */
if(drawn)			/* erase old box */
	{
	setcolor(0);
	drawit(&oldbuf);
	}
setcolor(15);			/* draw new box */
drawit(g);
drawn = 1;
oldbuf.x = g->x;		/* save pos'n for next erase */
oldbuf.y = g->y;
oldbuf.z = g->z;
}
static int xx = 0; /* plot position */ void drawp(glove_data *g) /* plot X,Y data to test smoothing */
{
if(g->keys==4) 	/* restart at left edge if "4" pressed */
	{
	cleardevice();
	xx=0;
	}
setcolor(0);
line(xx,0,xx,479);
line(xx+1,0,xx+1,479);
setcolor(15);
line(xx,240-2*g->x,xx+1,240-2*g->x);
setcolor(12);
line(xx+1,240-2*g->y,xx+2,240-2*g->y);
xx++;
xx++;
if(xx > 639) xx = 0;
}
—————— CUT HERE – makefile ———————————– glovgraf.exe: glovgraf.obj newglove.obj
tcc glovgraf.obj newglove.obj graphics.lib
glovgraf.obj: glovgraf.c glove.h
tcc -c glovgraf
newglove.obj: newglove.c glove.h
tcc -c newglove
From awilliam@qucis.queensu.ca Mon Oct 21 06:02:03 1991 Received: from QUCDN.QueensU.CA by karazm.math.UH.EDU with SMTP id AA09610
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 09:05:49 -0500
Received: from qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP V2R1) with TCP;
 Mon, 21 Oct 91 10:02:20 EDT
Received: from qusuna.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.1)
id AA25180; Mon, 21 Oct 91 10:02:05 EDT
From: awilliam@qucis.queensu.ca (Andrew Williams) Received: by qusuna.qucis.queensu.ca (4.1/SMI-4.0-qc1.1)
id AA20349; Mon, 21 Oct 91 10:02:03 EDT
Date: Mon, 21 Oct 91 10:02:03 EDT Message-Id: 9110211402.AA20349@qusuna.qucis.queensu.ca To: glove-list@karazm.math.uh.edu Subject: Ok.. what am I doing wrong??
I have the glove.. I have the software.. whereas everyone else seems to 
complain about not gatting great resolution.. I can't get the darn thing to work at all! A few questions:
Does the glove have to be in a particular mode before the HiRes Init 
sequence is transmitted??
Is there any sort of indicators as to which way to adjust the timing??
Anyone thought of making a dart game based on this thing??
Any help appreciated.. Andrew Williams ps. I'm not really as incompetant as this makes me appear. (at least I don't
  think I am!)
From DTANNER%SJSUVM1.BITNET@CORNELLC.cit.cornell.edu Mon Oct 21 00:04:31 1991 Received: from CORNELLC.CIT.CORNELL.EDU by karazm.math.UH.EDU with SMTP id AA09707
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 09:08:57 -0500
Message-Id: 199110211408.AA09707@karazm.math.UH.EDU Received: from SJSUVM1.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP V2R1)
 with BSMTP id 1724; Mon, 21 Oct 91 10:06:09 EDT
Received: from SJSUVM1 (DTANNER) by SJSUVM1.BITNET (Mailer R2.07) with BSMTP id 5659; Mon, 21 Oct 91 07:04:40 PDT Date: Mon, 21 Oct 91 07:04:31 PDT From: Don Tanner DTANNER@SJSUVM1.bitnet Subject: unsub To: glove-list@karazm.math.uh.edu From leh@manatee.cis.ufl.edu Mon Oct 21 07:10:23 1991 Received: from manatee.cis.ufl.edu by karazm.math.UH.EDU with SMTP id AA09894
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 10:14:32 -0500
Received: from localhost by manatee.cis.ufl.edu (5.61ufl/4.12)
id AA08250; Mon, 21 Oct 91 11:10:25 -0400
Message-Id: 9110211510.AA08250@manatee.cis.ufl.edu To: glove-list@karazm.math.uh.edu Subject: Amiga JOYMOUSE port :( Date: Mon, 21 Oct 91 11:10:23 EDT From: leh@manatee.cis.ufl.edu The problem with the large capacitors on two of the three output pins on each JOY/MOUSE port has proven insurmountable. Use the parallel port instead (as Alan Bland mab@druwy.att.com has already done.) Les From page%popeye.nosc.mil@nosc.mil Mon Oct 21 01:24:21 1991 Received: from trout.nosc.mil by karazm.math.UH.EDU with SMTP id AA10107
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 10:31:58 -0500
Received: from popeye.nosc.mil by trout.nosc.mil (5.59/1.27)
id AA07138; Mon, 21 Oct 91 08:27:53 PDT
Received: by popeye.nosc.mil.four.four.four (4.0/SMI-4.0)
id AA01637; Mon, 21 Oct 91 08:24:21 PDT
Date: Mon, 21 Oct 91 08:24:21 PDT From: page@popeye.nosc.mil (Ward C. Page) Message-Id: 9110211524.AA01637@popeye.nosc.mil.four.four.four To: glove-list@karazm.math.uh.edu Subject: Please unsubscribe me Please unsubscribe me from the glove list. Thanks. Ward Page Naval Ocean Systems Center San Diego page@cod.nosc.mil From texsun!sunbird!tellab5!sunJe!menelli@Moxie.Hou.TX.US Mon Oct 21 04:59:22 1991 Received: from Menudo.UH.EDU by karazm.math.UH.EDU with SMTP id AA11476
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 13:18:28 -0500
Received: from Moxie.Hou.TX.US by Menudo.UH.EDU with UUCP id AA14925
(5.65c+/IDA-1.4.4 for karazm.math.uh.edu!glove-list); Mon, 21 Oct 1991 13:14:23 -0500
Received: by moxie.hou.tx.us (Smail3.1.19)
id <m0kZ3cj-0002xDC@moxie.hou.tx.us>; Mon, 21 Oct 91 12:41 CDT
Received: from sunbird.Central.Sun.COM by texsun.Central.Sun.COM (4.1/SMI-4.1)
id AA13973; Mon, 21 Oct 91 12:24:31 CDT
Received: from tellab5.UUCP by sunbird.Central.Sun.COM (4.1/SMI-4.1-900117)
id AA10756; Mon, 21 Oct 91 12:24:29 CDT
Received: from sunJe.TELLABS.COM
by tellab5.tellabs.com (4.1/smail2.5/10-21-91)
id AA11234; Mon, 21 Oct 91 11:14:59 CDT
Received: by sunJe.TELLABS.COM (4.0/4.7)
id AA00375; Mon, 21 Oct 91 09:59:22 CDT
Date: Mon, 21 Oct 91 09:59:22 CDT From: texsun!sunJe!menelli@Moxie.Hou.TX.US (Ron Menelli) Message-Id: 9110211459.AA00375@sunJe.TELLABS.COM To: glove-list@karazm.math.uh.edu Subject: 68HC11 Hi-Res in the works With the large amount of code being produced for various platforms, it seems that the microcontroller based approach is no longer being considered… Even so, I have come up with a port of the various IBM PG driver sources (mostly Dave Stampe's code) for the MC68HC11. It works well, but I have not yet added the deglitching/hysterisis code, nor have I done any major fine tuning of the code. It does, however, drive the glove correctly and output the data packet over the serial port at 9600 baud (can be changed to a higher baud rate depending on clock frequency and internal configuration). Taking my cue from the AGE box, there is both a continuous mode that outputs the 6 bytes preceded by an A0 (for lack of any better indicator), and a request mode that produces the most recent set of 6 bytes on demand. As I've noted previously, the code has not had its performance analyzed to any great degree, but I think with some work this could help us out by freeing up more precious CPU time. A minimum setup wouldn't even really cost that much- I just bought an MC68HC811E2P, a version of the HC11 with 2k of EEPROM (more than enough room for the code), for $16.61. The only other major component needed is an RS-232 level shifter for a couple of dollars. So, is anyone interested in this? If so, I'll post the code for everyone to play with - BTW, this does run on the Motorola 68HC11 evaluation board, which some people on this list have indicated they own. Please send me any comments and suggestions, Ron Menelli menelli@tellabs.com From dirish@math.utah.edu Mon Oct 21 06:48:40 1991 Received: from math.utah.edu (csc-sun.math.utah.edu) by karazm.math.UH.EDU with SMTP id AA11683
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 13:52:49 -0500
Received: from alfred.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server)
id AA15934; Mon, 21 Oct 91 12:48:41 MDT
Received: by alfred.math.utah.edu (5.57/Ultrix3.0-C)
id AA24967; Mon, 21 Oct 91 12:48:40 -0600
Date: Mon, 21 Oct 91 12:48:40 -0600 From: dirish@math.utah.edu Message-Id: 9110211848.AA24967@alfred.math.utah.edu To: glove-list@karazm.math.uh.edu Subject: RE: 68HC11 Hi-Res in the works I tried to respond directly to Ron Menelli, but the mail message bounced, so I will let you all in on my thoughts about micro-controllers. I am interested in the microcontroller based approach, but not in assembly code at the moment. Also, I was planning on using a 6502 computer that I already have handy. However, I could be convinced to switch fairly easily. Mainly I would request that people working on micro-controllers keep us up to date on what they are doing. In the near future, I am probably going to be changing hardware platforms and may need a serial interface. In the mean time, I would like to know what the response over the serial line is like. I was thinking of connecting to my micro-controller via the printer port for speed's sake. Dudley Irish Dudley Irish / dirish@math.utah.edu / Manager Computer Operations Center for Scientific Computing, Dept of Mathematics, University of Utah The views expressed in this message do not reflect the views of the Dept of Mathematics, the University of Utah, or the State of Utah. From totty@flute.cs.uiuc.edu Mon Oct 21 09:41:39 1991 Received: from a.cs.uiuc.edu by karazm.math.UH.EDU with SMTP id AA12172
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Mon, 21 Oct 1991 14:45:48 -0500
Received: from flute.cs.uiuc.edu by a.cs.uiuc.edu with SMTP id AA17089
(5.64+/IDA-1.3.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 91 14:41:41 -0500
Received: by flute.cs.uiuc.edu (4.1/9.7)
id AA01248; Mon, 21 Oct 91 14:41:39 CDT
Date: Mon, 21 Oct 91 14:41:39 CDT From: totty@flute.cs.uiuc.edu (Brian Totty) Message-Id: 9110211941.AA01248@flute.cs.uiuc.edu To: glove-list@karazm.math.uh.edu Subject: I Very Much Would Like A Hardware Solution!
There has been lots of excitement about the new Hires code for the
ST/PC that has been posted.  People asked if a hardware solution is
still desirable...
YES!
I personally would much prefer a hardware solution.  I want to
hook the glove up via a serial port to a variety of workstations.
I don't want to have to try to write precise timing UN*X device
drivers for the glove.  The ideal hardware solution would have a
low part count, easily accesible parts, be reliable and relatively
low cost.  Greg Newby has put some time in thinking about glove
"boxes".  Last I heard he was dealing with some legal stuff.  We
were talking about fabbing some PC boards & possibly releasing a kit.
I am still very much interested in this approach.
By the way, how is the newsgroup idea progressing.  There has been
quite a barrage of mail recently, so I'd love to see this thing turned
into a newsgroup.
  1. – Bri
 /                       Brian Totty             o o
/__  __  o     Department of Computer Science     o  
/ / / / 1304 W. Springfield Ave \_/ "We have corn in // / / Urbana, IL 61801 Massachusetts too!" totty@cs.uiuc.edu From broehl@sunee.waterloo.edu Mon Oct 21 13:30:44 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA13247 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Mon, 21 Oct 1991 16:35:17 -0500 Received: by sunee.waterloo.edu id <AA08954>; Mon, 21 Oct 91 17:30:45 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110212130.AA08954@sunee.waterloo.edu Subject: Automatic calibration of delay loops To: glove-list@karazm.math.uh.edu Date: Mon, 21 Oct 91 17:30:44 EDT X-Mailer: ELM [version 2.3 PL11] Below is a modified version of the source, which does automatic calibration of the delay loops. It should work without change on any machine regardless of clock speed. (No more N and D – yay!) The D2BITS and D2BYTES values are now in microseconds. I've also adopted the suggestion that was made about including a function as a second parameter to init_glove(), though I currently don't do anything with it. My next step will be to look at reading the glove under timer interrupts. (Everything below is on sunee.waterloo.edu in pub/glove) ——— glove.h ————- /* GLOVE DATA SPECIFICATIONS The glove_data array has been simplified. These are its functions: x = X position, 3mm per number y = Y position, 3mm per number z = distance, 14mm per number rot = wrist twist. 0 is up 1 is slightly CW, 5 is down, 11 is slightly CCW. About 30 to 40 degrees per count. Note: exact scaling of all above change with distance! Closer is higher res. fingers = packed 2-bit values, 0 is open, 3 is (tight) fist: Bit format: TtIiMmRr for Thumb, Index, Middle, and Ring fingers. keys: $FF or $80 is no key. Responds with 0 to 9 for keys "0" thru "9" $82 = START, $83 = SEL, $0A = "A", $0B = "B", 0 is "Center" Up,down,left,right are $0D,$0E,$0C,$0F respectively. */ typedef struct glove_data { signed char x,y,z,rot,fingers,keys; } glove_data; /* prototypes */ void Hires (void); /* puts glove in hires mode */ void getglove (glove_data *); /* get data packet from glove */ int glove_ready(void); /* returns 0 if not ready */ int init_glove(int mode, void (*function)()); /* returns actual mode used */ int read_glove(glove_data *glov); /* reads glove data, with de-glitching */ void reset_glove(void); /* release the glove */ void udelay(unsigned microseconds); /* delay for a number of microseconds */ /* Modes passed to init_glove() */ #define LORES 0 #define HIRES 1 /* End of glove.h */ ———– newglove.c ————- / Originally "power.c" © manfredo 9/91 (manfredo@opal.cs.tu-berlin.de) Developed on an ATARI 1040ST with TC 1.1 using a logic analyzer to get the correct timings. / /* ported to PC compatibles by Greg Alt 10/91 galt@peruvian.utah.edu or galt@es.dsd.com / /* Substantially rewritten by Dave Stampe © 1991: PWRFILT.C No cash, no warranty, no flames. This stuff works great, so gimme credit. Goals <achieved> were: Higher speed, smaller code. Polled operation is now possible. Graphics test (VGA) Noise reduction added, gets rid of 99.5% of noise with NO DELAY! This runs on a 486/25 with an i/o card. Someone should adapt it for the usual printer port adapter. It was compiled with Turbo C++ 2.0 but will probably work on any Turbo C directly. MSC will need library calls checked. dstamp@watserv1.uwaterloo.ca 17/10/91 / /* Re-converted to use printer port by Dave Stampe and Bernie Roehl. October 18, 1991. I also split off Dave's graphics code into a separate file, and put some of the stuff that was shared between the two into glove.h I also added a little judicious whitespace here and there to enhance readability, and made a whole bunch of globals static. I also added init_glove(mode) and glove_read(glov), the latter of which calls getglove(glov), deglitch(glov) and dehyst(glov). –Bernie, October 18-19 1991 / /* More changes: init_glove() now auto-calibrates. A new function (available outside of this module) called "udelay" delays for a certain number of micro- seconds. Calls to fdelay have been replaced by udelay(), and the D2BITS and D2BYTES values are now in microseconds. init_glove() now takes an additional parameter, a pointer to a function (currently unused). –Bernie Roehl, October 21 1991 */ #include <stdio.h> #include <stdlib.h> #include <dos.h> #include <bios.h> #include "glove.h" #define PC_PRINTER 1 /* use the PC Printer port for i/o */ #define D2BITS 3 /* microseconds */ #define D2BYTES 96 /* microseconds */ #ifdef PC_PRINTER #define INPORT 0x379 /* i/o port addresses */ #define OUTPORT 0x378 /* bits from parallel port */ #define GDATA 0x10 /* PG data in */ #define GLATCH 0x02 /* PG latch out */ #define GCLOCK 0x01 /* PG clock out */ #define GCLOLAT 0x03 /* clock + latch */ #define SHIFTVAL 4 /* shift data right 4 bits */ #endif #ifdef DSTAMPE /* stuff from here down to #else is i/o card-specific */ #define INPORT 0x2A0 /* i/o port addresses */ #define OUTPORT 0x2A0 /* bits for i/o ports */ #define GDATA 0x01 /* PG data in */ #define GLATCH 0x02 /* PG latch out */ #define GCLOCK 0x01 /* PG clock out */ #define GCLOLAT 0x03 /* clock + latch */ #define SHIFTVAL 0 /* don't shift */ #endif static void fdelay(unsigned long val) { while (val–); } static unsigned long microfactor = 0L; /* usec/iteration times 91 */ void udelay(unsigned microseconds) { /* we do the divide here for precision */ fdelay((microseconds * microfactor) / 91);
}
void slowdelay()
{
udelay(4000);
}
/* defines for output line pair control */ #define C0L0() outportb(OUTPORT, 0) /* clock 0 latch 0 */ #define C0L1() outportb(OUTPORT, GLATCH) /* clock 0 latch 1 */ #define C1L0() outportb(OUTPORT, GCLOCK) /* clock 1 latch 0 */ #define C1L1() outportb(OUTPORT, GCLOLAT) /* clock 1 latch 1 */ static unsigned char getbyte () /* read a byte from glove <rolled code> */
{
register int i;
register unsigned char x = 0;
  
C1L0 ();	    		/* generate a reset (latch) pulse */
C1L1 ();
udelay(D2BITS);    		/* hold for 3 us */
C1L0 ();
for(i = 0; i < 8; i++)
	{
	x = (x << 1) + ((inportb(INPORT) & GDATA) >> SHIFTVAL); 
	C0L0 ();
	C1L0 ();  /* pulse */
	}
return(x);  /* return the byte */
}
void getglove(buf) /* read 6 byte data packet */
glove_data *buf;
{
register unsigned char *bp = (unsigned char *) buf;
register int i;
for (i = 0; i < 6; ++i) {
	*bp++ = getbyte ();	/* read data */
	udelay(D2BYTES);
	}
/* throwaways (speeds up polling later) */
getbyte ();	
udelay(D2BYTES);
getbyte ();
}
int glove_ready() /* returns 1 if glove ready, 0 otherwise */
{
return (getbyte() == 0xA0) ? 1 : 0;
}
/* HIRES ENTRY CODES byte: 1- any value between $05 and $31 2- only $C1 and $81 work OK 3- no effect 4- no effect 5- no effect 6- only $FF works 7- seems to affect read rate slightly, 1 fastest */ static int hires_code[7] = { 0x06, 0xC1, 0x08, 0x00, 0x02, 0xFF, 0x01 }; void Hires () /* enter HIRES mode <rolled code- speed unimportant> */
{
int i,j,k;
	      /* dummy read 4 bits from glove:  */
C1L0 (); C1L1 ();    /* generate a reset (latch) pulse */
udelay(D2BITS);
C1L0 ();
udelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
udelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
udelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
udelay(D2BITS);
C0L0 (); C1L0 ();    /* pulse clock */
	 /* handshake for command code? */
C1L0 ();
udelay(7212);   /* 7212 us delay */
C1L1 ();
udelay(2260);   /* 2260 us delay */
for (i = 0; i < 7; i++)   /* send 7 bytes */
	{
	k=hires_code[i];
	for (j = 0; j < 8; j++)     /* 8 bits per byte, MSB first */
		{
		if (k & 0x80) 
			{
			C1L1(); 
			C0L1();
			C1L1();
			}
		else
			{
			C1L0(); 
			C0L0();
			C1L0();
			}
		k = k<<1;
		udelay(D2BITS);
		}
	udelay(D2BYTES);
	}
udelay(892);    /* 892 us delay (end of 7. byte) */
C1L0 ();         /* drop the reset line */
udelay(100000);   /* some time for the glove controller to relax */
udelay(100000);
}
#define XHYST 2 /* hysterisis for X, Y low noise reduction */ #define YHYST 2 /* 2 eliminates +/-3 quanta of noise */ #define XACC 8 /* X, Y maximum accel/decel level. Should */ #define YACC 8 /* be 6-10, but too high limits gesturing */ #define XXTEND 2 /* stretches deglitching time */ #define YXTEND 1 static int ox = -1000; /* last x,y for hysterisis */ static int oy = -1000; static void dehyst(glove_data *g) /* hysterisis deglitch (low noise removal) */
{
int x = g->x;
int y = g->y;
if(g->keys==0) ox = oy = 0;	/* handle recentering ("0"key or "Center") */
if(x-ox>XHYST) ox = x-XHYST;	/* X hysterisis */
if(ox-x>XHYST) ox = x+XHYST;
if(y-oy>YHYST) oy = y-YHYST;	/* Y hysterisis */
if(oy-y>YHYST) oy = y+YHYST;
g->x = ox;			/* replace present X,Y data */
g->y = oy;
}
static int x1 = 0; /* delayed 1 sample (for smoothed velocity test) */ static int y1 = 0; static int x2 = 0; /* delayed 2 samples */ static int y2 = 0; static int lx = 0; /* last good X,Y speed */ static int ly = 0; static int lax = 0; /* bad data "stretch" counter */ static int lay = 0; static int lsx = 0; /* X,Y "hold" values to replace bad data */ static int lsy = 0; static int lcx = 0; /* last X,Y speed for accel. calc. */ static int lcy = 0; static void deglitch(glove_data *g) {
int vx, vy;
int x = g->x;
int y = g->y;
if(g->keys == 0)		/* reset on recentering ("0" or "Center" key) */
	{
	x1 = x2 = y1 = y2 = 0;
	lx = ly = lax = lay = 0;
	lsx = lsy = lcx = lcy = 0;
	}
vx = x-((x1+x2)>>1);		/* smoothed velocity */
vy = y-((y1+y2)>>1);
x2 = x1;			/* update last values */
x1 = g->x;
y2 = y1;
y1 = g->y;
if (abs(lcx-vx) > XACC) lax = XXTEND;	/* check for extreme acceleration */
if (lax == 0) lx = vx;                   /* save only good velocity        */
lcx = vx;                              /* save velocity for next accel.  */
if (abs(lcy-vy) > YACC) lay = YXTEND;	/* same deal for Y accel. */
if (lay == 0) ly=vy;
lcy = vy;
if (lax != 0)		/* hold X pos'n if glitch */
	{
	g->x = lsx;
	lax--;
	}
if (lay != 0)             /* hold Y pos'n if glitch */
	{
	lay--;
	g->y = lsy;
	}
lsx = g->x;		/* save position for X,Y hold */
lsy = g->y;
/* g->y = x;*/
}
static void (*upcall)() = NULL; int init_glove(int mode, void (*function)(
5)
KD@8* I,J7<J4 MI4 8/:'*@"$#!X@Z.6%0E+'5:, E.K@T*7($2I D3JAP@7*$2I(F1V+$< %E M"M.[>>-6KT1<B126/8L '"H$(W9T"0-,-70=*I2B'36>EF#ILP=,H8%5@C M!HRD-W!\GC,F#!O-CO-^1DD',^K-,694%3A5-@BA6V[+MOKY<XO:,D!\U@E# M=A>C>T",J2-'3ADW=,R(+ /B+QD0SL.005,&C^$TB$' >0,'1!^C:2!*-&JD MO?OW\./+GT^_OOW#9HQ((.1C@@ MA!)6R!^%%F98'X8:=@@_R]A_>=5MU5N7)S[XN\U/PSSBY@W5M ]^3P+=TJ\X%&R[V:>N?> M#PFU[UF00,E_VV.O;X.UH9<W(7/>_1BY9>GIO;)M→YA?#<.R>&X'D=G\DB< MO.#0-OQ*/M_)8FP<!&=\%=S),;DXN>\L^(_+1!P\A2M?!1#!$:#./6L]CL@. M1!,.'S XE5OAP1WU@DO,.)\/]5K_0WR$YB2:R(>?@0!L-#W!+?84I\B1\Q M)G;B4+P2/W$I'L6;.!6_XE8\BR]Q(AZ$D7@1]^$KV8@783'^PSOLE.7#1QB, MG_%#_,6]>!='XXQ8B1OB1/S&V7@=I^-=F(EO<3GNB+'X'I_B6GR.ZW%!SL7S M>"'OPW@<D0_R/DXB6+%]FP_)V(_7V$I%POV#=O3%0F<?^UEQ/)"02QG'KY<C M LH<,9D"ETC9⇒.'3<I:0Q4<84MYX#7 0KR-7LQ57H.Q8:EXY6Q9DD]@_KCU M-/GG)8LY1W34\CD1RAVX)[_CKN[DF?)$+B>+^8'PY9S<8BI<7 [-!^UG⇒8Q M%"CWIVA^S.LU V;CV'SCP/)AZ<J[>3\DXR50E%]9+5S.(\\C!^*I_'/?BVHN M@B-EA%CFN929<RQ>WH+I^08FCNJSF?AS"<PK4IL\7XQ'O,B*/7RNRVMD.!<0 M_)?IC",LP= 3^A)^Z%!4\$ZI=M[)UZL1QNB;YYT+.XZ^<W^Y/B^$B+(O#O/? MB" JNC6WX\B4GZ/$@6Z(&)]C\E,T)*12U0+<&)_Y*U_I-RLX'M1/H8X",A M&\NP(9:*4JO&;^6,:NEQW/;AX-PGV/1&/-2^Y="E(W/0"=+[ SE%&,MOU<*6 MJTX@H;HYQ\"@7*:O\O0]!'&P0\6%!)D'1O#G'A>#HWZ],\2R3 →AI3099 MO^>X_"[&<NPWRXDA-[<2,=L]T+\%"-<GZ@.^Y6==6P-R$M'5W2–%^RWT*LJ M0%+XUX/Y^P#JH-<6+8K+GL_K[NTH@M&CLT,RK=[0&69E[XO5&_01P348/;C$ M*S-5+X*U6_3K^MK7>CW'/:(*M:]:G5:=089NIY* KK<;=B_+9\_7'H0>(&*N MUS'03MA3NF\O[8A=5/D-8VD$57M C^QYW:ZW0/8GFZ'3(NQ+C!T7;G*\WM&Q M.Q\_$:\]19!V5I[90V']&^Z$,IM'9/+JU!6(.C?DYP,9OG7U/OA$NK":[R]] MV"EWGAC$ ;" MR;*T+M+]@,/X#'Q@D?H=1VX:\,U6#]RGZ8MR( =O/_V#7OA M8Z&!S^Y=JZ#Z4STAX=E[25».ASK_7>GG2<\<1!2 &1R-&2R"<NI/N)1^?C M'4$A>,P.S!L$0Z?N)(X7#O76_DN-/%-'Y4$= KKX,+ZZ?_R+I^N??%B6^+2+ MW GFA'?G6!Y@E<@M+W4S_+#S\:=<O!_&&9_@Y?"_NU=D_)XDM.Y]7$G*_S M8T+O#AVUM4';_"%/XU >T*OY+ _D4>M@K_!5_(\G>D+^WMOXH*?R@3ZJ+WI& MKNB9/W](K\STMZ3"_H87JF;_1;'=1?^D!.Z1G]9#?UDSZ)G_I2S^I5?:IW M])Z^TY_TW;[(73VGW_1-?,C3>%'_Z5=]F5_CLWZ,-W6T'N.%?:3OX<»UFMZ M9/_H@7VMA_7!GM />^ :ZW%]I2?UMA[;0WM105-C1⇒%[7"WL&?[:Y]?@:\1 MN9,,_IQ7PU#OZ[=]K<6>#;[0$WLCWF?A(@1"\MJ>W3N(>A]GQ>RSU_>W7K:O MI5*#[\D]JE\2W82 < A=3]^K/;-G=D,@UFJ9T5Q^KWRO?_4 7\&R#6:++8 MKU_N,!X=&OMF;^B57,5%'O13E7_\=4[>8KN\I_8)XN"R%:%('U^^RY_V ?[C MSOQ97O /?KX_AMRDB4)N6$&";WZR'_F#XNDB;3"*U3.^P6_UYU7IR].F>?$# MOK)_PZSW[S+]←CG6?ZRO_JV3WSU$E$C; @&Q*# AWW<^_RB+?:_1VC@4&4_ MT S"G@_UD>GQ933)UZ73?;5?]U4$7?T3Y)=_K+U#7_5_/K5C^$0>YWMTLXGV MHRW)G_?2-007_J?/]RL_ZPC3\5[Q9_ZCSQ]8</I!\()NM[,PSZ<[GAE_7_ M8=^S]_JP_NV3K-7_^G/_BK_^_/_;>_^)?_YG_\4W_] MS_Z-/^\W^O_?XJ?YH7\#8/.G_95\-I\ R/EY=?R!G9>IX'D0H)EPYT6 %& E MHAU5<WO(!+B+.7(<H*,BC-%B8 (Q1LG]8NR"\F?,D7^RG_#VKP%JHE_ME_^Q M9&@;YH:%\&P+H/V' EY),6"N8J?Y;=-?_]?]C4@R6EC&OO& D%\-B !6"O/* MD^:OP6=$H$9G!!:!18H*R 1F;,S=$]C[H5A2H S8UYA]XP;:UP*6?^*;ZR:V M+364&ESE_OF -J!5E@-.,[#:5K;_X7\]H 9DGC5KIYL)^,^]@=D?]1/&H&OF M6]FV^06 ?Z"H<*+T:_#;$$@%JGM6( !X-F6!1-DXEP &@CX8(TBNT6V/( $8 MZ4F"(MI",_S=@6C@$9CX]&\LA.^&FFV"7U[\E_V)+L037>6+B&;$DWS4J=EE M2IH=V/ =@%"@6=*;G0V>S1 0G/%CBQF%4Z8U@HH@+7@%BE$O&V(!6_ 72QHG M,KL5@GV@0&;F@7]PX">$T]P59@5 0@F&@=)-\G:P)8.FW^KG KY<1MO$]C-P M,2,;P($)]FH&'>7T LX(#9I-,PUR,&K@ +<"]F=' C=X T:##XZ05E$\:,?& M.;@^G&FDX!?XZ05KDQJ89OT$@=H@0*A:R8(C'I1'$*YJ>LP-Q0M^+$K@+S@) M&H#08![8(#R$W5JE-I[X@[!;R%< +G]% D?H\=D-R@RQ!1+6@;-@1@C_Y0@F MH<@%IO6#?IKBM@TR;^I@'-B.I&KCS$G(;\6#V&!"^+8L;O>?1DA<M6S[(,4& M%-9O2Z#30 ?>A/.?_Q>%(84HFA)Q=#&%! L?. ^B-)K<B, 0FG0N(5(8U>"" M7%2KIFD0;%,@5_C-=5D_H$LHU:4U?$/2UG:I,BLA5%@% H*6()O20NP475O8 M\+6]3W5A]N;OU7^>()\@4V0,4]1<H43D;?/9!^?!37 C' WW'D@Y.1=_)Q4J M*8_;C*$*YC;QUSKX$DI_WV!H" :*AM6?3@@:CH:H86GXW8&%#=AEZ!:ZAK)" MS0=L!8.O85M(&-:"PB!M>!L.@_>@4=@;?H91H6U8% *'GB']-QP:A[\A<H@' M$H>F87"8!L:&?EY,1Q(2?OP?GU &AG;/X&ZH&QZ'L"%W*!PFA]TA>/@=+H?* M82>(&]:&SZ$IR!R2AM6A-Y@:MH>GH6KX'N*#70\I*!LF@@J@=)3O6(+'407H M)G2#\2%\.!N*A$,30?(5BGG,7W7G]=TZA6'Z)Q\^B K."7CL-(11D(!8'!)Z M!^)NM" F/?FA]Q<>.H@FDWL'X1!T(Z$V)QU:'F[5^S<8>H?I8?]@(EY164)1 MINZLAP/B71@;67S^3X:(".*%+=\U."%"@BHB?6@A#BLZXGJ4^,ERXZ%Y2.T5 MB143@*@@4H@>8I(8)$9@:5^-Z B6B CB/N?_I(B%G4 X)+(OCE]\!%=YB4*B MAW,?9CE=H:# )-J(N:&6N.OI0'V2P+ FKHCB(7U@TPU$5I6;P>.A)FNB\Y$M M'(ADHL"G2]5+2-WS@Z.8/#XB K,6HH<90ECGI<55U2UQ)9%9]&Z-?U)8H0 MG_>3##D_CAU*]R(:B8L2G4@>2H6.XEOGUW6*;&&R52!V/7,B:_C>[76FHJ38 M&HJ* =5YV"JVA/4?K'C?-78?7@#3@K1W9V \]R$JB0%>![39=7>HXEAE\@ . M)>!V6"?&?+,=@<?BH8J845I$*YJ)!"*/&"'$0'J"<%?DH'NI(L#")8*($B*Q M>"[E0=ZBM#@IDH@:8H1(_+&(#>*NX=QQ=M1BRV/EA4J9SJW()OI^>= [1"_V MBO;BFU@_883B7GFH'I940P[_D-[)BO="G\@N/HGGH78HU8T,_B(H$M>MBWT/ M%SAF$8SPXK[WX($_!L)5)RQFC')?L.@>=EJ:!I%Q5T1X]>+(:"*.BRI?H)AD MA0VRRC;4X3&,X>*9*":"7C*CP>@7[E)ZD':!9KE9V,,XY!5&B2VBG717>1!J M@T!$0] 0!5&%*#!F2I_BNC<?^H;AD<.8'8I\0*+$V#4>=.G2M>A(A8EMXM<X M*ZX*^$R,N"]ZC7FAA*#\C0COE-HH-@:(92*':#+69A2)OK@U/HLG8G2H'_5^ M>N.&."K>-UV"!E@!OF#E8M+@'_([#^#BZ!\:CC['0-<S#HL'(^5X,GZ)5R.- M""'6C9HCYGCQ!827HI-X(4J)&%[U%CC>B]IBU8@?FHV#8]+H',:+C&+$V#'R MAJTC[,@V<HQ\(^UH+K*.NV/;6#;ZCK&C[E@YIHF>8N[H+-:.)A[96"UBC;TC M[H@\"H^7(^=H,$:/S&/E2#K2C=4C]=@Y2H^6(_:X/6:/WN/T&#YVCZ^C[&@\ MEHY'HM0(/I:/T".,P"PF&W;@Y'@]LH_'8_,X'19[Y./HZ#KJC[;C[%@_6H_[ M8W/(/YJ/S^/_J#V*C_1CA_@[.H_0H>#H(MZ/E2 #:1V6C'MC :E !H\&Y/@X M/PZ0[6,"R3L"D/WC^?A!'I#YHP!I0K*'W.,&>4)FC@@D!YE!>I /B7VXORV0 M$&3?)$,FCB2D"HE"KH\NY 5Y.]:0JR/P^$.JCJECED@=II !Y [Y/2Z1+>0* MN3GRD$ZDYRA%2GJ@XXS81**0R%^3<#KJC#0D$8DTAI 6Y BI02:1+&0)J41> MD66D#IE&DI%/)!-I1JZ18*3]Z$5VD48D_JA&GG^GW!;I-X:10J2%$">"B5$D M$AE'@I $I!Q91T:00&01N2@.D8<DEKA(^H\^)"0I1L*0$F0.R49.D5#D&?E& MMI$.0D#46.4+LT;P)%U\)5;($U05<49W(R49SO 8:A7Q%=QP%]D$N\)2S X@ MSQFU9^T-J.,7J=ZD4#W5^F)_G1]L%##)>;13(DI9EQ,B<^'$]S![,&)$P%/A M2QQ:]%:QQ3$!-#!C+DG')9,E%T#51^8.B.$(L4I@*_>+I)6+R C5Y-1(2&*3 MRV2V^&V4%ZJ#6V'82)/+"9J%.*Z-DN048D15%!%/:1%/>7R?!#_Y[-A ^Y0. M-D=BD B"B_%/+1]"5-" I)TV[*08T1&B(Q]$#241#FN621L19< -@ HUC2N M$&W>!"@ Y%A!'005P@&=S<J$I6"#C %^&5^!#U!–G!H(1>E8[V1'*4J?B M*U(#?!$]EU%!/-!G<T.#@48((XL#(R%#_(0XY!A9\LT–U7O<%*EB+3/.<%/ MNI/B5.#R1UA/B@3)E4@0#\$%2(%3"93#A@3 025:4C"24F#8AA,QG0K%MI MH& #5?:3&E<F05:D%^+%S_!#996KRB:Q4IX50P9'<Q5.DNM@4/!'<&T!"9>E M3K(N#>7WL%:24A8%6EE1S)4Y!#E!GP%>O41>B4$ C-LD'_GV]1(,R$Q1B$ , M@LI:>5C>$Q"%00'D4%SFE]_P*I$2YQ1>V7"%!N#BCJA+)@ZSU".A@0@7T%:@ MT5G.E)^EXG =)A:VD-N@Q6P,=85CB=.L#L-$+S59II(])'D36NR%O(1BJ( - M"H7E)S%7M)7X!&&B,E(4HJ1,(5Q>5-F%9&D#R8]CEM6UA)@@D<Q(T4WZ5"P$ M.!E-+%WD VPQ7+8'?<AY<;>]EZ"$=UDE:I*07E01T# A( S2Q[55'P 4@#E0 M2)7Y!7VI5<B7-M745U(4EP.%8$E(MH\@A;W223P01A5?R;4)DR8#AIE4[2KX MA%IR2X54 X47P5%Y)9"EVR=9L@U%WPQ9&P82(X,D$C2856&> PF1L!#9A#U1 M8YH86%5;M8"=&**$VS!Y0%,YAHC95BJ89L-G,U!TAH7D@YF)F1#(D^&!6!D! MF @7Z2&(D@1$(Y%4[%5]U8TG+;T9,4 70DLP#DPFKV5"9!GOGIWA0CT.)27? M14<^DB)D96E(LIE\9"5I5":9EN0@66?2F7-F!YE<NIE*9B399LJ9)V4C&40" MFGLFH1E(9I)P))X9:,*9;^9825#RE8>F&WE'8I*2YB4I2"J:A68B^5J^D)GF M0,E(,II])J2)7UJ:B"8GN4E2FFBDJ3EI7IIZ9J29:J*:IR:KR6FZFK%FJ0EK MKIJVIJSI9\:9FN::Z6A^FK]F/6EHCIIV9IXY:Q*;F":MB6M6FL7FHAEL_IF] MYJ/)9]Z9K2:R66TFFM>FJDEJ,IO)IK5Y;&*;WZ:VV6QVFH*F(OEL\IJ>IK 9 M;0*;RB.[Z02:F^VFNIEN0IOS)KI9;FZ:NV:C&6_2F_>FK[EOVIN@)K49;MZ: MV^:KJ6N*FN!FOAEJ3IO&IL(I<#J<#2?"*6YVFPFGQ$EPCIO*9L%9:W*;V>;% M27%.G!WGP<EP.IO_IK[Y;N*;%J?(.6Q6G",GN1EP1IPM9\:)<7J;$"?)>7+Z MFS>GM+ER@IP#I\JY;LJ;_:;.^7/RFR^GS?DPHIPQYZ@Y D: D*/C.!TUG4XG MO0-U1IUXRM2I'8UPVI'52742'8WCUEGG:9U>I\\!=OJ'6&>;,':&G6S"V8EV M.H!KY]?9=;:=:X*. U[.G"SGSNEQAIRY9M[)<?:<>J?!V7=NG'[GWEESNISG MILEY=.*<AZ?066\:GJXEXMEX*IY!I[N9>$J>CR?EZ2H2G87GPFEW^IR+I^8Y M= *<F>?#F7+^G<MFX&EZ IZH9^F9>FJ<JF?KR7J^GG0GSSEXRIP?Y]W)=PJ> MHR?NF736G9\GXWEY@IXEI^?9>8J>NZ?LF7N>GJYG[&E[SIXTY_&Y>BJ?G&?D M"706G81G\$E\;IZD)^Q9>T:?U.>/0":HG7#G]_EVTGGSI(QY?2)WB)\U&38B ME[1G[Y=^FI,KDXII>0Z6UQWRJ2R]BYBG]1G2.9\V4SFI*L*;@0=0YW_>E[SG M_HDK\GI$T=SI,,"?QJ:YHX#Z/^_G'EDHL9_-9V69?LH;D4;H:%*^@%DD,S$W M68;)IXA'?UY. ZCHV'[N&Q4D%@<S/J">':8XZW5!+"BT$8."BBFH\"EH1J B MX@+6/P0K5^*@V7L"B[!F"O0I^#!6).I)//X(] CYAC<"GSEGAA!_5'*X4VBV MTYB26-9] %A>4\9"\N$4G9_#YP(Z#=HLQ8LV.3XX""74,,&7B!-$ @H""EF- M3>*7U3!"16=C&PI-H MCVK>PV6E0XN3=D&8F#9Z?Y"!WKC_($X8C4((AC<++ M<#E8&V!%\5@KQJ%ZC1+:[TTHFYVY5S@P))-43J0O!%IZA 2Q3'9>"D@ABDI. M7S(;(UH*,:*%&91@JHR+N9UD(8DR&6(HIF6)TE*8*&\Y0G03G&AO(8<&0PS. M+I0S[HRAS0?#TO&B26<D.F.FDV.HIG$53EJ7"6*QB5(/N0:'@B'0#B#/PL#^ M9*&*RRBJU E:OZ<X]UN@#?*B67-*1&S&EM<58M .M$B]<#9$:%3?(AHPPB!( M@R="+YRB/2B?)%FT$E-&T(!FF@VO!,<6-N0V[5-H&0/(#1ME$C4KR!#(TY7I M1:05:86MY5K8C.X!,@)1 B,5I0_EAKP,NX*@(XUB=^VH-9J.8J,$*)659,13 M) 989D2=$3YA/())C!5L!,#U1?"4GT@*P4FT$NX75=FML1%=!>^P*W@C@I0[ ML4U,I!X3N4CY2'D#8Y?UCC8=)6CRF -XE2@?PW5H11'^ ^N50*5\=PAG47%Y M/U2ED.4 U?Q'<ACGH/H 1 (F34:N>HQX2 (3DSAN%1NN@I=<@0$<DH&4U% M#^%5E*4>I;NU47(@E,H-!#V]I04#U8 G/#E(9ODY*QV+CT3NXV$*4TTI-)% M099F!6A3195+'(-BZ-⇐"N[(5OH6Z2,2B?L0EM9'N\._Y,:$#EM;5!(KS1._ MF>M 0:@9,P#7QIDRE_T(51*&]$\516E*>723*8O_8%15$%3DIOA90%7891QR M:$4DB"F$1VG 7#_% B1%."5E!4TZ7;0E*EH#$H5<IL_"GQ UB"KH90&EEVHL M@DUG,]A $W3(<!IK@#"O$*S0.MQ WQ-"(;A,IZBI;*G[;)['8GI1!/A<D\A. M\?B$E1C)IM(X8"I8PZOD-$ 4Y1(HEF0L3\6!<2I<, \>R4QA4U 9E^EMM'U< M+E<02SF)U@^A2BNAO$U3;%03)4"4HB%&1=JBL H,283:4M8L?L- U5_2DT:> M;2I6L*<YU)"VFP(2.<3K4%X$EY:%^C!4Y!4AAD_!K2% KH6QT),(%WI6Y76+ M/CR9 H.309JZGY8EWP5/;$-+5>K"T%6F/TG8HE1*JWDJO(*E;#:JJ72* > MZ<JHDA !M$F)^CW89U,I(/%.UA99J9JQFXY"56F(D0/HJ/XIS;AMW*B[@U-! M@_*HD0>V,BD J9[I0$*G>CKII;RR7I \\XI*M*1BJ",,M$*>CAI2ZJ/(+*2G M1 8L40/H@G&EB0I0N'U@%!@A7XY>BU<#$C>D%(I(8TI467P+Q5/B6C"GG4^/ M"IW^J$5#D(J[]0YW:N9 !&@3>RJI:J[XJ1?J/9*K"*H:"YX:T$"ISL)UZ#=8 M%W!&(/I?S$\;JJ]Z64BJ?$7/]=2H$5D)]!"S-2+)*#'QXITE8(GR1E2\#'^" MJ$K*C"EZRDMUJY(\NUB3FEYZ&*WJH7!BO*IN2(NRFG:K@XU+H;8-JE'JR+"+ M?5> Z3?1J[H1&0S6X$?0%WS#Z_53:!G%JA! J=87BJ'XXM<I#FL$Y@=;3$]- M"5:2EH"8(-1D5*VF#@N"G-I2\E0+ZL[EK:8>#$:X.K&20(RJFK.:)C;)BBE5 ML[2K<QN>"9BF$ZM*9WC,U*0=1AURF:RG.(:.$9LHAC$ JX!K!12#21O1J&!1 M"1<W0<+E)=!$"E9#X*;N Q':R>DQV4Z3\3U1K(="W.A&&::C"_955Q8-?2K[ M,*YMJS5(R/K_X*JQZI63+3RA[P25 :V 8E0&7;5GL*+W:3/Q,(&9;@1?LF?E M #.$7C6:;AG]J,N6B4(0=U)C4IELF4<$#M&Z54)(ZZ@:JM"I%>MV&JA:#1KK M]Z0$DD!_JJQ*J&ZM@:F:,]/(GWYD]XEH="3)3R"RAM9'@>NUBJLRK22/)WJK M)"N>3JWVN=Y$)TF0>E)HK: .U[JM@I+L1Z:Q,^R5Y:551"]LKO#&G)JTFB^$ M:]/*TY2N#VJ*)JWNA=9+U1-*,:DCA-*@O-:J[\.-4I0&=AWIPA4$(0W!B9]% MD?*IN^O@6JH6#+XK]LI&R1;^DW5JGA:O'-Y.4YY2K3O-\GJTU#"=PU[XO/HJ MN()!%2N,,=6K>8*.CJ-):P7S18&NF,-I*IJ:(H"$::J,QB%)Q=@E60"J=\P[ M<5:XK@24) HDXJ"Y D\'6RI; P0/RO2D"5/JRG*BC*M8ZZ=@EGH9>.)TD>08 M'@U+ #8H8A9/UEU*55DM0^I ]#.TEI;K98=V7!P%WA)J)89WNF33A1\9HD62 MHHA_ I\!J ;JW@V@R1\B:8#BL(E< JHNZ)993 L16A/6PVJHCBG:H5!&N" MSCTC:-]HN2)Z%^B7DH'*C6HF--B!/DC1*_<9>NIW7>C3]+XRH$8GCBAEMF$K MJ!!;"OX(&N,Q&<5*G_GG/3>#[JCQ*-)YREFQ/RR5R G:H"_GD,=R&*WT%?0Y M&6Z=X&?X^7/H*7ZI]DG%VI^*K.Z)?5JR/R@7BL<RH9/G]'G&MK%2K":[Q1J? MQ>?RR7]*LK<G);M]9I^5K"H[R3Z?JRPFF\96GTVH)ZM_@K)9;![;R>JRE:<M M6\ORLJ$LS'G)NK*I+"S[RH:@QRPJRWP6H)NL[YG+<K*]+##[S#JS%"@S.\J: MLJ6L&7O+TK*[+#0;S.*RU2PI.\P:L\4L,EO.*K.G;"M+SBZSXFPF*\RZL^!L M#2K*?K+<;#3KS4ZSA"P]>X*RL]CL.&O.\K/:["][SX:S_2P\6\]^LP<M/CO/ M;K/[;#H;RQ*S "TK^]"NLPYM,JO._K,5[3E[T:*SV:Q$:]%.M!AM1RO+-K/Y M+$-;@?JS'"U*N]&NM"!M2FO0-K0B[<@W9'FT&FU+VVQ*H@YL^NC'OK3XI8/Y M/RBT[^PL"]-VHY_1'EK&TK01[4@[,6ZAS:4<R\8FM 3MC-!X*0"V0TX;T':S MU*Q3D_!5M?%L&#M_5F417R$Q\1$?849(J]+:M!3GQE<O.5OBJ#Y[TO*TV*;, M%TD1M8/L0BO0FIQR+9%9BNRQ9^U'RR#,'TU4U'58)(A"[5OKX&FJ-$4O,?1E M=EFM5^O+2F!27XG9BKJTA:TU6WA&MF"45=O'.IX([:&9]:%=;6UG:]B2M,0G MZU5Y71:2*%\+U[:S^%3;YWJ))>B#:EO9LK9B5-WP)R1?_I9F2]M>LU=MW?'W M&1%I:PT7R0*U7>UFNX9%H+(M:7L:MHK)+6\KT4I^?6U-Z]=*MY>?/=O8&K=? MK7S03C6W;JUE:])ZMW=M21O>VK58K7A;WI*WUJUY6_'(<)PM<0O55I!(YGOK MV$JS42V3R-U^M\:G%^C4!K+JK6C[(<FS();U$&K]@.0.^T7=5J$NZ"#6<;UP MRFWY&G[UH0=HI7"6 K(1+I,%.(@X;^R!@&2QF-@MA,5KN5!XQ0^57%Y:#56& MJR'$HI>7FK7?-K%N*C:AV[JWP-9 *OSL#LX&BNO?4;CFI\V53X&-(&K),"M$ M#Q'K9#LG)%I5A!=CQ0(/Y(7^]=2.B2-;?*#CI)AWT:AEY(*WG6@^I4JMN [/ MMJ4V=%M!U.6*'(I;NE:Y]5S2J-.M$XI3$%-S4K[%2X0@]^0=.]_B3@&71D%6 M4$+X$3MAX%:.*Y==8>/6M2Q;QH55/EM\;AG&3LQ3!6T9-4%1/B47L@D%R! ME".Q9PF$@^Z+V^,NCQB4%5%T35J*[HDK8BA=JI<.^@3&7H"$CO$V+41VH]U' M3?P25L:=!.5B7,82>UI5%6##+8S;D1 -6<:!J=-FKBE3+S5W?7BHZ)[P>,V% M&XE9*SW!%&'5!KKMZ;J+%T=:2?ZZE%9,"R/D'E2$A%$$J(+Z5>B5[.*14>T\ MNC&@7C>)K$OEIK?%"%_1>WTEB(BNA'%P7YR71:$_W+?CK=LH[D(/U]?G@+ N MN1D"]V5[]1IW SR3RU'0G?,#]-$R <406%Y@DT!6#9?7F5BE7LM=/.MJ?D MOE<W[#<#6*T%PQXP8VETP7Z9L$/M8I1N=4)<XYFXQN((3&P3:R,<>?W&;'0I M('A""5*;T2:U129+BY8XN\(NPYL\-"?+10J6[2JUW:V%X-,FN#?+NHOELKOG M;5#;X,JW'2Y]"^ 6M]X;%$O90G:?'<F!\SP/0"^XVR8==Y21^IG=OKG7[:3; MWWJ[NVW.6^@.O1FOS*ORPKQ+KW.+\^*W7Z_9"]&NO&POV7L_\;?HK7^+,U&] MF0^\%?)2J7'O,TOWVCU1K]R;]GJ]O:W?&_C^:D@LY*GV4K0B*.IP+?2]7._? MBS[2;;O"JEOT#K1'KZT7^7:]:._@>_/*M.WMYML][KVFS=,;]H*]FB3HRW=) MOECOUNOYQKRDOE9OT[>. KYC;W2K\4Z^^5WRV_9*O]6?N M;\S#ZIV=L[7\TPPC?Z'6$3B$-,4:Y.OXEO680\P\U/L^+,_0@RSO-_\5A. MS\ECQ$PU8T9SW^BQ/%^Q>5SWG!2.$#HJLEROX6CXAW+'<@S.+6#T4 3L#K]E M!@-_0*\WVZL0RL4GYS/?:#_CSW>%_GS\I(T,XND<)>W.2%\ K<U&#Q!&&L+/ MK X80N[,.K>;#/0LZT#SRXON3V*9_A?NH'T,YLFP(D,&3?W:<HNSH=Q4$7T? M]/:!'*5[QG.!G$)71GB3S^PR,\ZV5?2P(;?/K6E?9#P#+:4N]@PY4\X*-'6G M0\<:/#0/33U;SJ%B>X0VMPJHK\Q[1.-K$[0/71@]SDVT79:*;-#)9?0P]/V6 M_\7B(7091/MR5F1";X=<M,+\.P\D^%K+AH:ZSUJS DW]GM$[<^6\ZDX<'2H- M=,>XT59T GTC,]$],L.</4],,[0,72D<I8);H_J?]M#%\[Q,1[_!]ESEK ;/ M6%C#JJ*E=J8BM#4,O;[,1U&0AT.31I]QS^>@9I9NR&$(/D/!%)[G7 '#0C)B M F$Z_]'>'T^QY3X91 0"U*A(&3YT>/)(AW%I-,C<?F#.)'0#%O(N"KTT!]TU M M,OY"[M-⇒P)-@7:$'?T.BRO:C?2G-R]"?-/C[3#QB2J]9-TOB0)(T^S[ZY M,ZHA/V]0]*+"KXS38TDF@W -#0M,5\0+/#U3,/I)@HTQUB,1W^CC<Q=,1( M3R.T]K30_!PBTW#M/LU-?Z(?L]2\2:-O@#0@*3DWO_Q0-2TQ[YG8=&G6SFS3 MWW1##4L3QF+S04U-MM/]G1,=.J;-433S[(5&'F[S$'+W>BC]M"]]'XB?<5[0 M00.$"<Q1U#D!ZGF.K/C)J("4-?7\ZR9TL1"=1EWU(LR#M,U<1X^^N>\]79?( MKN;TODLX@WE,6D6M4B_3?#,J#6]=T/BR"AU56[=4M5&M-!/5_G1A>%(#S54U M0[T8RP_7\U/–(^*^;31'%*?U>ZT6-U6O\5OM35-DL2^2C7)7%"SS0,0%KTT M6]6N+QI[*635RJ_NVU6#M("U$UPPF\Q:]5 M1%O-135+FS*CT(&T2$W\;M6K M(⇒[5D/2??7X;%<CUFJTOWSHZ-5"M6'M.P,)4S-7'35/UCMBR^Q-:]:!=6(M M6N.+%W78O%>[U:IO4,V&GM:'M61=PO5.?T*X7.1UO'*U:2TP:PCQ;<?$/$FP MF,_RM+>RUI[U8$U<TXG>DZ*8P3[4PC5E?:%8I(P&8V'??8+8JM+;60N1T6AV MO>;JQ,704.'_ZL&"]7?K^FC7Y+5[9UX'S;BU,3O@JCS4Z!5SD$)S0'7B'"%\ MN#V4B/N;Y%#%QY@9>/28#6]"3?GJURU"B\M"U"(F0MPX5&S(&-? %6"C2J8" MU)M4K\TM0LPV2PBYI0;1\%X/V%Y$!5%TP1CY]0F=7R6Y]J N@I7F:_;<G,'" M"0'14CBI,[_6Z6&2*SYD+"+K4-&'CE7K*8J9F\+7PS4GR4[LH1E+"8* ++[] MPC^Z;D6EH[5N[3O;N3Z(TPISM1+=\M6P9)M+3G9Z'61+"(.N4;L^2-DB"'+R MF1Y:5#:"?573V!I"I&NK(52(KI)[DUS96'8T'5HWOA8#J)M*\+A+B'7Z8?M1 M%1=PZF97UXHU@A5[Q50I=MT#H5$>78B_U!]?V3+V]VM;KX]=%9M1['8/=]6) MT67<(3:;J_"]0A=QPA<R9S/7,"^T*^U2NWT.X'=BI&(/4\3T!N]44@:F737? MU;EULC9$;R-'U'WZB%39LW98#5?7UF9V9OUHH]9H]JO-60O;6;9K36='O[!V MD]U8$]O+]E*=;&O9UO7G'&P[VW,/78UA,]O.=7H%6I_9QS:PW6W'VMEV:_U= M,];A=G,=7T/;@;:T_6TKV^6V,>UND]OGMK$-:L/;6[99S5=[3MLVLCUL4]LD M;;Y-;T?;G_:O#6['V^/VLRUO"]SL-L&-;2O<_':SO5D7VP7WOOUP.]SB]L)= M;^O;$+?%?3U^CVM#UQ"\T,KL1=<3?<[79.PW!_W"?WR,UYE(6R-:#M<:O< MC6*N/5OOVHZV9"+IVMNT=<W=X=[</*;>Y M_];V?>?G?)?7F3W$DWX"U[W]XH]]JM=H?>M7?N/7OCW<,W[(UY$]^\-\S] M>K?>4G?O#7Q[V\SW[NUZZ]ZV]_1=?$??U7?SK7Q3W\)W\KU\K]X'=^<M>@_4 M5W?I/7D_WN?WO>UY4][K-_H→M/>T#?X'7MGW]*W]OU]B]_!M^_→LO?Q[?Q MC7OKW^'WZ5U^D]\NMM?,/?;/?SG8 CX+\W [Y_X]_Q-P3^]FY28_>[0&CD M<&,3H3&(SM]4AP.[@?N7KI*73=KZ(,TTU(U+ @T5.$;]@2N[3O *#HRJW_@@ MO\>E(([D0BW*@A/@!G)*=S,\H#*XQ?%)D1PV.+:+65<(0?B?P>XZ6I!&OU64 MD"
6)
+C.>SNM[T8-A\];C]* Q%.\F)DBK/-%7>.?1 MBC0?;=:#\A/X^C#+HR93?;],V&NI: U<'R\\];%=5]_A-O;1?#%J24MJY^D; MO=!7>I;]-XW98_+LX @3.MPQB@5?/U;[G0T]PC#:(_95B 4X2Y^AN#26@4O? MSO2\(]W-D_:C?&R]U@>:VWSCL3E_*<MSB4WU5ASA'#L?0+CS9WRXP"CHTKO] MT_3:'_(2$F6?2(;VC/-T_](;<M9]XHS⇒_6/"T1OQW;WO[TPW3%/]0_H4Z]- MY\W4=4CDVV_T:G<X'3]OTS(];>1XA_0E?6(/L?;TG+Q;[E?#TT9]=-^':?=Y M/$5%WD^>WWUY3^ ;\9O>@;]Y6_;DPH+?\S7F+?7C.'Y"@#3UTWGA.YUAQIW2 MR$Y'0>P*/\;7\7)Y9A_$P^!;/!9?XA?X<OV*K^*?^,+\$D_7+^8Q_AV_?E MV[V,G^/;^ Q^BD_&F_B]O!I?T,/X2#P=W]R[^#\^BP_D"_DM/I'OU^/Q+WZ0 MG\9/^=1]DA_E,_E+/I6_QROY7/Z5K^7K\6#^D"_E5_DDOI-_X^OX*+XM7^,W M\>T]CI_F0_E6?IQ?YH_Y6[Z73^8?^69^CZ_F%_DX/%4/EMOY=;Z<C^?3^6%^ MDT_HB_E8?I<OZ/OY=/F,+\,K^G-^H@_H%_I9_IW/Z-/X?+Z;O^;[^)'^EX_H M>_J&OJ2_Z#OZ4_R.S^:7]T;^I?_H3_J?OJ5/ZH_X@[ZHW^F[^J8^IQ_K@_J5 M?J _Z^OZMSZM_^;_^:-^K;_G/_G _JY/Z4/ZO3ZOK^J7^K]^HR_LP_G&?JNO M[+_Z;CRUW\=/^\]^L9_L'_NL?JB/ZR/[RSZL'^Y7^]F^L]_L8_K$OKF_Z0_[ M9SZ/3\2;WM:^'5_NH_OM_JF?WVO[X_ZUS^T'^^?^JL_OK_O0_K8O[>_[T;ZW M[^L#_/A^O(_D%_RY/L$O\!O\V'Z_S^PC_.I^IO_7:W!XA+. R$Z&U7C#/_!S M0#O0MU»\" <C7[X,I.Z_HP%06"B[X/5[QI_O;7P_>O(Z;1;B\R+#?]\*\ MS-\NSOLU/XWZXN+\%G_WTX\#])W\C!F'V_Q%?\"?[^-3GU:Z!]M':FZ=L14; M=]T1_\8@\8WAM)84@N.ZX32,&IXZ9).H\\<?\QU?QE+']U;@H N"'ZZ3.KD= M?YN/YI]XA'C(-1#B9R;IN^?O,_S9J"0N][.SECA !96?_#"_(@O8BN("?M*/ MG![:J/A[( /\X"+^PJR<SN+G5M"/J@$2'TDF8C)<%D!_X&_R#>.2;0:,*VCC MF@;7?43:^CG?7D*,-PG,/3>ZVRCCVB0ZWN<K_#V"-][YEY,<@CG>^O_J\K[$ M#USIXQD#V0?_O>/V.-*?^U/\KB/O992#>O02Z0DY?@/NS_;"_DR!?8 %G5 M&[.K1+Z7\*7'I9ZO]#O_DMO#$_@)X4\_T$"2/R;/UMF0^=?[=COZ_\V#]]O_ MO)_8[LO,A'E.YA1GNIS_YLL_2\?2R<]=R;QVABV17EHPQ-89TXKD!<]"<SO"75'0+_BJ2^#I M[]2 1+\$SV30,+BK^V3TZMR!];M4H)_L=V.G2P=^^V!<H\&YV+/N'A$+?)'! M[GB!?ZF$X%50#CAL@]?U!!$+XKI8ADR0?J<9%*O!!1T:Z["Y8"CB6]<5! YV M@]J"1$&47L,.*:@GD"H9L?H#OD$$F=]J*@42'-)-!1=VFT$$GO2B&A@*G+'U MN=8(WXRF$?=@8U=M2PSV@F)W-4'.8+C"&Q@7U/0]0U9V,C+ZC'AJ-OBT*<WH M!:F"W$"AQ3EP'GBY._%! ←=2;*IU*$EH] >)-K) O=D%$%X(-+.)H@._ R. M "%FPX(O&9&#.W>&<LCE':"#6KL#R'$0/$/N> 6ZH$"$8\&UWHBP%2@=! 12 MUU"$9SO2&/JN0KB^&E5=!QMK(,*1H/DN0#@C-(@A[HP5J;]C8.T-<M«PPWV M!<UBE3NU'9"0](<%C DJ9H2"#K+4X)%P<E$,\PPN"96"?\ <@>\DU64N^^ Y MRV8X%[P0%L"BA,>?0N&⇒YAECB$D!Z[M#%'/,^/<_6YPX3\%4!XP*W@TLP"F M 7. 7, WX%GP]4<*7 (V">N!04 XX)N0-_@:#!3N">V#=T(_89\02XCJLWSL M[O) PD ZH9(" 5@I:P:Z !6%8,!#7PUP4P@$) ,:"O> @\(_(:=P#9@H9!3> M^_2$H,(B8)Z0#Y@J_ *> 4&#J A*(=M. 6@%_&4U ,←#T!)8=AO5&@/_!1F M"9F$BT)-8:?P0M@KQ)J%@'1I8H(;8190,>'@<_PD^ Z%;[\W5K/0'Y?@,Q&B MSZ:%\+TU3R5I!4C':K:I]SH.)C1J 0PP=O4GE.\M*^A[NL)KX CM5.C#XNDI M!X6%J;-_D'7B61@LE/5I1+"%V2%ZH9"P "B!PA>V^2!\Z<*BT+008(#6"QBV MF3YY7+/"7T7P3<4K!/]E"[51XK-'X<4OA!))F (*L:J Y[3 2RQ/L5<K;!C2 MS4YYRA5]H:!054C?\1>ZU42&UD*3DLD0E=?:,Q@.CLA[.8-=6LK0?"([$\!X M8K!Y<0;<7DZ/4"A-8P.&"MUOY(-#0?#L?U'.:^GU]7Z%[4)TAWL!_< FS!; M\YPHT3/)GL8+NL?>LP,B#8T]*T&Z01JBGZ<\>,Z #-\X(D-VX9MPGU= J\\D MX_IHM9]JH<LP2M#1"Z$):;1ZH4&3&49O;;CFZ.@-:3YZ<,.(X:TO7$@W7.) MT%9Z5;3#GL\PB/:YF1F>YX!Z5[W 85Q/8JC?6Z?U#>=,B,-^A%!OL:44 ?!! M.\*&GY%@H(=@J9<X+.M915:&%S/,X4)F59(UC%?HJ+)Z:$-$$\#P76A?NPGJ M,&YZ1L/5WEE/83@R=!4^0]IZ;33/X6>OP.<Z,QP*C/)ZKT,CB&IO75@J%/F8 M'GR'=[U52T!#2V786QPN#*49LKR.833OL⇒/B.P-#U,V7T-]B>BP4>CZJJ1Y MV#A[E#C/WA*MCX,R5!+("LM86←<Q6FO66!* ^FETFI-+<,X8'*IPZ%0RE;1 M]MQ25(;'36W/>9B5DQD^#H%[V4.QH2=M5?@SS!2F#@6(;J..!_+P>5BE:A=0 M#4EZ][]ZH9@'=#@IV1X^# N(5B\*XF]/;8@[R:FQG80.BAX*WTF.D;7AFXYD M^.@\'[ZV'_>P6G8F: $R!%E>XT+KD*AP6,@S7!82$$F&T$(7X0I1AXA 1 /> M$&V'Q4-[80WQ"BA!M!/^$'V(M4,D8@[1WL<X?#XY 0\4!\)+(;G-8N@[P!C& M_X: @T,@XA$15N@I["(2"WV%.T0FXKX0BQA$+!1Z$8>(@,(SX@R15+A%Q!,F M$;F((T"FX8JK37A%[ +NJ"@ZKH54C$\! '@OFA.R#J]FY@.^02J&»)_62#& M"5⇒V 7RB[="O;1&+!9^$1E^/H7XDJJJXF([,"1F_O )F2G&PFE0>LA&?",B M,"@U]S.LQ7<L2V9#]"1B"JT\B(,(&BSCCH(H;".>$FEN@0W.U(H'BP#BDDB9 M$1^)N$2J7BRQVZ%6PBFPW%R)IL(FHK +<2"/L!HDI39L:HH1\PC&CJPE\% M-% I&+L7HAMQB7@_$;RQP)Z)%Y667P31@'A+S#],$6Z&0L→PBTE@S=-;!4J M$46#TK^^0_<*E4*I"R:.$>V(P;760IU*BU)1("=2$_F%5\/GDSR1T>"<TGWP M\[B)1D13(KEMGYA+F"2.5"X'ED1E(F7'.!:YRE.-' AMB[T>(AP1C9B=:6J= ME6P*(15B%VZJB'=/)",&3)(GX8_VU+%$KC+M4B$F#Z.%9<2 8D<1G@A,A!<Z M$BF*-,1&(AA1HEA.S">B"FV*K$*<(@8QBWA.U"GB$,V)$T69HAJQB%A*7"G> M%)F)^$2DHD=1H.A2G"D*$W.*2D66(E-1B"A4S"56%6&*G42C(E21IOA*3"D6 M%8&*-<6HXE&1J^A.;!&*$<V*P$* XE?1IZA%G"IV$Z^*<$6B(A%1K3A7?!6& M%<F*3<6A(ETQC6A5E"OR%;&*+\6XXE[18]A7'"S&%/V*A$7 HE/QG3A6?"KN M%+V*=46>8E 1L7A8-"QF%<&*7<66(E61LGA99"OV%,6*6T7'XD_1LSA9M"P& M%CF+IT73XF(1K9A4Q"MN%E6+>D6[8F;1K:A2Q"R6%2^(HT70XF-1L_A61"VN M%G&+5[PJ"VN1[;:"&"4!%WV(*9<C 5E%66A1D7B4E>J(.0(J N"@,B-5)"L9 M6>X&_A..XJ"%Q'6Y(B72%NLY/;^W6S2IL3AKXRX>JVZ+@:SP8B^AT199)/:= M6OH&GSK7HDCM"==8Z)#B6+GJZ#7G!*J_A=Z\+5%[]4\L4[GY:K7Z)EZ'*1 MJ1A?7#^O7S !>? *5'--4/035KAKUZZP\S-'R$F9#5B"UP3[XH1QQY'G B:0 M#V8&?,3.XM>!$==(Z0J:%'6+MB*WTKZ%4A52\2X&&"E$?3]:E(:QK;@G)+I0 M%-0'_ZC:HL2,%2>14"C,&!.+I#[C$M<%W7-TD1_=XGQQ*2[WH6@1]X;L0G3Q MHI);H+\,(X#QI/B%:S+^JP($)T8:8I0QF)"BDB9R+/@*1@'12Z\H4K@U,,?Q M!4$)[$6VW/SOW953..<M%3D>P#^H7,8 PI96K,ZQ&6,3/K:J86K1ZJ7\4WC5 M%K*+G\6^F_NE< !_T;G(0;Y %[F)'$3AN?A75/@%8#00213)00-%H0A$ 760 M_]PM&P0J1(GM!/)'Q,;A%V>+3#4((.O#R^AOD,% %T4M"Z53(^S(U*A=')7P M_\: 9K:47VD1'_?W>S/:%O.*A479(GJ1@9A;?#&V%WF+.D84(XWQUOA:U#7B M&A6+]T7(8J/1MYAL!#:N%86-@<8E8[21L1A:I#;N%K^+OT9LX[(1MIAK_#3N M&@^)H$9B8V^1VXAL[#8J&X&,S$9SH[,QV\A?[#5*&V>-4J9!H".P$"@)C 2B MO^Z-GA@Z@P?1PU="9!-\YG8Q'R#+W"@&4,'^(L50G7*%2(;A(+K"6!>UJ?_L M!GDW(ANSV*Z07 <8;-OAOAZ.U)F3G3R03QB/&0=N N=D4[R'XVUN*R0?)"\" M*_!WOKI1UT<-I1(+RPEB;SQB[$;MS65P4,>H6S<:-#".-J&"&+E1ZP4C[-\= M%R-).$>AD$W,VAC+ZCF22"**HCVS8!4,,%/>L2/1Z-R# PT=H7M,X!1T' -9 MZ!@W RWP''G0.O=[JSHJH:8R\YU#5A5#39-RA#<R8U!W)$>)H[L,((@+6YYT MY\1<$0BC(\AQSP@9:==<JR".,,=)7_%"7@<1E,]E2^2.#<=VXXK$Z]@,PM;8 M'+L?!#H! D^I(E9(NY#5A"1E^!["8]IQXPAN!+3\+[X9'+H$@X?N30=UC-.U MQY".5,:<V +'?_,GBY$P!9N#2+I:PW!P,>AS'&I)'@L:HK"D71/G]"A)23W> M.@@R/T+BH+2*]59U)-4H:9Z"F3?:XY&.2W=[W,A,[R"$-<=M8Z/$:I&+&CV6 M'*5?L<%=0XGP2 !XW#T*%NL/KT<MD.R1X1=]1( 1HPRG<>AH/<.VEA/4SKF M'/..OD:Z8$\H;C#U.PQN;,*/44*0">CQH99]!#OR&JN)Q3&Y6&50UN8=I-TP M'*V/=:+Z8UW#.Y-FC*YT'V5C_,?7W96BXLAU]+L)(&U5IQO@X_#I -D14CV: M.)1B8L&IHQU/Y%@5,P11"-59OL&F("]A*]$9/#[>!JETZ,:-25[J2KAT1#\N M^4*0S<$1)'EFYOAQ##R>&P<=#\@8&"XQ._A'X#NZ;^"/F4$ Y/T1C69^%#KV M"(F.]:ZM8$E!/5A18 \6*Q2.=)H"#N$G!^FH:3J.+/"#N0_]8->F^%BVPUQ( M'5N/QB8JI'/F"*F&^=GMA8)VX @+9!=RZXB"3,"]'B\W%D'4D(9P:N=V[!"F MYJ""-S'PW>.Q#5EL7-^A'=-"ST=XH^R@^A@84S>"/>R.@<'SX]"1[KB_(42" MC8(E8L@(9 =&F>B(?)L!*"*1<<B?XRD+1?AY%,)@(M$8::- 7NB1\]B%S KQ M9$9@)ZU(9.SQ PEK/!-Z\%)XH;\T89GE6X;!@_-IRVZ1T+*,WRQR7&;"6V1) MCBB-K41M8PK2V-B'O$&*&-./PTAOX['Q^JB,+$8>'BN+Q,AQ8S0RV(B,A$8V M(Z61UTAJY+OQKKB-##>2%KF12,AIXW"QNBANU$:&(P61S\AC9#?RVYA0[#0^ M&ZN1ZLAS)#AR'&ERU$1Z(\F/\TA[)#L2&(E23$<R(OV1O\519&MQ';F,3#>6 M&P^2S$ACY#]2&&F-5$@*^B(Y@L=@W'%DTNB.A)CU#LY_38IV)'ZO3MCF LR M%W-.&D1\I"4(^3>03,BM#'L^),F"I,2/LC<Y2DD:(B.2X\-I9/7-)2F2-!!N MTO)KR+^98>Q+%$F/#!O5H4B-TZ&09#92%D*3[$?&PP*(^\@;$5.K)&E6Q!:V M@(J2#<DV(BY/ 065!$CB_9A?]ZVJ9.51)4D\%$AB \B"\0V(4\R\_ I0%*Y M"8M 0LERI A&*UEM!)J%)*D[;,EWY*>B9JB!N!FB@LA6LD-G)(,O+KES/*L% M#8TVPK.B80XBD3>#XDOV)*%/3T/HV?="B4;WZGO1)&=09,,9F=2PO<"/%&09 M/BJ3&)=N1!KB;0B_VNH9)7,''DFQ4KPE=4! JZ14]#1IRT14AV%RUXAA=!JL M]#B374EWXZQM-=EL9.7\#76'C$FDI$,2X4:;_$8RG"*'833=X?NP+VE -$Q. MCH"3DCUC'&L')QG%DFUQ#B6'PLF=)%"2U0&MPTQ*KWP7233B&6H29C:]<G-Q M''$')P747G9R,*F;U$L6OGJ3RD?5!.[0HQ><C$W>(Z]8Z,FAI/((>)@[A$ZZ M)P.2O,;XI%?2C$0]O!NV)[>35LEMGU92 =6?K"A8#Z=G)*^*I .D)DGH\Q[J MT1(+X4/567DR&/D-,4NJ&C$NZL-(1B&ARTB>]$Q>&RTC^DGS9A%U.)H*7M M#_6'K:"WI,LP1(F0S/8=^,A$+$IXY)6/,&F=U$A1$3]QK[QZC6/2.[F5%2 M>#"2S@Z-Y'!2KV-3VS<:'78;.S\VQ0?Q D3KJ?#EU. $(48;@<&Q3$"+,%+F M&VN4MD;?9%(21YFE9%#Z*+V4V,C=Y$M2+1ESU%)R)>63Z4DQ98N2."F3+%." M*<V1ATG99)QRV&BF_%+**/&3/<HP98!R3=FF3%/N*1.2?TJ#)*"2(1F/G%.* M(_619THUY: 2)IF/W$_6(QV5;4E$I9V2(#FIE$>^)RF5>DI"Y4*247FIM%1N M*:6(B<I )9L239F,5%0**D^5HTI39:I25-FG+%6R*DF544E-)9Y22#F=S%1R M*C^5M4HXI:325DFF]%/**FN3M\I0Y:]R3%FGY%46*W65D,H/9:_253FLY%/" M*@N5NTIDY1 2'=FL7%0N*V.5P<I*I:&26IFM-%:^*>62GDIA9;=26IFG)%?2 M*CF)F\IK);0R62FGC%:"*[>5C<II9;RR7/FN=%>Z*>^4P$IU9;KR6%FO9%?2 M*;^5]TI,I;D22TF.Y%<&+,.5VDI[I:]R7-FOE%=V*N&5#TN%);.287FPA%CB M*M&5LTJ"Y:/287FQ/$O^*_&5Q$J Y<)27YFQ5%!.+$F6^4J#Y<A297FR9%EB M*U&6(4N0I;-25=FJ?%FZ+->5'$MQ)<QR9OFJI%D^*_>5(LN69=#29CFTQ%G2 M*RN6$DNBI<S26GFS!%HN+5&5-4NCY;G28WFH]%=6+7.6"4NK);=2W&@].%\A M++-RQ<60W-=2P'CA&CED&>N!/HA:VM%R90F5XQ#,$<Z6/TO6 ;A%N3AGE$!& M*DUJ,JY,#-@ ;JFUC!BH%Q\'4\:SHM/&O)APX<.U5-2+3A0E(]+RKO=>K'+1 MX/Z']$4:0^#2:2E:#+80HA27?4N8EW]Q.:AET5AN([@MP AOB[I+8)E]2S"R MY#A[3TOBI(-QW]+F"EE,+C>,=(,*HQXNN_"?R%66'MQ*%0P/8^&2.VF%HOMY M%$J,^"38)4>BP^AD3"R<+3<9,<98A%N%)Z=BO'3M+N>5,@(>8^*O'S%TPTP* M&7,*V#_,9=.RFG5DQ$ST(Y 3,R@KHZ;EQUBT]+]M&7L)22\NI1CE<+#K6C38 M%]E=YTN^T-C2AFCM0G1!0%Z7;37;'[[.1P";<CK>-ZPNXRY7"OGR,]F6T!/4 MX^2,Z"MXWY&H^@+ORC/J$52(NY(^8W^AH=BE=!(-&O]=Q36@0M:R7)1HO/XM M&N53$4M'Y:-1 *A8P:ND+)F)>JN2W&6BP'B'K%;Z%>5QZDM"&N5R?MG^H6'^ M%3F-,4P5 :OQ%6B4FUI"JGQ0THA7H[KPK"9K+%@FN&J-W\FXY0DS=1FUG&%: M+'66V\LE)NER<8FU]%8R,968,<LIYLJR?%FRS&$J*Z.864P;IM#RBNFS+&/V M+,^8+LQ591JSB=G%!%5N,->68TPM9AQ3C*FTE&/6,>F84DO/Y1>3BRG%Q&,Z M,9.6>4R3Y1WSB?G&]&'Z+]N5F<N.Y87R8VG'#&1Z,1&95<R!I2#3D>G&M&)> M0^2- S#4G+WQ$(AOA%0X*F(Q_48KI00HE$DF^#=:V@2.9"N"8VD.I_/(6AP] MUEIW0,A?4"<RV?.)E&"$(A>93\=2Y +L%'D/2T46(7\9J\A 9"O2\3BPR4"" M(<=XO4>UF?:1%3E6%.!)!8V9J;NB8OPB8E$>DT1"+ZF/-$CQX\Z.:=F,J&4N M(KF9.+EL9OQ1"$G(O#=Y,\F09,PSGR-2%"3$.6<F[5A0$\'_8R$2#>3.+!BH M'1];%,=$G9:,J/: U#C&-)*8JPV/HS93 ^DGY$"V(+^9@36V8QW2Q/!V) BF M8U".J$$;Y#&2E]%RM!$>--&92[Z]XWL.L1"?*QQ."2J14$N11CU3F,G&- ;1 M6UIV;@0>PP]2ETESA-Z5,Q])(\U[9B*3IA&#?%/TPS0)"<AGYG^P63#/]/3$ M-,<V=LNNA_!11G=L&-]](:.98<A?)OOFZEB G,0,-;=T932M8W-LG-G33,R] M(6=BT\'0T%/3*VA:$,SH(<N. \"S(X4#[XC0Y*Q1(&U>SP:0)K32PX"(+ ]> M-+>/7+RS9K=@4P.%=(PQ)2"12LW"(];1A7F SU-6.9EK&99N?II_G/A&,2 M@QR'#$7#X%Z)$SG6E&A^?0B;\D*>9%7AK*G;"MRQ'I&:=2=5I*BNK%GA.6LJ MN;8WN<? )K OF>F!)&E:FF"0+<'OF!J2>Z73_-(E'R>6T\R[XUN3F>EU0VTF MR!XJV,RZIL619]F]@&R6'B^$/,C$(W=P1J+6Y&.>OO*:D\?"9CKS8M<H4 ^N ME)R0 1P3Y%30[#%_5/ A-P&1&HXSA*>%KY"%!")L(4F1(4'_HZX,LPE &FD2 M((.:GB S)$L)/I>&Y$*&-Q=A0<BJIK*MGUD/<D'*?^:0#,TZ9'' 0PC>E&D( M-*F:@K3 HD%3$8G1S$?.:P";^\Q[)45S7N%\E&E2,H]J"$Z[9D@3I7;=7&:: M-LV8:K#B)B SB^7;-#R^-.UD<D<I)(ZEPQD*4M_A,L=A0IFCYMQ1R>3-9&JB M-Y=O*IPNH0O'E:0M(^%AG6QFN,@0WB[R6289$I?Y(I.8&$Z*Y18SG;G&Q&+R M-H6«\P/)Q73L/G@Q%CV,96<0\Y&YA]3L&G)]&.V,6V72TY#YD<RR;GAO'(Z M.<.84$XN)Y53DOG(9&1:.9^<74XTYYBS8<GDG')&,MF<6D[19)3SS GF3'/6 M.⇒<64X])B2SS>GEI%IN+<&81\Z=)3A3RMGG/'%>,[,$$,D@)YER(AGH!'3N M#/F<>D6PI)Z33_+D@3=1C: &6$XG4%K2T2G8B5'".04&*DH)A*=3C;E2?%%B M)D>=8<XE'XTR"HB>S*\U)B>=2DF&(9YS94F9G&0N*.V<C4[JQ::SI'DG"$T" M,8-.NTY<9Q4(U5GHA!BB\Z"8:SUBIZ S ,B2)%BB.N];/S18ISS$S0GIS$NF M.I%].4EI9YI-H)/I]*-=0+2=<)=@Y[(S)J'LS'/VU#R4A<Q80;F3U^E-E'S4 M)?L.=\G]X4;RS]DH7'<*.QMF?TGV66!R,CFA)'*V&UF4-#W-I.Y#GH>@#"!F M)7F4]TZ)7V22:VCMO.]).BN2D4G8I VBTLF1I$X>'LZ'"4^[X?H,'I&;1'>: M.;<4]LX^IE@OE.C1.TW..XV8;)F0)Z<SWG&;M$_^)T^>54ZSXKK3B%;3<WGR M.SV>"4^[8JL3,XF<Y*$I)T]Y.\HDY:Q3KO><?'EV/)M>MDX;Y;6S#&C5LWF> M#BV'Q\YA9K7!UVGI%">%)VL+"KVCI]X0Y7D-47FR.^\N!H(O&BE$ZQGUC'DR MH+R>.<_[$'V2/7GSC!O>.2N"S\['88%RKU?P]'C*MHR3!,NYIVO!Y#FD3'N* M*;.=K$,'I2(-D]8XD$Y^.1>4^;51VBTDBQ%74.CU/=-O]@VT9[Y2EG8_W&VH M+E"4F8A=YS!'\KGR7/,Y)2F-7L\9U%12SPGP!'?N#M&8%,L!I>DS7@@L<GB* M0,*2%$\J 2403& )A#L]6OA8/(*E4Y%R3V$I1*6),D\,:(=69IB@2BG*7'KV E"OH"(X Q 'D@#5 &F ,$!A0#90#&@ )@#H &> /< > $0'4 )B@ end —– End of forwarded messages From dstamp@watserv1.uwaterloo.ca Wed Oct 23 15:44:19 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA28998
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 23 Oct 1991 18:48:28 -0500
Received: by watserv1.uwaterloo.ca
id <AA07249>; Wed, 23 Oct 91 19:44:19 -0400
Date: Wed, 23 Oct 91 19:44:19 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110232344.AA07249@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu A reply to "Gary McTaggart" gmt@reef.cis.ufl.edu
-When objects are moving in the "world", would it be appropriate to only
recalculate the screen coordinates from the bottom up (world coordinates to
screen coordinates) only every X number of frames, depending on the nature
of the movement.
Not a bad idea… of course, you have to keep track of the object's position _somewhere_ in full resolution (in case the user "moves" closer). In effect, you don't update the world database, or flag the object as moved right away. The problem is, (especially if you're using eyephones) that the viewpoint is just as likely to move as the objects. This requires almost all of the objects on the screen to move significantly. It would work fine if the viewpoint doesn't change, though.
-If the movement of the object in the view coordinate system is:
1. a small amount of rotation in on the X or Y axis
2. any amount of rotation along the Z axis
3. any small movement ("small" determined by experimentation)

, could we not treat the object as a 2D image and use the screen
coordinates along with the previous Z view coordinate to approximate where
the object should be?
This is practical in some cases: it depends whether you do partial or full screen updates. Again, I'm not sure if it's always appropriate for VR, because the viewpoint often changes. If the object rotates on _any_ axis, the rendered image will change. Because of aliasing effects, even subpixel motions will affect the image. Whether the preservation of this effect is important, though, I don't know. The 2D image idea isn't too bad for distant objects, though, as it takes BIG changes in the viewpoint or the objects themselves to change them. So, if you have an "outdoor" VR world, it's worth it. "Indoor" worlds with all objects close might not be able to use it, though. This whole idea is a form of partial updating, which can be useful if there is only a few moving objects or the viewpoint is stationary. I haven't started serious work on partial updating yet, because it falls under the area of the graphics front-end that generates drawing lists. I've been concentrating on the renderer because it sets the standards for the rest of the software. It seems that a good VR renderer should also be able to redraw small areas of the screen, which is one form of what you were suggesting. I'm not sure whether keeping individual objects images is a good idea, because small objects can be drawn fairly fast, doing a "cutout" copy is quite expensive on a VGA video system, and close objects that look big tend to move and change a lot. Still, some good ideas to consider, some of which WILL affect the renderer.
I have not actually implemented the idea to test its effectiveness, and
being that I'm new at this sort of thing, this could be a common practice.
Yes– on lowend systems, and in video games. We have to see if it can be fit into a VR system. I'm pretty new to 3D rendering myself, although I have a lot of low-level graphics experience. I'm not too thrilled about programming the world database handler myself, as it's not really my field. And thanks for the input.
My life is Hardware,
my destiny is Software, Dave Stampe
my CPU is Wetware…
Anybody got a SDB I can borrow? dstamp@watserv1.uwaterloo.ca
From timd@twaddle.dell.com Wed Oct 23 12:52:24 1991 Received: from dell1.dell.com by karazm.math.UH.EDU with SMTP id AA29008 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 18:52:59 -0500 Received: from twaddle.dell.com. by dell1.dell.com (4.1/2.1-DELL-G) id AA09199; Wed, 23 Oct 91 18:21:18 CDT Received: by twaddle.dell.com. (4.1/SMI-4.1) id AA23869; Wed, 23 Oct 91 17:52:24 CDT Date: Wed, 23 Oct 91 17:52:24 CDT From: timd@twaddle.dell.com (Tim Deagan) Message-Id: <9110232252.AA23869@twaddle.dell.com.> To: glove-list@karazm.math.uh.edu Subject: mailing list!! PLEASE add me!! timd@twaddle.dell.com I have also been generating a net-list for the glove and would share it. I have the manuals for the COPs-800 (the family of microPs the glove uses) and am pursuing a piggy-back solution to add another COP888 on top of the existing one to get VERY detailed info form the glove. I am trying to get dissassemblers for the COP-800 family and would be glad to share info. thanks, Tim Deagan From dstamp@watserv1.uwaterloo.ca Wed Oct 23 16:16:58 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA29130 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 19:21:12 -0500 Received: by watserv1.uwaterloo.ca id <AA08943>; Wed, 23 Oct 91 20:16:58 -0400 Date: Wed, 23 Oct 91 20:16:58 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110240016.AA08943@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Dave Wargo (dwargo@cs.ucsd.EDU) replies: » »I would be interested to hear descriptions of any homebrew eyephone »projects that have been completed. What diplays are you using? »Monochrome or color? Binocular or monocular? Field of view? »Optics? Are you monitoring the user's head positon? Weight? »I'm trying to get an idea of the level of sophistication that »is currently being used, for use in future postings. » »Please post to the list, as I'm sure others care too! » »- Dave Stampe >I am in the process of trying to put somthing together. I have tryed at >first to use a couple of lcd tvs from radio shack and they just would not >work for what I wanted to do. > >Right now we are trying a couple of sharp displays. I think the real trick >is going to be the optics. This is not a trival task and I would be >interested in hearing what can be done short of spending $800.00 for a pair >of LEEP optics. > >Please pass along what you find out. > >Do you think that this could be the begining of a mail list for >eyephone-list? > >Thanks > >Dave Wargo > What model of the Sharp displays are you using? I recently did a (non-VR) project using the 5" color NTSC/RGB displays (forget the model). What did you pay? I can't seem to find smaller ones for less than $800 (maybe it's my supplier though…) and the really decent 5" models are over $1000. From what I've seem recently, a lot of the newer pocket TV LCD display have crummy resolution– it's cheaper for them to digitally preprocess the image than to use a decent LCD panel, I guess. I guess the LEEP optics cost *is* dropping– last time I talked to Eric Howlett (designer of LEEP systems) they were still $3500 each. Guess he decided the big markup on 6 cheap plastic lenses and a case wasn't helping sales (B_{) or maybe the production volume went up. From what I know of the LEEP optics, though, it would be difficult to add LCD panels, as the display's active areas must actually TOUCH at the center to get a full display. The monchrome LEEP units that I worked with actually had part of the PCB cut away on each display, and bridged with 40 or 50 wires, and the right panel was flipped over. The original NASA design used one 640x240 LCD panel to drive both eyes (not a bad idea, if you can find one that has the right dimensions). As for optics, I think that we should try to stick with single-lens systems. More lenses will either add distortion and chromatic abberation or will reduce the field of view. The LEEP system actually USES the distortion and chromatic effects, and compensates for them at the camera side. The way to get a big FOV is to bring the displays close to the eye. But then the user can't focus properly, so a converging lens must be added. I've checked out these types: - Biconvex: Forget it , the distortion is TOO GREAT (unless you want it…) - Planoconvex: Less distortion. Fits nicely against glasses. - Meniscus: Least distortion, but can interact with glasses. - Aspherical prescription lenses: These have NO distortion over a fairly large FOV. I think +10 or +12 Diopter is the strongest available with a decent FOV. There is some interaction with glasses. If you can get them, try out cataract surgery lenses. Prescription lenses are special, as the back surface is ground to work properly with the eye "rolling" behind them. A rig that Telepresence Systems in Vancouver put together abuot 3 years ago (no they're not currently doing much on VR, concentrating instead on 3D video for telerobotics) used a pair of +10D glasses and color LCD panels from handheld TVs. There was a lot of other problems with the system, but the optics worked (if you didn't need strong glasses). Some adjustment was provided in the spacing between the displays and the glasses, for about +/- 4 diopters for those who needed prescripton eyewear. It is probably better to mount the lenses on a frame than to use glasses, because of the convenience factor. Also, if the displays (mounted on the headband) move with relation to the glasses on the head, it causes a LOT of display shifting. Some of the wholesalers for prescription eyewear stock preground plastic lens blanks and may be willing to cut them to the desired shape. I got a set of +10D blanks cut at Imperial Optical in Toronto for $35 each (or was it for the set? Lost the invoice). Distortion may not be too great a consideration– UNLESS you're using 2 displays for stereo! Then the distortions cause a reverse-spherical distortion in depth except at the center of the display, and loss of stereo depth toward the display corners, due to vertical misalignment. Look at a sheet of grid paper thru the lenses you propose to use to judge the amount of distortion. To reduce the effect of distortion, set up the displays and the 3D software for a 1 m convergence distance, as this will minimuze disparity between the displays for a stereo range of 40 cm to infinity. Another consideration with stereo displays is how to make the 2 displays overlap in the visual field. The average distance between a person's pupils is about 6 cm, so unless you have small displays you can't just hang them in front of the eyes– they'll be too far apart. One way to fix this is to tilt the displays away from each other and use prisms to "bend" the images back in front of the eyes. This can also be achieved by offseting the lenses (Brewster stereoscope). Problem is, this causes a WEIRD warping of the picture (vertical lines are bent), more color problems and blurring, and greater distortion at the display edges. The BEST method is to mount the displays SIDEWAYS and use 45 degree mirrors to put the image in front of the eyes. The picture gets flipped left-to-right, though, but this isn't a problem if you can define new fonts on the computer. If you're using CRT-type displays, just exchange the leads to the horizontal deflection yoke in the display, and everything's back to normal. Interestingly, this limits you to 54 degrees of horizontal FOV, because the display must be as far from the lens as it is wide (draw a picture and you'll see). If you're REALLY picky, use front-surface mirrors to prevent double reflections of bright lines on dark backgrounds. Front surface mirrors are pretty heavy, though, as they are usually 3/8" thick. Edmund Scientific (Efton in Canada) stocks then in various sizes. If you want lighter weight or cheaper mirrors, just get standard mirror glass. You might also try flipping the LCD panels over, but that is difficult with color LCD modules, because the electronics are then on the wrong side. Also, the vertical view angle of the panels then gets flipped, causing contrast mismatches between the left and right eye displays. Now, how to decide on lens powers, display distances, etc? The formula for lens diopter is 1/D = 1/F - 1/d; where D is the lens diopter required, F is the lens-to-display spacing, and d is the desired "apparant" distance (I recommend 0.5 to 1.0 meters for comfort). All distances are in meters. Be aware that distortion increases with lens power! Nondistorting prescription glasses have smaller FOV's with increasing power, too. For FOV, use tan(FOV/2) = s/d/2, where s is the pertinant dimension of the display, and d is the lens-to-display distance. Most display sizes are given diagonally, with hsize 4/5 * diagonal, and vsize = 3/5 diagonal. A factor of 1.1 or 1.2 increase in effective FOV _MAY_ happen because of interactions between strong lenses and eye movements. There are some subtle problems with LCD displays. First, the vertical viewing angle range of these things is less than +/- 15 degrees, so if you have a vertical FOV of 30 degrees or greater, the top and bottom of the scene will be washed out or darkened. This is why the new color LEEP optics use a diffuser plate: the viewing angle increases at the cost of resolution. The other problem with LCD color displays is the visible RGB pixel bands. These may be a problem with wide-angle displays, due to the high magnification. And, in some cases, they cut down the usable resolution. If a display's specs say "288 pixels H resolution, RGB stripe" then you KNOW that there are 96 red pixels, 96 blue… etc: so if you want pure white, your horizontal resolution is 96 pixels! (This type of display gives good apparant resolution for small FOV's, but not for large ones…) What do I recommend for FOV and pixel size? Well… I think that we should try for AT LEAST 54 degrees horizontally and 40 degrees vertically (about 2 1/2 by 3 1/2 feet at arm's length). This is sort of a happy medium between psychophysical effects and the limits of single-lens technology. Pixel size should be LESS THAN 1/3 degree plus a diffuser (actually, 1/10 degree or less is best, but let's not kid ourselves). Using 320x200 resolution with the 54x40 degree FOV, we get 0.2x0.16 degree pixels… hmm, not bad. BTW, these numbers based on the human contrast sensitivity function, which peaks at 10 pixels per degree. This means that bigger pixels will be tend to be seen as _pixels_ rather than a continuous image. A diffuser acts as a spatial lowpass filter, blurring the pixels together. Myself, I am _considering_ using some 4" portable B&W TV's because of their low cast, rlatively large screen size and high resolution. Also, pixel blurring can be done by adjusting the focus. The only problem is the weight– they would have to be counterweighted, so the inertial load on the head is pretty big. Also no color… Have to think about it some more. DISCLAIMER: Some of the above is based on work with a 35x25 degree system, some is knowledge of the technology and experience with an (older) LEEP system I'm not the most knowledgable person about optics, so maybe someone with more experience can design a cheap 2-lens system with less distortion and the full FOV needed. Myself, I subscribe to the KISS philosopy, but it would be nice to have a higher lens power so smaller displays can be used. ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From texsun!sunbird!tellab5!sunJe!menelli@Moxie.Hou.TX.US Wed Oct 23 08:42:47 1991 Received: from Menudo.UH.EDU by karazm.math.UH.EDU with SMTP id AA29205
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 23 Oct 1991 19:36:20 -0500
Received: from Moxie.Hou.TX.US by Menudo.UH.EDU with UUCP id AA25965
(5.65c+/IDA-1.4.4 for karazm.math.uh.edu!glove-list); Wed, 23 Oct 1991 19:32:11 -0500
Received: by moxie.hou.tx.us (Smail3.1.19)
id <m0kZsZx-0002q5C@moxie.hou.tx.us>; Wed, 23 Oct 91 19:05 CDT
Received: from sunbird.Central.Sun.COM by texsun.Central.Sun.COM (4.1/SMI-4.1)
id AA11794; Wed, 23 Oct 91 16:57:02 CDT
Received: from tellab5.UUCP by sunbird.Central.Sun.COM (4.1/SMI-4.1-900117)
id AA05942; Wed, 23 Oct 91 16:57:00 CDT
Received: from sunJe.TELLABS.COM
by tellab5.tellabs.com (4.1/smail2.5/10-21-91)
id AA15072; Wed, 23 Oct 91 13:42:50 CDT
Received: by sunJe.TELLABS.COM (4.0/4.7)
id AA02654; Wed, 23 Oct 91 13:42:47 CDT
Date: Wed, 23 Oct 91 13:42:47 CDT From: menelli@sunje.tellabs.com (Ron Menelli) Message-Id: 9110231842.AA02654@sunJe.TELLABS.COM To: glove-list@karazm.math.uh.edu Subject: RE: PG controller board
Given the very experimental tendancy of this group I have a sugestion
for the people designing outboard controller cards. I would love to
have one which I could down load the code to. In my experience, being
able to down load a new version of the controller code, rather than
having to burn another prom is a big win. Especially for those of us
who would have to burn the proms at work then bring them home to work
on.
This is another reason that I think that the 68HC811E2 is the way to go. The 2k of onboard EEPROM is more than enough for the current incarnation of the driver software (about 800 bytes now w/deglitching code), and updates would be very easy.
Also, in terms of lower cost, such a system would let someone with
considerably less equipment start experimenting with a controller
card. I haven't looked, but surely we can find a simple monitor for
one of these controllers which will allow down loading?
I have written software for the Amiga that allows you to do that. A port should be simple. The HC11 has a bootstrap mode where it loads 256 bytes from the serial port into RAM and then executes it. My program sends a 256 byte program that then executes a program on the HC11 when loads a variable length into the EEPROM. No programming hardware is needed (except a jumper on the board to select bootstrap mode). -Ron Menelli menelli@tellabs.com From newton@neworder.ils.nwu.edu Wed Oct 23 14:39:33 1991 Received: from casbah.acns.nwu.edu by karazm.math.UH.EDU with SMTP id AA29233
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 23 Oct 1991 19:53:13 -0500
Received: from neworder.ils.nwu.edu by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
id AA08131; Wed, 23 Oct 91 19:49:05 CDT
Return-Path: newton@neworder.ils.nwu.edu Received: by neworder.ils.nwu.edu (4.0/SMI-4.0)
id AA01148; Wed, 23 Oct 91 19:39:34 CDT
From: newton@neworder.ils.nwu.edu (Dave Newton) Message-Id: 9110240039.AA01148@neworder.ils.nwu.edu Subject: Re: Transputers… To: glove-list@karazm.math.uh.edu Date: Wed, 23 Oct 91 19:39:33 CDT In-Reply-To: 9110231931.AA19069@watserv1.uwaterloo.ca; from "Dave Stampe-Psy+Eng" at Oct 23, 91 3:31 pm X-Mailer: ELM [version 2.3 PL11] In a previous message, Dave Stampe-Psy+Eng said:
Actually, VPL is just sending world database updates by Ethernet, which
is OK. But we're talking about sending rendered pixels to the video board,
which, for a 500x500x24 bit picture, needs 6 Mbits/sec times the frame rate!
Can the video board handle this data rate??? If ypu use 4 transputers, can
they SEND this rate??? For our purposes, I think the world database
could reside on one transputer, which does preliminary clipping and
sends polygon and attribute lists to the other transputers. IF the
video board can handle the input speed, this idea will work. But not
if you have to design a custom video buffer… Or, how about using
4 video boards, genlocking them, and switching between them as their
video segments occur???
 Each set of transputers that is doing rendering would have a copy of
the world in it, so theoretically all it would have to do is blob-move that memory into whatever yo uwere using for output. If I'm going the cheap eye-phone route, I'll probably not have 500x500x24 in the near future. From LEEK@QUCDN.QueensU.CA Wed Oct 23 17:50:00 1991 Received: from QUCDN.QueensU.CA by karazm.math.UH.EDU with SMTP id AA29497
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 23 Oct 1991 21:23:22 -0500
Message-Id: 199110240223.AA29497@karazm.math.UH.EDU Received: from QUCDN.QueensU.CA by QUCDN.QueensU.CA (IBM VM SMTP V2R1)
 with BSMTP id 0519; Wed, 23 Oct 91 22:19:47 EDT
Received: by QUCDN (Mailer R2.08) id 6554; Wed, 23 Oct 91 22:19:46 EDT Date: Wed, 23 Oct 1991 21:50 EDT From: LEEK@QUCDN.QueensU.CA To: glove-list@karazm.math.uh.edu Subject: Cheap eye-phones idea A friend of mine recent bought a used colour video camera from a store. (It's one of those pre-camcorder thing with external VCR required) The video cameria comes with a attachable B/W monitor. It comes with a len to correct the focal distance for viewing through the eye piece. These would be quite useful for mounting onto a helmet. All the electronics are built and accept a composite video (NTSC) and DC power. No messing around required. There is a switch to flip the image (for viewing from the other side of the camera.) This comes in handy as you can get the two monitors out of the way of each other by flipping one. He got the whole thing for about $150 Canadian. The owner of the store told him that he might be able to find defunction camera for parts at a much cheaper price… Look around pawn shop & used video equipment store around, you might be able to find something useable for a VR homebrew project. My second idea involve splitting the screen into 2 side for each eye. This save you 50% cost & weight at the expense of losing resolution. Some optic trickery is required…
                              _______
                             |       |
                             |       | ---->   This half for the right eye
                            -+- - - -+-
 This half for the left<---- |       |
                             |_______|
                             (screen rotated
                              by 90 degrees)
By dividing the screen this way, you can get a wider aspect ratio as a side effect. :) Hope this sparks some new ideas… K. C. Lee Elec. Eng. Grad. Student From dstamp@watserv1.uwaterloo.ca Wed Oct 23 19:22:02 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA29626
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 23 Oct 1991 22:26:13 -0500
Received: by watserv1.uwaterloo.ca
id <AA17551>; Wed, 23 Oct 91 23:22:02 -0400
Date: Wed, 23 Oct 91 23:22:02 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110240322.AA17551@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu, newton@neworder.ils.nwu.edu Subject: Re: Transputers…
From glove-list-request@karazm.math.UH.EDU Wed Oct 23 21:13:53 1991
From: newton@neworder.ils.nwu.edu (Dave Newton)
Subject: Re: Transputers…
To: glove-list@karazm.math.uh.edu

In a previous message, Dave Stampe-Psy+Eng said:
> Actually, VPL is just sending world database updates by Ethernet, which
> is OK. But we're talking about sending rendered pixels to the video board,
> which, for a 500x500x24 bit picture, needs 6 Mbits/sec times the frame rate!
> Can the video board handle this data rate??? If ypu use 4 transputers, can
> they SEND this rate??? For our purposes, I think the world database
> could reside on one transputer, which does preliminary clipping and
> sends polygon and attribute lists to the other transputers. IF the
> video board can handle the input speed, this idea will work. But not
> if you have to design a custom video buffer… Or, how about using
> 4 video boards, genlocking them, and switching between them as their
> video segments occur???

Each set of transputers that is doing rendering would have a copy of
the world in it, so theoretically all it would have to do is blob-move
that memory into whatever yo uwere using for output. If I'm going the
cheap eye-phone route, I'll probably not have 500x500x24 in the near
future.

Why??? A fair amount of the work involved in the preprocessing of the world database (especially if you're using an object-oriented tree or a BSP algorithm would then have to be done on each processor… needless repetition, with little load involved in the transfer from the central world-list handler you'd need. And the data rate to the central video board is STILL too high… 320x200x8 bit video, 20 frames/sec is 11 Mbit/sec, with no margin for peak loads, repetitive writes to any pixel, etc. Unless you are using a PARALLEL interface… As you can see, it's borderline. And for the cost of the Transputers and the video buffer, I'd like to get something good for my money. Not that I believe it's impossible, but I'm working without the transfer specs, and prefer to err on the side of caution. (B-{) So… can you post the transfer specs on the video card, prices, etc. I AM interested, just cautious. It would be great to be able to put together a 10Kpoly/sec system with Gourand shading, textures, GOOD color, stereo video (2 outputs) and 20 frames/sec for under $1500 extra… - Dave Stampe From dstamp@watserv1.uwaterloo.ca Wed Oct 23 19:48:06 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA29744
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Wed, 23 Oct 1991 22:52:16 -0500
Received: by watserv1.uwaterloo.ca
id <AA18884>; Wed, 23 Oct 91 23:48:06 -0400
Date: Wed, 23 Oct 91 23:48:06 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110240348.AA18884@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu LEEK@QUCDN.QueensU.CA writes:
A friend of mine recent bought a used colour video camera from a store.
(It's one of those pre-camcorder thing with external VCR required)
The video cameria comes with a attachable B/W monitor. It comes with a
len to correct the focal distance for viewing through the eye piece.
These would be quite useful for mounting onto a helmet. All the electronics
are built and accept a composite video (NTSC) and DC power. No messing
around required. There is a switch to flip the image (for viewing from the
other side of the camera.) This comes in handy as you can get the two monitors
out of the way of each other by flipping one.

He got the whole thing for about $150 Canadian. The owner of the store
told him that he might be able to find defunction camera for parts at a much
cheaper price… Look around pawn shop & used video equipment store around,
you might be able to find something useable for a VR homebrew project.

My second idea involve splitting the screen into 2 side for each eye. This
save you 50% cost & weight at the expense of losing resolution. Some optic
trickery is required…

_ > | | > | | —→ This half for the right eye > -+- - - -+- > This half for the left←— | | > |_|

(screen rotated
by 90 degrees)

By dividing the screen this way, you can get a wider aspect ratio as a side
effect. :)
K. C. Lee
The problem I see with the camera viewfinder is the tiny FOV (<20 degrees). This makes it difficult to navigate in a virtual world. A series of experiments performed recently (Restricting the Field of View: Perceptual performance effects, in Perception and Motor Skills #70) demonstrated severe degradation of visual-motor coordination and poor "conceptual mapping" with display "windows" (actually holes cut in a mask) for any size less than 30 degrees wide. Subjects performed a variety of simple tasks, including following a twisted line on the floor and exploring a room. Little degradation was seen with "display" FOV's grater than 100 degrees. I love the resolution, size and price of the camera viewfinders myself and wish the FOV was better… In fact, if I can do something about the weight, I'm considering using 4" B&W TV's with a simple lens to make BIG viewfinders with 54x40 degree FOV's. The split display idea will also result in a small FOV, mostly because the mirrors needed to get the image to the proper eyes will put them too far optically from the eye-lenses. Another possiblilty is to use a 640x200 monochrome LCD panel (they used to use them in compatibles) and use one side for each eye. Pretty easy to see how that would work, and you can put it REALLY close to the eyes (= big FOV). Now to find one…
My life is Hardware,
my destiny is Software, Dave Stampe
my CPU is Wetware…
Anybody got a SDB I can borrow? dstamp@watserv1.uwaterloo.ca
From broehl@sunee.waterloo.edu Wed Oct 23 20:16:50 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA29956 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Wed, 23 Oct 1991 23:21:01 -0500 Received: by sunee.waterloo.edu id <AA19470>; Thu, 24 Oct 91 00:16:53 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110240416.AA19470@sunee.waterloo.edu Subject: Re: Standards (fwd) To: glove-list@karazm.math.uh.edu Date: Thu, 24 Oct 91 0:16:50 EDT X-Mailer: ELM [version 2.3 PL11] > From: jcross@ecel.uwa.oz.au (Jennifer Cross - pgmr) > > After some careful thought, I've come to the conclusion that the various > > VR input devices will be too varied to make a single, universal interface > > practical. > Depends at which level of abstration you use. SGI have a neat tool called > "ConMan" which uses a pipe type metaphor to "connect" processes. With > this, you could "connect" each of the PG output steams to various > functions and customise the interface without any programming. > (each process specifies it's input and output sockets to ConMan, and > it manages the data flow). Sounds great, but maybe a bit complex for what we're trying to do. > > Since we wll probably have a set of routines for each VR input device we > > develop, I would propose a naming convention: all the routines related to > > the glove we love will have names prefixed with "glove_". Thus our > ^^^^^^^^ no no no! Suffixed! > This allows like routines to be grouped by function (again abstracting > from the specific). This would also make (next level up) routines like > init(GLOVE) reasonable. I'm flexible; what is the preference of the list? (Bear in mind this is easy to fix later with #define's) > > Host sends 'H' to board to put glove in hi-res mode > > Host sends 'P' to board to poll it for a 6-byte packet > > [etc] > use numeric commands and reserve (top?) bit for "extended command" Okay, how about 0x48 to put glove in high-res mode, 0x50 to poll the glove… :-) > Great Job - managed to provoke me to submit! Welcome aboard – the more minds, the better. – Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] From jcross@ecel.uwa.oz.au Thu Oct 24 00:05:29 1991 Received: from decel.ecel.uwa.oz.au by karazm.math.UH.EDU with SMTP id AA00462 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 00:05:29 -0500 Received: from accfin.ecel.uwa.oz.au by decel.ecel.uwa.oz.au with SMTP (5.61+IDA+MU) id AA22045; Thu, 24 Oct 1991 13:03:48 +0800 From: jcross@ecel.uwa.oz.au (Jennifer Cross) Message-Id: 9110240513.AA04532@accfin.ecel.uwa.oz.au Subject: »> Standards To: glove-list@karazm.math.uh.edu Date: Thu, 24 Oct 91 13:13:14 WST X-Mailer: ELM [version 2.3 PL11] > From: Bernie Roehl broehl@sunee.waterloo.edu > > From: jcross@ecel.uwa.oz.au (Jennifer Cross - pgmr) > > > After some careful thought, I've come to the conclusion that the various > > > VR input devices will be too varied to make a single, universal interface > > > practical. > > Depends at which level of abstration you use. SGI have a neat tool called > > "ConMan" which uses a pipe type metaphor to "connect" processes. With > > this, you could "connect" each of the PG output steams to various > > functions and customise the interface without any programming. > > (each process specifies it's input and output sockets to ConMan, and > > it manages the data flow). > > Sounds great, but maybe a bit complex for what we're trying to do. just an example of a great idea (but might be just a little too hard for the 386 trying to run a VR environment. But really this would work great on something like an (fast) Amiga since it has blindingly fast interprocess message passing, the "ConMan" (emulator) would only really take CPU during process registration (Sorry bout all those PC types with serious "interprocess" comms hassles. Still, dedicate a segment as shared memory and a you could get decent xfer rates (even if not provided by OS). And yes, I have an Amiga, and yes I work with PC's, Mac's, Suns and SG's all day (less SG for the moment <sadness>)) […] > Okay, how about 0x48 to put glove in high-res mode, 0x50 to poll the glove… > :-) Actually I think (IMHO) that to put the glove into hi-res a command init_glove(MODE,HIRES) – 0x81 0x01 0x48 would be better \ \ `- High Res \ `- set MODE command `- Init command group or if you are certain there will be less than 255 Init settings, we could settle for 0x81 0x48 init MODE_HI_RES if performance is important on commands, impliment most critical as level 1 (1byte) commands. If not enough of these use split secondary commands. (I love thinking up these things! - comes from implimenting CAD stuff on ComputerVision and CPM in fortran (I can feel my mind going Dave…)!! ) Thanks for the Welcome! – _
       (   >                  /)                        (voice) +61 9 362 6680
        __/_/> ____  ____  o //  _  __            (home)  cjcross@DIALix.oz.au
       / / (__/ / <_/ / <_<_//__</_/ (_ @ Beautiful Perth, Western Australia
      <_/                  />                     (work) jcross@ecel.uwa.oz.au
                          </                            (voice) +61 9 380 3879
From langfod@atlantis.CS.ORST.EDU Wed Oct 23 15:48:14 1991 Received: from CS.ORST.EDU by karazm.math.UH.EDU with SMTP id AA00531
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 00:40:53 -0500
Received: from atlantis.CS.ORST.EDU by CS.ORST.EDU (15.11/1.15)
id AA27661; Wed, 23 Oct 91 22:36:42 pdt
Received: by atlantis.CS.ORST.EDU (5.61/1.14)
id AA16701; Wed, 23 Oct 91 22:48:16 -0700
From: Maggot_Muncher langfod@atlantis.CS.ORST.EDU Message-Id: 9110240548.AA16701@atlantis.CS.ORST.EDU Subject: * LCD Panels * To: glove-list@karazm.math.uh.edu Date: Wed, 23 Oct 91 22:48:14 PDT X-Mailer: ELM [version 2.3 PL11] Marlin P. Jones & Assoc. a mail order surplus etc. dealer has some LCD panels in their latest(? Cat. 91-8) catalog. 640x400 ($55) w/ fluoro backlight - 3735-OP 640x200 ($29.95) supertwist - 3748-OP 256x64 ($16) w/ electrolum. backlight - 3793-OP address: P.O. Box 12685 phone: (407) 848-8236
       Lake Park Fl.         fax: (407) 844-8764
 33403-0685
BTW- I have no relation to them and have never ordered from them. – +—————————————————————————-+ | David Langford - Corvallis, OR | `Let the sweet breezes heal me | | | As they rove around the girth | | langfod@atlantis.cs.orst.edu | Of our lovely mother planet, | | langfod@jacobs.cs.orst.edu | Of the cool green hills of Earth.' | | | _Green Hills of Earth_ -Heinlein | +—————————————————————————-+ From DAVID@asgard.clare.tased.edu.au Thu Oct 24 02:14:36 1991 Received: from diemen.utas.edu.au by karazm.math.UH.EDU with SMTP id AA00731
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.EDU>); Thu, 24 Oct 1991 02:14:36 -0500
Received: from ecc.tased.edu.au by diemen.utas.edu.au with SMTP id AA22348
(5.65b/IDA-1.4.3 for glove-list@karazm.math.uh.EDU); Thu, 24 Oct 91 18:10:12 +1100
Received: from slick.clare.tased.edu.au by ecc.tased.edu.au (PMDF #12099) id 01GC4TBEHQEO94EHQZ@ecc.tased.edu.au; Thu, 24 Oct 1991 18:09 +1000 Received: from by slick.clare.tased.edu.au (4.1/SMI-4.1) id AB02734; Thu, 24 Oct 91 19:15:55 EST Received: From ASGARD/WORKQUEUE by charon1.clare.tased.edu.au via Charon 3.4 with IPX id 100.911024181040.864; 24 Oct 91 18:11:12 -0500 Date: 24 Oct 91 18:10:00 From: david DAVID@asgard.clare.tased.edu.au Subject: PC Hires Code - timing ! To: dstamp@watserv1.uwaterloo.CA, glove-list@karazm.math.uh.EDU Message-Id: MAILQUEUE-101.911024180958.816@asgard.clare.tased.edu.au X-Envelope-To: glove-list@karazm.math.uh.EDU, dstamp@watserv1.uwaterloo.CA X-Mailer: Pegasus Mail v2.1b. I'm trying to get the hires powerglove code to go, but I've hit what looks to be a timing problem. Could you answer a few questions for me regarding the HIRES code for PC's
  1. What does the glove "do" when it's in hires mode ?
          does it beep when it enters the mode ?
          what do the lights do ?
  2. Is the timing in the hires setup code critical, and if so, within
      what errors do I have to work ?
  3. Has anybody produced assembler to read the glove in hires, and
      also to switch off all other interrupts, and autocalibrate ?
          There's some problems with the code that was posted - primarily
          to do with setup overhead on the while loops - Not all of
          us have 486's with hi speed long division and subtraction etc...
          I'm using a 16M 286 AND a friend is using a 10M XT !  So we've
          got to have portable code that autocalibrates and runs OK on
          either machine.  We may even end up writing some assembler module
          to do it for us, but we'd rather not do something anyone else
          has done.
Thankyou _ David Ford Voice : +61 02 49 6887 Claremont College Fax : +61 02 49 1984 Link Rd email : david@slick.clare.tased.edu.au Claremont TAS 7011 AUSTRALIA The Internet : "Wherever you go… There you are…" Buckaroo Banzai From jim@kaos.stanford.edu Wed Oct 23 18:04:46 1991 Received: from fou-local (fou.Stanford.EDU) by karazm.math.UH.EDU with SMTP id AA00825 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 03:08:29 -0500 Received: from localhost.Stanford.EDU by fou-local (4.1/inc-1.0) id AA25862; Thu, 24 Oct 91 01:04:48 PDT Message-Id: <9110240804.AA25862@fou-local> To: glove-list@karazm.math.uh.edu In-Reply-To: Your message of "Wed, 23 Oct 91 20:16:58 EDT." 9110240016.AA08943@watserv1.uwaterloo.ca Date: Thu, 24 Oct 91 01:04:46 -0700 From: James Helman jim@kaos.stanford.edu Dave Wargo writes: I think the real trick is going to be the optics. This is not a trival task and I would be interested in hearing what can be done short of spending $800.00 for a pair of LEEP optics. Dave Stamp writes: I guess the LEEP optics cost *is* dropping– last time I talked to Eric Howlett (designer of LEEP systems) they were still $3500 each. LEEP has a rather strong quantity based pricing policy. Clearly group purchases are in order: 1st unit: $3000 2nd-3rd: $1500 each 4th-7th: $750 each Jim Helman Lab: (415) 723-9127 Stanford University FAX: (415) 591-8165 (jim@KAOS.stanford.edu) Home: (415) 593-1233 "The power of the computer is locked behind a door with no knob." -B. Laurel From broehl@sunee.waterloo.edu Thu Oct 24 03:52:25 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA01208 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 06:56:36 -0500 Received: by sunee.waterloo.edu id <AA25428>; Thu, 24 Oct 91 07:52:27 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110241152.AA25428@sunee.waterloo.edu Subject: PC Hires Code - timing ! (fwd) To: glove-list@karazm.math.uh.edu Date: Thu, 24 Oct 91 7:52:25 EDT X-Mailer: ELM [version 2.3 PL11] > 2. Is the timing in the hires setup code critical, and if so, within > what errors do I have to work ? Not sure about this, but the timing diagrams recently posted to the list may have the answer (they're in Postscript and I have yet to print them out). > > 3. Has anybody produced assembler to read the glove in hires, and > also to switch off all other interrupts, and autocalibrate ? No, but once I get the interrupt mode fully functional I may turn it into a TSR. > There's some problems with the code that was posted - primarily > to do with setup overhead on the while loops - Not all of > us have 486's with hi speed long division and subtraction etc… My fault – will be fixed soon, maybe today. I switched over to using microseconds as my delay unit throughout, and was doing the conversion (a multiply AND a divide!) for each bit. > I'm using a 16M 286 AND a friend is using a 10M XT ! Yikes! Get a new machine! (seriously!) > So we've > got to have portable code that autocalibrates and runs OK on > either machine. We may even end up writing some assembler module > to do it for us, but we'd rather not do something anyone else > has done. Wait a day or so till my fixes are in and try that… if it doesn't work, you may be forced into coding in assembler or buying a faster machine. – Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] From broehl@sunee.waterloo.edu Thu Oct 24 04:37:46 1991 Received: from sunee.waterloo.edu by karazm.math.UH.EDU with SMTP id AA01420 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 07:42:01 -0500 Received: by sunee.waterloo.edu id <AA25908>; Thu, 24 Oct 91 08:37:49 -0400 From: Bernie Roehl broehl@sunee.waterloo.edu Message-Id: 9110241237.AA25908@sunee.waterloo.edu Subject: Some thoughts on shutter-glasses To: glove-list@karazm.math.uh.edu Date: Thu, 24 Oct 91 8:37:46 EDT X-Mailer: ELM [version 2.3 PL11] When interfacing to shutter-glasses, we ideally want to be able to switch eyes every 1/60th of a second. That means we want to do it on every vertical retrace; it would be really nice if the VGA card were to generate an interrupt on vertical retrace, but it doesn't. That leaves only two approaches: - polling - using the timer interrupt The problem with polling is that you have to pepper your high-level code with calls to a routine that checks for vertical retrace and switches the screens and the LCD glasses. That's not too bad, though, since the routine is very simple and very fast. If you miss one swap, it's not the end of the world. The interrupt approach is good, but assumes that you can program the timer to run at *exactly* the framing rate; even a small inaccuracy will cause you to "drift" and miss the retrace. Alternatively, you could reprogram the timer on each vertical retrace, and thereby eliminate the inaccuracy. Bear in mind that if you're supporting both the glasses and the glove, you now have a few things to do on timer interrupts; this may be the way to go, but requires some more thought. (At least, *I* require some more thought). (A first pass:) The glove gets polled every 4 ms, the display gets swapped every 16 ms; so… timer interrupt routine runs every 4 ms, and does the following: - increment a counter - if the counter reaches 4: - wait for a vertical retrace - reprogram the timer - swap the display - zero the counter - in any case, do the glove stuff Now, waiting for a vertical retrace is a bad idea if we just missed one; we'll miss glove events, for one thing. However, this shouldn't happen after the first time through. Reprogramming the timer may be more serious; will we wind up with major inaccuracies? Will the system time-of-day clock drift? Any feedback would be appreciated… – Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] From yonder@netcom.netcom.com Thu Oct 24 01:29:15 1991 Received: from netcomsv.netcom.com by karazm.math.UH.EDU with SMTP id AA01789 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 10:34:20 -0500 Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA08319; Thu, 24 Oct 91 08:29:16 PDT Received: by netcom.netcom.com (4.1/SMI-4.1) id AA05982; Thu, 24 Oct 91 08:29:16 PDT From: yonder@netcom.com (Christopher Russell) Message-Id: 9110241529.AA05982@netcom.netcom.com Subject: low-end eyephones idea.. To: glove-list@karazm.math.uh.edu (Power Glove mailing list) Date: Thu, 24 Oct 91 8:29:15 PDT X-Mailer: ELM [version 2.3 PL11] I just kinda had a crazy idea and I was wondering what you more experienced types think of it. (Maybe this is already being done, I don't know). Maybe one small screen could be used with shutter glasses in between the screen/optics and your eyes. I've heard the Sega glasses aren't too good, but assuming that good shutter glasses were used, it seems to me one could get away with one screen and save weight and money. Though I'm not sure how you could place the screen (private eye? lcd? ) without having to use mirrors to get it to both eyes. hey, just brainstorming… This might induce some SERIOUS eyestrain.. Whatcha think… – Christopher L. Russell (yonderboy) Phone: (408)378-9078 Campbell,CA yonder@netcom.COM or clr40@amail.amdahl.com or chrisr@leland.stanford.edu From dstamp@watserv1.uwaterloo.ca Thu Oct 24 08:31:11 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA02012 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 11:35:22 -0500 Received: by watserv1.uwaterloo.ca id <AA29095>; Thu, 24 Oct 91 12:31:11 -0400 Date: Thu, 24 Oct 91 12:31:11 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110241631.AA29095@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu yonder@netcom.com (Christopher Russell) posts: >I just kinda had a crazy idea and I was wondering what you more >experienced types think of it. (Maybe this is already being done, I >don't know). Maybe one small screen could be used with shutter >glasses in between the screen/optics and your eyes. I've heard the >Sega glasses aren't too good, but assuming that good shutter glasses >were used, it seems to me one could get away with one screen and save >weight and money. Though I'm not sure how you could place the screen >(private eye? lcd? ) without having to use mirrors to get it to both >eyes. hey, just brainstorming… This might induce some SERIOUS >eyestrain.. Whatcha think… You're right– the problem IS how to get the display image to both eyes. Unless you use fiber optics (HAH!) you need mirrors to get both eyes in the act. The optical path is so long that you get a FOV of less than 20 degrees. If the images are'nt placed properly, you probably won't be able to fuse the two inages, and the displays will LOOK close (not good for the VR illusion. You might try strong prisms to "bend" the display into place, but this causes BIG distortions with the prism power you'd need. Also, each eye will see an image of the display tilted in opposite directions. That means that for non-stereo eyephones, you have the choice of: 1) using 2 displays, and feeding them both with the same signal 2) using one display, and covering/closing the other eye BTW, is anyone SERIOUSLY planning to drive their eyephones with stereo pictures, or is eyeryone going to start with a single image (flat). I'd like to suggest emulating the Sega glasses as a start for eyephone stereo. Switching the LCD backlights on and off won't work, as the image on the panels changes too slowly and the backights switch too slowly (I've measured their rise and fall times). A better way is to switch the video (but NOT the sync signals) to each display on and off. This will have lower the contrast somewhat, of course. If you're using CRTs or camera viewfinders are used, blanking signals could be sent right to the CRT driver electronics. ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From snowdond@computer-science.manchester.ac.uk Thu Oct 24 13:18:32 1991 Received: from sun2.nsfnet-relay.ac.uk by karazm.math.UH.EDU with SMTP id AA02470
(5.65c/IDA-1.4.4 for <glove-list@KARAZM.MATH.UH.edu>); Thu, 24 Oct 1991 13:18:32 -0500
Received: from computer-science.manchester.ac.uk by sun2.nsfnet-relay.ac.uk
        via JANET with NIFTP id <13545-6@sun2.nsfnet-relay.ac.uk>;
        Thu, 24 Oct 1991 13:40:39 +0100
Date: Thu, 24 Oct 91 13:00:59 BST From: Dave Snowdon snowdond@computer-science.manchester.ac.uk Message-Id: 9110241200.AA23286@r2i.cs.man.ac.uk To: glove-list@KARAZM.MATH.UH.edu Subject: Transputers
Here at Manchester we have a small vr group and were experimenting with
some existing transputer hardware built here at Manchester.
One thing to be wary of is that the quoted link speed (for a T800) is not
actually acheivable.
For every 8 bits of data the link engine actually sends 11 bits. Also there
is a 2 bit acknowledgement, so if you're trying to get bi-directional communication the link engine is effectively sending 13 bits for every useful 8 bits of data. This gives a max transmission rate of something less than one megabyte/sec. Because of overheads of setting up a communication you also need to send messages of several bytes to approach even this.
Some other hardware we're experimenting with is a frame-buffer which exists
as shared memory between 4 transputers. We can then use 16 links to send data to the frame buffer.
		Dave
          Dave Snowdon (snowdond@cs.man.ac.uk)            
     The Devil may care... But I don't mind (T.S.o.M.)
From agodwin@acorn.co.uk Thu Oct 24 19:22:35 1991 Received: from eros.uknet.ac.uk by karazm.math.UH.EDU with SMTP id AA02490
(5.65c/IDA-1.4.4 for <glove-list@KARAZM.MATH.UH.edu>); Thu, 24 Oct 1991 13:23:25 -0500
Received: from acorn.co.uk by eros.uknet.ac.uk with UUCP
        id <5768-0@eros.uknet.ac.uk>; Thu, 24 Oct 1991 18:41:20 +0100
Received: from snark.acorn.co.uk by acorn.co.uk (4.1/Am31) id AA07820;
        Thu, 24 Oct 91 18:22:39 BST
From: agodwin@acorn.co.uk (Adrian Godwin) Date: Thu, 24 Oct 91 18:22:35 +0100 Message-Id: 9110241722.AA00285@snark.acorn.co.uk To: broehl@SUNEE.WATERLOO.edu, glove-list@KARAZM.MATH.UH.edu Subject: Re: Some thoughts on shutter-glasses
That means we want to do it on every vertical retrace; it would be really
nice if the VGA card were to generate an interrupt on vertical retrace,
but it doesn't. That leaves only two approaches:

- polling
- using the timer interrupt

The problem with polling is that you have to pepper your high-level code
with calls to a routine that checks for vertical retrace and switches the
screens and the LCD glasses. That's not too bad, though, since the routine
is very simple and very fast. If you miss one swap, it's not the end of
the world.
This is ridiculous : you're solving the wrong problem, and it's costing you a fortune in CPU resource to do it. If you need to do something on a vertical retrace, (and if you can't get out of it by using interlace, say) then GENERATE THE INTERRUPT ! You need some hardware to drive the LCD shutter : drive that hardware from the VSYNC signal and also feed it into an interrupt input. There are lots of ways you can generate the interrupt - straight onto the bus, a serial port status line change, the parallel port ACK input, a countertimer input .. just choose one ! -adrian From jet Thu Oct 24 08:33:43 1991 Received: by karazm.math.UH.EDU id AA02542
(5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 13:33:44 -0500
From: J Eric Townsend <jet> Message-Id: 199110241833.AA02542@karazm.math.UH.EDU Subject: Re: Moving List to Newsgroup To: aaronp@narrator.pen.tek.com Date: Thu, 24 Oct 91 13:33:43 CDT Cc: glove-list@karazm.math.uh.edu In-Reply-To: 9110232232.AA07268@narrator.PEN.TEK.COM; from "aaronp@narrator.pen.tek.com" at Oct 23, 91 3:32 pm X-Mailer: ELM [version 2.3 PL11] you wrote:
2. If a new newsgroup is created, what should it be called?
comp.periphs.glove or comp.periphs.virtual:
Scope is not as broad as the discussions which take place
here. As stated in the preface to this summary, the
discussions here have simply gone beyond peripherals.
Um, that's a problem I have with the list. It was set up to discuss hacking the glove, not to discuss what polygon rendering techniques work best on which platform. – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From jet Thu Oct 24 08:40:33 1991 Received: by karazm.math.UH.EDU id AA02648
(5.65c/IDA-1.4.4 for glove-list); Thu, 24 Oct 1991 13:40:34 -0500
From: J Eric Townsend <jet> Message-Id: 199110241840.AA02648@karazm.math.UH.EDU Subject: Reminder of content of the list To: glove-list Date: Thu, 24 Oct 91 13:40:33 CDT X-Mailer: ELM [version 2.3 PL11] This list is for power glove stuff. Not monitors, not scan-line techniques, not anything else. I'm beginning to get "unsubscribe me but keep me updated on new source" requests from people who don't give a monkey's about scan-line techniques for VGA. I think they're right. Please keep the stuff related to power gloves (or even data gloves in general). If you wanna talk about viewing systems, then maybe it's time for a monitor-talk-list or somesuch. Thanks for your cooperation, eric – J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834 PowerGlove mailing list: glove-list-request@karazm.math.uh.edu "allow users to create more impactful documents" – from an Apple press release From kskelm@uccs.edu Thu Oct 24 07:50:44 1991 Received: from happy (happy.uccs.edu) by karazm.math.UH.EDU with SMTP id AA02702
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 13:42:14 -0500
Received: by uccs.edu (MX V2.3-1) id 21323; Thu, 24 Oct 1991 11:50:44 EDT Date: Thu, 24 Oct 1991 11:50:44 EDT From: "NO, That's NOT a cord of wood in my pocket!" kskelm@uccs.edu To: glove-list@karazm.math.uh.edu Message-Id: 00950980.60961480.21323@uccs.edu Subject: eyephones
This is just a stupid thought, but has anyone considered using the
REALLY tiny b/w screens found in the eyepieces of video cameras? A benefit here is that each can be independently focused.
(and I assume they're available in abundance if you know where to look)
	Just a thought...
		Kevin
From motcsd!roi!lance@apple.com Mon Oct 24 04:17:39 1991 Received: from apple.com by karazm.math.UH.EDU with SMTP id AA02827
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 13:50:59 -0500
Received: by apple.com (5.61/18-Oct-1991-eef)
id AA14274; Thu, 24 Oct 91 11:26:27 -0700
for 
Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4)
id <m0ka9hV-0001FDC@motcsd.csd.mot.com>; Thu, 24 Oct 91 11:22 PDT
Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.)
id AA02346; 24 Oct 91 11:17:40 PDT (Thu)
To: broehl@sunee.waterloo.edu Subject: VGA vertical retrace Cc: glove-list@karazm.math.uh.edu Message-Id: 9110241117.AA02342@roi.ca41.csd.mot.com Date: 24 Oct 91 11:17:39 PDT (Thu) From: Lance Norskog lance@roi.ca41.csd.mot.com The answer is to get one of the many VGA cards which do support vertical retrace interrupts. Alan Killian discussed his work with LCD goggles awhile back on sci.virtual-worlds, and we realized that the LCD timing is such that it may be preferable to switch the goggles ahead of the vertical retrace rather than on it. Also, we might want to separately control the two cells rather than just have a left-right control line. This would need an outboard box which read the horizontal and vertical sync, counted up retraces, and switched the LCD cells just before rather than "on the beat". This sounds like another job for the outboard glove control board. It could do the serial port AA and control line trick to control the LCD cells. Lance Norskog From dstamp@watserv1.uwaterloo.ca Thu Oct 24 11:28:40 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA03303
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 14:32:57 -0500
Received: by watserv1.uwaterloo.ca
id <AA10942>; Thu, 24 Oct 91 15:28:40 -0400
Date: Thu, 24 Oct 91 15:28:40 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110241928.AA10942@watserv1.uwaterloo.ca To: broehl@sunee.uwaterloo.ca, lance@roi.ca41.csd.mot.com Subject: Re: VGA vertical retrace Cc: glove-list@karazm.math.uh.edu
From glove-list-request@karazm.math.UH.EDU Thu Oct 24 14:57:02 1991
To: broehl@sunee
Subject: VGA vertical retrace
Cc: glove-list@karazm.math.uh.edu
From: Lance Norskog lance@roi.ca41.csd.mot.com


The answer is to get one of the many VGA cards which do support
vertical retrace interrupts.

Alan Killian discussed his work with LCD goggles awhile back
on sci.virtual-worlds, and we realized that the LCD timing
is such that it may be preferable to switch the goggles
ahead of the vertical retrace rather than on it. Also,
we might want to separately control the two cells rather
than just have a left-right control line.

This would need an outboard box which read the horizontal
and vertical sync, counted up retraces, and switched the
LCD cells just before rather than "on the beat".

This sounds like another job for the outboard glove control board.
It could do the serial port AA and control line trick to control
the LCD cells.

Lance Norskog
I've had no problems using Sega glasses with monitor VSYNC… if they're driven properly. Some of the older models might have had slower pi-cells.. I dunno. - Dave Stampe From dstamp@watserv1.uwaterloo.ca Thu Oct 24 11:42:36 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA03370
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.UH.EDU>); Thu, 24 Oct 1991 14:48:41 -0500
Received: by watserv1.uwaterloo.ca
id <AA12247>; Thu, 24 Oct 91 15:42:36 -0400
Date: Thu, 24 Oct 91 15:42:36 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110241942.AA12247@watserv1.uwaterloo.ca To: JET@UH.EDU, glove-list@karazm.math.UH.EDU Subject: Re: Reminder of content of the list
From JET@UH.EDU Thu Oct 24 14:53:20 1991
From: J Eric Townsend JET@UH.EDU
Subject: Reminder of content of the list
To: glove-list@karazm.math.UH.EDU


This list is for power glove stuff. Not monitors, not scan-line techniques,
not anything else. I'm beginning to get "unsubscribe me but keep me
updated on new source" requests from people who don't give a monkey's
about scan-line techniques for VGA.

I think they're right.

Please keep the stuff related to power gloves (or even data gloves in
general).

If you wanna talk about viewing systems, then maybe it's time for
a monitor-talk-list or somesuch.

Thanks for your cooperation,
eric


J. Eric Townsend - jet@uh.edu - Systems Wrangler, UH Dept of Mathematics
vox: (713) 749-2126 '91 CB750, DoD# 0378, TMRA# 27834
PowerGlove mailing list: glove-list-request@karazm.math.uh.edu
"allow users to create more impactful documents" – from an Apple press release
I think SOMETHING should be done… We've got a lot of momentum here, and sci.virtual-worlds seems to be DOWN since Monday. Could a temporary list be set up until the new newsgroup is up? If you don't want to, maybe someone else can… Any volenteers? - Dave Stampe From mwtilden@watmath.waterloo.edu Thu Oct 24 14:01:10 1991 Received: from watmath.waterloo.edu by karazm.math.UH.EDU with SMTP id AA04081
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 17:05:22 -0500
Received: by watmath.waterloo.edu
id <AA11152>; Thu, 24 Oct 91 18:01:10 -0400
Date: Thu, 24 Oct 91 18:01:10 -0400 From: "Mark W. Tilden" mwtilden@watmath.waterloo.edu Message-Id: 9110242201.AA11152@watmath.waterloo.edu To: glove-list@karazm.math.uh.edu Re: lenses. For the system we're putting together, we find that slimline freznel lense sheets (high density) work well. Credit card sized units are available through most science shops. Re: Displays. Sony last year discontinued the FDM-330 line of modular tvs and replaced them with a substandard FDL-370. The former were expensive, but ideal because of their modularity. We will be using 370s, but they're going to require pruning. Severe pruning. The lenses seem to be about 10cm uniformly. I only have two types right now so I don't really have a database of types available. The advantages are that they are flexible, cascadeable, extremely lightweight, cheap. We're going to be using two together for each eye to get a 4cm focal length. Will post. Is all. Mark Tilden From kilian@poplar.cray.com Thu Oct 24 13:05:00 1991 Received: from timbuk.cray.com by karazm.math.UH.EDU with SMTP id AA04229
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 18:09:21 -0500
Received: from poplar14.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6j)
id AA28005; Thu, 24 Oct 91 18:05:04 CDT
Received: by poplar14.cray.com
id AA20630; 4.1/CRI-5.6; Thu, 24 Oct 91 18:05:00 CDT
Date: Thu, 24 Oct 91 18:05:00 CDT From: kilian@poplar.cray.com (Alan Kilian) Message-Id: 9110242305.AA20630@poplar14.cray.com To: glove-list@karazm.math.uh.edu Subject: LCD shutter switching timings Folks,
Here is my post to sci.virtual-worlds discussing the timing of LCD shutter
switching based on a vertical sync signal. If you want to get numbers for a VGA display you need to have the video rate information ready. I do not have that information but if someone gan give it to me I can do the computations simply enough.
My LCD glasses don't use a vertical sync signal but they have a photodetector
glued to the CRT to detect a right/left image signal. My framebuffer cannot gurantee a different image every other frame so I came up with this synchronizing scheme. Oh it's Patent-pending right now so I wouldn't build it into any real systems you want to market until you can license it. Maybe sometime 1992.
Here's the post:

From: kilian@poplar.cray.com (Alan Kilian) Subject: New LCD shutter timings Date: Tue, 4 Jun 91 15:00:08 CDT
lance@motcsd.csd.mot.com (lance.norskog) Asks:

1) You reported that your Sega Goggles "don't go very dark".
Do you have an extinction ratio rating for them?
No, But I will measure them tonight and get a reading to you tomorrow.
2)
The naive scheme is to switch between states based on the vertical
retrace.
Another thing is that a vertical retrace does not give you a left/right image identifier and it is up to the user to choose the proper "Phase" for the glasses. Also it is necessary to have a display system capable of insuring alternation of left/right images every other frame time. Most channel attached framebuffers can not do this. (A channel is a wire connecting the supercomputer to an external device like a disk drive or framebuffer). I have developed a system using an optical detector and an area in each frame dedicated to the left/right image identifier. This system allows a device to remain in synchrony with images even if they are not alternating every frame. It can be used for projection movies, regular computer CRTs and video tape displays on conventional televisions. It is Patent Pending though so no commercial applications can use it without paying something.
It seems that you may want to decouple the square wave
to each lens from being alternate portions of one square wave, and
overlap them a bit, initiating the clear phase just before the
vertical retrace.
Hmmm let me think about that. Let's get some numbers in here. (Shuffle shuffle) O.K. 120 frames per second. 1.3ms from full phosphor output to zero output. 2ms to switch the LCD from one state to another. (On →Off or Off → On) How about 7ms for each frame to be drawn every 8ms. Now if you switch at the vertical retrace time it will be about .5ms after the last raster line was drawn and it will be 1ms from full extinction. By the time the glasses get to their other states (1.3ms) The first 14% of the raster lines are drawn and will be seen partly by the wrong eye. Also since the switching time is greater than the phosphor extinction time we don't have to worry about the lower part of the screen. So you are right, we want to start switching earlier. How much earlier? Well if ST is the SwitchingTime and ET is the ExtinctionTime and IRG is the Inter Raster Gap ST=2ms, ET=1.3ms, IRG=1ms We know we don't want to start switching any earlier then ST before the last raster line gets drawn or we won't be able to see it. So how about .5*ST before the last raster line? I think that that would be O.K. We also don't want to start switching any later than (LR+IRG)-ST otherwise the first raster line will be seen in the wrong line. So how does this new system fair? We now start to switch and get fully switched before the first raster line, but AFTER the last raster line has "gone out". Pretty good huh? I am going to move my sensor to the bottom of the screen and recompute the timing variables for this new system soon. Thanks.
Perhaps the off phase should be initiated right around the
bottom of the screen, so as to cut off dying phosphors because
the colors decay at different rates.
That's exactly what I come up with going through the numbers. Good intuition.
3)
The right solution for large screens (> 500 lines) would seem to be
bifocal shutters. The top half matches the top half of the screen,
and the bottom shows the bottom of the screen. This gives tighter
control in matching the scan rate of the screen.
I don't really understand this system. Do these shutters go on my face or on the CRTs face? If they go on my face then I don't see how I can control where the shutters boundary lines up with the raster lines. I COULD rotate my head 90 degrees and look at the screen sideways if I wanted to. So I have to assume that they are in front of the CRTs face. Now why would two independently controlled shutters help? I don't know but I'll think about it. Hmmmmmmmmm. O.K. I've got it. After the first half of the screen is drawn and goes extinct you can switch the top half of the shutter to opaque and not worry about it. Whoops I just realised that these things don't go opaque, they switch left/right So I should say: When drawing a left eye image after the first half of the screen is drawn and goes extinct, the upper half of the shutter can be switched to the right eye mode in preparation of the first raster line. Then just before the end of the left eye image you can begin to switch the lower half of the shutter to the right eye mode as we computer above. Pretty cool. I think that this would work just fine.
4)
A hacker at Vision Research Group (another LCD shutter vendor)
told me that the control waveforms should come out of a ROM
instead of an analog circuit; this gives better performance somehow.
I don't buy it. Computer people are terribly intimidated by analog electronics and seem to go to digital ROM things far too often. An analog circuit can have variable resistors in them to tune for a particular application and be much more versatile. A ROM based waveform thing needs a new ROM. Boo. I really don't like burning ROMs.
The next generation of LCD shutter gear should be designed based on
these conclusions: Separate the duty cycle for the two lenses.
Adjust the duty cycles of the lenses for the switching times
of the lens and the phosphor decay times of the colors of the monitor.
For big-screen work, try bifocals.
Good conclusions. I'll do just that. Thanks,
  1. Alan "ROMs, we don't need no steenkeen ROMs!" Kilian
-Alan Kilian kilian@cray.com 612.683.5499
Cray Research, Inc.           | "The Fragile X Syndrome may me the most
655 F Lone Oak Drive          | frequent cause of inherited mental
Eagan  MN,     55121          | retardation". Science 24-May-1991 PP1097
From texsun!sunbird!tellab5!sunJe!menelli@Moxie.Hou.TX.US Thu Oct 24 11:41:38 1991 Received: from Menudo.UH.EDU by karazm.math.UH.EDU with SMTP id AA04432
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 19:23:36 -0500
Received: from Moxie.Hou.TX.US by Menudo.UH.EDU with UUCP id AA02410
(5.65c+/IDA-1.4.4 for karazm.math.uh.edu!glove-list); Thu, 24 Oct 1991 19:19:26 -0500
Received: by moxie.hou.tx.us (Smail3.1.19)
id <m0kaFEr-0002xrC@moxie.hou.tx.us>; Thu, 24 Oct 91 19:17 CDT
Received: from sunbird.Central.Sun.COM by texsun.Central.Sun.COM (4.1/SMI-4.1)
id AA13053; Thu, 24 Oct 91 18:11:38 CDT
Received: from tellab5.UUCP by sunbird.Central.Sun.COM (4.1/SMI-4.1-900117)
id AA13100; Thu, 24 Oct 91 18:11:35 CDT
Received: from sunJe.TELLABS.COM
by tellab5.tellabs.com (4.1/smail2.5/10-21-91)
id AA04478; Thu, 24 Oct 91 16:41:41 CDT
Received: by sunJe.TELLABS.COM (4.0/4.7)
id AA03488; Thu, 24 Oct 91 16:41:38 CDT
Date: Thu, 24 Oct 91 16:41:38 CDT From: menelli@sunje.tellabs.com (Ron Menelli) Message-Id: 9110242141.AA03488@sunJe.TELLABS.COM To: glove-list@karazm.math.uh.edu Subject: 68HC11 power glove code (long) Here's the 68HC11 power glove code. Notice that it does not include deglitching. This is mainly because I think there is a problem in the glove read routine, and I wanted it to be more obvious (for now). I haven't tried any of the other versions of the software, so I don't know the proper behavior, but my code seems to receive a large amount of noise, and it gets worse when you make a fist with the glove. My guess is that there is some timing that is slightly off, and the reduced sample rate when a fist is made makes it worse. I haven't had time to play with it, and many people have been asking for the code, so I'll send it as is… Please send me any comments/suggestions/corrections/flames or whatever! -Ron Menelli menellli@tellabs.com ————————cut here—————————————- ;/ ; ; Originally "power.c" © manfredo 9/91 (manfredo@opal.cs.tu-berlin.de) ; Developed on an ATARI 1040ST with TC 1.1 using a logic analyzer to get ; the correct timings. ; ;/ ;/* ; ported to PC compatibles by ; Greg Alt 10/91 ; ; galt@peruvian.utah.edu ; or galt@es.dsd.com ; ;/ ;/* ; ; Substantially rewritten by Dave Stampe © 1991: PWRFILT.C ; No cash, no warranty, no flames. ; This stuff works great, so gimme credit. ; ; Goals <achieved> were: ; ; Higher speed, smaller code. ; Polled operation is now possible. ; Graphics test (VGA) ; Noise reduction added, gets rid of 99.5% of noise with NO DELAY! ; ; This runs on a 486/25 with an i/o card. ; Someone should adapt it for the usual printer port adapter. ; It was compiled with Turbo C++ 2.0 but will probably ; work on any Turbo C directly. MSC will need library calls checked. ; ; ; dstamp@watserv1.uwaterloo.ca 17/10/91 ;/ ; ; ; 68HC11 version by Ron Menelli, 10/23/91 ; ; A million thanks to the above people for taking this project as far ; as it has gone! This version runs on the MC68HC11 processor, specifically ; Motorola's MC68HC11EVB board. The assembler I used was Matt Dillon's ; DASM for the Amiga - this code will have to be converted a bit to be ; used on Motorola's freeware assembler. ; ; As it stands, this code is a direct port of Dave Stampe's code minus ; the IBM specific stuff (VGA, for example). The way this code works is ; by sending the data received from the Power Glove over the serial port ; at 9600 baud. By sending single character commands, the serial port ; action can be controlled as follows: ; ; Send Action ; ==== ========= ; C Start continuous mode - send every time the glove is read. ; The data is sent with a certain byte preceding it as a ; flag marking the beginning. The format I have used is: ; ; A0 X Y Z rot fingers keys ; ; ^ ; +— Flag character (A0 used for old time's sake!) ; ; R Start request mode - send the 6 byte data packet when ; requested by user. Format is the same as above, minus ; the flag character. ; ; ? In request mode, this causes the controller to report ; the current glove data. ; ; * Note that the deglitching code is not in this version ; ; Please send me any suggestions you have regarding improvements to this ; code! ; ; -Ron Menelli menelli@tellabs.com ; PROCESSOR 68HC11 ; Needed for DAsm ORG $D000 ; Jump to this address to start ; This is the beginning of RAM for the EVB. ; ; Macro definitions ; ; Delay 3us (made a macro because a subroutine would be too slow) MAC DELAY3US NOP NOP NOP ENDM ; Set Clock = 0, Latch = 0 MAC C0L0 LDAB #0 STAB PORTA ENDM ; Set Clock = 0, Latch = 1 MAC C0L1 LDAB #GLATCH STAB PORTA ENDM ; Set Clock = 1, Latch = 0 MAC C1L0 LDAB #GCLOCK STAB PORTA ENDM ; Set Clock = 1, Latch = 1 MAC C1L1 LDAB #GCLOLAT STAB PORTA ENDM ; ; RAM allocation ; BITCNT EQU $0000 BYTECNT EQU $0001 GLOVEFLAG EQU $0002 ; Flag byte for continuous mode GLOVEDATA EQU $0003 ; 7 byte array UNREADY EQU $0009 MODEFLAG EQU $000A ; Mode flag - continuous or request ; ; Port A definitions ; ; bit 0 - Data in ; bit 4 - Clock out ; bit 5 - Latch out ; PORTA EQU $1000 PACTL EQU $1026 GDATA EQU $01 GCLOCK EQU $10 GLATCH EQU $20 GCLOLAT EQU $30 ; ; Serial port definitions ; BAUD EQU $102B SCCR1 EQU $102C SCCR2 EQU $102D SCSR EQU $102E SCDR EQU $102F ; ; Timing constants (for an 8Mhz crystal) ; D2BYTES EQU 30 ; 96us D2SLOW EQU 700 ; ~= 2100us ; Other stuff CONTMODE EQU 0 ; Continuous mode REQMODE EQU 1 ; Request mode CONTCHAR EQU 'C ; Character to request cont. mode REQCHAR EQU 'R ; Character to request request mode QUERYCHAR EQU '? ; Character to request a data packet ; * Only valid in request mode FLAGCHAR EQU $A0 ; Flag indicating beginning of packet in ; continuous mode ; ; * ; * Program begins here * ; * ; INIT: LDS #$00FF ; Initialize stack pointer LDAA #0 ; Disable pulse accumulator on port A STAA PACTL LDAA #$01 ; Set EVB to serial receive normally STAA $4000 LDAA #$30 ; Set serial port for 9600 baud ; (using 8 MHz XTAL) ; (Set to $20 for 31.25 kbaud) STAA BAUD LDAA #$0C ; Transmit & receive enable STAA SCCR2 LDAA #FLAGCHAR ; Set up flag character in buffer STAA GLOVEFLAG LDAA #CONTMODE ; Start in request mode STAA MODEFLAG INITGLOVE: JSR HIRES ; Set hi-res mode ; ; * ; * Main program loop * ; * ; MAIN: LDAA #0 ; Zero the retry counter STAA UNREADY LDX #D2SLOW ; Wait a while JSR DELAY CHECKRDY: JSR GETBYTE ; Check to see if glove is ready CMPA #$A0 ; Is it A0 (the start of the sequence?) BEQ READDATA ; Yes, read the rest of the data sequence INC UNREADY ; Increment retry counter BEQ INITGLOVE ; If 256 tries, initialize the glove again LDX #D2SLOW ; Wait and try again JSR DELAY BRA CHECKRDY READDATA: LDY #GLOVEDATA JSR GETGLOVE ; Read glove data into buffer LDY #GLOVEDATA LDAA SCSR ; Check serial port receive status ANDA #$20 BEQ CHECKMODE LDAA SCDR ; Character received - check it CMPA #QUERYCHAR ; Is it the query character? BNE NOTQRYCH ; No - skip this LDAA MODEFLAG ; Yes - check to see what mode we're in CMPA #REQMODE ; If not in request mode, skip this BNE CHECKMODE LDY #GLOVEDATA ; Send 6 bytes over the serial port LDAB #6 JSR SENDSER ; This does our pausing for us (6.25 ms) BRA MAIN ; No need to continue checking NOTQRYCH: CMPA #CONTCHAR ; Is it the cont. mode activator? BNE NOTCONTCH ; No - skip this LDAA #CONTMODE ; Yes - set continuous mode STAA MODEFLAG BRA CHECKMODE NOTCONTCH: CMPA #REQCHAR ; Is it the request mode activator? BNE CHECKMODE ; No - skip this LDAA #REQMODE ; Yes - set request mode STAA MODEFLAG BRA WAIT ; No need to continue checking CHECKMODE: LDAA MODEFLAG ; Check the mode flag CMPA #CONTMODE ; Is it continuous mode? BNE WAIT ; No - wait and start the loop again LDY #GLOVEFLAG ; Send data (6 + Flag) over serial port LDAB #7 JSR SENDSER ; This provides approx. 7.29 ms of delay ; at 9600 baud BRA MAIN WAIT: LDX #D2SLOW ; Wait a while before continuing JSR DELAY BRA MAIN ; ; ; * Delay subroutine * ; * (Delay proportional to value in X) * ; ; DELAY: DEX BNE DELAY RTS ; ; * ; * Set hi-res mode * ; * ; HIRES: C1L0 ; Dummy read 4 dummy bits from glove C1L1 DELAY3US C1L0 DELAY3US C0L0 C1L0 DELAY3US C0L0 C1L0 DELAY3US C0L0 C1L0 DELAY3US C0L0 C1L0 C1L0 LDX #2402 ; Delay 7212us JSR DELAY C1L1 LDX #752 ; Delay 2260us JSR DELAY LDAA #7 STAA BYTECNT LDY #HRCODE ; Send the 7 byte code BYTELOOP: LDAA #8 STAA BITCNT LDAA 0,Y BITLOOP: LSLA BCC BITOFF C1L1 C0L1 C1L1 BRA NEXTLOOP BITOFF: C1L0 C0L0 C1L0 NEXTLOOP: DELAY3US DEC BITCNT BNE BITLOOP LDX #D2BYTES JSR DELAY INY DEC BYTECNT BNE BYTELOOP LDX #296 ; Delay 892us JSR DELAY C1L0 LDX #20000 ; Delay a "long time" JSR DELAY RTS ; ; Glove initialization bytes ; HRCODE: dc.b $06,$C1,$08,$00,$02,$FF,$01 ; ; * ; * Get the 6 byte data packet * ; * (Places data in buffer pointed to by Y) * ; * ; GETGLOVE: JSR GETBYTE ; Get each byte consecutively STAA 0,Y ; and store in memory INY LDX #D2BYTES JSR DELAY JSR GETBYTE STAA 0,Y INY LDX #D2BYTES JSR DELAY JSR GETBYTE STAA 0,Y INY LDX #D2BYTES JSR DELAY JSR GETBYTE STAA 0,Y INY LDX #D2BYTES JSR DELAY JSR GETBYTE STAA 0,Y INY LDX #D2BYTES JSR DELAY JSR GETBYTE STAA 0,Y LDX #D2BYTES JSR DELAY JSR GETBYTE ; Throw away last two bytes LDX #D2BYTES JSR DELAY JSR GETBYTE RTS ; ; * ; * Get a byte from the glove * ; * (Returns byte in A) * ; * ; GETBYTE: C1L0 ; Pulse the latch line C1L1 DELAY3US C1L0 LDAA #8 STAA BITCNT GETLOOP: LSLA ; Read 8 bits sequentially LDAB PORTA ANDB #GDATA ; Mask off other bits ABA ; Assemble the data byte C0L0 C1L0 DEC BITCNT BNE GETLOOP RTS ; ; * ; * Send an X byte packet over the serial port * ; * (Y contains the address of the data buffer, * ; * B contains the number of bytes to send) * ; *** ; SENDSER: LDAA SCSR ; Check status register for Tx ready
          ANDA    #$80
          BEQ     SENDSER     ; Try again if not ready
          LDAA    0,Y         ; Send byte to the serial port
          STAA    SCDR
          INY                 ; Move to next data byte
          DECB
          BNE     SENDSER     ; Send next byte if not done
          RTS
From dstamp@watserv1.uwaterloo.ca Thu Oct 24 17:07:52 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA04592
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Thu, 24 Oct 1991 20:23:56 -0500
Received: by watserv1.uwaterloo.ca
id <AA29548>; Thu, 24 Oct 91 21:07:52 -0400
Date: Thu, 24 Oct 91 21:07:52 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110250107.AA29548@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu kilian@poplar.cray.com (Alan Kilian) posts a file:
Hmmm let me think about that. Let's get some numbers in here.
O.K. 120 frames per second. 1.3ms from full phosphor output to zero output.
2ms to switch the LCD from one state to another. (On →Off or Off → On)
How about 7ms for each frame to be drawn every 8ms.
That's assuming you've a) Got a Stereographics type frame rate doubler, or b) A *very* high-end multisync monitor and reprogrammed the video hardware on
<any of a LOT of home computers, including the IBM PC VGA card and including
 the Atarti, Amiga, and Mac>
Most of us *won't* be using such a monitor, so stereo will have to be at 30 left, 30 right frames/sec. Sega glasses work GREAT at this rate. That 1.3 mS phospor delay can be fixed with a 555 timer chip, set to delay 1.3 mS LESS than the vertical frame rate, and triggered off the photodetector. Works stably enough. If you've got the bucks for 120 Hz display system, you can probably afford Stereogrophics "CrystalEyes", which blow the Sega glasses out of the water on speed and transmissivity– AND they're wireless. If you ARE reprogramming the hardware, you can set the vertical blanking time to be long enough to let the Sega glasses switch, anyway. Doesn't sound too hard. THe problem is the super-multisync monitor required, which is currently running at $900-$1500 a pop. Just noodjing,
My life is Hardware,
my destiny is Software, Dave Stampe
my CPU is Wetware…
Anybody got a SDB I can borrow? dstamp@watserv1.uwaterloo.ca
From dstamp@watserv1.uwaterloo.ca Thu Oct 24 19:19:37 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA05118 (5.65c/IDA-1.4.4 for glove-list@karazm.math.uh.edu); Thu, 24 Oct 1991 22:23:54 -0500 Received: by watserv1.uwaterloo.ca id <AA05558>; Thu, 24 Oct 91 23:19:37 -0400 Date: Thu, 24 Oct 91 23:19:37 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110250319.AA05558@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu > A minor nit. I believe the new enhanced Denise chip for Amiga's. >(it comes with the new OS upgrade and in the newer Amiga's like the A3000 >and A500) can do programmable scan rates. > The slower the scan rate, the higher the resolution, and vice-versa. >(Obviously, the bandwidth to video ram is fixed, so if you need to >fetch data at a faster display rate, you have to fetch less of it.) >There is program that runs the scan rate between 20-70hz floating around >somewhere, I don't know if it can run any faster. > > Why do we need 120 frames per second? If you can only render >VR frames at 15-20 per second, I think 60fps is fast enough. The problem isn't programming the video rate to 120 Hz, it's affording a monitor that can display it! (B-{)) The idea behind 120 Hz frame rates is to reduce flicker when using Sega glasses: as half the frames go to the left eye and the other half to the right, standard 60 Hz video is seen as 30 Hz, which flickers noticeably. At the 120 Hz video rate, each eye sees 60 Hz, thus no flicker. I don't know if anyone's fooled with 100 Hz or 80 Hz video– 80 Hz monitors are a lot cheaper than 120 Hz capable multisync monitors. ————————————————————————– | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware… | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | From dstamp@watserv1.uwaterloo.ca Fri Oct 25 09:09:37 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA07909
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 25 Oct 1991 12:13:59 -0500
Received: by watserv1.uwaterloo.ca
id <AA11100>; Fri, 25 Oct 91 13:09:37 -0400
Date: Fri, 25 Oct 91 13:09:37 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110251709.AA11100@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Subject: straw poll Can whoever was doing the straw poll send me a message? My mailer ate the last one, and the address in the message doesn't work. - dstamp@watserv1.uwaterloo.ca From dstamp@watserv1.uwaterloo.ca Fri Oct 25 10:47:37 1991 Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA08349
(5.65c/IDA-1.4.4 for <glove-list@karazm.math.uh.edu>); Fri, 25 Oct 1991 13:51:51 -0500
Received: by watserv1.uwaterloo.ca
id <AA19649>; Fri, 25 Oct 91 14:47:37 -0400
Date: Fri, 25 Oct 91 14:47:37 -0400 From: Dave Stampe-Psy+Eng dstamp@watserv1.uwaterloo.ca Message-Id: 9110251847.AA19649@watserv1.uwaterloo.ca To: glove-list@karazm.math.uh.edu Coyt Watters sent me some mail. I tried to get back to him, but the address didn't work. So I'll post my reply here, as I think it's of general interest:
Been following the thread on Sega LCD glasses.

Why does 30hz to each eye cause a flicker, when 24hz (Film) does not?
I believe the reason is that the Sega glsses give you 50% duty cycle on the images to each eye, and a movie projector gives over 90%. This results in 5 times the 24 Hz/30Hz flicker (at least). You can see the flicker in movies if you have a fast-moving white object on a dark background– just look at the edges.

Would it be possible to use two camcorder viewfinders, mounted at
the sides of the head and projecting onto curved screens before the
eyes?

The center of vision would not be a problem, but there would be distortion
at the edjes of vision due to the curving screen. This could be overcome
by the lens used to project the image.

Attempt at picture

/ \ / \ ←- screen
/ | \ not to scale (of course!)
| o^o |
U( )U ←—-projector
"""
^
User
Provided the screens were made of a tough, lightweight plastic, the unit would
not weigh very much, and the weight of the video units would be centered
of either side of the head, so their weight would balance.

-Coyt D. Watters (cwatters@magnus.acs.ohio-state.edu)
Not that bad an idea. There are a few implementation problems for garage VR, though. First, the mirrors must be a fairly special shape, and making such a mirror is not trivial. You'd have to have some way to turn computer-generated shape data into a form to mold plastic around, then get it coated. Not my field, but someone else might know how. The second, more serious problem has to do with the high mangification. A slight shift of the mirrors on the head will cause motion in the image proportional to the same shift in the progector CRT position. For example, a 1mm motion with a CRT 12mm wide (standard viewfinder CRT) shifts the image by 1/12 of its width. And unless the mirrors were REALLY light, it is difficult to eliminate shifts entirely. Still, I've seen military helmet-mounted displays that use this technique. So perhaps these problems are more easily solved than I think. BTW, sci.virtual-worlds is back up. I guess we should take the eyephone stuff back there (B-{
/data/webs/external/dokuwiki/data/pages/archive/programming/gla-91o.txt · Last modified: 2001/09/13 08:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki