Jump to content

Photo

Session 20: Asymmetrical Playfields - Part 3


53 replies to this topic

#1 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,742 posts
  • Dr.Boo
  • Location:Tasmania

Posted Fri Jul 11, 2003 9:26 AM

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

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 something - anything! - that can make the process easier. Having prepared you for the fairly shocking quality of this, I now point you towards http://www.atari2600.org/DASM/fsb.exe FSB stands for "Full-Screen-Bitmap", and it's the tool I use for generating the data for those spiffy Interleaved ChronoColour ™ Full-Screen-Bitmaps. But it's able to be used for monochrome playfields, too.

The tool (Windows-only, sorry - if 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 colour 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 colour bitmaps - but 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 pixel - and hence the image will be black and white (specifically, it will be two-colour). That's the capability of the '2600 playfield display, remember! It's only through trickery that there ever appear to be more than two colours on the screen at any time. That trickery being either time-based or position-based changing of the background and playfield colours to give the impression of more colours.

Actually, I cheated a bit - if 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.

Right, let's get right into it. Create yourself a graphic file with a 40 x 192 pixel image, just 2-colours. It doesn't really HAVE to be two colours 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 up - that'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 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 embarassed 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 Unrecognised 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.

What I would like to discuss, though, is just how the data for a full-screen-bitmap should be presented. We can organise our data into 192 scanlines, each having 6 bytes of data - or we could organise 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 organised 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 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 reorganise 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 organised 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.

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 sorce-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.

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? Hint - make 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 colour 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 colour does the circle appear to be? Why? If you haven't cottoned-on yet, this is leading towards colour-bitmap technology - we may cover that in a future session. By using different colours over time, we can trick the eye to seeing a different colour than those we actually use.

4. How can this temporal colour change be used to display a range of colours? This is tricky, so don't worry if you can't understand it. Hint: don't just change the colour 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 graphics - and why on earth would you want to do this?

Don't forget to remind me to answer these questions next session!

Until then, enjoy!


Changes in bold made 12/July/2003 - AD

#2 Galaga_Freak OFFLINE  

Galaga_Freak

    Chopper Commander

  • 179 posts
  • Location:St. Louis

Posted Fri Jul 11, 2003 7:14 PM

Cool stuff!

Some ones I generated:

Attached Thumbnails

  • mf.png
  • gf1.png
  • gf2.png
  • circles.png


#3 Emehr OFFLINE  

Emehr

    River Patroller

  • 4,179 posts
  • Happiness is... a chomping Pac-Man!
  • Location:An obscure body in the SK system

Posted Fri Jul 11, 2003 7:23 PM

I'm unable to post my .bin to the forum (it was created on a Mac and the forum software doesn't accept it) so I put it in my webspace here:

http://home.earthlin...tella/color.bin

Press and hold the left fire button to change the background color to white.
EDIT: I removed this "feature" in the current bin

These are the colors I am using for red, green, and blue...


RGBTable  .byte $40 ;Red

          .byte $C0 ;Green

          .byte $80 ;Blue


And here are my observations:

I already knew that combinations of the 3 component colors (red, green, and blue) yielded 8 colors, but what are the other 8 colors? My first guess would be: red, green, blue, cyan, magenta, yellow, black, and white. Alas, upon writing this little test program I found out that I was either wrong or my color perception is off-whack because I'm running this on an emulator and not on a real television (I'm guessing the latter).

Anyway, the main colors I see are...

red
green
blue
orange (red+green)
cyan (green+blue)
violet (red+blue)

My instincts tell me that a mixture of red+green+blue should be white. On a black background it looks more like a purplish-grey. Against white it looks more black.

I also observed that there is less flicker when drawn against a black background, and that the colors are richer (i.e. less washed out than on a white background). I'm guessing that this method is meant to be drawn with the background color set to black and that to get a black pixel, one simply does not draw a playfield pixel for all three phases of red, green, and blue. I'm also guessing that for optimal color pleasure, one should view this on a real television! So, does anybody have a Cuttle Cart or a Supercharger that they want to sell for less than the cost of a Cuttle II? :)

Having fun with this,
Jason Rein

#4 Emehr OFFLINE  

Emehr

    River Patroller

  • 4,179 posts
  • Happiness is... a chomping Pac-Man!
  • Location:An obscure body in the SK system

