Subject:
|
Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Mon, 10 May 1999 17:44:19 GMT
|
Viewed:
|
1438 times
|
| |
|
|
On Mon, 10 May 1999, Mark Tarrabain wrote:
> I was not intending to limit its functionality to that performed by the RCX with
> the standard firmware loaded. I did say "when no new features are being
> exploited". The idea of flashing an identifier associated with the current
> program may not be that viable given the limited display capabilities of the RCX.
> If this can be worked around, though, I think it'd be a neat idea.
You have 4 7-segment characters which could display a 4 character text string
(albeit with some of the characters being different case and some confusion
between characters).
> I believe that the concept of an administrative mode is overkill for this sort of
> project. The only circumstance in which I can see this being important is to
> prevent other RCX units from deleting or overwriting your programs, such as may be
> encountered in RCX competitions.
Adding limited functions to check the memory usage without having to haul
your bot over to the computer would be useful and I don't think it would
take much to do it.
> I proposed a workaround for this -- that the RCX
> *NOT* allow any changes to its state unless no programs are running (or the
> current program is being debugged). Since in such a competition, the RCX's
> program is going to be presumably always running, and will probably not be a
> debugging state, I do not see this as being a potential problem. Further, the
> issue of security itself for something like an RCX is moot. Somebody can easily
> just pick it up, take out the batteries, and wipe the whole firmware, as well as
> all your loaded programs. While speaking on the subject of computer security, a
> professor I had once said that "physical access to a machine will always superceed
> root privileges". (The premise behind the statement being that it's important to
> keep systems under lock and key where security sensitive data is kept, no matter
> how secure the operating system or login procedures may be.)
I think you have misunderstood my intent -- it is not to provide any sort
of security, but rather acess from the front panel to some internal state
of the machine.
> Just one question though... how were you expecting to control the motors without
> having a program looaded or using a host computer?
By having that functionality built into the "shell" program that controls
everything (ie, the same one that handles switching active programs when
you press the program button).
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
|
|
Message is in Reply To:
9 Messages in This Thread:
 
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
