When I mention QBasic to some people, they immediately think I'm talking about Quick BASIC. The two products, however, are a little different. They were both created by Microsoft but Quick BASIC is basically a super set of QBasic. QBasic has an interpreter and an editor built as one package; I hesitate to call it an IDE since your projects could only use one module at a time. It was also limited in the amount of memory available to the program and the amount of memory available to the editor. I experienced the latter problem only once while creating a game involving viruses and robots (I didn't get around to naming it); the editor just started losing lines of code I had written and was behaving eradically. Eventually, I became frustrated and moved on to other and presumably smaller projects.

QBasic made its first appearance with MS-DOS 5.0. It came with a few example programs and games. One of these games was called Nibble. I love this simple game, even to this day. It's a little similar to games like Centipede, although the game itself is far too simple to make a reasonable comparison. The goal for each level is to gobble up the numbers that appear in random locations. Each time one of those numbers gets consumed, your "snake" grows a little longer. You have to avoid running into the walls of the level, which get more complicated as you progress, and you must not run into yourself. As you attain higher levels, your snake becomes faster and faster. This game was never synchronized with the system clock, so if you play the game on a machine made today, it would move around so quickly as to render the game unplayable.

I have often thought a game like Nibbles would make an excellent game to practice your porting skills on other platforms. It is sufficiently interesting to make the project worthwhile and could be adapted to play well using almost any input device. It could also be rendered using a simple text mode, just like the QBasic version, or you could enhance it in a graphics mode using imagery, vector graphics, etc.

QBasic also introduced the concept of functions and other forms of structured programming. GW-BASIC could only remember and execute your program if each line was prefixed by a number, or right away if you are using instructions in immediate mode. As you added and removed lines from your code, there were a couple of functions to reorder or renumber your line numbers when you ran out of room.

The concept of a function didn't really exist in GW-BASIC; instead, it allowed you to jump to a particular line number using commands like GOTO or GOSUB. The latter was more like a function since you could jump to a specific region of code and then return from that function when the code had finished. GW-BASIC also supported one line functions which were handy for calculations. Although QBasic could still use line numbers, it encouraged the use of named labels for functions instead. Despite my work with Amiga's BASIC, I still preferred the old way since I had been doing it for so long. It took me a while to adjust to the new program structure at first, so I purchased a new QBasic book after upgrading and essentially dove in head first.

Interrupts would become increasingly important for me in the future, but at this time I knew little about them. QBasic had no direct interface for handling interrupts, but it could handle interrupts used by the system's timer:

ON TIMER(n) GOSUB MySubRoutine

Having no functionality to manipulate interrupts meant there were no functions to gather information about input devices like the mouse. Despite this seemingly major failing, all was not lost. While it could not handle input from the mouse directly, you could make use of a machine code sub-routine which could get the information you needed, like position and button states. You could use techniques like this to gather information from other devices.

QBasic also introduced me to one of the greatest time saving features ever created: the debugger. A debugger can be a separate program or feature within an IDE which allows you to trace through your program and examine variables and addressable data as the software executes. One of the core features of a debugger would be the ability to set a break-point at a specific addressable location that corresponds to a precise line within your source code. Before debugging, I was tracing through my program by hand and using PRINT commands to dump the contents of a variable. Even today, there are professional programmers who don't use a debugger, either by choice or lack thereof, and choose to examine how there software operates by sending information to a log file or an output stream of some sort.

Categories: PC, Programming, Reflections
No Comments »

I first discovered this little gem while poking around on my Tandy 1000 RL computer back in 1991. Because I was familiar with various versions of BASIC already, I was able to fire it up and immediately begin writing fairly simple applications. However, there were differences to Atari's version of BASIC, and no discernable way to figure that out without a book or some other documentation. I poked around on a few of my favourite Bulletin Board Systems (BBS) and found a small cache of programs written in GW-BASIC. I downloaded each of them, spending all of my download credits in the process. I poured over them line by line and found myself having more questions than answers.

Many new programmers today expect there to be some sort of documentation available when they learn a new technology. It's an expectation that has evolved over the years. Today, it would be practically unheard of if you couldn't find some resource describing the software on the Internet, or some blurb in a book, or even bundled with the product. However, when I started looking for a book on GW-BASIC (version 3.23 to be exact), it was darn near impossible. The people I spoke with had no understanding of programming, let alone a specific language. The computer sections in the store were spartan compared to the sections you find in stores today. In fact, several years later, I still needed to special order the books I wanted through the book store; even today, I usually order my titles through Amazon since a store like Indigo usually doesn't have them in stock.

