Hi all,
I'm new here and hoping that somebody can help me with this. I'm using ooPic-R which is connected to 2 sensors and a SSC-32 servo controller (with 12 servos). I want to make it learn how to walk just by sensors and without walk sequence. Now I need huge tables.

The ooPic manual says that i can use object oVar3
http://www.oopic.com/ovar.htm

but the 6.1.1 oopic compiler online understands oVar8 and oVar16. I need a table of the size 729 by 6 and each cell has 3 values -1, 0, 1 (preferably, if not possible, i can settle with 0, 1, 2)

What's the most efficient way to store them? I read somewhere that you can only store array of objects, in which case I'm out of luck because there are only 86 bytes object memory.

Thanks in advance for your help,
Harley

------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

You are going to have to store the table in the EEPROM. Even if you
were able to use all the available bits in the regular RAM space, you
would need almost 1100 bytes (729*6=4374 @ 2 bits each). If EEPROM
space is limited, you can store each row of 6 values in one word (16
bit) variable. I would then write a function to call out which one
that you want. Here is an example:

Dim EEPROM_Table As oEEProm
Const TableOffset = 10000

Sub Main()
EEPROM_Table.Node = cvE0 ' or cvE1 if you have it)
EEPROM_Table.Width = 1 ' Set to 16 bit transfers
EEPROM_Table.NoInc = cvTrue ' Do not automatically increment
End Sub

Function GetValue(x_Index As Word, y_Index As Byte) As Byte
EEPROM_Table.Location = TableOffset + (x_Index * 2)
x_Index = EEPROM_Table.Value ' Read 16 Bit Value
x_Index.RShift(y_Index * 2)
x_Index = x_Index And 3 ' Clear all but last 2 bits
Return x_Index
End Function

Sub WriteValue(x_Index As Word, y_Index As Byte, Data As Byte)
Dim Temp As Word
EEPROM_Table.Location = TableOffset + (x_Index * 2)
x_Index = EEPROM_Table.Value
Temp = 3
Temp.LShift(y_Index * 2)
Temp = Temp Xor 65535
x_Index = x_Index And Temp
Temp = Data
Temp.LShift(y_Index * 2)
x_Index = x_Index + Temp
EEPROM_Table.Value = x_Index
End Sub
This code compiles but I did not test it to see if it works
properly. It should be able to read and write 2 bits at a time
(enough to represent 0, 1, 2, or 3) to the EEPROM table at the
location specified by x_Index and y_Index. It will not be really
fast although your application of this does not sound like it will be
a problem. They say that the B versions of the oEEPROM object has
some trouble with two byte transfers but I think you could rewite
this to use one byte transfers. The Table offset is where the table
will begin on the EEPROM. Depending on the size of the EEPROM you
use, you may need to change this. The table will take up 1458 bytes
so you need to keep that in mind and if you are using it on E0, you
need to make sure that it is stored above your program location.
Good luck.
--- In o...@yahoogroups.com, trungtuandung@... wrote:
>
> Hi all,
> I'm new here and hoping that somebody can help me with this. I'm
using ooPic-R which is connected to 2 sensors and a SSC-32 servo
controller (with 12 servos). I want to make it learn how to walk
just by sensors and without walk sequence. Now I need huge tables.
>
> The ooPic manual says that i can use object oVar3
> http://www.oopic.com/ovar.htm
>
> but the 6.1.1 oopic compiler online understands oVar8 and oVar16.
I need a table of the size 729 by 6 and each cell has 3 values -1, 0,
1 (preferably, if not possible, i can settle with 0, 1, 2)
>
> What's the most efficient way to store them? I read somewhere that
you can only store array of objects, in which case I'm out of luck
because there are only 86 bytes object memory.
>
> Thanks in advance for your help,
> Harley
>

------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Thanks a lot!! That's a cool way of making use of the EEPROM. It's a
great idea to store the 6-digit word as one variable.

1. How about taking a 6-bit word as a base-3 number (digit 0,1,2) and
convert it to a decimal number instead? My concern is that, your
method use shift operation on 2 bits which is probably faster while
mine below might be slow due to multiply/divide operations. Should I
sacrifice one more bit and use base-4 like what you did instead?

