Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Thu, 27 Nov 2003 15:33:09 GMT
|
Viewed:
|
9743 times
|
| |
|
|
Thanks for the response.
In lugnet.robotics.rcx.robolab, Dick Swan wrote:
> "Don Stauffer" <BrainChild@Skyler.com> wrote in message
> news:Hoz4Gp.1zto@lugnet.com...
> > Having investigated rotations sensors thoroughly, I conclude
> > they have some serious design flaws. ... <<SNIP>>
> > So, is there a way in Robolab to write a sub vi-like routine,
> > and specify theactual byte code instructions, just for that
> > time-critical part of the program, to be called by a regular
> > Robolab program?
>
> The rotation sensor bad counts cannot be fixed at the byte-code
> level. The problem is "native" to implementation in the underlying
> firmware code.
It seems to me it's a design flaw in the entire method of counting rotations,
which relies on the theoretical ideal of "instantaneous" voltage changes, which
can't be produced. You can't go from 2V to 5V without passing through every
voltage in between.
All the fixes I've seen look as though they would just reduce the frequency of
the problem until it seldom happens, but not absolutely prevent it.
Regarding "byte codes", I thought this term referred to the RCX equivalent of
80x86 "machine code", and so would be what _any_ firmware would be written in.
From what you said, it sounds like "byte codes" are more like calls to
"interrupt service calls" in DOS or API calls in Windows.
So what would you call the result of assembly? Just "machine code"? And is
there a listing of the RCX instruction set available, since I guess the "byte
code" document isn't what I need after all?
> Several of the RCX replacement OSes have improved the rotation
> sensor performance. But of course they no longer run the byte codes.
> It might be feasible to patch /hack their code back into Lego's
> byte-code interpreter firmware. Which raises two questions:
> [1] Would this still be competition legal?
North America FIRST competition rules:
"...robot...must be made entirely of LEGO elements in original factory
condition"
"The Robot must be programmed using LEGO MINDSTORMS Robotics Invention System or
RoboLab software (any version)."
So, it doesn't exactly say the firmware can't be changed; for example, to choose
between the RIS and Robolab software requires the firmware change, so to offer
the choice the rules must consider firmware changes not to be a change from
"original factory condition".
I'd have to ask.
> [2] When is your competition date (i.e. how soon do you need it)?
The 2003 competition is in about a week, I think, but the school considers this
year a "trial run"; they just got into Mindstorms, so they know it's really too
late to do a really good job this year. So, it's mainly for next year in my
opinion.
> The process that might be possible is the following:
> [1] Use the rotation sensor handler source code from one of
> the replacement OSes. Less that 200 bytes of code.
> [2] Assemble this code at some unused location within current
> Lego firmware. (E380 to EE5D looks like unused locations).
Here's the core of my question: what is the process by which the machine code
gets placed in a specific location in the RCX memory; how can you tell E380 to
EE5D addresses are available; how would the patch be "stitched" into the ISR -
equivalent of an 80x86 JMP assembler command?
> [3] Make the Analog-to-digital interrupt handler routine point to
> this "patch". (And also add a few other rotation handler hooks).
> [4] Manually edit (via NOTEPAD or similar) the "firm0328.lgo" file
> to include this patch.
> [5] Download the modified "firm0328.lgo" file.
> [6] Everything remains Robolab compatible.
It seems to me it's not unreasonable to patch something that's broken; would
they disqualify us if we soldered and taped a broken wire? OTOH, they could
expect everyone to start with the exact same choice of two programming packages,
with the original associated firmware, so it's fair.
That's why I was wondering if there's a way to specify and poke a patch as part
of a Robolab program itself, rather than by modifying the firmware in
preparation for running a program. Sort of like putting a short assembler
routine into a QuickBasic string and then calling it from the QuickBasic
program; technically, the entire subroutine is just part of the QuickBasic
program (an analogy, of course; I'm not suggesting using QuickBasic!)
I've just never seen stuff that low-level in Robolab, and wondered if anyone
were aware of it or could at least point me toward it.
|
|
Message is in Reply To:
 | | Re: Robolab, byte codes and assembler
|
| "Don Stauffer" <BrainChild@Skyler.com> wrote in message news:Hoz4Gp.1zto@lugnet.com... (...) <<SNIP>> (...) The rotation sensor bad counts cannot be fixed at the byte-code level. The problem is "native" to implementation in the underlying firmware (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
24 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
