You've probably seen this game featured on ticalc.org. But here is a topic about it.
Now I'll take this opportunity to explain the weird technical side of it.
First off, the game was originally designed to be run on 83+'s. So the whole thing was written with 6MHz. The playing field actually 150 rows tall by 104 pixels wide. The whole thing scrolls 2 pixels per frame. This is how I got such good scrolling. When the screen has to scroll up or down, it doesn't have to re draw anything because that part of the screen is already drawn, it just goes and looks for it.
The screen is 104 pixels wide so that all I have to do is copy and paste the new shapes in when it is their time. Then they get naturally shifted across the screen. To make the whole process easier, the entire 150 row screen buffer is upside down. It just makes for easier math, (and causes DCS glitches).
To make all this happen at 6MHz, most of the game actually executes in the free space between screen writes. I disable the port ($29) delay so that I must use around 80 t-states between writes. Starting at the right side of the screen, the first three columns of 8 are spent copying the last 8 columns to plotSScreen. The 4th column is spent drawing the square. It also copies attempts counter from another buffer where it is pre drawn. And the last 8 rows are spent shifting the screen buffer. This is why the attempts is slightly off center, the right four columns are pulled directly off the big screen buffer and cannot be changed every frame.
There, now finally you all will know the thought that went into this. Ha!
Now I'll take this opportunity to explain the weird technical side of it.
First off, the game was originally designed to be run on 83+'s. So the whole thing was written with 6MHz. The playing field actually 150 rows tall by 104 pixels wide. The whole thing scrolls 2 pixels per frame. This is how I got such good scrolling. When the screen has to scroll up or down, it doesn't have to re draw anything because that part of the screen is already drawn, it just goes and looks for it.
The screen is 104 pixels wide so that all I have to do is copy and paste the new shapes in when it is their time. Then they get naturally shifted across the screen. To make the whole process easier, the entire 150 row screen buffer is upside down. It just makes for easier math, (and causes DCS glitches).
To make all this happen at 6MHz, most of the game actually executes in the free space between screen writes. I disable the port ($29) delay so that I must use around 80 t-states between writes. Starting at the right side of the screen, the first three columns of 8 are spent copying the last 8 columns to plotSScreen. The 4th column is spent drawing the square. It also copies attempts counter from another buffer where it is pre drawn. And the last 8 rows are spent shifting the screen buffer. This is why the attempts is slightly off center, the right four columns are pulled directly off the big screen buffer and cannot be changed every frame.
There, now finally you all will know the thought that went into this. Ha!
Regarding that perfect run - was that automated, or are you just that good? Or, third option, did you spent several days screenshotting over and over until you got it right? 
At any rate, excellent job, and I'm extremely impressed by the fastcopy wasted-cycle use trick. Thanks for sharing the technical details. 