I eventually wandered into a local computer store - I was attracted by a demo of Wing Commander II playing on one of their expensive new 486 machines, so I went in to ask them if they knew where I could get my hands on some material. I spoke with the owner and he seemed to recall seeing a book for BASIC in the back of the store. He left for a couple of minutes and returned with two books under his arm. One was for the exact version of GW-BASIC I was looking for and the other was a compatible book for MS-DOS. I was ecstatic and I nearly fainted when he gave them to me for free. I don't remember what I said to the man that day, but I'm sure it wasn't adequate.

I wrote so many programs in that environment. I think I still have a few of them today on floppy diskette. They were simple at first, like simple word games such as hangman. However, it wasn't long before I discovered how to increase the resolution and colour depth and draw simple graphics. I had already written code for the Atari which made use of pixel plotting routines or simple geometric shapes. There were pre-canned routines the Atari provided for drawing shapes, along with a few parameters for style, colour, and shape. GW-BASIC was similar but provided several more commands and options. With a smaller font and a higher resolution, debugging within BASIC became more feasible. I still couldn't scroll, but at least I could view a larger portion of the code on the screen.

Sound was also possible through the PLAY command, or if you were so inclined, through a custom routine written in assembly language which could be written to generate all sorts of sounds like noise or even speech. I had converted several songs using music sheets and converted them to their GW-BASIC equivalent. Not terribly exciting, but it did make for some creative demos which seemed to impress onlookers.

Some of the more interesting projects involved controlling external devices like printers. I must have programmed my software to use every conceivable option available through my Star NX 1000 II dot-matrix printer. I could instruct it to use standard type effects like bold and italics when printing text, but I could also program it to print graphical data like images and shapes. I even created printed graphics for the Mandel Brot set by rendering the fractal to my printer instead of the screen, one pixel at a time.

Perhaps the most interesting device was a robotic arm which was controlled through a series of commands dispatched through the parallel port. I didn't have access to such a device at home but my school eventually purchased one, so one of the teachers decided to create a contest for students. Whoever could program the robotic arm first, would win a special prize. The task was to pick up a piece of chalk and draw a picture consisting of at least four shapes. It was a fun contest and I walked away with a pass which granted me as much lab time as I wanted.

Before I upgraded to a new machine and moved to a new version of MS-DOS, I was intimately familiar with every command in that book, even the more obscure commands like CHAIN and PCOPY. Although, the really obscure commands were still a mystery. I didn't know you could actually write assembly language routines in GW-BASIC using DEF USR and USR commands until sometime later.

Categories: PC, Programming, Reflections, Software
No Comments »

At around the same time I discovered DeskMate, the Amiga OS made its entry into the market as the aptly named operating system for the Amiga computer. Until recently, I had never owned an Amiga machine. I spent a fair amount of time with friends mucking around with various bits of software and hardware. One of my favourite combinations was the NewTek Video Toaster which was a powerful video editing software kit. You could do all sorts of video effects and overlays due to a technology called genlock. Genlock allowed you to synchronize different signals so that their sources become coincident, which made it possible for you to place blackout bar over your sister's face just for kicks.It also sported several hardware and software features which I had never seen before. Real hardware multi-tasking was available on the Amiga 1000, but we mostly used the Amiga 500 which wasn't as sophisticated in the same areas but provided terrific hardware for games. A friend of mine had a massive collection of software which were all archived in a custom-built diskette storage case made of wood and decaled with the Amiga logo. When we weren't playing games and slogging through his massive collection of software, we were programming in Amiga BASIC or the occasional dip into the Lattice C compiler. I didn't really understand the compiler since it was my first experience with a compiler, and it's really difficult to learn a new programming technology when you have no means to experiment in your free time and no books available to read. At the time, I really wasn't that interested anyway because I really connected with the structured BASIC available on the Amiga. It was a technology I could more readily understand because of my experience with Atari's BASIC and Tandy's GW-BASIC.

