Search the Community

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

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.

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

I have read comments, here and on YouTube, over the past 3 years. I have made some updates to all of these games here! A quick note about the hacks: I have decided to place all of my hacks in one, convenient thread. As I grew up with my Atari 5200 and Atari 800XL, there were certain games that I thought had a little more potential. I had created basic hacks for a few of these games. I always thought that my 5200 Popeye could look better. Brutus didn't have a number "5" for a head in the arcade version. I knew I had drawn more accurate Mario characters on my 800XL. If only I could plug them into the games. I teamed up with Playsoft, who provided the tools and wisdom to make these games possible. Some of these games have other contributors. Tep392 helped us tweak the collision and touchy controls in DK Jr. I believe that Tep392 and Kjmann worked on the original Donkey Kong RMT sound version. I believe there is another member who helped Playsoft in some of the A8 to 5200 conversions. I am not sure who drew the giant Popeye head. If anybody has clarity on this, let me know, so credit can go where it is due. These are truly community projects, and I had a great time watching them transform. Playsoft did an amazing job of hacking display list interrupts, giving me a little more height area (eg. thicker 5200 Mario Bros floors, as well as multiple floor types). I have been holding off on releasing the latest Mario Bros hacks, because I didn't want to release as many revisions. I was also hoping for some upgraded sound effects for Mario, but there's not always enough time in the day. There's a bonus hack for the 7800 Mario Bros. I found the 7800 graphics tedious to hack. The characters were drawn too small and flat, and the game itself plays horribly. That version has the least number of animation frames, so the animation is poor regardless. It is my "Lipstick on a Pig" release. Donkey Kong: Atari 8-bit Computer Arcade version -- DK_A8_Arcade.xex Atari 8-bit Computer RMT version (Updated sound) -- DK_A8_RMT.xex Atari 5200 Supersystem version -- DK5200_Arcade.bin Donkey Kong Jr: (Arcade & Enhanced versions) Atari 8-bit Computer Arcade version -- DKJr_A8_Arcade.xex Atari 8-bit Computer Enhanced version -- DKJr_A8_Enhanced.xex Atari 5200 Supersystem Arcade version -- DKJr_5200_Arcade.bin Atari 5200 Supersystem Enhanced version -- DKJr_5200_Enhanced.bin Popeye Arcade: Atari 8-bit Computer version --PopeyeArcade_A8_Final.xex Atari 5200 Supersystem version -- Popeye5200_ArcadeFinal.bin Mario Bros (1983, 5200 version): Atari 5200 Supersystem bin version -- MarioBros_Arcade_52.bin Atari 5200 Supersystem car format -- MarioBros_Arcade_52.zip Mario Bros XE: Atari XL/XE version - MarioBrosArcade_XE.zip Mario Bros 7800: Atari 7800 version - Mariobros_7800_Arcade.a78

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

I know you can turn on or off the key click (POKE 731,0 or POKE 731,255), but I'm wondering if it's possible to generate the key click sound on command? Is there a bit of code to call from basic, or possibly a way in basic to generate the same or very similar noise? I don't remember my sound coding from back in the day or I'd probably be able to figure it out myself. I don't mind cheating by calling the existing key click routine

Hi, New/old A8 basic coder here (haven't touched it in ~30y). Trying to remember how to use ML strings to redefine character sets... My most immediate problem is that I can't get certain characters on the screen. CHR$(127) does not output the right-facing triangle character. I need to get that in a string to redefine my character set but I'm forgetting how. The screenshot attached shows another person's program that contains said character in a string, but I don't know how it was done. I have access to Atari800MacX, Envision on a windows XP VM, and I'm open to other mac/win/a8 tools if there's an easy-peasy character set generator that outputs what I need. I also don't mind converting the values by hand into ATASCII but I figure there's easier ways My requirements are that the code be self-contained in the basic file and that it be as compact as possible, so I can't use external files to load the charset data, and I figure strings are better than data statements.

Understanding Atari Graphics by Michael Boom 1982. 101 Atari Computer Programming Tips and Tricks by Alan North 1983. Your Atari Computer - a guide to Atari 400/800 personal computers by Ion Poole 1982. An Atari for Kids by Sharon Boren 1984. All books are in used condition with various stages of wear. If these do not sell, they will go to Salvation Army. Media Mail from 80138. Thank you.

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

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.

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)

Rewindgames will release ANG Software's Greatest Hits on October 24th 2016. Worldwide premiere at the Abbuc JHV Meeting on October 22nd in Herten Germany. This premium collectors edition features the 6 best Dutch puzzle games for the Atari 8-bit: Johnny the Ghost, Mines!, Simple Minds, Shit!, Thinx and Whoops 2 on one disk! For sale at Rewindgames.com from October 24th 2016 for only € 12.99. Exclusive premiere discount at the Abbuc JHV. Buy it in Herten, Germany for only € 9.95! https://youtu.be/OBwwmjXkwQo

I am digging out some of the rare stuff in my collection (after 20+ years of storage) and wondering what the value on some of them are... Specifically, here's an Atari 1200 prototype unit. I haven't tried to turn it on, but it worked years ago when I last powered it up. I have a couple of 8-bit prototypes, 5200 prototypes, and quite a few 2600 prototypes I'll be asking about soon, too! Thanks for your help...