Dim Leg(6) As Nib
Dim Index As Word

Sub HashToIndex(Void)
'take a state from Leg(1..6) (eg. 012012)
'and convert to decimal. eg 140 for 012012
Index = Leg(6) + Leg(5)*3 + Leg(4)*9 + Leg(3)*27 + Leg(2)*81 +
Leg(1)*243
End Sub

Sub HashToState(Void)
Leg(6) = Index Mod 3
Index = Index / 3
Leg(5) = Index Mod 3
Index = Index / 3
Leg(4) = Index Mod 3
Index = Index / 3
Leg(3) = Index Mod 3
Index = Index / 3
Leg(2) = Index Mod 3
Index = Index / 3
Leg(1) = Index
End Sub

2. Last time I thought sByte is the only way to store var to EEPROM,
but i realize sByte doesn't work anymore, and there's a better option:

Dim Relevance(729) As EEPROM Nib
Dim Reliability(729) As EEPROM Nib
Dim Weight(729) As EEPROM Nib

As you see I need to store corresponding Relevance, Reliability,
Weight (and a more few more similar columns that i'm trying to reduce)
to each state. Now that I hash each 6-digit word into an index
decimal number, I can get a round with the 2D array. However, is it
reliable to use the variables as declared above on ooPic-R, compiler
6.1.1, yet? Or is it more reliable to handle the oEEPROM object like
you did?

Thank you for the quick help, hope to hear more from you and others.
--- In o...@yahoogroups.com, "tinslwc" wrote:
>
> You are going to have to store the table in the EEPROM. Even if you
> were able to use all the available bits in the regular RAM space, you
> would need almost 1100 bytes (729*6=4374 @ 2 bits each). If EEPROM
> space is limited, you can store each row of 6 values in one word (16
> bit) variable. I would then write a function to call out which one
> that you want. Here is an example:
>
> Dim EEPROM_Table As oEEProm
> Const TableOffset = 10000
>
> Sub Main()
> EEPROM_Table.Node = cvE0 ' or cvE1 if you have it)
> EEPROM_Table.Width = 1 ' Set to 16 bit transfers
> EEPROM_Table.NoInc = cvTrue ' Do not automatically increment
> End Sub
>
> Function GetValue(x_Index As Word, y_Index As Byte) As Byte
> EEPROM_Table.Location = TableOffset + (x_Index * 2)
> x_Index = EEPROM_Table.Value ' Read 16 Bit Value
> x_Index.RShift(y_Index * 2)
> x_Index = x_Index And 3 ' Clear all but last 2 bits
> Return x_Index
> End Function
>
> Sub WriteValue(x_Index As Word, y_Index As Byte, Data As Byte)
> Dim Temp As Word
> EEPROM_Table.Location = TableOffset + (x_Index * 2)
> x_Index = EEPROM_Table.Value
> Temp = 3
> Temp.LShift(y_Index * 2)
> Temp = Temp Xor 65535
> x_Index = x_Index And Temp
> Temp = Data
> Temp.LShift(y_Index * 2)
> x_Index = x_Index + Temp
> EEPROM_Table.Value = x_Index
> End Sub
> This code compiles but I did not test it to see if it works
> properly. It should be able to read and write 2 bits at a time
> (enough to represent 0, 1, 2, or 3) to the EEPROM table at the
> location specified by x_Index and y_Index. It will not be really
> fast although your application of this does not sound like it will be
> a problem. They say that the B versions of the oEEPROM object has
> some trouble with two byte transfers but I think you could rewite
> this to use one byte transfers. The Table offset is where the table
> will begin on the EEPROM. Depending on the size of the EEPROM you
> use, you may need to change this. The table will take up 1458 bytes
> so you need to keep that in mind and if you are using it on E0, you
> need to make sure that it is stored above your program location.
> Good luck.
> --- In o...@yahoogroups.com, trungtuandung@ wrote:
> >
> > Hi all,
> > I'm new here and hoping that somebody can help me with this. I'm
> using ooPic-R which is connected to 2 sensors and a SSC-32 servo
> controller (with 12 servos). I want to make it learn how to walk
> just by sensors and without walk sequence. Now I need huge tables.
> >
> > The ooPic manual says that i can use object oVar3
> > http://www.oopic.com/ovar.htm
> >
> > but the 6.1.1 oopic compiler online understands oVar8 and oVar16.
> I need a table of the size 729 by 6 and each cell has 3 values -1, 0,
> 1 (preferably, if not possible, i can settle with 0, 1, 2)
> >
> > What's the most efficient way to store them? I read somewhere that
> you can only store array of objects, in which case I'm out of luck
> because there are only 86 bytes object memory.
> >
> > Thanks in advance for your help,
> > Harley
>
------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

One more thing, can anybody clarify this? it's said that sByte can access the 256 byte-space of INTERNAL EEPROM which don't seem to be the same thing as the EEPROM at E0 slow on which program code is stored. If I declare
Dim A as EEPROM Nib
that means I use the 'external' EEPROM which is much slower. then what happens to the fast acccess internal EEPROM, is there anyway to use it?
thanks in advance

------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I have never used sByte. I only use the internal EEPROM for storing
information that I want to be available even after a reset.

Dim A as EEPROM Nib

That line will initalize the variable A on the internal 256 byte
EEPROM. I am not sure that you can dimension variables on the external
EEPROM.

--- In o...@yahoogroups.com, trungtuandung@... wrote:
>
> One more thing, can anybody clarify this? it's said that sByte can
access the 256 byte-space of INTERNAL EEPROM which don't seem to be the
same thing as the EEPROM at E0 slow on which program code is stored.
If I declare
> Dim A as EEPROM Nib
> that means I use the 'external' EEPROM which is much slower. then
what happens to the fast acccess internal EEPROM, is there anyway to
use it?
> thanks in advance
>

------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

1. You could do it that way but you are still going to have to use
the same amount of variable space. There is not a varible between a
byte and a word so you would end up with a decimal value between 0
and 729 (3^6). Since that is greater than 256 (8 bits) you have to
go one step up to a word (16 bits). When you do this, you have no
way to save the left over bits so use them however you want. So your
method won't actually save any space over mine, they both use 729 * 2
bytes of storage. I don't know if I have made since here or not, if
not, I will try to clarify.

2. Those statements will not work. There is only 256 bytes of space
available on the EEPROM (Internal) and you are trying to use 2187
bytes. Also when you specify a nibble versus a byte, the compiler
only lets you use the first 4 bits but all 8 bits are allocated
(Hense the RShift, LShift, Mod...). That is one reason I rarely use
nibbles or boolean values, they do not save any space, they all use
one byte of RAM space.

--- In o...@yahoogroups.com, "tuandung248" wrote:
>
> Thanks a lot!! That's a cool way of making use of the EEPROM. It's
a
> great idea to store the 6-digit word as one variable.
>
> 1. How about taking a 6-bit word as a base-3 number (digit 0,1,2)
and
> convert it to a decimal number instead? My concern is that, your
> method use shift operation on 2 bits which is probably faster while
> mine below might be slow due to multiply/divide operations. Should
I
> sacrifice one more bit and use base-4 like what you did instead?
>
> Dim Leg(6) As Nib
> Dim Index As Word
>
> Sub HashToIndex(Void)
> 'take a state from Leg(1..6) (eg. 012012)
> 'and convert to decimal. eg 140 for 012012
> Index = Leg(6) + Leg(5)*3 + Leg(4)*9 + Leg(3)*27 + Leg(2)*81 +
> Leg(1)*243
> End Sub
>
> Sub HashToState(Void)
> Leg(6) = Index Mod 3
> Index = Index / 3
> Leg(5) = Index Mod 3
> Index = Index / 3
> Leg(4) = Index Mod 3
> Index = Index / 3
> Leg(3) = Index Mod 3
> Index = Index / 3
> Leg(2) = Index Mod 3
> Index = Index / 3
> Leg(1) = Index
> End Sub
>
> 2. Last time I thought sByte is the only way to store var to EEPROM,
> but i realize sByte doesn't work anymore, and there's a better
option:
>
> Dim Relevance(729) As EEPROM Nib
> Dim Reliability(729) As EEPROM Nib
> Dim Weight(729) As EEPROM Nib
>
> As you see I need to store corresponding Relevance, Reliability,
> Weight (and a more few more similar columns that i'm trying to
reduce)
> to each state. Now that I hash each 6-digit word into an index
> decimal number, I can get a round with the 2D array. However, is it
> reliable to use the variables as declared above on ooPic-R, compiler
> 6.1.1, yet? Or is it more reliable to handle the oEEPROM object
like
> you did?
>
> Thank you for the quick help, hope to hear more from you and others.
> --- In o...@yahoogroups.com, "tinslwc" wrote:
> >
> > You are going to have to store the table in the EEPROM. Even if
you
> > were able to use all the available bits in the regular RAM space,
you
> > would need almost 1100 bytes (729*6=4374 @ 2 bits each). If
EEPROM
> > space is limited, you can store each row of 6 values in one word
(16
> > bit) variable. I would then write a function to call out which
one
> > that you want. Here is an example:
> >
> > Dim EEPROM_Table As oEEProm
> > Const TableOffset = 10000
> >
> > Sub Main()
> > EEPROM_Table.Node = cvE0 ' or cvE1 if you have it)
> > EEPROM_Table.Width = 1 ' Set to 16 bit transfers
> > EEPROM_Table.NoInc = cvTrue ' Do not automatically increment
> > End Sub
> >
> > Function GetValue(x_Index As Word, y_Index As Byte) As Byte
> > EEPROM_Table.Location = TableOffset + (x_Index * 2)
> > x_Index = EEPROM_Table.Value ' Read 16 Bit Value
> > x_Index.RShift(y_Index * 2)
> > x_Index = x_Index And 3 ' Clear all but last 2 bits
> > Return x_Index
> > End Function
> >
> > Sub WriteValue(x_Index As Word, y_Index As Byte, Data As Byte)
> > Dim Temp As Word
> > EEPROM_Table.Location = TableOffset + (x_Index * 2)
> > x_Index = EEPROM_Table.Value
> > Temp = 3
> > Temp.LShift(y_Index * 2)
> > Temp = Temp Xor 65535
> > x_Index = x_Index And Temp
> > Temp = Data
> > Temp.LShift(y_Index * 2)
> > x_Index = x_Index + Temp
> > EEPROM_Table.Value = x_Index
> > End Sub
> >
> >
> > This code compiles but I did not test it to see if it works
> > properly. It should be able to read and write 2 bits at a time
> > (enough to represent 0, 1, 2, or 3) to the EEPROM table at the
> > location specified by x_Index and y_Index. It will not be really
> > fast although your application of this does not sound like it
will be
> > a problem. They say that the B versions of the oEEPROM object
has
> > some trouble with two byte transfers but I think you could rewite
> > this to use one byte transfers. The Table offset is where the
table
> > will begin on the EEPROM. Depending on the size of the EEPROM
you
> > use, you may need to change this. The table will take up 1458
bytes
> > so you need to keep that in mind and if you are using it on E0,
you
> > need to make sure that it is stored above your program location.
> > Good luck.
> > --- In o...@yahoogroups.com, trungtuandung@ wrote:
> > >
> > > Hi all,
> > > I'm new here and hoping that somebody can help me with this.
I'm
> > using ooPic-R which is connected to 2 sensors and a SSC-32 servo
> > controller (with 12 servos). I want to make it learn how to walk
> > just by sensors and without walk sequence. Now I need huge
tables.
> > >
> > > The ooPic manual says that i can use object oVar3
> > > http://www.oopic.com/ovar.htm
> > >
> > > but the 6.1.1 oopic compiler online understands oVar8 and
oVar16.
> > I need a table of the size 729 by 6 and each cell has 3 values -
1, 0,
> > 1 (preferably, if not possible, i can settle with 0, 1, 2)
> > >
> > > What's the most efficient way to store them? I read somewhere
that
> > you can only store array of objects, in which case I'm out of
luck
> > because there are only 86 bytes object memory.
> > >
> > > Thanks in advance for your help,
> > > Harley
> > >
>
------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

thank you. you're pretty clear but there are just some parts where
i'm confused:

1. what's with the internal and external EEPROM? i'm buying a new 32Kb
EEPROM (max for oopicR) to use but how to i use variables there?
isn't the program code stored in the external EEPROM instead of the
internal EEPROM? where doess the "EEPROM byte" let you store variable to?

2. Don't Rshift, Lshift, etc only belong to object types that inherit
from oValue class? so they should only work if you use objects like
oWord or oByte, instead of word or byte. So if I declare "Dim A(8) as
nib" don't I get 4 blocks of half-byte next to each other?

As a sidenote, if I want to use bit shifting on a variable type, I
think I have to assign the value to object type first.
eg.
Dim A as EEPROM word
'extreme example: if i wanna multiply A by 2
Dim B as oWord
B = A
B = A.Lshift(1)
A = B

thanks again. This is a great place to learn from others.

>
> 1. You could do it that way but you are still going to have to use
> the same amount of variable space. There is not a varible between a
> byte and a word so you would end up with a decimal value between 0
> and 729 (3^6). Since that is greater than 256 (8 bits) you have to
> go one step up to a word (16 bits). When you do this, you have no
> way to save the left over bits so use them however you want. So your
> method won't actually save any space over mine, they both use 729 * 2
> bytes of storage. I don't know if I have made since here or not, if
> not, I will try to clarify.
>
> 2. Those statements will not work. There is only 256 bytes of space
> available on the EEPROM (Internal) and you are trying to use 2187
> bytes. Also when you specify a nibble versus a byte, the compiler
> only lets you use the first 4 bits but all 8 bits are allocated
> (Hense the RShift, LShift, Mod...). That is one reason I rarely use
> nibbles or boolean values, they do not save any space, they all use
> one byte of RAM space.
>
------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Internal Memory and EEPROM:

If you look at the memory map afer compiling a program, it will tell
you what memory is available (object, variable, and EEPROM). In this
window, the object memory it typically the most precious (any Dim
statement with an oWhatever type). An oByte will be placed in object
memory space and a Byte will be placed in variable space. If you
place the EEPROM delimiter in the Dim statement (i.e. Dim A As EEPROM
Byte) then that variable will be stored on the internal EEPROM) When
you declare a Bit, Nib, or Byte, they all take up one byte of memory
space. Objects cannot be declared on the internal EEPROM.
Examples:
Dim A As oByte ' Defines in object space
Dim A As Byte ' Defines in variable space
Dim A As EEPROM Byte ' Defines in internal EEPROM
This statement is not allowed:
Dim A As EEPROM oByte
This is because you are defining A as a oByte object. Because it is
being treated as an object, it cannot be in the EEPROM, only the
object space.
External EEPROM:
The EEPROM at address cvE0 (decimal 80, I think) is the external
EEPROM (seperate chip) where the program is stored. Depending on the
length of your program, you can use the additional space on this
EEPROM for storage space but you cannot assign variables to it (hence
my first suggestion) You can only access bytes of storage by using
direct addressing.

