informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/programming/gla-91o

16139 lines
671 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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 (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
-- 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) ((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))
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
> J Eric Townsend <JET%UH.EDU@metro.ucc.su.OZ.AU> in
> Message-Id: <199110141907.AA04448@karazm.math.UH.EDU> wrote:
> 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" (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 (c) 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-((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)) 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 = ((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
|> One reasons that Jez San et al write such fast code is that they
|> count
|> almost every instruction cycle in their assembler routines aiming to
|> end up
|> with as few as possible. Writing at such a low level of course means
|> that
|> they have to know a lot about how the computer and its processor
|> work. High
|> level languages and computer operating systems tend to try to mask
|> off the
|> computer; they also try to be flexible which is not always
|> necessary.
>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))
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" (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 (c) 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 += ((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.
--- 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" (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 (c) 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)())
{
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 (tm) 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.6((K**D@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[[=GCW\^_O__W^OTGX( $!DC@@0C:9V""##9HQ((.1C@@
MA!)6R!^%%F98'X8:=@@?AQZ&"&*('8Y(8H8FGEAABBI&R&*+#;X(8X(RSGA@
MC39.J$".(N[(8XD^_HABD$*N2&21+AZ)9(Q*+DECDT[>"&64.E+I((Y6SL>A
M:#!TZ>678(8IYIADEFFFET:=J>::;+999IHPW)"EE',^2: 0=3XX99[XL2@G
MGQ_N">B&@AZ()X]8#IIH?'\ZN2B?CR)XZ)"#"A@I?XV>>.F<FV8XJ:6%5AI?
MIPEFRB"I5*(*XZ>CABHJ@*X6:>I]JCH:ZZMZ&L$JKEK>FJ>IM2X9+)(I[@KH
ML$5"."NON3)+JZ_S&2LDLM-"NZR5U/Z8;7O2 NGLLQ5>"^.V.9)[7[<%0ENI
MN>^)F^2W"JH[([J]PDNHE>Y>*.^Q^T:Y*[OC]IMCOOD)7"? +2Y(KZ@(DRAG
MPYH:S*FO"PLK,7XS!&S$$/,1?/#%V(+,K<5(%F'D?LMZ7*[(42)<\:DL9TC$
M?YT:J[*%$).8,WV3BI:Q?T7 8)3)NOHWZ<OR$<UH?SD8H72SGYHZ\\SU43U?
MTTM3:F^]KTY:Q T<RP=BTS*T]S-_9\= X!"S%G$VU^XUS39\:K?G-GQ-XV"?
MWO1A#=_-K6X-M^!%Y_KUU_TAKO<0;]_'N'M(Q_<TK(!G/'GA[65:A-I6S]=Y
M?&'_3=_.'I+N;;3N(=ZX?403O;I]K^MKQ.<'QF[WU?8M''K!F1/NGND:+NJU
MG+;+%SKQ_A6?(NT$%G]Y>WZC'BCH\@%.;,PD>YHZ\OP=;T3Q@8-_7_0'(D[?
M[N^1WZQ[XIO?;JK87\_C\-_WA_[;*8IO7]T)NB\?W^N#7GWNQKI96<].OH-5
MG8:GN(SA8 8/A,'&,C:$(1CE!N2SG 2#9@.UX6!6,Y#@[. S [4];@@QT%R<
MC" G(4A0A'@BP@>=!@/^O<=\%]25"&=6G**A4( F$XT'*;C!]CRP/1VTFP$E
M!#RM,<MK,>#8URRXHRD6+0<<@X$09I!!(S0M8TTCGOJJ(B<;#D$&',.BKOSG
MQ8W=H AHM ';[B88"A;!*#;<GAOA.#<3.BUC,PA;WHHV@Z]AS8%. ]O&:L W
M-K+0/TW$6?R2M2.O)5&*;U0DG@H)MAMPD83U:UH8K4BWNY$OBM_[FIQ,U;0I
MQN"."G@E((-F!+5],6ER<J4I-V:V5,I);NPC)05Y^;4'SLV1P)IDM1*HP'/I
M<80LM*(0#J?(-KXG8W*:61@YAK[Z@1&4U/S9@EJ)/$"&LHVWE%PNR]G&L/T,
M<<!,9'O<R4NJ91)Q7U.6X")YL@31SYJ<U-L]JYE!Q*719-R,CSGSEB9S4C./
M0&3G0M%9/W7*<Z+TE&<\0T=/*@*4FO(4';^8^3ME0NZ9A_Q>$&[PQBX1U(AJ
MXR0OAX#0+@70FVWT6?V"%J<9XNVB./VF*"L*'WRR,YX_FZ'<]!,Z$0[SD"!%
MIOQ(>M,<_3.E,[ !2\T7MK"I;FARXN;,NMG+;UXSI)N+#SF#>DZY.5*>JCNG
M43JJU78*T @XZ.A',QG2]_6(JE7-TE7+.IA$,G6>2O3E3,<ZGXF>U7T^C1M0
MS2G4]D"T8$;%*5(5NUEA\A*J?)4J DG*3T/ID3TIS<$-RL95Q%[4H!MCK'P<
MR[Z^LG&ME)6K N*)R\G:U9?PY&7]$CK<O696I/$";&G?]9Y_VA.OM?RC:UN'
MO&Q*=VX*/>=C?[;*G\)2HFVU9F_C^DUW@A28L-6K/:.ZQ.5>R:2(HM@S,0G=
MNJFMF@8]JG3==CG:]C*Z%\0FWJ8)WLJ*YEJ6T^\09L;)X":4",2=@2(Q>;@<
MDO6 ME(NR_Y)RID=2C3";>//OLG=]M0PNS- +2CQ*L%7JI7 ;#5P#V?K6[DQ
M^'M#L(%=.4:$8A*!/1+&)(7#6KV/:7A5[@&Q$7_FX7EF;,:TW-@&1?A(]D1V
MGJ^$0= :-001/HX&$&4;#J+XRC)WF99Q^F5C\4KFH&W9;5V>8 R&%J?B"!&O
M-D!D#X]H3#]FS4;N91*5(G>O0:E9/NHSE_H>Z41F!KH^+WOT?PY]TT63:-$8
MYAU5)3V@0W&:3J"\+#3G5>3!)?#3Z>(9O'"DTZ0-;'J,]AVJJ]3I/-4JRFO^
MZWO(&NMUP7=E&B(T$W\-Z(ME.GC$GM'.A-V?68/J1,>F-6F3_1]FE_3(2(JV
MV*B=,&Y'"%W.IIFW!V2]<$-RW#JKY+0)ETQLK]N9N#)WLY6D[>R]6U(A<S>F
M%(5N77O(VJ"^MX/J#3-]SZ^? H=VN@T^)V'+6W94(OC#]S/Q^/RKWZ7#.+G[
MI'%D&QS@\"/IPSK>Z%/+E]\,]RNS*@ZN;]O;T?TB>,EES6V0SSOE X\OSGG$
M)3>)"4X^#[K0AP[TH1M=YMO>N;U8GMQ-DUR22E_UTQ$.\ZA_B^F%3CC-K>XL
MK(]NZL/F^LK!SERM$\[KIMZZT\7.*[0G?>UP-_L^R?Y>ML>;[H*.>]4'95.(
M3]"(2 >VWDU.N!-?>S]C-K'^M(7W@@]>[2KWSQN=-FK!RWUK;@^<Y 5DLJ_)
MUN.//WOC1]N@Y^&G\S?XO+3W?OFE<]OT]T&]ZM_>>JG;G42/&Y#2C,(\S(\>
M09F'M:CBO+FTHC!3& I=TUY(0YO[F_70)]P'5=PT&-O':GAZ,%$M'WW(=_^&
M:@YCKZ7WR(3BR?E-K_W5?Q_P 55V\7\B6D(M?>[;,XS]J>Y0946=-?GS$H!9
M=R=9$GS-I'[_1E%7-A]*0S4)Q3C;@G[B9G^^QB=X,E1I=7T!<BC$165W)X$H
M!R\5:$W3)RC8AUA=M7@:@R2$1B^F0VBYEWZL%X)8\U;-Y1Y_0ES;IR+.AH(%
MPX,SXH.)1X"'9Q_B)TI"T%WUT4)$,V%% X'"!R\$-(0*Z(,M$H5/^#>P-U()
M(GYZ4QP"1A]$(P3V)&:?Q&Q"J&EG553G0X4+]U\W!(9]%7(ATF/S! --XV(#
MY%)=-F4T %W+<H:!!3N24Q]L2'J"J(8*&(?=5C)ULSEX F;VL8<L5C="HP S
M$P0<J#T1@Q^=DX4Y&&(T1G4(LCJ\1GDT:(C>5R1.N"F=>(CO 8#9%8$GLCJP
M.(BK1WB<:(L38R53@5<0= -[!D*TESO_X8GQT8L/]$'!:#Q?YX'Q03O&>#JO
M$D69)%N?%$"%B#G\$8WO08V>)US7>'B]MW[.6"<98Q2<Q%BDE(9S,DLWP'O$
M5$WPX82;Z'+S6&Q*YXZ,A8.U]7*UE8XS!8HV*(<JLBOT*(6XZ'Z^E'T!N6)M
MF#P+&9 7EH(&.';ZYTT,*8D.B8H,0ED9V7=O&':AIX+ QS*M2(C>1&2\AH(0
M0UDJZ3FR6)%6PH+<=I+TX9(-&8N!*"0XR8_O03N 6"O0J&SXAY)@I)(8DHW"
MQHW_Z$4OB88C,W<S,I0B^6[FQ#?<M"Q*68S) V30-5,IHXV[.)*^MQ]7.4\]
M5D@ZR7TTADBQQ5^(>)#/9E465W=DZ1]89%VQ902&QXXSAY=SPX \E$<\%7AI
MYR0&Z7??9R%11C5WDX!QUGZ,N4-VXT"FHI$E68ZV1G?C>'-+TIDQN9A=,XPP
M8I/P!H,4Z)DRV8$GY22F61\Y@"=N%YL%*)HD0I4<*957(Y?W"#04IR2TZ7IY
M@INHF8KV8YAUZ9L[>3[(*8K&*7J::62 DI@!F)"V:7M;<W&\24G1.9:K^2I!
M691S^9WW1WY(\IJ'J9OD.8$"LIT#THKAV9VJUB#$J7GK:2.$QAY,69Z"\SGZ
M>9\S>86)R)H "BGB&9K6*3B>1B3N293RF6]D29T?6*";^: $>9WD>)>W*98P
MJ9BUYIJ:MI\3BJ$-8FU-=A^=\X#XV*&W YX'6G\D29\W):+2F4"RZ2LTRI;/
MZ1[U6:.VN93^N*-EJ:$9:H 2ZITD:I%$BA]'NJ(4ZJ,)*J3"N:1*.B@GBH'4
MUJ "*A_H.8 OJIJ(^9Z%,R*@*2&K*#%=ZJ!4^B,\Y2;HR&)>XD%?(J=?(F5&
M=Z=OH@!X&G1VZB4M]25_ZB5/]B6#*JAZ B9TVB6)ZB8F!"9]:E-[Z*=MZE*3
MND)@<HYZ2JA\J2;-R7FD*1_G]Y/:>*645Z9_*20F\SF3URZ3@R<C=U*9XJJB
M^BFDNA^I6GFWFCJ5%TU8B(9(.#*Q.GY>&I)&,ZK&^BFYZIR DJR9\S3LL:JP
M6H/!FBFD6JO\,35OV(HINB/0VJRB,ZW2RIW;>)HG1:O'FJVW*#@F X^LVJOA
M&JWPVA[5RJ'[@:VZRJZWHZJ3TZV/!*[Q"GJE1ZXC8ZX$BZZ?"IUPJ*_N^J^R
M^J_SFI]!8J_Y:K VN*_[VFL-"ZRYF2$Y&JH\>JZ\PZQ#JGN[RJ_\FK%%XZ_R
M"K((636X^K(*VZ[OH[(IVW)+TK&CRAX%JZNFZB VIRK:NK#>^JX:Z["Z8B#6
M6J\P2[%#6['?2K0I:VZMVHSE.JM6R[,M0I.ER;2\*K,,RVCZ@;(/*Z9!B[5>
MV[2]\R=AB['"FB>[YR,5X[$KN[,3JX._)[(F.SE&@;)\VVMCZYL26ZI<RZ\7
M=+$TB[(M R4X2[<CA*R[FIG?@K>P)+0U^[74RK+C&KC,FJH+DK=/:[D=@D(0
MQH$X\*9+)@1C%IFN5FV82ZHB6YP(*[F4V[<T^[?_8:_ZL;DE:[&?6[2^*Y*%
M5 -$14I3!&/B8HR)R;BN6WGQ>7J[.[ML6[N82[7PH;E+>[9=.Y"'V[8<=WIE
M1%3T)44--D "VX17N[)[R[55BB"RB[VT"[5CBR766[9.B[V_6KF_6YMK(T!G
MDUIF\XUPR+HW^K&,^[H0&B+M6[^@&Z_L8;O^,;^#R[LS2[0ZR[T,@C4W]E_I
M1&#HXHD8(K>->[Z"6Y '>R+TB[;9^[M"\*SP.[W7>KUUJ\ H_([<"K6(&R$8
M3%0_L\%? VX*,+7.I+S::,!52:\\<L(IS*L&\KY&R[C] <%FZ[0&8K+1"[42
MDL-GL\,5-4T7Y"Y 3(Q"[+@]6YV1.VKZX;DV7,4$+,*V.D+T^Y\Q*\/]FL:=
MNGV8&E(TU2A%H&/D*\ BO+QEVKP1#+W;>[E.[+P_MB,GG, SK,;Y"[G]^%]<
MY3Y%(+Q]7*QAG*V"G+F4>[*.C+\AO,;I^;&+_+SV^\DW3,:N6%&3K,?\UZ*0
M5I<[JQ^ W'4QP\A)S,2_2ZKP:*(P/,)R3,6%K+\)\C;O=(.4W(>7/)^P L(.
M3,3B6H6F+,>Z7#0Y),IS2[9,B\O"7(/7_,@.8LR)M3&47%<!O*7WF,E13)%.
MPLU3^ZHJ[+<NK+2E',=#&R#W6\T2(LYX3,F>9)^4Y\?8',HQ7,0U"*+KG,+/
M^LYT_,=&C**_S*P+W<FH;,%;R(Y:G&)!8DC+_- UJ,X%#:;]H:4/_(;X.L,,
MO<#9/-!/_+(G[<Z]"\JIW"!8HQ]9S+_;0W\!W9I@[-!B/,I3FHCVG,L5;<AL
M#"ZW6L^=;+@-#<EJQ8[V-;SRN+J8[-/7!LWKRY5#[<G#/-"UFB))O<W3W,A=
MK<K[$389_)5F16"GN+@_6<$#C=4'S)AC3=1EW;A(Z]$NJ]3VR]26BRR(LTF4
M%[[-RCU4/9]+W+I#_+B,QZ9US=7ONK9&S=(OS-?![->2;<7['%<S0[R*%%P#
MNI/):]4)G7%N^]AZJP#5++;SG(N6C<*%&]/Z+"$_M(=)=39\EF4:'=HCK=@_
M;9?.(KF=F]+Q/-DK?;L1/3O#3=%WO8B>*M#'3=# W+WXAM"YB]KW>-<.W-)4
M<]U(C,;:V]3*RB!?',L@/=TJJJ9<.LCN6]2D#;M0'-+@G;;B#:,S4MZJ)L3I
M6]IM=S$P7=^L7; U$M;K_-_AK=+H7"1N'2#/S-@7VB$&7MP4K,BM3;[Q/=U)
MW,T,K&YU3-=F[<R8*]</B:K8;<,LW,1'3<]BO=7[>N(2#BA<DB;EVVIU^#9=
M]C9!\\IYMZQ]:6*9:%,&<F"ON$))1N0UOFLS]A]=9D,Y?D,]OJD!!)(^GBE"
M7N0=CJ ?>M ZMZ8$FJ3];:&)"^8=DK3/"# DW;+KK:M:^*05XLL+>GU9"]P'
MDJ;L'*732=T0C8A(:N>@RI5;SN:/FZ-RSN>LJYRG.K)>WN6$'M0EFIQU+J78
M">C\T:0[GN@N*N9!BK"2_N"$D\AZO;(D+)D)0N?/M^AW#M3231]CS"!:VR*D
M[M2FGJ%.V*.E#NGMZ>=E9^D,0NNP;NMMCNL>ZNM9+>Q?SN5FZN@;R^BQ;LL+
MA.RPJYZZSIZ;'N;&SI\R2>;5&^< O;5J/NC$KNB?#I,5L^JK=^8OW.V_B>E3
MU1\]9Z@"PNM87A_MOJ=W^LJH$JEFPM/;N";?;"'XSJF5WNB]B=QZ_NQ9SIWD
M3B"FJC1 NIR]HR$)G^Y(-O#>WB'F[O"@/H?.:[.Z:!\='O$83VH4'Y74&Z..
MAR @3_"L$_*\G81CCNJ"Y>QZ<O'^%.P6DO(E#94=#^PNCW X[R\W1?._KO,Y
M\O,EO/#E@S+CF>?2WN<C+^ZY"'5._YG$:M9,W]&&[O$E_.[4?O D[[+CGJ[[
M(?1P?J_Q@_0$DH53_/)V:_$RK[0%O^T^NTRBNJ&QI^_=RXT?G^LBK^4Y?]5]
M?^@LZB%H+Y9@K?00+]+]D>30U*:YI&5O9N2Q_/0P3Y>BCO(FW'2"#LM:G_AH
MWB#HXYAMI&9E@S4Z[?=1F=B5TNHJ8O2_6?C/?1](1R&N[SCPP3?:1$C09?HM
M1^EDGRZ_K^H!G^8KG_:(C^<M'2+H X S2&2FSR*4WO7,?)X2/^<;3[+XT2C!
M4ON1>/NP@C5>94VGC_?ACNUU7_T":-T^LOE7?\ZQ__E[;]KH8\[6%/Z\SZ1O
M_XSE3\Q#_^@?B^X2 O8AOYW6^61&LG,/\Z]1@+_;<?_*ER];$.S/ZPV_<Z?Q
M[M[(&'#'[^9QO/V5.MQ' Q1_8R__$;WS!P!)A!F:)-RO[ DHAL?SZ,/'(Q>[
MPV3TK[MR5\;?U\L5P4_@);@*V&@$8-;K>?E'^"F_-S0#Q0N<$C40PO<9*-0G
M)'">C/"!B2,#;CVXYR%V1UK[@$;A TX^)I@#1^#T*Q*="55 P7'%<>)?%115
M^PT$2A8CN 7)7ZTS+20C!;HL"XC]3(09-&A64+Q\0"WX!???N#-S;>_J1< Y
M6/P,GMYC>_&N/NR..W-7=@<?-$\W$.HY/#E(C":@RB. =!Y+8I#Z/GD'H+8
M'2&H$:8/&E@)F2"+@'?!QN95"$K(HD $"_R!+E#J.3C:]CZ4CVNI@2%088BI
MN&<"/Q^WXWO_KQ V/-FW]%1@Z*J%:Q"?J$$O& F[H.*+A#\BX26*,=C&LM\4
M_'O'L&;9PAXT0A[AU"-_OR]1.,-LMP.M'QU\?P#M#FJ(L!';0HK?N"7>4.9%
MOP.8_OY<QB-\UR\"<4(#6/%\G 1)/(EGR]B-*=-2/,8\3(0A0DO5"%9(_+">
M+ZQZ0% #JL(E<1#?FKII?P?H\IE#SI<)"PW[VX<2D1D."NI$IO9?J"MY=H\C
M)@EJF \C8J^;A?RI(A+"$M@CQB$)U(@W,;0-PP*X :D@E.J#OHP7TD.;& P-
M'@6\9#L1"&Z_:%;=F*!S@X-4C^5M1(=(!OF?11MU;]!"*$%+:(_\WSU$A%01
M)8+$54@/3\16'(#X219>0K#H_J2B2NP8;/$:ABG*]Q I8C&,$ Q1_\F]CR@%
M Z#;815P#<Z%O9-H%5,B)B0]+/$<ND2$^!6M'3C,18-1&H6[U@<1>^),;(NP
M$"Y:/9\H_4(@7<2(@U DBD ;$09%1N%+BE]''0;"KN@&HUYEK'R3+L/D17(H
M#/V<'8R+7#$5?L8@V OKD3'$C3MOE(W%CL@8/<2\<W=#SDUEJJF J.A=F\A&
MGE#).4<SH>,&8M'Q.?MA.HH))/BE(.',JW9-;]D-.TT7[4:4>"QID=&@M<:B
M]QJC(Z([C]^PI:7'9XC_$-KMV&3PL=#MNN!8&)5=L[LYH9'3.0O_5$6FW<'I
MCS1Q"8)'\_CM+IV-@DI$\>25QS4GFF1B9VR0CC$_9D@,&1XY)%XTB>A/ D;#
M$#4A%61"%%/I,;UYQ9?E( VDB,2)_C$[N<7#N.<\)(5<=*A11Y%'#=DA=Z2O
MBY 3,49".QXY&G7DD+21)K)$5J@%>2.'4_D#A+YQ)@9(T\8D=2-R>W.7,2-*
M2(77'E>DD,P3%0,_"KL<N1J5Y$_TD2\R+&Y))+DD7>2Z4Y)2+L-4R39I)NW#
MDXN21+))HLD6T:G$Y)Y\C_CBW07&+.GV8"372Y C+D^6#)2H_^:CEH2-#N+5
M&<HBM7>F9*8[DC4O,[Y$3&D\H*-ZJY/%2E-NQDCW"3=(F=D8*<1)@<JYIBC]
M@U)I(T( NZC'/_DE:R6,""ZC!,/X24X)*//$^VE;N[)7\DIF\4VR8'01C*ZQ
M-Y9#L&@I9^2&W),R"*_D"_-7%!L-D)24RY+9+<AH>8$NI; TBRT04H*[1C=4
MI&69;)6/LAH&RP-4+D]1<:24Z+)&%HDB-/JN(H*$EVSR3/()+L27_IGVZXXA
M,E_*2WO18YB*':HES5)5QLMA=9<ND",R I (["5+8 @-CUB7O)?:TDTB2XP8
M,#UC5+R/ !,MTDI2N3!/)(#4F'0/96J[NO@6DV3)%)##DF0*3(:I,NWAR[R0
M(Q-?YLR,N2IAYK?,?(YR5-;'J'C=;J:<K!/4\AZJR*>H%UNFOOR9,G-GCL>8
MJ3.I)L\TFM[25E9-J+DUM>;5G)FL$FSZ3*\Y-;GFUY2:Q<Y*/<DL=2X'7\)4
MBUB3/6))(0@N<^-1?)OO\FQ:S;))-M-FS\29>]-OQDVF.#A3YM\\FH<S:T;-
MP#DN&6>+3)QOLG VMCGY-/MFXS2;?'-Q8D[!*38!Y^:\G);S<4I.F]DY$>?H
M-)*?4W263L79-35GZ'R6<Z=;,H@[DWO"BJ>\#S.$/5"9J)8@JIR7W#5)A4'F
M3-4U.T],0)03B6=-NH<>(A!;1VA4,N.MVCP7PIDO<X"[W#RN"J&L$FZ4*,):
M#%E9]0;@F(O)@S?=X^O\#^F$02BA1/)!4(^S5%H<(P0=BO19#\VGBJ FM6]=
MMHC;&2BF22(Y'(KH0\9/6#FP0,V58U_5J&,Z3A[A@^P@Z@&@U]/Z#=!T8E9@
MXP$M'YFDIH5,RT@LLV7G<Y\TDC@VK-UF P=(=:QSU 1(YLVL-D4"B0,I&P3B
M!N$Q:3E#8( E0R!^0Z:$$L;Q.' #+55EHHO-1_!ATN^1E()#7+"AD;.!NDZ
MZL=4FS0KRWQTMGO"!ADE^7DC>>:<F),GZCB&"8_Y1 HT[662$O(_)T\)W92I
M$W>6D\YC_$:&^< 3^!.:=(KXXS1JP(VY)6J)1GE1\R47PP7;D $/-/7 Q"#I
M.AD398F@EVR=Y(IULHX"5A152R1&L:#/F:)B$--*N2_4I!39S]9I(PXI&PH0
M2D.1/I),&G@64!F-I(5$?% (8,(Q:M&/R#'_K,%T$M'(2:T$'A6BF_3_49>
M1DUD)U9THV-4Q-2/2L3U&A#_=!#?Q1T=CA-:.9U%TWA3%"0;40W'I)= 2@*"
MBKFD</VS6_J"7M@&^ITR$+@@SPLJ]H;E+<6EAY*:-K[0PDQ-S:1@I-L4IZ!3
M;RI<NFE95(3>)*JTT^AY/B6+.1%(O:UP!#8E8CYT6HV@HV4T5/U330J3<! /
MRA8W1I:2PEFY0,V2,,VCZ4\)=1>VEGH:F",5I$4@CA[2$#H?!JCYT4:F(Z+&
MT92G/S6$VL 360: UAJBL;=DZC0))*BD]MD3.,JK9D89<3/\JONML!U!AJI/
MF,J>./6+BDO5N22X4&QP&SV+0CR^.'$X7 I?D@&=! ))HCLCAIP&T1@SJ91Y
M< B3\?CZD$!Q$MF$:% %&L8V5.@]M1)1AG&\D2/R/L.*34E=?0<'Z!@B(/D.
MQ)WI$M'4LLP3=#17?1"5@0&7*!,)GD92-_3J[.BK>K*B"D_)&EG3:(^DK"YS
M=2Y1M DZ"VDMS9R?E7-R5J:*6>GDZ528FI5ZCE;8:5DG:VNMK/T4MGI6O?E:
M,^MJO:RUU;2F5L-Y6C]E;_V=H;6S!E?2FEN;Z7!EK;'5MI96XTI;DZMNO:VN
MU;DR5]#:7&<K=;VNHG6Y#LSBNEVE:W>UKMF5N]),R*E:M>MX_:U,$[VV3>@J
M6X\K;O6NYW6W3LZ:B3KA:]ADK\I5O-Y7\[I?]>O8!*_"M;JZU^@*8(FK??VO
M [:]"M@%BUT#;(,UL 46N4;8]SIA"6R"S:\'UG-F6-,I7TDG?GVN_!7!,MCP
MNF%9YXAUL"2VPBK8!RMA+RR(]:\:5L5B6!G[8DOL9@VQ,=;%3M<4JV._:X^-
MKQ_V3(JH)M<$6:9[V*?E%<9R6/S 4"4'X\N*9]1IUE</83T4J]"444#CV 0+
M5ZHFR^E]0+*SL8_:"$2:.HQ<)(FR\T1<0 RRTBUHU+# -'T0C?()6?FI.,8Q
M=1!(ECW0V2+!9NFFD;40<-8[&D6IXTC&41JA$N3CC-6'E1(ER K^.!)AEC^H
MCU/4.%IJH25"O+6*6C3ZAR0\2E&Q'=?41J@/6:E/BJLC.7UH=H6.PJ+B+CAM
MH@0=#\3-1!%3&1^29[7( 7$"A3".Q&-/R6RFK1".1,>E6@_*-$#'\?*U8?2L
MW0!;\DCLR*RPLOS4B-R-//I+T,<>N[.\,4<4 4A49P0BM 4?#0/7@HTH D%,
MR.KH,>7&I,R?9BM,X4.3%9EX2<2X3QUJ-^QH5HP2;F-Q7)%$\CKZ'9+ =/6
M?:J1ZL5&3,>Z!2^LEH/B,'E;1OT'7)*SE2*36K/=\EE ![:]8 Q7=2".)89L
MA^!!*2N?*)]TG*$R Z8H2-D>UW.32=QHN6B0;(AXIA27VI[<BD5.S]I,<1VZ
M\\D^O!\Q5'* R;6J*-??<E:)&WXT[;!-=B37Y/(55E5SLTX#HAK_M-3P7'0"
M1[6I.NFX)G8;#10UPPC=+=R,MZ+DYTH^QW=OJ8=8 ;F:\5/V7#BZ=,$/UGVU
M$.Z>\+%RR8Q4K8!8NV74R0+=2=D]B(DEB[I_AJ+B#KG!=AW)S$VOJ$KN"A#Z
M0U9(!]X]O. 'WOH[8C)BCB4)V7RH8J@<DS>R.B"OW:02( 6&TEVH]&Y;A.8M
MO-=BXTZ=A$) )(S>8!5J::DB",V;2W3,?:%<A!174!/V4#<&R5,KO2J"]OY/
MTV51VMFR?7A!1O+IK$C+9.]&Z] QT!-R])Y="5)Z;ZP4I*]HD#HWX;O'HDO;
M:+KX@:Y>,[WA2_\.DE@A2L/<-A-[&ELA2%2*34&C<0Q0/'D^G*_=@+Y6]NU^
M7O#+),KG?*T0/Z1PS TK"UFS[8% OT?6_"9<(JH8ERQMA+!UDV)Z"/_[9W4/
M'_.M2H[YVET><4#<B^LC'=WWZ](V#4QLS=&LD#<+1O(N"9=+2R?PQ6W!ZTO"
MV(L4W%)/+ 3.OKC5"J'8'7R#62R%_;']U<8F62'\:W&L U:R69?'VN 6NX1_
M<!.VL$]XQ2IA'PR%J; 4YL%,V K/6" L8K5PC:6Q.Q8+.V$O'(9[\!0^PV*X
M"J-A,YR&KS ;?L-9> W'X3:\A:-P'2;#/M8.?V$NG&/U<!F>PW!X#,MA04R'
M][ ?SL-X&,@:X21<B/\P(0[$:K@1(^)!'(DAL1L&Q//A."ZJ30RGO,2CDB#_
M+E!1*C21J42QFRA4@'53&:IVQXGGW2=^Q6WJ.G*J4%RI3#$J[B&72A4KJDYL
M//-4F6A4=>K??6)33(QU,2[65&+"7>0,!U;+$EH[O&P":'N=M\WE4765H(MP
M,NV35:M!R=U6W%*3;9_L?6ZH::S<B 0V#JJQ41K[- .ANUK1-2YQ",Y5Y;5#
MIN(*'#RF;[ JL?%?KC?+?$0SEF\23([U-G7<+!I<*7O'+"Z[:9IJMMTJFS?N
M:X<GGX7CB<&,%]MW"\@H;" W,[9%C@\RR1IJS_C%[;(*!^=>FYZ8;W,,P7G8
M;->1V1LT]E"KS;<]Y-N!D)=;>]-N)'FO:3)S?(]3LDB6C"CRO4VW<^RLY M!
MCF[_>"B35&:(C6.R<4MUU.W"G6/W]E:Y9$M.:"9K:.#>=)S&KG)!6U<_["-_
M8P GSP[9*4QN"7F"J6392Q:]LN":8A@YB6GDK]620>G+0LAC.1Z7Y?61-&&2
M24;)$AE<H9J*/"G@F$M&:=&X*Y\OC_K;OO)2MG!Y6217L*?<E]?;7X[+OVHR
M:[:U$0-&URO";3, =<U:R&@10]PORW!Q>2ZKL$%ID,4:7H;(S<7%96/*/!GU
MWV7^&UI9+?_D453)I)I7 1O&J^01YIF,F+'70-;''TTHM^,W])JE&)& ; BN
M(==CQSPSX#)SJV\8-+J<#<+&7T*RQ/1J%ODPHV:%&Y/=LN[*4889-NMEVNS+
MK$9Z!LC7>2T/"$%2/_2#__(E/6LXV^.T7+&$1T4SSW>YCS9EJHR4)R.$D,H]
M.3!OYA")Q?H1#[L!+T,_4V=WA<]2,U>FR\KY>EVWYER<US-IPQ$(FC_CX]V,
M,5=M6LMHW**'*2VWK)5%M%R^T/'LO+5HURR6U?-/1EF]+,6Y-N(\GG4S*$M?
M,J=!:[ MIDI6M$-+@TK91:/C$'B41PB23LKGN4:_Y*_5[P*<CH9HM_F45>F)
MK)#Z42M+'1<8H@VP MV8,1Q@WGSO*P/)Y/W,G*5T<5;3.)D>[V@V+;,J-#BF
M6;4C#7WI>GOTUO2$MM$ONGN5YPSMD3W5MNK1'AH\MV>F-:,!M8+^5WG:2R,S
M&I8ZVJF$3M*1.5 7B_],J&ETB!S0<?I*P[F7=IH!,X$>19KFF,V39/;" #1_
M/F-HFE,K:N+,1F$P5H[+3EDHF\\0G:D?-3BS>OQL3SL-5RO\7'6@.-.)&4//
MZ@)7C6FRFT;4-WHO\RAN[)#I])0>T;.Y!&\D54W.]-@_(\W+.E^QXP0=JYOT
MPQK7A5JK96JG/(]%M4ZVUAT:6\MC!F4O]T/TN&GM-I&4T+]%R\+SK<[4JCD;
M8\G6;(\Y-+2N7)D-Q5&VZ8RIU;.B;6X$XEX[:*E60G-TN&[8USI0XS_DH]HX
M<J<NV,^:<"D Z/R3I?.<_M,EQ51#[ $AL06K=MX>[+!07.KE[*CWDRXTUZ8Y
M70,NFTS-3K7)QM([63QK.!(]GU<6;LL5:\WSKC=C7;-+M%YFVL[:ZH'J^O:S
MJ1:O=M2G.M4,5,L1CX0+7]$?,[M4M[BP;)QAM,#^V(XY-ZMK0)VK+S8,OMH9
MVU>#,BLZ6SA;(OG-],4&ANV@99T!=<#N6W5YHP5H0[VN??;$7=@G&V/':Y^<
MK3M%;4O%OBC).!#=)J;?VWLVTYBY7"MF;,:8:?5C3EB%6V5I9K==K5'VXL[,
M'&Y!4XEM?!&C&\V.VYJ;8;'FG.VIUW;&'JJ&6TX#;7B=X=2VO.;2+V=O"VT+
MS:21<]6ZV*_;%(5LL'R3J79.%GY*K6\'LZR->+\SF>;1R-K@#6KDG=S0<X%T
MT6W[>G,]]_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 XE5OA''P1WU@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]!'&P**0\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!\()N[[M[,PSZ<[GAE_7_
M?M13_M'?[IW^VG_]?7_RPW[+[_IC/^K_^D@_VD/ZQP_S4[_LM_W6'M67_@J,
M^Z5]I*?G%*+Q=WEXGN8=/MC'^*I_]K-^Z/_[:7_T!_X/7_<[^^*_^YU_[O?]
MMY_7A__6?_VM_\H/]]8=^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 SR3R**U'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=)
MOECOUNOYQKRD[[<K^)(:3ZP=B_FVN^XC3!9CCK:'+^L;XAUVE^_:Z_;RN^5L
M[ROVGKVT+]&K];J,P"_+"\N:OE9OT[>. KYC;W2K\4Z^^5WRV_9*O]?O:NOX
M%K]%W.2:]ZZ^9:\DD6EXO_*.!VC^!F.,(YQ7B]5BQM@M=HNU8G,*+V8!TGFO
MF#"V_H: E8K[JXLU%"P&CBOWO'D 3RXF ,>_CIQ%6+9\K9A9[C:KY#6T*R)3
MNRUNN)LZMB:,L;CNOA&JQ37,BQ"HOOB1"7!70P@Z- WPW:.S*3'/&7%SMDF1
M$8_<9J51A!T;O(;A4KKY&\?&D"DV(?#*\\842)F;0J:LK;QERA(QS.2BS"#O
M)BJU;_6@ @R>U< #!!T8I;%MLMKK.Q5Q>2/:Z#:2!<&F&\*ALB%P(#"!F+S5
M:K=;$USA*G3%B0HLK8F!)IGZ>05'9S3P%^P"8T(HV?8F\E9Y.((8S)YY;J71
MP-$!8\%'<*:KN''!$##;LJ6ML3N0JF(-7<!D\#;S%#JA=S :3*'.*T@PZ :R
MP69PVN:V]@G"Q! AG V68SP:(AR?K68US,7FX8V(.MM$T[SMP*5G"FP$?\!K
M,/.ELAEO4W 6O,O!)Y9(F\8$-VF+Y ,AFDV&C4*:86?P'Z8PS0*DK8%(S!#L
MM;2!/MH,+,0TPL+'%LP&XVI>\/'+:NF"[L-NFD9\-M4O$#IR6,)0VFF6&4E5
MB7#)E@;OB\IP#DR6+0SL@L JC+83BD1G,M'];TL#-MP4:H,5[AGL#1_#/*\-
M_ ?;.49/P%:U!9QA33!-?3">' A+ 0'"_)PMG:QP2/(L*LQ K?!8 O<(L A
M">.@^6 ^Z% 7!,?@+@#$BK (LYS!@@Y#-VP0HR\M<(&6$ \B"W%J0[*=P!!Q
MBG;-3,3F@R)Q$2>^<K#E5KX)P1SP)ERS1,*>,&79\AUD-*!=(PG[/Q%Q_'';
MML2)[67D,<3$T]K?F@T'PS7QV<+"N,/FRDBLAG0WZ\_@U@73PM&L/W,+#5PO
M;S4<"TTKK#!62 <[#*+@T/81B\4?"S)<Q);$!QPI;.+&'M[:5KP[=*SK7=.!
M% >%^)LL-R(4Q,:P*TRYFFY\,#[<#,.]ND=<;*;.Q>"#,=G-W<5H,6#<]&$(
M>H]'W!?GP?2NYR8.JS05#%&D%1_&NP:1NY%2<T:P0/RG(< V\60\MS# BB);
M[+[(9H#;S6(8*Q_.)6CZBU;" ?$EO*W PTTQ ]?4H,(B<6I\#_^8); .'*.Y
MQJ"4#*6L[AKN$D8\#Z-!(?$>[/P^<Q[Q+ZRP]<:O,,7RGUS&T1K-,R*0A>,,
MO65G&<6#<$,#!&O$>3&59;%T+J$Q4R@5WQ!*L%7<!V/%J:\;(A$/Q5R&2UFR
MA,<VJ39&N]'$P U?K!_3PP=0.!RZ_<2%;Y>&5E@.WC' B-O1&^GQ4KP!JYC^
ML?0"(..]SC%V?!:#,*8#UF!]1!=Q!0OADV0[<7"#_ YKP_=29%P:_\=9\)\8
MO\W"WDR3>[RAC.ME-R1<.*A2A-!5+7U\C#%:.)0=PNIC$B(9H\B\ R/L&S_"
M+QE./!R[QO3%C2(-_Q:V0P_<#M?&@(Q6&-)HPJ?,X2*;563K\1HL(S+$\#$[
MPV< 74:.I1)(\'3*\5D\"/IC(S)3'"YTP&'Q"DP=@\(F32QLC0W(;C'TBTKB
MQ[^+=(P7E\&Y,3%\X"S'E+$L)""SR'5RH,L6'<4G&92<)C_(ET^$W,),R*K6
MH'P5$\C&+GND<H (.?)^7 7'PS^RA.P7YZ!"S6_,#$MCS4N9;!K;QIDP0=PI
M/\HB#$(\)#MF%G+#DK 54->5J0PDB\9OF> F^F8_J[+14A%J=Z^R4A:7>6=N
M</07IX!\4\Z0<\-E"BW<D1.RQ'#0,H3+C6!P-=P&MT($"!Q<LRQE>' 0+A 5
M&3HY:"Y_6BW?/M;R#1?K5LI,+Q#Z%\_&UN_O6^9FO\.O[XO]HG_D;W'K#-O+
MH,+X>_NZRP<NO%QN(AW"+_>+^]K)\K*8"/(PON"OR]LO\[BWKN%+,*.QZG*.
MZQ5/L>MRUMLP.[$_7<D;+R.^\W+'K/UJOI6O %DO+\P>\\9L&^K+.NS/JS);
M* #S9UP/&[WQL= K 1UJLN_V&_0BO1?S8ROU-I #21.Q*\^Q,O/#_.<POQSO
M_[GPMKZS[\UL_.;,QN/('#(/S)EOWHDR)\SM<LF,-#> 88*^7+V4%B/@O?S
M(2H4,BYK^JH^KZBVQ<NA'4")G R"FKF>7/ Q%*I\HA,TVOF6)!7=0!=55:.)
M;O@G-T/-[V;=3#3)"V3>:KLWO\LC)]$<-0?.,?-:]!Q7S-8CW>LT@\H/9,%H
M-"=SC]WD#'DZSMS+H['ER1N#<V6<-./('%3 ["Y6/00(55PV.\P^'6XF+XC.
MU0+B[#-USN>GTQB51"I8AF?6"CXAAC.SYSK_C[ SQVRO]28,ANMP"RY]]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;$+?%?3//U^CVM#UQ"\T,KL1=<3?<[79.PW!_W"?WR,UYE(6R-:#M<:O<
MC6*N/5OOVHZV9"+IVMNT=<W=X=[<[[;!'7$CS0CEE$'VE-A0-;B9D;#/*;>Y
M?7$3O\;'>.UP7-B$;<;=(.A;8RI8/7,'U]SV_N)1M%)1-\6M=!-T5@0W<2ZO
MVQTWV5UC,R&$;L*]= _<2W?8[61\W>EVP-UK9UD.U<L-=]O=/7> YW9_J$XU
MQNUUY]WSV>115'77-3/.37/7"=]%9P,#P)CG-='-5K=79FMBI7,7W>KVO.US
M:]QQM^&-=?O:<[?<;6(#V0"WYFU@Q]6C-Z_]>>O:FW?EC7"7W9:WR'UWF]T_
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]\NM__M?,/?;/?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"))"-/!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?((+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_A//V_?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/O__992#>O02Z0DY?@/NS_;"_DR!?8 %G5
M&[.K1+Z7\*7'I9ZO]#O_DMO#$_@)X4\_T$"2/R;/UMF0^=?[=COZ_\V#]]O_
MO)_8[["C/[LO,A'E.YA1GNIS_YLL_2\?VO\3O^2?=QKR[K\TR_#/_R?_>_=E
M5CARW3H*V+6--^1_@A@<4,Y_VK^$7P!0W(?_._@1 -M_NC]R7P90WR?V\_A!
M_!Q^2[^%W\// T@";/Y- #6 Q#\[4Z]+2"#2@\4=GW(@GP:D6N./ _@![ ":
M #> T#-'P7P!$@#+ %V^WR @#_U'P8P!=C_TP&B "^ $D <H @P!*C2$GJ$
M&]Y',\#FVD$B\V!MH_J! "N 53\DX,M/")@$) +N )6 >3X#H,D/[_<#O %Z
M 8^ 1L >H!E0"TCOBP!N =V ?R,FH-T. B@&M!89_B ]."XZX!VP#5@'3.*Y
M_=Q]>Z3&W)K@,:>IB,QM@#Q UY'0W&7N_@6HT,Q=*G(NDCD"6/P+ 9W^O"1
M"?!K= ?Y'>AN1&>_JY+A[VAW;@RSUFZ.!UCS\(5U;(QVV+L#GE\#4%:@R8OH
M 5$'T;KD3-8.9%?Q8-YYZE@JU#S7R?A.<G>N.]1YZN@/PQP(%KW."V:V"]WI
M] QW/;J2 OO.C1-,2X58ZA1V@AO1G;ZN:_>PTV!=O>2 U;N/70'/;K<J&]DI
M-MQY0+7FG,PN>=<)E&'8[%B!3*$4DQ[0-U>T X9Q H5S9;%5H)GL&V@#+ ,Z
M'G:!R0WHG*# %KB^6YSML;1S-@3N'$1*(97@P0?BZ,9SOL!^H&)L :AU<<_1
MJ.!SU+!TGD$03,?^0P;2YE!C2)@KASFL0*=B8!LH589V5CH=V> N4V? (VOL
MQN9WGS(/TI4C0R=)<4]UZ&Q8SH1GX'>$')@*- F6%(9UYHK+FOZD2*>ERQQ8
MQ))T&)K/G;VN25<.;%:@QY*!UL P((6,)PBN\Y#-Z,AV.! !73'P'>A$X =6
M9#XPN<!B1HI&**:A\PF&1I(@Q,#P'"U0U6(5I ?V 3->N+IF75?,;S01O->U
M]\J"0HSB3A10Z^*G4PMNNP)U84$"7B?B>E<2S'"$QK9W2<&Y&5PL4A<DF-3=
MN6!V';M"4/D.]]?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:H__H1\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^DGS9%%A%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 S%%U-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,
-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" (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 (c) 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-{))
--------------------------------------------------------------------------
| 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)
- 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 (tm) 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."
Reference in New Issue View Git Blame Copy Permalink