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.