supercat

I wonder if it would be practical to include a REAL mouse interface in the next AtariVox-or-whatever gizmo that comes along? Games would have to be programmed to take advantage of it, but it shouldn't be too hard to make something a game could simply poll when convenient for an X/Y/button readout.

When I ported my "Wormy" jingle to the 2600 (quite a few years ago, actually) I wrote a PC program in which I specified the 'importance' of different pitches and then had the program search for the least awful tuning. That actually worked pretty well after I tweaked things a few times. Too bad Atari wasted silicon on the RESMPx circuit instead of adding a 1/2/4/8 prescalar circuit to the sound generators.

What about having the user point the stick in the desired direction, but without the stick providing thrust? Use one side button (selectable which one) for thrust, the other for fire, and the 'any key' on the keypad for hyperspace.

On the Commodore 64, you could select up to 4 players even with only two joysticks; the other two players would use keyboard for bidding. Since you've got joysticks and buttons, it would seem possible to do the same sort of thing, albeit awkwardly, on M.U.L.E. Especially if the real goal is to have all four "players" cooperate to achieve the best colony score.

Don't be shy, my code often doesn't look any better. 883117[/snapback] I recall reading an interview of (IIRC) John Carmack and he was reluctant to release the QuakeC source code for ID's new game not because of fears people would do unauthorized ports, but rather because people would see how sloppy he was. Some parts were sorta cute, though. IIRC... if (player.inwater) cprint(" sleeps with the fishes."); else if (enemy.classtype==ENEMY_DOG) cprint(" was mauled by a rotweiler."); else if (enemy.classtype==ENEMY_ARMY) cprint(" was shot by a grunt."); ... else /* Hell if I know--he's just dead */ cprint("died."); Been ages since I looked at the code, but I still remember that comment.

Your 'calculator', however, can't really determine what is musically the closest fit. Sure it might give you numbers that are closest in frequency to the correct notes, or it might even go so far as to suggest what key to transpose the piece into for a least-squares fit of sorts. But getting good music on the 2600 generally requires going beyond that. In some situations, a note which is 35 cents sharp might sound horrible and selecting a different pitch entirely might sound better. In other cases, the note which is sharp might actually sound okay and changing it would disrupt the melodic flow of the piece. Your 'calculator' is very unlikely to know the difference. Also, while some people's opinions may differ, I tend to think that percussion on the 2600 is good for smoothing over intonation problems. That plus it sounds cool.

It would probably be possible to come up with something that could produce an arbitrary collection of games which were limitted to Combat-style objects and playfields. Such games would tend to be regarded as not very interesting. Trying to get graphics beyond the level of Combat or Adventure gets tricky. The games that manage the best graphics have very carefully-crafted restrictions about what objects can appear where, and then use clever tricks the programmer used to take advantage of those restrictions. Crafting a good game on the 2600 requires a good understanding of programming and of fun, to ensure that the restrictions in gameplay don't prevent the cartridge from being enjoyable.

This is why I thought 30Hz flicker would be a good goal. Basically, to send out a bomber in frame 1, what you would do would be to create a single missle in frame 1 and set the frame 1 "bomber" flag and bomber X position (possibly Y position, if you can afford to make it variable). Before the display kernel, if the bomber flag is set for the current frame, if the X and Y positions of the missle are both less than those of the bomber, set the Y position of the missle to the bomber altitude minus a little bit. Then during the kernel, set the player 1 position to the bomber's X coodinate. When about to draw the 'main' part of the frame, check to see if the bomber flag is set. If not, use the normal kernel. Otherwise, use a two-part kernel. First part shows players 0 and the ball normally, but doesn't show player 1 or missle 1. Middle part shows players 0 and the ball along with player 1 (the bomber). This then falls into the normal kernel which is used for the remainder of the frame. Voila--now there's a plane that drops bombs. If the bomber is destroyed before the missile has become visible, the missile should be silently (and scorelessly) destroyed as well. If the bomber is destroyed after the missile has become visible, its horizontal position should be set to zero but the bumber flag should remain set until the missile is destroyed. Once the missile is destroyed, the bomber flag should be cleared when and only when the bomber is also destroyed or flies off screen. A bit of magic, but it should be workable.