The Amiga OS made a strong impression on me as to what I was missing when I used a personal computer running DOS or Windows. There really wasn't any comparison at the time. I remember feeling a bit underwhelmed whenever I switched my machine on after returning from a night of Amiga fun. However, after a few hours I was back into full swing. I'm not sure if I came to the realization that the machine I owned presented me with all sorts of different puzzles and tantalizing delights, but I do remember feeling like there was so much more to explore and learn. I believe that is what kept me from begging my folk's for an Amiga every time I returned home. Although, I might have asked once or twice...

Categories: Amiga, Reflections, Software
No Comments »

Despite Tandy's DeskMate application which tried to handle a number of disk and application related functions, MS-DOS (Microsoft Disk Operating System) was the actual operating system on which Deskmate needed to operate. I had experience with an earlier version of Microsoft's DOS which I used at school; I believe the versions were 2.0 and 1.25. Unlike today where hard drives are common place and often taken for granted, the machines in the lab could only boot by way of 5 1/4" floppy diskettes which contained the operating system. I believe the Tandy computer came with MS-DOS 3.42 and it was pre-installed on the hard drive. This was so much better than booting from a floppy, and I quickly assimilated as many commands as I could, since the school never gave me the time I wanted on the machine or the resources. Even with the aid of a text book, there were a few commands which took me a while to grasp, like COMMAND.COM or DEBUG.COM. My understanding of these wouldn't completely solidify until I started programming in lower level languages like C and assembly language. I was also introduced to Microsoft's shell scripts which they called Batch files. With the addition of extra software on the system, these scripts could actually become fairly sophisticated. Before I moved on to greener pastures and more flexible user interfaces, my system had sophisticated menus and launchers which helped my family out when they wanted to use the machine (it wasn't often, but it did happen).

Version 5 was a much more refined operating system and contained powerful commands and programs like QBasic. It also featured a memory manager which allowed software to access all of that wonderful new memory that you may have been fortunate enough to acquire. Although it was included in MS-DOS Version 4, I believe the DOSSHELL command's popularity spiked in Version 5. This was a program which was intended as a graphical replacement to the dull COMMAND.COM shell. It introduced a feature called task swapping which allowed you to load more than one program but only run one of them at a time; unlike multitasking which appears to run more than one program at the same time. Also, DOSSHELL could not load more programs than your memory would allow since it did not have a paging mechanism. Naturally, all of these benefits conflicted with the new versions of Windows which did exactly the same thing only better, and was soon relegated to a supplemental disk in future releases before being dropped entirely.

Version 6 introduced the much feared DELTREE command. DELTREE was a command which could recursively remove directories and files; it was so feared because new or untrained users would presumably delete their entire operating system accidently. If this was indeed a problem, I think they should have modified the program to make it more difficult to accidently trash your operating system by adding extra prompts and warnings for example, since it is a very useful command in some circumstances. Despite its notoriety, it was a fairly simple command as far as software goes, and the void was soon filled by programmers who released new versions on the Internet which did exactly the same thing only better; I wrote a utility to replace it as well but mine displayed a user interface if you specified the right command option.

Categories: DOS, Reflections, Software
No Comments »

There are two sides to every coin. Game development can be hard or game development can be easy. These are relative terms, of course. Just because writing a game can be easy, doesn't mean your grandmother could do it (although I wouldn't hedge any bets, especially with mine). Personally, I think writing any finished application is an achievement for any programmer working alone. With the help of my colleagues, I have produced several applications which have made it onto store shelves, but I won't take the credit since my part was just one piece to the puzzle. Of course, some applications cannot be programmed by just one person. Oh sure, one software developer could work for years or decades to achieve their goal, but who has the time and talent required to design and engineer something as complex as Metroid Prime, Photoshop, or the KDE Desktop on their own? It just doesn't happen in the real world because life inevitably steps in and takes over.

However, all is not lost for the eager programmer setting out to create a game. It all boils down to following a few simple rules and having a few good resources available. For the next couple of weeks, we'll look at some of the tricks of the trade and present a list of books which I have found very useful while exploring game development. So, without further procrastination, let's dive right in to our first topic.

Game Design - The key difference between finishing a game and an unfinished hack is managing expectations. Yes, we would all love to design and build a game like Halo, but that's not terribly likely and will almost certainly lead to failure. Instead, try and reduce the scope of the project by carefully choosing the characteristics of a game you wish to include. Care must be taken to use only those features which are absolutlely necessary. You should spell out how you want your game to work, what features need to be written, and any third party tools you plan to use which can save you time. In essence, you need to write a bit of documentation. Yes, I know, documentation is a bore and some of you may find it difficult. But you don't need to write a best-selling novel, just outline what you want to do and how you want it to work.

