Search the Community

DPOKE ============================================================== 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/ ============================================================== Writing a two-byte, 16-bit value (DPOKE) goes hand-in-hand with reading (DPEEK). An 8-bit computer environment has many opportunities for managing 16-bit address and the Atari environment is no exception. Address of display lists, Address of screen memory. Addresses of buffers. Address pointers abound. OSS BASIC XL provides the DPOKE command to perform a 16-bit, two-byte write to a specified memory location. Like DPEEK, this can be duplicated in regular Atari BASIC, although much slower. So, in BASIC XL the action: Dpoke Address, Value is frequently seen in Atari BASIC programs expressed as: POKE ADDRESS, VALUE - INT( VALUE / 256 ) * 256 POKE ADDRESS + 1, INT( VALUE / 256 ) That’s a bit more complicated than DPEEK. Here the value must be broken down into the high byte (integer result of the value divided by 256) and the low byte (the remainder after division), and then the two values assigned to the two consecutive bytes in memory in low byte, high byte order. This can also be worked into a reusable subroutine in Atari BASIC: 10 DPOKE=28500 20 ADDRESS=560:VALUE=39968:GOSUB DPOKE 30 END. . . 28497 REM IMPLEMENT DPOKE 28498 REM INPUT = ADDRESS 28499 REM INPUT = VALUE 28500 HB=INT(VALUE/256) 28501 POKE ADDRESS,VALUE-HB*256:POKE ADDRESS+1,HB 28502 RETURN This is still fairly simple code. A small difference here is the high byte is calculated and retained to avoid multiple occurrences of the same floating point division. But, again, expressed in Atari BASIC this is fairly slow using one floating point division and one multiplication. As before, applying assembly language rocketry yields: DPOKE in Mac/65 Assembler Code 0100 ; DPOKE 0105 ; 0110 ; Write a 16-bit word into 0115 ; the specified address. 0120 ; 0125 ; USR 2 arguments: 0130 ; Addr == address to write. 0135 ; Val == Value to write. 0140 ; 0145 ; USR return value is 0. 0150 ; 0155 ; Use the FR0 FP register. 0160 ; The return value for BASIC 0165 ; goes in FR0. 0170 ; No FP is used so all of FR0 0175 ; (and more FP registers) can 0180 ; be considered available. 0185 ; 0190 ZRET = $D4 ; FR0 $D4/$D5 Return value 0195 ZARGS = $D5 ; $D6-1 for arg Pulldown loop 0200 ZVAL = $D6 ; FR0 $D6/$D7 Value 0205 ZADDR = $D8 ; FR0 $D8/$D9 Address 0210 ; 0215 .OPT OBJ 0220 ; 0225 ; Arbitrary. This is relocatable. 0230 ; 0235 *= $9600 0240 ; 0245 INIT 0250 PLA ; argument count 0255 TAY 0260 BEQ EXIT ; shortcut for no args 0265 ASL A ; now number of bytes 0270 TAY 0275 CMP #$04 ; Value, Address 0280 BEQ PULLDOWN 0285 ; 0290 ; Bad args. Clean up for exit. 0295 ; 0300 DISPOSE ; any number of args 0305 PLA 0310 DEY 0315 BNE DISPOSE 0320 BEQ EXIT 0325 ; 0330 ; This code works the same 0335 ; for 1, 4, 8 ... arguments. 0340 ; 0345 PULLDOWN 0350 PLA 0355 STA ZARGS,Y 0360 DEY 0365 BNE PULLDOWN 0370 ; 0375 ; Y is already zero here. 0380 ; 0385 LDA ZVAL 0390 STA (ZADDR),Y 0395 INY ; now Y is 1 0400 LDA ZVAL+1 0405 STA (ZADDR),Y 0410 ; 0415 ; On failure Y = 0 0420 ; On Success Y = 1 0425 ; 0430 EXIT ; 0435 STY ZRET 0440 STY ZRET+1 0445 RTS ; bye. 0450 ; 0455 .END The error detection and handling have a few differences from DPEEK. The DPOKE routine does not inherently require a response value where DPEEK does, so the DPOKE code does not have separate, early-exit code and uses only one place to set the response value merely to indicate general success or failure. This code uses an additional Page Zero value to accept the value to write to the address: 0190 ZRET = $D4 ; FR0 $D4/$D5 Return value 0195 ZARGS = $D5 ; $D6-1 for arg Pulldown loop 0200 ZVAL = $D6 ; FR0 $D6/$D7 Value 0205 ZADDR = $D8 ; FR0 $D8/$D9 Address The real work part of the code is obviously different since writing bytes into memory (DPOKE) is not the same as reading bytes from memory (DPEEK): 0375 ; Y is already zero here. 0380 ; 0385 LDA ZVAL 0390 STA (ZADDR),Y 0395 INY ; now Y is 1 0400 LDA ZVAL+1 0405 STA (ZADDR),Y The DPOKE version above conforms to my standard plan (more or less) for stack management and error handling. Most of the remaining utilities will stick with this plan. However, for the sake of (averting) argument there are admittedly more optimal ways to accomplish this depending on the programmer's definition of optimal. For instance, the value to write to the address need not be temporarily stored in Page Zero. After the code pulls the target address from the stack and establishes it in Page Zero it could pull the value and directly store it to the target address, like this: 0375 ; Y must be 1 here. 0380 ; 0385 PLA ; high byte 0390 STA (ZADDR),Y 0395 DEY ; now Y is 0 0400 PLA ; low byte 0405 STA (ZADDR),Y That does look clever as it subtracts two bytes from the code, and removes ZVAL from Page Zero. However, to make this work the argument handling must be different to pull two, not four bytes worth of arguments, and the Y value must be reset to 1 before arriving at this code, and the error return value needs to be reworked. In other words, the code savings in one place may be consumed by code needed in another place. The standardized approach may not be the most optimal, but it is conceptually consistent, flexible, and doesn't need to be re-factored from scratch for each different routine. Also, regardless of the degree of inefficiency in this less-than-optimal method the execution time is negligible compared to slower Atari BASIC. More time is spent by Atari BASIC converting the floating point values into 16-bit integers to pass as arguments to the machine language routine than the amount of time for execution of the the machine language routine. Testing DPEEK and DPOKE The Atari BASIC program below, TESTDPK.BAS, demonstrates how to load the machine language routines into strings and it tests the two routines: 0 REM H1:TESTDPK.BAS 100 REM TEST DPEEK AND DPOKE USR() TOOLS 110 GRAPHICS 0:POKE 710,0:POKE 82,0 120 GOSUB 10000 130 REM 140 REM TEST DPEEK 150 REM 155 ? "*** DPEEK ***" 160 DL=PEEK(560)+256*PEEK(561) 170 ? "BASIC Dpeek Display List = ";DL 180 DL=0 190 DL=USR(DPEEK,560) 200 ? "USR() Dpeek Display List = ";DL 210 REM 220 REM TEST DPOKE 230 REM 240 CL=10+256*68:REM 711=10,712=68 250 X=USR(DPOKE,711,CL) 260 REM 270 REM VERIFY WITH DPEEK 280 REM 290 ? "*** DPOKE ***" 300 ? "10 + 256 * 68 = ";10+256*68 310 CL=PEEK(711)+256*PEEK(712) 320 ? "BASIC After Dpoke = ";CL 330 CL=0 340 CL=USR(DPEEK,711) 350 ? "USR() After Dpoke = ";CL 360 END 970 REM 980 REM DPEEK AND DPOKE 990 REM 10000 DIM DPE$(36),DPO$(38) 10001 DPEEK=ADR(DPE$):DPOKE=ADR(DPO$) 10010 RESTORE 27000 10011 FOR I=0 TO 35 10100 READ D:POKE DPEEK+I,D 10101 NEXT I 10110 FOR I=0 TO 36 10111 READ D:POKE DPOKE+I,D 11000 NEXT I 11001 RETURN 26999 REM dpeek.obj 27000 DATA 104,168,240,10,10,168,201,2 27010 DATA 240,9,104,136,208,252,132,212 27020 DATA 132,213,96,104,153,213,0,136 27030 DATA 208,249,177,214,133,212,200,177 27040 DATA 214,133,213,96 28999 REM dpoke.obj 29000 DATA 104,168,240,28,10,168,201,4 29001 DATA 240,6,104,136,208,252,240,16 29002 DATA 104,153,213,0,136,208,249,165 29003 DATA 214,145,216,200,165,215,145,216 29004 DATA 132,212,132,213,96 First the program performs DPEEK the slow way in BASIC by calculating the 16-bit address of the display list (at locations 560 and 561) with a multiply in BASIC (line 160). Then the program performs the same action using the DPEEK USR() routine (line 190). The value determined by each method is displayed for comparison: Next the program tests the DPOKE USR() routine by assigning a 16-bit value to locations 711 and 712. First it calculates the 16-bit value and reports it. Then it performs DPOKE via the USR() routine (Line 250). Then it retrieves the contents of the two memory locations by the slower BASIC method for DPEEK and by the DPEEK USR() routine. Finally, it reports the value determined by each method to verify the value was written to memory correctly: Below are the source files and examples of how to load the machine language routine into BASIC included in the disk image and archive: DPOKE File List: DPOKE.M65 Saved Mac/65 source DPOKE.L65 Mac/65 source listing DPOKE.T65 Mac/65 source listed to H6: (linux) DPOKE.ASM Mac/65 assembly listing DPOKE.TSM Mac/65 assembly listing to H6: (linux) DPOKE.OBJ Mac/65 assembled machine language program (with load segments) DPOKE.BIN Assembled machine language program without load segments DPOKE.LIS LISTed DATA statements for DPOKE.BIN routine. DPOKE.TLS LISTed DATA statements for DPOKE.BIN routine to H6: (linux) MAKEDPOK.BAS BASIC program to create the DPOKE.BIN file. This also contains the DPOKE routine in DATA statements. MAKEDPOK.LIS LISTed version of MKDPOKE.BAS MAKEDPOK.TLS LISTed version of MKDPOKE.BAS to H6: (linux) TESTDPK.BAS BASIC program that tests the DPEEK and DPOKE USR() routines. TESTDPK.LIS LISTed version of TESTDPK.BAS. TESTDPK.TLS LISTed version of TESTDPK.BAS to H6: (linux) ZIP archive of files: Dpoke_Disk.zip Tar archive of files (remove the .zip after download) Dpoke_Disk.tgz.zip For we are his workmanship, created in Christ Jesus for good works, which God prepared beforehand, that we should walk in them. Ephesians 2:10

