Why isn't my program working?
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
I have two comments. 1. Is the comment in line 110 incorrect, or is the code incorrect? 110 IF B1<127 THEN T(1)=0:GOSUB 1215: REM TURNS OFF BIT 2 Should that say "BIT 1" in the comment? 2. I would eliminate all the motor control stuff and just have the Basic code print a message on the screen, or turn a pixel off or on, to indicate it's intention to change the motor state. That way you can determine for certain that the problem is entirely within the Basic program. 70 IF B0>127 THEN T(0)=1: PRINT "MOTOR 1 ON" 80 IF B0<127 THEN T(0)=0: PRINT "MOTOR 1 OFF" or whatever. Printing messages to the screen may slow the program down significantly, in which case, make the messages very short: 70 IF B0>127 THEN T(0)=1: PRINT "11" 80 IF B0<127 THEN T(0)=0: PRINT "10" etc. Bill Dudley retired embedded systems developer motto: "printf is your friend" This email is free of malware because I run Linux. On Sat, Jan 28, 2017 at 1:47 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
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
On Sat, Jan 28, 2017 at 2:10 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
1. Is the comment in line 110 incorrect, or is the code incorrect? 110 IF B1<127 THEN T(1)=0:GOSUB 1215: REM TURNS OFF BIT 2
Yes, typo in the remark.
No that's the digit value if binary bit# 1 which equals 2 that's a reminder to know what decimal value is being used by the Poke For when the array that hold the Binary# gets converted to Decimal# for the Poke instruction the array has 8 bits, 0- 7 when you convert Binary to decimal, that refers to the Digit value ie, [using fixed width here] Bit # 7 6 5 4 3 2 1 0 Digit Value 1 2 6 3 1 8 4 2 6 8 4 2 1
2. I would eliminate all the motor control stuff and just have the Basic code print a message on the screen, or turn a pixel off or on, to indicate it's intention to change the motor state. That way you can determine for certain that the problem is entirely within the Basic program.
Yup. Dan and I tried the same kind of thing. I did a simplified version just now: 70 IF B0>127 THEN PRINT "BUTTON ZERO ON" 100 IF B1>127 THEN PRINT "BUTTON ONE ON" Took out lines 80 and 110. It works as expected when running: nothing happens until I press either button, then the appropriate messages show up, and they stop when I release the buttons.
I'd put in ALL the lines, just change the gosubs to prints. If that works as expected, then I'd ask the question: How are the port bit sets and resets accomplished? If motor 1 is on bit 1 and motor 2 is on bit 2 of the SAME port, then somebody (you or the basic interpreter) has to do some clever stuff to change bit 1 without causing bit 2 to be changed, and vice-versa. In C portx |= 1 ; // turns on bit 1 portx &= 0xFE ; // turns off bit 1 by ANDing old value of portx with 11111110 portx |= 2 ; // turns on bit 2 portx &= 0xFD ; // turns off bit 2 without disturbing bit 1 by ANDing old value of portx with 11111101 Bill Dudley This email is free of malware because I run Linux. On Sat, Jan 28, 2017 at 2:21 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
2. I would eliminate all the motor control stuff and just have the Basic code print a message on the screen, or turn a pixel off or on, to indicate it's intention to change the motor state. That way you can determine for certain that the problem is entirely within the Basic program.
Yup. Dan and I tried the same kind of thing. I did a simplified version just now:
70 IF B0>127 THEN PRINT "BUTTON ZERO ON" 100 IF B1>127 THEN PRINT "BUTTON ONE ON"
Took out lines 80 and 110. It works as expected when running: nothing happens until I press either button, then the appropriate messages show up, and they stop when I release the buttons.
If motor 1 is on bit 1 and motor 2 is on bit 2 of the SAME port
Define "port". In the Lego interface box (which communicates with the computer through a Lego card), you can control motors/lights/sensors via eight locations. You turn each location on/off using subroutines they supply. But I'm using the (English) "port" and "bit" interchangeably. Fortunately each location has an LED so you don't need anything plugged in to know if it is working. ------------------------- 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
Try moving lines 60, 70, 80 to be located AFTER 90, 100, 110, i.e. change their line numbers to 116,117,118. If the new order of operations causes the other motor to stutter, then the cluprit is probably the I/O writes, as per my previous email. Bill This email is free of malware because I run Linux. On Sat, Jan 28, 2017 at 2:47 PM, William Dudley <wfdudley@gmail.com> wrote:
I'd put in ALL the lines, just change the gosubs to prints.
If that works as expected, then I'd ask the question:
How are the port bit sets and resets accomplished?
If motor 1 is on bit 1 and motor 2 is on bit 2 of the SAME port, then somebody (you or the basic interpreter) has to do some clever stuff to change bit 1 without causing bit 2 to be changed, and vice-versa.
In C
portx |= 1 ; // turns on bit 1 portx &= 0xFE ; // turns off bit 1 by ANDing old value of portx with 11111110
portx |= 2 ; // turns on bit 2 portx &= 0xFD ; // turns off bit 2 without disturbing bit 1 by ANDing old value of portx with 11111101
Bill Dudley
This email is free of malware because I run Linux.
On Sat, Jan 28, 2017 at 2:21 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
2. I would eliminate all the motor control stuff and just have the Basic code print a message on the screen, or turn a pixel off or on, to indicate it's intention to change the motor state. That way you can determine for certain that the problem is entirely within the Basic program.
Yup. Dan and I tried the same kind of thing. I did a simplified version just now:
70 IF B0>127 THEN PRINT "BUTTON ZERO ON" 100 IF B1>127 THEN PRINT "BUTTON ONE ON"
Took out lines 80 and 110. It works as expected when running: nothing happens until I press either button, then the appropriate messages show up, and they stop when I release the buttons.
Try moving lines 60, 70, 80 to be located AFTER 90, 100, 110, i.e. change their line numbers to 116,117,118. If the new order of operations causes the other motor to stutter, then the culprit is probably the I/O writes, as per my previous email.
Already tried that. Thought I mentioned it in the original message. The result of that experiment is it's still the bit/port/motor controlled by button 0 that stutters, even though the button 1 code comes first.
I'd like to see the subroutines that Lego supplies to change the ports/bits. A "port" usually means an 8 bit wide I/O thing -- 8 bits that are all written at one time, because they share an address. A "bit" is one single wire in a port. Did you try taking the original program, and replacing ALL gosubs with print statements? You want to see if there are extra unexpected writes to the "wrong" motor. Bill This email is free of malware because I run Linux. On Sat, Jan 28, 2017 at 3:02 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Try moving lines 60, 70, 80 to be located AFTER 90, 100, 110, i.e. change their line numbers to 116,117,118. If the new order of operations causes the other motor to stutter, then the culprit is probably the I/O writes, as per my previous email.
Already tried that. Thought I mentioned it in the original message. The result of that experiment is it's still the bit/port/motor controlled by button 0 that stutters, even though the button 1 code comes first.
On Sat, Jan 28, 2017 at 4:02 PM, William Dudley via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I'd like to see the subroutines that Lego supplies to change the ports/bits.
A "port" usually means an 8 bit wide I/O thing -- 8 bits that are all written at one time, because they share an address.
A "bit" is one single wire in a port.
Did you try taking the original program, and replacing ALL gosubs with print statements?
You want to see if there are extra unexpected writes to the "wrong" motor.
Bill
I think Evan forgot to mention that the ports on the 9750 Lego interface box works perfectly when only programming one port, the problem only happens when trying to program -more- than one port on the 9750 box and when we try, then we experience a very strange type of stuttering/toggling/oscillation on any of the ports and the combination of ports that we use doesn't matter, they each experience this problem whe nusing more thsan one port Only when we program just one port it works fine so the code works fine when only programming just one port also the subroutines work fine the code access each and every port the way its supposed to As I said, its only when we attempt to program multiple ports We have two version of the code to attempt this, only the one version was shown here and both experience this strange symptom Dan
the problem only happens when trying to program -more- than one port on the 9750 box
In BASIC. Remember it worked fine in Logo. Which reminds me: Jon and I had similar problems programming multiple ports in BASIC last summer. We chalked it up to a timing issue -- Lego called for a PC and we used a 386 -- but maybe we were wrong. Granted there are totally different subroutines for the PC vs. for the Apple, just saying though....
We have two version of the code to attempt this, only the one version was shown here and both experience this strange symptom
Your version: 9 billion lines of complexity. Mine version: a few lines of simplicity. :) Result: same.
On Sat, Jan 28, 2017 at 6:04 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
the problem only happens when trying to program -more- than one port on the 9750 box
In BASIC. Remember it worked fine in Logo.
yes, which only leads me to further suspect a quirk in the Applesoft Basic Interpreter We expect it to behave one way but it is not I outline to you how the Logic flows in the code a couple of times, and there is no explanation for this strange stuttering/toggling/oscillation
Which reminds me: Jon and I had similar problems programming multiple ports in BASIC last summer. We chalked it up to a timing issue -- Lego called for a PC and we used a 386 -- but maybe we were wrong. Granted there are totally different subroutines for the PC vs. for the Apple, just saying though....
well, we have to find the answer this time
We have two version of the code to attempt this, only the one version was shown here and both experience this strange symptom
Your version: 9 billion lines of complexity. Mine version: a few lines of simplicity. :) Result: same.
Evan, been trying to help you here for dozens of hours or I'll bring a MUCH larger Pool Noodle with me :)
On Sat, Jan 28, 2017 at 6:22 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I outline to you how the Logic flows in the code a couple of times
It's my code, I know how the logic flows.
dude, why you going there you keep nitpicking at each sentence and taking it out of context, Read the entire message for its context I spend hours offline trying to explain everything as best I can to you when you ask this thread was lacking some details which we encountered and I offered it here only to keep the members here apprised of the state of this problem Dan
On Sat, Jan 28, 2017 at 4:02 PM, William Dudley via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I'd like to see the subroutines that Lego supplies to change the ports/bits.
A "port" usually means an 8 bit wide I/O thing -- 8 bits that are all written at one time, because they share an address.
A "bit" is one single wire in a port.
Did you try taking the original program, and replacing ALL gosubs with print statements?
You want to see if there are extra unexpected writes to the "wrong" motor.
Bill
Bill, see my recent reply about the code, Evan didn't explain everything to keep the email short we have tested the subroutines already they work perfectly when programming and accessing just one port, on any one this 9750 lego interface has 5 output and 2 input ports And so all of the debugging steps I tried so far lead to my suspicion that Applesoft Basic doesn't behave the way we expect it The Logic flow in the code is pretty much correct, aside from some little slopiness to run the test quickly His email doesn't show all of the Debug steps I took that night it would just take too much room here Dan
Chances are I'll still be working on this during the February workshop. ------------------------- 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
A few people asked to see the subroutines provided by Lego. The 1000 series initializes the system. 1100 series turns bits off. 1200 series turns bits on. Descriptions and code are exactly as described in the instructions. 1000 REM INIT 1001 S=(SLOT NUMBER -- MINE IS 4 -ek):l=49280+S*16 1002 POKE L+3,1 1003 POKE L+2,63 1004 POKE L+1,0 1005 POKE L,0 1006 RETURN "Below is a subroutine which will send the data stored in an array DB(...) to the interface. It is assumed that the elements DB(0) through DB(5) contains 1s and 0s to turn the bits on and off. These data elements are then combined into a single decimal value to be sent." 1100 REM OUTPUT DATA 1101 DB=0: REM INIT DATA 1102 FOR I=0 TO 5: REM CONVERT BINARY DATA 1103 DB=DB+DB(I)*2^I 1104 NEXT I 1105 POKE L,DB: REM SEND DATA TO INTERFACE 1106 RETURN "The following routine will turn on all the bits specified. It has two entry points. If you call it at the beginning (line 1110), you will turn off all the other bits. If you call it at line 1115, you leave the other bits alone. To use this routine, you must first set the required (T(0) to (T(5)) to 1." 1110 REM TURN ON SPECIFIC BITS 1111 FOR I=0 TO 5: REM TURN OFF ALL BITS FIRST 1112 DB(I)=0 1113 NEXT I: REM FALLS THROUGH TO NEXT PART 1115 FOR I=0 TO 5 1116 DB(I)=DB(I) OR T(I): REM TURN ON REQUIRED BITS 1117 NEXT I 1118 GOSUB 1100 1119 RETURN "For example, to turn on bits 3 and 4, without changing the other bits, you could use the following line: T(3)=1:T(4)=1:GOSUB 1115. To turn on bits 3 and 4, and the rest off, use: T(3)=1:T(4)=1:GOSUB 1110. There's also a routine to turn bits on for a set period of time, and another routine to read bits, but I'm not using those right now. A while ago I asked Dan offline how to make a routine to turn specific bits * off *. He explained that the easiest way is to copy the 1115-1119 routine (changing the series to 1200) and change the OR in line '16 to AND. It works perfectly when used one bit at a time.
On Sat, Jan 28, 2017 at 08:38:23PM -0500, Evan Koblentz via vcf-midatlantic wrote:
1105 POKE L,DB: REM SEND DATA TO INTERFACE
I've been skimming so may not have followed all that has been done. I would start with a print of DB here to see what it really being sent to the device. If they look fine I would try the pokes directly to try to understand what pattern of pokes and bits set causes improper operation.
On Sat, Jan 28, 2017 at 8:49 PM, David Gesswein via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Sat, Jan 28, 2017 at 08:38:23PM -0500, Evan Koblentz via vcf-midatlantic wrote:
1105 POKE L,DB: REM SEND DATA TO INTERFACE
I've been skimming so may not have followed all that has been done.
I would start with a print of DB here to see what it really being sent to the device. If they look fine I would try the pokes directly to try to understand what pattern of pokes and bits set causes improper operation.
yes, I had that in my version of the code too I display each of the variables on a formatted screen, similiar to escape codes, by just using Tab's to see each variable from each part of the code, both the Main Code and each of the subroutines the subroutines check out good Dan
On Sat, Jan 28, 2017 at 8:58 PM, Dan Roganti <ragooman@gmail.com> wrote:
On Sat, Jan 28, 2017 at 8:49 PM, David Gesswein via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Sat, Jan 28, 2017 at 08:38:23PM -0500, Evan Koblentz via vcf-midatlantic wrote:
1105 POKE L,DB: REM SEND DATA TO INTERFACE
I've been skimming so may not have followed all that has been done.
I would start with a print of DB here to see what it really being sent to the device. If they look fine I would try the pokes directly to try to understand what pattern of pokes and bits set causes improper operation.
yes, I had that in my version of the code too I display each of the variables on a formatted screen, similiar to escape codes, by just using Tab's to see each variable from each part of the code, both the Main Code and each of the subroutines the subroutines check out good Dan
I don't think I mentioned that I had the subroutines hard-coded while debugging his problem So the math conversion is all removed, in Subs 1100 and Sub 1110, since we only used 1 or 2 ports We set preset DB to the correct value, each for Port 0 and Port 1 This time we tried it again, where DB=3, so both Port 0 and 1 switch On the motors at same time. But now both motors stutter, eg, toggle on/off repeatedly very quickly Before only one of the motors would stutter when switching them On separately, using the separate joystick buttons that happened on Port 0 with one program, and the other motor would spin perfectly fine on Port 1. Then we saw the opposite happen with a different program So the problem moved to the other port with different programs, where each are following a similar logic flow The difference between the programs was one used Joystick buttons and the other used keyboard commands But now, this strangeness would only happen Ports 0,1 _pair_ And when we tried other pairs of output Ports, such as, port 0 and 5, then -both- motors would stutter, switching them On separately So there's really two strange problems, but I really think they are both related to each other. And from all of the debugging steps, I just can't pinpoint it yet I saw Evan run this with Apple LOGO and it works =perfectly= in his video using Joystick Buttons, one for each motor, they both turn On correctly, and they never stutter. So I find it very hard to think it's the 9750 Lego interface box -NOR- the 6522 VIA Interface card in the slot I'm finding it very suspicious there's a glitch in the Applesoft Basic Interpreter, But I'm still trying to debug this some more using Applesoft Basic So I'm considering switching to Assembly on my end I have a similar setup here too just like Evan, with the 9750 interface box, Just not interface card for the slot yet, so I have to get one wired together. Because the only common denominator between Applesoft Basic and Apple Logo is machine code Just so I can see if there is any definitive glitches with Applesoft Basic but we may have another update very shortly Dan
On Sat, Jan 28, 2017 at 10:11:52PM -0500, Dan Roganti via vcf-midatlantic wrote:
On Sat, Jan 28, 2017 at 8:58 PM, Dan Roganti <ragooman@gmail.com> wrote:
On Sat, Jan 28, 2017 at 8:49 PM, David Gesswein via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Sat, Jan 28, 2017 at 08:38:23PM -0500, Evan Koblentz via vcf-midatlantic wrote:
1105 POKE L,DB: REM SEND DATA TO INTERFACE
I've been skimming so may not have followed all that has been done.
I would start with a print of DB here to see what it really being sent to the device. If they look fine I would try the pokes directly to try to understand what pattern of pokes and bits set causes improper operation.
???yes, I had that in my version of the code too??? I display each of the variables on a formatted screen, similiar to escape codes, by just using Tab's to see each variable from each part of the code, both the Main Code and each of the subroutines the subroutines check out good Dan
???I don't think I mentioned that I had the subroutines hard-coded while debugging his problem ???So the math conversion is all removed, in Subs 1100 and Sub 1110, since we only used 1 or 2 ports We set preset DB to the correct value, each for Port 0 and Port 1
This time we tried it again, where DB=3, so both Port 0 and 1 switch On the motors at same time. But now both motors stutter, eg, toggle on/off repeatedly very quickly
Did you try just looping on poke L,3 and varients to see if that worked without the rest of the code other than the initialization?
On Sat, Jan 28, 2017 at 10:24 PM, David Gesswein via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Did you try just looping on poke L,3 and varients to see if that worked without the rest of the code other than the initialization?
pretty sure Evan already did that raw test beforehand He will have to reply if he had done so, if not, we can try that Dan
just tried that raw test [no code], it works great, no stutter, all of the motors spin perfectly this tells me there's a glitch with Applesoft Basic so I still have to dissect the code some more to see where it gets corrupted these are the hard-coded values from the raw test, POKE 49344, 0 ---> ALL Ports=OFF POKE 49344, 1 ---> Port# 0=ON POKE 49344, 2 ---> Port# 1=ON POKE 49344, 4 ---> Port# 2=ON POKE 49344, 8 ---> Port# 3=ON POKE 49344, 16 ---> Port# 4=ON POKE 49344, 32 ---> Port# 5=ON Then, we tried using this combination, so we can run the motors fwd and rev this requires using the combined Ports, A, B, C to use the Motor Bridge circuit POKE 49344, 1 ---> Port# A=FWD [Right Motor] POKE 49344, 4 ---> Port# B=FWD [Left Motor] POKE 49344, 16 ---> Port# C=FWD POKE 49344, 2 ---> Port# A=REV POKE 49344, 8 ---> Port# B=REV POKE 49344, 32 ---> Port# C=REV we used this convention for the motor direction Fwd: Binary= 01 Rev: Binary= 10 Then, we tried using this combination, so we can run 2 motors at the same time the robot only has 2 motors for now so just these permutations are used here POKE 49344, 5 ---> Binary= 0101, Port# A+B=FWD POKE 49344, 10 ---> Binary= 1010, Port# A+B=REV POKE 49344, 4 ---> Binary= 0100, Port# A+B Turn Right Fwd POKE 49344, 1 ---> Binary= 0001, Port# A+B Turn Left Fwd POKE 49344, 8 ---> Binary= 1000, Port# A+B Turn Right Rev POKE 49344, 2 ---> Binary= 0010, Port# A+B Turn Left Rev POKE 49344, 6 ---> Binary= 0110, Port# A+B Spin Right Fwd [Left=Fwd, Right=Rev] POKE 49344, 9 ---> Binary= 1001, Port# A+B Spin Left Fwd [Left=Rev, Right=Fwd] so then we were going to hard-code these values for each direction, and then steer this robot with the Joystick together with the 2 button on there the two joystick buttons are used to switch steering modes, between Turning and Spinning Dan
just tried that raw test [no code], it works great, no stutter, all of the motors spin perfectly this tells me there's a glitch with Applesoft Basic so I still have to dissect the code some more to see where it gets corrupted
these are the hard-coded values from the raw test,
POKE 49344, 0 ---> ALL Ports=OFF POKE 49344, 1 ---> Port# 0=ON POKE 49344, 2 ---> Port# 1=ON POKE 49344, 4 ---> Port# 2=ON POKE 49344, 8 ---> Port# 3=ON POKE 49344, 16 ---> Port# 4=ON POKE 49344, 32 ---> Port# 5=ON
Then, we tried using this combination, so we can run the motors fwd and rev this requires using the combined Ports, A, B, C to use the Motor Bridge circuit POKE 49344, 1 ---> Port# A=FWD [Right Motor] POKE 49344, 4 ---> Port# B=FWD [Left Motor] POKE 49344, 16 ---> Port# C=FWD
POKE 49344, 2 ---> Port# A=REV POKE 49344, 8 ---> Port# B=REV POKE 49344, 32 ---> Port# C=REV
we used this convention for the motor direction Fwd: Binary= 01 Rev: Binary= 10
Then, we tried using this combination, so we can run 2 motors at the same time the robot only has 2 motors for now so just these permutations are used here POKE 49344, 5 ---> Binary= 0101, Port# A+B=FWD POKE 49344, 10 ---> Binary= 1010, Port# A+B=REV
POKE 49344, 4 ---> Binary= 0100, Port# A+B Turn Right Fwd POKE 49344, 1 ---> Binary= 0001, Port# A+B Turn Left Fwd
POKE 49344, 8 ---> Binary= 1000, Port# A+B Turn Right Rev POKE 49344, 2 ---> Binary= 0010, Port# A+B Turn Left Rev
POKE 49344, 6 ---> Binary= 0110, Port# A+B Spin Right Fwd [Left=Fwd, Right=Rev] POKE 49344, 9 ---> Binary= 1001, Port# A+B Spin Left Fwd [Left=Rev, Right=Fwd]
Kudos to Dan for his patience as I worked through all the decimal-binary conversions by hand. Obviously the actual math is first-grade level, but what you guys all memorized (conversion-wise and binary addition-wise), I have to stop and deduce each time. It works perfectly. To make the programming easier I'm setting a variable (probably "M" for "move") rather than typing the POKE address each time. We also figured out a good way to use all of the Apple joystick's functions. For example, while turning the stick left, I'll users press button 0 for a standard left turn (left tread off, right tread forward) or button 1 for a left spin (left tread reverse, right tread forward). Wanna spin left? POKE M,9 ... etc. ... beautiful.
another update, this is regarding the original code found in the Teacher's manual which is how we started and arrived at this problem that was the pdf file in the "Lego Lines" Zip file, which also contained the disk image. We mentioned that Basic code was likely just demo code to fiddle some bits on the port address to spin a motor, blink a lamp, or sense a contact switch. As the Lego folks instead pushed their Lego Logo software, with it's flashy graphics to impress the kids in their education market. So, they apparently didn't use this Basic code in a live example, eg. integrate all of this code with their subroutines and the Main code into a functioning robot.. The variable DB, which is used in each of their subroutines for the Read Port and Write Port operations, was getting corrupted in our version of the code. And this created that stuttering symptom. When any of these subroutines are used in separate programs, they work perfectly fine. And as we observed, our code also works perfectly fine when spinning just one motor. The only time the robot goes bezerk is when trying to spin multiple motors. Which is needed since the robot requires both motors for locomotion. So, I had to use separate variable for the Read Port and Write Port operations for that port address to the robot interface. So I just used DR for the Read Port, and DW for the Write port. And then the associated code in each Read and Write subroutine which used that variable was made to match as well. And so I sent Evan the latest disk image and everything works fine now with his robot. No more stuttering motors this is the screenshot from the program, its only 40col, a kind of telemetry display http://www.rogtronics.net/files/hobby/comp/apple/Robot-Lego/images/ROBOT0.67... I was going to update the 80col version with this bug fix too, this is more of a flow chart display http://www.rogtronics.net/files/hobby/comp/apple/Robot-Lego/images/ROBOT0.68... but since Evan's recent foray in learning Binary [hehe] he will continue using the new code we made with the hard-coded values recently Another attempt to use the Applesoft Basic compiler is another goal, to speed up eveything just have to find the disk images #$#%@^#$ Dan
So, I had to use separate variable for the Read Port and Write Port operations for that port address to the robot interface. So I just used DR for the Read Port, and DW for the Write port. And then the associated code in each Read and Write subroutine which used that variable was made to match as well. And so I sent Evan the latest disk image and everything works fine now with his robot. No more stuttering motors
It's awesome that you fixed this 30-year-old bug.
http://www.rogtronics.net/files/hobby/comp/apple/Robot-Lego/images/ROBOT0.67...
I love this version. It's very lunar landar-ish.
but since Evan's recent foray in learning Binary [hehe]
Okay from now I only program (and speak to other humans) in raw machine code! :) (Didn't exactly have to "learn" binary, I'm just not experienced at on-the-fly conversions like you guys are.)
On 2/1/2017 7:50 PM, Dan Roganti via vcf-midatlantic wrote:
another update, this is regarding the original code found in the Teacher's manual which is how we started and arrived at this problem that was the pdf file in the "Lego Lines" Zip file, which also contained the disk image.
We mentioned that Basic code was likely just demo code to fiddle some bits on the port address to spin a motor, blink a lamp, or sense a contact switch. As the Lego folks instead pushed their Lego Logo software, with it's flashy graphics to impress the kids in their education market. So, they apparently didn't use this Basic code in a live example, eg. integrate all of this code with their subroutines and the Main code into a functioning robot..
The variable DB, which is used in each of their subroutines for the Read Port and Write Port operations, was getting corrupted in our version of the code. And this created that stuttering symptom. When any of these subroutines are used in separate programs, they work perfectly fine. Oh Dang. Evan talked about the read of the port but we didn't see the code. Shame on us for not asking to see the read port usage. Seeing DB reused probably would have raised a red flag.
And as we observed, our code also works perfectly fine when spinning just one motor. The only time the robot goes bezerk is when trying to spin multiple motors. Which is needed since the robot requires both motors for locomotion.
So, I had to use separate variable for the Read Port and Write Port operations for that port address to the robot interface. So I just used DR for the Read Port, and DW for the Write port. And then the associated code in each Read and Write subroutine which used that variable was made to match as well.
And so I sent Evan the latest disk image and everything works fine now with his robot. No more stuttering motors this is the screenshot from the program, its only 40col, a kind of telemetry display http://www.rogtronics.net/files/hobby/comp/apple/Robot-Lego/images/ROBOT0.67... I was going to update the 80col version with this bug fix too, this is more of a flow chart display http://www.rogtronics.net/files/hobby/comp/apple/Robot-Lego/images/ROBOT0.68...
but since Evan's recent foray in learning Binary [hehe] he will continue using the new code we made with the hard-coded values recently Another attempt to use the Applesoft Basic compiler is another goal, to speed up eveything just have to find the disk images
#$#%@^#$ Dan
On Thu, Feb 2, 2017 at 12:00 AM, Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On 2/1/2017 7:50 PM, Dan Roganti via vcf-midatlantic wrote:
The variable DB, which is used in each of their subroutines for the Read Port and Write Port operations, was getting corrupted in our version of the code. And this created that stuttering symptom. When any of these subroutines are used in separate programs, they work perfectly fine.
Oh Dang. Evan talked about the read of the port but we didn't see the code. Shame on us for not asking to see the read port usage. Seeing DB reused probably would have raised a red flag.
always go direct to the source, than using a middle man ;) Dan
On Thu, Feb 2, 2017 at 11:38 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Oh Dang. Evan talked about the read of the port but we didn't see the code.
Shame on us for not asking to see the read port usage. Seeing DB reused probably would have raised a red flag.
I foolishly assumed Lego knew what they were doing.
They do, they make a butt load of money from kids' parents.
I changed the subject line. "Not malfunction Stephanie!" This version has two kinds of turns (spin left, spin right), not the numerous variations Dan proposed. It was so much simpler this way. After all, the point of this robot is to teach kids (and maybe non-technical adults) in the museum about programming. I might try the more advanced version later, but for now I'm going to put the whole project aside, declare it "Done" (or at least, "Good enough,"), and return my full focus to VCF East stuff (with exceptions for the February workshop when I'll try this using a Laser 128 and the Trenton show on March 18). The program starts and turns off all the bits/motors. Joystick up/down makes it go forward/reverse. Joystick in the middle stops the motors. Button 0 stops the motors, turns on the left tread in reverse, and turns on the right tread in forward. Thus it spins to the left. Button 1 does the opposite of button 0. It'll keep spinning until you let go of the button. When you let go, it reverts to the forward/reverse code. Number five is alive! Special thanks to Dan for FORCING me to understand every single detail. I knew he's right and that there is no magic "make robot" button. :) Hopefully I also taught Dan something about how to teach such things to people who are just as intelligent as him :) but don't necessarily have the aptitude to pick it up so quickly. Two notes: 1. I'm sure some of you will point out places where I could save a line here or a byte there. Chances are I will acknowledge that you are correct, but please don't be offended if I keep it the way it is. Once again, the point of this exercise is to have very straightforward code for kids and non-technical visitors. I will probably make a big poster showing code and a flow chart. 2. Moving the stick left or right does nothing. That's by design. As I said I'm going to take a break from this project for a while. Later I might make L/R movement do what buttons 0/1 do now. That would give people more standard joystick control to drive, backup, and steer. Then I can use the buttons for other tricks, such as turning on the headlights/taillights and controlling the opto/touch sensors. (Last fall, just for giggles, I put a brakelight in the Logo robot at World Maker Faire. Real easy -- when the 'bot stops, turn on the extra light behind a red Lego lens. I could just as easily make backup lights that way -- when the 'bot goes in reverse, turn on more extra lights and make the computer beep every few seconds! Turn signals would also be simple.) Lots of fun possibilities here. Additional thanks to the several other group members and friends-of-our-group who all helped me with parts of this project (I don't want to forget anyone.) It might be a non-impressive program that a lot of you could do at age 15 but it's a big deal to me. -Evan PS. I named this robot "Leinad". -------------------------------- 10 REM INIT LEGO 20 GOSUB 1000 30 M=49344 40 POKE M,0: REM MOTORS OFF 100 REM LISTEN TO JOYSTICK 110 FB= PDL (1) 120 LR=PDL (0) 200 REM STRAIGHT 210 IF FB>75 AND FB<180 THEN POKE M,0 220 IF FB<75 THEN POKE M,5 230 IF FB>180 THEN POKE M,10 300 REM TURNING 310 IF PEEK (49249)>127 THEN GOTO 400 320 IF PEEK (49250)>127 THEN GOTO 440 330 GOTO 100 340 END 400 POKE M,0 410 POKE M,9 420 IF PEEK (49249)>127 THEN GOTO 410 430 GOTO 100 440 POKE M,0 450 POKE M,6 460 IF PEEK (49250)>127 THEN GOTO 450 470 GOTO 100 1000 REM INIT 1001 S=4:L=49280+S*16 1002 POKE L+3,1 1003 POKE L+2,63 1004 POKE L+1,0 1005 POKE L,0 1006 RETURN
As usual I forgot to mention something: yes, I made backup copies in case I do anything stupid to the file or the disk. :) The disk has an extra file called ROBOTBACKUPCOPY.BAS which I also saved to another disk. Meanwhile I've got the .dsk image saved, a text file saved, and now all of you have the code which is similarly archived in the previous email via our list which is hosted in an east coast data center.... so yeah there are enough backups if (when?) I do some dumbass thing and say "Oh crap!" and need to restore it. However, many of my disk labels aren't sticking well. I suppose the glue wears out. Suggestions on where to get newly-produced (not NOS) proper 5.25 labels? Or suggestions for other kinds of modern labels that won't come off?
2. Moving the stick left or right does nothing. That's by design. As I said I'm going to take a break from this project for a while. Later I might make L/R movement do what buttons 0/1 do now.
Okay so I lied. :) It occurred to me that changing the button control to joystick left/right is as easy as changing line 310 from this:
310 IF PEEK (49249)>127 THEN GOTO 400
To this:
310 IF LR<75 THEN GOTO 400
And line 320 from this:
320 IF PEEK (49250)>127 THEN GOTO 440
To this:
320 IF LR>180 THEN GOTO 440
And line 420 from this:
420 IF PEEK (49249)>127 THEN GOTO 410
To this:
420 IF LR<75 THEN GOTO 410
And line 460 from this:
IF PEEK (49250)>127 THEN GOTO 450
To this:
IF LR>180 THEN GOTO 450
That should work, right? Direct swap of the button code to the joystick left/right code. But it doesn't work. Not even close. I made a ROBOT2 file, changed that code, and it basically goes berzerk. Motors come on as soon as I run the program, moving the stick caused all kinds of conflicts, etc. Why didn't it work? What am I missing?
--------------------------------
10 REM INIT LEGO 20 GOSUB 1000 30 M=49344 40 POKE M,0: REM MOTORS OFF 100 REM LISTEN TO JOYSTICK 110 FB= PDL (1) 120 LR=PDL (0) 200 REM STRAIGHT 210 IF FB>75 AND FB<180 THEN POKE M,0 220 IF FB<75 THEN POKE M,5 230 IF FB>180 THEN POKE M,10 300 REM TURNING 310 IF PEEK (49249)>127 THEN GOTO 400 320 IF PEEK (49250)>127 THEN GOTO 440 330 GOTO 100 340 END 400 POKE M,0 410 POKE M,9 420 IF PEEK (49249)>127 THEN GOTO 410 430 GOTO 100 440 POKE M,0 450 POKE M,6 460 IF PEEK (49250)>127 THEN GOTO 450 470 GOTO 100 1000 REM INIT 1001 S=4:L=49280+S*16 1002 POKE L+3,1 1003 POKE L+2,63 1004 POKE L+1,0 1005 POKE L,0 1006 RETURN
I could just as easily make backup lights that way -- when the 'bot goes in reverse, turn on more extra lights and make the computer beep every few seconds!
Having too much fun now. I'll get my hands on more Lego lights another time (I think we have them at the museum), but for now I changed line 230 from this:
230 IF FB>180 THEN POKE M,10
To this:
230 IF FB>180 THEN POKE M,10: CALL -198: FOR W=1 TO 500:NEXT W
Now the robot has a backup alert just like your neighborhood dump truck. :)
I added a few lines... -------------------------- 10 REM INIT LEGO 20 GOSUB 1000 30 M = 49344 40 POKE M,0: REM MOTORS OFF 50 FOR X = 1 TO 5 60 HOME : PRINT "I AM LEINAD LEGOBOT!" 61 PRINT "" 62 PRINT "MOVE THE JOYSTICK UP" 63 PRINT "TO MAKE ME GO FORWARD" 64 PRINT "" 65 PRINT "MOVE THE JOYSTICK DOWN" 66 PRINT "TO MAKE ME GO BACKWARD" 67 PRINT "" 68 PRINT "PRESS THE LEFT BUTTON TO TURN LEFT" 69 PRINT "" 70 PRINT "PRESS THE TOP BUTTON TO TURN RIGHT" 71 PRINT "" 72 PRINT "PLEASE BE CAREFUL. I AM FRAGILE" 73 PRINT "" 74 PRINT "HAVE FUN! SINCERELY, LEINAD" 100 REM LISTEN TO JOYSTICK 110 FB = PDL (1) 120 LR = PDL (0) 200 REM STRAIGHT 210 IF FB > 75 AND FB < 180 THEN POKE M,0 220 IF FB < 75 THEN POKE M,5 230 IF FB > 180 THEN POKE M,10: CALL - 198: FOR W = 1 TO 500: NEXT W 300 REM TURNING 310 IF PEEK (49249) > 127 THEN GOTO 400 320 IF PEEK (49250) > 127 THEN GOTO 440 330 GOTO 100 340 END 400 POKE M,0 410 POKE M,9 420 IF PEEK (49249) > 127 THEN GOTO 410 430 GOTO 100 440 POKE M,0 450 POKE M,6 460 IF PEEK (49250) > 127 THEN GOTO 450 470 GOTO 100 1000 REM INIT 1001 S = 4:L = 49280 + S * 16 1002 POKE L + 3,1 1003 POKE L + 2,63 1004 POKE L + 1,0 1005 POKE L,0 1006 RETURN
On Sun, Jan 29, 2017 at 4:31 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I changed the subject line. "Not malfunction Stephanie!"
who is Stephanie
Special thanks to Dan for FORCING me to understand every single detail. I knew he's right and that there is no magic "make robot" button. :) Hopefully I also taught Dan something about how to teach such things to people who are just as intelligent as him :) but don't necessarily have the aptitude to pick it up so quickly.
think in Binary
Two notes:
1. I'm sure some of you will point out places where I could save a line here or a byte there. Chances are I will acknowledge that you are correct, but please don't be offended if I keep it the way it is. Once again, the point of this exercise is to have very straightforward code for kids and non-technical visitors. I will probably make a big poster showing code and a flow chart.
2. Moving the stick left or right does nothing. That's by design. As I said I'm going to take a break from this project for a while. Later I might make L/R movement do what buttons 0/1 do now. That would give people more standard joystick control to drive, backup, and steer. Then I can use the buttons for other tricks, such as turning on the headlights/taillights and controlling the opto/touch sensors. (Last fall, just for giggles, I put a brakelight in the Logo robot at World Maker Faire. Real easy -- when the 'bot stops, turn on the extra light behind a red Lego lens. I could just as easily make backup lights that way -- when the 'bot goes in reverse, turn on more extra lights and make the computer beep every few seconds! Turn signals would also be simple.) Lots of fun possibilities here.
Add a Bumper switch too next so it can sense it's environment On Sun, Jan 29, 2017 at 4:36 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
As usual I forgot to mention something: yes, I made backup copies in case I do anything stupid to the file or the disk. :) The disk has an extra file called ROBOTBACKUPCOPY.BAS which I also saved to another disk. Meanwhile I've got the .dsk image saved, a text file saved, and now all of you have the code which is similarly archived in the previous email via our list which is hosted in an east coast data center.... so yeah there are enough backups if (when?) I do some dumbass thing and say "Oh crap!" and need to restore it.
However, many of my disk labels aren't sticking well. I suppose the glue wears out. Suggestions on where to get newly-produced (not NOS) proper 5.25 labels? Or suggestions for other kinds of modern labels that won't come off?
and make a backup to the Cloud ;) <ducks and runs> On Sun, Jan 29, 2017 at 5:42 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I could just as easily make backup lights that
way -- when the 'bot goes in reverse, turn on more extra lights and make the computer beep every few seconds!
Having too much fun now. I'll get my hands on more Lego lights another time (I think we have them at the museum), but for now I changed line 230 from this:
Now the robot has a backup alert just like your neighborhood dump truck. :)
see now, this is a perfect opportunity to add a Five-Five-Five a 555 Beeper or Alarm circuit, the same kind of sound just as those Utility vehicles which is trigger every time you turn on a Port a little Homebrew addition never hurts somebody over there should have the necessary parts would cost only about $2 On Sun, Jan 29, 2017 at 6:55 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I added a few lines...
--------------------------
make a BACKUP Dan
On Sun, Jan 29, 2017 at 7:10 AM, Dan Roganti <ragooman@gmail.com> wrote:
On Sun, Jan 29, 2017 at 4:31 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I changed the subject line. "Not malfunction Stephanie!"
who is Stephanie
oh I see now another reference to the Johnny 5 movie it's been a while
On Sun, Jan 29, 2017 at 7:10 AM, Dan Roganti <ragooman@gmail.com> wrote:
2. Moving the stick left or right does nothing. That's by design. As I said I'm going to take a break from this project for a while. Later I might make L/R movement do what buttons 0/1 do now. That would give people more standard joystick control to drive, backup, and steer. Then I can use the buttons for other tricks, such as turning on the headlights/taillights and controlling the opto/touch sensors. (Last fall, just for giggles, I put a brakelight in the Logo robot at World Maker Faire. Real easy -- when the 'bot stops, turn on the extra light behind a red Lego lens. I could just as easily make backup lights that way -- when the 'bot goes in reverse, turn on more extra lights and make the computer beep every few seconds! Turn signals would also be simple.) Lots of fun possibilities here.
Add a Bumper switch too next so it can sense it's environment
so you might be wondering, why should I add that, cause I operate this under Remote Control well, it's just another -small- demonstration of adding intelligence, you know, the robot can now think, [adults only please] "hey dumbass, you made me hit the WALL, I'm going to turn around NOW" :) and assume control of itself for a brief time until it turns around the kids will get a kick out of seeing that Dan
On Sun, Jan 29, 2017 at 7:50 AM, Evan Koblentz <evan@vcfed.org> wrote:
don't fall victim that many of us failed sometimes, by using the old project for spare parts in the new project I saw you did that once already Save the old one too
Nope. Previous versions were science experiments. Nothing was worth saving other than the V-8 motor.
maybe not now, but after another 5yrs, you might regret it a lot of us have regretted this cause we run out of parts and start cannibalizing
Using direct bit values rather than that string T() string was a good work around. I'm very glad THAT worked, or else there was a real mess somewhere! I think you'll be happier with that method rather than the T() array in the long run anyway. The T() interface was very inefficient. But I can't explain why it didn't work either. On 1/29/2017 4:31 AM, Evan Koblentz via vcf-midatlantic wrote:
Special thanks to Dan for FORCING me to understand every single detail. I knew he's right and that there is no magic "make robot" button. :) Hopefully I also taught Dan something about how to teach such things to people who are just as intelligent as him :) but don't necessarily have the aptitude to pick it up so quickly.
Very nice. We have to always keep in mind the meeting folks where they are at with technical instruction. Great job, Evan, for working through it. I think you may be over the hump with the bitwise details and be on your way to more interesting control logic and your other high level language goals.
On Sun, Jan 29, 2017 at 10:56 AM, Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Using direct bit values rather than that string T() string was a good work around. I'm very glad THAT worked, or else there was a real mess somewhere! I think you'll be happier with that method rather than the T() array in the long run anyway. The T() interface was very inefficient. But I can't explain why it didn't work either.
On 1/29/2017 4:31 AM, Evan Koblentz via vcf-midatlantic wrote:
Special thanks to Dan for FORCING me to understand every single detail. I knew he's right and that there is no magic "make robot" button. :) Hopefully I also taught Dan something about how to teach such things to people who are just as intelligent as him :) but don't necessarily have the aptitude to pick it up so quickly.
Very nice. We have to always keep in mind the meeting folks where they
are at with technical instruction. Great job, Evan, for working through it. I think you may be over the hump with the bitwise details and be on your way to more interesting control logic and your other high level language goals.
oh what's that I hear......... I can hear people chanting in the background, what are they saying, let's take a look, <opening window> AS-SEM-BLY.......AS-SEM-BLY.......AS-SEM-BLY Dan :)
Very nice. We have to always keep in mind the meeting folks where they are at with technical instruction. Great job, Evan, for working through it. I think you may be over the hump with the bitwise details and be on your way to more interesting control logic and your other high level language goals.
oh what's that I hear......... I can hear people chanting in the background, what are they saying, let's take a look, <opening window> AS-SEM-BLY.......AS-SEM-BLY.......AS-SEM-BLY Dan :)
* THIS * exhibit is for children. I can't make that any more clear. Programming it in assembly is out of the question.
On 01/29/2017 04:50 PM, Evan Koblentz via vcf-midatlantic wrote:
Very nice. We have to always keep in mind the meeting folks where they are at with technical instruction. Great job, Evan, for working through it. I think you may be over the hump with the bitwise details and be on your way to more interesting control logic and your other high level language goals.
oh what's that I hear......... I can hear people chanting in the background, what are they saying, let's take a look, <opening window> AS-SEM-BLY.......AS-SEM-BLY.......AS-SEM-BLY Dan :)
* THIS * exhibit is for children. I can't make that any more clear. Programming it in assembly is out of the question.
Yes if Dan had to teach you assembly I doubt the language would be suitable for children. (hehe) -- Linux Home Automation Neil Cherry ncherry@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies
On Sun, Jan 29, 2017 at 5:21 PM, Neil Cherry via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On 01/29/2017 04:50 PM, Evan Koblentz via vcf-midatlantic wrote:
Very nice. We have to always keep in mind the meeting folks where they
are at with technical instruction. Great job, Evan, for working through it. I think you may be over the hump with the bitwise details and be on your way to more interesting control logic and your other high level language goals.
oh what's that I hear......... I can hear people chanting in the background, what are they saying, let's take a look, <opening window> AS-SEM-BLY.......AS-SEM-BLY.......AS-SEM-BLY Dan :)
* THIS * exhibit is for children. I can't make that any more clear. Programming it in assembly is out of the question.
Evan no, I meant just a friendly challenge to enlist you to personally advance up the "ladder"
Yes if Dan had to teach you assembly I doubt the language would be suitable for children. (hehe)
oh my !
On Sun, Jan 29, 2017 at 10:56 AM, Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Using direct bit values rather than that string T() string was a good work around. I'm very glad THAT worked, or else there was a real mess somewhere! I think you'll be happier with that method rather than the T() array in the long run anyway. The T() interface was very inefficient. But I can't explain why it didn't work either.
FYI, during those hours we spent awake late at night on debugging this problem, I mean Evan actually kept reminding me to go sleep, can you believe it :) those debugging steps took up a lot of time, eventually my version of the code morphed into a sort of telemetry display reminiscent of the vintage Nasa mission control days, a multitude of ascii screens in many rows I'm sure there are many fans here about that, but we had only one screen, close enough for now :) also it was kind of therapeutic while I was recuperating rather than binge watching movies every night it kept those gears in the brain clanking away all I had with me was a laptop with the emulators besides I didn't have to worry about getting the boss mad when you try to troubleshoot while on pain meds even worse, imagine trying to run the motion systems at work :) so I thank Evan et al for letting me tackle this So I made to this to keep track of the variables in the code [1st link] this was made in 40 col only then I figured why not switch to 80col and expand it[2nd link] the 80col mode had more room, so I decided to make the display into a flow-chart something that would make an educational display, more on a high school level but I was considering trying this too in the hi-res graphics mode since the apple ][ didn't have escape codes, I just used the Tab commands Applesoft basic has separate VTAB and HTAB commands, not only did this remove the scrolling, it helped speed up the display, cause only the data gets refreshed, the text remains the same But as usual then Basic starts to slow down with any more code or math, even the Prints can slow it down some more then I came across some old documents online from the 80s, where they were already complaining how Applesoft Basic is rather slow, I mean who wasn't, with any Basic, so several places made a Basic compiler too, just like the ones they had for CP/M http://www.rogtronics.net/files/ROBOT0.67.jpg http://www.rogtronics.net/files/ROBOT0.68.jpg Dan
also it was kind of therapeutic while I was recuperating rather than binge watching movies every night it kept those gears in the brain clanking away all I had with me was a laptop with the emulators besides I didn't have to worry about getting the boss mad when you try to troubleshoot while on pain meds even worse, imagine trying to run the motion systems at work :) so I thank Evan et al for letting me tackle this
You're welcome.
So I made to this to keep track of...
See that's the difference between us. My perspective is, "The robot works now. Move on." Your perspective is to spend the next three months in the rat-hole of machine code under Applesoft. :) Neither side is right/wrong. I hope you have fun with it, and it definitely would be cool if you lead an effort to discover something at the heart of the problem, but I'm moving on. :)
http://www.rogtronics.net/files/ROBOT0.67.jpg http://www.rogtronics.net/files/ROBOT0.68.jpg
Whoa. That DOES look very cool!
On Mon, Jan 30, 2017 at 1:51 AM, Douglas Crawford <touchetek@gmail.com> wrote:
But as usual then Basic starts to slow down with any more code or math, even the Prints can slow it down some more then I came across some old documents online from the 80s, where they were already complaining how Applesoft Basic is rather slow, I mean who wasn't, with any Basic, so several places made a Basic compiler too, just like the ones they had for CP/M
http://www.rogtronics.net/files/ROBOT0.67.jpg http://www.rogtronics.net/files/ROBOT0.68.jpg Dan
Very nice designs for displaying the status!
thanks !!
You could still produce those display without the T() array,
yes, these versions were before we switched to hard-coded values for the Poke's
you just have to do more work digging the bits out of the peek and poke data!
just to summarize, as I mentioned in the other thread, the original code works fine when only operating just one motor it only starts to go bezerk when operating multiple motors btw not sure if it was mentioned in the old thread, half of that code was found in the teacher's manual that was the various subroutines we posted here it's that pdf file I noticed in the zip file along with the Lego Lines disk image, and it also contained some files with example code, they have a chapter in there devoted to coding for the 9750 box directly, then we just added the Main code, with the joystick buttons or keyboard commands to get the robot to roll around You see the first disk image, Lego TC Logo, we found is what made these robot kits popular, the one which we were trying to extract way in the beginning, this had the flashy graphics screen where you can program the 9750 box but it was using customized commands, similar to Apple Logo. I think that was an earlier thread, where we had problems trying to examine that disk image and then I found out from another Apple Lego guy this was a unique file format entirely in binary, so not just assembly code for the program , but also the disk image it wasn't a standard Dos or Prodos image none of the tools we had could examine anything from it, so we gave up on trying to extract that disk, and then luckily I found the teacher's manual in the other "Lego Lines" disk image so this was how we got stuck, but we think that code provided by Lego was not fully tested, they probably tried it a few times with simple examples, saw that it worked with just one motor or lamp, maybe tried other ports, just as we did all along and then said, "good enough, ship it !!" because it seems there was little documented history of using this, but instead that first disk image was commonly used in schools, Lego TC Logo about the T(i), their idea about using the T(i) array is a very common practice this is basically the parameter variable which you transfer when you call other subroutines much like in Fortran, C, or other languages, when you call a function, you have parameter list to keep the important variables local, such as DB, in those subroutines since you like to avoid any possibility of corrupting DB elsewhere in the Main code but since we switched to using hard-coded values with the Poke's, I took a break and like to go back later and dissect that Applesoft Basic Interpreter some more, but since the new Basic code works fine with multiple motors, I'm not sure if I will try Assembly code just yet, I likely will find the same result with the Assembly code, that it works fine with multiple motors. And so there remains a quirk within the Applesoft Basic Interpreter. Dan
PS. I named this robot "Leinad".
I was on the phone with Dan just now. He'd be Googling to figure out where I got "Leinad". I told him to keep thinking about it REAL HARD. Finally it dawned on him that it's Daniel spelled backward. :)
On 1/29/2017 7:52 PM, Evan Koblentz via vcf-midatlantic wrote:
PS. I named this robot "Leinad".
I was on the phone with Dan just now. He'd be Googling to figure out where I got "Leinad". I told him to keep thinking about it REAL HARD.
Finally it dawned on him that it's Daniel spelled backward. :) "Leinad" -brought to you by Evan "Kubrick" Koblentz
participants (7)
-
Dan Roganti -
David Gesswein -
Douglas Crawford -
Evan Koblentz -
Neil Cherry -
william degnan -
William Dudley