Definitely! Gotta use that somewhere else some time. I think Activision have the effect in Dolphin and/or Stampede. Certainly in Dolphin; probably in Stampede as well. Star Wars ESP uses it for the walkers' legs, and various other games use for other sorta-big objects. Hm... I admit I may be lazy here and there as well. When a game is almost done, I get pretty reluctant when someone suggests more or less a total rewrite. Ask Thomas about that, he always tries that Well, none of my 2600 kernels have been overly complex, but I sometimes rewrite them between one version and the next. My seven-color paint kernel, for example, was limitted to making the cursor be red or icky-yellow. By totally rewriting it, I was able to make the cursor be any color I want. Sometimes code can get pretty convoluted to deal with that sort of thing. Yeah, it's a pain. I've actually never used skipdraw (heresy?) but instead try to figure out what all I'm going to be doing for a certain section of display so as to minimize the number of conditionals within it. Probably much easier with some game designs than with others. Well, I like the striped playfield even though it's simply easier to draw than a solid one. I think my biggest graphics peeve is probably the fact that balloon and string are the same color. That and the fact that my balloon is always popping.

It would seem that the TIA uses a four-bit counter and five 4-bit comparators to handle the HMOVE circuit, in addition to having to have the five divide-by-160 units and the sequencing logic for the HMOVE. Doesn't that seem a little overcomplicated to you? Perhaps there's something in the hardware that makes it simpler than it sounds, but some of the quirks suggest that they did not use any of the simplifying approaches I can think of. I find this puzzling, actually. I would think the simplest way to handle the hardware would be to have four derived signals during hblank which pulse (non-overlapping), one, two, four, and eight times. Just AND these signals with the appropriate bits in the HMxxx register and use that to add clocks. When I said "count" to 160/168, I didn't necessarily mean using a binary ripple counter; I meant simply have a circuit which produces one output pulse every 160 or 168 input pulses. While the counter circuitry used to generate scan lines may divide by four and then divide by 57, the sprite circuits clearly divide by 160, since it takes 160 pulses to move them an entire line. This is a total guess, but I would suspect Gunslinger, Air-Sea Battle, etc. used this feature. It required virtually no silicon to implement and allows the programmer to turn a bit on and have the player object control it's corresponding missile while the player is moving. Therefore, I would suspect sofware wouldn't have to do any housekeeping of a missile object until it is fired. Again, that is a hunch...I do not know that for certain. Air Sea battle might possibly use it, though there's really no point since the player's gun is always in the same spot. Most other games care about the shot X position, and would thus have no problem manipulating it directly. The delay registers are necessary for many useful effects, though the term "vertical" is a misnomer. I find it interesting that the function is implemented using a mux instead of simply forcing the second register to act as a transparent latch when the delay is disabled. Eh, rambling is fun. BTW, my biggest wish-list item on the 2600 would probably be a circuit which would generate four pulses per scan line and allow the user to have one, two, three, or all four routed to the sound circuitry. Would greatly improve the 2600's otherwise-attrotious intonation.

Interesting idea, but just because you don't see it, doesn't mean it isn't there. The collisions will still happen Yeah, I'd forgotten about the collisions, but those'd only a problem for the playfield, not the ball. Unless you think someone's going to sneak through the one-pixel gaps in the ball. So you could still save a little on the ball positioning logic. You can still INY (or whatever register you like) six times within the unrolled loop. That's ~ 10 bytes extra for each shape/HMOVE table, as you'd need to pad on both sides. Besides blowing up the data, it'll complicate things again on other ends, as this data will no longer fit into pages and stuff. I'd not looked at your allocation to see how it's laid out. A tradeoff indeed. I choose to go another route. In my cost/gain analysis a somewhat better looking magnet ain't worth all the fuss involved to get there (Not even considering the required ~500 extra bytes of ROM.) Aw, my magnet was cute. :-) Still, your point is well-taken. Not everything that can be done, should be done. On the other hand, I do find myself thinking that you got a lot more out of the display system in Gunfight and Starfire than you do here, so there oughta be room for a little 'extra'. Though perhaps with Gunfight you weren't concerned with leaving ROM for more levels.

How about making the game wait until the joystick is released following the end of a level or balloon pop?

Is there any way to set Z26 so it'll flag a glitch if a frame is the wrong length? I know it has a function to show the number of scan lines and frame rate (though I'm puzzled by why 263 scan lines shows up as 62.xxHz), but that won't show if any individual frames are off-spec.

