kenjennings

Simple Assembly for Atari BASIC A multi-part discussion of a few pet peeves about Atari BASIC and simple machine language utilities to fill in the gaps. July 2016 ============================================================== Part 1 - Introduction http://atariage.com/forums/blog/576/entry-13175-part-1-of-11-simple-assembly-for-atari-basic/ Part 2 - Learn 82.7% of Assembly Language in About Three Pages http://atariage.com/forums/blog/576/entry-13176-part-2-of-11-simple-assembly-for-atari-basic/ Part 3 - The World Inside a USR() Routine http://atariage.com/forums/blog/576/entry-13177-part-3-of-11-simple-assembly-for-atari-basic/ Part 4 - Implement DPEEK() http://atariage.com/forums/blog/576/entry-13178-part-4-of-11-simple-assembly-for-atari-basic/ Part 5 - Implement DPOKE http://atariage.com/forums/blog/576/entry-13180-part-5-of-11-simple-assembly-for-atari-basic/ Part 6 - Various Bit Manipulations http://atariage.com/forums/blog/576/entry-13181-part-6-of-11-simple-assembly-for-atari-basic/ Part 7 - Convert Integer to Hex String http://atariage.com/forums/blog/576/entry-13182-part-7-of-11-simple-assembly-for-atari-basic/ Part 8 - Convert Integer to Bit String http://atariage.com/forums/blog/576/entry-13183-part-8-of-11-simple-assembly-for-atari-basic/ Part 9 - Memory Copy http://atariage.com/forums/blog/576/entry-13184-part-9-of-11-simple-assembly-for-atari-basic/ Part 10 - Binary File I/O Part 1 (XIO is Broken) http://atariage.com/forums/blog/576/entry-13185-part-10-of-11-simple-assembly-for-atari-basic/ Part 11 - Binary File I/O Part 2 (XIO is Broken) http://atariage.com/forums/blog/576/entry-13186-part-11-simple-assembly-for-atari-basic-the-end/ ============================================================== This actually isn't the project I meant to be working on. I ended up here, because of a series of other needs. Originally, I was working on converting some old examples from Compute! not written for the Atari and needed to demonstrate a machine language sort for an Atari BASIC numeric array. This required I understand Atari BASIC variables, and while writing that discussion I realized I needed facilities not included in Atari BASIC (16-bit peek and poke, memory moves, etc.) So, that brought me here to fill in some gaps missing in Atari BASIC. Now that I'm done with this hopefully the Atari BASIC Variable article will be done soon, then I can get back to the machine language sort. it will take a while to get these articles posted, reformatted, etc. Several will be posted today, and others over the next few days. For those who don't care to wait for the multi-part bloggitty-blog version the complete document is attached below in a couple formats: LibreOffice ODT. Remove the .zip after downloading: HelpBASIC.odt.zip PDF version: HelpBASIC.pdf ============================================================== Introduction: The Good… The Atari 8-bit computer was a paradigm-changing platform when introduced in 1979. The extensive, built-in color graphics and sound capabilities started computer-based “multimedia” years before the word existed. Atari would have been justified keeping it a completely closed box of mystery. Fortunately, they did not. Atari provided a BASIC language with reasonable support for the computer’s custom hardware graphics and sound features. Many other computers introduced before and even after the Atari had BASIC languages providing little to no support for graphics or sound. They were little different from the original BASIC (circa 1964) developed in an era of time-sharing terminal printers intended for number and text processing. Atari BASIC incorporates some good ideas. On program entry Atari BASIC converts commands to an abbreviated form called tokens. Using tokens cuts down memory use for program storage, speeds up program execution, and the tokenization process provides immediate syntax error feedback at the time a programmer enters a program statement. Atari BASIC provides exceptionally high readability compared to other BASICs of the day. Atari BASIC nicely inserts spaces between commands and values in program listings. This spacing does not occupy the program's memory thanks to tokenization. Finally, Atari BASIC recognizes long variable names enhancing readability. Some do not like the way strings work in Atari BASIC, but I find they make a lot of sense. When moving on to C years later, I credit the reduced learning curve for C strings to Atari BASIC; the way an Atari string behaves in memory is more like a C array of characters (less the ‘\0’ terminator) than Microsoft BASIC strings. Also, a character pointer in C is a concept similar to the Atari BASIC ADR() function. The Bad… Of course, nothing is perfect. Atari BASIC is missing some useful features for dealing with computer hardware on the computer’s terms. This is not really a critical failure of Atari BASIC, since many other BASICs do even less than Atari BASIC and part of the purpose of original BASIC was to protect the beginner programmer from architectural questions about the computer hardware. But, given the Atari’s additional graphics and sound features part of the fun of programming is making the Atari hardware do interesting things. 8-bit computers frequently have reason to deal with 16-bit, two-byte values. While Atari BASIC has PEEK and POKE working with single-byte values it lacks a way to work directly with two-byte values. The Atari hardware provides many interesting bells and whistles for graphics and sound. (Literally, it can make bell and whistle sound effects.) Effective interaction with hardware registers and the operating system often require manipulating individual bits within a byte. Bit operations are not available in Atari BASIC. Hand-in-hand with 16-bit values and bit operations is working with hexadecimal representation of values. When one becomes familiar with the hardware it begins to make a lot more sense to refer to and display values in their hexadecimal form. Hexadecimal value representation is not included in Atari BASIC. Moving blocks of memory around has many practical uses in the Atari environment – copying character sets, animating characters or Player/Missile graphics, rapid updates of color registers, etc. Atari BASIC does not have a general purpose memory move feature. There is a common hack using Atari BASIC strings to perform a high-speed memory move. However, this method requires more setup, is not obvious to the casual programmer, and so is not as convenient and flexible as a command to move memory. Atari BASIC’s I/O functions are missing the ability to load bulk, binary data into memory from a file, (such as graphics or character sets.) Atari BASIC must use slower loops to read a file, or waste memory by including the data within the BASIC program. And the Ugly (or just darned weird)… The worst weird thing about Atari BASIC does is that it handles all numbers as 6-byte, BCD, floating point. In spite of this it is still comparatively fast, so it makes one wonder how fast Atari BASIC could be if it used 16-bit integers instead of bogging down the 1.79 Mhz CPU with floating point math. Another problem built into Atari BASIC is line lookup for statements. Atari BASIC identifies statements during execution by searching the line numbers from the beginning of the program to the desired statement. This causes statements at the end of a long program to execute slower than statements near the start of the program. Atari BASIC has two different syntax options for GOTO. These are both valid: 100 GOTO 10 200 GO TO 150 What's up with that? It is a joke, right? I do hope the implementation cost less than a dozen bytes. Couldn't this have been replaced with a solution to one of the other problems, such as 16-bit PEEK and POKE? All these issues with floating point use, line searching, and command syntax are fundamental to the internals of Atari BASIC, so solutions to these situations require writing a new version of BASIC. Since I’m not planning on making a career of this, contentment will have to come from resolving the easier problems mentioned earlier. The Solution To fix these problems get a copy of OSS BASIC XL or BASIC XE, or TurboBasic XL. Really. Seriously. These BASICs can load and run all Atari BASIC tokenized programs (that is, SAVE’d programs) and ENTER Atari BASIC LIST’ed programs correctly at least 98% of the time. Both are faster than Atari BASIC and provide many of the useful features discussed here. And with the advent of high quality emulators you don't even need to concern yourself with acquiring the languages on physical ROM cartridges or disks. You can get the whole Atari experience plus modern convenience just by downloading a few digital image files. So, problem solved. Thanks for reading. See you later. The Other Solutions You're still here? The movie is over. Go home. . . . So, trading up to a better BASIC is out of the question? For whatever questionable reason you are actually married to Atari BASIC and can’t switch to anything else? Fine. (Do not send me pictures of your children.) If there were no other options the article would end here. However, the miles of text (in the half dozen subsequent parts) must indicate interesting stuff follows. Most of the issues are less difficult than they appear. In some cases a simple solution can be written using just Atari BASIC. However, given the speed of Atari BASIC the real problem becomes how to do it fast enough to be worthwhile. The best performance comes from machine language code. Even badly written assembly will produce machine code that runs circles around Atari BASIC. Below, the article will demonstrate that it has more than enough badly written assembly code to go around for everyone. This article presents several reusable machine language utility programs expanding BASIC programs’ capabilities, and improving performance. These utilities are designed to be called from BASIC’s USR() function. This article is not entirely a lecture on learning 6502 programming from scratch. But, the solutions are not terribly complicated, so it should not be too difficult for a beginner to follow. Final solutions with the utilities implemented in Atari BASIC test programs will appear for those who don't care about the assembly code. Next time we will learn about Assembly language syntax and instructions in as few pages as possible. For I know the plans I have for you, declares the Lord, plans for welfare and not for evil, to give you a future and a hope. Jeremiah 29:11

