Navigating Through the Display File Jungle

Those who’ve manipulated the nice orderly display file on the ZX-81/TS-1000 have been somewhat perplexed by the T/S 2068. Yes, the illustration on page 251 of the user’s manual that comes with the T/S 2068 does explain it. Still, most everyone reacts with the question, “Why?”

This configuration was made to dovetail with the Z80 instruction set to allow us to do some reasonably fast display file operations, But only if we understand how, 

If you’ve ever watched the distinctive way that a SCREEN$ is LOADed into the computer, 8 character lines at a time, you’ve actually seen the odd display layout. If you’ve taken an elementary digital design course, you may also have noted the similarity between that pattern and the nice regular spacing of some variables on a Karnaugh map. 

This might lead you to suspect that the strange display file layout is due simply to the rearranging of several address lines in the display circuitry. If so, you’d be correct. What this means is, we can start with a nice orderly row-column notation, and transform it to the display file notation simply by swapping several bits. Why then did they deliberately miswire the display hardware? 

There are some good reasons, honest! If we look at some of  the computers that the “big kids” use, we see that they have both text and graphic display modes. These modes are set in the display hardware. The graphics modes are, of course, simply to allow us to do graphic work. 

The text modes, however, relieve the computer of having to figure out which pixels to set in order to put a particular character on the screen. That’s all done in hardware. This buys us speed, at the expense of extra hardware. While the speed increase may not be noticeable when just a few words are put on the screen, there’s a definite difference when an entire screen of text is put up.

We might say that the T/S 2068 has no text modes, only graphics modes. 

The “text modes” are simulated in software. (The T/S 2068 DOES have to figure out which pixels need to be set in order to put a certain character on the screen.) This means that text operations to the screen will be somewhat slow.

To compensate, the machine’s designers used every trick they had to speed up this function.

For example, many readers are aware that the “pixel patterns” for the display characters are stored in a table at the top of the ROM, 8 bytes per character. Because we have the option to produce our own pixel patterns, the system variable CHAR$ “almost” points to this table. (Actually, CHAR$ points to a spot 256 bytes BELOW the table’s address.)

Now, to find the pixel pattern for a particular ASCII character, we do the following things: 

1. Put the ASCII value is a register PAIR.
2. Shift the value left 3 bits. 
3. Add the value in CHARS to this. 

And we have the address of the pixel pattern! Here’s why. First the pixel patterns for the various characters are arranged in the order of their ASCII value. The first 8 bytes are the pattern for a blank space, which is decimal 33, and to on. The left shift multiplies everything by 8, since each pattern takes up 8 bytes. Now, since the value of the first character is not 

zero, but decimal 32, we’d ordinarily have to subtract (32X8) or 256 from this result to get the proper displacement into the CHAR$ table. But the value in CHAR$ is already 256 counts LOWER than the address of the table, and so the subtraction doesn’t have to be done! This saves us some time in computing the address, It’s not a lot of time, but every little bit helps. 

Once we have the address of the 8 bit pixel pattern bytes, we have to figure out where in the display file to put them. Before we do this, please read over the description in the box on going from a 3 pixel row-column notation to the display file notation. This starts us with a pixel row and column, and transforms them to a memory address and a bit position within the memory byte. Note that my pixel notation is not the same as the one used by BASIC; see page 152 of the T/ S 2068 user’s manual. Basic has to first transform to its own pixel notation into the one shown here, and THEN it transforms that to a display file position. (Silly but true). 

Finding the display file location is the topmost byte of the character is easily done when you understand the description in the box. However, doing the same thing 9 times for each character would waste a lot of time. Fortunately, when you know where one pixel line for a character is located, it’s very easy to find others, Look in the box at the T/S 2068/Spectrum display file format. By adding 256 decimal to the address for a given pixel line, we’ll get the address of the pixel line below it, because we’ve just incremented the “pixel line in character” field, We can only do this until the field becomes 111, binary, but at that point we’re at the bottom line for the character, and don’t WANT to do any more, 

Suppose the display file had been laid out in the more orderly fashion? The “pixel line in character” field would be swapped with the “line in 8-group” field. That’s all. Then to find the address of the next pixel line we’d add 32 decimal, instead of 256. But this is NOT as convenient. 

If the address were in the HL register, for example, we could add 256 by simply doing an INC H. Adding 92 would require us to ADD some other register to HL. This not only takes longer, but ties up an additional register pair. This is even worse, because it turns out we can’t easily use the DJNZ instruction for a test loop if we tie up any extra registers. It may not be obvious until you try to write the code for yourself, but it’s so. As things really are, we have just enough registers.

While the ROM display routine uses this trick to gain speed, it loses it again, for other reasons. This is because the same routine also handles the standard graphics characters, user defined graphics tokens, the T/S 2040 printer, things like INF, BRIGHT, INVERSE, FLASH, and moving the character position in response to AT and TAB. It wastes lots of time checking what it’s supposed to be doing, and then saves a little time when it finally gets around to doing it. 

So what’s the point? Programs like word processors tend to contain their own custom display routines that run VERY fast. The information given in this article is sufficient for the enterprising machine code programmer to write his or her own, and if you’ve been trying to put data directly into the display file, this might be just what you’ve been looking for. 

This will be little help to those who want to PEEK and POKE the display file from BASIC. The BASIC commands for operating on the display file probably will work faster and are certainly a lot easier.  

Also note that even in machine code, this odd display file layout will force graphics routines to run slower than they otherwise might, since you have to swap address bits to get the row-column position you want. 

But what it does, it does well. While it sacrifices some graphics speed, it gives us a faster text display, in a way, it “narrows the gap” between them. There will be some users who lose out by this design decision, but I think the majority of us would be much more irritated by slower text. Oh well, you can’t please everyone.