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.

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.

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.

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.

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.

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:

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.

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.

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.

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.