By translating those exciting images and ideas you have into something concrete, you'll be able to assess your goals and overall design much more easily. It also makes your game much easier to digest for other people. If you wanted to hire an artist, for example, you would need to describe the concept in fragmented conversations over the phone or via the Internet. It would make the job of the artist so much easier if you had the design for the game already completed. In fact, most artists (the smart ones anyway) won't accept a contract without a working game design in place. Without this document, you would be unable to tell the artist which assets need to be produced now and what can wait until later. If you know all of the work which must be completed before the artist draws a single pixel, he/she will be able to commit to a schedule and a price.

Over the last few years, several good books have been written on designing (and managing) game development projects. However, these books tend to focus on many details which are only relevant or important to large scale projects. Naturally, there are excerpts which you will find useful, but don't get overwhelmed by the sheer volume of information. Generally, you don't need to concern yourself with all of those details; the object of this lesson is to finish a fun game you want to create in your spare time. If followed some of those books to the letter, it would take ages to complete a project and you may find your interest in the project begin to drift after a year or two.

Project Management - When you are creating a game by yourself and for free, I don't recommend setting a schedule. Schedules are for people and companies who must release the game in a timely manner because their economic futures depend on it. The bottom line for you and me, however, is that schedules aren't very accomodating for new game developers and they aren't very much fun when you're ten weeks behind your target date. If you don't need to release a game in six months, then why would you care that your line drawing algorithm is taking twice as long to craft as expected?

On the other hand, you could always use the project as a way to enhance your project management skills, which is admirable but you may find the accuracy of your estimates vary considerably. This is partly due to life, who once again chooses to interfere with your project. As a programmer at work, I can count on having at least five or six hours a day for solid work. At home, my free time will vary wildly. If you only consider the cost (in time units) and forget about dates, then you may find your estimates more useful. If you really insist on reading a book to brush up, then I recommed:

• Joel Spolsky's book entitled Joel on Software. It's a compilation of articles for novice program and projects managers. It has a number of good practical tips which can benefit almost any software project, including projects done by the hobbyist.

Categories: Game Development, Programming, Reflections
No Comments »

I first experienced this desktop software while using a Tandy 1000 RL machine which my father decided to go out and buy at the last minute on Christmas Eve, so I wouldn't be disappointed. It was a nifty little machine with a 20 MB hard drive, built-in audio, 3 1/2-inch drive, and virtually no expansion capabilities what-so-ever. It had one ISA bus; everything else was pretty much hardwired into the system. It did have serial and parallel ports which allowed you to plug-in a MODEM or printer which certainly helped later on. After booting it up, I discovered the manufacturer had installed DeskMate onto a read-only partition on the harddrive. Much to my dismay, they had pre-configured it at the factory. When I needed to reinstall the system sometime later, DeskMate never functioned like it did out of the box. For some reason, and I have yet to figure out, it was about two or three times slower.

When compared against other Windowing environments at the time, such as Windows 2.X or even Windows 3.X, it could hold its own. The major feature missing was network support, but even Microsoft products didn't support that until Windows 3.11.Until DeskMate walked into my life, I had never experienced a visual desktop before. It was an exciting experience and I wanted to explore every nook and cranny. First and foremost, I wanted to write software for it, so I phoned the number provided by Tandy Corporation in our manual. They said I needed to purchase the software development kit (SDK) and a suitable compiler. At the time, I didn't know what a compiler was so I thanked the person and went about calling local stores and asking them questions. After a bit of research I discovered that the SDK was expensive and so was the compiler, which according to the sales person was a "program to make other programs." They were probably brushing me off since I was basically a kid (or a young punk) at the time. I know they were at least a few hundred dollars a piece which put them out of my price range. In the end, I'm happy I didn't invest the money in the SDK since I have since learned it wasn't very good. Apparently, many companies had to write much of their own code in order to do anything useful. I would still like to check out the API, so until then, I reserve final judgement.