DPEEK ============================================================== 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/ ============================================================== Since one byte can hold the value 0 to 255 a value larger than 255 requires two bytes. The second byte takes the place value 256. Just as Base10 has “ones” values 0 to 9, and then “tens” value for the next position, so the two bytes provide a Base256 value – “ones” value 0 to 255 in the first position and then 256 as the “tens” in the second position. The two-digit value limit for Base10: multiply the maximum base value by 10 for the “tens” value and add the maximum base value of the “ones”, or 9 * 10 + 9 = 99. The same applies for Base256: multiply the maximum base value by 256 for the “tens” and then add the maximum base value as the “ones”, or 255 * 256 + 255 == 65,535. (Or, in hex this is $FF * $100 + $FF == $FFFF.) So, the real value limit of 16-bits starts at 0 and ends at 65,535 or $FFFF. The 64K address space of an 8-bit computer is described by a 16-bit value. So, the Atari environment is liberally sprinkled with 16-bit values as addresses, pointers, and larger integer values. Manipulating 16-bit values is complementary to working in the Atari computing environment, but Atari BASIC does not provide a direct and easy method for this. OSS BASIC XL provides the Dpeek() function to perform a 16-bit, two-byte PEEK of the value at a specified memory location. This can also be duplicated in regular Atari BASIC, although slower. In BASIC XL the action: Value = Dpeek( Address ) is frequently seen in Atari BASIC programs expressed as: VALUE = PEEK( ADDRESS ) + 256 * PEEK( ADDRESS + 1 ) That’s not very complicated. A little programming grease mixed with Atari BASIC’s ability to GOSUB to a variable produces this reusable subroutine: 10 DPEEK=28000 20 ADDRESS=560:GOSUB DPEEK 30 ? "DPEEK(560)= ";VALUE 40 END. . . 27997 REM IMPLEMENT DPEEK 27998 REM INPUT = ADDRESS 27999 REM OUTPUT = VALUE 28000 VALUE=PEEK(ADDRESS)+256*PEEK(ADDRESS+1) 28001 RETURN The routine is simple; just one real line of BASIC code. But, execution in Atari BASIC is fairly slow, since it includes a floating point multiplication. Infrequent slothfulness is forgivable, but repeated use causes obvious performance drag. What this problem needs is a little assembly language propulsion... DPEEK Mac/65 Assembler Code 0100 ; DPEEK 0105 ; 0110 ; Return the 16-bit contents 0115 ; at the specified address. 0120 ; 0125 ; USR 1 arguments: 0130 ; Addr == address of value. 0135 ; 0140 ; USR return value is 16-bit 0145 ; contents of address. 0150 ; 0155 ; Use the FR0 FP register. 0160 ; The return value for BASIC 0165 ; goes in FR0. 0170 ; No FP is used so all of FR0 0175 ; (and more FP registers) can 0180 ; be considered available. 0185 ; 0190 ZRET = $D4 ; FR0 $D4/$D5 Return value 0195 ZARGS = $D5 ; $D6-1 for arg Pulldown loop 0200 ZADDR = $D6 ; FR0 $D6/$D7 Address 0205 ; 0210 .OPT OBJ 0215 ; 0220 ; Arbitrary. This is relocatable. 0225 ; 0230 *= $9700 0235 ; 0240 INIT 0245 PLA ; argument count 0250 TAY 0255 BEQ EXIT_ERR ; shortcut for no args 0260 ASL A ; now number of bytes 0265 TAY 0270 CMP #$02 ; Address 0275 BEQ PULLDOWN 0280 ; 0285 ; Bad args. Clean up for exit. 0290 ; 0295 DISPOSE ; any number of args 0300 PLA 0305 DEY 0310 BNE DISPOSE 0315 ; 0320 EXIT_ERR ; return "error" 0325 STY ZRET ; Y is Zero 0330 STY ZRET+1 ; 0335 RTS ; bye. 0340 ; 0345 ; This code works the same 0350 ; for 1, 4, 8 ... arguments. 0355 ; 0360 PULLDOWN 0365 PLA 0370 STA ZARGS,Y 0375 DEY 0380 BNE PULLDOWN 0385 ; 0390 ; Y is already zero here. 0395 ; 0400 LDA (ZADDR),Y 0405 STA ZRET 0410 INY 0415 LDA (ZADDR),Y 0420 STA ZRET+1 0425 ; 0430 RTS ; bye. 0435 ; 0440 .END In this first example I’ll walk through all the setup and safety checks. This will be similar for most of the other utilities. Some programmers would consider that there is much more code here than required. The safety checks look like overkill, because the working code for this particular utility is so short. Protecting the BASIC programmer from torpedoing the system is important enough to justify protection. From the point of view of execution timing this overhead is inconsequential compared to the speed of BASIC. First of all, the routine is relocatable which means the code makes no absolute references to locations within itself. All branches are relative to the current location, so the code could execute from almost anywhere in memory. However, it does need a couple of fixed locations for working values in the program: 0155 ; Use the FR0 FP register. 0160 ; The return value for BASIC 0165 ; goes in FR0. 0170 ; No FP is used so all of FR0 0175 ; (and more FP registers) can 0180 ; be considered available.0185 ; 0190 ZRET = $D4 ; FR0 $D4/$D5 Return value 0195 ZARGS = $D5 ; $D6-1 for arg Pulldown loop 0200 ZADDR = $D6 ; FR0 $D6/$D7 Address The program needs two values – the address from which to PEEK the 16-bit value, and a place to put the 16-bit value for BASIC to reference. Specifically, the code is using the Page Zero locations. “Page Zero” means all the address locations where the high byte of the address is $00. (The 256 locations from address $0000 to $00FF). Page Zero locations are chosen for several reasons: 6502 instructions referencing Page Zero are one byte shorter and usually execute faster than instructions referencing other pages. The 6502 has useful addressing modes that only work for Page Zero references. BASIC already defines a place in Page Zero for the value the machine language routine returns to BASIC. Since Page Zero locations are so useful they are also highly contested. The Atari OS defines and uses just about every byte in the first half of Page Zero. BASIC and the Floating Point routines use almost all of the second half of Page Zero. As it turns out the locations used by this machine language routine are “claimed” by the Floating Point routines. However, as long as the machine language routine does not need to use the Floating Point routines then these locations are free for use. Now to the working code. The routine begins by pulling the argument count from the stack and checking for zero arguments. If it finds no arguments to process then the routine branches to another location for an early exit. Yes, the TAY instruction is not needed to correctly branch for no arguments. The PLA instruction sets the zero flag when the argument count popped from the stack is zero. However, the exit code will use the Y register to return an error value (which is zero) to BASIC: 0240 INIT 0245 PLA ; argument count 0250 TAY 0255 BEQ EXIT_ERR ; shortcut for no args Next, the routine converts the number of arguments into the number of bytes to pull from the stack. It uses ASL which is the same as multiplying the value in the Accumulator times two. This is stored in the Y register which is used as an index for later loops. The routine verifies the argument count is correct (only 1 argument – the address to PEEK) which is 2 bytes. If this is correct the routine branches to the code that will pull the stack values and place them in Zero page memory for use later: 0260 ASL A ; now number of bytes 0265 TAY 0270 CMP #$02 ; Address 0275 BEQ PULLDOWN If the argument count is incorrect then the routine discards the argument values on the stack, so it can safely exit. Remember the Y register already contains the number of argument bytes on the stack: 0295 DISPOSE ; any number of args 0300 PLA 0305 DEY 0310 BNE DISPOSE Next, the routine falls into the exit section. Earlier, if there were no arguments the routine branched here directly. Note that if there are no arguments the Y register contained 0 when it branched here directly, and at the conclusion of cleaning up the stack in the DISPOSE loop the Y register will also be 0. So, in either case of bad arguments, too many or too few, the return value to BASIC is cleared to 0: 0320 EXIT_ERR ; return "error" 0325 STY ZRET ; Y is Zero 0330 STY ZRET+1 ; 0335 RTS ; bye. Clearing the return value really isn’t necessary and isn’t exceedingly useful beyond insuring random values are not returned to BASIC in the case of an error. Returning a real error would require the USR() pass another argument from BASIC that the routine would use to indicate success or failure. However, the DPEEK action is so simple that this level of error detection begins to enter the arena of silly. The error detection shown here already leans toward overkill and is done for design consistency with the other utilities covered later. At this point the arguments are correct. The routine pulls the values from the stack and places them in Page Zero locations $D6/$D7 referred to as ZADDR. On entry to this point in the code the Y register contains the number of bytes to pull from the stack (always 2 for this routine). The loop pulls them off the stack and places them into memory descending as it goes, because the high byte is pulled first, then the low byte. The base address is not ZADDR, but ZARGS, a value defined one byte less than ZADDR. This is because the Y value will be used as an index from the number of argument bytes (2, 4, 6, etc.) counting down to 1, not to 0. Counting backwards results in the stack values placed in memory in the correct low byte, high byte order used by the 6502. When Y reaches 0 it falls out of the loop: 0360 PULLDOWN 0365 PLA 0370 STA ZARGS,Y 0375 DEY 0380 BNE PULLDOWN This code works for any number of arguments as long as the destination can be sequential bytes in memory. However, this is admittedly overkill for only one argument. More explicit code that directly pulls one 16-bit argument from the stack requires the same number of instructions, but is one byte less (and executes faster). Just for reference: 0360 PULLDOWN 0365 PLA 0370 STA ZADDR+1 ; high byte first. 0375 PLA 0380 STA ZADDR ; low byte next. The actual work to perform the double byte peek is just the five instructions before the final RTS. The routine reads two bytes through the address contained in ZADDR ($D6/$D7) and copies the bytes to the return value, ZRET ($D4/$D5): 0400 LDA (ZADDR),Y 0405 STA ZRET 0410 INY 0415 LDA (ZADDR),Y 0420 STA ZRET+1 After the routine exits Atari BASIC converts the value stored in locations $D4/$D5 (ZRET in the code) into a floating point value. This becomes the return value from USR(). So, in the following BASIC statement the variable X is assigned the value taken from $D4/$D5: 250 X=USR(DPEEK,560): REM DISPLAY LIST ADDRESS Below are source files and examples of how to load the machine language routine into BASIC included in the disk image and archive: DPEEK File List: DPEEK.M65 Saved Mac/65 source DPEEK.L65 Mac/65 source listing DPEEK.T65 Mac/65 source listed to H6: (linux) DPEEK.ASM Mac/65 assembly listing DPEEK.TSM Mac/65 assembly listing to H6: (linux) DPEEK.OBJ Mac/65 assembled machine language program (with load segments) DPEEK.BIN Assembled machine language program without load segments MKDPEEK.BAS BASIC program to create the DPEEK.BIN file. This also contains the DPEEK routine in DATA statements. MKDPEEK.LIS LISTed version of MKDPEEK.BAS MKDPEEK.TLS LISTed version of MKDPEEK.BAS to H6: (linux) DPEEK.BAS BASIC program that loads DATA statements into a string. DPEEK.LIS LISTed version of DPEEK.BAS DPEEK.TLS LISTed version of DPEEK.BAS to H6: (linux) The next task should be a test program to demonstrate using DPEEK in BASIC. But, since DPEEK isn’t much use without DPOKE, we will visit DPOKE first before using the machine language routines together in a BASIC program. ZIP archive of files: Dpeek_Disk.zip Tar archive of files (remove the .zip after download) Dpeek_Disk.tgz.zip Therefore I tell you, do not be anxious about your life, what you will eat or what you will drink, nor about your body, what you will put on. Is not life more than food, and the body more than clothing? Look at the birds of the air: they neither sow nor reap nor gather into barns, and yet your heavenly Father feeds them. Are you not of more value than they? And which of you by being anxious can add a single hour to his span of life? And why are you anxious about clothing? Consider the lilies of the field, how they grow: they neither toil nor spin, yet I tell you, even Solomon in all his glory was not arrayed like one of these. Matthew 6:25-34

