| | Re: Faster NXT LCD Screen Refresh
|
|
(...) So that is how you did it. I was wondering about this ever since I saw the announcement. Incidentally, this would have been great cross posted to .color as well. <</robotics/nxt/?n=539>> Doug (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
|
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) This kind of works. In the first instance, you get two identical shades of grey. In the second instance (and I've tried this) you'd be surprised to see that the difference in shades between the two greys is actually very small. You really need (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
|
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) I already got one shade of grey out of it by flicking between two images at the current rate: (URL) I use all those spare cycles to mix and merge screen layers in real time, so this image has full parallax scrolling. I've been trying to do (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
|
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) <snip> (...) This is really interesting. If I understand correctly, to get colors, or at least shades of grey, you have to refresh the screen quickly and the "darker" the pixel, the more often it shows up in the pattern. For example, let's say (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
|
| | Re: Adding syscalls/opcodes to NXT-G
|
|
(...) John - I know you don't like this and I agree that the best solution is NI changing their compiler to allow extending firmware with new syscalls. The way things work, I'm afraid, this will not happen anytime soon. I'm trying to suggest (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt)
|
|
| | Faster NXT LCD Screen Refresh
|
|
Here's a trick to get a faster rate on the LCD display refresh. It currently takes 16 milliseconds to refresh the NXT LCD. 16 "messages" are sent to the LCD. One message is sent per millisecond. There are two messages from the ARM to the LCD for (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
|
| | pbLua Beta 3 - Available
|
|
All, pbLua beta 3 is available now at: (URL) This new version has the bug in the regulation fixed, and the default motor mode is brake, not float. I've also updated the API docs to correct errors (there are probably more) and added an install doc (...) (18 years ago, 22-Mar-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
|
| | Re: pbLua Fun at OSX
|
|
(...) Finally, I did something right - by accident! Christian, could I ask you to please send me (off list if you like) some screen shots of what happens when you connect the NXT? I can't remember if I sent you Mac instructions, but you just look (...) (18 years ago, 21-Mar-07, to lugnet.robotics.nxt)
|
|
| | pbLua Fun at OSX
|
|
Hello World, pbLua-Beta2 is out and 90% of my wishes are true now :D Running pbLua with OSX worked out of the box... 1. Flashing NXT and reboot the box once 2. checking for new NXT-Device (ls -la /dev/tty.usb*) 3. connecting with screen to NXT (...) (18 years ago, 21-Mar-07, to lugnet.robotics.nxt)
|
|
| | Re: The standard NXT firmware & the case of the missing opcodes
|
|
(...) I guess what I'm saying is '<<=', 'OP_ASL' and 'OP_LSL' are all the same thing (zero fill). '>>=' means either 'OP_ASR' (smear fill) or 'OP_LSR' (zero fill) depending on whether your target is signed or not. If you wanted direct equivalents (...) (18 years ago, 21-Mar-07, to lugnet.robotics.nxt.nxthacking)
|