Binary File I/O (Part 2 of 2) ============================================================== 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/ ============================================================== New XIO in Mac/65 Assembler Code Many articles on this subject go by a simple route – use BASIC code to set up all the IOCB values for the 7/Get Bytes or 11/Put Bytes commands, and then provide a minimal assembly routine that simply calls the CIO vector. While BASIC mangles the binary read/write functions, XIO itself also is sufficiently broken to justify a complete machine language USR() routine that exercises CIO commands the way they were intended. For example, ICAX values are not always needed or even wanted, but XIO requires the values. In fact, ICAX values are rarely needed outside of the 3/Open command. Similarly, the filespec/buffer is often not necessary. This routine will perform the same purpose of XIO, but allow a variable number of arguments, adding more arguments only as needed: Always required (2 arguments): 1) Channel Number – Only low byte values 0 to 7 accepted. The high byte is ignored. 2) CIO Command – Only the low byte of the argument will be used. Optional (4 arguments): 3) Filespec/Buffer address – 16-bit value 4) Filespec/Buffer length – 16-bit value Additionally optional when the Filespec/Buffer is provided (5 arguments): 5) ICAX1 – the low byte of this argument is used. High byte is ignored. Additionally optional when the Filespec/Buffer and ICAX1 are provided (6 arguments): 6) ICAX2 – the low byte of this argument is used. High byte is ignored. Since the routine accepts 2, 4, 5, or 6 arguments it can support any of the following: 2) USR(NEWXIO,6,18) – Perform command 18/Fill for screen device (assuming channel 6) 4) USR(NEWXIO,1,254,ADR(F$),LEN(F$)) - Use channel 1 to format (254) the disk drive described by F$. This would also be the format/number of arguments needed for performing CIO Commands 7/Get Bytes and 11/Put Bytes. 5) USR(NEWXIO,5,3,ADR(F$),LEN(F$),6) - Use channel 5 to open (3) the disk directory (read/4 + directory/2 = 6) described by F$ 6) USR(NEWXIO,6,3,ADR(F$),LEN(F$),28,7) – Use channel 6 to open (3) as graphics mode 7 with a text window (read/4 + write/8 + window/16 = 28) assuming F$ describes “S:” Variable number of arguments means this program is organized differently from the prior utilities that copy stack arguments to Page Zero. Since this is just an interface for putting values into the IOCB it doesn't make use of Page Zero beyond returning a status value to BASIC. 0100 ; NXIO.M65 0105 ; 0110 ; NEW CIO/XIO INTERFACE 0115 ; 0120 ; SETUP IOCB WITH THE SUPPLIED 0125 ; ARGUMENTS AND CALL CIO 0130 ; 0135 ; USR 2, 4, 5, or 6 ARGUMENTS: 0140 ; CHANNEL == IOCB CHANEL (LOW BYTE) 0145 ; COMMAND == CIO COMMAND (LOW BYTE) 0150 ; BUF ADR == ADDRESS OF BUFFER 0155 ; BUF LEN == LENGTH OF BUFFER 0160 ; ICAX1 == CIO ICAX1 VALUE (LOW BYTE) 0165 ; ICAX2 == CIO ICAX2 VALUE (LOW BYTE) 0170 ; 0175 ; RETURN VALUE IS CIOV RESULT IN Y REG 0180 ; 0185 ZRET = $D4 ; FR0 $D4/$D5 Return Value 0190 ; 0195 CIOV = $E456 ; CIO Vector 0200 ; 0205 IOCB = $0340 ; Base IO Control Block 0210 ICHID = IOCB+$00 ; Handler ID 0215 ICDNO = IOCB+$01 ; Device number 0220 ICCMD = IOCB+$02 ; ** CIO Command 0225 ICSTA = IOCB+$03 ; CIO Status 0230 ICBAL = IOCB+$04 ; ** Buffer address (low) 0235 ICBAH = IOCB+$05 ; ** Buffer address (high) 0240 ICPTL = IOCB+$06 ; Put char routine (low) 0245 ICPTH = IOCB+$07 ; Put char routine (high) 0250 ICBLL = IOCB+$08 ; ** Buffer length (low) 0255 ICBLH = IOCB+$09 ; ** Buffer length (high) 0260 ICAX1 = IOCB+$0A ; ** Aux Byte 1 0265 ICAX2 = IOCB+$0B ; ** Aux Byte 2 0270 ICAX3 = IOCB+$0C ; Aux Byte 3 0275 ICAX4 = IOCB+$0D ; Aux Byte 4 0280 ICAX5 = IOCB+$0E ; Aux Byte 5 0285 ICAX6 = IOCB+$0F ; Aux Byte 6 0290 ; 0295 .OPT OBJ 0300 ; 0305 *= $9000 ; Arbitrary. this is relocatable 0310 ; 0315 INIT 0320 LDY #$FF ; Make the return 0325 STY ZRET ; value -1 ($FFFF) 0330 STY ZRET+1 ; by default. 0335 ; 0340 PLA ; Get argument count 0345 BEQ BYE ; Shortcut for no args. 0350 ; 0355 TAY 0360 ; 0365 CMP #$01 ; One arg is not enough. 0370 BEQ DISPOSE 0375 ; 0380 CMP #$03 ; Three args is not supported. 0385 BEQ DISPOSE 0390 ; 0395 CMP #$07 ; More than six is not valid. 0400 BCC DO_CHANNEL ; All good. Ready to pull args. 0405 ; 0410 ; Bad arg count. Clean up for exit. 0415 ; 0420 DISPOSE ; Any number of arguments 0425 PLA 0430 PLA 0435 DEY 0440 BNE DISPOSE 0445 RTS ; Abandon ship. 0450 ; 0455 ; Pull channel and multiply times 16 0460 ; 0465 DO_CHANNEL ; Arg 1 = Channel 0470 DEY ; subtract one arg 0475 PLA ; discard high byte 0480 PLA ; Channel number 0485 CMP #$08 ; More than 7 channels 0490 BCS DISPOSE ; is invalid. 0495 ASL A ; * 2 0500 ASL A ; * 4 0505 ASL A ; * 8 0510 ASL A ; * 16 0515 TAX 0520 ; 0525 DO_ICCMD ; Arg 2 = Command 0530 PLA ; discard high byte 0535 PLA ; command byte 0540 STA ICCMD,X ; Store Command in IOCB 0545 DEY ; subtract one arg 0550 BEQ DO_CIO0555 ; 0560 DO_ICBA ; Arg 3 = Buffer Address 0565 PLA ; Address high byte 0570 STA ICBAH,X 0575 PLA ; Address low byte 0580 STA ICBAL,X 0585 DEY ; subtract one arg 0590 ; 0595 DO_ICBL ; Arg 4 = Buffer Length 0600 PLA ; Length high byte 0605 STA ICBLH,X 0610 PLA ; Length low byte 0615 STA ICBLL,X 0620 DEY ; subtract one arg 0625 BEQ DO_CIO 0630 ; 0635 DO_ICAX1 ; Arg 5 = Aux Byte 1 0640 PLA ; discard high byte 0645 PLA ; Aux byte 0650 STA ICAX1,X ; Store AUX1 in IOCB 0655 DEY ; subtract one arg 0660 BEQ DO_CIO 0665 ; 0670 DO_ICAX2 ; Arg 6 = Aux Byte 2 0675 PLA ; discard high byte 0680 PLA ; Aux byte 0685 STA ICAX2,X ; Store AUX2 in IOCB 0690 DEY ; This should be zero args now... 0695 ; 0700 DO_CIO ; IOCB is set, now execute... 0705 STY ZRET ; Clear return value low 0710 STY ZRET+1 ; and high byte. 0715 JSR CIOV ; Engage, Mr Crusher. 0720 BPL BYE ; No error 0725 STY ZRET ; Copy Y to return value 0730 ; 0735 BYE 0740 RTS 0745 ; 0750 .END The initialization is similar to prior utilities. It begins by setting the return value to a known value ($FFFF) that cannot be returned by a successful exit. Then it pulls the argument count and does a series of value checks to identify any invalid number of arguments. If the code identifies an issue here it branches to cleaning the stack and then exits. One difference in the stack argument management is that this utility does not double the argument count to derive the number of bytes on the stack, because it will not be looping to copy the stack values into Page Zero. The channel handling is more involved than other arguments: 0455 ; Pull channel and multiply times 16 0460 ; 0465 DO_CHANNEL ; Arg 1 = Channel 0470 DEY ; subtract one arg 0475 PLA ; discard high byte 0480 PLA ; Channel number 0485 CMP #$08 ; More than 7 channels 0490 BCS DISPOSE ; is invalid. 0495 ASL A ; * 2 0500 ASL A ; * 4 0505 ASL A ; * 8 0510 ASL A ; * 16 0515 TAX The channel is pulled from the low byte of the argument. If the value exceeds the range of available channels, then it diverts to the stack cleanup to dispose of the remaining arguments and exits. Recall the earlier discussion about identifying the IOCB for a specific channel -- multiply the channel number times 16 and add to $340. Here the code multiplies the channel number by 16 allowing use of the value as an index to load values into the correct IOCB. The remaining arguments are handled similarly: 0525 DO_ICCMD ; Arg 2 = Command 0530 PLA ; discard high byte 0535 PLA ; command byte 0540 STA ICCMD,X ; Store Command in IOCB 0545 DEY ; subtract one arg 0550 BEQ DO_CIO The values are pulled from the stack and stored in the corresponding IOCB field. Then the argument counter is decremented. At the end of processing the arguments for command, buffer length, and ICAX1 (arguments 2, 4, and 5) the argument count is tested if it has reached zero. If this occurs then the program skips over the work for processing any subsequent arguments. Finally, it gets down to business: 0700 DO_CIO ; IOCB is set, now execute... 0705 STY ZRET ; Clear return value low 0710 STY ZRET+1 ; and high byte. 0715 JSR CIOV ; Engage, Mr Crusher. 0720 BPL BYE ; No error 0725 STY ZRET ; Copy Y to return value Recall that the Y register is used to count arguments and by the time the routine reaches this point the Y register is guaranteed to contain zero. So, this is a convenient source to clear the high byte of the return value for BASIC. Next, the code calls the CIO Vector ($E456). When the CIO routine returns the error code is in the Y register and the utility copies that value to the low byte of the return value. Let's go over a couple implications when this is used in BASIC: 1. The function accepts an absolute address and a length allowing access to any part of memory. While this is much more flexible than XIO it also means that this routine cannot directly accept a BASIC string. This routine can use a string passed by its address via ADR(). It is also up to the BASIC program to pass the correct length. LEN() is correct only when the string has defined content, so a BASIC program must fill or pad out the string to its expected length. 2. Since this is a USR() routine it is not integrated in BASIC's error handling. Therefore TRAP cannot trap any Input/Output errors. The BASIC program must check the return value of the NXIO routine or use the STATUS command to identify problems. Testing New XIO Now that we have some experience using files for binary data we're going to start with something different. The Atari BASIC program below, MAKENXIO.BAS, creates a binary file containing the machine language code for the NXIO routine. 1 REM MAKENXIO.BAS 5 REM CREATE NXIO.BIN FILE 10 OPEN #1,8,0,"H1:NXIO.BIN" 15 FOR I=1 TO 94 20 READ D:PUT #1,D 25 NEXT I 30 FOR I=95 TO 255 35 PUT #1,0 40 NEXT I 45 CLOSE #150 END 21996 REM H1:NXIO.OBJ 21997 REM SIZE = 94 21998 REM START = 36864 21999 REM END = 36957 22000 DATA 160,255,132,212,132,213,104,240 22001 DATA 84,168,201,1,240,8,201,3 22002 DATA 240,4,201,7,144,6,104,104 22003 DATA 136,208,251,96,136,104,104,201 22004 DATA 8,176,243,10,10,10,10,170 22005 DATA 104,104,157,66,3,136,240,34 22006 DATA 104,157,69,3,104,157,68,3 22007 DATA 136,104,157,73,3,104,157,72 22008 DATA 3,136,240,14,104,104,157,74 22009 DATA 3,136,240,6,104,104,157,75 22010 DATA 3,136,132,212,132,213,32,86 22011 DATA 228,16,2,132,212,96 22012 DATA 67,3,133,212,96 This will make managing the utility easier, allowing the test program (and any other BASIC program) to load the utility directly from the file without reading DATA statements. Note that the program purposely pads the output to 255 bytes, so that a BASIC program can use the (broken) XIO command to load the binary data. Next, is the test program that exercises the features of NXIO. It begins by loading the NXIO machine language routine into a string using XIO. This is acceptable for the tightly confined usage here – the program does only one operation to read a file of 255 bytes. The remaining CIO activity in the program is run by the shiny, new NXIO routine: 100 REM TSTNXIO1.BAS10 5 REM TEST THE NEW XIO USR ROUTINE 110 POKE 82,0:GRAPHICS 0 115 DIM NXIO$(255):NXIO$(255)=" " 120 NXIO=ADR(NXIO$) 125 REM READ NXIO FROM FILE 130 OPEN #1,4,0,"H1:NXIO.BIN" 135 XIO 7,#1,4,0,NXIO$ 140 CLOSE #1 145 REM 150 REM TEST THE BAD ARG EXIT 155 REM TEST BAD ARGS 0160 ? "TESTING BAD ARGUMENTS..." 165 BADARG=USR(NXIO) 170 ? "BAD ARGS 0 = ";BADARG 175 REM TEST BAD ARGS 1 180 BADARG=USR(NXIO,3) 185 ? "BAD ARGS 1 = ";BADARG 190 REM TEST BAD ARGS 3 195 BADARG=USR(NXIO,3,3,32000) 200 ? "BAD ARGS 3 = ";BADARG 205 REM TEST BAD ARGS 7 210 BADARG=USR(NXIO,3,3,32000,2,3,3,3) 215 ? "BAD ARGS 7 = ";BADARG 220 GOSUB 595 225 REM 230 REM DO CIO 3/OPEN TO SET UP 235 REM A GRAPHICS MODE AND RUN 240 REM THE 18/FILL COMMAND.2 45 REM FORCE "S:" CLOSED 250 CLOSE #6 255 REM OPEN AS GR MODE 5, NO WINDOW 260 GROPEN=USR(NXIO,6,3,ADR("S:"),2,12,5) 265 REM SAME AS EARLIER XIO FILL DEMO 270 COLOR 3 275 PLOT 70,45:DRAWTO 50,10 280 DRAWTO 30,10:POSITION 10,45 285 POKE 765,3290 XFILL=USR(NXIO,6,18) 295 GOSUB 600:REM WAIT FOR A KEY 300 REM REPORT THE RESULTS 305 GRAPHICS 0 310 ? "GROPEN = ";GROPEN 315 ? "XFILL = ";XFILL 320 GOSUB 595 325 REM 330 REM GAMES WITH BINARY FILES 335 REM LOAD THE 8 BYTE MEMORY FILE 340 DIM D$($="!!!!!!!!" 345 ? "LOADING 8 BYTE MEMORY.BIN..." 350 OPEN #1,4,0,"H1:MEMORYT0.BIN" 355 XREAD8=USR(NXIO,1,7,ADR(D$), 360 CLOSE #1 365 FOR I=1 TO 8 370 ? ASC(D$(I,I)), 375 NEXT I 380 ? "XREAD8 = ";XREAD8 385 GOSUB 595 390 REM 395 REM SAVE THE ROM CHARACTER SET 400 CR=57 344:REM ROM SET $E000 405 ? "SAVING ROM CHARACTER SET..." 410 OPEN #1,8,0,"H1:CSET.BIN" 415 XSAVE=USR(NXIO,1,11,CR,1024) 420 CLOSE #1 425 ? "XSAVE = ";XSAVE 430 GOSUB 595 435 REM 440 REM GAMES WITH THE BINARY LOAD 445 REM SETUP SCREEN FIRST... 450 GRAPHICS 0:POSITION 0,12 455 SC=PEEK(88)+256*PEEK(89) 460 FOR Y=0 TO 7 465 FOR X=0 TO 31 470 POKE SC+Y*40+X,Y*32+X 475 NEXT X 480 NEXT Y 485 ? "NORMAL CSET DISPLAYED" 490 ? "TO LOAD SOFT SET" 495 GOSUB 595 500 REM 505 REM LOAD THE SOFT SET IN 510 REM FLIPPED HALF SETS 515 CH=36864:REM SOFT SET $9000 520 POKE 756,144 525 OPEN #1,4,0,"H1:CSET.BIN" 530 CSLOAD1=USR(NXIO,1,7,CH+512,512) 535 CSLOAD2=USR(NXIO,1,7,CH,512) 540 CLOSE #1 545 ? "SWAPPED, SOFT CSET CSET DISPLAYED" 550 GOSUB 595 555 REM 560 REM THE END 565 GRAPHICS 0 570 ? "CSLOAD1 = ";CSLOAD1 575 ? "CSLOAD2 = ";CSLOAD2 580 END 585 REM 590 REM WAIT FOR A KEY 595 ? "PRESS A KEY" 600 OPEN #1,4,0,"K:" 605 POKE 764,255 610 GET #1,A 615 CLOSE #1620 RETURN The program begins by reading the machine language routine via XIO into a string 255 characters long. Yes, the routine is actually only 94 bytes long, so it wastes a bit of space. Such is life when using XIO. The first round of tests validates the argument management. There is a separate test for each bad argument possibility – 0, 1, 3, and 7 (or greater). Each failure to start results in error code 65535 from NXIO: The next round of tests uses NXIO with all the supported arguments to open a graphics mode 5 display with no text window. Then it draws a shape and uses NXIO to execute the 18/Fill command: After the fill completes press a key to continue and then the program prints the NXIO exit codes for the Graphics Open and the Fill: Press a key again and the program runs the next test which uses 7/Get Characters to read the 8-byte MEMORYT0.BIN file created earlier. After loading the file the program prints the ATASCII codes for the bytes in the string. It should report the values below, and then print the exit code from NXIO for the 8-byte read.: Press a key after this to run the next test. This will use the 11/Put Characters to save the entire 1,024 bytes of the Atari's ROM character set to a file. Then it will print the exit code from the NXIO routine for the operation: Press a key to run the next test. This will prepare the screen to demonstrate loading the character set from the file into memory. The characters are displayed in the internal order. Note the order of the characters. Press a key to continue the test. The program will use 7/Get Characters to load the first 512 bytes from the file into the second 512 bytes of the soft character set in memory, and then it loads the second set of 512 bytes from the file into the first 512 bytes of the soft character set in memory. This effectively swaps the images of the first half of the character set with the second half. Observe the “changed” order of the characters: Finally, press a key to return the display to the normal character set and the program will display the return codes from NXIO for the loading activities and then it ends: The tests all work as expected, especially all the uses of 7/Get Characters and 11/Put Characters. So, there is no problem with CIO. The problem really is that BASIC's XIO command unnecessarily manages the interface to CIO commands. Correct use of the CIO commands is so simple and the behavior XIO implements is so involved and complicated that it is difficult to consider it simply an accident. What could be the reason for XIO's bizarrely over-engineered behavior? Perhaps at the time Atari BASIC was designed there was an expectation that these I/O operations must work in increments no less and no more than 255 bytes. Perhaps a misunderstanding between OS design and BASIC design? Perhaps design requirements were in motion and it was too late to fix the behavior. Truly weird. Below is a list of the source files and test examples from the New XIO discussion available in the disk image and archive. The files are listed in the order presented during the discussion. The BASIC programs come in the tokenized BASIC format ending in .BAS. Two listings in text format are also provided: Atari ATASCII format as .LIS and unix/linux text format ending in .TLS. New XIO File List: MSAVEDAT BASIC program to PRINT eight values to a file. MSAVEDT0 BASIC program to PUT eight bytes to a file. MLOADDT0 BASIC program to GET eight bytes from a file. XIOFILL BASIC program performing the XIO fill command using device “Q:” MSAVEDT2 BASIC program using XIO for 11/Put Bytes to write a file. MSAVEDT3 BASIC program using XIO for 11/Put Bytes to write data to a file with a trailing string to identify the source of excess file data. MLOADDT BASIC program using XIO for 7/Get Bytes. MLOADDTX BASIC program using XIO for 7/Get Bytes with a trailing string to detect excess data read from the file. MSAVE512 BASIC program to generate a file containing 512 bytes. MLOAD512 BASIC program using XIO for 7/Get Bytes attempting to load 512 bytes from a file. MLOAD8 BASIC program using XIO for 7/Get Bytes attempting to load bytes from a file containing 8 bytes. NXIO.M65 Saved Mac/65 source NXIO.L65 Mac/65 source listing NXIO.T65 Mac/65 source listed to H6: (linux) NXIO.ASM Mac/65 assembly listing NXIO.TSM Mac/65 assembly listing to H6: (linux) NXIO.OBJ Mac/65 assembled machine language program (with load segments) NXIO.BIN Assembled machine language program without load segments with additional data padded to the end of the file to make it 255 bytes long. NXIO.DAT LISTed DATA statements for NXIO machine language routine. MAKENXIO BASIC program to create the BIN file with padding to 255 bytes so the file can be loaded using XIO to read the binary data. TSTNXIO1 BASIC program testing the NXIO USR() routines for various CIO commands. ZIP archive of files: NXIO_Disk.zip Tar archive of files (remove the .zip after download) NXIO_Disk.tgz.zip Game Over The movie really is over this time. Thanks for playing. Enjoy the new toys. Finally, welcome to the new world of assembly language. Try to think of new ways to accelerate and improve BASIC programs. - End - Blessed is the man who walks not in the counsel of the wicked, nor stands in the way of sinners, nor sits in the seat of scoffers; Psalm 1:1

