INSIGHT: Atari
Bill Wilkinson
I have almost worked my way through my backlog of letters, so I will once again appeal to all of you to keep those cards and letters coming. Since it can sometimes take quite a while for a letter sent to COMPUTE!’s editorial offices to wend its way to me, I have decided to give you an address where you can write me directly:
Bill Wilkinson
c/o OSS
P.O. Box 710352
San Jose, CA 95171-0352
Before I start answering questions this month, I would like to talk a little about the future of Atari.
Right From The Source
I had the rare privilege to attend the meeting of the San Leandro (California) Atari User Group on the evening that Leonard Tramiel agreed to come and answer questions.
I hope the name Tramiel is familiar to all Atari owners by now. Jack Tramiel, the founder and former leader of Commodore, bought Atari from Warner Communications in July. Leonard, Jack's son, is now head of software at Atari. And though I am sure some favoritism was involved in choosing him for the position, I think it was probably an excellent appointment.
Leonard Tramiel is an articulate, humorous, open, and opinionated person. He endeared himself to me when he espoused one of my favorite opinions: The IBM PC is an eight-bit machine, and the Apple Macintosh is a 16-bit machine, and no amount of marketing ballyhoo is going to change that. (We are referring to the fact that the width of the data path to the Central Processing Unit (CPU) controls processing speed as much as, if not more than, the speed of register operations. Whew! Got that? There will be a quiz on Monday.)
Anyway, while Leonard was extremely careful to avoid divulging any technical details about future Atari computers, he went a long way toward reassuring many listeners (for example, me) that Atari in general (and Leonard Tramiel in particular) knows what it is doing and where it is going. By the time you read this, the Winter Consumer Electronics Show (CES) in Las Vegas will be underway. And we're expecting to see the introduction of 16-bit and 32-bit Atari computers.
However, I also came away with the feeling that Atari will not abandon the eight-bit, 6502-based market for some time to come. In particular, Leonard stated emphatically several times that the 800XL would undergo only those modifications which would make it "both less expensive and more reliable."
Preserving Atari Loyalty
Possibly Leonard missed his calling: As a public relations person he did an outstanding job. I didn't take a formal poll, but I believe the impression he left on the audience was in the range of 90 to 95 percent positive. If there were any real negatives, it was regarding his stand that he wouldn't guarantee that current Atari peripherals would work on the new machines.
The attitude of some in the audience was, "Well, if I can't use my peripherals on the new machines, I am going to look at all computers instead of just Atari's." That's a reasonable attitude, but the response was just as rational: "If Atari can't convince you to buy the new machines on their merits and prices alone, then we don't know what we are doing." And finally, my view is that—with the possible exception of printers—there are very, very few Atari peripherals that I would want on a new, super-duper computer. (Who wants to talk to a disk drive at 19200 baud? Who really likes the kludge that became the 850?)
In summary, then, I have a better feeling about the future of Atari than I have had in a year or more now: to the point that our company, OSS, is continuing with plans for more and new Atari-compatible products. I will withhold judgment of the new machines until I see their software (Please give us an operating system! Not CP/M, MS-DOS, or Apple or Commodore style!), but with Leonard Tramiel's leadership I have some hopes in that direction, also.
Where It's At
I've received a few letters in recent weeks asking if there is a good list of important memory locations for Atari computers. Oh, come now, COMPUTE!. Can it be that you are not advertising your 1983 book Mapping the Atari? To my knowledge, this is the one and only complete memory map of Atari computers. Further, it is much more than a memory map. It gives example programs, discusses which system routines will use and/or change certain locations, and much, much more. And yet there are readers of this magazine who are not aware of this book! How can that be?
Well, to be fair, the cover of Mapping the Atari does state that it is intended for owners of Atari 400 and 800 models. However, the people who wrote me own either 1200XLs or 800XLs. Does that matter? Not really.
More than 99 percent of the significant memory locations are the same in all Atari computers: 400, 800, 1200XL, 600XL, 800XL. Notice that I did qualify that just a little. Just what is a significant memory location?
Sidetrack: If you have been reading this column for any time at all, you know that I feel that the compatibility problems which many software vendors suffered when the XL machines appeared are the fault of the vendors. Since the first documentation from Atari appeared in the marketplace, Atari made a point of specifying which memory locations would control what functions, which subroutine entry points (mainly vectors) would remain unchanged, and which parts of the operating system (OS) were subject to change. Surely, when Atari released its first revision of the OS in early 1982, you would think the vendors and authors would have been put on notice: "Hey, guys, things are subject to change, and this proves it." The reply: "Yeah, but if I know that this routine at $D099 will save me two bytes of code, I'm gonna use it."
The only consolation I seem to get is that every other machine seems to have the same kind of problem: Apple programmers had to go back to the drawing board when the He and lie arrived. Many major programs for the IBM PC simply do not run on the PC-AT. Nobody can write machine language software for Commodore computers and expect it to work on more than a single model. The list goes on.
Mapping XL Memory
Back to the memory map: Generally, if you use Mapping the Atari with an XL machine, you can trust most of the RAM locations that are listed. Atari did publish a set of locations that were changed in the XL machines, but there were not many. Even the ones that did change were ones unlikely to be used: OLDROW and OLDCOL moved, but the only routines that use them are FILL and DRAWTO. And even if you were to call for a FILL, you probably would do so after a PLOT, which automatically sets up OLDROW and OLDCOL for you.
The ROM locations listed in the book are a bit more subject to change. As a rule of thumb, I would trust only the information about the last few bytes of a cartridge, the floating point ROMs, and $E400 through $E462. Also, it's a pretty sure bet that if the book mentions a difference between OS revision A and revision B when discussing a location, there will be yet another difference in the XL machines. (Example: Anybody who thinks that EOUTCH—output a character to the screen—is at an immutable location should refrain from using a machine manufactured after 1916.)
So all you XL machine owners should rush out and buy a copy of Mapping the Atari. And then you should write to COMPUTE! and tell them (don't ask) to publish an update, either in the form of a revised book or a low-cost appendix, for XL computers.
More No-Nos
As long as we are on the subject of only using legal memory locations (see how I sneaked that in?), let me respond to a couple of people who have asked a relevant question: "I have an 800XL, and I can't get it to put characters to the screen if I follow the instructions in Machine Language for Beginners. How can I change the program so it will work?"
When Richard Mansfield wrote that book, he was writing for Commodore, Apple, and Atari owners. And all the machines he was writing for except Atari have a documented entry point for a routine which will put a single character on the screen. So, for uniformity, he used an undocumented subroutine call on the Atari computers which does much the same thing. At the time he did this, that particular location had been written up several times in both the professional and amateur press, so he felt fairly safe. Ah, well, Richard, even the best of us have to be bitten once in a while.
The proper way to do any input/output (I/O) on an Atari computer is via Central Input/Output (CIO) calls. In early 1982, I wrote a series of articles on CIO calls which appeared in this column. I am not going to repeat that series, but I will give you a few pointers to get you started with CIO.
There are two things you can do if you want more info on the subject: (1) Find a library (perhaps a user group library) with back isues of COMPUTE! (don't write the magazine; they don't have any). (2) Get your hands on a copy of the Atari Technical Reference Manual (it used to be $30 from Atari customer service, but I don't know where you can get it now). The manual includes a pretty fair description of CIO along with lots and lots of other very worthwhile goodies.
The Legal Solution
Without further ado, then, let's look at how to put a character on the screen.
0200 IOCB0 = $0340 0210 IOCBCMD = $0342 0220 IOCBLEN = $0348 0230 CMDPUT = $0B 0240 CIO = $E456 0250 ; 0260 ;Enter with character in A register 0270 ;Routine will print it to screen 0280 ; 0290 PUTSCREEN 0295 LDX #CMDPUT 0300 STX IOCBCMD ; request output 0310 LDX *0 ; multipurpose zero 0320 STX IOCBLEN ; first, zero length 0330 STX IOCBLEN + 1 ; (both bytes) 0340 JMP CIO ; and now X is channel for CIO
That's it. Simply put those six lines of code anywhere in your machine language program. Then, when you want to print a character on the screen, use JSR PUTSCREEN after placing the character in the A register.
In theory, you can get an error when you call CIO (a minus value in the Y register indicates this), but in practice I don't believe you will ever see one as a result of putting a character to the screen.
How, you may ask, is this any better than calling a point in the OS ROM which does the same thing? Answers: (1) This way works on all Atari computers (well … the 6502-based ones, at least). (2) This follows Atari's rules. If you do it this way, Atari could scramble the OS ROMs anyway they wanted, but your program would still run.
Of course, the equates at the beginning of the program fragment are the keys to the whole thing. IOCB stands for Input/Output Control Block. Technically, you are supposed to put the channel number times 16 in the X register and then access the appropriate IOCB via X (see below). Since the screen is always open on channel zero, I took a legitimate shortcut. Similarly, CIO is actually a vector in the OS ROMs which is guaranteed to stay in place. If you follow the rule about using the X register to access the IOCBs, you are already set up for CIO, which requires the channel number times 16 in the X register.
Oh, yes. Normally, CIO expects to transfer an entire buffer (for example, a line of text), in which case you must give CIO the buffer address and its length. But CIO cleverly provides for situations in which you want to print only a single character: Tell CIO that the length pf the buffer is zero, and it will output a single character (or input a character, but that's a topic for another time) via the A register.
And that's about it. Simple, really. Before we quit for this month, though, I would like to show you how simply that routine could be converted to output a character to any channel.
0200 IOCB0 = $0340 0210 IOCBCMD = $0342 0220 IOCBLEN = $0348 0230 CMDPUT = $0B 0240 CIO = $E456 0250 ; 0260 ;Enter PUTC with the character 0270 ; in the A register and the 0275 ; channel number times 16 in the 0280 ; X register. 0285 ; 0290 PUTC 0300 PHA ; save character for a moment 0310 LDA #CMDPUT ; request output… 0320 STD IOCBCMD, X ; … on this channel 0330 LDA #0 0340 STX IOCBLEN ; now, zero length 0350 STX IOCBlen + 1 ; (both bytes) 0360 PLA ; recover the character 0370 JMP CIO ; and now X is channel for CIO
Do you see the really minimal changes we made? This is one of the beauties of the Atari OS. It is so completely organized (orthogonal is a good computerese word for it) that it's actually easy to learn and use. Perhaps we'll do a little more of this if you would like. Write and tell me.