The maximum size for an external EEPROM isactually 64k-bytes
(512kBits). I have used a 24LC512 with no problems.

If RShift, and LShift are only usable with oByte style variables,
then divide or multiply by powers of two for the same result. I
cannot remember if I have actually used that in a program before but
the code compiles which tells me that the compiler knows how to
handle it.

Dim A(8) As Nib:
This will use 9 bytes of space. The index is zero based and it will
not split the individual bytes in the memory space. Sorry. All of
these use 9 bytes of space:
Dim A(8) As Bit
Dim A(8) As Nib
Dim A(8) As Byte

--- In o...@yahoogroups.com, "tuandung248" wrote:
>
> thank you. you're pretty clear but there are just some parts where
> i'm confused:
>
> 1. what's with the internal and external EEPROM? i'm buying a new
32Kb
> EEPROM (max for oopicR) to use but how to i use variables there?
> isn't the program code stored in the external EEPROM instead of the
> internal EEPROM? where doess the "EEPROM byte" let you store
variable to?
>
> 2. Don't Rshift, Lshift, etc only belong to object types that
inherit
> from oValue class? so they should only work if you use objects like
> oWord or oByte, instead of word or byte. So if I declare "Dim A(8)
as
> nib" don't I get 4 blocks of half-byte next to each other?
>
> As a sidenote, if I want to use bit shifting on a variable type, I
> think I have to assign the value to object type first.
> eg.
> Dim A as EEPROM word
> 'extreme example: if i wanna multiply A by 2
> Dim B as oWord
> B = A
> B = A.Lshift(1)
> A = B
>
> thanks again. This is a great place to learn from others.
>
> >
> > 1. You could do it that way but you are still going to have to
use
> > the same amount of variable space. There is not a varible
between a
> > byte and a word so you would end up with a decimal value between
0
> > and 729 (3^6). Since that is greater than 256 (8 bits) you have
to
> > go one step up to a word (16 bits). When you do this, you have
no
> > way to save the left over bits so use them however you want. So
your
> > method won't actually save any space over mine, they both use 729
* 2
> > bytes of storage. I don't know if I have made since here or not,
if
> > not, I will try to clarify.
> >
> > 2. Those statements will not work. There is only 256 bytes of
space
> > available on the EEPROM (Internal) and you are trying to use 2187
> > bytes. Also when you specify a nibble versus a byte, the
compiler
> > only lets you use the first 4 bits but all 8 bits are allocated
> > (Hense the RShift, LShift, Mod...). That is one reason I rarely
use
> > nibbles or boolean values, they do not save any space, they all
use
> > one byte of RAM space.
>
------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, trungtuandung@... wrote:
>
> One more thing, can anybody clarify this? it's said that sByte can
access the 256 byte-space of INTERNAL EEPROM which don't seem to be
the same thing as the EEPROM at E0 slow on which program code is
stored. If I declare
> Dim A as EEPROM Nib
> that means I use the 'external' EEPROM which is much slower. then
what happens to the fast acccess internal EEPROM, is there anyway to
use it?
> thanks in advance
>

