Atari 2600 Programming for Newbies

If you see that, then the utility is working fine. Ignore the various error messages—as 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"

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 solutions—so 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 data—or 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 yet—so 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…

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 result—and 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 again—but worse yet, not from the start of the line, but actually two bytes 'in'. Urk! This is a fundamental limitation of absolute indexed addressing—you 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 slower—and 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 values—and 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 easy—and 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.