Who needs some 8-bit classics, especially some of the harder to find XE titles? All tested and working perfectly; cart-only unless otherwise noted. PM for pics and we can chat about a price that works for both of us. Thanks! Cartridge-based: Crime Buster XE Donkey Kong XE AtariArtist (silver label) AtariWriter Pilot Tape-based: Caverns of Khafka cassette tape + box UNTESTED but I received it brand new - only opened it because I needed the manual for my collection Let me know if you have any q's! Need a manual? Check out my "manual man" post for a semi-complete list (still worth inquiring about others that I may have)!

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:

A short time ago I found some (debatably) useful utilities for the Atari 8-bit while scraping a crate of old floppies into ATR files. One of these is a character set editor I have been working on (and off) for a few decades. I spent most of July adding a few useful features for the modern era of Atari emulators, and dealing with some bugs. So, here's a new toy to play with, GRID EDIT. The attached ZIP file will unpack to an ATR. I ordinarily use this as D2:. GRIDEDIT_ATR.zip Better docs should be completed soon, (Copy and paste from a word doc is not looking very good.) Here's a first stab at useful info... ==================================================== REQUIRES 40K RAM, OSS BASIC XL, floppy disk drive or emulator supporting Host drives. PROBABLY REQUIRES DOS 2.0S, or other DOS with an equally small (or smaller) footprint. With DOS2.0S there is about 1.4K of free ram between the end of the program, and the fixed location of the first character set in RAM. RECOMMENDED Joystick, or Touch Tablet FEATURES Edits 8 fonts in memory. Most functions/operations can be applied to a single character or an entire font. Reverts font changes to the last saved version, the version read at startup, or the original ROM version. An onscreen doodling area allowing preview of the fonts with font and color changes permitted per line. Keyboard, Joystick, or Touch Tablet operation. Non-modal (mostly) input methods allow open workflow for the user. (Simultaneous editing, menu, and doodling operations.) ==================================================== INTRODUCTION My favorite Atari 8-bit feature is redefined character sets, because it is fairly simple to utilize and so readily fit into my tiny brain. Atari’s character set magic provides considerable bang for the buck allowing even slow BASIC programs to achieve graphics movement approximating animation. Over the years I’ve collected and written countless character set editors. GRIDEDIT is one of my old, much-abused BASIC prototypes of unpolished features and experimental user interfaces hacked up prior to writing better versions in Assembly. This is a simple character editor for ANTIC Mode 2 (GRAPHICS 0) text fonts. It can also be applied to Mode 6/7 text with the understanding the program does not show colored characters. GRIDEDIT was originally developed using the Atari 800 with 48K (and cassette!). A few changes were recently added using Altirra emulating a 64K 800XL. Seems to work fine. ==================================================== SUMMARY In the upper left is the edit grid to change the current character. in the top center of the screen is the menu to choose actions, switch fonts, etc. In the upper right is the character selector showing all 128 Atari font characters. Below the selector is a status line reporting the state/behavior of the program. In the center of the screen is a preview line that shows the current font centered on the current character being edited. At the bottom of the screen is a doodling area. Each row of text can have its own colors and fonts assigned. (DLI abuse going on.) The user’s input cursor appears as a flashing block on the screen. Move the cursor with the current input device – the arrow keys, the joystick, or the touch tablet stylus. Press a controller button or use the Space Bar or Enter key to select the item under the cursor. The display/user input is primarily non-modal. While a Menu is waiting for input the Edit Grid is still functional, the Character Selector can choose characters in the current font, and the Doodling area allows drawing characters. ==================================================== EDIT GRID The Edit Grid presents an 8 x 8 grid of the current character's bitmap. Within the bitmap the controller button(s) (or keyboard) turn bits on and off: Use the joystick button to toggle bits on and off. Use the keyboard’s ‘Return’ and ‘/’ keys to turn bits on and off. Use the touch tablet’s left, right, and stylus buttons to turn bits on and off. The outer borders are shortcuts for bit shifting operations. Selecting the outermost border containing arrows will move the entire bitmap contents in the direction of the arrow. The next border inside will move just the bits in that horizontal line or vertical column. The ‘S’ or ‘R’ characters at the corners of the inner border indicate the current bit shifting mode when selecting the bit shift shortcut borders. The character displayed in inverse video indicates which mode is in effect: S – “SHIFT”: bits shifted past the borders of the grid are lost, and the new bits shifted in are zero/clear. R – “ROLL” bits shifted past the borders of the grid “roll” around and reappear as the new bits on the opposite side of the grid. ==================================================== MENU The menu allows choice of functions or operations. A choice is made by moving the cursor to the corresponding line and pressing the controller button or Return key. Some choices will present other menus. Most menus have a Cancel option as the last entry that will quit the current line of prompting and return to an earlier menu. Some Menus include an OK option to accept the changes made on screen. ==================================================== CHARACTER SELECTOR This array presents all 128 Atari characters. Move the cursor to the desired character and press the controller button or Return key to edit the character in the current font. ==================================================== STATUS The status box provides important information to the user. The first line reports the current Font (1 to 8 ) and the character being edited as a hexadecimal value for its position in the font. The left half of the second line displays the list of possible input devices. The current input device is shown as an abbreviation – “Joy” for joystick, “Key” for keyboard, and “Tab” for Atari touch tablet. The input devices not in use are represented by a single inverse video character of the key to press to activate the device. (‘J’, ‘K’, or ‘T’). The right half of the second line displays the current mode for bit manipulation functions and other operations. The values may be “Char” or “All”. “Char” mode means the function or operation chosen works only on the current character. In “All” mode the functions and operations act on the entire current font. The first character of each mode appears as inverse video indicating the key to press to set the mode. The last line of status displays the font and character information marked as the intended source for the Copy operation. The first value is the font number, then a slash, then the hexadecimal value of the character’s position in the font. ==================================================== PREVIEW The Preview lines show the current font on the top line, and inverse video on the second line. A flashing marker appears above and below the current character. Additionally, the Preview display also allows choosing the character to edit. Move the cursor to the desired character and press the controller button or Return key to edit the character in the current font. ==================================================== DOODLING The Doodling area allows plotting the current character in a 40 character x 8 line display. Each line of the display can be adjusted to set a new value for font (CHBASE), character control (CHACTL), Border color (COLBK), line color (COLPF2) and text luminance (COLPF1). The joystick button plots the character on screen. The ‘Return’ key also plots, and the ‘/’ key plots the inverse video value of the current character. Likewise, the touch tablet buttons plot in normal and inverse video. ==================================================== STARTUP LOAD the program into OSS BASIC XL, and RUN it. After a few moments the program will present a list of disk drive devices choices numbered 1 through 4. Choose the disk device to use as the default device by pressing the corresponding number key. The Return key is not needed. The chosen default device will be used for all subsequent save and load operations. The program will attempt to load eight fonts from the default disk drive. The fonts have fixed names on the disk: FONT1.FNT, FONT2.FNT, etc. up to FONT8.FNT. If a file is not found then the program will automatically use a copy of the internal ROM font. The program will save a backup file on the default disk device for each font. The backup for FONT1.FNT is F1.FNT, FONT2.FNT is F2.FNT, and so on. The backup is created only during the program startup and never written again. If the DOODLE.DAT file exists, the program will load the configuration of the Doodling area from that file including the characters that had been drawn in the Doodle area, and the fonts and colors chosen for each of the lines. ==================================================== INPUT The cursor may be controlled and input provided via keyboard, joystick, or touch tablet. Special keys controlling the operating configuration function regardless of the current input method. KEYBOARD Use the arrow keys (with or without the ctrl key) to move the cursor. JOYSTICK Use the joystick plugged into the first joystick port to move the cursor. The joystick button will choose items, draw pixels in the current character, or draw in the doodle are depending on the location of the cursor. TOUCH TABLET The tablet stylus will move the cursor around the screen. CONFIGURATION KEYS Configuration keys are always available regardless of the type of input. K - Set keyboard input J – Set joystick input T – Set touch tablet input C - Set Character-only mode for Functions A - Set All (entire Font) mode for Functions S - Set Bit Shift mode for Grid Editor R - Set Bit Roll mode for Grid Editor ==================================================== BUGS There are certainly more than enough bugs to go around. Share with friends and enjoy. You’re welcome. “All” mode has side effects when editing a Doodle row’s configuration: When a Doodle configuration item menu is entered (CHBASE, COLBK, etc.), the program automatically changes all the lines’ values to the current value for the chosen line. Since only the last value of the current row is remembered for the case of the Cancel menu choice, it causes Cancel to return all the rows to the previous value of the current row, not the previous value of each individual row. Switching back to “Char” mode will cause the Cancel menu item to revert only the chosen Doodle row’s configuration, leaving all the other rows modified. ==================================================== RANDOM NOTES Disregard that FRE(0) says there’s about 10.5K of free memory. The 8 fonts are at fixed locations starting at $7800. This works out to about 1.4K of actual free memory. The lowest hanging fruit for optimizing has been done – using variables in place of constants. Without that the program would probably be looking at space for only 5 fonts. This program had little pre-planning - - or 30 years of design consideration depending on the point of view. It has been hacked on over and over to add features and change behaviors. Due to this there are redundant variables and temporary variables that occur only once in the code. Finding and optimizing this is an exercise for the masochistic. The easiest way to free up a ton of memory is to remove the many, many REMark lines. That is, if you never intend to understand the program. Reading comprehension plummets without the comments. Those who understand Display List Interrupts will recognize that the DLIs for the Doodling area are doing three and one-half things more than can actually fit in the horizontal blank time allowed. It is what it is. The DLIs are there just to provide a rough guess of what the characters sets will look like. The most recent round of hacks made the program play nicer with an emulator (Altirra preferred for Windows). This added support for Host drives (really trivial) and touch tablet input. An emulator implementing a fake touch tablet is a cheap way to have mouse support from the Host environment without handling the mouse in the Atari itself and so frees the Atari from the overhead of a polling (or frequently interrupting) machine language handler. Tablet support took just about an hour to work out tablet coordinates vs the Player/Missile screen cursor. ==================================================== WHY OSS BASIC XL? I work in straight Atari BASIC only if someone requires it. OSS BASIC XL is 99% of my BASIC use and one of the underappreciated gems on the Atari 8-bits. It bugged me that Atari magazines back in the day printed articles for Action!, but never for BASIC XL which had a much larger user base. It loads Atari BASIC tokenized (SAVE’d) programs without changes, 99% compatible ENTER’ing programs previously LIST’ed by Atari BASIC. It is faster (much faster) than Atari BASIC. BASIC XL provides a heap of neat, built-in extra features… Player/Missile graphics support. Memory move at machine language speeds. String arrays. Structured statements: If/Else/Endif and While/Endwhile FAST mode that predetermines line location to eliminate the line lookup overhead. [*]It fits in a ROM cart occupying the same memory as 8K Atari BASIC. [*]Everyone and their cousin should be able to easily get the ROM running under emulation.