I don't know much about sByte; I just tried to declare a variable of
that type on V5 and V6 without success. I think you can just about
forget the internal EEPROM.

So, use the external EEPROM as documented. Yes, it will be slow.
But you are using the OOPic for a thing it doesn't do well. What you
gain in object abstraction, you give up in performance.

When you think in terms of executing 300 or so lines of code per
SECOND, things like EEPROM access may not be the limiting factor.

The OOPic does well with hardware abstraction. Things like motors
and servos are easy to control. Projects that require a lot of
computation would probably be better served with a different
controller.

Richard

------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

sByte was vaporware for V.5 compilers that never worked. The V.6
compiler has the proper way worked out that works Dim A as EEPROM Byte,
for instance.

DLC

rtstofer wrote:
> --- In o...@yahoogroups.com, trungtuandung@... wrote:
>
>> One more thing, can anybody clarify this? it's said that sByte can
>>
> access the 256 byte-space of INTERNAL EEPROM which don't seem to be
> the same thing as the EEPROM at E0 slow on which program code is
> stored. If I declare
>
>> Dim A as EEPROM Nib
>> that means I use the 'external' EEPROM which is much slower. then
>>
> what happens to the fast acccess internal EEPROM, is there anyway to
> use it?
>
>> thanks in advance
>>
>>
>
> I don't know much about sByte; I just tried to declare a variable of
> that type on V5 and V6 without success. I think you can just about
> forget the internal EEPROM.
>
> So, use the external EEPROM as documented. Yes, it will be slow.
> But you are using the OOPic for a thing it doesn't do well. What you
> gain in object abstraction, you give up in performance.
>
> When you think in terms of executing 300 or so lines of code per
> SECOND, things like EEPROM access may not be the limiting factor.
>
> The OOPic does well with hardware abstraction. Things like motors
> and servos are easy to control. Projects that require a lot of
> computation would probably be better served with a different
> controller.
>
> Richard
>
> ------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Many thanks to those who have answered so far. i'm very clear about
the points that you all have helped clarified now. i'm changing the
goal for the robot a little now since the current direction requires
way too much memory. will be back with more questions soon.
thanks again
------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )