Jump to content

Search the Community

Showing results for tags 'Atari BASIC'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 6 results

  1. Is there any situation where the entry number in the Variable Value (VVTP) table structures would not be sequential from entry to entry? Either values out of order or gaps >+1 between adjacent entries? Been poking around and can't come up with a reasonable circumstance that causes the entries to be disordered. BASIC uses the tokenized variable number to index into the VVTP to get the Variable Value structure. So...it seems that the entries are always created sequentially and gaps should not be possible. Then the entry number in the variable value structure is really just redundant/does not serve a purpose.
  2. I'm going to assert that distribution of the Atari System ROMS is legal and that Atari do not own any copyright on them. I'm looking for peer review of my research here. The ROMS I'm talking about are the AtariOSA, AtariOSB, AtariXL, BASICXL, and 5200 roms. These programs were written and published between 1978 and 1989, that is a period in time when copyright law required there to be a copyright notice on a work for it to be protected. Curt Vendel says that the source listings all have copyright notices on them. That is not acceptable however as the notice must be:- "affixed on publicly distributed copies and phonorecords in such a manner and in a location that provides reasonable notice to the public of the claim to copyright. In all cases, the acceptability of a notice depends upon its being permanently legible to an ordinary user of the work and affixed to the copies in such manner and position that it is not concealed from view upon reasonable examination." --- 2206.1 There is a copyright notice printed onto the rom chips but this is not acceptable either because:- "A concealed notice that is permanently covered so that it cannot be seen without damaging or tearing the work apart is unacceptable. The U.S. Copyright Office considers such works to be published without notice. To be acceptable, a notice must be legible to an ordinary user of the work under normal conditions of use and affixed to the copies in such a manner and position that when affixed it is not concealed from view upon reasonable examination by the Office or the ordinary user." --- 2206.7 There is no copyright notice within the ROM code. There is no copyright notice on the label in the bottom of the Atari machines. I searched the copyright office for Atari copyrights and only found a regestration for the 65XE OS and that was registered in 1990 (TX0002705413 / 1990-01-09). From BitLaw... "Copyright registration is the process by which a formal claim of copyright is filed on a work with the U.S. Copyright Office. Registration is not a condition of copyright protection, although it is a prerequisite for filing a copyright lawsuit on U.S. origin works. However, it is possible to file a lawsuit on a previously unregistered work merely by filing an application for registration immediately prior to initiating the lawsuit. Even though registration is not a requirement for copyright protection, the Copyright Act does provides several inducements or advantages to encourage copyright owners to file for copyright registration. Among these advantages are the following: If registration is made within 3 months after publication of the work, it is possible to collect statutory damages and attorney's fees in infringement actions (otherwise only actual damages may be collected); If made before or within 5 years of publication, registration will establish prima facie evidence in court of the validity of the copyright and of the facts stated in the certificate; Registration establishes a public record of the copyright claim and allows for the recordation of transfers of ownership of the copyright; and Registration allows the copyright to be used to prevent the importation of infringing copies." Aside from this, the ROMS were distributed with PC Xformer, The current copy from emulator, inc. (v3.80) still has the roms in it, The About box says the roms are used with permission from Atari and I found:- "Reprinted From MICHIGAN ATARI MAGAZINE by permission. By John Nagy DAREK MIHOCKA's ATARI 800-in-an-ST-Program WILL BE RELEASED with ATARI's approval! NEIL HARRIS, spokesman for ATARI, has agreed (in a public message on the GEnie ATARI SIG) to allow both USE and DISTRIBUTION of the ATARI code within Darek's emulator. The permission is contingent on Darek's PUBLISHING the SOURCE CODE for his emulator, so that other programmers may be able to add their efforts......." This is mention of ST Xformer, which became PC Xformer. Aside from this, Atari released the ROMS into the public domain in the Translator disk for the XL. I tried emailing the current Atari, Inc. asking them to formally release the roms into the public domain but I've had no reply. I think from the above, they already have and we can all stop dancing around the how or where of obtaining of these ROMS.
  3. Those interested in a little historical primer on Paul Laughton & Kathleen O'Brien should read this synopsis, first, if you haven't already. Below, you will find a very Interesting video interview that goes deeply into areas that are not normally covered in Atari-specific interviews with Paul Laughton. Here you will get the gossip about how Kathleen O'Brien (the other Co-Author of Atari BASIC, & author of Atari Editor Assembler, etc.) physically assaulted Steve Jobs in a very memorable Reality Check. Hahaha, she's probably the only person who ever put him in his place for being impolite & obnoxious while applying his "Reality Distortion Field" conversation technique, ha! Paul Laughton discusses his early career with IBM, and his early work with Shepardson Microsystems, providing a lot of background history on what it took to later bring us Atari BASIC, DOS, and Optimized Systems Software (OSS) products. This includes a lot of coverage of the work that was done for Apple that provided the basis for the later Atari products (this interview is like a prequel to the "ANTIC the Atari 8-bit Podcast" audio interview with Paul Laughton). He discusses how the "Apple Annie" Apple project led to the early basis of the Atari software. His Atari days are 42 minutes into the interview, but watch the whole thing, to put all of the details in perspective. Lots of good stuff on the past, the present, & the future in this interview! Computer History Museum: "Oral History of Paul Laughton" https://www.youtube.com/watch?v=EeEGJg6vXCg
  4. 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
  5. The World Inside a USR() Routine ============================================================== Part 1 http://atariage.com/forums/blog/576/entry-13175-part-1-of-11-simple-assembly-for-atari-basic/ Part 2 http://atariage.com/forums/blog/576/entry-13176-part-2-of-11-simple-assembly-for-atari-basic/ Part 3 http://atariage.com/forums/blog/576/entry-13177-part-3-of-11-simple-assembly-for-atari-basic/ Part 4 http://atariage.com/forums/blog/576/entry-13178-part-4-of-11-simple-assembly-for-atari-basic/ Part 5 http://atariage.com/forums/blog/576/entry-13180-part-5-of-11-simple-assembly-for-atari-basic/ Part 6 http://atariage.com/forums/blog/576/entry-13181-part-6-of-11-simple-assembly-for-atari-basic/ Part 7 http://atariage.com/forums/blog/576/entry-13182-part-7-of-11-simple-assembly-for-atari-basic/ Part 8 http://atariage.com/forums/blog/576/entry-13183-part-8-of-11-simple-assembly-for-atari-basic/ Part 9 http://atariage.com/forums/blog/576/entry-13184-part-9-of-11-simple-assembly-for-atari-basic/ Part 10 http://atariage.com/forums/blog/576/entry-13185-part-10-of-11-simple-assembly-for-atari-basic/ Part 11 http://atariage.com/forums/blog/576/entry-13186-part-11-simple-assembly-for-atari-basic-the-end/ ============================================================== Atari BASIC's USR() function is powerful offering variable arguments and a return value. Many other BASICs' USR() or SYS() functions are relatively primitive taking no parameters and returning no results. This Atari-ism was a big help to me when learning C. The idea of subroutines called as functions with arguments and a return value was already introduced to me by Atari BASIC and USR(). Atari BASIC’s USR() function provides certain environmental conditions to a machine language routine. A machine language routine called via USR() requires good behavior conforming to the environment to insure safe execution and exit. A machine language routine meant to be called by USR() should follow these guidelines for acquiring arguments and returning to BASIC safely: The 6502 A, X, and Y registers do not need to be saved before use. The first byte on the stack provides the number of arguments passed to USR() excluding the first argument which is the starting address of the machine language routine. When there are no arguments this byte for the argument count will still be present on the top of the stack with the value 0. So, every machine language routine must always remove the argument count from the stack before the routine can exit safely. Every argument is present on the stack as two-byte, 16-bit integers. So, directly passing Atari BASIC's six-byte, floating point values is not supported. BASIC converts floating point values into 16-bit integers (truncating the fractional part) before pushing them on the stack. Likewise BASIC strings cannot be passed, but the addresses of strings determined by ADR() can be passed. Atari BASIC pushes the USR() arguments on the stack in order from right to left, so that the machine language routine will pop them off the stack in the same order as specified in the USR() statement. Atari BASIC pushes each argument value on the stack in low byte, high byte order. This is the opposite of how the 6502 pushes an address on the stack. So, the values must be pulled off the stack in reverse – high byte pulled off first, low byte second. The routine must remove all arguments from the stack before it can safely exit. The last item on the stack is the return address. The machine language program simply uses the RTS (Return from Subroutine) instruction to exit. The environment is in Binary Coded Decimal (BCD) mode for decimal math by default. If Add or Subtract instructions will be used on binary values then the routine must clear the decimal mode (CLD instruction). Decimal mode does not have be re-enabled before the routine exits. The machine language routine can return a result to Atari BASIC. The return value is a 16-bit integer stored at locations $D4/$D5 (or 212/213 decimal). In the USR() call X=USR(ADDRESS,...) BASIC converts the value at $D4/$D5 to an Atari floating point value and assigns it to the variable X. If a program needs multiple return values or other kinds of output, then additional arguments to the USR() routine can provide addresses as targets for output and it is up to the machine language routine how to use those addresses to return other values. A good machine language routine should be able to handle some adversity and protect against easy-to-manage, stupid-programmer tricks. For instance, a typo in a BASIC program could result in the program passing too many or too few parameters to USR(). This is an easy mistake to make, because BASIC can only verify the syntax of the USR() statement, not the number of parameters passed. A badly behaved routine would assume a specific number of parameters, and then cause the system to crash by returning with the stack in incorrect condition. Also, if a routine is not expected to return a computed output value to BASIC, then it is good form to use the return value as a flag indicating successful completion or failure of the routine. Next time, this assembly language discussion will include actual assembly language. Many are the plans in the mind of a man, but it is the purpose of the Lord that will stand. Proverbs 19:21
  6. Learn 82.7% of Assembly Language in About Three Pages ============================================================== 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/ ============================================================== (The printed PDF version of this section really is just 3 pages long.) The hardest part of problem solving is overcoming the perception of difficulty. 6502 Assembly language is not difficult. It is only a different way of thinking about programs. In fact, because the 6502 is a simple processor, the world of 6502 Assembly language is simple. The hard part of Assembly programming is breaking a complex problem down in a way that can be solved by the simplicity of Assembly. BASIC presents a program as text and program execution means interpreting each BASIC instruction which takes considerable time. The 6502 world is distinctly different. The text representation of 6502 instructions that humans can read and write is called “Assembly Language”. An “Assembler” is a program to convert the human-readable Assembly Language text into the 6502 “Machine Language” instructions for execution. The final program is only the 6502 machine language instructions without the Assembly Language text. The 6502 works on data one, 8-bit byte at a time. The bytes of data come from memory which the 6502 describes with addresses 16-bits (two bytes) long. A two-byte address identifies one specific byte of memory at a location ranging from 0 to 65,535. This range is also referred to as 64K. The program the 6502 executes and the data it uses reside in the 64K of addressable memory. Additionally, Atari's custom hardware and devices also occupy specific addresses in memory. The 6502 has a 256 byte structure called the stack occupying a specific block of memory. The CPU accesses only the top of the stack. It may add (called pushing) bytes only at the top of the stack and can remove (called pulling) them only from the top of the stack. The 6502 uses the stack to save return addresses when calling subroutines. Programs may use it for temporary information storage. The 6502 has three dedicated registers called, “A” (for Accumulator), “X”, and “Y” that can each contain one byte of data. Most work occurs on data contained in these registers, though some operations can be done directly on memory. The majority of work takes place in the A register. The X and Y registers can't perform the same math and other data manipulations as the A register, but they can hold temporary values and facilitate looping behavior. Data may be exchanged one byte at a time between the A register and the X or Y registers, between the A register and the stack, and between any of the 3 registers and memory. The 6502 machine language program is a sequence of instructions in memory. The instructions direct work such as reading data from memory into a register, writing data from a register into memory, pushing and pulling values to and from the stack, performing addition or subtraction, comparing values, merging data values, manipulating individual bits in a byte, evaluating various kinds of true/false conditions, and changing program flow based on those evaluations. 6502 machine language instructions may be one, two, or three bytes long. In general, longer instructions take more time to execute than shorter instructions, though there are exceptions. At the completion of most instructions the CPU evaluates the results and sets flags identifying conditions for testing by subsequent instructions. The conditions include whether or not the result is zero, whether or not the result is negative, and whether or not a math operation results in a value overflow (or carry). The 6502 has special treatment for the first 256 bytes (aka a “page”) in memory referred to as Page Zero. The 6502 has specific instructions referencing Page Zero addresses that are shorter than other instructions, so Page Zero use can reduce the size of a program and in some cases makes a program faster. Page Zero addresses also facilitate special methods of accessing memory not possible with addresses outside of Page Zero. 6502 assembly language describes each instruction using three-character abbreviations followed by either an explicit byte value or an address. The “#” sign (that is the “pound” or “number” pre-internet, “hashtag” in contemporary terms) precedes explicit values to differentiate them from addresses. Values and memory addresses are expressed as decimal numbers (e.g. 32) or preceded with the dollar sign to express hexadecimal. e.g. the value #$20 equals #32 decimal, and the address $52 equals 82 decimal. Reading a value into a register is called “Loading”, thus the instruction to “Load” a value into the Accumulator is, “LDA”. For the X or Y register replace the “A” with “X” or “Y” resulting in “LDX” or “LDY”. Writing the value from a register into memory is called “Storing”, so the instructions are “STA”, “STX”, and “STY”. There are different methods to determine the target memory location. These methods, called addressing modes, are not equally available to all registers. The X and Y registers usually allow fewer options. Here are a few example instructions, how they acquire values, and how they do (or do not) resemble BASIC: LDA #32, loads the byte value 32 into the Accumulator. In BASIC, A=32 assigns value 32 to variable “A”. LDA 710, loads the byte value held at address 710 (decimal) into the Accumulator. In BASIC, A=PEEK(710) assigns the byte value held at address 710 to variable “A” (and converts it to the Atari's six-byte floating point format). Alternatively, imagining that memory is like a numeric array the BASIC expression A=MEMORY[710] would be conceptually similar. The prior two examples work exactly the same for the X and Y registers: e.g. LDX #32 or LDY 710. LDA $2C0,X, determines the value of $2C0 (hex) plus the value held in the X register, then loads the byte value held in that resulting address into the Accumulator. In BASIC, A=PEEK(704+X) determines the value of 704 plus the value of variable “X” and assigns the byte value held in that resulting address to variable “A”. Or, using the memory model again, this would be similar to A=MEMORY[704+X]. LDA ($D4),Y determines the address held in the Zero Page location $D4 and $D5 plus the value held in the Y register, then loads the byte value held in that resulting address into the Accumulator. Using an address to point to another address is a powerful feature of the 6502 called, “indirection” which is the basis of making reusable code that can operate on any possible memory. Change the contents of the Page Zero value, and the instruction acts on a different location. The closest parallel in BASIC: A=PEEK(V+Y) where the variable “V” defines the base location, and Y is an index added to the location. The instructions INX or INY adds 1 to the X or Y register and DEX or DEY subtracts 1 from the X or Y register. Note there is no address or option. These are one-byte instructions. In BASIC, obviously, this is X=X+1 and X=X-1, etc. In the examples above we saw the X and Y registers add an offset to a target address in different ways. This is a basis for loop control and iterating across a range of bytes held in sequential memory locations. Each of the Load instructions above has a corresponding Store instruction. These store the Accumulator value into a specified address using the same methods of determining the target address seen earlier: STA 710, STA $2C0,X. The BASIC equivalents would use POKE to store in memory: POKE 710,A, POKE 704+X,A. The third form is STA ($D4),Y and imitated in BASIC: POKE V+Y,A where V is a variable containing a base address. There is no STA #32. Storing a constant value in memory requires first loading a register with the byte value and then using a store instruction to place it into a target memory address. CMP #32, Compare the contents of the Accumulator to the byte value 32, setting flags in the CPU for evaluation by subsequent statements. A BASIC example is only vaguely similar: IF A=32 THEN ZFLAG=1. This performs the comparison and sets variable “ZFLAG” in preparation for later examination. However, the 6502 comparison evaluates several different criteria at the same time, not just this one flag. BEQ $9C40 or BNE $9C40. These cause the program execution to jump to (or branch) to the destination address based on the current state of flags set or cleared in the CPU. The CPU evaluates and sets the state of flags by a CMP instruction or any instruction that changes register contents. In this case when the Zero Flag is set due to a previous comparison then the compared values are considered equal, thus the instruction is “Branch when EQual”, BEQ. When this evaluation is true then the program branches to the target address. BNE is the opposite evaluation for when the Zero flag is not set, or “Branch when Not Equal”. The 6502 has branch instructions for each of the flags to “Branch when” the flag is set or “Branch when” the flag is clear. One special note: the branch target address must be within +/-127 bytes of the current program address. The BASIC equivalents that are roughly similar: IF ZFLAG=1 THEN GOTO 1200 or IF ZFLAG=0 THEN GOTO 1200. PLA pulls the top value off the stack and places it in the Accumulator. The stack is a hardware feature inherent to the 6502, so there is no direct parallel in BASIC. For the sake of illustration consider the stack an array and a variable called “SP” (for stack pointer) identifies the top element. A BASIC equivalent would then be: A=STACK[sP]:SP=SP-1. PHA pushes the value in the Accumulator to the top of the stack. Again, this requires an imaginary expression in BASIC: SP=SP+1:STACK[sP]=A TAX and TAY transfer the contents of the Accumulator to the X or Y register respectively. In BASIC, it is conceptually similar to X=A or Y=A. Likewise, TXA and TYA transfer the contents of the X or Y register to the Accumulator which is like A=X or A=Y in BASIC. JMP $9C40 is like GOTO 1200 in BASIC and JSR $9C40 is like GOSUB 1200 in BASIC. These instructions change the program counter to the specified 16-bit address. JSR also pushes the current program counter address on the stack allowing the subroutine to return to this location. RTS is how a subroutine exits and returns to the point where it was called. This instruction updates the program counter with a 16-bit address pulled from the stack. That address is usually pushed on the stack by a prior JSR instruction. This is similar to RETURN in BASIC. The heart of man plans his way, but the Lord establishes his steps. Proverbs 16:9
×
×
  • Create New...