| |
Sergey wrote:
<Discussion of ECHO_ON ECHO_OFF snipped>
> Advantages:
>
> - Possible to use standard terminals and create a faster custom terminals.
> For instance, my terminal implementation works fine even without pause between
> characters (only small pause after LF ~ 25ms was necessary).
Personally, this is a BIG advantage. Users who do not have access to Tcl now have
to deal with double respose characters. A simple ECHO_OFF at the beginning
of their script and they now can use ANY terminal emulator easily. The Mac
Tcl script does not support the serial port anyways.
> - Less errors in line (I think most errors are happened when transmitter and
> receiver are works together).
Even more reason for the above.
> Disadvantages:
>
> - Non-standard solution (in fact, standard regulates only behaviour of ACCEPT
> but not concrete implementation, like in case with handling of backspaces, for
> instance).
Yes it's non-standard, but as long as it's documanted, I think it's OK. I would
suggest that instead of EMIT, we check the state of an ECHO_FLAG in ACCEPT.
> > I have a new version I'd like to post shortly, any other ideas for
> improvements?
>
> So far, I have found only one thing - TX? word supposes to return flag but
> returns nothing. pbFORTH doesn't use EKEY? word, but somebody else can do...
>
> And this question about stack overwriting disturbs me. Do you have some
> solution around?
Yep. The stack is now in high memory and the boundary issue is gone. The image
is smaller too because of no stack in the image!
> > I was thinking about adding words to control the upload baud rate, and maybe
> > a little bit of info for the screen to let everyone know pbFORTH is alive!
>
> Oops, this is exactly what I'm doing now. ;-)
> My idea was to create some kind of monitor that could control On/Off
> indication (LCD+sound) and battery indicator. I'm not sure yet about motor and
> sensors - it could require changes in RCX words… And also a question, is it
> really necessary?
What do you mean?
> But On/Off indicator will be definitely helpful.
> So if you are interested, we can combine our efforts.
Yes, combined efforts are needed. I'd still like to be the official source for
pbForth distributions - I'd be happy to integrate your changes into the source.
I don't want to have too many versions floating around.
> About higher upload baud rate I'm not sure. My tests show me that most errors
> happened when response comes from RCX. It could be that IR transceiver and
> receiver are not designed to work simultaneously?
Maybe later then. My priorities now are to get the stack bug (done) and to make
a more standard echo removal so that it's practical to use ANY uploader.
Cheers,
Ralph Hempel - P.Eng
--------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbFORTH>
--------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------
|
|
Message has 1 Reply:
 | | Re: Double echo
|
| (...) I also think that standardisation is not a primary goal in our case ;) I still can't see a real necessity to have it as switchable feature, but having these ECHO_ON / ECHO_OFF available it's better then nothing. Would be nice to have them in a (...) (25 years ago, 27-Oct-99, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | Re: Double echo
|
| Hi Ralph, (...) Yes, it works. After fighting for a while with Cygwin32 + binutils (it's still present a bug in linker configuration), finally I got the development environment. Your makefile works fine so it was very easy to get pbFORTH compiled. (...) (25 years ago, 26-Oct-99, to lugnet.robotics.rcx.pbforth)
|
5 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