Most people would regard it as intolerable; indeed, it's the primary reason the game is so despised. As noted, the approach to get 30Hz flicker with the plane is simple. Have it only appear when it can drop a missile, which is to say when either (1) there is at most one group of missiles on screen, or (2) at least one of the groups of missiles on screen has only a single missile and it's targeting something other than the rightmost city/base, and the timing is right. In the former case, the plane occupies the opposite frame from the group of missiles that's on the screen. A new missile is created which will reach the height of the plane at the same time as the plane reaches its X position; display of the missile and collision-detection for it will be inhibited on scan lines above the plane [alternatively, the height of the missile could be locked at the top of the screen until the plane reaches the right X coordinate, whereupon the height would be set to that of the bottom of the plane]. The latter case would be trickier, but might add some variety. Here, the plane would only appear once because NUSIZ would be zero. The plane would have to be timed to be 32 or 64 pixels to the right of the missile when its altitude reached the bottom of the plane. From that point on the frame downward, NUSIZ would be set to 1 or 2. This approach would be trickier than the first, since the timing on the plane would have to be correct. Could still be pretty cool, though.

Ah. I'd figured you would have unrolled the inner loop three times to eliminate annoyances like division by three, etc. A time-space tradeoff to be sure, but it pays off big. This would get you down to one ENABL every six scan lines (use COLUBK to hide the ball and playfield on the unwanted scan lines). That plus eliminating some extra playfield writes on the blank rows should free up enough cycles to add more stuff. BTW, the design of the magnet demo was predicated upon the idea that in a six-line kernel, one will have time on some scan lines but not others; the magnet moves could be done when time was available. Well, the loop overhead goes down to once every six scan lines if you unroll the loop, and some other things get simplified as well. If you add a little padding on the balloon data, you can get by with checking the Y coordinate once every six scan lines instead of every scan line. Indeed, there are all sorts of tricks that become available when loops are unrolled.

Unlike some other video systems which generate RGB and then turn it into composite, the TIA (and all other Atari 8-bit video systems as well) generate luminance and chrominance signals directly. The only way to turn that into RGB is with a chroma decoder of some sort. If you want optimal quality, the best approach would probably be to use five sample/hold circuits. The first three should take the composite signal and sample it at different phases of the chroma clock. The last two should be sample the outputs of the first two at the same time as #3 is sampled. If you get the timings right, this should yield a smear-free RGB signal that's pixel perfect.

It would most certainly have a lot to do with the above. I'll have to play around with that, since being able to move eight pixels left could be useful.

Too bad Mario can't get very far. I'd not looked at her critically, but agree with you. Using missle 0 to give her brown hair (and thus letting her skin be a more reasonable shade) would probaly have improved her considerably. Since there's no action on those scan lines, cycles should be available. Well, the elevator and conveyor screens both have fireballs, IIRC, and they should probably be made capable of climbing ladders. If that's done there, I'd see no reason it shouldn't also be done on the rivet screen.

Look earlier on this thread. I'd say there were three main issues with the O2: -1- Most of the on-screen display objects must be drawn from a pool of 64 shapes, most of which are rather bland. -2- The display documentation warns that bad things will happen if display registers are written mid-frame, but some games apparently do so without ill effect, so the restriction doesn't seem to be absolute; I don't know what the actual rules are. -3- There was little third-party interest in the game until it was too late to matter. Some of the later games show that it's possible to do a lot of things with the O2 that its designers never dreamed of. Unfortunately, the O2's situation didn't get beyond that the 2600 was in back when Atari was cranking out all the different variations of Combat and Air Sea Battle. Indeed, I would expect that if you had shown a lot of O2 games to Atari's programmers/engineers back in the late 1970's, they would have thought the O2's games were far beyond anything their unit could do. Fortunately for the Atari, a lot of programmers weren't content to live within the 2600's limitations so they worked around them.

Mr. Frye being the author of the first Atari Pac Man? If he was in a good mood, I'd think he'd give a four-word answer to the effect of "Four kay six weeks" (or whatever his time limit was).

Really? What all is the kernel doing? In each group of six scan lines, the kernel writes each playfield register eight times, COLUBK twice, GRP0 six times, GRP1 six times, HMP0 six times, and HMOVE six times. Thirty-four writes. If each of those writes takes an average of ten cycles, that's 340 cycles out of 456. What am I missing?

