 | | Re: Motor Control Register (0xf000)
|
|
(...) As it is, it seems[1] that two of the three NAND gates in the 74HC10 are being used as a driver for speaker output (it's odd that it's two, not one though). So, this leaves one three input NAND gate to do the decoding. Now that I think about (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
<snip> (...) Ok, thank you for the explaination! I am thinking that the Memory Manager would need some rework to support this, since the start of memory is currently established at compile time. I will have to take a look at this (time allowing). (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) I have implemented what Mark Riley has suggested. I submitted a patch to the patches section at the sourceforge project page. The changes are quite small but require some tricky tweaks to the build process. I have only minimally tested it and (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) While you are at it you could also make a remark near the explanation of the f000 motor control register, and make it clear that this is a hardware function. When I started to use this extra memory in leJOS I missed the remark at the very end (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) In that case, why didn't the RCX designers use an 8 input NAND to decode their addresses, to leave more of the RAM usable? Maybe there werent aware of this possibility? Jürgen (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
It also turns out that there are 8 bytes of external RAM that peek through at addresses 0xff80-0xff87. Writes to these locations also affect the motor control register. I suppose there's a small advantage in using these registers to control the (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) This is interesting. It makes sense that the memory backing these locations still works, but I never would have thought to try to use it. I will make a note of this on my pages. -Kekoa (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) Interesting, I never looked at that version. I think the one disassembled by Kekoa is 0309. Current versions of leJOS also use this upper memory to store part of its firmware (almost 3K). Jürgen (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
Joe, [some reordering of comments for clarity] (...) The idea is to pick a certain number of functions that will fit in the upper RAM space (~2900 bytes) and put these functions in a seperate linker section (other than the default ".text" section). (...) (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
Mark, This is very interesting. I have experienced strange motor behavior with programs on BrickOS before; I now wonder if this may have been the situation. I do not currently know enough about GCC to make the changes that you mentioned, but I am (...) (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
