TROGBlog - Porting Elite to the 2600

[RSS Bot]

After spending a couple days researching Elite, I'm convinced this game could be ported to the Atari 2600 and still retain most of its original look and feel. Here's what the original Elite looked like on the Commodore 64:

 

http://www.atariage.com/forums/gallery/1254209109/gallery_5668_432_4005.png

And here's a prototype screenshot on the Atari 2600 (this is from an emulator, not a mockup):

 

http://www.atariage.com/forums/gallery/1254209109/med_gallery_5668_432_997.png

The Bitmap

 

The first challenge of the port is implementing a high-resolution bitmap. This can be achieved by using the 30Hz text display from Stellar Track. The 12 characters from this display provides a resolution of 12 x 8 = 96 pixels per scanline. The next question is how tall should the display be. This is defined by how large of a video buffer can be provided and maintained by the hardware. I chose a 1K buffer as a reasonable target. 1024 / 12 bytes per line = 85 scanlines. This would fit nicely in the 96 scanline resolution of a 2-scanlines-per-pixel Atari display. Using square pixels also simplifies the rendering math.

 

To simplify the kernel code, it would be preferable to keep each column of buffer bytes in its own page. 84 x 3 = 252, so using 84 scanlines you can fit 3 1-byte columns in a single page. Multiply that by 4, and you've got 12 characters spanning 84 scanlines, so the final resolution is 96 x 84 pixels. The size of the bitmap can be seen inside the yellow border in the prototype image.

 

The Hardware

 

The 2600 only has 128 bytes of RAM, so it's going to need some help. The only current options for hardware that would provide a 1K RAM buffer are the Supercharger and an M-Network cartridge. The Supercharger only allows for a 6K game without multi-loading, and I don't think 6K would be sufficient to do an Elite port justice. Writes to Supercharger memory are also slower, if my conclusions from studying the Supercharger are correct.

 

The M-Network architecture, on the other hand, is just about optimal for this scenario. The 16K of ROM provides plenty of room to make a detailed game. The 1K continuous block of RAM is perfect for the high-resolution buffer, and allows quick read and write access to the entire buffer. The extra 1K of split RAM would be useful as scratch memory for the 3D calculations, and also as extra memory to store details about your ship configuration and cargo.

 

Another hardware consideration is the CPU. The main processor for the Commodore 64 is a MOS 6510 running at 1.02 MHz. The Atari CPU is a MOS 6507 running at 1.19 MHz. It's surprising that the Atari CPU, released in 1977, is clocked 19% faster than the Commodore CPU, which was released 5 years later in 1982. Other than the I/O port and the extra address pins, I'm not aware of any 6510 feature that would make it more powerful than a 6507. So the Atari starts out with a 19% advantage over the Commodore.

 

The big disadvantage for the Atari is having to process the kernel. This effectively excludes 192 of the 262 scanlines from any kind of render processing, resulting in a (192/262) = 73 percent loss of processing power. So only 27% of the processor can be dedicated to rendering. When the faster Atari clock is factored in, you get 27 * 1.19 = 32 percent speed relative to the Commodore processing. So it can only handle about one third the processing load.

 

Video Buffer Sizes

 

The upside of the small Atari video buffer is that there are fewer pixels to render. The Commodore buffer used 256 pixels by about 140 pixels, for a total of 4480 bytes. The Atari is using less than 1024 bytes, so it has less than a quarter of the pixels to render. This matches well with the one-third processing power.

 

Rendering

 

The main functions needed to display the images are:

 

3D Rotation

Projection from a 3D object to a 2D plane

Hidden surface removal

Line drawing

Circle drawing

 

I found some online resources that could really help with these functions. The most authoritative source is one of the original authors, Ian Bell, who posted the entire source code for Elite! This source was written for a BBC Micro, which also uses a MOS 6502. The only problem is there are very few comments in the code, and it's written in some kind of BASIC wrapper around the assembly code.

 

While googling for 6502 3D algorithms, I happened upon a great 3D tutorial written specifically for the 6502. If you scroll down to the "art of 3d" section, you'll find three links to C= Hacking issues. It's a 3 part study titled "A Different Perspective: Three-Dimensional Graphics on the C64." It includes a very detailed discussion of projections, rotations, line drawing, circle drawing, and hidden surfaces. It also provides full assembly implementations of these algorithms, and optimizing suggestions. I highly recommend it.

 

Code Organization

 

Using the M-Network bankswitching scheme, here's how I think the implementation would work.

 

ROM bank 7 (slice 1)

 

On system boot, the code would immediately bankswitch to bank 0. Bank 7 would be entirely reserved for only routines that need to access the 1K RAM buffer. This is necessary since none of the other banks can access this RAM directly, and it would be far too slow to use bank switching to set the video buffer or read it for kernel processing. So, the only code that would go here is the bit-mapped section of the kernel (which is actually very small, less than 200 bytes,) and the line drawing and circle drawing routines, which would need direct buffer writing access. Hopefully they could be squeezed into 1.5K.

 

ROM banks 0-6 (slice 0)

 

All the other routines, including projection, rotation, and surface removal, would go here. The only data that would have to be passed to slice 1 is an array of line and circle definitions that need to be drawn to the screen. This array could be stored in one of the 256 byte RAM sections, which are also available to slice 1. Other ROM banks would include system boot, sound effects, text display, trade interfaces, and all the 3D data for the various ships. It would also include the non-bitmapped bottom portion of the ship kernel, which would include radar and ship status meters.

 

Other Platforms

 

There are two other systems that came to mind while I was doing this study. The first is the Channel F. Oddly enough, its hardware setup is great for 3D rendering. It already has dedicated RAM for a screen buffer, and its resolution of 102 X 58 is comparable to the Atari buffer, minus the flicker. Plus, its CPU operates at 1.79 MHz, so it has the most processing power and the smallest video buffer to render. I know that video RAM access is slow in the Channel F, but this still sounds like a possibility.

 

The other system of interest is the Vectrex. This system is begging to have an Elite port. Graphics rendering would be a breeze on this system. The Vectrex is powered by a Motorola 68A09 at 1.5 MHz, which is far more powerful than the Commodore CPU. Elite ported to this system could look better than any of the original 8-bit versions. A Google search produced no evidence of any effort to port Elite to the Vectrex.

 

The Prototype

 

elite_study.zip (5.01K)

Number of downloads: 0

 

The prototype binary I'm posting here is quite simple. It doesn't contain any 3D rendering. The ship is just a static image loaded from ROM. What it does demonstrate is the size and appearance of the bitmap, and the simplicity of the kernel. The only difference between this bitmap kernel and an actual M-Network bitmap kernel is that it would point to a different location in memory, corresponding to the M-Network RAM, rather than ROM. The VideoRAM[0-11] addresses in the source would become RAM pointers.

 

I haven't implemented this in an M-Network bankswitching scheme yet. That will require more research, since the M-Network switching method is fairly complicated.

 

http://www.atariage.com/forums/index.php?app=blog&blogid=138&showentry=6640