Unlike most video chips which uses a position register for each sprite and have logic to check when the beam reaches the specified position, the 2600 uses a different scheme (which possibly saves a few transistors, though given some of the weird stuff they added to deal with it I don't know how much it really saves). Each sprite on the 2600 has a counting circuit which will trip every 160 pulses. Normally there are 160 pixels on a scan line, and so the counter will trip at the same location every scan line. This would be all well and good if all you wanted to do was display a sprite at whatever position it powered up at and never wanted to move it. In practice, though, being able to move sprites is nice (well, actually pretty much essential for making any sort of playable game). There are two ways to move the player sprites and the ball, and three ways to move the missiles. The first way to move any of these objects is to write to a special location, called the object's "reset address", which will cause the object's counter to be zeroed. This will cause the object to appear on every scan line at whatever X coordinate the electron beam happens to be. It is fairly easy to position objects to within +/- 7 pixels of any desired position (a 15-pixel range) by executing a variable delay loop before hitting the object's reset address. With trickier code, accuracy can be refined to +/- 1 (a three-pixel range). Placement more precise than this is not possible when using the reset address alone. Because the designers of the Atari figured people would want more precise object placement than would be allowed using just the reset addresses, they added a ludicrously complicated bunch of circuitry which may be called the "hmove circuit". The HMOVE circuitry does two things: -1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period. In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right. -2- It disables counting (and video) for the first eight pixels of a scan line. This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-). There are many other weird and wacky intricacies with the TIA, and it must have had a somewhat interesting evolution (I don't think counting to 160 is really any easier than counting to 168, and if the counters did the latter there'd be no need to blank the first part of a display line when performing an HMOVE. BTW, method #3 for moving missles is to program the hardware to trigger a reset of the a missle position counter when its corresponding player sprite has just output its fourth pixel of display data. Combad uses this when the player fires, but I really don't know of much other usefulness for this feature. Seems a waste of silicon that could have been better used elsewhere.

The 2600's restrictions go much deeper than that. I posted earlier exactly what the 2600 has to work with. A few cartridges can go beyond the restrictions listed (Galaxian does admirably) but generally you get exactly what I listed and nothing more. If one were coding for an 8K or larger cartridge, one could certainly do better than what Garry Kitchen did in 4K. On the other hand, if Garry Kitchen were coding for an 8K or larger cartridge, he could probably have done better as well. The barrel screen is IMHO just fine. Some things could be improved slightly, it looks pretty decent. The biggest thing to investigate would be smoothing Kong using the sprite-shift technique in which selected pixels of a double/quad sprite are shifted to the right by one/two pixels. Since nothing movable appears in that part of the display, this would be feasible for a comparatively modest code expenditure (probably about 30 bytes). The biggest problem with the game is the rivet screen, where the issue isn't graphics but gameplay. My personal design recommendation would be to assume full-time 30Hz flicker on the monsters and give each monster a two-level range of motion. This would improve gameplay interest considerably without being unreasonable to code. Unfortunately, the code to let the monsters use ladders would almost certainly push the cartridge beyond the 4K ceiling. The "wicket" screen would certainly take more code space than would be available on a 4K cartridge, but would otherwise not be a problem. The mudpie screen would be doable if the fireballs were not allowed on the same lines as the mudpies, and provided that all the mudpies on a row moved in the same direction. Some other 'tricky' restrictions would also apply to the mudpies, but they're too complicated to discuss here. Could Mr. Kitchen have done better given a larger budget of code space and time? Certainly. Given what he had to work with, is the result unreasonably bad? I think not.

At the local arcade, the repair guy uses a butane iron. Not quite sure why (it's not as though there's no electricity available) but he seems to like it.

That's why I'd think it would require an 8K cart, though actually I just had an even simpler idea (which would probably also require an 8K cart :-( since there's not a whole lot of code space) which would be to recognize that the whole point of a plane/satellite is to drop a missle, and so there'd be no point in having one come out when both "frames" of missles were already occupied. Thus, with 30Hz flicker the plane/satellite would be in-frame with a "single" missle. If this could be done and still fit within 4K that'd be cool. On the other hand, since even that would probably push things beyond 4K one may as well bite the bullet and use multiple kernels to eliminate satellite flicker. Though I just had another thought on that subject: if one were really clever, one could have a single missile come down and be timed so that a plane/satellite would "drop" a second or third copy. The copy dropped by the plane would have to be the rightmost one unfortunately, but the effect could still be somewhat neat and it would make the gameplay less "wimpy" than only allowing one set of three missiles on screen when the plane/sat was on.