You got programs in BASIC XL published? Remarkable. I sent a bunch of games and utilities to Antic, Analog, and Compute! in BASIC XL and never got any of them published. (Compute! was always nice enough to use the S.A.S.E. to return my materials with the rejection letter.)

I recall reading elsewhere that BASIC XL was a big (the biggest?) seller for them. They sold more of those carts than Action.

Took a look at the OSNXL listing. This isn't a program listing per se; it is the output at time of assembly. I see a lot of external symbols not defined in the source, (or otherwise could not find the definitions) , so there's probably an include file or two not shown in the listing. I do see the occasional comment in there. Not aware of any assembler that would attempt to excise comments in the assembly. It looks like the author just wasn't a big fan on in-line documentation and/or it was likely not something expected to be scrutinized in public. Common programmer feature (flaw) -- when you're working with something every day all sorts of decisions appear self-explanatory and documentation seems redundant. And then a year (or twenty) later you look at it and wonder what the heck you were thinking of.

Paddle triggers are actually joystick direction lines. There is only one joystick and so one joystick trigger per port. But, two paddles per port, so something else had to be done to supply two paddle triggers.

The baboon ("Mandrill") was shown in the first reviews of the Amiga in magazines. Digiview came later. I think the picture was included in a demo disk for dealers. I recall it testing the crashability of DeluxePaint on a minimal memory spec 1000 in a store. (Can you believe they sold Amigas at Boston Store?)

