💾 Archived View for spam.works › mirrors › textfiles › programming › gla-91o captured on 2023-11-14 at 11:50:03.
View Raw
More Information
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
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,®);
}
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, ®s);
/* 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, ®s);
}
/* 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+{body}lt; %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