Looking for a replacement top and bottom shell for my 1979 style Atari 800. If anyone has one, or a parts unit I could pull the shell off of, let me know. I'm open to negotiating on price. Thanks!

Hi, I have the following items for sale: Atari 8-bit Computer Tape Games* EURO 20 European Countries and Capitals (Atari) TIB EURO 7 Meltdown (Cosmi) TB EURO 40 Richard Petty's Rennzirkus (Ariolasoft) TIB EURO 40 Strätos (Adventure International) TB (incl. Xerox instructions) EURO 15 The E Factor (Cosmi) TIB EURO 20 Zaxxon (Datasoft) TB * For more pictures just scroll down to the update post Atari Memorabilia EURO 25 Atari T-Shirt Berzerk (Size S, unused) EURO 25 Atari T-Shirt Defender (Size S, unused) Activision Patches EURO 10 Chopper Command EURO 35 Decathlon Bronze Make an offer Decathlon Gold EURO 10 Dragster EURO 25 Freeway EURO 20 Kaboom! EURO 30 Megamania EURO 125 Pitfal 2 EURO 25 Pitfall! Make an offer Robot Tank Star of Honor EURO 25 Spider Fighter EURO 70 Tennis EURO 50 Stampede Belt All patches are original, no repros. Atari 2600 Original Releases - Atari 2600 Reproductions EURO 175.00 Good Luck, Charlie Brown! - CIB - NTSC Made by CPUWIZ; #22, shrinkwrapped EURO 45.00 Music Machine - CIB - NTSC - Reproduction; Made by CPUWIZ *** Pending ***Atari 2600 Stella gets a new Brain Original Release (serial number #012, signed manual, very good condition): EURO 130 Atari 7800 - Atari Lynx - Atari 8-bit Computer Disk Wargame Construction Set (SSI) - complete: EURO 15 Springer - Tigervision/NTSC - CIB: EURO 60 The Great American Cross-Country Road Race - Activision/NTSC - DIB: EURO 25 Gauntlet: The Deeper Dungeons Data Disk - Mindscape/NTSC - DIB: EURO 35 Infiltrator - Mindscape/NTSC - DIB: EURO 30 Pinball Construction Set - Electronic Arts/NTSC - DIB: EURO 15 One on One - Electronic Arts/NTSC - DIB: EURO 15 Atari Standees + Mobile All items are made of cardboard (no posters) and all are original. The shipping to the USA (EURO 37) is so expensive because of the individual sizes are too big to ship as a small parcel/letter. Megamania – Activision 2600 – Standee – 31 cm x 22 cm – US – good condition – EURO 175 Merchandise Contra III Promo Puzzle from 1992 (shrink-wraped, bent because of the foil): EURO 100 Intellivision - Intellivision Poster - More Pictures For more detailed pictures please check this Gallery Please check also my other sale listings: Atari 2600 Reproductions + Homebrews Atari 5200 Prototypes Shipping Information I am located in Germany. The shipping options are: - GERMANY Regular Parcel (EURO 7.50) - EU Regular Parcel (EURO 17.00) - USA/CANADA Airmail Parcel (EURO 37.00, runtime about 14 to 21 days, insured, tracking) or Airmail Letter option for USA & Canada: I can offer airmail letter in robust box for 2 regular-sized boxed Atari games/parcel for EURO 4/parcel (no tracking, no insurance, runtime about 5 to 7 days) *** Payment Information Payment by Paypal/EURO only. If you have any questions, please drop me a PM. Exchange rate is about 1.00 EURO -> 1.20 US$ Be sure to check this topic from time to time, I am adding games on a daily base. Thanks for watching, Marc.

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