Posted Fri Jul 11, 2003 9:28 PM

I just found out that my red, green, and blue values were incorrect for displaying RGBCMY and white. The new values I use are:


RGBTable    .byte $4E  ;Red

            .byte $CE  ;Green

            .byte $8E  ;Blue


My updated binary:
http://home.earthlin...tella/color.bin

...and the source...
http://home.earthlin...tella/color.asm
http://home.earthlin...ayfieldData.asm

Whee! :D
Jason

#5 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,742 posts
  • Dr.Boo
  • Location:Tasmania

Posted Fri Jul 11, 2003 11:09 PM

I just found out that my red, green, and blue values were incorrect for displaying RGBCMY and white. The new values I use are:


RGBTable    .byte $4E  ;Red

            .byte $CE  ;Green

            .byte $8E  ;Blue




Great work, Jason! It's through experimentation like this that I developed the Interleaved Chronocolor ™ system and tools. For reference (and there's no 'right' or 'wrong' - here are the colour values I used...

RED = %00110100 ; $34
GREEN = %11000110 ; $C6
BLUE = %01110010 ; $72

I may try yours and see how my colour images look :)


PS: Can you figure out what the difference between Chronocolour ™ and Interleaved Chronocolour ™ actually is? It's a minor change designed to reduce the impression of flicker, but still using this system of time-based colour change on a per-scanline basis...

#6 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,119 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sat Jul 12, 2003 1:45 AM

I'm unable to post my .bin to the forum (it was created on a Mac and the forum software doesn't accept it)...

It's not the Mac's fault. The forum software doesn't accept .bin files at all.

:idea: Post it zipped!

#7 Emehr OFFLINE  

Emehr

    River Patroller

  • 4,179 posts
  • Happiness is... a chomping Pac-Man!
  • Location:An obscure body in the SK system

Posted Sat Jul 12, 2003 8:28 PM

As Mac user w/o PC emulation, I rolled my own playfield editor tool for Mac users that should work all the way back to System 7.5 (hey, I had nothing better to do today ;)). It doesn't read picture files, rather it's a graphical editor. Imagine drawing right on the Stella window (at double resolution) complete with the looong 8x1 playfield pixels, eight colors to choose from, height-adjustable pen, and the ability to save to a DASM formatted text file (customizable). It works. All I need to do is teach it how to read the files it creates and make a Read Me for it (not to mention extensive testing/debugging). I'll post it here when I have more than 80% confidence in it. ;)

Anyway, on to the lesson at hand...

Post it zipped!

Thanks Thomas, I'll try that next. :)

PS: Can you figure out what the difference between Chronocolour ™ and Interleaved Chronocolour ™ actually is?


As I understand the interleaved version (from viewing your Mona Lisa fade (nice work BTW!) and from reading your chronocolour.asm file posted to [stella] (thanks, Google!)), instead of diplaying...

frame 0: all Red
frame 1: all Green
frame 2: all Blue

...you're changing the color each scanline. Thus...

frame 0: RGBRGBRGB...
frame 1: GBRGBRGBR...
frame 2: BRGBRGBRG...

Is that correct? I'd love to see it in action on a television set.

Jason Rein

#8 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,742 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sat Jul 12, 2003 8:37 PM

PS: Can you figure out what the difference between Chronocolour ™ and Interleaved Chronocolour ™ actually is?


As I understand the interleaved version (from viewing your Mona Lisa fade (nice work BTW!) and from reading your chronocolour.asm file posted to [stella] (thanks, Google!)), instead of diplaying...

frame 0: all Red
frame 1: all Green
frame 2: all Blue

...you're changing the color each scanline. Thus...

frame 0: RGBRGBRGB...
frame 1: GBRGBRGBR...
frame 2: BRGBRGBRG...

Is that correct? I'd love to see it in action on a television set.

Jason Rein



That is correct. I, too, would love to see it on a TV!

#9 Blackbird OFFLINE  

Blackbird

    Chopper Commander

  • 135 posts

Posted Sun Jul 13, 2003 8:40 AM

You do the same when you display multiple sprites, right? You switch them off every frame, while continuing with the RGB cycle?

#10 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,742 posts
  • Dr.Boo
  • Location:Tasmania

Posted Sun Jul 13, 2003 8:45 AM

