Introduction
The Atari 8-bit computers have astounding capabilities considering the chips were first manufactured for development systems in 1978 and the home computers went on sale to the public in 1979. The computers are the evolutionary successor to the Atari 2600 video game system, and the ancestor of the Amiga. Some concepts from the 2600 apply to the Atari 8-bits, and understanding the Ataris provides insight into the Amiga's custom hardware features.
The 2600 requires a programming methodology that would drive most people nuts. The machine has 128 bytes of RAM. (BYTES, not KILOBYTES.) There is no memory for graphics. Everything displayed on the screen has to be written into the graphics chip's registers by the program as the screen is drawn. The game logic is slave to tight timing cycles. Between the programming difficulty, and the more primitive graphics capabilities, Atari 2600 games tend to be simple. In spite of this there are mind-blowing games on the 2600. Respect is due the person who can write any kind of functional game for the 2600.
The Atari computers began design as the advanced replacement for the 2600 video game system. Almost as soon as design started the focus shifted from a video game to making a personal computer with superior graphics ability. Some of the resulting machines' graphics features would not be bested until the Amiga appeared.
Programming the Atari computers is considerably easier than the 2600. In fact, by comparison, the Atari computers allow downright lazy coding. The graphics chips generate the playfield text and graphics and Player/Missile overlay graphics without direct CPU intervention. The program simply arranges the data in memory and tells the graphics hardware where to find everything. An Atari computer game is free to spend more time on complex game logic.
The Atari systems were popular in their time, selling several million units, and around the 1982 to 1983 years they were very popular targets for software developers. But, everything was not ported to all computers. Each computer model had games written for them that may have been ported to only a limited number of other systems that possibly did not include the Ataris, or may not have been ported to any other computer at all.
Porting other systems games to the Atari is an entertaining and educational experience. The programmer learns how other computers worked, devises ways the Atari can represent the same/similar screen display using a different graphics architecture, and gives one an appreciation for how much can be done with tiny amounts of memory.
Overview Of The Atari Hardware
The first part of porting is knowing what you're porting to, and so understand how to fit the Atari's abilities into another computer's features. Some things another computer can do may not be easily portable to the Atari, and at other times you may choose to enhance something on the Atari beyond what the original platform can do. Do not expect, or even try to make an Atari game look exactly like the game on another system. Atari graphics features have their own strengths and weaknesses, so try to fit game behavior into the Atari's style. Atari graphics are originally intended for NTSC color television, so some features must look different on the video standards used on other computers (PAL, SECAM, etc.). An overview of Atari features:
-
1.79 MHz 6502 processor. This is one of the fastest 6502 computers released. Most other systems work at 1MHz.
-
Custom character set. The Atari's text modes can render the imagery for text characters from anywhere in memory. The images for characters can be changed simply by pointing to different memory.
-
6 text modes.
- 2 modes of 40 column text based on the "high resolution" pixels. This allows monochrome text, plus a border color. One mode is 8 scan lines tall which is the standard text display on the Atari. The other is infrequently used and is 10 scan lines tall allowing for lower case descenders if an appropriate custom character set is supplied.
- 2 modes of 20 column text based on the "medium resolution" pixels (1 or 2 scan lines tall). This allows 5 colors including the background. Each character is a single color.
- 2 modes of 40 column text based on the "medium resolution" pixels (1 or 2 scan lines tall). This allows up to 5 colors including the background with 4 colors (3 plus the background) within a single character.
-
8 graphics modes.
- color modes range from very low resolution at 40 pixels across the screen, to "medium resolution" at 160 pixels across the screen.
- "high resolution" mode is 320 pixels across the screen allowing monochrome graphics (2 shades of the same color)
-
Mixing graphics modes on the screen. The display is generated by the ANTIC graphics chip executing a "Display List" of instructions which specifies what kind of text or graphics to display for each horizontal line on the screen. No CPU intervention is required for mixing graphics and text modes on the screen.
-
Display List Interrupt. The Display List instructions can trigger a machine language routine when the display reaches that line of the display. Typical use is to change the value of color registers allowing more colors on screen, and changing the Player/Missile graphics to new positions.
-
Vertical Blank Interrupt. The end of the Display List at the bottom of the screen triggers a system machine language routine that can optionally transfer to a custom routine supplied by the program.
-
Text/Graphics memory indirection. Any part of the Atari computer's memory map may be displayed as text/graphics for each line in the Display List. Memory used for text/graphics does not need to be contiguous from one line to the next.
-
Overscan. The Atari display can extend vertically or horizontally beyond the edges of the typical NTSC TV. (Mileage may vary on modern LCD screens or emulators.) Vertical overscan is done with the Display List instructions. Horizontal overscan is a register setting in the graphics chip. Horizontal overscan results in the graphics chip displaying more text characters or graphics pixels on the horizontal line than described earlier for normal graphics behavior.
-
Player/Missile graphics
- Four, 8-bit wide "Players" with separate color registers from the text/graphics colors. (2 colors - the register color and "transparent")
- Four, 2-bit wide "Missiles" using the associated Players' colors, or a separate playfield color as a "Fifth Player".
- Bits rendered as 1, 2, or 4 medium resolution pixels.
- Full collision detection of Player/Missiles to each other and to each specific color of playfield pixel.
- Variable priority allowing Player/Missiles to be in front of or behind playfield text/graphics.
- Priority settings can mix the colors of pairs of Players allowing multi-colored Players.
- Player/Missiles coordinates are independent of the playfield and can appear naturally in the overscan areas.
-
128 color palette. 256 colors in some color interpretation modes. Depending on graphics mode and color interpretation mode 2, 4, 5, 9, or 16 colors can be used for the playfield text/graphics.
-
Full Color indirection. In most of the graphics modes the normal color interpretation allows all the colors on the screen to be any one of the 128 colors in the palette via a hardware register assigned to that color. Changing the value of the color register changes all the pixels in the screen using that color register.
-
Four color interpretation modes. The 14 text and graphics modes can be rendered using one of four kinds of color interpretation. In theory, this makes 56 graphics modes possible. However, the last three color interpretation modes (GTIA modes) work best in conjunction with certain graphics modes, so not all 56 combinations are practical.
- Normal color interpretation utilizing color indirection.
- 3 GTIA modes: 16 shades of one base color. Up to 9 colors using color indirection. 16 colors all using the same brightness.
-
An easy but infrequently used feature is color mixing between Player/Missile pixels and playfield pixels engaged by specific priority controls. This can create up to 23 colors in normal color interpretation mode and up to 38 colors in the GTIA color interpretation modes.
-
Fine scrolling.
- Up to 16 pixels horizontally (4 normal text characters) and up to 16 scan lines vertically.
- Hardware assisted coarse scrolling. The Display List can contain a pointer to the memory to use for graphics. "Moving" a line of text or graphics on screen requires only updating the pointer to memory instead of redrawing the entire line of data in memory.
-
Four channel sound with variable noise waveforms.
-
Two (or four on the Atari 400/800) game controller ports provide inputs separate from the keyboard. (Digital joysticks, potentiometers, and light pen input.)
-
Option, Select, Start buttons read separately from the keyboard and game controllers.
Whew! That's a lot, and it still leaves out considerable detail. People have written entire books about this.
Atari Programming Environments
The next consideration for the Atari as the porting target is understanding how the chosen language affects the scope of the available feature on the Atari. 6502 Assembly language provides total control of the machine language program and offers complete use of all the Atari's features. If it can be done on the Atari, it can be done in Assembly.
Atari BASIC -- It is easy to understand and allows for quickly testing code changes, since it is an interpreted language. I use BASIC for new projects to prototype a program, so I can get logic in order and some semblance of the graphics working before starting in Assembly language. If the game for another computer is written in BASIC, then converting to Atari BASIC is the best practical first step. However, operating in Atari BASIC limits the hardware features possible. Some Atari graphics features require use of machine language.
If you are determined to work with BASIC, then I recommend using something other than Atari BASIC. My favorite is OSS BASIC XL (or XE) which is compatible with Atari BASIC, but considerably faster, and has built-in support for Player/Missile graphics that Atari BASIC does not have. However, no matter what you do any kind of interpreted BASIC is far, far slower than Assembly language. That's reason enough to avoid Atari BASIC.
There are versions of BASIC, and other languages that can be compiled into machine language. Often the results are as good as working in Assembly, though sometimes there can still be compromises or language-specific gymnastics when working directly with Atari hardware features. I do not have a lot of experience with these languages. BASIC and Assembly cover all the bases for me.
Things You Can Do In Atari BASIC
The following is a list of Atari features that a BASIC program can use. Assembly is not needed to set up the features, though with BASIC the feature's use may be limited.
-
Redefined custom character sets
-
Create a Display List mixing text and graphics modes on the same display.
-
Overscan. Surprisingly easy, but not often used. Build a Display List using more scan lines for vertical overscan. Change the graphics chip's horizontal width register. The change in display width does make it more difficult to print or plot graphics as the wide display does not match the expectations of the Operating System's graphics routines.
-
Hardware assisted coarse scrolling. Well-planned use of the Display List and pointers to screen memory can make coarse scrolling the display, or a limited set of lines on the display appear to move together as one solid object without tearing.
-
Player/Missile graphics - Loading and positioning an image for Player/Missile graphics is easy in BASIC. Animating an image is a harder problem. OSS BASIC XL has built-in commands for vertically moving Player missile graphics. The other common method is to use Atari BASIC/BASIC XL's unique string capabilities to assign a string to Player/Missile memory and manipulate the string.
-
Color mixing between playfield and Player/Missile pixel colors.
-
Sound. Atari BASIC includes commands to play sounds. Complicated music is more difficult due to the execution speed of BASIC.
-
And trivial things: reading the keyboard, game controllers, and the Option, Select, Start keys.
Considering Other Platforms
Porting the first-person shooter Counter-Strike:Global Offensive to the Atari is an admirable goal which would probably never reach acceptable results within a person's lifetime. A better pool of potential games to port comes from other retro platforms sold around the same time as the Atari, since they would have reasonably similar capabilities as the Atari.
Numerous kinds of computers were sold commercially during the era of the Atari, and for the sake of space I cannot discuss every single one. Many systems have become obscured in history to the point it is difficult to find programs or source code listings. This is not to say they are unsuitable as a source for porting. It just means more effort will be needed to collect accurate descriptions of how those computer's function. If you do find an interesting game and the source for it on a less popular computer, then thumbs up for your team and have a ball with it. Pick and choose the systems and games to port as it suits you; be the first to port something unique, or be the 9,547th person to produce yet another version of Space Invaders.
A reasonably concise list of the commonly available home computers marketed in the US during the 1977 to 1983 timeframe: Pet, TRS-80, Apple II, TRS Color Computer, VIC-20, TI-99/4A, Commodore 64. I'm not as familiar with many non-US brands. Based on the documentation availability and YouTube reviews of systems and games here is my short list of non-US systems that seem to be popular: BBC MICRO, Acorn Atom, Electron, Oric 1, Sinclair ZX81, ZX Spectrum, Dragon 32.
Other Platforms Limitations
Other platforms from the Atari's era have varying capabilities. SOME are extremely limited. SOME are better than others. SOME may be limited in most respects, but have a feature the Atari can't exactly duplicate (e.g. 64 column text, Color maps.) SOME could be improved with optional add-ons that will not be considered here. The POSSIBLE, lower-spec options:
-
Limited graphics modes. Perhaps even no graphics beyond the text display.
-
If multiple graphics modes are possible the hardware cannot easily mix graphics modes, or mix text with graphics on screen. Where this does occur it is usually done by simply drawing text on a graphics display.
-
Limited color palette: 2, 4, 8, or 16 colors. Either no, or limited color indirection supported.
-
Color may be implemented by a separate color map that specifies the color used in a character-sized tile. The Atari doesn't have a color map feature, so this is one of the harder objectives to work around.
-
Fixed location in memory for the text/graphics screen.
-
Fine scrolling is usually not supported beyond physically redrawing the entire screen, and coarse scrolling requires redrawing the screen.
-
No sound or limited sound.
Common Conflicts Due To Atari-Specifics
Some conflicts are nearly universal between differing platforms. Many revolve around text character representation. While most computers are based on an ASCII layout for A-Z, 0-9, and basic symbols, each platform adds unique usage for other values. Possibilities include:
-
No lower case support.
-
ASCII control character values are not treated as such.
-
Custom graphics characters in place of others ASCII characters.
-
Some lesser-used symbols are not supported. (e.g. braces, back tick, tilde.)
-
Differing use of character codes above 127. Some computers do not have characters greater than 127. Some use the entire range of characters greater than 127 for more, unique, printable characters.
These are the common issues specific to the Atari's differences:
-
Plain text on the Atari is in ATASCII codes which is ASCII-like for the usual A-Z, 0-9 characters, but different from ASCII in the following ways:
- ASCII control characters are used as the graphics characters.
- Character 155(dec)/$9B(hex) is the end of string and new line/carriage return.
- Character 0, often used as end of string on other systems, is a valid graphics character on the Atari.
- The Atari uses codes greater than 127 to show the Inverse Video version of characters images of the characters from 0 to 127.
-
Character set image order on the Atari is different from ATASCII order. (Other systems with refined character sets may tend towards ASCII order.)
- Notably, entry 0 in the character set is for the blank space. (This is a benefit in game code. When a program reads a zero value byte from screen memory it can use the CPU zero flag immediately without doing a comparison to recognize a blank/empty place on screen.)
-
Keyboard scan codes on the Atari are also different from both ATASCII and the the internal character set order.
The Other Platforms
The 6502s
Games written in Assembly for other 6502-based computers would be easiest to port to the Atari in Assembly, since the language syntax will be similar. Many older Assemblers required line numbers that may not be allowed in modern Assemblers. It is possible older code may lack directives expected by modern assemblers. Managing idiosyncrasies of the different Assemblers may require retyping, or re-indenting.
PET - 1977
The 40xx series supports a monochrome text display of 40x25 characters. Later models support 80 column text. It has no actual graphics capability and no color. It does have a large text character set which includes lower case characters and many graphics shapes. With careful use the text can create displays that appear to be drawn graphics. Since everything is text-based, any game object or moving player is based on character positions. It has no sound, no joysticks, and as it has very limited hardware its BASIC language is generic with few unique considerations. There would be very little difference in capabilities between a BASIC program and an Assembly program in the Pet other than the execution speed.
Any game for the Pet 40xx series systems should fit well within the Atari's display capabilities. The 25 lines of text can easily be handled with a modified Display List. Some graphics characters on the Pet would require a redefined character set on the Atari replacing characters with Pet-like images.
APPLE II - 1977
The Apple supports 40x24 character text mode. Earlier models had only upper case alpha characters. Later models supported lowercase. It has an infrequently-used, low resolution, 80x48, 16-color mode. Most games use the remarkably engineered 280x192 high resolution mode that works on a NTSC television to display six colors at 140 x 192 by exploiting the NTSC artifacts. This mode uses 7 of the 8 bits in a byte for pixels that are 1/2 the NTSC color clock width producing two artifact colors, or white where two pixels are drawn next to each other. The eighth bit controls shifting the signal by 1/4 color clock to produce two different artifact colors for the pixels from that byte.
The Apple supports two separate screens for high resolution graphics allowing a computer with enough memory to double-buffer and display one screen while redrawing the other. There is a hardware register setting to replace the bottom of the graphics screens with several lines of text.
The BASIC language includes commands for engaging the graphics modes and drawing lines.
The Apple software has a shape table feature that executes a list of pseudo-coded line drawing commands and permits rotating and scaling the drawn lines. Most Assembly games will write images directly to screen memory which is linear horizontally, but is not contiguous between adjacent lines. Built-in sound is limited to clicks and short beeps on the keyboard speaker. If joysticks are used they are analog controls made of 2 potentiometers (paddles controllers).
Converting graphics to the Atari has obstacles. The easiest is the non-contiguous order of lines of screen memory. Since the Atari Display List can specify the memory to read for a line of graphics the Atari could arrange graphics memory in exactly the same way as the Apple, so Apple code accessing horizontal rows would work as-is. But, this isn't necessarily needed as the common optimization for both the Apple or the Atari is a lookup table of pre-calculated addresses for each line of the display to eliminate the multiplication needed for the vertical coordinates. Here the Atari merely needs a table of different values, and then the Apple's lookup code works the same regardless of the order of screen memory.
The Atari has a high resolution mode that generates NTSC artifact colors, but can only derive 4 artifact colors, not the 6 from the Apple. Since artifacts effectively halve the pixel resolution then the Atari's Mode E, "medium resolution", 160 pixel graphics mode could also be a substitute, though its use of 2 bits per pixel requires more coding compensation to simulate the Apple results. It really depends on whether or not the Apple game uses all six colors and how the colors are used. Player/Missiles could provide more color in limited places.
Both options for graphics memory simulation are minimal problem solvers as the real problem is that the Apple is displaying 7 bits of each byte as pixels to the Atari's 8 pixels. This throws off pixel position for plotting, line drawing, and memory masking writing images into screen memory. If Apple code is run directly on the Atari it will produce graphics where every 8th vertical line of pixels is blank. Code manipulating graphics memory, and the data used for animating objects must be dissected and rebuilt in a form suiting the Atari.
VIC-20 - 1979
The VIC-20 has a 16 color palette, supports 22x23 color text, and redefined character sets. 16 colors are available for the background and 8 colors for the text. Text characters may be 8x8 pixels in one foreground color, or 4x8 pixels allowing 3 colors in the characters, plus the background. There are no graphics modes. Displays that appear to be graphics are exploiting redefined character sets. It uses a color map to specify colors per character positions. It has a 3 voice sound chip, and supports an Atari digital joystick.
The BASIC language included in the VIC-20 is generic BASIC with no commands supporting the hardware. BASIC programs using any of the graphics and sound will be packed with POKE statements.
Since the only graphics capability is redefined character sets, there are literally hundreds of games that are almost the same game pushing text characters around the screen using a different redefined character set. Quite an amazing number of these games were sold commercially. More advanced games use redefined characters to simulate bit-mapped graphics and shift images through multiple characters to simulate pixel-based graphics animation.
ANTIC Mode 6 text has 20 characters per line and can show characters in 4 colors where the entire character is a single color. This is the closest in size to the VIC-20's 22 character text mode. Using the Atari's wide screen for overscan allows adding characters to the line, so the Atari can manage 22 characters in Mode 6 which fits (just barely) on an NTSC TV. However, this does mean the Atari's version of 22 characters is noticeably wider than the VIC-20's. (Covering more TV screen area could be considered a bonus.)
ANTIC Mode 6 also uses 64 characters in its character set, so the VIC-20 program may run through more characters than the Atari can display. Where many VIC-20 characters are specific graphics objects the Atari could deal with it via a Display List interrupt switching to different character sets every few lines, or using a more dynamic (and slower) method where the character images needed at the moment are copied to the characters shown on screen. Where a VIC-20 game uses multiple characters to simulate a larger graphics bitmap the Atari could do the same thing, and as only 22 characters are needed for the one line, a different character set every 2 or three lines could do the same work.
Alternatively, since the VIC's text is the equivalent of 176 pixels horizontally, the Atari could use ANTIC Map Mode E lines to draw the text characters. With Horizontal overscan the Atari can display the 176 pixels, but the medium resolution graphics displays 4 colors including the background. The VIC's Multi-color character mode halves the horizontal pixel resolution. The Atari could use a 80-pixel per line GTIA color interpretation mode (BASIC Graphics Mode 10) with overscan to display the 88 pixels the VIC uses and has 9 colors available.
Another obstacle is the VIC's 16 background, and 8 text colors using a color map. All colors are not used in most situations, so simply using a DLI to change foreground colors as needed per line could solve for the problem. Background coloring is a little more difficult as the Atari has one color for the background. Where more color is needed, Player/Missile graphics can add limited amounts of color. But, inevitably there will be situations where a color or two will have to be ignored or worked around.
ACORN ATOM - 1980
This computer has graphics capabilities approximately like the TRS-80 Color Computer (64 column text, 4 and 2 color graphics modes from 64x64 to 256x192). The BASIC language has memory manipulation commands that work on 4 byte words, plus it includes an in-line Assembler. Sound is from the keyboard speaker.
BBC MICRO - 1981
COMMODORE 64 - 1982
The Commodore 64 is newer than most of the systems and in some areas more capable than others. It has a 16 color palette, supports 40x25 color text, and redefined character sets. Similar to the VIC-20 the text characters may be 8x8 pixels in one foreground color, or 4x8 pixels allowing 3 colors in the characters, plus the background. Unlike the VIC-20 the C64 also supports pixel-addressable graphics modes. These modes use similar rendering, and memory arrangement as the text character modes. (1 bit for monochrome color pixels, and 2 bits for 4 color pixels.) It uses a color map to specify color per character positions and supports limited color indirection for some colors on the playfield. It supports 8 movable "sprites" in 24x21 pixels and 1 color, and 12x21 pixels in 3 colors. Sprites support limited collision detection with the playfield graphics. It has a 3 voice sound synthesizer chip, and supports two Atari digital joysticks.
Like the VIC-20, the BASIC language included in the Commodore 64 is generic BASIC with no commands supporting the hardware. BASIC programs using any of the graphics and sound will be a mass of POKE statements.
Since the C64 uses a color map like the Vic-20, porting to the Atari has similar concerns regarding color. The C64 has 40 column text modes displaying one color per text character (approximately like ANTIC mode 2), or a multi-color text mode allowing 4 colors within a text character using two bits per pixel resulting in 4 pixels across the width of the character. The normal and multi-color character set bit encoding is the same as Atari uses in ANTIC text modes 2 and 4, respectively.
ANTIC Text modes 2 and 4 use 128 characters in the character set and the C64 uses 256, so the C64 program may run through more characters than the Atari can display. Solutions are similar to the VIC-20 -- where characters are specific graphics objects the Atari could deal with it via a Display List interrupt switching character sets every few lines, or using a more dynamic method where the character images needed at the moment are copied to the characters shown on screen.
The C64 has graphics modes roughly corresponding to Atari's high resolution, ANTIC mode F, and medium resolution ANTIC mode E. While the bit encoding is the same as the Atari modes the byte arrangement is not linear across the screen. Instead, memory is arranged in character-sized cells as if the graphics were a characters set. Pixel manipulation on the C64 requires a fair amount of computation due to the memory arrangement. The Atari's linear memory allows more opportunity for optimization and pixel manipulation requires less code.
The C64 supports more sprites with greater horizontal resolution, so the Atari would need to adjust for differing number of objects on the same horizontal line, or use other graphics as a substitute for sprites. The C64 uses a lookup table and pointer to the current image for each sprite. Between the different size of sprites, and the 3-byte-wide memory arrangement the data for sprites must be reworked to function for Atari Player/Missile graphics. The Atari supports more thorough Player/Missile collision detection, so this does not require compromise unless the game must simulate sprites using non-Player/Missile graphics.
The C64 supports fine scrolling the size of one character horizontally and vertically. However, when vertical scrolling the C64 loses a horizontal line of text, and for horizontal scrolling it loses two vertical columns of text. Also, when fine scrolling reaches its limit the screen data has to be coarse scrolled through screen memory by the CPU. When porting it is possible to treat the Atari similarly and coarse scroll the hard way by redrawing the screen, but extra effort could simplify the code to leverage the Atari's coarse scrolling support in the Display List.
ACORN ELECTRON - 1983
Interestingly, this is a 2MHz 6502 system when accessing RAM, and 1MHz when accessing ROM. It supports text up to 80 columns. Graphics range from 160×256 (4 or 16 colors), 320×256 (2 or 4 colors), 640×256 (2 colors). It had a large 32K ROM with unique features in BASIC, plus an Assembler.
ORIC 1 - 1983
This is a 1MHz 6502 system. It has a 40x28 text mode supporting redefined character sets. It also has a high resolution 240x200 graphics with 3 lines of text below. It has a palette of 8 colors, and uses a color map arrangement to specify foreground and background colors. It has a 3 voice sound chip.
Other CPUs
Games written in Assembly for computers that do not use the 6502 will be harder to port, since the programmer must learn the nuances of a different Assembly language. It is much easier to port BASIC programs which are not CPU dependent. Alternatively, where the game's rules and behavior are completely documented, and videos exist of full game play, then porting can be based on analyzing these resources without without reading too much of the original code.
TRS-80 - 1977
The TRS-80 models use a Z80 CPU. This makes porting Assembly language source more difficult. Porting from BASIC games would be a better place to start if you don't want to learn Z80. However, the hardware is not excessively complicated. Graphics are supported, but are very minimal compared to Atari capabilities. It could be reasonable to base porting to Atari on observation of the display behaviors with some investigation in the data and light examination of code.
The TRS-80 models support 64x16 monochrome text and "graphics" using character cells divided into 2x3 segments as pixels (128x48 pixels). The BASIC language has commands to plot pixels, and also allows a string packing technique to compress a series of pixel instructions, and then "print" them quickly to a location on screen. Some later models support 80 column monochrome and higher resolution graphics.
The 64 column text would need some workarounds on the Atari, if needed, since it is bigger than the Atari screen width. Abbreviate text, or use more than one line. TRS-80 has 16 lines v Atari's 24 lines. Splitting text into multiple lines may be workable for text issues that allow this as a solution, since the Atari has plenty of extra lines.
The 128x48 graphics pixels are an odd dimension considerably less than most Atari graphics modes. This could be duplicated with a line of Mode B and Mode C referencing the same line of screen memory and setting narrow screen width for 128 pixel width. Alternatively, use the normal width screen for 160 pixels horizontally, and only draw in the middle 128 pixels.
TRS COLOR COMPUTER - 1980
This system is based on the 6809 CPU which is not so similar to the 6502, so BASIC programs are an easier starting point. It supports color text at 32x16. It also supports graphics modes from 64x32 in 8 colors up to 256x192 in 4 colors. The prior monochrome TRS-80 Model concept of text characters subdivided into pixels also applies to this system, but supports more than one color on screen. (The last version, Model 3 has more enhanced graphics.) It includes a sound chip, and allows two analog joysticks similar to the Apple.
TI-99/4A - 1981
This is a unique system using a 3MHz TMS9900 CPU, technically a 16-bit processor, though only 256 bytes of scratchpad RAM and the system ROM are on the 16-bit bus while the rest of the RAM is on an 8-bit bus which severely reduces the speed.
The system uses a graphics coprocessor providing four graphics modes plus a couple more "undocumented" variations from 240x192 to 256x192 that vary in number of colors or flexibility in placing color. The system has 15 colors with one color as "transparent". The graphics modes display text character or graphics.
The system supports 32 sprites overlayed on top of graphics, but only 4 sprites are visible per scan line. Sprites have 1 color (and transparent) and are 8x8 or 16x16 pixels, and there is collision detection between sprites. The "transparent" value in sprites shows the graphics pixels behind the sprites.
The computer has a sound chip with 3 voices for music, and 1 channel of white noise. The TI-99/4A supports two joysticks.
SINCLAIR ZX81 - 1981
ZX SPECTRUM - 1982
DRAGON 32/64 - 1982
The system is very similar to the TRS-80 Color Computer -- Same CPU, similar text and graphics modes. The BASIC is similar, but uses different tokenization, so the text of a BASIC program from the Color Computer would have to be reentered to work on the Dragon.
Types of Games To Port
BASIC PROGRAMS
BASIC programs will utilize fewer of the features of the computer making it easier to port to the Atari. Consider that when BASIC is the source and Assembly is the target, then even Atari BASIC games are also eligible for "porting". A functional, but mediocre Atari BASIC game could be embellished with Assembly language into a work of art and an exciting gaming experience.
ASSEMBLY PROGRAMS
Assembly programs may use more features of the original platform. Each source system is differently-abled from the Atari, so it is unlikely the Atari port can look exactly the same as the original. Oranges do not have to equal Apples, so an approximation or replacement in the Atari style is the goal.
On the other hand, just because the game is in machine language doesn't necessarily mean the author is pushing the platform to limits that would be difficult for the Atari. Sometimes nice, simple games are in Assembly, just because BASIC can't handle timing or many screen updates.
ATARI TOOLS
-
Emulators: Altirra, Atari 800.
-
Assemblers: MADS, Atasm
-
Eclipse, WUDSN
-
Grafx2
RESOURCES FOR GAMES AND PROGRAMS
General sources that provide information, demonstrations, programs, or source for a variety of computers.
-
Books/Magazines from the 1970s and 80s. (Compute! Mapping books.)
-
Multi-Platform and dedicated.
-
(archive.org)
-
classic computer magazine archive
-
trs80 color computer archive
-
YouTube video demonstrations
-
Github