supercat

Incidentally, in some banking schemes like 3F or X07, "NOP 0" or "BIT 0" may cause an undesired bankswitch. "NOP 128" is probably safer.

How are you keeping track of the worm segments? A tapeworm-style game is unlikely to get very hard unless the worm can get quite long, and the 2600 doesn't really have a whole lot of spare RAM.

Cool indeed, from a historical perspective. I would very much second the notion that the batteries should not be left in the cart. It may be worthwhile to try to preserve the labels of the batteries (either by removing the labels, or gutting the batteries and storing them separately from the cart) to allow comparisons if other similar carts turn up. At minimum, preserve or copy down any markings that look like a date codes, serial numbers, etc. The actual guts of the batteries are 100% worthless, though.

It's true that different parts of the TIA use different clocks, but I would regard the TIA more as a collection of synchronously-clocked subsystems than a bunch of asynchronous ripple logic. Synchronizers are generally used when subsystems driven by slow clocks feed signals to those driven by faster ones; there are a few interesting race conditions: -1- sprite motion pulses are derived from sysclk/4, and are or'ed with a gated version of sysclk. In normal use, the motion circuitry will never have the /4 and /1 clocks enabled simultaneously; if they are both enabled, the timing of every fourth motion pulse will be skewed enough to cause distortion in the displayed sprite. -2- at pixel 79, the playfield color mode will get switched a little early, with the interesting effect that despite the output synchronizer, pixel 79 will often end up showing the right color on one half and the wrong color on the other. In general, though, the TIA is pretty straightforward. I've never looked at ANTIC, GTIA, etc.

Actually, I'd say the reverse is true, in a sense. Many devices today use fully static designs driven by a clock which has minimum high/low times and a maximum rate, but no other requirements. Some devices use an internal clock multiplier which will only operate within a certain range of speeds, but the device logic itself doesn't care whether it's clocked fifty times per second or fifty million times per second. If the clock stops for a second, or even a year, the device will remain in the state it had just after the last clock pulse, and will resume functioning as soon as clock pulses start arriving again. At any given moment, all bits are securely "held" by part of the circuit. The operation of such a device might be likened to bucket brigade in which nobody lets go of a bucket until the next person has grabbed it. Dynamic logic, by contrast, has far more rigorous timing requirements. If those requirements aren't met, things can malfunction very badly. A dynamic design might be likened to a line of people who are juggling objects among themselves. Each object that is passed will be released by the old holder before it is caught by the new one. If the new one isn't in proper position to catch the object, it will fall on the floor. Of course, actual people who are passing objects can adjust their timing if needed, but imagine a line of robots who were all wired to operate in tandem from the same control signals. If the timing on those signals isn't right, things will all come crashing down. That having been said, there are straightforward ways of implementing dynamic logic and tricky ways, and nearly all of the TIA's dynamic logic fits the straightforward pattern: two-phase non-overlapped clocking. Most of the circuit modules in the TIA receive two clock signals which run in the sequence (low low) (high low) (low low) (low high). When a clock is high, the chips connected to that clock will drive their outputs according to their inputs; when the clock is low, the output will 'float'. An output which is floating will hold its state for a few microseconds; the output must be re-driven (meaning the inputs must have the correct data to do so) before that time is up. Two-phase non-overlapping clocks are pretty straightforward provided two requirements are met: -1- The two clock phases must never be high simultaneously; their separation must be sufficient to allow all the devices controlled by one clock to switch off completely before any of the devices controlled by the other clock switch on. -2- Neither clock phase may be allowed to go for too long without being active. While the TIA contains two three-bit ripple counters, a divide-by-three for the CPU clock, and some two-phase clock generator circuits and miscellaneous latches, most of the chip is controlled via two-phase non-overlapping clocks.

IMHO, it is useful and interesting to know the precise definition of colorburst being 1000/1001 times 30 frames/sec * 525 lines/frame * 227.5 cycles/line. That doesn't mean someone who doesn't specify it to the ninth place is "wrong", but merely that it's useful knowing where numbers come from. I still think that 1000/1001 multiplier is 'odd'; I understand that it's useful to have a number of clocks per line pair that's a multiple of small numbers (455=5*7*13) but I'm not sure why they chose 455 and then threw in the 1000/1001 kludge, rather than simply picking a different multiple (e.g. 495=5*9*11, or 429=3*11*13, or 441=3*3*7*7)?

The first few levels should be visually identical to the originals, except for the copyright notice at start.