You do the same when you display multiple sprites, right? You switch them off every frame, while continuing with the RGB cycle?



I don't quite understand what you're asking. If you are referring to more than 2 sprites per line - no, there are several other methods/tricks used to display multiple sprites - most of them do NOT involve time-based multiplexing.

If you are referring to sprites using the Interleaved Chronocolour ™ technology to get higher colour resolution - the technique is essentially identical to the playfield system, except it's trickier as the sprites need to be displayed at 6 per line - the so-called 6-sprite trick. We'll get to that later in our sprite sessions, which are coming up next!

If I didn't answer your question, please re-ask it in a clearer form.

#11 Blackbird OFFLINE  

Blackbird

    Chopper Commander

  • 135 posts

Posted Sun Jul 13, 2003 7:04 PM

What I mean is, having two 48-pixel sprites next to each other. What you did with your various dancing baby demos, with two dancing babies together. Since you can't have two 48-pixel sprites on the same line, you switch back and forth from one sprite to the other every frame.

The question I was asking was, when you switch back and forth, do you complete the RGB cycle for a single dancing baby and then switch to the second dancing baby (three frames, then switch), or do you switch the dancing babies every frame while the RGB cycle is going on (one frame, then switch)?

There's actually no need to answer now, as I found out by slowing down the framerate in z26, so it is the second method as far as I know. I was asking this because there was much more flicker in the early demo which displayed Wile E. Coyote (GENIUS!), as I think it used the first method. But thank you for answering, and I apologize for my lack of clarity.

#12 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Mon Jul 14, 2003 10:23 AM

Andrew Davie wrote:

Can you think of good ways to draw circles in such an odd screen-size? Hint - make the size of your image the LAST step in the draw process!


1. Create a new blank picture window that is 40 x 48.

2. Zoom in to see what you are doing.

3. Create your shape, playfield, etc.

4. Stretch/skew your image to 40 x 192 before saving it.

#13 Dones OFFLINE  

Dones

    River Patroller

  • 2,273 posts

Posted Wed Jul 16, 2003 12:19 AM

Hello everyone, this is my first time posting here. I have been following the tutorials and have been learning a lot. I wrote a free, small Win9x/XP ultility called AssymRead. It translates windows bmp files into text data for DASM. It offers a simple GUI and some customization features. Hope you find it useful.

Attached Files



#14 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Sun Jul 20, 2003 10:45 AM

Exercise 1 on this session is kicking my butt. I can't get the image to display correctly. My circle was displaying correctly all of the way up PF2 on the right side, and then repeating part of the left side. It looks more like a fish than a circle right now. :D If I add more delay before PF2 is re-written, I end up with spaces between my pixels, and my pixels are all over the place. It is like they are wrapping. Do I need to put delays before the re-writing of PF1 and PF2, or just before PF0?

Also, the bottom half of the screen seems to correct itself before the top part. Do we need different delays for different scanlines? :?

#15 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,119 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Jul 20, 2003 2:42 PM

Also, the bottom half of the screen seems to correct itself before the top part.  Do we need different delays for different scanlines?   :?

Are you reading indexed from a table somewhere in your kernel? This sounds like that table is crossing a page border, causing one exttra penalty cycle.

#16 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Sun Jul 20, 2003 11:40 PM

Thomas Jentzsch wrote:

Are you reading indexed from a table somewhere in your kernel? This sounds like that table is crossing a page border, causing one exttra penalty cycle.


I am reading indexed from tables in the circle.asm file which is referred to by the include statement, like so:

               lda CIRCLE_STRIP_0,x

                sta PF0

                lda CIRCLE_STRIP_1,x

                sta PF1

                lda CIRCLE_STRIP_2,x

                sta PF2

I've been playing around with different delays before PF0, PF1 and PF2 for the right side of the screen. I haven't found the right combination yet, though. :ponder:

#17 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,119 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Mon Jul 21, 2003 1:54 AM

:idea: Try to use align 256 before every CIRCLE_STRIP table.

If that doesn't help, you better post the whole source code.

#18 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Sun Aug 3, 2003 10:43 AM

If that doesn't help, you better post the whole source code.


I've tried delays only before PF0 right, before PF0 right and PF1 right, before PF0 right and PF1 right and PF2 right, and I just can't seem to get it right. I'll improve it one pixel at a time, and one more delay throws everything out of whack. Now I am going to split my code in half and cover only 96 lines at a time with different delays to see if that makes a difference. If you spot something retarded in my code, please let me know. Thanks.


