Useful
Inventions
Favorite
Quotes
Game
Design
Atari
Memories
Personal
Pages

Atari 2600 Programming for Newbies

Session 20: Asymmetrical Playfields (Part 3)

By Andrew Davie (adapted by Duane Alan Hahn, a.k.a. Random Terrain)

As an Amazon Associate I earn from qualifying purchases.

Page Table of Contents

Original Session

This session we're going to wrap-up our understanding of playfield graphics.

 

 

 

 

Full-Screen-Bitmap Tool

It doesn't take long before you get sick of doing data by hand, and often the time spent in creating tools is repaid many-times-over in the increase in productivity and capability those tools deliver. Sometimes a tool is a 'hack' in that it's not professionally produced, it has bugs, and it isn't user-friendly. But until you've tried creating bitmap graphics by hand a bit-at-a-time (and I'm sure that some of you have already done this by now), you won't really appreciate somethinganything!that can make the process easier. Having prepared you for the fairly shocking quality of this, I now point you towards FSB, the Full-Screen-Bitmap tool. It's the tool I use for generating the data for those spiffy Interleaved ChronoColour (tm) Full-Screen-Bitmaps. But it's able to be used for monochrome playfields, too.

 

The tool (Windows-only, sorryif you're on a non-Windows platform then you may need to write your own) is run from a DOS command-line. It takes three graphics files as input (representing the RED, GREEN, and BLUE components of a color image) and spits-out data which can be used to display the original data on an Atari 2600. For now we're not really at the level of drawing color bitmapsbut we'll get there shortly. First, let's examine how to use FSB to generate data for simple bitmap displays.

 

As noted, FSB takes three graphics files as input. Let's simplify things, and pass the utility only one file. This equates to having exactly the same data for red, green, and blue components of each pixeland hence the image will be black and white (specifically, it will be two-color). That's the capability of the '2600 playfield display, remember! It's only through trickery that there ever appear to be more than two colors on the screen at any time. That trickery being either time-based or position-based changing of the background and playfield colors to give the impression of more colors.

 

Actually, I cheated a bitif we pass only one file, the utility will process it, then have a fit when it can't find the others. As I said, it's a bit of a hack. But sometimes, hacking is OK. Sometime, I'll get a round tuit and fix it up.

 

 

 

 

40 x 192 Pixel Image

Right, let's get right into it. Create yourself a graphic file with a 40 x 192 pixel image, just 2-colors. It doesn't really HAVE to be two colors for the utility to work, but the utility will only process the pixels as on or off. It's difficult to create good-looking images in such low-resolution and odd aspect ratio. Remember, with a graphics package you're probably drawing with square(ish) pixels, so your 40 x 192 image probably looks narrow and tall. On the '2600 it will be pretty much full-screen. That is, the pixels are 'stretched' to roughly 8x their width. So, if you like, use your paint program's capabilities to draw in that aspect ratio. Doesn't matter how you do it, as long as your final image is just 40 pixels across, 192 deep.

 

Once you have the image, save it as either a .BMP, a .JPG or a .PNG file. I don't support .GIF as the idea of software patents is abhorrent to me. Having said that, I actually am the inventor of one particular piece of patented software (It's true! Look it upthat's exercise 1 for today) so you just never know when I'm serious or not, do you? Once we have that image file, we can feed it into the utility…

 

Navigate to where you've placed the utility .exe file, and type (without the quotes) "FSB".

 

You'll see something like this…

 

D:Atari 2600ToolsFullScreenBitmapDebug>fsb



FSB -- Atari 2600 Colour Image Generatorv0.02

Copyright (c)2001 TwoHeaded Software

Contains paintlib code.
paintlib is copyright (c) 1996-2000 Ulrich von Zadow





Usage: FSB [-switch] RED_FILE GREEN_FILE BLUE_FILE



Switches. . .

  RED_FILE     File with red component of image (2-colour)

  GREEN_FILE   File with green component of image (2-colour)

  BLUE_FILE    File with blue component of image (2-colour)

  v            Toggle verbose output ON/OFF

  nNAME        set output filename prefix. Defaults to IMAGE



Input files may be .BMP, .JPG, or .PNG format.



Reading File: IMAGE

Unrecognised and/or unsupported file type.

If you see that, then the utility is working fine. Ignore the various error messagesas I said, it's a hack and incomplete. But it does work well-enough for our purposes. If there's much demand/usage and I'm embarrassed enough I'll clean it up.

 

This time, let's pass an image to it … let's assume we saved our file as test.png in the same directory.


Type (without … you know the drill) . . . "FSB test.png"


D:Atari 2600FullScreenBitmapGraphics>fsb test.png



FSB -- Atari 2600 Colour Image Generatorv0.02

Copyright (c)2001 TwoHeaded Software

Contains paintlib code.
paintlib is copyright (c) 1996-2000 Ulrich von Zadow



Reading File: test.png

Bitmap size: 40 x 170 pixels

........

........

........

........

........

........

........

........

........

........

........

........

........

........



>>>lots of stuff cut from here!! <<<


.*..*.*.

.*.*.*.*

..*.*.*.

**.*..*.

...*.*.*

*.*.*.*.

.*..*..*

.*.*.*.*

*.*.*.*.

..*..*..

Reading File: IMAGE

Unrecognised and/or unsupported file type.

You'll see a WHOLE LOT MORE of those lines with dots and asterisks. This is my debugging visual output of the graphics as the utility is converting the data. Strictly speaking this is not necessary. But as I said, it's a hack. Increasingly I'm feeling I need to fix this *sigh*. That's one of the problems with releasing your tools for others to use. Please IGNORE that last line saying Unrecognized and/or unsupported file type. It's uh … a feature. Anyway, plunging on… .

 

Remember in the previous sessions how we determined that an asymmetrical playfield was created by writing to playfield registers PF0, PF1, and PF2, and then with exquisite timing writing again to those registers before the scanning of the electron-beam across the scanline got to display them again? In essence, there are 6 bytes of data for each scanline (two of each of the three playfield registers). Although 4 bits in playfield 0 aren't used, and there's a potential saving there of 8 bits total (ie: one byte per line) we're not going to delve into that sort of saving here. Let's just accept that the utility will convert the 40-bit wide image into 'segments' such that we really have data for PF0, PF1, PF2 for the left side of each scanline, and more data for those registers for the right side of each scanline.

 

Some of the examples presented by our astute readers have already shown formidable asymmetrical playfield solutionsso good, in fact, that I'm not going to trouble with an 'official' asymmetrical playfield solution for these tutorials. Take one of the already-presented solutions and use that.

 

 

 

 

Data

What I would like to discuss, though, is just how the data for a full-screen-bitmap should be presented. We can organize our data into 192 scanlines, each having 6 bytes of dataor we could organize it into 6 columns, each having 192 bytes of data. The first method is more intuitive (to me, anyway) but it is a much more inefficient way to store our data from the 6502's perspective. In fact, to use the first method correctly we would need to use an addressing-mode of the 6502 that I haven't introduced yetso let's just look at how the utility spits out the data and hopefully as time goes by you will come to trust my wisdom and perhaps even understand WHY we did it this way ;)

 

A hint: When using an index register, you can address 256 bytes from any given base-address. That is, the index register can range from 0 to 255, and that register is added to the base address when doing absolute indexed addressing to give you a final address to read from or write-to. Now consider if we had our data organized as 192 lines, each being 6 bytes long … we could do the following…


    ldx #0  ; index to the PF data

    ldy #0  ; line number



ALine   lda PFData,x   ; PF0 data

        sta PF0

        lda PFData+1,x    ; the next byte of data
                          ; (assembler calculates the +1 when assembling)

        sta PF1

        lda PFData+2,x    ; the next

        sta PF2



; delays here, as appropriate



       lda PFData+3,x  ; PF0 data, right side

       sta PF0

       lda PFData+4,x  ; the next

       sta PF1

       lda PFData+5,x  ; the next

       sta PF2



       txa

       clc

       adc #6

       tax  ; increment pointer by one line (6 bytes of data)



       sta WSYNC  ; wait till next line



       iny

       cpy #192

       bne ALine
       

The above code essentially assumes that the data for the screen is in a single table consisting of 6 bytes per scanline, and that the scanlines are stored consecutively. Can you see the problem with this?

 

It's a bit obscure, but the problem is when we get to scanline #43. At or about that point, the index register used to access the data will be 42 x 6 (=252) and we come to add 6 to it. So we get 258, right? Wrong! Remember, our registers are 8-bits only, and so we only get the low 8-bits of our resultand so 252 + 6 = 2 (think of it in binary: %11111100 + %00000110 = %100000010 (9 bits) and the low 8 bits are %00000010 = 2 decimal). So at line 43, instead of accessing data for line 43 we end up accessing data for line 0 againbut worse yet, not from the start of the line, but actually two bytes 'in'. Urk! This is a fundamental limitation of absolute indexed addressingyou are limited to accessing data in a 256-byte area from your base address. There are addressing-modes which allow you to get around this, but they're slowerand besides, it's better to reorganize your data rather than using slow code.

 

OK, so now let's consider if each of the bytes of the playfield (all 6 of them) were stored in their own tables. Think of the screen being organized into 6 columns each of 192 bytes (the depth of the screen). Since each table is now <256 bytes in size, we can easily access each one of them using absolute indexed addressing. As an added bonus, they can all be accessed using just the one index register which can ALSO double as our line-counter. Like this…


       ldx #0  ; line #

ALine  lda PF0Data,x  ; PF0 left

       sta PF0

       lda PF1Data,x  ; PF1 left

       sta PF1

       lda PF2Data,x  ; PF2 left

       sta PF2

  

; delay as appropriate



       lda PF3Data,x  ; PF0 right

       sta PF0

       lda PF4Data,x  ; PF1 right

       sta PF1

       lda PF5Data,x  ; PF2 right

       sta PF2



       sta WSYNC



       inx

       cpx #192

       bne ALine
       

The above code assumes that there are 6 tables (PF0Data - PF5Data) containing 'strips' or 'columns' of data making up our screen. We COULD have had just a single table with the first 192 bytes being column 0, the next being column 1, etc., and letting the assembler calculate the actual address from the base address like this (snippet…)


       ldx #0  ; line #

ALine  lda PFData,x  ; column 0 - PF0 left

       sta PF0

       lda PFData+192,x   ; column 1 - PF1 left

       sta PF1

       lda PFData+384,x   ; column 2 - PF2 left



; delay, etc.



       lda PFData+384+192,x; column 3 - PF0 right



; etc.

What it's important to understand here is that the "+192" etc., is *NOT* done by the 6502. Remember how our assembler converts labels to their actual values (using the symbol table)? Likewise it converts expressions to their actual valuesand in this case it will take the value of 'PFData' and add to it 192, and put the resulting 16-bit value as the 2-byte address following the lda op-code. Remember, the 6502 absolute addressing mode is simply given a base address to which it adds the index register to get a final address from which data is retrieved (lda) or to which it is stored (sta).

 

The above example with the manual-offset from the base address (that is, where +n was added) is functionally identical to the example where there were 6 separately named tables. In both cases, the data is assumed to be strips of 192 bytes, each strip being one of the columns representing the values to put into each of the 6 playfield registers (given that there are 6 writes to three registers per-line, I think of the three registers as 6 separate registers).

 

So that's exactly what FSB does. It creates 6 tables, each representing a 'strip' of 192 lines of data for a single register. Those tables are saved to a .asm file with the same prefix as the input file, and contents like this (abridged)…


screen



screen_STRIP_0

 .byte 240

 .byte 240

 .byte 240

 .byte 240



;188 more bytes here



screen_STRIP_1



;192 bytes here



screen_STRIP_2



;192 bytes here



screen_STRIP_3



;192 bytes here



screen_STRIP_4



;192 bytes here



screen_STRIP_5



;192 bytes here


;end

For space purposes that has been heavily abridged. The file was produced from a source-file called 'screen.jpg'as you can see, the filename prefix has been used to create labels to identify the whole table ('screen') and also to identify each of the strips ('screen_STRIP_0', etc). So you can use either of the access methods described above, if you wish. Remember, if this file were assembled, the values of the symbols 'screen' and 'screen_STRIP_0' would be identical as they will be at the same address in the binary.

 

 

 

 

include

So, we have a DASM-compatible file which contains a text-form version of the graphics file. How do we include this data into our source, so that we may display the data as an image? It's pretty easyand in fact we've already encountered the method when we included the 'vcs.h' and 'macro.h' files.

 

We just use the include dasm pseudo-op.


  include "screen.asm"  ; or whatever your generated file is

When you use the include pseudo-op, DASM actually inserts the contents of the file you specify right then and there into that very spot into the source-code it is assembling. So be careful about where you enter that include pseudo-op. Don't put it in the middle of your kernel-loop, for example! Put it somewhere at the beginning or end of your code segment, where it won't be executed as 6502 code. For example, after the jump at the end of your kernel, which goes back to the start of the frame.

 

 

 

 

 

Summary

Until next time, enjoy!

 

 

 

 

 

Exercises

  1. Create a circle as a 40 x 192 image and save it as a .JPG, .PNG or .BMP. Convert it to source-code through FSB to create source-code data. Can you think of good ways to draw circles in such an odd screen-size? Hintmake the size of your image the LAST step in the draw process!
  2. Take one of the asymmetric playfield demos from the last session and convert it to display the data generated in step 1.
  3. Set the playfield color to a RED for one frame, then the next frame set it to a GREEN, and for the third frame set it to a BLUE. What effect do you see? What color does the circle appear to be? Why? If you haven't cottoned-on yet, this is leading towards color-bitmap technologywe may cover that in a future session. By using different colors over time, we can trick the eye to seeing a different color than those we actually use.
  4. How can this temporal color change be used to display a range of colors? This is tricky, so don't worry if you can't understand it. Hint: don't just change the color each frame! What else can you change?
  5. All our discussions about bitmap graphics have revolved around the use of asymmetrical (mirrored) playfields. Yet some (not many!) games use non-mirrored playfields. What timing problems can you see when using non-mirrored playfields for bitmap graphicsand why on earth would you want to do this?

 

 

 

Other Assembly Language Tutorials

Be sure to check out the other assembly language tutorials and the general programming pages on this web site.

 

Amazon Stuff

 

< Previous Session

 

 

Next Session >

 

 

 

 

Session Links

Session 1: Start Here

Session 2: Television Display Basics

Sessions 3 & 6: The TIA and the 6502

Session 4: The TIA

Session 5: Memory Architecture

Session 7: The TV and our Kernel

Session 8: Our First Kernel

Session 9: 6502 and DASM - Assembling the Basics

Session 10: Orgasm

Session 11: Colorful Colors

Session 12: Initialization

Session 13: Playfield Basics

Session 14: Playfield Weirdness

Session 15: Playfield Continued

Session 16: Letting the Assembler do the Work

Sessions 17 & 18: Asymmetrical Playfields (Parts 1 & 2)

Session 19: Addressing Modes

Session 20: Asymmetrical Playfields (Part 3)

Session 21: Sprites

Session 22: Sprites, Horizontal Positioning (Part 1)

Session 22: Sprites, Horizontal Positioning (Part 2)

Session 23: Moving Sprites Vertically

Session 24: Some Nice Code

Session 25: Advanced Timeslicing

 

 

 

 

Useful Links

Easy 6502 by Nick Morgan

How to get started writing 6502 assembly language. Includes a JavaScript 6502 assembler and simulator.

 

 

Atari Roots by Mark Andrews (Online Book)

This book was written in English, not computerese. It's written for Atari users, not for professional programmers (though they might find it useful).

 

 

Machine Language For Beginners by Richard Mansfield (Online Book)

This book only assumes a working knowledge of BASIC. It was designed to speak directly to the amateur programmer, the part-time computerist. It should help you make the transition from BASIC to machine language with relative ease.

The Six Instruction Groups

The 6502 Instruction Set broken down into 6 groups.

6502 Instruction Set

Nice, simple instruction set in little boxes (not made out of ticky-tacky).

 

 

The Second Book Of Machine Language by Richard Mansfield (Online Book)

This book shows how to put together a large machine language program. All of the fundamentals were covered in Machine Language for Beginners. What remains is to put the rules to use by constructing a working program, to take the theory into the field and show how machine language is done.

6502 Instruction Set

An easy-to-read page from The Second Book Of Machine Language.

 

 

6502 Instruction Set with Examples

A useful page from Assembly Language Programming for the Atari Computers.

 

 

6502.org

Continually strives to remain the largest and most complete source for 6502-related information in the world.

NMOS 6502 Opcodes

By John Pickens. Updated by Bruce Clark.

 

 

Guide to 6502 Assembly Language Programming by Andrew Jacobs

Below are direct links to the most important pages.

Registers

Goes over each of the internal registers and their use.

Instruction Set

Gives a summary of whole instruction set.

Addressing Modes

Describes each of the 6502 memory addressing modes.

Instruction Reference

Describes the complete instruction set in detail.

 

 

Stella Programmer's Guide

HTMLified version.

 

 

Nick Bensema's Guide to Cycle Counting on the Atari 2600

Cycle counting is an important aspect of Atari 2600 programming. It makes possible the positioning of sprites, the drawing of six-digit scores, non-mirrored playfield graphics and many other cool TIA tricks that keep every game from looking like Combat.

 

 

How to Draw A Playfield by Nick Bensema

Atari 2600 programming is different from any other kind of programming in many ways. Just one of these ways is the flow of the program.

 

 

Cart Sizes and Bankswitching Methods by Kevin Horton

The "bankswitching bible." Also check out the Atari 2600 Fun Facts and Information Guide and this post about bankswitching by SeaGtGruff at AtariAge.

 

 

Atari 2600 Specifications

Atari 2600 programming specs (HTML version).

 

 

Atari 2600 Programming Page (AtariAge)

Links to useful information, tools, source code, and documentation.

 

 

MiniDig

Atari 2600 programming site based on Garon's "The Dig," which is now dead.

 

 

TIA Color Charts and Tools

Includes interactive color charts, an NTSC/PAL color conversion tool, and Atari 2600 color compatibility tools that can help you quickly find colors that go great together.

 

 

The Atari 2600 Music and Sound Page

Adapted information and charts related to Atari 2600 music and sound.

 

 

Game Standards and Procedures

A guide and a check list for finished carts.

 

 

Stella

A multi-platform Atari 2600 VCS emulator. It has a built-in debugger to help you with your works in progress or you can use it to study classic games. Stella finally got Atari 2600 quality sound in December of 2018. Until version 6.0, the game sounds in Stella were mostly OK, but not great. Now it's almost impossible to tell the difference between the sound effects in Stella and a real Atari 2600.

 

 

JAVATARI

A very good emulator that can also be embedded on your own web site so people can play the games you make online. It's much better than JStella.

 

 

batari Basic Commands

If assembly language seems a little too hard, don't worry. You can always try to make Atari 2600 games the faster, easier way with batari Basic.

 

 

Back to Top

 

 

In Case You Didn't Know

 

Trump's Jab = Bad

Did you know that Trump's rushed experimental rona jab has less than one percent overall benefit? It also has many possible horrible side effects. Some brainwashed rona jab cultists claim that there are no victims of the jab, but person after person will post what the jab did to them, a friend, or a family member on web sites such as Facebook and Twitter and they'll be lucky if they don't get banned soon after. Posting the truth is “misinformation” don't you know. Awakened sheep might turn into lions, so powerful people will do just about anything to keep the sheep from waking up.

 

Check out these videos:

What is causing the mysterious self-assembling non-organic clots?

If You Got the COVID Shot and Aren't Injured, This May Be Why

Full Video of Tennessee House of Representatives Health Subcommittee Hearing Room 2 (The Doctors Start Talking at 33:28)

 

 

H Word and I Word = Good

Take a look at my page called The H Word and Beyond. You might also want to look at my page called Zinc and Quercetin. My sister and I have been taking those two supplements since summer of 2020 in the hopes that they would scare away the flu and other viruses (or at least make them less severe).

 

 

B Vitamins = Good

Some people appear to have a mental illness because they have a vitamin B deficiency. For example, the wife of a guy I used to chat with online had severe mood swings which seemed to be caused by food allergies or intolerances. She would became irrational, obnoxious, throw tantrums, and generally act like she had a mental illness. The horrid behavior stopped after she started taking a vitamin B complex. I've been taking Jarrow B-Right (#ad) for many years. It makes me much easier to live with.

 

 

Soy = Bad

Unfermented soy is bad! “When she stopped eating soy, the mental problems went away.” Fermented soy doesn't bother me, but the various versions of unfermented soy (soy flour, soybean oil, and so on) that are used in all kinds of products these days causes a negative mental health reaction in me that a vitamin B complex can't tame. The sinister encroachment of soy has made the careful reading of ingredients a necessity.

 

 

Wheat = Bad

If you are overweight, have type II diabetes, or are worried about the condition of your heart, check out the videos by Ken D Berry, William Davis, and Ivor Cummins. It seems that most people should avoid wheat, not just those who have a wheat allergy or celiac disease. Check out these books: Undoctored (#ad), Wheat Belly (#ad), and Eat Rich, Live Long (#ad).

 

 

Negative Ions = Good

Negative ions are good for us. You might want to avoid positive ion generators and ozone generators. A plain old air cleaner is better than nothing, but one that produces negative ions makes the air in a room fresher and easier for me to breathe. It also helps to brighten my mood.

 

 

Litterbugs = Bad

Never litter. Toss it in the trash or take it home. Do not throw it on the ground. Also remember that good people clean up after themselves at home, out in public, at a campsite and so on. Leave it better than you found it.

 

 

Climate Change Cash Grab = Bad

Seems like more people than ever finally care about water, land, and air pollution, but the climate change cash grab scam is designed to put more of your money into the bank accounts of greedy politicians. Those power-hungry schemers try to trick us with bad data and lies about overpopulation while pretending to be caring do-gooders. Trying to eliminate pollution is a good thing, but the carbon footprint of the average law-abiding human right now is actually making the planet greener instead of killing it.

 

Eliminating farms and ranches, eating bugs, getting locked down in 15-minute cities, owning nothing, using digital currency (with expiration dates) that is tied to your social credit score, and paying higher taxes will not make things better and “save the Earth.” All that stuff is part of an agenda that has nothing to do with making the world a better place for the average person. It's all about control, depopulation, and making things better for the ultra-rich. They just want enough peasants left alive to keep things running smoothly.

 

Watch these two YouTube videos for more information:

CO2 is Greening The Earth

The Climate Agenda

 

 

How to Wake Up Normies

Charlie Robinson had some good advice about waking up normies (see the link to the video below). He said instead of verbally unloading or being nasty or acting like a bully, ask the person a question. Being nice and asking a question will help the person actually think about the subject.

 

Interesting videos:

Charlie Robinson Talks About the Best Way to Wake Up Normies

Georgia Guidestones Explained

The Men Who Own Everything

Disclaimer

View this page and any external web sites at your own risk. I am not responsible for any possible spiritual, emotional, physical, financial or any other damage to you, your friends, family, ancestors, or descendants in the past, present, or future, living or dead, in this dimension or any other.

 

Use any example programs at your own risk. I am not responsible if they blow up your computer or melt your Atari 2600. Use assembly language at your own risk. I am not responsible if assembly language makes you cry or gives you brain damage.

 

Home Inventions Quotations Game Design Atari Memories Personal Pages About Site Map Contact Privacy Policy Tip Jar