On Wed, May 24, 2017 at 12:10 PM, Dan Roganti <ragooman@gmail.com> wrote:
On Wed, May 24, 2017 at 1:02 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Suppose I want an Applesoft (Microsoft) BASIC program to do something for a certain amount of time as measured in seconds or minutes. FOR-NEXT loops don't align to any real increment -- they just count based on how fast the processor can go, right? If so, then how do you make something happen for a time amount?
On Wed, May 24, 2017 at 10:10 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Thanks everyone. Interesting stuff. Here's something I do not understand. Lego's modified version of Logo has a command, COUNTER, which they say increments in tenths of a second. One of their sample programs runs the counter to 600 to give you a minute of something happening (a motor spinning). I didn't time it against a real clock, but, how could this work? The same Logo environment disk runs identically in anything from a ][+ through a GS. (My demo uses a Laser 128 as you'll recall.)
The Apple ][ and Applesoft Basic doesn't have an exact counter/timing mechanism built-in. There's only a couple of software methods available in a stock Apple ][ eg #1. For/Next loop -- you know already how to do this #2. Timer [software/Kernal Rom] I mentioned this to you before [see my old email with the sample code in Basic from 4/14/17] Even though this is still software controlled, this is incremented using the Applesoft Kernel machine code, So this is more accurate than the For/Next loop in BASIC In Zero page memory, you have 16bit binary counter, decimal 0 to 65535 at locations $4E, $4F, in basic you would use PEEK(78), PEEK(79)
[SNIP]
I would suggest sticking with that Counter I mentioned in zero page memory at $4E,$4F -- PEEK(78), PEEK(79) Dan
might as well post the sample code in here too so you just need the decimal value, this is a 16bit binary counter, so in decimal it's 0 to 65535 T1 = PEEK(78) + 256 * PEEK(79) You'll have to use this calibration test code and a stopwatch to find how many ticks of that Counter will get 1sec of time eg 10 T1 = PEEK(78) + 256 * PEEK(79) 20 FOR J=1 TO 1000:NEXT J 30 T2 = PEEK(78) + 256 * PEEK(79) 40 PRINT T2-T1 50 END Then adjust J for 1sec before the PRINT displays the answer But it will wrap around, cause this Counter is non-stop so sometimes T2-T1 will be negative just convert it back to positive if T2 <0 by multiplying this with -1 When you add this to your robot code, you'll have to adjust J again, Because the extra lines from your robot code will create more delay But at least you'll be in the ballpark, just calibrate this again using your robot code and a stopwatch to tweak the measurement closely. That difference will now be your constant for 1sec of time Now you can use this measurement for things such as travel time in the robot But there's one slight glitch to work around, [on live hardware - some emulators don't replicate this entirely] I know you like to use RUN "filename" most of the times But for some reason that Counter is frozen at a fixed value, basically from the time you Power On the computer. So just do this first, LOAD "filename", then RUN And so the counter will be free running for as long as the computer is On Dan -- _ ____ / \__/ Scotty, We Need More Power !! \_/ _\__ Aye, Cap'n, but we've only got 80 col's !!