; '2600 for Newbies
; Session 17 - Asymmetrical Playfields - Part 1





                processor 6502

                include "vcs.h"

                include "macro.h"

    
;--------------------------------------------------------------------------

    

                SEG

                ORG $F000

    

Reset



   ; Clear RAM and all TIA registers



                ldx #0

                lda #0

Clear

                sta 0,x

                inx

                bne Clear

    

       ;--------------------------------------------------------------------

       ; Once-only initialisation...

    

                

        

       ;--------------------------------------------------------------------

    

StartOfFrame

    

   ; Start of new frame

   ; Start of vertical blank processing

    

                lda #%00000001

                sta CTRLPF    ; mirror playfield



                

                lda #$AE

                sta COLUBK   ; set the background color





                lda #0

                sta VBLANK

    

                lda #2

                sta VSYNC

    

                sta WSYNC

                sta WSYNC

                sta WSYNC   ; 3 scanlines of VSYNC signal

    

                lda #0

                sta VSYNC



       ;------------------------------------------------------------------

       ; 37 scanlines of vertical blank...

            

                ldx #0

VerticalBlank

                sta WSYNC

                inx

                cpx #37

                bne VerticalBlank

            

       ;------------------------------------------------------------------

       ; Do 192 scanlines of color-changing (our picture)

        

                ldx #0   ; this counts our scanline number
;--------------------------------------------------------------------------



ALine


;                sta WSYNC   ; may remove
;                inx         ; may remove

                lda CIRCLE_STRIP_0,x   ; PF0 left (6 cycles)

                sta PF0                ; 2 cycles?

                lda CIRCLE_STRIP_1,x   ; PF1 left (6 cycles)

                sta PF1                ; 2 cycles?

                lda CIRCLE_STRIP_2,x   ; PF2 left (6 cycles)

                sta PF2                ; 2 cycles?

                

                nop                    ; 2 cycles

                nop                    ; 2 cycles

                nop                    ; 2 cycles

                nop                    ; 2 cycles

                nop                    ; 2 cycles

                nop                    ; 2 cycles
;                nop                    ; 2 cycles
;                nop                    ; 2 cycles
;                nop                    ; 2 cycles
;                nop                    ; 2 cycles
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop



                

                lda CIRCLE_STRIP_3,x   ; PF0 right

                sta PF0

                

                nop                    ; 2 cycles

                nop

                nop                    ; 2 cycles

                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop

                               

                

                lda CIRCLE_STRIP_4,x   ; PF1 right

                sta PF1

                
;                nop                    ; 2 cycles - test
;                nop                    ; 2 cycles - test
;                nop                    ; 2 cycles - test
;                nop                    ; 2 cycles
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop
;                nop

                

                lda CIRCLE_STRIP_5,x   ; PF2 right

                sta PF2

                

                sta WSYNC

                

                inx

                cpx #192

                bne ALine


;--------------------------------------------------------------------------

               ; CLEAR THE PLAYFIELD REGISTERS

                lda #0

                sta PF0

                sta PF1

                sta PF2

            

       ;--------------------------------------------------------------------------

            

                lda #%01000010

                sta VBLANK   ; end of screen - enter blanking

            

       ; 30 scanlines of overscan...

        

                ldx #0

Overscan

                sta WSYNC

                inx

                cpx #30

                bne Overscan

            

                jmp StartOfFrame



                include "circle.asm"


;---------------------------------------------------------------------------------



            ORG $FFFA

        

InterruptVectors



            .word Reset   ; NMI

            .word Reset   ; RESET

            .word Reset   ; IRQ



        END


#19 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,119 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Aug 3, 2003 11:49 AM

If you spot something retarded in my code, please let me know.

I have cleaned your code a bit and added/corrected the cycle counts (@ = total cycles after the instruction).

Here is your code:
ALine                      ;   @07   
; left PF:

    lda CIRCLE_STRIP_0,x   ; 4         

    sta PF0                ; 3 @14     @ < 22, ok   

    lda CIRCLE_STRIP_1,x   ; 4  

    sta PF1                ; 3 @21     @ < 27, ok

    lda CIRCLE_STRIP_2,x   ; 4  

    sta PF2                ; 3 @28     @ < 38, ok



    nop                    ; 2 !   

    nop                    ; 2 !   

    nop                    ; 2 !   

    nop                    ; 2 !   

    nop                    ; 2 !   

    nop                    ; 2 !