I'll add my ditto. Started with Atari 800, added an 800XL later with 256K. Could not afford an Amiga when it came out, could only lust for it from a distance for what seemed like an eternity. Once I got some steady employment (Thank you USAF) I got an A500. I happened to meet a US dealer while I was in stationed in Germany (weird story) and got their very first A3000 delivery shipped to me, so I may have been the first A3000 owner in Europe. Before I even turned it on I upgraded it with 16M of 32-bit RAM. It was an awesome machine. (Still is. I have a 2000, and another 3000). Regret selling the original 800 and the A500. But I eventually got two other 800s to make up for it. I was using that 2000 with a 68040 and 128M RAM for USGS DTED visualization with World Construction Set (government contract project.) In 1996 my neighbor had a garage sale and I saw they had a 1040ST. They sold it and the color monitor to me for $20. Once I used it as a serial terminal. Couldn't find another use for it.

Are you grouping missiles to act like another player? You could use P0 for the top layer, and P1, P5, (P2, P3 ) below. ???

OSS Mac/65 OSS Basic XL DDT MyDos Newell OS/Fastchip/Omnimon That covers about 97.3% of my non-gaming time in the 1980s. The remainder: AtariWriter/PaperClip, and Kermit terminal communications.

Unlike many other platforms of the era, the Atari's executable files have a structure to them. Rather than a simple model of starting at a fixed address and loading data sequentially until the end of the file, the Atari can break the data down into segments specifying the start and end addresses of each segment. This allows the Atari executable file to optimize its contents, loading data into just the parts of memory that it is using. The value $FFFF identifies the start of a segment. The next two bytes are the starting address. Then next two bytes are the ending address. The bytes that follow are the contents of memory from the start address to the end address. Atari tests special memory locations while loading an executable file. One is "init" and the other is "run". When the contents of "init" changes while a file is loading then the Atari calls the address in the "init" location. After the routine called through the "init" location returns, the Atari continues to load more data from the file. When the "run" address changes the Atari calls the routine in the run address AFTER it finishes reading the entire file. Assemblers for the Atari generate a load segment (that is, the $FFFF-Start Address-End Address sequence) when the .org or *= is specified changing the assembly address location.

