Jump to content

Search the Community

Showing results for tags 'Atari 8-bit'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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
  • GIMP Users's Discussion


There are no results to display.

There are no results to display.


  • 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


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 107 results

  1. Looks like a little over 18 hours are left on this eBay auction listed by seller "nintendolover." Looks like a part of that huge video game collection that the same guy was looking to sell complete but didn't have any takers at his astronomical price, so he appears to be splitting it up by system. It's currently at $510 and counting. Any ideas on what the winning bid will wind up being? Too rich for my blood and I have the system and a complete collection already, so I thought I'd point it out in case anyone was interested. Not mine, as my eBay ID is the same as my username here. Cheers. https://ebay.to/2WfWHG2
  2. Here I've got the Atari Corp. variation (1987 Copyright) of Defender for Atari 8-bit computers. It was sold to me as "new" but the top of the seal had a cut in it so I took out the contents to show you all. Don't think there are too many of the Atari Corp. small box version laying around. $30 OBO with free shipping. Please see the provided pics for exact condition and shoot me a PM if interested in discussing further. Thanks!
  3. I offer 30% discount on all remaining Atari 8-bit and C64 software. Just check the latest lists with the regular prices and deduct the 30% discount. ITEMS As some of you may know I've closed my online shop*. Now I'm selling off my stock. I start with the Atari 8-bit software (200+ items, a mix of US and Euro releases, just check the lists) and C64 items (250+ items, a mix of US and Euro releases, just check the lists). The pdf files contain detailed deskription and a picture of each item. The prices stated in the lists were the old shop retail price and of course, I am absolutly open for offers NEWS I've already received quite a few offers for selected games, but I would really like to sell the items in bulks with huge discounts, so please be patience if you've sent an offer for single or few games. SHIPPING I am located in Germany. Shipping USA/Canada: 5kg - 37.99 EUR; 10kg - 54.99 EUR; 20kg - 76.99 EUR Shipping EU: 5kg - 17,99 EURO; 10kg - 22,99; 20kg - 33,99; 31,5kg - 44,99 EUR If you have any questions just drop me a line. Thanls for reading, Marc. * The box business isn't effected by the closing of the shop. Shop_Atari_8bit_Software.pdf Shop_C64t_Software.pdf
  4. M.U.L.E. disk dump working in emulation. Cover has seen much better days. Includes folio, disk, & quick reference card. I cannot smell anything, but may have been stored in parents home for a time, and they were heavy smokers. So, please expect smoke smell (though hopefully there isn't any.) Also, I have a cat, so cat dander is to be expected. Asking $25 + shipping & PayPal fees.SOLD
  5. Family Fun Party Quiz game by Suncom for Atari 8-bit & Commodore 64. Appears to be complete, though box has definitely seen much better days. Much of my vintage items were stored for years in my parents home & they were very heavy smokers. I cannot smell anything, but be warned that there may be a smoke smell. Also, I have a cat so dander is also to be expected. Asking $25 + shipping & PayPal fees.
  6. I am looking for the Miner 2049er map/poster that came with the Atari 800 game. It may also have come with the Atari 5200 and Commodore 64 versions of the game, but I'm not sure. I used to have this poster, which came with my personal copy of Miner 2049er, but I guess its considered pretty rare now. I sold my game with its poster in the early-to-mid 2000s. I found some pictures (not scans) of the Miner 2049er poster that I'm talking about on the miner2049er.net website. Here is a thumbnail and link to the full, but low-res, poster: http://www.miner2049er.net/wp-content/gallery/bbsba8/img_6816.jpg Here is a thumbnail and link to a close-up of the poster: http://www.miner2049er.net/wp-content/gallery/bbsba8/img_6817.jpg The artwork for the Miner 2049er poster is fantastic. I have looked for a hi-res scan of it that I could get printed as a poster for my office wall. Does anyone know if there is a high-res scan (300dpi or better) scan that I could print at about 20 inches tall? Adam
  7. I'm selling new 6-foot joystick extension cables for use with anything that uses DB9 connected joysticks / controllers, including Atari 2600, 7800, 8-bit computers, Colecovision, Genesis, Commodore VIC and 64, Atari ST, etc. $6.50 each ($12 / pair) + shipping. PayPal accepted for payment. PM with shipping address if interested and I'll send you a total. Thanks!
  8. I was just checking out the 2600 version of Super Cobra. I am amazed with how the 2600 can be pushed beyond previous limitation, with the use of the DSP chip. I am not knowledgeable enough in HOW the DSP works, but it appears that ONE thing the DSP does is manages the placement (reuse-ability) of the 2 Players. Is this possible, because the VCS is so simple? What I mean is, would Antic and GTIA get in the way of any possibility of on-board enhancement chips for the A8/5200? Given the sloppy introduction of the 5200, the controller reliability issues, and the inexcusable, original, pack-in game, the 5200 never got to a point to require add-on chips. From what I understand, the 5200 was just starting to overtake the ColecoVision when they pulled the plug. Sad that it had its life cut short. Could an add-on chip handle calculations, to allow even more on-screen 5200 Players, like the 2600. I realize this can be done in code, since the 5200 has more memory than the VCS, but would an add-on chip offload the burden? Are there limitations to the 5200 cartridge slot/rear bus, which would make this an obstacle? Even a "SGM" type add-on would have been cool. My gut tells me that it may only work on the VCS, because programmers are already "racing the beam." Just curious. I wish the 5200 would get some love with a Harmony-like upgrade.
  9. Hi, I have recent purchased a 800XL (PAL) and paired it with a SIO2SD external drive, all appears to work fine, expect on a lot of games I'm getting a corrupted sprite, and I'm not sure why, would anyone be able to shed light on what may be causing this? Configuration, software, PAL/NTSC issue, RAM or Antic failure? Note that some games appear to run perfectly. Also passes memory tests fine. I apologize for the poor photos, but you can see the corrupted missile or sprite running vertically down the display, these will follow the player or enemies. Any help would be appreciated.
  10. Been a while since I attempted this, and perhaps I'm getting Atari 8 and 16 bit machines a bit confused, but I remember writing a utility back in the day that moved the screen around memory. One interesting thing was that if the pointer to screen memory was placed just before or just after the start of actual screen memory, there would be a neat artifact like 1-dimensional video feeback, where one line would get duplicated, then that would get duplicated, etc. It looked like a faux 3d perspective effect where the "closer" objects would be taller. I found From Compute's Second Book of Atari Graphics, Program two, here: http://www.atariarchives.org/c2bag/page185.php to move screen memory around, but it's not behaving how I'd like. I have a feeling it's limited to a specific region of memory. I started with it, modified to use graphics 9. It does move the screen through memory using the arrow keys, but does not exhibit the powers-of-two one-dimensional video feedback I remember. Perhaps it's not crossing the screen boundaries in the way I remember? Modified listing using basic mode 9: 5 GRAPHICS 9 10 REM COARSE VERTICAL SCROLLING DEMO 15 REM PRESS UP/DOWN ARROWS TO MOVE DISPLAY THRU MEMORY 20 DLIST=PEEK(560)+PEEK(561)*256:REM GET START OF DISPLAY LIST 30 LMSL=DLIST+4:REM POINTER TO DISPLAY MEMORY 40 LMSH=DLIST+5 50 DISPLAYL=0:REM INITIALIZE ADDRESS OF DISPLAY MEMORY 55 REM READ KEYBOARD 60 IF PEEK(764)=255 THEN GOTO 60:REM WAIT FOR KEY 70 IF PEEK(764)=14 THEN POKE 764,255:GOTO 110:REM UP ARROW / 80 IF PEEK(764)=15 THEN POKE 764,255:GOTO 140:REM DOWN ARROW ? 90 GOTO 60 100 REM MOVE DISPLAY WINDOW INTO LOWER MEMORY 110 DISPLAYL=DISPLAYL-40 120 IF DISPLAYL>=0 THEN GOTO 170:REM CAN'T DISPLAY NEGATIVE MEMORY 122 DISPLAYH=DISPLAYH-1:DISPLAYL=0 124 IF DISPLAYH<0 THEN DISPLAYH=0 126 GOTO 170 130 REM MOVE DISPLAY WINDOW INTO HIGHER MEMORY 140 DISPLAYL=DISPLAYL+40 150 IF DISPLAYL>240 THEN DISPLAYH=DISPLAYH+1:DISPLAYL=0 160 REM CHANGE DISPLAY MEMORY POINTER 170 POKE LMSL,DISPLAYL:REM PUT NEW DIPLAY ADDR IN DISPLAY LIST 180 POKE LMSH,DISPLAYH 200 GOTO 60:REM GO WAIT FOR KEYBOARD ENTRY The eventual goal is to have a split screen using display lists, having a static mode 11 top—rainbow sky—and a "scrolling" (by changing memory that then propagates down the feedback loop) bottom section in mode 9—ground. The features on the ground should ideally be bits from memory (to simplify my landscape drawing code P189L2.bas.txt
  11. From the album: Hardware

    Not mine. This is Dan Kramer's legendary custom 3-Fire Button Trak-Ball Controller built in Atari Inc's Consumer Engineering Division. This was used for playing the in-house "3-Base Missile Command" game for Atari 8-bit computers. Dan and others built several custom Trak-Balls there that weren't meant for the public. This one was unveiled at the 2015 Davis Atari Party.
  12. I've been hinting that this was in the works for a while now. And I figure its time to start revealing a bit of what I have been working on for the last 1-1/2 years. I call it the 1088XEL. Why? Well for one thing thanks to Lotharek's U1MB board and the on-board 64K RAM, there is a total of 1088K of usable memory. Basically the idea behind this project is to create something that is designed from the ground up to accept some of the most popular upgrades as plug-in daughter boards. Yes no more making up wire harnesses, crimping terminals, scratching your head and trying to figure out where to mount things. The other goal of the project is create a very small footprint mother board. I'm talking about something in the area of 6" x 6" (15x15 centimeters). And to utilize only thru-hole components, as well as the original five A8 LSI chips (Sally, Antic, GTIA, Pokey, PIA). Actually there will be an additional Pokey on board to support Stereo Sound. If you've been following some of my other projects, then you've witnessed the nesting technique I wish to exploit when laying out this board, which is how I will get it shrunk down to such a small size without resorting to surface mount devices. The first prototype will initially be created as an NTSC version board, but will provide support for an upgrade path to PAL via a future daughter board design, an oscillator change, and of course PAL Antic and GTIA chips. I have taken some liberties at reducing the component count by eliminating capacitors, some support chips (through utilization of SRAM memory), and just not caring too much about RFI radiation issues. Me bad So for all intents and purposes this will still be a 'real' Atari 8-bit computer as far as the basic hardware is concerned (not an FPGA implementation). Now for the big reveal (please keep in mind that these are preliminary schematics, and that the design is still in flux, so in other words there might be a few mistakes and omissions )... - Michael
  13. Update: Final version can be found here. I have always been a big fan of Mario Bros. Mario Bros XE is the BEST home conversion, out of the box! Not only does this version include the icicles, but it also includes most of the animations and cut scenes. This is my effort, with the help of Playsoft, to make the graphics more arcade-like. Please keep in mind, there are hardware limitations limitations: All enemies and background characters share to 4 colors and 1 background. eg: If the pipes were green, the ice would later be green. If the turtles shells were green, text would be dark, and other items combinations would be messed up. A RED Mario would result in a white face. The flesh tone is not selected. it is a result of overlapping the two player colors. I chose a darker brown. It is closer to red than the old pink color, and allows for a more natural blue. I am limited to the original enemy character widths. The shellcreepers do not jump out next to their shells, because the software sprites are not wide enough. I think the original animation is pretty good. I only tweaked slightly to match the more arcade-like graphics. Mario Bros Intro Level 10 Mario Bros IceAge (The icicle levels)
  14. 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
  15. 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
  16. 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
  17. I've been working with DLI's on the Atari 8-bit/5200 - a fascinating and powerful technology for doing really cool things with the display! I have decided to add them to the next release of Virtual World BASIC for the 2600! Here's a BASIC Display List Interrupt Demo for the Atari 2600, the program listing and the DLI chapter from the manual to discuss. DLI_Demo4.bin Display_List_Interrupt_demo4.txt The BASIC DLI demo is only 20 lines of code, easy to review (I reused code from 9LineBlitz). Note: This DLI code won't compile until the next version of vwB is released (soon, along with other enhancements). Draft of the new chapter on DLI's: Display List Interrupts ------------------------------- Display list interrupts run during the vertical blank and provide the ability to split the screen up into multiple horizontal sections, each of which can contain a vertically, horizontally or diagonally scrolling playfield with free floating or tile-mapped sprites. The DLI demo program (DLI_Demo.txt) demonstrates setting up display lists to scroll the top half of the screen vertically while scrolling the bottom half of the screen horizontally at different speeds. The demo actually uses 4 DLI calls to do this but arranges them to create two contiguous scroll zones. Syntax for calling the DLI is simple: "gosub DLI" two rows (1/5) of the screen will be updated based on the value you store in scrollvirtualworldtoggle (it's reused for DLI's; just don't use zero). Put in an 8, and the bottom two rows of the screen will be updated: 100 scrollvirtualworldtoggle=8:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 9 and 10. Put in a 1 and rows 2 and 3 will be updated near the top of the screen: 100 scrollvirtualworldtoggle=1:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 2 and 3. Trick to span three rows (about 1/3 of the screen) - use "3" as a prefix before the start row. Put in a 37 and the bottom three rows of the screen will be updated: 100 scrollvirtualworldtoggle=37:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 8,9 and 10. Put in a 30 and the top 3 rows will be updated. 100 scrollvirtualworldtoggle=30:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 1,2 and 3. It's no more complex than setting the x,y coordinates for the playfield camera to pan the view about the virtual world, you're just able to do that independantly for each section of the screen you define with a DLI! You can call a DLI from each gameloop with different camerea settings; each game loop runs on one of the vertical blanks so one of your DLI calls will happen "before" (called from the top blank) the display is drawn and one will happen after the display is drawn, the one called from the bottom blank (gameloop2). DLI Overhead: 3 row DLI's will occuply nearly the entire top blank, and cannot fit in the bottom blank while 2 row DLI's leave plenty of space for your own program code. Just like raising an event to scroll the entire screen, A DLI need be called only as frequently as you need to update it's target section of the screen (pan the camera). Exercises for setting up multiple DLI's and setting their animation rates: 1. Increase the scrolling speed of the top half of the screen to match the bottom, so they are both animated at 30 FPS (every other frame). 2. Change the demo to show three visible scroll zones; try to set up two zones scrolling horizontally in opposite directions or at different speeds, while the third "larger" zone (comprised of two zones) scrolls vertically or diagonally.
  18. UPDATE: The final version can be found here! Donkey Kong was one of my childhood favorite games. I have always loved the attention to detail in the Atari Computer port. The gameplay is smooth, and it include more game nuances than other conversions of the time. I always thought that Mario and Donkey Kong could have looked a little better. I actually thought Pauline looked BETTER than the arcade. (I did make her more arcade-like in this hack, because I am going for arcade closeness.) After I dug into the game, I found even more appreciation for the A8 version. The memory-saving techniques that Landon used were great. His software sprite routine is terrific. These techniques allowed him to fit SO MUCH into 16K. They did come with a price. Donkey Kong is a mirror image, which means that there are some sacrifices that need to be made. In order to keep Kong's eyes only 1-pixel apart, his mouth is a little off-center in one of the chest-beating frames. Drawing the software sprites on screen seems to mean one less color than a "tile/character" mode. That means no white teeth or eyes for Kong. However, the smoothness at which the software sprites move make it totally worth it. So, in the end, I am trying to make some tweaks, using the advantage of modern day tools. Mario will be the toughest. Mario's made up of 3 player/sprites: red, flesh, and blue. The blue player seems to always be 1-pixel behind the other two. I would really prefer to get rid of that, because it is going to create issues for some of the frames. At this point, I have tweaked most of the playfield objects (Kong, Pauline, Girders, Oil Can, Still Hammers, Fireballs, Pies, etc.). The only player (sprite) I have touched is Mario, and I have only replace ONE of his frames at this point. Pauline's items are also a player. I am sure, as with JR, this will evolve. Original Update Updated Screens:
  19. Okay so, I have still after months had NO luck finding a single image of the cover of this game for Atari 8 Bit computers. Copter Chase specifically. The other seemingly non-existant one is Hazard, an Atari 400/800 8 bit cassette from the company "Artworx" both of which are CIB, Copter Chase is in fact Sealed. Does anyone else have ANY INFORMATION on rarity or value at all? So the two are Hazard - Atari 8 bit Cassette Tape by "Artworx" (CIB/NIB) and Copter Chase - Atari 8 Bit Disk Sealed
  20. Atarimax - SIO2PC-USB - single SIO version >> £20 - SOLD AtariBuff SIO2BT - bluetooth SIO adaptor >> £15 SOLD elsewhere SIO2PC - this is the kit version >> £10 SOLD elsewhere Atari 800XE - v.nice condition, working (no leads) >> £65 no longer for sale Atari 7800 - French RCA video version - 2 controllers, video lead and mains lead (needs UK adaptor) >> £40 - SOLD AtariBuff C2600 Television Computer System - (2600 clone - 250 games built-in, needs UK PSU) >> £30 no longer for sale Notes: prefer post to UK only. Will post to EU/USA, but buyer please estimate your shipping before declaring interest item sizes 1-3 (15x10x3cm, 200g); 4-6 (45x30x12cm, 2kg) all shipping will be insured post with tracking - and is NOT included in above prices paypal gift only - or buyer pays fee items advertised elsewhere - so first come, first served open to sensible offers/deals on combined purchases
  21. Updated to reflect status of one unreliable Indus drive after testing it out. Also dug out the Jaguar unit and noticed that switchbox was nowhere to be found, so removed CIB from the description. I've decided to unload my Atari video game and 8-bit computer collection. I'll try to get a full list together soon. Computer collection highlights: 800XL computer Indus GT drives (2 drives; one in fair conditionnot to be trusted, the other in good condition with plastic storage case and the original software) 1050 drive in box (Happy enhanced) APE For Windows Complete Starter Kit USB Games by Atari, Infocom, Epyx, EA (much of it CIB) Misc cables, software, peripherals Video game collection highlights: Boxed consoles (Jaguar w/ CD, 7800) Loose consoles (2600, 5200, Lynx, Telegames II) Some CIB 2600 and 5200 games Controllers for each console system 2600 cartridge adapter for 5200 I haven't used most of these items for years, but they've been stored indoors out of the way. Now they're in the way. Anyone in the Phoenix area is welcome to schedule a time to stop by and check things out. (That would also be the quickest way to take home a huge bargain.) Meanwhile I'll do my best to get a more detailed list ready with condition and prices. Pricing will be fair, as my motivation to unload the collection is more about to time than money. Hope this is enough info in the initial post. I'm trying to gauge interest without spamming the group.
  22. SOLD!! Atari XE System, COMPLETE 2 beige controllers & beige light gun. I'd like to see $150 + ship ATARI MULTI CART IS NOT INCLUDED - only used to show i plays carts fine see photos, a little dusty but very nice. kept in storage bin buy itself. works perfectly. someone remind me how to boot the built in game??
  23. This is a rare bird indeed. I picked this up along with a few other fellow atariagers many years ago from a cable company that was selling off old gear. This unit was used to create the TV Guide station for the cable company, it has a special cart designed to do just that purpose. I would rather let the pictures speak for themselves and then folks can ask questions In the photos you will notice a screen shot of th custom cart software i comes with, but I also used my Atari Multi Cart to show that it can indeed play regular games. This does NOT come with the A/V cable I used to get the video feed to my monitor. The custom video setup is BNC/RF/COAX I guess, I don't know much about it but the BNC connector for video out is a broadcast industry standard from back in the day before digital. there is also some crazy thing plugged in to the peripheral port and custom cartridge uses both the cart & expansion ports to plug in. Be ware you do NOT get my a/v cable or any controllers, just what you see in the photos that is built in to the blue rack box which you can unscrew three screws and take the cover off very easily. this is heavy. 25Lbs and is gonna fit into a box that is roughly 24x20x6 I would like to get about $350 $200 + ship for this considering how unusual it is and how it has all these cool modifications for the power supply, video and peripheral port. what you see is what you get, please ask many questions, make reasonable offers, yadda yadda. remember, no a/v cable, controller or my flash cart is included, just what is built into the box, you of course get the very unique custom software which has two nice chips on it. I will add a closeup of that cart later
  24. Atari 600xl Chips for Sale C014795 $11.99 C012296 $10.99 C014806 $10.99 C014805 $11.99 All chips have been tested and are working. I have several of each chip. US shipping would be $2.70 plus $0.10 per chip. International shipping is $5.70 plus $0.70 per chip. PM me with which chips you need and how many as well as the shipping address and I will send an invoice through paypal. I will also consider any reasonable trade offers of atari 2600 games or original Commodore software.
  • Create New...