Questions and Answers
The following are answers to some of the mail we have received of late.
Q. PEEK (741)+256*PEEK(742) (from July '81) is not a good way to find the display list. PEEK(560) is. Why didn't you?
A: Knowledge about the Atari is a rapidly unfolding thing. We pass on what we know when we know it. And remember, we write columns about four months before you read them. Since we are experimenting with the Atari all the time, and learning more, sometimes we discover a better way of doing things about which we have already written. No matter; we try to give the best of what we know at the time.
Q: In the DLI article (December 1981) you don't use memory page 6. Why? If you did, you could fix the location of the program and avoid the relocation code.
A: First, we left the page alone so the user could use it along with the DLI routine. Remember, the DLI routine will coexist and coexecute along with many assembly routines as it is an interrupt handler. Hence, it is potentially more useful located outside of page 6.
Second, it gives us a chance to explain all about string handling and the general principles behind regarding a string as just a collection of bytes in memory, useful in other ways besides merely holding characters. These are tutorials, remember, and often the stated goal is far less important than the getting there. The principles behind the demonstration will be far more useful, in many ways, than will be the demonstration.
Q: In the July article you show a mixed mode display, which I can't produce. Could you send me the code for this? (Multiply this by 80 letters or so.)
We omitted the code because I was addressing the principle of stacking display blocks, and the code is somewhat confusing. It tends to raise more questions that it answers, but I have included it here for the curious. See Listing 1.
Basically we are modifying a graphics 8 display list to:
GR.2
GR.2
GR.0
Gr.8 x lots
We are not duplicating the July display exactly, but you can with the principles in the code.
We use two GR.2 lines to make the memory requirements come out to 40 bytes, to keep "in sync" with graphics 8. We then put data into the first 120 bytes of DM for character output.
Character data is translated from ATASCII to INTERNAL format for display; they are not the same. A machine language routine here would be quite nice; there is probably one in the operating system that could be used. The INTERNAL codes are then POKEd into memory.
Because we now generate 16+16+8+189 scan lines, instead of 192, we have a total of 229 generated lines. This will probably cause your TV to "roll." So we chop out the lower 40 graphics 8 instructions by moving the JVB instruction up. I copy the data bytes first, then the JVB byte, to prevent the JVB taking off into random memory.
Or so we thought. (And so we told you.) JVB is the jump and wait for vertical blank; it makes the display list into a GOTO loop, so we said. Except that just by accident we found out that where it jumps to doesn't matter. That's right: the data bytes following the JVB are irrelevant. Why? Because at the start of every screen refresh, the operating system copies the display list location shadows (560, 561) into Antic and re-sets him to the start of the DL. So all is well even if Antic, at the end of the DL, jumps off to kingdom come.
Except: during disk accesses, where apparently the Vblank routine copy is nulled. Then the screen will go wild. (See what I mean about "rapidly changing knowledge"?)
Along these lines, a fun display is to set up two display lists and two display memories, and have Antic execute them alternately. (Use a DLI in the first 112 instruction to swap display memories.) You'll get two displays superimposed on each other. For example, we had a graphics 0 display of Basic code imposed on the graphics 8 display it produces. Nice, and nifty for an editor or such. However, it does tend to flicker.
Q: Speaking of flickers, your DLI routine has an annoying flicker in midscreen--a border between two colors that jumps back and forth. Why?
A: You're right. Next question?
Seriously, the reason for this is that the 6502 just doesn't have enough time to copy all the data into the CTIA color registers before the TV scan line begins. In fact, it can't even start until midway through the last scan line of the display block with the interrupt flagged. The TV refresh process outruns this rather generalized routine. You'll have to learn assembly language to deal with this properly; use WSYNC, then rapidly store up to three colors after the WSYNC using STX, STY, and STA. You'll still be offscreen. For those of you I've lost, the timing of a DLI routine is a very touchy thing; if you don't know machine language and how the Atari relates to the TV, forget it.
This routine will also crash in graphics 8 as it will not complete between interrupts if you have interrupts on two consecutive scan lines. If you want that, learn assembly language, then write your own driver.
On Memory Boards
Q: My Atari dies after being on for a while. Or, my Atari freaks out unexpectedly. Or, my Basic programs scrozzle themselves. Or....
A: 1. If you squeeze the last few bytes of available memory, Basic seems to screw up. Something in the upper memory management routines fails during tight squeezes, and there isn't much you can do about it.
2. The Atari memory boards may be giving you trouble. Here's Small's Memory Board Fix (which works amazingly often on bizarre Atari problems):
The Atari memory boards get hot, really hot, in their enclosed metal cans in the enclosed metal cage. This heat can mess things up, particularly in the connectors. The metal is necessary to avoid spraying radio frequency interference all over, but it does cause problems. So every month or so we pull all the boards out of the Atari and re-seat them. This re-establishes the socket connection. Cleaning the ends of the connector (a pencil eraser works wonders) and coating them with Lubriplate, then re-seating them is also a good idea--helps prevent corrosion.
If this fixes it, fine. If not, go the drastic route (as we had to on one very touchy 800):
1. Remove the lid. Bypass the interlock with a taped in Q-Tip.
2. Remove the memory board lids (pull the two Phillips head screws). Re-install the boards.
This will really help to keep things cool. Of course, you may not be able to watch TV nearby (nor will your neighbors) but it will prevent overheating.
Now that you have the lid open, some of you are doubtless going to get the clever idea of copying ROM cartridges onto disk. After all, you can boot up, then plug them in with DOS running. Then, a simple binary save, right?
Wrong.
Atari has some nasty, nasty surprises awaiting you if you try this. First, plugging the cartridges in sends a nice hefty spike into the memory lines, straight into sensitive Antic, CTIA, and the 6502B. Do you really want your Atari in the repair shop? All it takes to destroy these chips is a little static electricity in the wrong place, and your body is probably full of it in the winter.
Second, the Atari people have some special checks to prevent this. For example, disk I/O doesn't work the way you might expect from cartridges. Ever had your directory mysteriously disappear? This should be food for thought.
On Piracy
Speaking of piracy in general. I have found copies of my software (what goes into these articles) floating around all over the place. This is really embarrassing when the disk that was pirated is a development disk and you've saved all sorts of junk on it.
But second, when you think about it, the prices you pay for software nowadays in many cases are pretty low anyway (when was the last time you could go on a date for $20), so why not give the author his royalties, and get the documentation as well?
I wish that people didn't consider protection schemes a Scott Adams adventure #30 to be broken. If you think about it, the hours you spend breaking the scheme are equal in dollars to what you would pay for the software in many cases. (And if you're thinking about selling copies, don't; all the software companies I've talked to are currently prosecuting people caught doing this.)
Q: I have 32K. Should I get 48K?
A: Maybe. If you use no cartridges, the Atari can use up to 48K RAM. If you use one cartridge, you are reduced to 40K available; if you use two, 32K. Eventually, as more RAM-only programs become available, 48K will be more and more handy. For example, Microsoft Basic, which we are currently testing, requires 48K but has no cartridges (disk based). We're in a transition period, in other words, and it may be to your advantage to wait a bit; hardware prices are dropping quickly, as usual.
On Disks
Q: During a disk access, my disk stops for a while for no reason and then restarts. Why?
A: A bug in the O.S. program. No, the disk isn't stopping to cool off (like an 820 printer) or anything. This is fixed in the new revision cartridges, which are slowly becoming available.
Q: What are DOS 2.5, 2.7, 2.8, 2S, 2.OS, 2.OD?
A: DOS 2.OS is the final, "cast in concrete" version of DOS 2. The others are developmental versions. They are pre-release copies. There are lots of 2S disks lying around; these have a bug in the interrupt subsystem, so best get rid of them. Also, if you boot up under 2S, you can't "DOS" to a 2.0 version of DOS. They're incompatible. So your best bet is to change your disks over to 2.OS and use it.
DOS 2.0D is for the double density 815 drive, which has been cancelled, delayed, sent back, or whatever (depending on who you talk to).
Q: What is a "fast formatted disk?"
A: Inside the 810 disk drive there is a microprocessor. When the Atari wants a given disk sector (128 bytes), it asks that microprocessor for it. The micro then spins the disk and moves the head to get that sector. If you have a disk with a more efficient layout, you can go between sectors (without a complete spin between them, for instance). A "fast formatted disk" has this improved layout, and, thus, when you access it, disk I/O is around 20% faster.
Disks that you format with your 810 will not have this improved layout, because it lays them out the old, slow way. A new ROM, called the "C" ROM, can be installed into your disk drive to make it format disks the fast way.
Who knows when it will be available? The rumor mill says that 1) all disk drives going to Europe have it; 2) all disks to the East Coast have it; 3) all disks shipped after September 1981 will have it, etc. Probably by the time this is printed some policy will have been established.
For those of you who can't wait, the Chicago area user's group has constructed their own version of the format ROM, which requires a few wiring changes to the disk and programming a new EPROM (not your beginner-level stuff). The Chicago ROM is 10% faster than the Atari ROM, which is definitely interesting. The ROMs work quite well; I've seen them tested. However, since the Chicago folks developed them I'll let them document it and take the credit. Incidentally, modifying a drive this way (of course) violates the warranties.
On GTIA
Q: What's the GTIA chip and how do I get one?
A: The CTIA chip actually generates color for your TV. A new chip, GTIA, replaces CTIA and allows graphics modes 9, 10, and 11 out of Basic. (The operating system was written with GTIA in mind, and so was Basic, by the way.) It is an upgrade to the CTIA chip. The rumor mill again says it is available everywhere except where the rumor originates. We have one as the result of extreme kindness on the part of Atari, and are testing it. The added modes are:
Graphics 9: Allows 16 intensities (select by COLOR ) of pixels to be displayed in the background color. Great for grey-scale shading.
Graphics 10: Allows eight different kinds of pixels to be displayed in any of the standard colors. Uses the four P-M registers and four playfield registers to set colors.
Graphics 11: Allows 16 different colors for pixels, all in the same intensity.
The pixel size is four bits long, and one scan line high. This is 80 x 192 resolution, an interesting twist on the general rule that vertical resolution is less than horizontal.
There will be a more complete article on the GTIA chip when it is more widely available. (The problem is, most people at Atari don't have them either, and are trying just as hard to get one. Who do you think will get priority?)
On Languages
Q: Forth?
A: Forth is a dynamite programming language available for the Atari. Its speed is somewhere between Basic and assembly language, but much closer to assembly language. Best of all, it's a reasonably high level language (very stack oriented, as a matter of fact). I'm trying to learn it now.
Versions are available from many sources. Atari lists Forth in their APEX exchange, but will not release it yet. Beware of other versions which may use undocumented entry points in the operating system, and which will quit working when the new cartridges are generally available.
There has been a lot of good software written in Forth. I have a synthesizer program, lent to me by Ed Rotberg of Atari, which plays the best music I ever heard from an Atari (and has different instrument sounds, too; drums, guitar, hand clapping, etc.). The Atari demo with the "Disco Dirge" is written in Forth to give you an idea of its execution speed and flexibility.
Q: Microsoft Basic.
A: You will be hearing a great deal about this from us. We are currently working with Microsoft Basic and it is a fantastic product, indeed. It is much faster than the Atari 8K cartridge Basic and has many, many more functions. It really turns the Atari into a serious business computer, for example. Look at the description of Microsoft Basic in any Apple, TRS-80 or PET book and you will get an idea what is available. Add to that many special Atari functions, and soon you will be writing only in Microsoft.
Listing 1.
10 REM GRAPH PROGRAM 20 REM LAYOUT: 30 REM 40 REM 1 LINE GR.2 20 BYTES 16 50 REM 1 LINE GR.2 40 32 60 REM 1 LINE GR.0 80 40 70 REM 120 LINE GR.8 80+(4800) 160 80 REM 1 LINE GR.0 +40 168 90 REM 1 LINE GR.0 +40 176 100 REM 1 LINE GR.0 +40 184 110 REM 1 LINE GR.0 +40 192 200 REM SET MODE 210 GRAPHICS 8+16:REM FAKE LAST FOUR 220 REM DISPLAY LIST 230 ST=PEEK(560)+256*PEEK(561) 240 REM ST+0,ST+1,ST+2=112..LEAVE BE 242 REM ST+3=79. CHANGE TO 7+64. 243 POKE ST+3,7+64 245 REM ST+4,+5=DATA. LEAVE BE. 246 REM ST+6,ST+7=15. MOD TO 7,2. 247 REM (MODE 2, THEN MODE 0). 248 POKE ST+6,7 249 POKE ST+7,2 250 REM DM + 0 - DM + 29 = MODE 2 L1 255 GOSUB 1000 260 DIM A$(60) 261 SETCOLOR 4,8,2 270 A$=" MODE 2 BIG TITLE " 280 REM 12345678901234567890 290 REM TRANSLATE A$ TO INTERNAL CSET 300 GOSUB 500 333 REM FIND DISPLAY MEMORY 340 DM=PEEK(ST+4)+256*PEEK(ST+5) 410 REM POKE INTO MEMORY 420 FOR T=1 TO 20 430 POKE DM+(T-1),ASC(A$(T,T)) 440 NEXT T 450 A$=" MODE 2 SECOND LINE " 460 REM 12345678901234567890 470 REM TRANSLATE A$ TO INTERNAL CSET 480 GOSUB 500 485 REM POKE INTO MEMORY 490 FOR T=1 TO 20 493 POKE DM+20+(T-1),ASC(A$(T,T)) 496 NEXT T 497 GOTO 600 500 REM SUBROUTINE TO XLATE ASC TO 510 REM INTERNAL CSET 520 FOR Z=1 TO LEN(A$) 530 IF A$(Z,Z)=" " THEN A$(Z,Z)=CHR$(0) 540 IF ASC(A$(Z,Z))<>0 THEN A$(Z,Z)=CHR$(ASC(A$(Z,Z))-32) 550 NEXT Z 560 RETURN 600 REM DO MODE 0 LINE NEXT. 40 BYTES 610 A$=" A TEXT MODE 0 SUBTITLE" 620 REM XLATE 630 GOSUB 500 640 REM POKE INTO MEMORY 650 FOR T=1 TO LEN(A$) 660 POKE DM+40+(T-1),ASC(A$(T,T)) 670 NEXT T 675 REM PLOT A SAMPLE GRAPH 676 SETCOLOR 2,8,0 680 XMIN=2 690 YMIN=5 700 XMAX=319 710 YMAX=159 720 COLOR 1 725 PLOT 1,70:DRAWTO 319,70:PLOT 1,70 726 XSAV=1:YSAV=70 730 FOR X=5 TO 315 STEP 5 740 Y=INT(RND(0)*70)+40 750 DRAWTO X,Y 752 PLOT XSAV+1,YSAV:DRAWTO X+1,Y 753 PLOT XSAV+2,YSAV:DRAWTO X+2,Y 755 XSAV=X:YSAV=Y 760 NEXT X 770 REM PUT IN 4 TEXT LINES AT BASE/ 780 REM AFTER 160 (GR.8) INSTRUCTIONS 790 GOTO 790 1000 FOR Y=ST+150 TO ST+210 1010 IF PEEK(Y)=65 THEN 1100 1020 NEXT Y 1030 PRINT "PLATO OFF." 1040 STOP 1100 B1=PEEK(Y+1) 1110 B2=PEEK(Y+2) 1120 POKE ST+162,B2 1130 POKE ST+161,B1 1140 POKE ST+160,65 1150 RETURN
Table of Contents
Previous Section: Atari Resources
Next Section: Atari Languages