Introduction Atari Jam is a Windows tool for developing Atari 8-bit computer software. The theoretical concept is that it is a PBI device that maps the memory, allowing an external device to monitor and change things in real-time. In practice, this is accomplished by attaching to an external emulator and accessing the RAM. The program gives the user a suite of tools to interactively modify, tweak, test and program software. It is not intended to be a replacement for a development IDE but rather to let the user experiment and rapidly develop small projects or pieces of something larger. It currently compatible with an Atari 800XL with 64K of RAM. Features Live memory viewer/editor Interactive disassembler Assembler Character editor Character map editor Player/missile editor Graphics control (GRACTL, DMACTL, GPRIOR) and color picker Display list editor Experimental video player (AVI) Vector control Notes The video player is very limited in the input it will accept. It uses a dither pattern that will be applied each frame, using the current palette. The user can adjust colors to find the best match. The program monitors GRACTL and PM registers through the addition of an OS patch that removes shadowing for the paddles. This patch slightly reduces the cycles used by the OS during a refresh. Hopefully, this is something people will find useful. I plan to have a version ready to try by March 1st.

I recently was given a large collection of Atari items. There were many catalogs in it, including a 6-page DataQue Software "Product Information Release #91.06.03." There is some pretty neat (and hard to believe) information about some two Atari-compatible computers it it. Here is a picture of the first page of the "catalog:" I've also scanned and uploaded the full 6-page catalog to archive.org, here: https://archive.org/details/DataQueSoftwareProductsForAtari8BitComputers1991 I've dictated, using Dragon, the descriptions of these two Atari computers: 130XEC: An Atari 130XE computer on a PC card! This will allow you to have all the fun and utility of an 8-bit system hidden in your PC. Using a special MSDOS interface, you're 8-bit applications can use the PC video and other peripherals, in addition to normal 8-bit devices. It may even be possible to run an 8-bit process as a task using Windows 3.0! The 'XEC' will be designed with a high degree of compatibility with the original XL/XE line. Connections will be provided for two joystick ports, cartridge port, audio/video monitor output, SIO connector, and of course normal 80x88 PC card edge. 1600XLE: The Ultimate 8-bit machine... with a blazing 'no wait state" 8MHz 65C816 processor on a 'baby AT' size motherboard, nothing will come close to the performance of this machine. A custom interface chip will allow PC interface cards to be used on the Atari 8-slot backplane. This motherboard will fit into most PC style cases, and will run Atari 8-bit applications which make no illegal entry points into the OS, or use direct screen access. This monster would be for the power users only, not the casual game player! Using normal PC peripherals would keep costs down, and allow maximum expandability. Has anyone ever heard of this company before? A search of the Internet associates someone named Chuck Steinman with some DataQue products. What's the story of these, very-probably, unreleased hardware items? Were prototypes of these computers ever made, or was this just an idea that never even reached prototype stage? What about the other products in this catalog; were they released? Adam

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!

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

