Dan R. and I were up late, via phone + Facebook, trying to solve the latest bug in the quest to make cool Lego computer-controlled robots. A few days ago I gave up on the last version of the robot and make a new one. The previous version had a steering issue: it was rack-and-pinion style, like a car, but the Lego sensors (opto and touch) couldn't react fast enough to switch off the pinion motor. Thus the rack would keep moving after hitting its mechanical limit, breaking the Legos (or I'd strengthen the Lego construction and then risk burning out the motor). So I took it apart and made an all-new robot. This one has tank treads controlled by individual motors on each side. In the software, my first choice was to control it via keyboard: I'd pick four keys in the corners of a square pattern to represent the treads moving left/forward, left/reverse, right/forward, right/reverse. I wanted the user to have to hold the buttons down, like a gas pedal, for the motors to keep going. Applesoft expects the opposite -- press-and-release to do anything. We tried various tricks but at best the relevant bits would stutter on-off-on-off, not stay on as needed. Thinking it might be a keyboard issue, I switched to joystick button control. Button 0 for left tread, button 1 for right tread. When that works, then I'll made the joystick movement act as a shifter for forward/reverse on each tread. Same problem! With the latest test code I've got one motor stuttering and the other working smoothly (again this is in gas pedal style -- press and hold to keep the motor going). Here's where it gets really weird. Dan and I weren't sure where the problem resides, so I tried it in Logo. Works perfectly! That proved the problem isn't the joystick nor the Lego hardware interface. (I also tried swapping my well-used Lego hardware interface for the new-in-box one that Ben G. loaned us; same problem.) Back to BASIC. Swapped the button 0 and button 1 code positions in my test program. It still has the problem with the button 0 bit stuttering, even though it executes button 1 first! What the.... I'm stumped. Here is the test code (Lego subroutines excluded; they work fine): 10 REM INITIALIZE LEGO INTERFACE 20 GOSUB 1000 30 REM CLEAR THE MOTOR BITS 40 T(0)=0:T(1)=0:GOSUB 1215: (refers to ports 0-1 on the 7-port interface box; routine 1215 turns bits off) 50 REM CHECK JOYSTICK BUTTONS 60 B0=PEEK(49249) 70 IF B0>127 THEN T(0)=1:GOSUB 1115: REM TURNS ON BIT 0 80 IF B0<127 THEN T(0)=0:GOSUB 1215: REM TURNS OFF BIT 0 90 B1=PEEK(49250) 100 IF B1>127 THEN T(1)=1:GOSUB 1115: REM TURNS ON BIT 1 110 IF B1<127 THEN T(1)=0:GOSUB 1215: REM TURNS OFF BIT 2 120 GOTO 50 Other things we tried: swapping motors, swapping wires, different ports on the interface box, non-consecutive ports, rearranging the code lines to alternate (such as PEEK for B0/B1, enable one motor, enable the other, disable one, disable the other, loop). Also tried using the keyboard equivalents to joystick buttons 0/1 which on my computer (//e Platinum) are open-Apple and Option (Option = closed Apple from the earlier //e). I lost track of the results from each individual experiment (and I'm not going to do them all again), but they were all either the same or worse. Again, right now with the above code, the motor attached to button 0 stutters (you can even see port 0's LED flashing every couple of seconds) while the motor attached to port 1 goes on, stays on smoothly while you hold button 1, and turns off when you let go. Sooooo.... the problem isn't the joystick, the hardware, the Legos, or the computer. And it works fine in Logo. That leaves one thing: BASIC. How do I fix this? ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation