On Wed, May 24, 2017 at 10:35 PM, David Gesswein via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Wed, May 24, 2017 at 01:14:10PM -0400, Dan Roganti via vcf-midatlantic wrote:
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)
This code can give errors in the count since say the counter was 78 = 255 and 79 = 1 when you execute the peek(78) and then it increments to 0, 2 before the peek(79) You will then get 255, 2. Don't know if its important to our usage.
There are techniques to handle this such as reading high, then low, then high again to see if you read over a rollover. I can provide more if interested.
yes, Basic code will always have some pitfalls This is by far not a highly accurate Timer, it's a software Timer I found this method in an old 80s article as an alternate solution Atomic Reads in Basic code is the least of all options that's possible I'm not entirely aware of the Applesoft Kernel Rom internals, If you run this in a loop, and print the values continuously on the screen, I almost never see this scenario happen, but I confess my eyes are tired maybe I should save it in a file to look it over Probably since the Basic Kernel Rom isn't running that much faster. And since the Basic code is interpreted, this scenario can be considered negligible Of course, Assembly code with a Hardware Timer is still by far the optimum solution.
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
That's not really correct. Say T1 was 255,255 = 65535 and T2 is 0,0. Subtract is -65535. Just flipping the sign gives 65535. The correct difference is 1. Correct correction if negative time is 65536 + difference I think. This type of stuff is a lot harder than it looks.
I see what you mean, your scenario shows when the counter wraps around. Since that's only a Calibration Test code, in order to determine the constant for 1sec elapsed time, I only accounted for normal situations with small amounts of elapsed Time, eg T2=1000, T1=2000, then the difference is -1000, multiply -1, then diff = 1000 That scenario would be significant within the actual robot code. Then you would need to add a check in the code for whenever the Counter wraps around. But then Basic code wouldn't be fast enough to check the Carry Bit of the Add Acc operation for when the Counter wraps around. Here again, Assembly code would come in to "Save the Day", just like UnderDog :) In Basic code, you can use this to check for that wrap around. If ABS(T2-T1) > 65535-T1 is True Then you know the Counter wrapped around like in your scenario eg. T1=65000, T2=0 IF ABS(T2-T1) > 65535-T1 IF ABS(0-65000) > 65535-65000 65000 > 535 [True] Then this means the Counter has wrapped around, so skip this T2-T1 value and try again versus the normal scenario T1=1000, T2=2000 IF ABS(T2-T1) > 65535-T1 IF ABS(2000-1000) > 65535-1000 1000 > 64535 [False] Then this means the Counter has not wrapped around, so this T2-T1 value is valid Dan -- _ ____ / \__/ Scotty, We Need More Power !! \_/ _\__ Aye, Cap'n, but we've only got 80 col's !!