I remember that program, I tried it when I was something like 12. Lots of questions here !
Actually you are missing the point. There are two distinct parts dealing with display. The initialisation part uses PUTCH to draw a target and the ball. But for the scroll, the pixels are manipulated directly in the video RAM, not with PUTCH. PUTCH is very slow, you can't use that for decent animations. You have to do everything yourself in the video ram, and that's what this program does.
Also, there is no text mode on Thomson. It's only graphic, text is actually
emulated by PUTCH. I remember that I was shocked when I first used a PC (was about 14). I could not understand why it was not possible to draw a line and that you had to switch to this weird CGA graphic mode first, to be able to draw a line.
The 320 is actually not related to the resolution of the screen but to the fact that the ball is 8x8 pixels. 8 pixels are defined by one byte and there are 40 bytes per line (40x8 = 320). Every 40 bytes, you are on the next line in the video. Since the ball is 8 pixels high, the distance in RAM between the first and the last segment of 8 is 40x8, hence 320 bytes. When the program copies the ball to the next column, it has to take one byte every 40 bytes 8 times. The adress is therefore incremented by 40 until 320 is reached.
If you want to understand this program, you must first understand how the video works on Thomson. It's key.
Now for your other questions:
1. X and Y are general purpose index registers, by opposition to A and B which are accumulators. They work differently. There's a whole set of instructions and addressing modes dedicated to them. X and Y are most of the time used to fetch and store data from/to the memory. For example :
is a pretty powerful statement. It loads 2 bytes of data from the adresses at X and X+1 in A and B, then increments the X pointer by 2. All that in a single instruction!
Don't make the mistake to think X and Y are accumulators or coordinates or whatever. Using X and Y as inputs when calling DRAWH is a mere convention that was decided by the guy who wrote the DRAWH routine.
2. Using the monitor routines such as KTSTH or DRAWH is for sure NOT the fastest way. It's actually awfully slow. Think of these routines as a kind of very simple kernel with simple drivers, well actually, you call that a monitor. Monitors were what was before kernels. These routines are here for compatibility (more or less identical on all Thomson machines) and to simplify a programmer's work.
There are three reasons why these monitor routines are slow :
a) they are generic and designed to do a lot of things. PUTCH is a kind of printf. It's huge. Freaky awesome, you'll love it. Believe me. But it's so slow.
b) to call them you actually invoke an interrupt, a bit like INT 21H in DOS or INT 80H in Linux. And that's slow, oh yes it is. Believe me, it's true.
c) the interrupt does a lot of other things before actually executing the routine you call. Things that you don't need, billions of stolen CPU cycles, total disaster.
So if you want to make your PC128 great again, you must do everything yourself and that means poking that video RAM damn hard and scrutinize the keyboard key per key. (hint: you may even scrutinize only the keys you need instead of the whole keyboard).
But you are too young for that. It's better to understand the various examples given in the book first.
This whole story is interesting because it tells a lot about why some software on Thomson were so awful and some were just unbelievable. 70-80% of the commercial software would use BASIC. BASIC is slooooooooooooooooow. 15% of the software would use assembly and the monitor, well that's much faster but still ... 5% of the software, the really good software, would use assembly and control every aspect of the electronics themselves, without the monitor. If all the software on Thomson were like these 5%, it would have been something, I can tell you.
Think of our OS-9 project (
http://os9.forler.ch, website totally outdated but project still up), it's crazy compared to Microsoft BASIC.