Not all programs need to be games. And, in the case of Screen Copy, it is a demo program that ultimately became a utility. Most of us take the idea of making a screen shot for granted. Yet, back in the early ’80s, the idea was uncommon. That didn’t deter me.
Not quite an iPhone.
Of course, the idea of saving to printer wasn’t unique. Even the ZX81 had a way to print the screen using the
COPY command. In a way, it isn’t much different than the PC’s Print Screen key. But that really isn’t the point. Sometimes, you just want to grab a copy of what’s on the screen for future use. That is where Screen Copy comes in.
Although it doesn’t display a nice thumbnail that you can select and share, Screen Copy does exactly what it says. Using a simple string array, it scans the display map and saves what it finds into it.
Of course, this is a demo program, so it does a little bit more than that. In this case, Screen Copy displays a couple of patterns on the screen to give it something interesting to grab. For many readers, this will be the most interesting part of the program. A series of
FOR loops are used to invert the screen, which then creates triangles that intersect into an hour glass shape.
Screen Copy, 1984 by Steven Reid
Once complete, the real work begins. Screen Copy spends a good deal of time scanning each line and dumping it into the array. I sped this up a big using
FAST so you wouldn’t have to wait. Once done, the program clears the screen and prints what it copied.
What’s the use?
Although well documented, Screen Copy could be better. The animation code is decent enough and, for the purposes of this article, I’ll leave as is. But the copy routine itself is dreadful. Straightforward and slow, the routine works but lacks elegance. The epitome of brut force, I obviously was just testing things and not trying to optimize.
Using the ZX81’s
FAST command helped, but it was something I added later. Given that the screen is well known, I could more easily of just copied each character from memory using a loop. Eliminating the
PRINT AT should return quite a few cycles. Using a little assembly routine would be even faster and, for added benefit, reusable. As is, the code is a great demo, but not useful.
A few tweaks.
The program works as designed, but doesn’t lend well to sharing. Besides speeding up the copy routine, I added in a title and action language at the end of the program. This ensures that you can run it over and over again.
Some other fun exercises would be to optimize the array. A screen takes up almost a third of a kilobyte of ram. For a tiny 16K machine, together with the existing screen you’re burning a 10th of what is available to you. Given the routine would be helpful in large programs, the routine needs some compression. Using BASIC would be too slow, but a fast copy routine in Assembly would do the trick. In fact, it could come close to the iPhone.
Some randomness in the animation would also be helpful. The loops are straight forward as is. But, each could have been modified slightly to provide some more interest. Again, these are ideas and not really uses for the routine itself. The existing
COPY command should suffice to record the screen. In this case to an external printer.
An otherwise simple demo, Screen Copy does what it says. No fluff or frills. But still not an iPhone.