On 1/30/2017 3:05 AM, Dan Roganti wrote:


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

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 
​
Yes not a bad idea at all when the BASIC can handle it!
2 updates per second seemed pretty bad though.
Recreating Evan's program as he disclosed it was the first time
I sat at the Apple II and used Applesoft Basic.
I was pretty shocked at its performance at the slowness.
The same thing on he C64 would have been no problem.
I would have been tempted to "role out" the loops though, as in
DB=T(0)+T(1)*2+T(2)*4+T(3)*8+T(4)*16:POKE Address, DB
But more likely I would have chosen to parameterize with a single scaler variable
ie: set up variables for each bit,
T0=1:T1=2:T2=4:T3=8:T4=16
(Actually I'd name them for their function rather than just T, ie: MR=motor right=2 , ML=motor left=4, etc
(Just guessing at the correct name meanings/bitassignments)
and passing a set of bit selections via something like this to turn them on:  T=MR+ML:GOSUB "TurnOn1bits"
and then something like this to turn them off: T=MR+ML:GOSUB "TurnOff1bits"
I'm sure you've done things like this before too.

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.
Someday I would like to see the original code failing  with the hardware.
As I said, I can't explain why the T() version failed. I had suspicions that didn't
pan out.  When I printed the DB value I expected to see a bit value change
sporatically but it doesn't- but also the BASIC is so slow that actually if the
motors were stuttering then that's too fast for BASIC to be doing anyway.

Dan