DeskMate had all sorts of small applications available. It had all of the standard applications like a word processor, simple database, spreadsheet, drawing application, telecommunications software, etc. These applications are extremely simplistic compared to what is available today; although the word processor did have spell checking and even a thesaurus and dictionary (purchased separately), and the database was functional enough to be useful. It even installed a personal diary program, which was very well done. It also came with a variety of useful on-screen tutorials to help you learn the software as you use it. Microsoft Windows didn't have anything that helpful until Windows 95.

Categories: Reflections, Retro, Software
1 Comment »

I was exposed to this piece of software at about the same time I was learning how to send graphical data to our printer. I didn't really appreciate the complexity of this software until much later. My father was the one who was the real expert, but I also fired it up to help with my homework and to calculate some values I needed for a few of the games I was writing. It was the first time I had ever seen a spread sheet program, even though it appeared on the Apple II a couple of years earlier. Financially, the program was a boon for Apple and almost single-handedly lead to the mass adoption of the system. Financially, I'm not sure how it fared on the Atari since it took the company about a year to port it to other systems, but it's common to see systems for sale on eBay which are being sold with a few games, miscellaneous pieces of software, and VisiCALC.This spread sheet software introduced me to a world where software can be used for something other than playing games. Although, let's face it, they're not as much fun or practical these days. I think I absorbed that idea pretty well for a boy who hadn't quite entered his teenage years. I started to think about how I could write programs for my father which would help him with his financial chores. I don't think I produced anything terribly useful, but I did write a few small calculator programs which could do a few interesting calculations involving trigonometry and simple algebra. I hadn't yet discovered decimal encoding techniques like Binary Coded Decimal (BCD), but I eventually learned that Atari used BCD routines in its library implementation which BASIC used extensively. VisiCALC was able to handle floating point values efficiently because it was written in assembly language and the 6502 processor has floating point instructions available. The programmers used these instructions directly instead of using Atari's library, which had a very positive impact on performance.

For more information on the development of VisiCALC, there are a couple of sources on the Internet available including one from the creators themselves.

Categories: Atari 8-bit, Reflections, Software
No Comments »

My experience using BASIC is something I cannot easily put into words. I had never been exposed to programming before, so at first I had a hard time understanding the concept. I started out slowly, playing around with some simple commands which were described in various issues of ANTIC magazine.

Actually, my first experiments were much simpler, consisting of just a single command being given to the interpreter. I loved being able to control the color of my background or make a bunch of erratic and tuneless beeping sounds through our television speaker. For the first time, I was in control of the machine, even if all the machine did was squeak and change colors. I didn't learn about how the interpreter used line numbers until my father picked up a copy of Atari BASIC by Albrecht, Finkel, and Brown. It was during my sessions with this book that I also learned about control flow statements, looping, data types, and loads of new commands. It still took me a while before I learned how to save my creations to disk, but it was too late to go back by then. The bait had already been taken, and it wasn't long before my parent's saw what was happening: I was hooked and I was going to need funding for my new hobby.

For the most part, I learned most of my Atari BASIC programming skills through my father's subscription to ANTIC. This magazine was devoted to the Atari 400/800 series of computers which were popular in the early to mid-1980s. Another popular magazine at the time was A.N.A.L.O.G., but I didn't have access to as many of them as I would have liked. I enjoyed the latter because it had much more diverse and complex programming examples and articles. When I got my hands on our first copy, I wasn't even pausing to read most of the articles, I just brought it straight to the computer and began entering the source code in by hand. Sometimes the process took hours and my code was often marred by spelling mistakes and missing commands. I eventually learned these mistakes were called bugs by people in the software world. Tracing through these programs taught me a lot about programming and debugging. Mostly, it taught me to be careful while typing, and began to practice my typing skills using another software program designed for this purpose. To this day, however, I am mostly a 3:4 finger typist; three being the typical number of fingers I use for my left hand, and four being the perfect number for my right.

My father eventually purchased a dot-matrix printer for the system. It was a Star NX-1000 II, and I absolutely adored this printer. I quickly learned how to use it in BASIC and began printing reams upon reams of code. I enjoyed debugging and enhancing my programs using the printed form. It was an excellent way to get a handle on the whole problem, since the environment in the interpreter prevented you from seeing the whole picture easily. The font was just too large and the software did not have the ability to manually scroll the view. In fact, the concept of a window wouldn't be realized on desktop computers until a few years later. In order to examine a block of code, you needed to continually LIST the sections in chunks or just dump the whole thing at once and wait for the area you were interested in to come into view. The continuously scrolling source code was slow enough you could track it with your eyes, and once you saw the region of code you wanted, pressing the break key would stop the process.