The Wikipedia page on ANTIC has a pretty good write up on the Display List instructions. https://en.m.wikipedia.org/wiki/ANTIC

Faster CPU, Higher resolution, independent multiple-playfield scrolling, 4096 color palette, half-brite mode, digital samples for audio... Where have I seen that before.... Oh, yes, it's the Amiga. It would be neat to have a modern remake of an 8-bit Atari in an Amiga 1000 pizza box case.

I think it must be the original model of sega controller. I've got several newer ones with more buttons and they don't work more than a few minutes. I'm guessing they require some sort of polling read/write protocol, not just a simple read from the port.

If they planned to have two complimentary models it follows that the computers would be designed and released at the same, or similar times, like the 400/800. Given the timeline it looks like the 600XL (and 800XL) was a reactionary move to the public nose-wrinkling at the 1200XL, not a pre-planned action. It still is entirely possible that the clueless management of Atari thought pre-planning sequential rather than simultaneous development of two computers in an unbelievably fast-changing market was a good idea. This would be more proof they were complete idiots.

It plays perfectly fine in its current state. But, I could have also lived with scrolling. Its not like the Atari is especially bad at scrolling.

XL = eXtra 'Leet

I had thought "baud" was an abbreviation for "bits audible".

Because the world stupidly chose Microsoft products. DOS and Windows are morons that think the file extension identifies the contents of the file. On the Atari .COM or .EXE is a matter of convention. An Atari executable program could be named anything. On DOS/Windows .COM and .EXE mean executable programs. So, to prevent DOS/Windows from being confused by Atari files people have taken to changing the file extension of Atari programs, because the Atari doesn't care.

There's nothing to prevent a DLI routine from acting across multiple scan lines... or even the entire screen. If you have an ANTIC display list running a text or map mode realize that there's DMA supporting that display for the display list, fetching screen memory, and for text modes fetching the character set graphics. All these have bus priority over the race-the-beam 6502 code. Even the blank line instructions take time for ANTIC to fetch for DMA which can throw off the timing where they occur. The point of all the bells and whistles in the Atari 8-bit computers (that is, ANTIC playfields, and the player/missile DMA) is to make the coding easier so a continuous display kernel is not needed to maintain the display.

Remarkably, I have an answer.. . He was pretty nice about the interruption and provided a lot of interesting facts: Not a lot of good news. Looks like the business end of *grass could be largely lost unless someone else who worked on it retained the related media. Perhaps when summer comes around he'll be able to recover something.

The text on the Wikipedia page appears to be taken from Thomas A. DeFanti's page on EVL about GRASS. https://www.evl.uic.edu/entry.php?id=1935 "The last version of GRASS was RT / 1, a port of GRASS to other platforms that seperated the language from the display model and allowed it to be ported to other platforms. Versions existed for DOS, Windows, SGI platform using OpenGL, HP-UX, AIX, Macintosh and Amiga." I sent an email to Tom DeFanti inquiring about the ports. This took a few tries. Invalid email addresses. The last one I sent hasn't bounced so far. We'll see how this goes.

I'm up for two.

I read in a couple places that ZGRASS was ported to PC, Mac, and Amiga as "RT/1". Does anyone have any of these? I haven't been able to find a download for Amiga, and the applicable occurrences of ZGRASS and RT1 on Google are so few that I have little hope of this existing. Is there original source code available for ZGRASS on the astrocade? I haven't found that either. Has anyone considered porting ZGRASS to other platforms, say something comparable in the 8-bit world, like the Atari 8-bits??

https://youtu.be/BORsUKQGd_E?t=44 And then RDEA6's posted and it turns out every evil deed I had attributed to Microsoft is actually true. They changed the version and added a bug. Classic.

Anything reading from a CIO device should safely deal with the fact that fewer bytes were read than requested. But, what should happen if the request is for one (or more) bytes and zero bytes are returned? Should the reader recognize length of zero? (I think so). Or should the device behave like an end of file had occurred? (probably not ideal). We are talking about the dragon network cart, right? So, as a special device never conceived of for the Atari in 1978 I think you have some lattitute for deciding appropriate behavior for the CIO user.