I'm working on getting Atari 8-Bit set up in RetroPie using the Atari800 emulator and most everything seems to be working just fine except for this: My WASD keys don't deliver any input at all. I've tried multiple keyboards, checked to make sure they aren't currently bound to joystick controls in the emulator and I assume there is somewhere in the emulator which is binding them to "movement" but I can't seem to find it. So right now, any game that requires pressing "S" to start, like the Scott Adams adventure games, I can't do anything with because my "S" key doesn't work. I've scoured Google looking for solution but it seems there aren't many people who have set up Atari800 on the RetroPie because it most certainly isn't the most user friendly of emulators. Anyone else run into this same issue and found a solution? Thank you in advance for your help!

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

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.

Available for $39.95. Many cartridges available. Will run on any Atari 8-bit computer from 16K and up. To ensure the game can be ported to the Atari 5200 and for very few that may find an Atari computer with only 16K on Ebay, I mapped the game to only use the RAM from location $0000 to $3FFF (0 to 16384). The game also is not OS dependent, so it can also run fine with 400/800 OS. Speed has been adjusted if detected running on NTSC machines so it will run the same speed on both PAL, SECAM, or NTSC. The game using the joystick to move the pointer / "putter club" around. There are two modes. The default is that you set the pointer to where you want to aim the ball at, hold the fire button down for how hard you want to hit it, and release. The other is similar to how the Atari 2600 Miniature golf works, the pointer / square bock represents a putter golf club, and how hard the ball is hit is based on the distance the club is from the ball. I remember my brothers and I having fun with 2600 miniature golf and purposely put the square in the opposite corner of the screen and hit the ball just to see how long it will go bouncing around the screen. Over the years, I made various miniature golf games using Basic on various machines. I lost my original Atari Basic version of the game. One day Video 61 suggested doing a miniature golf game in ML and put it on cartridge. One feature this game does have is when you hit the space bar, a score card pops up. It will do that through the pause on the 5200. There is no point in having pause with a miniature golf game because you can just put the joystick down if you need to walk away to do something. There are 4 different Miniature Golf courses, some holes are real challenging. The moving obstacles can disabled. The game using some Super-IRG so it can appear a few more colors are present, majority of the holes only have a few pixels alternating at 50/60 frames per second, so there is no noticeable flicker on standard displays. Wide Over scan mode with Horizontal Fine scroll is in use. HOZSCR is set so the right screen static is down to one pixel. All the holes are drawn using the central 42 characters so there should not be anything off the screen. http://members.tcq.n...o61/putt18.html thanks for looking,