Another great feature of the Atari's BASIC language was the ability to examine and modify specific bytes in memory. At the time, I don't think I fully understood the concept of a memory address, at least not the way I understand it now. It was more abstract for me than other concepts. I knew that writing certain integer values into locations identified by other integer values allowed me to play music and control the colors of fonts and backgrounds, but I didn't associate these number values to a physical address in the machine. In fact, I'm not sure I even truly understood what memory did, other than the typical high-level rationalization: if you buy more RAM it will allow your computer to play this game or use that piece of hardware. I generally understood memory to be a good thing. The more you had, the better off you were.

It wasn't until I started programming the Commodore 64 (C64) with a friend of mine that I began to understand its function and organization. A big part of that understanding came from a device called the Super Snapshot cartridge which could plug into a port on the Commodore computer. This miraculous device had a number of cool features, and one of those features allowed the user to interrupt a game (or whatever) and examine/modify the contents of RAM and then return as if nothing had happened. Initially, we used this device to cheat on games by changing the number of lives, strength, loot, whatever. All we needed to do was isolate the byte responsible for tracking these attributes in memory, modify the contents of the variable at that address, and voila! We were invincible, we could crush any opponent, or we could buy any item. Life was good. I believe the manual for the Super Snapshot explained a number of details about memory and how it was organized. This served as a great stepping stone for my next foray into the world of Atari memory.

The next big advance for me came after reading the book: Mapping the Atari by Ian Chadwick. It explained what all of those numbers meant and how they were used by the Atari. I was enthralled and began to experiment with earnest. Incidently, the commands I was using to read and write values to and from memory were called PEEK and POKE respectively. Loads of fun can be had with these commands and that great little book. As it turns out, this book became even more useful while dabbling with assembly language years later on the Atari.

Categories: Atari 8-bit, Programming, Reflections, Retro
1 Comment »

Atari DOS - This operating system was the first operating system I was exposed to during my youth, and the 2.x series was the most popular in my household. The operating system was loaded off of 5 1/4" double-sided double-density diskettes which usually offered about 320 KBs of storage space after formatting, although other disk formats offered less or more storage depending on density. The operating system did little more than manage disk functions such as formatting diskettes or erasing and copying files, hence the full name "Disk Operating System." It could, however, be used to boot strap the cartridge or run a binary program at an arbitrary address after it was loaded. The DOS was mostly used to access files and programs stored on floppy diskette. It provided a File Management System (FMS) which needed to remain in memory in order to provide disk access functionality to other programs.

Believe it or not, there are still hardware/software hobbyists and professionals creating products to use with your Atari. I have a software solution called A.P.E. which allows me to use my computer as a virtual disk drive, printer, modem, etc. It's absolutely fantastic and accelerates software loading to a fraction of the time it took before. There are also products which allow you to connect a hard drive through the cartridge port, or even USB devices!

A.P.E. stands for Atari Peripheral Emulator and is an essential piece of software for any Atari user. Until a few years ago, I was forced to play my Atari games via an emulator or on the Real McCoy using the terribly slow, but wonderfully nostalgic floppy disk drive. I don't think it's necessary to mention how painful it was waiting for the disk operating system to load, and then waiting for the actual game to load, and then waiting for the game to save, and then waiting for the game to load the second disk... you get the idea. There was a lot of waiting, and somehow I mangaged to do it without batting an eye lash in 1984.

First and foremost, A.P.E.'s biggest strength comes in the form of its disk drive emulation software. In order to get it to work, you must own a working Atari computer. The author probably explains exactly which Atari computers are compatible somewhere on his website, but I can tell you for sure that the Atari 800 XL and Atari 400 computers work like a charm. Simply connect your Atari computer to your personal computer using a custom SIO interface cable. The cable can be purchased through the web site, or you can even make your own if you're so inclined. Install the APE software on a computer, configure it, select a disk image, and boot up your Atari machine. Voila! The software you selected will boot in record time. Plus, your personal computer now acts as a virtual hard drive for your Atari! You can put away those floppy diskettes, all of your games and applications can be saved and archived as an "ATR" file, which A.P.E. can understand.

Categories: Atari 8-bit, Reflections, Retro, Software
No Comments »