| |
Hi Ralph,
> The memory waste issue isn't that big a deal. The average distance
> to a boundary is 128 bytes, right. Say we allocate a 32 element data
> stack for a small task, which is typical. If allocating the 65 bytes of
> stack puts us through the boundary, we just ALLOC up to the boundary and
> then allocate the stack.
>
> My maze walker (unoptimized) took about 4K of space. There is PLENTY
> of space left. Let's optimize HAT when we need to....
Yea, no stack-hungry applications...
Just to be sure, do you plan to add an automatic stack boundary alignment to
HAT word?
I think it could be a good solution.
And memory, you are right, with Forth we have enough memory ;->
> We can do this. We have individual control of the LCD segments. How about:
Aha, you can control LCD segments directly through the port, right?
Did you try it?
> |_| |_ |_
> | |_ | |
>
> or something like that!
Wow, that's would be really cool!
Let's do it!
(and here you are, ready logo for pbForth - like this picture with NQC on LCD
;)
BTW, looking in ROM listing recently I just realized that there are a lot of
useful data there.
For instance, could be nice to see current type of the sensor or mode of the
motor, etc.
Something like SENSOR_TYPE@, MOTOR_MODE@, ...
What do you think about this?
Sergey
|
|
Message has 1 Reply:
 | | RE: Double echo
|
| (...) I think I can add auto stack stuff before the weekend. (...) I did it, it works. (...) Yes, but hopefully if you set the mode, you wont forget it too quickly! :-) Here are the new words for the next release: RCX_ECHO - a variable, initially 0 (...) (25 years ago, 29-Oct-99, to lugnet.robotics.rcx.pbforth)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
