INSIGHT: Atari

Bill Wilkinson

Last month, I said that this month's column would include the final part of the series on writing self-relocatable code. Unfortunately, that project has turned out to be bigger than I thought it would be, so I am going to put it off a month and devote an entire column to it. However, as compensation, I will finally discuss the "new" Atari graphics modes I hinted at a couple of months back. Before I get to the juicy stuff, though, I'd like to continue a little of the ranting and raving that I started last month.

How To Shed 50 Kilobytes Without Even Trying

I heard (from two different sources) the official Atari "line" regarding the new 1050 disk drives. It seems that Atari chose to utilize only 128 bytes per sector and only 127K bytes of file space per drive in order to achieve "increased reliability." Honest. Do you believe it?

Actually, that's pure computer puckey (to paraphrase Colonel Sherman Potter). And it's ridiculous for several reasons.

First off, Atari is implying that double-density drives are unreliable. If that's true, then IBM, Radio Shack, Commodore, and a lot of other computer companies are in real trouble. Actually, Atari and Apple are the ony major computer companies still relying on single-density technology as their primary modus operandi. And, despite Atari's claims, even Atari's 1050 is actually using true double density.

It turns out – based on what we have gleaned from the specs of DOS III at this time – that Atari formats the 1050 drive with 40 tracks of 32 sectors each, with 128 bytes per sector. That's a total of 160K bytes. Most double-density manufacturers achieve either identically the same total (40 tracks times 16 sectors times 256 bytes) or slightly more (40 tracks times 18 sectors times 256 bytes equals 180K bytes – the format used by most Atari-compatible drives such as Percom, Astral, Micro-Mainframe, etc.). So why does Atari claim only 127K bytes?

Real simple: DOS III only supports 127K bytes. Shall I say that I don't know why Atari chose this limitation? With a relatively minor modification, and by using only another 64 bytes of memory per drive, DOS III could have supported a full 180K drive.

Now, as it turns out, I do happen to know the real reason Atari chose 128 bytes per sector. And I know this from the most reliable of sources, one of the DOS Ill's designers.

It seems that so many of Atari's own products violate Atari's own "rules" (especially those about respecting the LOMEM pointers), and so many other products also reach outside DOS to do direct sector disk I/O that Atari's planners were fearful of the impact of changing either LOMEM or the sector size. Hence the scheme of DOS III.

A secondary impact of the LOMEM problem was that it caused more and more of DOS III to be moved to the diskette from memory, to be called in as overlays when the user requested a function not in memory. Even the keyboard menu processor eventually got moved to disk. The result of all this? While DOS III may be the easiest-to-use DOS yet, it still suffers from the time-consuming swaps to a MEM.SAV file when you want to achieve something as simple as getting a disk directory.