I would expect there to be lots of undocumented registers, but for them not to be memory mapped; most of them will typically work together to mimic the behavior of documented "registers" that don't actually exist in the documented form. I'm not familiar with the CTIA/GTIA, but to borrow some examples from the original TIA... -1- The documentation shows that each sprite has a divide-by-160 counter. The documentation does not show that each sprite actually has a cascaded divide-by-four and a divide-by-forty. Usually, the cascaded counters behave like a divide-by-160, but the synchronization logic gets tripped up if a sprite is reset within a small window of its normal trigger point. -2- The documentation states that there is a pulser circuit which adds and subtracts pulses. It does not mention that the subtraction of pulses is achieved by delaying the end of hblank, nor does it mention that there is a four-bit counter that counts once every four pixel clocks except that if it's sitting at zero it will remain there until the next HMOVE. The documentation also does not mention that each sprite has a latch which turns its pulser on and off, and that this latch may be 'jammed'. -3- The documentation does not describe the particular behavior of the shift registers used in the audio generation circuitry. Though it accurately describes what any particular AUDCx mode will do in isolation, the description is not sufficient to know what will happen if AUDCx is changed while a sound is playing. All of those behaviors are the result of incompletely-documented registers. I'm sure many more examples could be found for the TIA.

I really like the mazes in Adventure. In some games like Zork and Crystal Caverns, the mazes are essentially a randomly-linked collection of rooms. There is no realistic way of trying to explore them short of making a map, and there is nothing remotely logical about the interconnections. In Adventure, by contrast, the mazes make sense at least on a local spacial level. Go east from one room and--with few exceptions--you will proceed into a room whose west end connects to it. As one first starts to play Adventure, one will find oneself wandering aimlessly, but the different parts of the maze are sufficiently visually distinct that one will soon learn to recognize "Ah, this is that really annoying passage that goes on forever until it reaches that stupid dead end." Few games have mazes that work so well. Your attitude seems to be a little condescending. I would expect appreciation for more advanced games that build on the concepts of Adventure is probably a result of your having experience with the simpler ones. Before people had any exposure to even simple games, there was no way they would have been able to have any fun with more complex ones. I recall liking E.T. back in the day, though I never owned it (friends did). I really don't care for the style of game where you need to be directly on top of a zone to see it, especially if repeated playing is of no particular use in determining where things are apt to be. I don't mean to imply that everything should be placed identically in every game, but that the placement of objects and zones should make some "sense", so that one who plays the game enough will be able to recognize certain patterns. BTW, what do you think of Superman? In some ways it's more advanced than Adventure (despite having come out first) but I would regard Adventure as the better game. Adventure's mazes make sense in a way that Superman's city map really doesn't.

For some applications, a high-impedance (at least a meg or so) audio amplifier can be a useful diagnostic device. When playing a paddle-based game, the paddle input should have a 60Hz saw wave whose volume will be controlled by the paddle. If something else is heard, that would suggest a problem.