; right PF:

    lda CIRCLE_STRIP_3,x   ; 4  

    sta PF0                ; 3 @47     26 < @ < 48, just ok



    nop                    ; 2 !    

    nop                    ; 2 !

    nop                    ; 2 !   

    nop                    ; 2 !



    lda CIRCLE_STRIP_4,x   ; 4  

    sta PF1                ; 3 @62     37 < @ < 54, too late    

    lda CIRCLE_STRIP_5,x   ; 4  

    sta PF2                ; 3 @69     47 < @ < 64, too late 



    sta WSYNC              ; 3
;---------------------------------------    

    inx                    ; 2

    cpx #192               ; 2

    bne ALine               , 2³
So, if you just remove all nop instructions it should work perfect. :-)

Always remember: "You *must* count cycles (correctly!) inside the kernel, else everything will be just try and error." :)

:idea: BTW: While developing, you should use the SLEEP macro instead of nops.

#20 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Sun Aug 3, 2003 12:34 PM

Thanks Thomas! It worked, but the right half of the screen was backward. Then I realized that I was mirroring the playfield, when I didn't need to. I changed this:

               lda #%00000001 

                sta CTRLPF    ; mirror playfield

to this:

               lda #%00000000

                sta CTRLPF    ; do not mirror playfield

and everything works perfect now!


Thanks again,
Sheldon

#21 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Sun Aug 3, 2003 1:09 PM

Hmmm. I have all of my screens containing text working now, but they are upside down. I guess after resizing your screens with the paint program, you have to flip your graphic before saving it and converting it to data with Andrew's FSB (full screen bitmap) program. :D

#22 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,119 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Aug 3, 2003 1:13 PM

It worked, but the right half of the screen was backward.  Then I realized that I was mirroring the playfield, when I didn't need to.

Oops! Trying to solve one problem when there are actually two (or more!) by using try and error is IMO close to impossible (or at least very time consuming).

#23 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,119 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Aug 3, 2003 1:17 PM

Hmmm.  I have all of my screens containing text working now, but they are upside down.  I guess after resizing your screens with the paint program, you have to flip your graphic before saving it and converting it to data with Andrew's FSB (full screen bitmap) program.   :D

:idea: Or you can just count down the x register. :)

#24 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Sun Aug 3, 2003 1:44 PM

I didn't think of counting down the x register. :)

Here is what I ended up with after flipping my graphics vertically:

Attached Thumbnails

  • atari.png
  • circle.png
  • excess.png


#25 Sheldon Sims OFFLINE  

Sheldon Sims

    Chopper Commander

  • 112 posts
  • Location:San Fernando, Trinidad, West Indies

Posted Tue Aug 5, 2003 10:11 PM

Is that correct? I'd love to see it in action on a television set.



That is correct. I, too, would love to see it on a TV!



I just converted Andrew's Chronocolour NTSC bouncing Mario demo and Jason's Color.bin to WAV files using Bob Colbert's MAKEWAV program, saved them onto microcassette, and loaded them up on the "Heavy Sixer" using the Supercharger.

Both of them look GREAT on a real TV. The output through a real Atari and TV beats the socks off of the emulator displaying on my LCD monitor.

I also plugged Andrew's color values into Jason's Color.bin file to see what that would look like on a real TV. Andrew's color values for RED, GREEN and BLUE are a little darker, which causes the word HELLO and the ending exclamation mark to appear a little darker white than when using Jason's color values. Also, the white text appears to blink worse when using Andrew's RGB values.

Since you guys were curious, I figured I would test these files out for you. I hope I explained everything good enough. Let me know if you would like me to test anything else on a real Atari and TV. I can convert a .BIN file up to 4K and load it up on my modified Supercharger in just a couple of minutes. I also have an EPROM burner, EPROM chip, PCB, and blank cartridge shell. Right now all I have is a 4K EPROM chip, so I am better off trying everything in the Supercharger. I'm sure I will end up buying homebrew supplies for 8K and 16K cartridges in the future, but for now, my limit is 4K. :)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users