Jump to content

Photo

ECS BASIC Color Coding Patent

intellivision ecs basic ecs

32 replies to this topic

#26 intvnut ONLINE  

intvnut

    River Patroller

  • Topic Starter
  • 3,124 posts
  • Location:@R6 (top of stack)

Posted Thu Nov 1, 2018 9:45 AM

Yikes, OK.  I hadn't realized level 8 had that property.  *d'oh*  If I had once known that, I'd forgotten it.

 

I re-ran at level 6, and profiled around 2hrs of play.  It looks like the EXEC consumes about 2.7% of the total cycles.

 

shot0004.gif

 

I wrote a Q&D perl script to total up the time spent in the EXEC (cycles spent in $1000 - $1FFF) vs. time spent in the game (cycles spent in addresses above $1FFF).  It reported:

.

Exec cyc:   187689134
Game cyc:   6663889944

.

When I divide that out, I get 2.7%.

Attached Files


Edited by intvnut, Thu Nov 1, 2018 10:16 AM.


#27 mr_me OFFLINE  

mr_me

    River Patroller

  • 3,523 posts
  • Location:Ontario

Posted Fri Nov 2, 2018 5:49 AM

I'm guessing with typical exec based cartridges, the exec uses a lot more than 3% of the processing time. With chess does that happen naturally because there's no sounds, no moving objects or did the chess programmers have to work around the exec. What would the exec processing time be for a simple ecs basic program test.

#28 intvnut ONLINE  

intvnut

    River Patroller

  • Topic Starter
  • 3,124 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 2, 2018 6:41 PM

I'm guessing with typical exec based cartridges, the exec uses a lot more than 3% of the processing time. With chess does that happen naturally because there's no sounds, no moving objects or did the chess programmers have to work around the exec. What would the exec processing time be for a simple ecs basic program test.

 

Chess installs its own ISR to handle display blanking, the chess clock, and "FORCE MOVE".  It chains back to the EXEC ISR I believe to handle animation and sound.  There is some animation and sound, basically at the start and end of a move. 



#29 mr_me OFFLINE  

mr_me

    River Patroller

  • 3,523 posts
  • Location:Ontario

Posted Fri Nov 2, 2018 8:11 PM

Yeah but with 12 moves in over two hours, there's no sounds, no animation other than the clock, 99% of the time. So even though it hooks back to the exec sprite routines, they aren't taking much cpu time. If it's similar, an ecs basic program should have low exec usage as well.

#30 intvnut ONLINE  

intvnut

    River Patroller

  • Topic Starter
  • 3,124 posts
  • Location:@R6 (top of stack)

Posted Sat Nov 3, 2018 3:30 AM

Yeah but with 12 moves in over two hours, there's no sounds, no animation other than the clock, 99% of the time. So even though it hooks back to the exec sprite routines, they aren't taking much cpu time. If it's similar, an ecs basic program should have low exec usage as well.

 

It's harder to tell with ECS BASIC than it is with Chess.  Because ECS BASIC primitives synchronize with the EXEC, I believe there are delays in the ECS BASIC interpreter where it waits to sync with the EXEC, whether or not it needs to.

 

This isn't time spent in the EXEC, but it is time spent in consequence of the EXEC.  The lines are a bit blurrier between ECS BASIC and the EXEC.

 

EDIT:  FWIW, I did run my silly perl script on the dump.hst and dump2.hst I posted earlier from my 162 and 203 second runs.  For dump.hst, 23% of the cycles were spent in the EXEC.  For my optimized version, only 19% of cycles were spent in the EXEC.  Clearly there's a bit of non-linear behavior here, as I did not optimize the interaction between the code and the EXEC.


Edited by intvnut, Sat Nov 3, 2018 3:38 AM.


#31 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,486 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sun Nov 4, 2018 5:51 AM

 

It's harder to tell with ECS BASIC than it is with Chess.  Because ECS BASIC primitives synchronize with the EXEC, I believe there are delays in the ECS BASIC interpreter where it waits to sync with the EXEC, whether or not it needs to.

 

This isn't time spent in the EXEC, but it is time spent in consequence of the EXEC.  The lines are a bit blurrier between ECS BASIC and the EXEC.

 

EDIT:  FWIW, I did run my silly perl script on the dump.hst and dump2.hst I posted earlier from my 162 and 203 second runs.  For dump.hst, 23% of the cycles were spent in the EXEC.  For my optimized version, only 19% of cycles were spent in the EXEC.  Clearly there's a bit of non-linear behavior here, as I did not optimize the interaction between the code and the EXEC.

 