Binary File I/O (Part 1 of 2) ============================================================== 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/ ============================================================== Sidebar: This section turned out to be considerably more difficult and time consuming to write than anticipated. No two sources agree completely on this subject. The only consistency I found is the list of CIO and XIO command numbers. Everything else encountered documents this subject with varying amounts of accuracy. Descriptions of the CIO and XIO commands sometimes differ in the just names, but in ways that imply different expectations for results. Detailed descriptions of the commands vary from the strangely incomplete to being outright wrong. One guide for machine language on this subject described CIO features using the BASIC XIO limitations. Another tutorial declared that only 155 bytes could be read in one operation. In the end it took writing test programs in BASIC and Assembly to understand precisely how XIO commands work vs how the corresponding CIO commands actually do work. If anyone cares, the stuff that worked is derived from reading De Re Atari (50%, which was mostly correct), Compute!'s Mapping the Atari (20% and it has a couple mistakes), Atari's BASIC Reference Manual (15% which was painful and incomplete), and rest from several 6502 programming manuals that were altogether horriffic. Stating that programs work with data would be borderline silly. Everything about programs is about working with data – they calculate data, manipulate data, and copy data. A fundamental concern of programming is how to introduce data to the program and get it back out. Many programs have their data built into them or receive data by computing values, reading from storage, or by other input/output device or communications. A file contains data. A serial port sends and receives data. A joystick provides data. Numbers are data, text is data, graphic information is data. Data, Data, Data. Atari BASIC programs have access to several data acquisition methods. Data may be stored in a program using DATA statements. Data may be read from a file, or from user input. Although all data is ultimately represented as bytes in memory, BASIC languages provide a higher abstraction where the data it accepts is usually expressed as text and numbers, and even in the case of number values the input and output data is expressed as the text equivalent of the number value. This means data presented to BASIC is typically not in its final, usable form for the computer. The BASIC language reads the text data then converts it into a format the computer understands. Although an Atari BASIC program can contain its own data, it cannot have the data built into it in a form that is immediately usable. For instance, variables and array elements must be specifically initialized. The program must assign the values as it runs. There is not even a default behavior to clear numeric array values to zero. Data contained in DATA statements is not immediately usable by the Atari's unique features. The Atari's custom hardware features often use blocks of binary data – Graphics data, character set data, Player/Missile images, etc. The Atari BASIC DATA statement cannot present arbitrary binary data. It can only present decimal numbers and strings with limitations on the characters that can be included in the string. Like most BASIC languages, Atari BASIC has little provision for dealing with data in the computer's terms other than PEEK and POKE. Most Atari BASIC programs creating data in memory for Atari graphics features will read DATA statements – the text equivalent of number values – and then POKE those values as bytes into memory. This consumes a lot of storage space in the BASIC program. The byte value 192 in a DATA statement is presented as the text characters “1”, “9”, and “2” and then if there is another value the comma separator between the values also occupies memory. This one value to POKE into one byte of memory requires four supporting bytes in DATA. And then after the program stores the value in memory the DATA statement continues to occupy memory, wasting space. Wasted space means reduced space for code and reduced features in large programs. In addition to DATA's memory space issue the other problem with reading DATA statements is BASIC's slow execution time. BASIC must loop for every data value; reading the data, storing it into memory, and then reading more data. Any significant amount of data provides a long, boring wait for the user. Many BASIC games share this “feature” of making the user wait for a long program initialization. The second test program for the BITS utilities illustrates this problem. The time to store several machine language utilities totaling only about 300 bytes in memory was long enough that the program's loading section was modified to output helpful progress messages to assure the user the program had not crashed. Now consider that one complete character set is 1,024 bytes, and a complicated program may need to setup several thousand bytes of data. Assembly language and some compiled languages do not have these same issues with data storage space. These languages can declare where data will occupy memory and define the initial values. This is saved with the assembled/compiled machine language program, so the same mechanism that loads the machine language program into memory also establishes the organized, initialized data in memory. So, what to do about BASIC's problems? Eliminating the space-wasting behavior means eliminating DATA statements filled with numbers, or somehow optimizing the contents. Strings could be used to represent a lot of data. One character of a string is conveniently one byte of information. But strings still have a few problems: ATASCII characters are not always the same as binary byte values, so some translation is needed. Representing cursor control characters can be problematic when a program is LIST'ed and then ENTER'ed. There are two characters that cannot be expressed at all in a quoted string – the ATASCII End of Line character and the quote character itself. If the data includes either of these unpresentable characters then the string as DATA must replace them with a different value that can be included, and then after assigning the string it must go back and insert the problem characters into their correct positions in the string. This means adding more data to identify the locations of these special characters. Furthermore, the DATA statements filled with strings still occupy memory after the data is assigned to a string variable, though the waste factor for string characters is closer to 1:1 rather than roughly 4:1 for numeric (byte) data. If a BASIC program completely eliminates the DATA statements then where else can a program get its data? Here is an idea – This program loads values into memory from DATA: 10 RESTORE 50 20 FOR I = 0 TO 7 30 READ D:POKE 1536+I,D 40 NEXT I 50 DATA 2,34,27,155,132,130,129,128 That program above has the same end result as this program loading values into memory from a file: 10 OPEN #3,4,0,"D1:MEMORY.BIN" 20 FOR I = 0 TO 7 30 INPUT #1,D:POKE 1536+I,D 40 NEXT I 50 CLOSE #1 The difference is that the file reading method leaves behind no redundant DATA occupying valuable code and memory space (aside from the code to load the data.) Whether reading eight bytes or 800 bytes the amount of code to read from a file is the same. So, how does the data get into the file? A little one-time work is required to write the data into the file. Here is the same original code, but instead of POKE'ing the data into memory it writes the data out to the file. Then, the original program can be changed to read the data from the file and POKE that into memory, and so eliminate the DATA statements. 1 REM MSAVEDAT.BAS 5 REM SAVE FILE FROM DATA 10 RESTORE 50 15 OPEN #1,8,0,"H1:MEMORY28.BIN" 20 FOR I=0 TO 7 30 READ D:? #1;D 40 NEXT I 45 CLOSE #1 50 DATA 2,34,27,155,132,130,129,128 There is a question that is not obvious at this point, but will be wedged in here now, because the answer determines the way the code should write data to and read data from the file, and ultimately the direction of an assembly language utility. The question is, “What data is in the file?” Most of the time I work with the Atari800 or Atari++ emulators in Linux to extend the lifespan of the real 8-bit hardware, so here I will detour into Linux for the benefit of tools that show exactly what is in the data file. First of all, the file itself containing the data written for the 8 bytes: -rw-rw-rw- 1 kenjen users 28 Feb 24 18:15 MEMORY28.BIN This file is intended to contain data for 8 bytes, so then why does the directory listing report the file contains 28 bytes? A hex dump utility shows the file contains the following information: 0000 32 9b 33 34 9b 32 37 9b 31 35 35 9b 31 33 32 9b 2.34.27. 155.132. 0010 31 33 30 9b 31 32 39 9b 31 32 38 9b 130.129. 128. The right side of the hex dump provides the explanation. The file contains the text representation (ASCII/ATASCII) of the numeric values. The byte $9B is the ATASCII CHR$(155), the Atari's End Of Line character, which appears after each value. Recall that BASIC prefers to read and write data using text representation of values. The example program uses PRINT (or ?) and INPUT which quietly translate between an internal representation and the text representation. This is BASIC's data abstraction versus the programmer's desire to have BASIC do what is meant, not what is written. The program's (poorly expressed) intent is to store and read bytes of memory. However, BASIC treats the numbers as bytes only within the context of PEEK and POKE instructions. So, then how to get data into the file that is just discrete byte values? Single characters are bytes, so using the CHR$() function will output numeric values as single characters (aka bytes), so that's potentially workable for output. But, then how about reading the bytes? A program using INPUT will still read the file contents as a string which means it will try to read bytes until it reaches an End of Line ($9B) character. So, this is also not a workable solution. Atari BASIC provides a method to write and read a file one byte at a time with the commands PUT and GET. The same example program using PUT instead of PRINT (or ?): 1 REM MSAVEDT0.BAS 5 REM PUT BYTES TO A FILE 10 RESTORE 50 15 OPEN #1,8,0,"H1:MEMORYT0.BIN" 20 FOR I=0 TO 7 30 READ D:PUT #1,D 40 NEXT I 45 CLOSE #1 50 DATA 2,34,27,155,132,130,129,128 The program above results in this file only 8 bytes long: -rw-rw-rw- 1 kenjen users 8 Feb 24 18:52 MEMORYT0.BIN and that file contains the eight values as individual bytes (Linux Hex dump): 0000 02 22 1b 9b 84 82 81 80 ."...... This program uses GET instead of INPUT to retrieve the data to store in memory: 1 REM MLOADDT0.BAS 5 REM GET BYTES FROM FILE 10 OPEN #3,4,0,"H1:MEMORYT0.BIN" 20 FOR I = 0 TO 7 30 GET #1,D:POKE 1536+I,D 40 NEXT I 50 CLOSE #1 So, now we know how using data files can save valuable memory space in BASIC, and how to optimize the file content to the actual bytes as they would be stored in memory. However, a fundamental problem with BASIC remains – the program must read the file data byte by byte during a loop, and BASIC's slow execution speed will turn any significant amount of data into a long and inconvenient wait. In fact, doing device I/O byte by byte in BASIC is slower than reading from DATA statements in memory, so this memory saving solution penalizes the program with even slower data loading. If only there was some kind of machine language solution that could read the bytes from a file as fast as possible. What to do, Toto?!? OSS's BASIC XL provides a precedent with the Bput and Bget commands that write and read arbitrary length blocks of memory directly to and from a file as fast as the device can transfer bytes which is far faster than BASIC's ability to loop for individual bytes. How does BASIC XL manage this? Is it simply reading individual characters in a loop at machine language speed? Or is it doing another trick? It turns out that bulk input and output of bytes is a feature provided by the Atari OS's Centralized I/O (CIO) routines, but the problem is that Atari BASIC does not support all the commands that CIO provides. Gaming Atari's CIO (or not) Many systems of the 8-bit era require the programmer use unique calls to read and write information to each kind of device. Each act of reading a disk file, a cassette file, and user input typed from a keyboard may require calling different entry points in the OS. Likewise, writing to a disk file, a cassette, the screen, or a printer may also require calling different OS routines. Even using two disk drives could require different OS calls. Input/Output programming on these systems can be tedious affairs of device-specific coding for every possible input/output option which deters programmers from even providing choices to users. But the Atari system is different. The Atari includes a standard, modular, reusable input/output model. Simply put, the programmer fills out a common data structure describing the input/output operation and makes a call to one address in the OS. This is a high level abstraction for device input/output. There are no sectors to consider, no serial communications to worry about, no fixed buffers in the system. Everything is a stream of data in or out, read or written on demand. In a very general way this is similar to the unix world's “everything-is-a-file” philosophy. Changing disk file output to screen or printer output requires only a different device/file name. The setup and the call to the OS are the same for all. Considering the Atari's Central I/O (CIO) was written in the late 70s this is nearly magical, and very under-appreciated behavior in an 8-bit computer. Atari CIO The Atari CIO defines a basic set of commands that every handler must be prepared to accept. (Listed in the chart below.) This doesn't necessarily mean every device must do every I/O command. A keyboard cannot do output, and a printer cannot do input. However, the device handler is responsible for sanely managing commands and safely replying that an incompatible command request is not implemented. Command Command Number Description Open 3 Same as BASIC's OPEN command Get Text Record 5 Similar to BASIC's INPUT command Get Characters (Bytes) 7 Similar to BASIC's GET command Put Text Record 9 Similar to BASIC's PRINT command Put Characters (Bytes) 11 Similar to BASIC's PUT command Close 12 Same as BASIC's CLOSE command Status 13 Same as BASIC's STATUS command Command numbers above this range are handler-specific operations. For example, commands 17 and 18 are specific to the screen device (“S:”) to perform graphics DRAWTO and Fill, respectively. Commands from 32 to 38 (and higher) perform various DOS file management functions for the “?” device. Per the list above, everything provided by the base CIO commands appear to correspond to a BASIC language I/O command. Well, almost, but not quite – “Similar” is not the same as “Same”. There is a bit of a disconnect between how BASIC uses these CIO actions, and what the CIO actions can really accomplish. Atari BASIC does not actually use the 5/Get Text Record and 9/Put Text Record. These commands read and write a stream of text characters ending with the Atari End Of Line character which is the Atari OS/CIO's general definition of “Text Record”. Atari BASIC's PRINT and INPUT behaviors are more complicated than the “Text Record” model, because BASIC I/O activity occurs incrementally rather than in a complete record. INPUT can handle multiple variables in one line. PRINT outputs variables and strings as BASIC interprets the values. PRINT also uses semicolons to suppress the end of line, and commas cause tabs/columnar output which are not inherent abilities in the CIO 9/Put Text Record command. So, BASIC is not using the Text Record I/O commands and is managing the I/O by other means. Additionally, notice that the titles for command 7/Get Characters and command 11/Put Characters do not exactly match how BASIC uses those commands. Both commands move bytes – stress the plural: b-y-t-e-S. However, Atari BASIC uses these CIO commands in the most minimal manner to serve as PUT and GET which move only one byte. Since we're looking for a way to read or write an arbitrary number of bytes (plural) these two CIO commands appear to be exactly what we need. The CIO command list above comes from Atari's “BASIC REFERENCE MANUAL” discussion of BASIC's XIO command. This suggests that XIO is capable of exercising these commands. If this is true, then the XIO command could be used to run these CIO operations as CIO intended. That's the theory. The IOCB First, let's learn how CIO operations work. The next section will examine how the XIO command relates to the CIO operations. Earlier it was stated that the programmer fills out a common data structure describing the input/output operation. This data structure is called the Input/Output Control Block (or IOCB). Each of the eight input/output channels has a 16-byte, IOCB dedicated to it at fixed locations in memory starting at $340/832(dec) for channel 0, $350 for channel 1, and so on up to $3B0 for channel 7. So, it is easy to find the IOCB for a channel. Multiply the channel number by 16 and add that to $340. The IOCB tracks the state of I/O operations to the channel. Though the IOCB is 16 bytes long the programmer need only interact with a few of the bytes. Some of the bytes are maintained by the OS, and some are not typically used at all except for special device commands. The values are referred to by their offset from the start of the IOCB: ICCMD: IOCB + $2 This is the CIO command discussed above. ICSTA: IOCB + $3 This is the last error/status of the previously completed CIO command. ICBAL/ICBAH: IOCB + $4 and + $5 This is the 16-bit address (low byte and high byte) of the input or output buffer here. In the case of 3/Open and CIO commands for DOS operations on disk files this buffer is the address of the string for the device/file name. ICBLL/ICBLH: IOCB + $8 and + $9 This is the 16-bit length (low byte, high byte) of the data here. In the case of read and write operations (5, 7, 9, or 11) this is the number of bytes to read in or write out from the buffer. CIO will update this value indicating the number of bytes actually transferred. In the case of 3/Open and commands for DOS operations on disk files this is the length of the device/file name. ICAX1: IOCB + $A Auxiliary byte for the handler. This commonly indicates the Mode for the 3/Open command. CIO will maintain this value here. Meaning of Mode values: For files combine these values for the Mode: 8 - write 4 - read 1 - append For the disk/DOS specifically: 2 - open the directory. For the “S:” device additional values direct how the OS opens graphics mode displays: 16 - Create the text window. 32 - Do not clear screen memory. Finally, For the “E:” handler the value 1 added to the open state (12 + 1 = 13) enables forced read Mode from the screen as if the Return key were held down. ICAX2: IOCB + $B Auxiliary byte for the handler. For the “S:” handler this specifies the Graphics mode to open. (The GRAPHICS numbers that BASIC uses, not ANTIC modes.) For the “?” device value 0 is normal inter-record gaps, and 128 is the faster, short inter-record gaps. Other serial devices may use specific values here. The programmer need not be concerned with much more in most situations. The other bytes in the IOCB are either the responsibility of CIO, or only used for specific device functions. For the sake of reference: ICHID: IOCB + $0 Set by the OS to the index into the handler table when the channel is currently open. If the channel is closed the default value is 255/$FF. ICDNO: IOCB + $1 Set by the OS to the device number when multiple devices of the same kind are in use - e.g. 1 for “D1:”, 2 for “D2:”. ICPTL/ICPTH: IOCB + $6 and + $7 CIO populates this with the jump address for the handler's single-character PUT routine. Atari BASIC uses this as a shortcut to output characters. ICAX3, ICAX4, ICAX5, ICAX6: IOCB + $C through + $F Optional auxiliary bytes for the handler. NOTE and POINT DOS operations use these locations. Atari BASIC's XIO BASIC's XIO command provides a generic interface to access CIO functions that BASIC does not directly implement with a built-in command. The diagram below shows how the XIO values relate to the CIO's IOCB fields: XIO cmdno, #aexp, aexp1, aexp2, filespec ↓ ↓ ↓ ↓ ↓ CIO ICCMD Channel number ICAX1 ICAX2 ICBAL + ICBAH, ICBLL + ICBLH The XIO arguments conveniently match the list of CIO's IOCB values that a programmer should manage. This should mean the XIO command can substitute for any other CIO I/O command (in theory). An important distinction concerning XIO behavior vs the usual CIO expectations is that the 3/Open command uses ICAX1 and ICAX2 values where most other CIO commands don't need to specify those values. Depending on the device and the CIO command the original values set by the 3/Open could be significant and should not be disturbed. However, XIO accepts ICAX1 and ICAX2 values on every command which potentially could allow a later command to overwrite the values set by 3/Open. If ICAX1 and ICAX2 are important for later commands then for safety's sake they should be remembered and restated on subsequent use of XIO. A variety of documentation describing XIO share a common mistake by describing the last argument as always a filespec (the device identifier, and filename if applicable). In reality, the last argument simply provides the data buffer and length for the CIO command. This buffer has variable purpose. It is expected to contain the filespec for 3/Open and DOS-specific file manipulation commands. For most other commands this argument provides the input or output buffer for data. Atari BASIC can use an explicit string or a DIMensioned string for the buffer argument to XIO. The contents of this string does not even matter for some commands – for example, the 18/Fill and 17/Drawto CIO commands for the “S:” device do not use the buffer, so they do not care what value is passed. Below is an example of XIO performing the 18/Fill command for the non-existent device “Q:”. This works, because the real device identifier, “S:”, is only needed when the screen device is opened and the 18/Fill command does not use the buffer. 1 REM XIOFILL.BAS 5 REM DO FILL ON MYTHICAL Q: DEVICE 10 GRAPHICS 5+16 20 COLOR 330 PLOT 70,45:DRAWTO 50,1040 DRAWTO 30,10:POSITION 10,45 50 POKE 765,3 60 XIO 18,#6,0,0,"Q:" 70 GOTO 70 XIO and CIO 11/Put Bytes Assuming the XIO command works as advertized it should give access to the CIO commands 7/Get Bytes and 11/Put Bytes to manage a stream of bytes of arbitrary length. Below is a program using XIO to write a binary file using the 11/Put Bytes command. For the sake of demonstrating the global nature of XIO the other BASIC commands to OPEN and CLOSE the file are also replaced by XIO performing CIO commands 3/Open and 12/Close: 1 REM MSAVEDT2.BAS 5 REM SAVE FILE FROM DATA BY XIO 10 RESTORE 15 DIM D$(8) 20 FOR I=1 TO 8 25 READ D:D$(I)=CHR$(D) 30 NEXT I 35 ICAX1=8:ICAX2=0 39 REM OPEN 40 XIO 3,#1,ICAX1,ICAX2,"H1:MEMORY2.BIN" 44 REM PUT BYTES 45 XIO 11,#1,ICAX1,ICAX2,D$ 49 REM CLOSE 50 XIO 12,#1,ICAX1,ICAX2,"H:" 60 DATA 2,34,27,155,132,130,129,128 Hey! That seemed to work! So, lets take a look at the MEMORY2.BIN file... -rw-r--r-- 1 kenjen users 255 Feb 27 16:58 MEMORY2.BIN What on earth?!? The string is 8 bytes, but the file contains 255 bytes? How weird. Let's see what hexdump in linux says about the contents... 0000 02 22 1b 9b 84 82 81 80 9b 08 00 00 00 00 40 01 ."...... ......@. 0010 00 00 00 00 81 14 00 04 00 19 00 04 04 00 00 00 ........ ........ 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ . . . 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....... The 8 bytes that the program intended to write are there at the beginning of the file where they should be, so that's one good thing. But, the rest of the file appears to be junk out to the length of 255 bytes. It looks like the write started with the designated data string and then kept on going through whatever memory followed the string. Make the following additions to test this theory... 17 DIM E$(26) 18 E$="This should not be output." After running the program again and putting the file through hexdump: 0000 02 22 1b 9b 84 82 81 80 9b 68 69 73 20 73 68 6f ."...... .his sho 0010 75 6c 64 20 6e 6f 74 20 62 65 20 6f 75 74 70 75 uld not be outpu 0020 74 2e 40 08 00 00 00 00 40 01 00 00 00 00 81 14 t.@..... @....... 0030 00 04 00 19 00 04 00 00 00 00 00 00 00 00 00 00 ........ ........ 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ . . . 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....... So, that confirms it. The eight characters from D$ string were output and then followed by whatever happened to be in memory after that string to a total length of 255 bytes. This would suggest a simple bug with the way Atari BASIC passed the output length to CIO, but there's something else in the output that tells us the problem is worse than that. The byte that follows the first eight bytes is $9b, the Atari End of Line character and which occupies the place in the output where the first character of E$ should appear. (Interesting.) That End of Line character is not part of the real data of either of the strings. This must mean that Atari BASIC intentionally output the End of Line after the D$ content as if it were performing PRINT. The odd part is that Atari BASIC accounted for this End of Line by skipping the next actual byte in memory which is the first character of E$. Then Atari BASIC figured out how many bytes remained until it reached 255 bytes and directed output of those bytes from memory. In the Olympics of buggy behavior this is a Track and Field gold medalist. What could have possessed them to do this? Perhaps this could be salvageable. The good part is the intended bytes were output intact at the beginning of the file. If the behavior is simply that Atari BASIC pads additional content, then this is a usable and (barely) tolerable situation for binary file output. So, let's see what happens with more data – such as half a kilobyte simulating an Antic mode 6 or 7 character set: 1 REM MSAVEDT3.BAS 5 REM SAVE LARGE FILE WITH XIO 15 DIM D$(512) 20 FOR I=1 TO 497 STEP 16 25 D$(I)="0123456789ABCDEF" 30 NEXT I 35 ICAX1=8:ICAX2=0 39 REM OPEN 40 XIO 3,#1,ICAX1,ICAX2,"H1:MEMORY3.BIN" 44 REM PUT BYTES 45 XIO 11,#1,ICAX1,ICAX2,D$ 49 REM CLOSE 50 XIO 12,#1,ICAX1,ICAX2,"H:" And after running the program the actual file length is... disappointment again... -rw-r--r-- 1 kenjen users 255 Feb 27 22:14 MEMORY3.BIN One point of good news is the hexdump utility shows the file does contain only the real bytes of the intended string up to 255 characters and that the last byte in the file is not substituted with the End Of Line: 0000 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 01234567 89ABCDEF 0010 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 01234567 89ABCDEF 0020 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 01234567 89ABCDEF . . . 00e0 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 01234567 89ABCDEF 00f0 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 01234567 89ABCDE That nails the coffin shut. Atari BASIC's use of the CIO 11/Put Bytes command is almost completely broken. For some reason Atari BASIC XIO believes the 11/Put Bytes must output a 255 byte, fixed-length block and Atari BASIC doctors the I/O activity to meet this expectation. Next we will look at CIO's 7/Get Bytes command and see if Atari BASIC's support is also broken for this command. XIO and CIO 7/Get Bytes First, let's verify that 7/Get Bytes can at least read the first 8 bytes from the 255 byte binary file: 1 REM MLOADDT.BAS 5 REM READ FILE USING XIO 10 DIM D$(8):D$(8)=" " 15 ICAX1=4:ICAX2=0 19 REM OPEN 20 XIO 3,#1,ICAX1,ICAX2,"H1:MEMORY2.BIN" 24 REM GET BYTES 25 XIO 7,#1,ICAX1,ICAX2,D$ 29 REM CLOSE 30 XIO 12,#1,ICAX1,ICAX2,"H:" 35 FOR I=1 TO 8 40 ? ASC(D$(I,I)), 45 NEXT I:? When it runs BASIC reports: 2 34 27 155 132 130 129 128 It looks like it is reading the data into the string correctly. But, is there anything else going on? Remember Atari BASIC thinks the write has to output 255 bytes. Maybe it is also doing something strange during the read. Lets see if it is reading more than directed: 1 REM MLOADDTX.BAS 5 REM READ FILE USING XIO 10 DIM D$(8):D$(8)=" " 11 DIM E$(255):E$="!":E$(255)="!":E$(2)=E$ 15 ICAX1=4:ICAX2=0 19 REM OPEN 20 XIO 3,#1,ICAX1,ICAX2,"H1:MEMORY2.BIN" 24 REM GET BYTES 25 XIO 7,#1,ICAX1,ICAX2,D$ 29 REM CLOSE 30 XIO 12,#1,ICAX1,ICAX2,"H:" 35 FOR I=1 TO 8 40 ? ASC(D$(I,I)), 45 NEXT I:? 50 ? E$ This is basically the same program with the addition of a large E$ declared and populated entirely with exclamation points, "!". If Atari BASIC reads only the 8 bytes it needs to populate D$ then E$ should be undisturbed and the program will end by displaying 255 uninterrupted exclamation points. But, this is the actual result: Unfortunately, this did not do what is expected or needed. BASIC overwrote E$ with the remaining data from the file. (An interesting bit of trivia is that the first character of E$ is preserved. This character corresponds to the End Of Line that BASIC had inserted in the output.) So, now we know that the CIO 7/Get Bytes command works well enough from Atari BASIC to retrieve short sequences of binary data as long as a buffer of 255 bytes is provided. Now to figure out if it can load longer data. Given the 255 character limit when using 11/Put Bytes the next program will test that limit for reading. First, we need a file that has more than 255 bytes. Recall that the earlier attempt to write 512 bytes actually failed, so here is a (much slower) program to make the 512 byte file as intended: 1 REM MSAVE512.BAS 5 REM WRITE 512 BYTES TO FILE 10 DIM D$(16):D$="0123456789ABCDEF" 15 OPEN #1,8,0,"H1:MEM512.BIN" 20 FOR I=1 TO 32 25 FOR J=1 TO 16 30 D=ASC(D$(J)) 35 PUT #1,D 40 NEXT J 45 NEXT I 50 CLOSE #1 Next is the program to test if Atari BASIC XIO has a 255 byte limit for the 7/Get Bytes command similar to the way it limits 11/Put Bytes: 1 REM MLOAD512.BAS 5 REM READ 512 BYTES FROM FILE 10 DIM D$(512) 15 D$="!":D$(512)="!":D$(2)=D$ 20 ICAX1=4:ICAX2=0 24 REM OPEN 25 XIO 3,#1,ICAX1,ICAX2,"H1:MEM512.BIN" 29 REM GET BYTES 30 XIO 7,#1,ICAX1,ICAX2,D$ 34 REM CLOSE 35 XIO 12,#1,ICAX1,ICAX2,"H:" 40 ? D$ D$ is declared 512 bytes long and filled with exclamation points. Then it attempts to read the 512 bytes from the file into D$. If this works properly the entire contents of D$ should show the "0" to "F" pattern read from the file all the way to the end. But this is what happens, instead: No joy for Atari BASIC's XIO. The result shows the first 255 characters of D$ are populated with the values from the file and the remainder of D$ is the exclamation points set during the program initialization. But, the horror is not over. Recall the MEMORYT0.BIN file created earlier that contains only 8 bytes? This program attempts to read just those 8 bytes from the file: 1 REM MLOAD8.BAS 5 REM READ THE 8 BYTES FROM FILE 10 DIM D$(8) 15 D$="!!!!!!!!" 20 ICAX1=4:ICAX2=0 24 REM OPEN 25 XIO 3,#1,ICAX1,ICAX2,"H1:MEMORYT0.BIN" 29 REM GET BYTES 30 XIO 7,#1,ICAX1,ICAX2,D$ 34 REM CLOSE 35 XIO 12,#1,ICAX1,ICAX2,"H:" 40 ? D$ And this is what happens when the program runs: ERROR- 136 AT LINE 30 The program gets an End Of File error during the XIO performing the 7/Get Bytes request. BASIC XIO expects to read 255 bytes from the file no matter the size of the string buffer supplied, even if the buffer is defined shorter. So, the bottom line is that Atari BASIC XIO has mangled use of the CIO 7/Get Bytes command similar to the 11/Put Bytes command. Here's a summary of what we have left of these CIO command as Atari BASIC has abused them: XIO for 7/Get Bytes is usable for reading binary data from 1 to 255 bytes. If the intended data is shorter than actual file size (of 255 bytes) then Atari BASIC will continue retrieving data from the file and storing it into memory up to that 255 byte maximum length. In order to complete this activity the file must have at least 255 bytes, and in the interest of safety the string buffer accepting the data should be 255 bytes. XIO for 11/Put Bytes is usable to write 1 to 255 bytes to a file with the understanding that anything shorter than 255 bytes will be padded to the length of 255 bytes with junk. In addition, Atari BASIC's capability is further restricted, because it only performs input and output to a a string variable. Saving and loading data to any arbitrary memory location is problematic. This could be circumvented with more involved coding to manipulate a string table entry to point to a specific memory addresses before the read or write. But, again, since BASIC insists on moving 255 bytes at a time, even this method isn't a great solution. We're not going to even bother trying that. In the next episode we'll look at a machine language replacement for XIO and its test program. For my thoughts are not your thoughts, neither are your ways my ways, declares the Lord. For as the heavens are higher than the earth, so are my ways higher than your ways and my thoughts than your thoughts. Isaiah 55:8-9