SeaGtGruff
-
Content Count
5,587 -
Joined
-
Last visited
-
Days Won
2
Posts posted by SeaGtGruff
-
-
They're drawn with the playfield. Using Hack-O-Matic II, it looks like they start at around 0b88.
Michael Rideout
-
Okay, here's my "cleaned up" version, which does more or less the same things that your original code does. (Paddle 0 is getting positioned a little to the right of paddle 1, even though they have the same X position, don't know why.) I added some DIMs so that all variables have meaningful names, and I made a few other changes, so you might want to compare it closely to your original code to see if there's anything you want to change back.
Well, now I'm not checking p against j so it's not bigger than q!
I'm not sure what you're refering to, I saw no J in your last posted code. Was that something in your earlier posted code? I removed the variables that were used to save the player0x and player1x values since there's no real need for them, the bB variables keep their values (unlike registers on a 2600 or 800) so you can just use them instead of having extra variables for them. So instead I added variables for the extreme "good" left and right positions-- p0_l_limit, p0_r_limit (player0 left and right limits), and p1_l_limit, p1_r_limit (player1 left and right limits), which have to be a little bit different depending on the size of the players (i.e., difficulty settings).
As it is, there are a few problems with the code that you need to work out, mostly dealing with how the ball hits the bricks. For one thing, your routine to turn off the bricks when they're hit is turning off only the bricks in row 7. This can be fixed by calculating the bricky position in a similar manner to the way brickx is calculated. Also, it's possible for the ball to hit more than one brick at once, which is why the bricks in the middle don't get turned off when the ball keeps hitting them (the calculation to get the equivalent brick position keeps returning the brick that's already been turned off, since the ballx position straddles two bricks). Also, if the ball hits the side walls without actually hitting a brick, you want to bounce it but not turn off any bricks, so your "hit_something" routine needs to check for that. And I figure you might want to modify the way the ball bounces so it doesn't always go back the way it came (e.g., after the first hit, bounce it down to the left instead of back down to the right).
I wasn't finished with the routine, which is why it's horribly broken. The hardest part about getting a brickrow value is turning bally into a value that corresponds to a row number. Also, the ball going off the bottom isn't quite working yet. bally eventually wraps and the ball appears at the top of the screen.
Yes, I gathered that you weren't finished with that part, so I started to work on it for you, but then I thought, "Whoa, you aren't sure how he wants things to work!" so I took it out (but I saved it first so I can continue on it if you'd like).
For example, when the ball goes past the paddle and leaves the screen, what do you want to have happen? My guess was that you want the player with that paddle to lose their "turn," meaning that ball is gone and the other player starts a new ball into play. For that, you'd need another start_ball routine (e.g., p0_start_ball for when player0 starts the ball, and p1_start_ball for when player1 starts it).
The conversion from the ball coordinates to the playfield coordinates shouldn't be too bad, except for handling when the ball is colliding with two or three bricks at the same time. I temporarily added some code to freeze the ball on collision, and display its coordinates in the score, which helped me find the following values:
ballx = 31 means ball is hitting the left wall and brick 0 simultaneously.
ballx = 32 through 34 means the ball is hitting just brick 0.
ballx = 35 means the ball is hitting bricks 0 and 1 simultaneously.
ballx = 36 through 38 means the ball is hitting just brick 1.
ballx = 39 means the ball is hitting bricks 1 and 2 simultaneously.
etc.
I modified the calculation accordingly, first I subtract 32 from ballx to get brickx, then I divide brickx by 4 (you were dividing by 4 first, then subtracting 8, which is more or less the same thing, but I like the subtract-then-divide better).
My thinking was that if the ball is colliding with two or three bricks simultaneously, then check the ball's direction to see which brick to remove. For example, if the ball is moving left, and hits both brick 3 and brick 4, then remove brick 4, but if brick 4 has already been removed then remove brick 3. Or, if the ball is moving right and hits both brick 3 and brick 4, then remove brick 3 if it hasn't already been removed, otherwise remove brick 4.
I'm not certain of the bally values yet, but I think they're as follows:
bally = 31 means the ball is hitting "air" and row 0 (pfrow 4) simultaneously.
bally = 32 through 38 means the ball is hitting just row 0 (pfrow 4).
bally = 39 means the ball is hitting rows 0 and 1 (pfrows 4 and 5) simultaneously.
bally = 40 through 46 means the ball is hitting just row 1 (pfrow 5).
bally = 47 means the ball is hitting rows 1 and 2 (pfrows 5 and 6) simultaneously.
etc.
So the quickie conversion would be bricky=bricky/8 (so you'll have to add back the "include div_mul.asm" which I took out). But in both cases, brickx and bricky, you need to check whether the ball is colliding with just one brick, or two or three bricks, and then figure out which brick to remove depending on which bricks have already been removed (and perhaps also which way the ball is moving).
For example, if ballx=38 and bally=63, then the ball is hitting just brickx=0 and bricky=7, so there's no question-- remove that brick, it's the only one the ball can be hitting.
But if ballx=39 and bally=63, then the ball is hitting brickx=0 or 1 and bricky=7, so you don't know whether the ball is hitting both bricks (i.e., if neither one has been removed yet), or just one (i.e., if one of them has already been removed), until you check them with pfread.
Or, if ballx=39 and bally=47, then the ball is hitting as many as three bricks at the same time-- brickx=0 or 1, and bricky=5 or 6. You know it can't be hitting all four bricks, because at least one of them must have already been removed in order for the ball to collide with any remaining bricks at just that spot, but since you don't know which brick has already been removed, you have to assume that all four are still there, and check them one by one depending on the ball's movement.
For example, if the ball is moving down and left,
then remove brickx=1,bricky=5 if it hasn't already been removed,
else remove brickx=0,bricky=5 if it hasn't already been removed,
else remove brickx=1,bricky=6 if it hasn't already been removed,
else remove brickx=0,bricky=6.
Or, if the ball is moving down and right,
then remove brickx=0,bricky=5 if it hasn't already been removed,
else remove brickx=1,bricky=5 if it hasn't already been removed,
else remove brickx=0,bricky=6 if it hasn't already been removed,
else remove brickx=1,bricky=6.
Or, if the ball is moving up and left,
then remove brickx=1,bricky=6 if it hasn't already been removed,
else remove brickx=0,bricky=6 if it hasn't already been removed,
else remove brickx=1,bricky=5 if it hasn't already been removed,
else remove brickx=0,bricky=5.
Or, if the ball is moving up and right,
then remove brickx=0,bricky=6 if it hasn't already been removed,
else remove brickx=1,bricky=6 if it hasn't already been removed,
else remove brickx=0,bricky=5 if it hasn't already been removed,
else remove brickx=1,bricky=5.
In other words, you're always removing the first brick that the ball is hitting. For example, if it's hitting brickx=0 and 1 at the same time, then it's hitting brickx=1 first if it's moving left, and hitting brickx=0 first if it's moving right.
PS -- The good news is that I redesigned your make_screen routine in a way that uses up less ROM, so there's more room for additional levels-- although the logic to handle the ball/brick problems mentioned above will eat up most of the saved ROM, if not more than what was saved.
600 bytes saved? Shows how bloated my code is.
Not necessarily. The main savings came from consolidating make_screen so the four rows could be drawn with a FOR..NEXT loop, which I did by making the bricks variables into an array.
I'm not sure yet (haven't tried it), but further savings may be possible by writing directly to the playfield instead of using pfhline. It would certainly save time cycles at least. A while back I worked out how to store the playfield as data, and move it directly to the playfield array, without having to use the pf draw routines. In some cases it uses more ROM (if only a few pf draws are needed to draw the screen), but it almost always saves a whole lot of machine cycles. I'm posting an example that draws a purple castle as in Adventure, to illustrate the process. I'm posting the .asm and .bin files, too, because I had temporarily modified the score digits to spell out "Reventure" (but there's a timing issue in the 6-digit display that causes the "broken" letter in the second position-- the last column of the first digit gets changed to the last column of the third digit because the player0 data gets moved a hair too soon), and you won't be able to see that if you compile the .bas file yourself without using the modified score digits.
Michael Rideout
-
Okay, here's my "cleaned up" version, which does more or less the same things that your original code does. (Paddle 0 is getting positioned a little to the right of paddle 1, even though they have the same X position, don't know why.) I added some DIMs so that all variables have meaningful names, and I made a few other changes, so you might want to compare it closely to your original code to see if there's anything you want to change back.
As it is, there are a few problems with the code that you need to work out, mostly dealing with how the ball hits the bricks. For one thing, your routine to turn off the bricks when they're hit is turning off only the bricks in row 7. This can be fixed by calculating the bricky position in a similar manner to the way brickx is calculated. Also, it's possible for the ball to hit more than one brick at once, which is why the bricks in the middle don't get turned off when the ball keeps hitting them (the calculation to get the equivalent brick position keeps returning the brick that's already been turned off, since the ballx position straddles two bricks). Also, if the ball hits the side walls without actually hitting a brick, you want to bounce it but not turn off any bricks, so your "hit_something" routine needs to check for that. And I figure you might want to modify the way the ball bounces so it doesn't always go back the way it came (e.g., after the first hit, bounce it down to the left instead of back down to the right).
I actually started to add code for these things, but I've removed it so I can post my initial "clean up" version since I don't know how you want the ball and bricks to behave in those situations.
Also, I fixed the positioning of paddle 1, which wasn't being displayed in your original code, so I hope that was okay (maybe you had meant to remove it)? And I added movement for the paddles by reading the joysticks. However, in doing so I discovered that bB has no functions for joystick 1! So I added joy1up, joy1down, joy1left, joy1right, and joy1fire to bB, but then I decided to remark out the lines for joystick 1 for the moment. In any case, I'm posting the include file that has the joystick 1 functions added to it, but I can't upload a file with the .asm extension, so I renamed it to a .bas extension, and you'll need to rename it back to the .asm extension before you can use it.
Let me know what you think.
Michael Rideout
PS -- The good news is that I redesigned your make_screen routine in a way that uses up less ROM, so there's more room for additional levels-- although the logic to handle the ball/brick problems mentioned above will eat up most of the saved ROM, if not more than what was saved.
-
Well, I could try to clean up the version I started, and post it for you, but it sounds like you've already added a lot more to the game. If you want to post an updated version of the source, I could un-spaghetti-fy it for you.
Michael Rideout
-
Wow! I think I'm in the first two pictures, which show the games set up with the TV sets. I have my back to the camera, and in both pictures I'm the guy directly to the left of the lady who's walking around.
Michael Rideout
-
Did you see my reply from Oct. 21? The problem was being caused by a reference to a line number that didn't exist. So in making other changes, you probably fixed the line number problem without realizing it!
Michael Rideout
I fixed that and it still didn't work, I figured out I was checking variable M, which I never set.
The line number problem is what was causing the compile error, but you're right that the program still wouldn't run (even though it would at least compile) after the line number was fixed. I had looked at your code, and tried to reorganize it or clean it up, but I was kind of busy with other things and didn't have time to figure out everything you were doing, so I put it aside. I'm glad you got it working again. I can post my unfinished version of the reorganized code if you want, keeping in mind that it doesn't run correctly.
Michael Rideout
-
Did you see my reply from Oct. 21? The problem was being caused by a reference to a line number that didn't exist. So in making other changes, you probably fixed the line number problem without realizing it!
Michael Rideout
Hey SeaGt... I guess I'm a little slow. It took me until now to realize that your avatar is the Swordquest Fireworld chalice, and that you won it back in '84.
http://www.geocities.com/TimesSquare/Lair/9260/sqfw.html
Do you still have the chalice?
Yes, I still have it. When I joined AtariAge, I couldn't think of anything else to use as an avatar.
Michael Rideout
-
Did you see my reply from Oct. 21? The problem was being caused by a reference to a line number that didn't exist. So in making other changes, you probably fixed the line number problem without realizing it!
Michael Rideout
-
Hmm, I thought there was an interesting sense of color familiarity in the BSOD!
By the way, Foebane, I like your avatar-- it's an image from TMCOG, right? I have almost all of the series on tape, except I screwed up and missed an episode or three somewhere near the end. :-(
Michael Rideout
-
If you have an 8-bit Atari or equivalent emulator installed, you can check out a large library of images in ColorView (aka COLRVIEW) format. This technique was developed years before Andrew glommed onto it, renamed it, and oh-so-cheekily TM'd it.Maybe you should remember your own posts.
The thing about any flickering technique is that... well... it flickers! So even though these demos and games that use flickering are extremely impressive, I think it's best to keep the number of flickered frames to a minimum (i.e., two rather than three), and to keep the amount of flickered colors on the screen to a minimum, otherwise the results can be too distracting to the viewer/player.
As for "discovering" techniques that other people have already used, well, it's happened to me in both directions. I was experimenting with "Super IRG" mode some ~10 years before it was apparently given that name, but IIRC my inspiration for it came from something I'd read in "Mapping the Atari," so undoubtedly there were other people out there who'd done the same thing before I tried it; and since I didn't write an article about it or give it a name, I can't quarrel with anyone else for "discovering" and "naming" it several years after I used it privately. But I do know that when I "discovered" it for myself, I kept thinking "Why isn't anyone writing games that use this technique?!?" I never wrote/finished one, so more power to anyone who did!
I have a bit of a quandry with this right now, because I've just spent the last few nights working on graphics for a "Dragon Warrior" demonstration that relies on the "flicker/dither"... harumph, I mean "Super IRG"-- technique to get a pretty decent representation of a "Dragon Warrior" screen (on the 8-bit emulator), but really, what's the point? What I mean is, I can finish it and post it to show that a fairly accurate A8 port of "Dragon Warrior" is possible, but if it could never be published anyway, then it would be far more productive to use the technique to create an original game. I've been working in Paint to draw the screen, which I'm now coding for the A8, but even though the picture wasn't done directly on the A8, it should still look pretty close on it, because I picked and mixed the colors on an A8 emulator and saved the screenshot in interlaced mode, then used those color values in the Paint program... although of course it could make a big difference what the palette settings are, and the picture won't look the same on a real Atari as on an emulator, because the colors mix a bit differently. Still, I'm going to post the Paint picture so people can see what I've done. The screen uses a 13x13 map, with each "block" (2x2 characters on a Nintendo) being drawn as a 3x2 block on the Atari, to get 12 pixels across and 16 down in each block-- really 13 and 1/3 blocks across, and 26 lines of GRAPHICS 12 characters to get 13 blocks down. For the blocks that have animated characters/sprites in them, I ended up using a solid background rather than trying to show the terrain behind/underneath the sprite, since my picture assumes that the P/M graphics will be used at quad-width to get a sixth "underlay" color which will replace pixel color "00" in those blocks where the "00" color is from the P/M graphics rather than from SETCOLOR 4. And since each "block" is only 12 pixels across rather than 16, my A8 conversion isn't exactly the same as the Nintendo version. But these pictures should still give an idea of what could be accomplished with flicker/dither.
Michael Rideout
-
I am growing more interested in trying my hand at coding games for the A8. The sad part is that I know nothing about it. I have been reading a few of the books on atariarchives.org over the past few days and I am slowly picking up on a few things but I have yet to try anything. Could anyone here recommend the best books to read to learn how to program games for this system? Someone recommended that I begin with learning basic and go from there. Is this a good idea? Any suggestions would be greatly appreciated.I would prefer if someone who actually does indeed know what they are talking about could reply. Thank you.
Should you learn BASIC first? Well, BASIC will let you get started right away, so you can play around with the graphics to see how the different modes work, etc. But BASIC doesn't let you control the Atari the way assembly does. On the other hand, assembly isn't as immediate as BASIC is. So each has its own strengths and weaknesses. But without a doubt, assembly is probably what you'll want to end up programming in, because it's so much more powerful than BASIC. This doesn't mean you shouldn't start with BASIC, though, and there's no reason why you can't learn both at the same time. In fact, you can write assembly routines and call them from within BASIC programs if you want.
If you don't know much about the Atari 800/XL/XE, you'll definitely want to get a good book about its memory locations, such as "Mapping the Atari." It might not help you get started with programming the Atari, but it will be an invaluable reference that you'll turn to again and again as you learn to program the Atari.
Also, it makes a difference whether or not you already know anything about programming in general (i.e., on any computer or in any language, not just on the Atari in particular). For example, the Compute! books on Atari are okay for learning about different tricks, but you'll get more out of them if you already know how to program. So if you're just getting started in programming, any good beginner's textbook about whichever language you're interested in-- BASIC, assembly, Forth, C, etc.-- might be helpful, whether or not it specifically deals with the Atari. Of course, if you're learning assembly, then you'll want to get a book about 6502 assembly, since that's what the Atari uses. And if you're learning from a book that doesn't deal specifically with the Atari or its version of a given language, then you might need to compensate for any differences between the version of the language that's described in the book versus the version that's available for the Atari (e.g., Deep Blue C doesn't have everything that C++ does).
Aside from that, the best thing to do is to have a pretty clear idea of what you want to accomplish in a game, and be familiar enough with the Atari's features and capabilities to know if or how you can make it happen on the Atari. That is to say, you might have a fabulous game idea, but it might not be possible to do it on the Atari in the exact manner that you've envisioned, so if you're familiar with what the Atari can do (including advanced techniques that let you push the Atari past its usual limitations), then you'll be able to rethink your game vision to reshape it into a more workable plan.
Above all, I recommend just tinkering with little snippets of code to experiment with different features and techniques. Some of the books may help with that, but nothing beats just pure imagination. For instance, back in the '80s I experimented with the "flicker/dither" technique, and I created simple displays in GRAPHICS 12 that expanded the number of available colors by blending the five colors that are available in GRAPHICS 12. If I remember correctly, my inspiration for this was something I'd read in "Mapping the Atari." I started designing some graphics for an adventure game using this technique, but then my disk drive broke and I put the Atari aside so I could focus more on the Amiga. Just recently, I found out that someone made a game using that same technique, in 1998 I think, and he gave the "new" graphics mode the name of "Super IRG"! So you shouldn't stick to just what the books say, but try to think of how to combine different features or techniques in ways that might not be specifically described or demonstrated in the books. Chances are, there are other people out there who have already tried it, or are just beginning to try it, so you might be able to get pointers or suggestions from them. (I wish I'd had access to a forum like AtariAge back when I was first learning about the Atari!)
Out of curiosity, what sorts of games are you interested in programming, and which books have you been reading about the Atari?
Michael Rideout
-
All very interesting stuff. I thought I'd chime in and mention that the mario demo I did a long time back, now, also included a SECAM version which looked, for all intents and purposes, identical to the PAL and NTSC version. The trick I used was to dither the 1-bit colour-separated images (that is, separately dither (stucki) each of the red, green, and blue subcomponents of an image). If you haven't seen my chronocolour demos, you really should dig them up -- some are quite impressive even today.Cheers
A
Hi, Andrew! Are you talking about flickering three frames together-- one with red dithering, one with blue dithering, and one with blue dithering? If so, I've heard of that idea before, but have never tried it or seen it in action. I'll do a search for your chronocolour demos, they sound intriguing.
Michael Rideout
-
What you are describing is artifacting, a phenomenon which may be used when the dot clock is a multiple of the chroma clock (2x on the Atari 8-bits or the 7800; 2x or 4x on the Apple) and which is nothing but trouble on machines where color is line-synchronized but the dot rate doesn't match chroma (e.g. old Commodore 64's). On the 2x machines/modes, even pixels will appear different colors from odd pixels. On an Atari machine that can show 4 colors in 320-dot mode, it is entirely practical to use artifacting to generate 16 colors. There is some flexibility in choosing what those 16 colors are, but not total. Basically, just pick different combinations of four colors and see what combinations of 16 colors they yield.
I'm not talking about artifacting in GRAPHICS 0, where each pixel is only half of a color clock. I mean dithering in a high-res GRAPHICS mode (e.g., GRAPHICS 15) where each pixel is a full color clock.
Several years ago, I started working on the graphics for an adventure game, using brown, white, yellow, red, and blue as the basic colors in GRAPHICS 12 (red for bits 11 with normal characters, and blue for bits 11 with inverse characters). By choosing the right hues and luminances for the colors, I could get a pretty decent light green (blue and yellow) and dark green (blue and brown) to create, for example, a landscape of trees-- light green for the grass, dark green for the foliage on the trees, and of course brown for the tree trunks.
Dithering can be used with many patterns, but to get the appearance of new solid colors that are mixtures of two real colors, the pattern should be a checkerboard, with the colors in the pattern being alternated from one frame to the next (correct technical term should be field, but if the picture is noninterlaced, then each field is a frame). Without flickering between alternating color patterns, you just get a checkerboard dither of two colors, as in the standard paint programs for the Atari.
You can also make checkerboard patterns between a real color and a mixed color, which looks like the checkerboard dither of a standard paint program except one of the colors comes from a mixture. Or you can create dithers where the dots have a 75%-25% mixture rather than a 50%-50% mixture. So for example, if you start with yellow and red and your two real colors, you could get seven mixtures between yellow and red, with the middle mixture being a "solid" color:
100% yellow
75% yellow, 25% orange
50% yellow, 50% orange
25% yellow, 75% orange
100% orange (yellow and red mixed by dithering and flickering)
25% red, 75% orange
50% red, 50% orange
75% red, 25% orange
100% red
I used to have a demo screen that I made on the XL/XE which displayed a color wheel with real colors, "solid" mixtures, and dithered patterns between the "solid" mixtures and real colors. I programmed it so I could turn the flickering on or off by pressing a certain key, and the difference between the two was nothing short of dramatic. With no flickering, the same color mixtures listed above would be:
100% yellow
87.5% yellow, 12.5% red
75% yellow, 25% red
62.5% yellow, 37.5% red
50% yellow, 50% red
37.5% yellow, 62.5% red
25% yellow, 75% red
12.5% yellow, 87.5% red
100% red
On a TV, there may be some artifacting involved which creates "color bleeding" (don't know what else to call it) that helps to further blend the colors when using a dithered pattern in a high-res color mode, but I'm not talking about GRAPHICS 0 artifacting, and I haven't heard anyone use the term "artifacting" when describing the dithered checkerboard pattern that is commonly used in Atari paint programs to mix two colors together.
I experimented with artifacting in GRAPHICS 0 and GRAPHICS 8, but I was never able to create the "16 colors" that I had read about, just four artifacted colors which could then be dithered together.
These sorts of techniques are very easy to implement on an 8-bit Atari if you trick the Atari into thinking it's using a different GRAPHICS mode. For example, switch to GRAPHICS 8, POKE 87 with 9, and you can PLOT and DRAWTO using COLOR values from 0 to 15, the so-called "16 colors" that you get from artifacting. What you actually get are 16 combinations of four artifacted colors, but you can combine this with flickering to make the mixtures look more "solid." However, as long as you're just getting four artifacted colors that are being mixed together, it makes more sense to me to use four real colors in a high-res color mode. On the other hand, the artifacted colors are not the same as the Atari's real colors, and by using different hues and luminances with GRAPHICS 8 you can get different artifacted colors, so it might be interesting to combine GRAPHICS 8 with GRAPHICS 15 using a custom display list, and use flicker/dither with the GRAPHICS 8 lines to get some colors that aren't quite the same as if you were using GRAPHICS 15.
Michael Rideout
-
Okay, I used the wrong term, I guess an easy way to remember it is "factor" = multiply. The term I should have used is "triangular number." The number of different combinations of 128 colors is as I said, 129 * 64 = 8256. This assumes that two combinations are considered to be equal if they involve the same colors (e.g., color 30 mixed with color 46 is the same as color 46 mixed with color 30).
For example, the SECAM 2600 has only 8 colors, so the combinations are
color 0 mixed with color 0, 1, 2, 3, 4, 5, 6, or 7 (8 mixtures),
color 1 mixed with color 1, 2, 3, 4, 5, 6, or 7 (7 mixtures),
color 2 mixed with color 2, 3, 4, 5, 6, or 7 (6 mixtures),
color 3 mixed with color 3, 4, 5, 6, or 7 (5 mixtures),
color 4 mixed with color 4, 5, 6, or 7 (4 mixtures),
color 5 mixed with color 5, 6, or 7 (3 mixtures),
color 6 mixed with color 6 or 7 (2 mixtures),
color 7 mixed with color 7 (1 mixture),
= 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1
= (8 + 1) + (7 + 2) + (6 + 3) + (5 + 4)
= 9 * 4 = 36 mixtures
The general formula is (X + 1) * X / 2, as Thomas said.
*However*, in actual practice the number of *discernible* mixtures produced can be considerably less than that, depending on the colors being mixed, and the method being used to mix them. For example, the GIF image I posted for the 8 SECAM colors (created in a paint program rather than on a real Atari) shows 36 mixtures, but some of them look very similar to each other. Using RGB color space to illustrate, mixing red [1,0,0] with green [0,1,0] produces dark yellow [.5,.5,0]-- the sum of the RGB values divided by the number of colors being mixed. Thus, mixing red [1,0,0] with cyan [0,1,1], or green [0,1,0] with magenta [1,0,1], or blue [0,0,1] with yellow [1,1,0] produces the same color-- gray [.5,.5,.5]. This assumes that the colors are being mixed as completely as possible, or as a single pixel. With flickering, or with alternating colors via interlacing, the original colors are still somewhat visible, so the mixtures may appear slightly different.
Applying this to the NTSC Atari's 128 colors, we can say that the mixture of two colors is the sum of the hues, divided by 2, and the sum of the luminances, also divided by 2. This isn't quite right as far as the hues are concerned, because it matters which hues we're talking about (e.g., hue 1 mixed with hue 15 is *not* hue
. Nevertheless, in theory,color 0 (hue 0, luminance 0) & color 14 (hue 0, luminance 14)
= color 2 & color 12
= color 4 & color 10
= color 6 & color 8
= "color 7"
The amount of flickering will be different, but if we could mix those colors exactly (and if the luminances follow regular steps), then the results would be the same.
Adding in the hues, we get similar results. For example,
color 20 (hue 1, luminance 4) & color 38 (hue 2, luminance 6)
= color 22 (hue 1, luminance 6) & color 36 (hue 2, luminance 4)
= hue "1.5", luminance "5"
Keeping in mind that the flickering is least when the hues and luminances are closest together, the best (least flickery) results are obtained by mixing adjacent hues and adjacent luminances.
So for any given hue, we can get 15 luminances-- the 8 luminances which the Atari can produce for that hue, plus the 7 luminances which are halfway between them (i.e., luminances 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, and 14).
And we can get something like 46 hues-- the 16 pure hues, plus 15 hues between the 15 pure colorful hues (i.e., hue 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5, 10.5, 11.5, 12.5, 13.5, 14.5, and 15.5-- where "15.5" is hue 15 mixed with hue 1), plus another 15 hues which are the 15 pure hues mixed with hue 0.
Putting these together, we get something like 690 colors (15 luminances of 46 hues). Obviously, these aren't the *only* possible combinations. And if we can mix the colors using dithering along with flickering (as I've successfully done in the past on the XL/XE computers), we can get some pretty good mixtures using hues that are nonadjacent. For example, mixing blue with brown can produce dark green if we pick the right shades of blue and brown (think of brown as "dark yellow"). So it's pretty difficult to calculate the exact number of *practical* combinations that can be produced, but it's safe to say that it will be considerably less than X*(X+1)/2.
Unfortunately, all of this tends to work better on a TV than on a monitor, and it tends to work better with TVs that have lower resolution than with TVs that have higher resolutions-- at least, that's been my experience. This is due to the "color bleeding" that tends to occur when the TV has a lower resolution, especially when you dither two colors together using the smallest pixels that the Atari can produce.
Michael Rideout
-
I don't know to what phase RSYNC resets the horizontal clocks, but I suspect doing a proper interlaced vertical-sync signal would require a bunch of RSYNCs at 38-cycle intervals. Note that horizontal sync must continue unabated; just adding a single RSYNC to every other frame to cut a scan line short by 38 cycles might work with some monitors, but not others; turning on VSYNC mid-scan-line is also apt to yield dubious results.I haven't been able to try interlacing on a real Atari, but I reviewed the Stella-list posts about interlacing several months ago, and when it was first demonstrated by others it was shown that RSYNC wasn't needed (IIRC). I don't know about modern TVs or computer monitors, but the only thing that was needed a few years back, when it was first demonstrated in Stella-list, was to turn on VSYNC at the correct time, depending on whether the even or odd field was being drawn.
By the way, many years ago I was obsessed with getting more colors on my 8-bit Atari (600XL, 800XL, 65XE, and 130XE). I successfully mixed colors very well by combining flickering with dithering, which is easy on an 8-bit but very difficult on a 2600 (because of the difference in resolutions, plus the difference in the graphics features). Anyway, I found that colors could be mixed fairly well by using flickering with alternating scan line colors, rather than using dithering, but the results weren't quite the same. For example, a RYRYRYRY checkerboard pattern flickered with a YRYRYRYR checkerboard pattern creates a pretty good solid orange (but it tingles if you move your eyes), whereas alternating RYRY lines flickered with YRYR lines also produces orange, but it looks slightly different. This is due to the bleeding of colors that results when colors are put side-by-side on a line, such that using a dithered checkerboard design mixes the colors a little bit more because the colors bleed together on the TV screen. Without dithering, there is no color bleeding (if that's the right term to describe it), so the flickering still blends the colors, but they don't look the same. Dithering isn't really feasible on the 2600, unfortunately.
Michael Rideout
-
By the way, if you mix X colors, you don't get X-squared combinations, since some of them will be the same (e.g., yellow-red and red-yellow produce the same mix). You actually get X! colors (if I have the notation correct)-- that is, "X factorial" (if I'm using the correct term).
For example, mixing 8 colors gives you 8+7+6+5+4+3+2+1, or 36 different mixes.
So mixing 128 colors gives you 128+127+126+...+3+2+1, or 64*129 = 8256 different mixes.
Michael Rideout
-
When you mix colors by flickering, the results are better (i.e., less obvious flicker) if the colors being mixed are close together in hue or luminance. For example, you could mix hue 2 (yellowish-orange) and hue 3 (reddish-orange) to get more of an "orange-orange," or you can get 15 shades of a particular hue by mixing two consecutive luminances (i.e., luminance 0 and 2, or 2 and 4, or 4 and 6, or 6 and 8, or 8 and 10, or 10 and 12, or 12 and 14).
Creating an interlaced display can be either good or bad for mixing colors. On the plus side, the combined scan lines will be closer together. But on the minus side, the colors that you're trying to mix won't be drawn directly on top of each other, so they won't mix together as well.
By the way, as I understand it, there's no need to use RSYNC when creating an interlaced display. All you need to do is draw 262 complete lines (on an NTSC 2600), then start drawing a 263rd line, but turn on VSYNC halfway through the line. Obviously, this means you'll need to count machine cycles or color clocks so you'll know when to turn on VSYNC. The next field should automatically begin with half of a scan line, so you'll need to keep that in mind when you're counting the scan lines (i.e., the first line is not a full line, so don't start counting until *after* the half line). Then, at the end of the second field, turn on VSYNC as soon as the last line has been drawn.
Last year I started to write a game called "Quest for the Lost Pyramids of Atlantis," which I've put aside for the time being, but my plan was/is to have NTSC, PAL, and SECAM versions combined in one game, controlled by the difficulty switches. And I was using interlacing to get more colors in the SECAM version. After I made a few test screens, I started working on the title screens, which implement the interlacing, etc. I'm attaching my last working copy of the title screens, which can be displayed in NTSC, PAL, or SECAM. All three versions use an interlaced screen, but only the SECAM version uses the interlacing to mix colors.
To run it on the z26 emulator, use
Z26.EXE -g7 -v3 -! LSTPYR1H.bin
for SECAM, use
Z26.EXE -g7 -v3 -1 -! LSTPYR1H.bin
for PAL, and use
Z26.EXE -g7 -v3 -0 -! LSTPYR1H.bin
for NTSC. If you run it for the SECAM version, you may need to use the "-" key to switch from the PAL palette to the SECAM palette (which should show yellow letters on a red screen, with red and black mixed together on the bottom part).
If you can load it into a Cuttle Cart or Krokodile Kart on a real Atari, set the left player difficulty to "hard" for NTSC. Set the left difficulty to "easy" for PAL or SECAM. The right difficulty chooses between PAL and SECAM-- "easy" is SECAM, and "hard" is PAL. At least, I think that's correct! I can't test it on a real Atari, just an emulator, so I have no idea how well it works on a real Atari, if at all!
And the title screens are kind of boring, but if anyone can test it on a real SECAM 2600, at least they can tell us how well the interlaced color-mixing works (if at all).Michael Rideout
PS-- I'm also attaching a picture I made in a graphics program to try to see how interlaced colors might look on a SECAM 2600. It simulates interlacing by using alternating colors. I should be able to create an actual binary that would show the same sort of display on a real Atari, if anyone with a SECAM 2600 is interested.
-
I was browsing an 8 bit magazine disk last night and it had an article on Russian multiplication, and how it can be used for very fast binary calculations.It works as so: C = A * B
Take the operands A and B, and place them into a row. For each new row, double A and divide B by 2 (discarding the remainder). Keep doing so until a value of 1 is reached in the B column
Then, derive the result © by adding up the values in the A column, but only where the B column value is odd.
Examples (values of B marked with # are ignored in the final calculation)
23 x 14 # = 322 46 7 92 3 184 1 === 322 = 46+92+184 (sum the values of A, only where the B column value is odd) 17 x 53 = 901 34 26 # 68 13 136 6 # 272 3 544 1 ==== 901 = 17+68+272+544
Thanks to 6502 shift/rotate instructions, this algorithm can easily be incorporated into programs to multiply 2 8-bit numbers for a 16-bit result. Very handy for games or demos needing quick calculations for graphics.
I did a quick Google Search and dug up some links:
http://mathforum.org/dr.math/faq/faq.peasant.html
Egyptian division: http://www.mathforum.org/library/drmath/view/57574.html
Division would be great too. The formula used is a similar concept, and could also be fairly easily programmed.
Thanks, Rybags, this is very cool, and it rings a bell from my computer science classes back in college.
Michael Rideout
-
A quick primer may be in order here. When addressing in indirect mode, the CPU is actually using 2 zero page locations to determine the final address. So, when writing to address 88:LDY #10 LDA #33 STA (88),Y
You are actually using addresses 88 and 89. Memory address 88 is the low byte, memory address 89 is the high byte. Basic code to do the same thing would look like:
Y=10:SCREEN=PEEK(88)+PEEK(89)*256:POKE SCREEN+Y,33
Of course, the register Y is a byte, so you can only go 255 characters onto the screen using this technique. I remember running into this in Compute's old Machine Language for Beginners book, which was a pretty good introduction 6502 assembly code, but not so good for Atari specific items (Since the other computers of the era tended to have a screen always located at a fixed location in memory).
What you need to do is when you want to go past the 256 character, is bump the high byte. However, modifying address 89 is probably a bad idea. So, you should make a copy, and use that.
LDA 88 ; Make our own copy of screen address STA $C0 LDA 89 STA $C1 LDY #10; print a character at location 10 LDA #33 STA ($C0),Y INC $C1 ; Bump high byte, same as "adding" 256 to Y STA ($C0),Y; print a character at location 256+10 LDY #5 INC $C1 STA ($C0),Y; print a characater at location 256+256+5
This probably only makes sense if you are writing a routine to be called from BASIC. If you are writing a game or an application that has a custom display list, you would arrange you own display memory instead of using locations 88 and 89. It is then pretty common to use a look-up table to calculate the screen position.
Does that help? If you would like an example using a look-up table I can write one up for you.
Just a thought, maybe you could pass your assembly routine the column and row number you want to print to, and have it calculate the screen position from there? Or, you could also add the length, if you are printing long strings to the screen. Not sure what/how/why you're doing this, so don't know what suggestions would make sense/fit in with your needs.
Michael Rideout
-
Yes, that's correct, as long as the players are positioned appropriately, such as
Player 0 horizontal position = 48
Player 1 horizontal position = 80
Player 2 horizontal position = 112
Player 3 horizontal position = 144
Player 4 horizontal position = 176 *
* When using this technique, it's convenient to combine the four missiles into a fifth player.
Michael Rideout
Actually, it makes more sense to position player 4 first, followed by the other players. That way you have your players set up in the order they appear in memory space.
Using the 5th player has some advantages, but it depends on what your color needs are because it uses a color register already used in antic 4 (COLOR3 to specific).
I find that once the initial positions are set for the four missiles, it's easy to write to them as a unit because they share memory space, as if they are one player already.
I was disassembling my routine that uses P/M underlays in GRAPHICS 0, and I see that that's exactly the way I had done it. And I didn't actually combine the missiles into another player (color-wise), since I was setting all four players to the same color anyway, but they were positioned so as to create another player in effect:
48 for M3
56 for M2
64 for M1
72 for M0
80 for P3
112 for P2
144 for P1
176 for P0
It's murder trying to disassemble my routine to debug it, because I can't find my original notes, but I think my problem may be emulator-related. If I remember correctly, it was working great with one emulator, then I installed a different one and the program stopped working. It might be the way certain things are set, as I've discovered that some of my programs won't work correctly unless I have a particular setting enabled (mainly the "ROM patch" setting). Also, about the same time that I was downloading different emulators, I was also downloading different OS ROMs, so there might be a problem there.
Once I get my routine disassembled and commented, and get it working with the emulators again, I'll post the disassembly.
By the way, can anyone recommend a good disassembler? I'm using dis6502 1.9, but it doesn't seem to have all the features (menus and options) that are shown in the documentation for an earlier version. Part of my problem was getting the file into a format that would disassemble, since it's a raw binary file without headers, so I had to hack it to add the headers so it would even load into the disassembler. And the "dump" window doesn't show anything, so I can't tell the disassembler which bytes are data, and it tries to disassemble them. I've saved the listing and am now editing it in an IDE, but it would be nice if dis6502 would load raw binaries that have no headers, and let me edit the disassembly listing.
Michael Rideout
-
This may have been true 20 or 30 years ago, but modern NTSC TV's are very sharp and very good and stable color. Easily twice as sharp, if not more, as those 3 decades ago, and most modern NTSC TV's go beyond the traditional 640x480 resolution too, as do modern TV shows and recordings. If you ever watch TV land channel on cable, you will quickly notice that the recording resolution of the old shows from yesteryear are much lower as well, this dual effect of 30 year old TV's and 30 year old recording standards is what made NTSC TV of yesteryear look so inferior to PAL of the day. This margin in NTSC vs. PAL color is now minute or non-existant today.
Actually, modern NTSC uses a different colorspace than older NTSC, from what I've read. The older NTSC colorspace was YIV, now it's YUV like PAL, so it would seem to make sense that the margin between them is much less today. But the way I understand it, the problem with NTSC color instability is (or was?) due to the way the frequencies or signals were combined. Of course, that's probably been improved on, too (one would hope).
Michael Rideout
-
Yes, that's correct, as long as the players are positioned appropriately, such as
Player 0 horizontal position = 48
Player 1 horizontal position = 80
Player 2 horizontal position = 112
Player 3 horizontal position = 144
Player 4 horizontal position = 176 *
* When using this technique, it's convenient to combine the four missiles into a fifth player.
Michael Rideout
I was going to refer you to a programming utility (if it can be called that) which I posted a few months ago, to display up to 96 colors (97 counting the border) in GRAPHICS 0, using P/M underlays and DLIs. However, whenever I try to run it on an emulator, it crashes, so I need to debug it to see what's wrong, because it used to work like a champ! All I can figure is something got corrupted, or there's a typo in the machine code listing, etc.
Michael Rideout
-
1
-
-
Yes, that's correct, as long as the players are positioned appropriately, such as
Player 0 horizontal position = 48
Player 1 horizontal position = 80
Player 2 horizontal position = 112
Player 3 horizontal position = 144
Player 4 horizontal position = 176 *
* When using this technique, it's convenient to combine the four missiles into a fifth player.
Michael Rideout
-
Actually, that's just about the way it always looked on my (unadjusted) NTSC Ataris, but some of the other colors in that screenshot look a little off. Hue 4 was always more of a red on my NTSC machines, with just a tiny hint of violet, and hue 15 was more of a greenish-brown.
According to the documentation, NTSC hue 1 is supposed to be the same color as the NTSC colorburst frequency. And according to some docs I saw on the web about NTSC television and the NTSC colorspace, the NTSC colorburst frequency is yellow with a hint of green.
Michael Rideout
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
James Bond 007
in Atari 2600
Posted
I used HexView to look at the 4K .bin, it says "PJOE GAUCHER LOUIS MARBEL" near the end of the code (but maybe the first P isn't part of the names?). The 8K .bin says the same thing.
Michael Rideout