Is the ECS BASIC really just blocked waiting on the EXEC?  I thought that it was synchronized with the EXEC in that the EXEC is the one which "ticks" the interpreter engine.  In that way, the ECS BASIC is just another "game" running off the EXEC in EXEC time.

 

Consequently, keys are read at 20 Hz, and each statement is executed on an EXEC "tick" boundary (every 20 Hz).

 

Perhaps this is what you meant, but I guess I make a distinction between something like an IntyBASIC program, which runs in its own game loop and then has to "WAIT" for the ISR to synchronize, and an EXEC program which are just a bunch of subroutines triggered by the EXEC itself as it chug alongs in its game engine loop. I always thought the ECS BASIC was the latter.

 

    -dZ.



#32 intvnut ONLINE  

intvnut

    River Patroller

  • Topic Starter
  • 3,124 posts
  • Location:@R6 (top of stack)

Posted Sun Nov 4, 2018 2:54 PM

 

Is the ECS BASIC really just blocked waiting on the EXEC?  I thought that it was synchronized with the EXEC in that the EXEC is the one which "ticks" the interpreter engine.  In that way, the ECS BASIC is just another "game" running off the EXEC in EXEC time.

 

Consequently, keys are read at 20 Hz, and each statement is executed on an EXEC "tick" boundary (every 20 Hz).

 

Perhaps this is what you meant, but I guess I make a distinction between something like an IntyBASIC program, which runs in its own game loop and then has to "WAIT" for the ISR to synchronize, and an EXEC program which are just a bunch of subroutines triggered by the EXEC itself as it chug alongs in its game engine loop. I always thought the ECS BASIC was the latter.

 

ECS BASIC is not implemented as an EXEC "process", in terms of its timer-driven process table.

 

The ECS BASIC interpreter loop does, however, synchronize with the EXEC's 20Hz phase counter, blocking the "RUN" loop from progressing.  The top of the keyword interpretation loop has this:

.

        ; main interpreter outer loop during 'RUN'
L_2E25:
        MVI     G_0102, R0              ; 2E25   Get current EXEC phase
        CMPI    #$0002, R0              ; 2E27   Is it phase 2 or higher?
        BGE     L_2E2C                  ; 2E29   Proceed with execution

        PULR    R7                      ; 2E2B   Otherwise, don't.

.

When you launch BASIC in the fastest execution mode—it is actually sensitive to the "slow down" mode based on pressing 1, 2, 3 instead of DISC, if memory serves—it watches the EXEC variable at $102 to determine which part of the 20Hz cycle it's in.  It ordinarily counts down 2, 1, 0, 2, 1, 0.  (In slower modes, it counts down from a higher number, which is how it achieves its slow-down.)   Here's a trace of $102 from an EXEC based game (Astrosmash).  You'll note it briefly takes on the value 3, but that's in anticipation of it getting decremented.  It's a 20Hz cadence if you do the math on the cycle counts.  ECS BASIC would only see the 2, 1, and 0, if I'm not mistaken.

.

 WR a=$0102 d=0003 CP-1610          (PC = $1097) t=5247326
 WR a=$0102 d=0002 CP-1610          (PC = $1130) t=5259726
 WR a=$0102 d=0001 CP-1610          (PC = $1130) t=5274666
 WR a=$0102 d=0000 CP-1610          (PC = $1130) t=5289600
 WR a=$0102 d=0003 CP-1610          (PC = $1097) t=5291985
 WR a=$0102 d=0002 CP-1610          (PC = $1130) t=5304533
 WR a=$0102 d=0001 CP-1610          (PC = $1130) t=5319468
 WR a=$0102 d=0000 CP-1610          (PC = $1130) t=5334402
 WR a=$0102 d=0003 CP-1610          (PC = $1097) t=5336693

.

So, the run loop is literally synchronizing with the EXEC by watching an EXEC state variable and busy-waiting.  If an ECS BASIC statement takes less than 1/20th of a second to execute, it gets rounded up to 1/20th of a second. If an ECS BASIC statement takes longer than 1/20th of a second to execute, its execution time effectively gets rounded up to the next 20Hz boundary.  Every statement ultimately seems to take some multiple of 1/20th of a second thanks to this busy-wait.

 