I rolled up a quick-n-dirty simple retro birthday card for a friend. (No music. Maybe for next year's card.) (And, No, FillInTheBlank is not their actual name. ) Assembly code. Redefined character sets do the animated flames. Display kernel updating colors on every scan line. lots of laziness in evidence. Too lazy to actually do a VBI or DLI. Assembly code is here if anyone is interested: https://github.com/kenjennings/WIP-HBFITB Video is on youTube: https://youtu.be/WLELDFDT3uM

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

There's no way!!! help!!!

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!

Hello! I want to share some ATARI POKEY I made. These are both originals and covers, along with some behind the scenes. So, without further ado, I'm going to leaving this link here: https://www.youtube.com/watch?v=jgwcI3ATf3U&list=PLptR0gr8Js-44DoEDc_ZvYY6wlQWZZbcC Please, enjoy! I'm also looking forward to hearing from you all!

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.

I'm presently in the market for an Atari XE game system. The bare minimum I want is the console & keyboard with any accessories for TV hookup. If anyone has the whole setup - console, keyboard, joystick, light gun, Flight Simulator and Bug Hunt Cartridges, hookup accessories - that's even better. I reside in the USA. While I am willing to pay for shipping in the USA and Canada, I will not pay shipping costs for any units from elsewhere (UK, Europe, etc). Anyone who has the above and is willing to part with it can either reply here or contact me via DM. If we decide to do business and close the deal, I'm willing to cut a check but can negotiate other payment terms.

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.

Hello Atari 8-Bit Community! We were inspired by the many kind responses about our Atari BASIC game development document, our newly posted 1980's Anschuetz/Weisgerber/Anschuetz Atari BASIC games, and our Antic Atari Podcast. For those that missed it, here are the links: Forum post with Atari BASIC game development document and 1980's Atari BASIC games: http://atariage.com/forums/topic/268424-1980s-anschuetzweisgerberanschuetz-basic-games-release/ Antic Atari Podcast: http://ataripodcast.libsyn.com/antic-interview-297-robert-anschuetz-eric-anschuetz-john-weisgberber-antic-magazine-games In this post, we are uploading version 2.0 of the Atari BASIC game development document. This version enhances the original document in many paragraphs, and also adds some new and very interesting sections to the document. This version includes our original 1980's type-written (we didn't have a printer) instructions and programming notes that were submitted along with our BASIC games to Antic, COMPUTE!, and A.N.A.L.O.G. Perhaps even more interesting, we have also scanned the correspondence letters from these magazines for programs that were accepted and rejected for publication. The table of contents indicates these new sections (Development Notes pages 46-71, and Magazine Correspondence 75-91). These are scans from documents that hadn't seen the light of day since the 1980's! Thanks go out to John Weisgerber for saving all of this information for the past 30 years! We are still trying to dig up the old design notes and the graph paper that we used for character bitmaps! They are probably in the attic, closet, or basement somewhere. We hope you enjoy these new additions. Robert Anschuetz Eric Anschuetz John Weisgerber Anschuetz-Wesigerber-Anschuetz v2.0.pdf