I know what you're talking about with Adventure. Not sure why it works so well, but it definitely does. Better than Superman, IMHO. All the mazes make sense 'locally' even if their interconnections won't fit on a 2d map. Going north then south, or east then west, will almost always take you back to the same place (I think there are some exceptions involving the bridge, but that's it). And the handling of the killer ducks is brilliant. If your character merely died, I don't think they'd be nearly as scary, but instead you get stuck.

For one function you use the red button on the controller. What button would you use for the other function? Using two controllers is not a friendly solution (HSW did that in the game before ET). BTW, the use of the button in the pit is indicated by the "levitate" icon.

A write to HMOVE triggers a latch that does three things: (1) it sets a another latch which is cleared at the end of each scan line, and which will delay the start of the visible portion of the next scan line by eight pixels (effectively pushing all sprites right 8 pixels); (2) it turns on a pulsing circuit for each sprite; (3) it starts the position-compare counter if it's not already running. Every four pixel clocks (1.33 CPU cycles) each pulser circuit will compare its HMxx with (position-compare-counter xor 8 ) and shut off if they match. Then the position-compare counter will be incremented if it's non-zero or if HMOVE was just written. After those things are done, every sprite whose pulser is enabled will receive a motion pulse. Motion pulses received during the visible part of the frame will distort a sprite's image but not move it. Each pulse received during horizontal blanking will move a sprite one pixel leftward. If an HMOVE occurs on cycle 73 or 74, all of the motion pulses that result will occur during the blanking interval, but the latch responsible for blanking 8 pixels of the next line will not get set (thus, outputting 0-15 pulses will cause sprites to move 0-15 pixels left). If the HMOVE occurs before cycle 73, one or more of the pulses will occur during the displayed part of the frame and the sprite will not move as far left as expected. If an HMOVE occurs within a few cycles of its normal time, the system may manage to output all of the required motion clocks during the blanking interval. If the HMOVE occurs too late, some of the motion clocks will occur during the displayed part of the frame and thus not cause motion. The more motion clocks need to be sent, the earlier the HMOVE must begin.

Sometimes "unstable" behaviors can be caused by race conditions. There is at least one race condition on the TIA that is readily observable. Enable SCORE mode and turn on bit 7 of PF2. The right half of pixel #79 may be an odd color; the exact behavior seems to depend upon temperature and other weird factors. The problem in that case is that the color circuitry for COLUP0 is being disconnected from the color multiplexer at the same time as the color circuitry for the right half is being connected, and both actions are happening while the output from the multiplexer is being sampled. COLUPF isn't supposed to affect the color of that pixel, but sometimes it does.

To get 640x200 one would need to have 320-dot resolution on the chroma. The Atari 8-bit machines don't. Certain hues will cause the left half of the even pixels and the right half of odd pixels to be brighter than the right half of even pixels and the left half of odd pixels, but without the ability to split pixels I'm not quite sure how that would be useful. It might be possible for the Atari 2600 to create a kinda-sorta 320-dot high resolution effect when used on a black and white television set, but I'm not sure how useful that would be. A somewhat more interesting possibility would be to use color cycling to create a visible motion effect on black and white televisions. In a game like "Adventure", for example, one castle and its key could have increasing cycling hues while another had decreasing hues. On a black and white television, one would have stripes that would move rightward, while the other would have stripes that move left.

According to an email I received from Mr. Robinett, Atari wanted a Superman game, but WR wasn't particularly interested in doing one, so Atari gave the code to someone else to turn it into Superman. I don't remember getting a sense of whether Mr. Robinett felt or expressed any gladness that he was off the hook for Superman, or unhappiness that the first release of his kernel would be in someone else's game. BTW, was Warren Robinett's "Basic Programming" cartridge the first release with David Crane's text kernel, or did Stellar Track come first? None of David Crane's own released games used the text kernel, though it appears in a Boggle prototype.

Hey, Porky's had nudity, and that was even sold in 'ordinary' stores.

You can do pretty much anything with a cart while executing from the internal RAM on the 2600. Indeed, on some carts there are things that can only be done safely when running from internal RAM.

With the game hacked for invincibility, it is possible to get through far more enemies than would be even remotely plausible in an unhacked version. There is no level advance.

To compute the integer square root of any number from 1 to 65535, one need only compute the square root of numbers in the range 16384 to 65535. A 192-entry table (one entry for each 256 units of range) could be used to get an answer within +/-1 of the correct result. So do the rough lookup and then refine it.

I would suggest buying it, reading the manual, and printing off a set of overlays to put near the controllers. Although the cartridge is severely hamstrung by the 2600's limited RAM (half of which is available to the user) and keypad controllers, it's interesting to see what the 2600 can 'almost' pull off. The cartridge allows the user to open up windows showing the interpreter stack, the values of all variables, the code being executed with the current token highlighted, etc. If this cartridge had been designed as a teaching tool for the Atari 400 (with more RAM and something resembling a keyboard) such features would have made it interesting. Even if it just had an extra 128 bytes of RAM and a 6x8 keyboard, that would have improved things a lot. Even as it is, though, I still think it's neat to see the 2600 put up a pretty-darned-reasonable-looking text display.

Any good algorithm will require much more code, and much larger data tables, than would fit in 4K or even 64K. Further, a modern PC is over 1,000 times as fast as the 2600; a move that takes a second on the PC would take many minutes, if not hours, on the 2600.

There are no inexpensive DIP-based PLD's that include 128-bytes of RAM (indeed, I don't know if any such PLDs exist, period). Using a PLD plus an external RAM and ROM would be possible, but I know of no inexpensive PLD which would be suitable for that task and is available in DIP form. There is a chip that could be used which would include bank-switching, RAM, and ROM all within a single inexpensive chip, but it's only available in surface-mount. The latter chip will probably be used for 2600 carts in the future, but that design isn't finalized yet.

I'm sure that adding some extra RAM and ROM would allow for a better chess game, but one would have to spend hundreds of hours of effort to still, at best, turn the 2600 into a rather mediocre chess player. When Atari's chess cartridge made its debut, it was cheaper than any other chess-playing machine on the market. Today, there are programs available free that are far better than anything the 2600 could dream of accomplishing even with a 70MHz ARM as a coprocessor.

BTW, it's probably too late for this idea to be useful, and it's probably not practical anyway, but I may as well suggest... would it be practical to make a daughterboard that would plug into the space occupied by the ROM on an Atari cart? I would guess it would be necessary to use surface-mount, but such a thing would have two advantages over using a new PCB: -1- It would be a smaller PCB, and wouldn't need gold fingers. -2- Though it would require more labor to assemble than a normal PCB, the labor required to destructively remove a ROM and solder a header to two boards might be less than the labor required to non-destructively remove a RAM and solder it into another board. The approach might have been fairly nice (albeit pointless) for some older cart PCBs that had two rows of holes with all the cartridge signals; one could destructively remove the old ROM without unsoldering it and connect the new board to the other holes. It doesn't look like Atari's SARA boards have the extra holes, though.