That's why I say that the execution penalty incurred due to the EXEC doesn't reside entirely inside the EXEC.  Much of it is in the busy-wait outside the EXEC in the main interpreter loop, in this synchronization point that waits for the EXEC to get into one of the 3 phases of its 20Hz cycle.

 

Ironically, it appears you can speed up ECS BASIC by selecting a slower EXEC speed (pressing 1, 2, or 3 at the menu).  I'll have to experiment with that later.


Edited by intvnut, Sun Nov 4, 2018 2:55 PM.


#33 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,486 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sun Nov 4, 2018 3:09 PM

 

ECS BASIC is not implemented as an EXEC "process", in terms of its timer-driven process table.

 

The ECS BASIC interpreter loop does, however, synchronize with the EXEC's 20Hz phase counter, blocking the "RUN" loop from progressing.  The top of the keyword interpretation loop has this:

.

        ; main interpreter outer loop during 'RUN'
L_2E25:
        MVI     G_0102, R0              ; 2E25   Get current EXEC phase
        CMPI    #$0002, R0              ; 2E27   Is it phase 2 or higher?
        BGE     L_2E2C                  ; 2E29   Proceed with execution

        PULR    R7                      ; 2E2B   Otherwise, don't.

.

When you launch BASIC in the fastest execution mode—it is actually sensitive to the "slow down" mode based on pressing 1, 2, 3 instead of DISC, if memory serves—it watches the EXEC variable at $102 to determine which part of the 20Hz cycle it's in.  It ordinarily counts down 2, 1, 0, 2, 1, 0.  (In slower modes, it counts down from a higher number, which is how it achieves its slow-down.)   Here's a trace of $102 from an EXEC based game (Astrosmash).  You'll note it briefly takes on the value 3, but that's in anticipation of it getting decremented.  It's a 20Hz cadence if you do the math on the cycle counts.  ECS BASIC would only see the 2, 1, and 0, if I'm not mistaken.

.

 WR a=$0102 d=0003 CP-1610          (PC = $1097) t=5247326
 WR a=$0102 d=0002 CP-1610          (PC = $1130) t=5259726
 WR a=$0102 d=0001 CP-1610          (PC = $1130) t=5274666
 WR a=$0102 d=0000 CP-1610          (PC = $1130) t=5289600
 WR a=$0102 d=0003 CP-1610          (PC = $1097) t=5291985
 WR a=$0102 d=0002 CP-1610          (PC = $1130) t=5304533
 WR a=$0102 d=0001 CP-1610          (PC = $1130) t=5319468
 WR a=$0102 d=0000 CP-1610          (PC = $1130) t=5334402
 WR a=$0102 d=0003 CP-1610          (PC = $1097) t=5336693

.

So, the run loop is literally synchronizing with the EXEC by watching an EXEC state variable and busy-waiting.  If an ECS BASIC statement takes less than 1/20th of a second to execute, it gets rounded up to 1/20th of a second. If an ECS BASIC statement takes longer than 1/20th of a second to execute, its execution time effectively gets rounded up to the next 20Hz boundary.  Every statement ultimately seems to take some multiple of 1/20th of a second thanks to this busy-wait.

 

That's why I say that the execution penalty incurred due to the EXEC doesn't reside entirely inside the EXEC.  Much of it is in the busy-wait outside the EXEC in the main interpreter loop, in this synchronization point that waits for the EXEC to get into one of the 3 phases of its 20Hz cycle.

 

Ironically, it appears you can speed up ECS BASIC by selecting a slower EXEC speed (pressing 1, 2, or 3 at the menu).  I'll have to experiment with that later.

 

Gotcha!  So essentially, all statements are executed on an EXEC "tick" boundary (20 Hz), but that's accomplished by synchronizing the ECS BASIC "RUN" loop with a busy-wait.  That's interesting.

 

I guess it is one way to avoid putting the onus on the user of having to synchronize themselves (like IntyBASIC does) when using ISR-sensitive features (like sprite updates or color modes).  It's the sort of thing I would have done with P-Machinery in order to simplify the programming model of users.

 

The problem is that the EXEC is already running at 20 Hz and the BASIC interpreter is a bit slow, so that is one heck of a penalty. :o

 

Thanks for the details.

 

    -dZ.


Edited by DZ-Jay, Sun Nov 4, 2018 3:10 PM.






Also tagged with one or more of these keywords: intellivision, ecs basic, ecs

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users