(Of course, there is a very, very elegant way to completely avoid the LOMEM problem on the new Atari XL computers. Why not move the DOS into the as-yet-unused extra memory? Why waste 14K bytes of RAM? I probably shouldn't drop this idea in Atari's laps [I should sell it to them], but it will take them at least six months to even discuss it, so I figure it's OK.)

As I said last month, DOS III contains a nice little file manager. It's a crying shame that it wasn't released three or four years ago, since it seems ideally suited to an 810 size drive. But it doesn't look to me like a system for the long haul, when larger and larger drives become available for the new Atari computers.

And lest too many of my critics cry "foul" for my promoting OSS's version 4 DOS (which will allow up to 32 megabytes per disk drive), let me hasten to say that I am not suggesting that version 4 and the 1050 are necessarily the answer. What I am saying is that Atari could have achieved virtually the same results by sticking with DOS 2.0 and extending it to handle up to 120K bytes of file space (with 128 byte sectors – it will handle 240K bytes with 256 byte sectors).

Well, enough. I promise no more on this subject until I give you the patches to DOS 2.0s to give you 120K bytes on a 1050. In the meantime, ask yourself this question: if DOS III is limited to 127K bytes of file space, how will Atari handle the double-sided, double-density drive in the 1450XLD, which will have a capacity of at least 320K bytes? Atari, will you answer?

One more comment. I just want to say that, aside from the 1050,1 am impressed with all of Atari's new hardware products. And I even like some of their new software. I think Atari is back on its feet and running hard.

Four Equals Seven

Many of the games currently on the Atari market use custom-designed character sets for background displays. The classic example of this is, of course, Eastern Front by Chris Crawford. That beautiful scrolling map he displays is actually composed of "characters." This works because a couple of the ANTIC graphic modes allow the programmer to treat each pair of bits within a character cell as one of four colors.

In fact, by controlling the high order bit of the character to be displayed, the programmer may choose two different sets of four colors. Which would be really nice except for the fact that only one of the colors can change between the two sets, thus there is a total of five displayable colors.

If you don't remember and/or understand all that, don't worry. There's a better way. A way which will get you seven colors! The method only works on machines with a GTIA installed, but I hope that all COMPUTE! readers have added a GTIA by now. (If you have purchased a machine in the last year and a half or so, you got a GTIA with your machine. If you have an old machine with a CTIA, the upgrade cost is nominal.)

The credit for finding and documenting this until now hidden feature of the Atari must go to Steve Lawrow, the author of our MAC/65 assembler. He did a nice job of investigating all the ramifications and provided me with the table which I've reproduced here. Before I go into the details of the table, though, let me briefly describe how one accesses two new Atari Graphics modes.

Getting At The New Modes

First, the new modes are variations on BASIC GRAPHICS 1 and GRAPHICS 2 (and, by extension, GR. 17 and GR. 18). And the method of producing the variations is so simple that it's almost funny that no one stumbled on it before. Simply turn on the GTIA's special color mapping mode. And what, pray tell, is that? In this case, it is the upper bit of GPRIOR, the priority select register.

GPRIOR is a hardware register that has its OS shadow location at $026F (decimal address 623). That means (for those of you not familiar with shadow locations) that by changing the RAM location $026F you cause the OS to change the appropriate hardware register for you. (And see COMPUTE!'s book Mapping the Atari if you need to know more.)

Briefly, then, you need simply to turn on the upper bit of GPRIOR in order to activate these new modes. There are, however, some caveats to be observed. Perhaps the easiest way to observe the toughest potential problem is to turn on your Atari, go into BASIC, and do a POKE 623, 128.

What do you see? Garbage on the screen, if you have a GTIA. Unfortunately, activating the GTIA destroys the normal character display mode(s). More on this later.

Now, on to the table. When you tell BASIC to PRINT #6 in Graphics modes 1 and 2, it prints larger than normal characters to the upper portion of the screen. In particular, though, the characters are available in several different colors. Try this little program to see what I mean: GRAPHICS 2 : PRINT #6; "AaAa" (where the underlined characters are typed in inverse video).

And why do you get four different colors? Because the upper three bits of each of the characters are different. In particular, the upper three bits for the four characters shown are 010, O11, 110, and 111, respectively. Because you are in Graphics mode 2, all four characters came out as uppercase letters.

Now, the bytes which are put in screen memory are actually translations of the bytes which you PRINTed. In particular, when the bytes shown are translated to screen codes, they end up with upper bits of 00, 01, 10, and 11, respectively. The upper two bits of the bytes placed in screen memory determine the color to display; the bits in the character set determine which bits will be "turned on" on the screen.

The concept used in our "new" graphics mode is similar. In particular, the upper two bits of the bytes placed in screen memory determine the color MAP to use. The actual bits in the character set determine which color will be selected from the appropriate map. In other words, we have added yet another level of color indirection to the Atari!

In GRAPHICS 10, memory is organized in groups of four bits. The value of the four-bit nybbles determines which color register is displayed. Thus, since there are nine color registers (five for the primary graphics and four for player/missile graphics), there are a maximum of nine independently displayable colors. (Yes, I know that you can get 16 colors in GRAPHICS 9 and 11; but in those cases the colors are not truly independent.)

In GRAPHICS 1 + and 2 + (well, I had to call them something, didn't I?), pairs of bits (instead of four-bit nybbles) determine the color register to use. Remember, though, that the pair of bits can only select a color from the particular MAP which has been selected by the two upper bits of the character on the screen.

And, finally, this implies that the other six bits of the character on the screen select the particular character from the character set memory, just as normal GRAPHICS 1 and 2 do.

Does that sound complicated? It should, because it is. Anyway, now is the time to look at the table. It shows the MAPs that are available.

Color Selection Under GRAPHICS 1 + And 2 +

Bit Pairs Of Color Selectors In Character Memory

Upper Bits of Character on Screen (Map Selector)	00	01	10	11
00	704	704	704	704
01	704	705	712	709
10	704	706	712	712
11	704	707	712	711

And, you presumably ask, what are the numbers shown in the table? Simply the location of the color register which will be displayed when you use the given bits within the given map. For example, 704 is PMCOL0 (player color 0) and 712 is PFCOL5 (playfield color 5). However, the easiest way to change the color registers, in this instance, might be to refer to them via the locations shown in the table.

So, writing POKE 704,0 will make the background color black. Writing POKE 712,152 will give you a nice blue for bit pattern 10 in MAPs 01, 10, and 11. A little observation of the table will show you that MAP 00 is essentially useless: it always gives you the background color, regardless of the bit patterns in the character memory.

On the other hand, bit pattern 00 always gives you background color, regardless of the MAP used, so it may prove useful in many circumstances. For the rest, note that MAP 10 gives you only three colors, but it is the only MAP which gives color 2 (706). Sigh. The system is not totally flexible, but it is handy.

First thing next month we'll put this all together with a little BASIC program that demonstrates the capabilities of the new modes.