supercat

How about using the Playfield and Ball to draw a nice big digit behind the score table showing the player's rank from the last game (if applicable)? A 7-segment-style digit could be done without requiring any CPU cycles during the score-digit-display kernel.

I wonder if the Sears Pong unit pictured had 8 angles like the arcade? I saw an Atari Pong unit which featured 8 angles, but the Sears 4-in-1 I had when I was growing up only had 4 angles (I would guess it used the ubiquitous GI chip). Given that the case design was essentially the same as the Atari, I wonder why the step back?

The BTP2 music driver can play four channels (two out of each TIA channel), with reasonably decent pitch accuracy and a five octave range. It does gobble up some ROM and CPU cycles (46 cycles/line, and nine pages worth of tables) but the audio quality is pretty decent. EBTBTP2 could be even better, though--stay tuned.

How about using 13 characters but dropping the rank? If you display 10 scores, in order from highest to lowest, do you really need to label them 1-10?

Was the use of 2600 form factor on 7800 carts simply a cost-saving measure? I think the "image" of such carts might have been improved if they'd been bigger (a suitable cartridge port design could handle either larger or smaller carts without difficulty).

I don't know what the first games in development were, but I don't see any reason why Atari would want to release a "Pong" only cartridge. The whole purpose of the 2600 was to be better than the dedicated systems. Atari released Video Olympics so that people who wanted to play the style of games provided by older systems could do so, but they wanted very much to avoid having the 2600 be seen as a "glorified Pong machine". That having been said, I do find the naming of "Video Olympics" and "Pong Sports" to be somewhat curious. Given the naming of other Atari/Sears cards, I would have expected those names to be interchanged (with Atari using its trademark on its own cartridge, and Sears using the more whimsical name).

If a company wants people to buy its product, it should allow them to experience some real benefit from doing so. Purchase should be fast and easy, and the overall experience (from finding the product to using it) should be better than that of getting an illegitimate copy and using that. IMHO, record companies made a major misstep in trying to act like tough guys. They ensured that they were perceived as evil corporations, and thus many people felt no objection to stiffing them. A better approach would have been to recognize that "sampling" music was fine to a limited extent, but to make clear that people who listened to thousands of copied songs while buying none should be regarded as leeches. Toward that end, rather than trying to use various schemes so that media must be proven authentic in order to be usable, the record companies might have been better served to instead focusing on means by which media could be proven authentic even though it would play regardless. Such optional schemes then would provide a social benefit to the legitimate users without socking them with the hardships imposed by mandatory ones. There is one wrinkle in all this I should mention, btw: to accept digital distribution would have required a significant shift in major record companies' business model. Historically, signing with a record label has been the only way for many bands to get public exposure via the radio cartel. Consequently, the record labels could pay musicians peanuts while they themselves made millions. As things like Internet broadcasting have taken off, it has become possible for many bands to ignore the major labels and manage their own publicity. Of course, that would pose a problem for the major record labels even if none of their records were ever illegally copied. Piracy provides a nice excuse for trying to shut down Internet distribution, but it's not the major driving fear.

Generally not possible. Many SuperCharger games require that significant amounts of the cartridge RAM be writable. That just plain isn't going to happen on an EPROM-based cart.

Actually, I've posted ages ago in various forums about a way content vendors could have allowed digital video to be handled with greater security for the content vendors but far less CPU power for the users, but unfortunately they use a silly bloated sequence of decrypt-decompress-reencrypt in the PC, followed by decrypt in the monitor. A much easier sequence would have been to create a 'side channel' on the video display that would send encrypted data between the display and the DVD drive. The PC would neither know nor care about the details of the encryption between the two devices. It would just tell the PC or drive what it wanted to display, and shuffle data between the two devices so it could happen. The DRM companies could freely reveal the control protocols and allow people to write drivers for Linux or any other operating system; since the PC wouldn't have to know how to unscramble the data, there wouldn't be anything in the drivers to reverse-engineer.

How did teletypes and display terminals compare in price?

Too bad they didn't do that reduction without creating those holes. By the look of it, the holes are there because both halves of the cartridge were cast with two-piece molds that opened front-to-back. The part of the mold that formed the keys had to be able to escape without breaking the newly-cast plastic. I would think they could have avoided the holes if the front of the case held the board and included the top; the back of the case would contain the keys and could then slide on from the bottom. A rib running top-to-bottom through the center of the back would support the board and would also provide a place for a counter-sink screw in the front to hold the two halves of the cartridge together. The back of the cart would be formed with a mold that separated top-to-bottom rather than front-to-back, and it would be necessary for the screw to cut the hole and threads in the bottom-piece rib, but those shouldn't be particular problems.

How about 1-3-2 or 2-3-1? 1--212-21 or 12-212--1

I wonder how they'd look if you used black and white mode, or else used blue as the background? Not sure you can really tell without real hardware, alas.

With some sound chips, rapid modulation of a frequency register between two values will yield a reasonably clean tone whose frequency is between those the values would produce provided that the modulation occurs at a steady rate which is significantly above the frequencies in question. The TIA is not very amenable to such techniques. Each sound channel on the TIA operates by taking a 31.5Khz signal, putting it through a programmable counter/divider (controlled by AUDFx), and feeding that into a wave shaper circuit controlled by AUDCx. Each divider contains a 5-bit counter, comparator, and reset circuit. With every pulse of the input clock, the counter will be compared to AUDFx and the result of that comparison is latched. If it didn't match, the counter will be incremented; otherwise, the counter will be loaded with zero and a pulse will be output to the wave shaper. One nasty consequence of this design is that if, e.g., both AUDFx and the counter equal '6' but the comparator result hasn't been latched yet, and the programmer writes '5', the counter will have to count all the way to 31 and wrap before the next pulse will be output. If a program keeps track of the counter state, it would be possible to avoid writing to AUDFx when the counter was about to reach its terminal count. On the other hand, if the program is keeping track of counter state, why bother with AUDFx at all? Why not just write the desired waveform out to AUDVx directly?

Thanks. It was hard getting all 26 frames of animation for the elf, but Nathan Strum really did a great job with his character animation and his toy designs. If I do a sequel to TT, I may go back and add some more toys, since I couldn't use all of Nathan's great toys in my first game. As for 'original era' games with beautiful graphics, Dark Chambers and Centipede both have gorgeous title screens. Airlock's is pretty good by 2600 standards, too (too bad the rest of the game isn't). Grand Prix has gorgeous looking cars, and Dolphin manages some very nice looking sprites. Spitfire Attack and Space Chase both have a pretty good initial 'wow' factor, though the wow factor of the latter wears off after a few seconds. According to Rob Fulup, his Demon Attack was the first game where a professional artist was hired to do the graphics. Boy did it show. Those demons look great compared with the usual programmer-designed graphics of other games. On the other hand, what games have better looking ducks than Adventure?

I agree to some extent, though if Mythicon was planning to profit by selling game carts for $10 they must have been planning to make a whole lot of them with minimal unit cost. On the other hand, Froggo was also a low cost seller and their carts used a 74xx along with, IIRC, an OTP 2764, so package parts can't have been that horrendously expensive. I wonder if anyone had any ideas for what the second game would be in the Firefly Series, Sorceror Series, or Starfox Series?

I would think the best way to handle a cell that's in thermal runaway is to simply ensure that there's nothing flammable nearby, and that there's adequate ventilation to clear out any noxious fumes. If one could force a damaged cell into thermal runaway someplace it could burn away without damaging anything, that would seem like it would probably be the safest way to neutralize it, but I don't know how best to do that.

Just remember that according to the inventor of Duff's Device (no relation to Homer's favorite beer), Pi seconds is a nanocentury.

They're slow because there's no real demand for machines using that architecture to be faster. When Apple migrated to the PowerPC architecture, that eliminated any real need for 68000-based machines to run at speeds comparable to high-end PCs. Too bad, because I would expect that if the money put into accelerating the 8x86 architecture were put into the 68000 series, they'd do even better.

What's the best way of disposing of a battery pack that may be compromised? Set it outdoors away from anything flammable in a bucket of salt water to discharge it, or would that just make it more dangerous?

Donkey Kong running and Pac Man dying?

Good idea, but doesn't it increase the temptation for third party publishers of the day to minimize their risk and develop for the 2600 first, then add a few bells and whistles for the new system, and sell the same game again? A lot of popular arcade games really couldn't be done terribly well on the 2600. A version of Millipede for the system I described would likely have very little code in common with the 2600 version, for example. As to whether developers would have supported the new machine, who knows. Not sure Atari would have seen third-party development as a good thing, though.

Yeah. The exact number of cycles you have to wait depends how the object is being moved. The worst case is trying to move 7 pixels left with a convention HMOVE (or 15 with an 'early' one). The best case is 7 or 8 pixels right (or 0-1 left with an 'early' move); in that case there's no restriction.

You raise an interesting point. With most types of products, either the consumer investment will be slight, or the expenditure required to support consumers will be slight (people may spend hundreds or even thousands of dollars on a TV set, for example, but not demand much from the manufacturer other than to repair units that fail within the warranty period). If a company introduces a product and it sells poorly, the manufacturer can simply drop it and nobody will object. The 5200, by comparison, was a big investment from which consumers expected Atari to supply continuing dividends (in the form of new games). Certainly the 5200 was not the first game machine to be abandoned by the manufacturer. It was, however, probably the first to be abandoned by a manufacturer that wasn't getting out of gaming altogether. I'm not sure what Atari should have done with the 5200, though its best bet might have been to encourage third-party development for the machine or, more precisely, to encourage third-party developers for the 400/800 to port their games to the 5200. Even if Atari couldn't have turned a profit developing new software for the 5200, I would think that both Atari and the third-party developers could have stood to benefit from cooperation. Consumers, furthermore, would perceive that they were still being served even if Atari itself was no longer spending much money on supporting them.

Each object has a 4-bit motion-compare value (loaded via HMxx or HMCLR) and a pulser on-off latch (not directly accessible). The system also has a 4-bit motion counter, a "counter force enable" latch, and a "HMOVE triggered" latch. The motion circuitry operates using the TIA's system clock (which I'll qclock) which runs at a rate of one cycle every four pixels (i.e. once every 1.33 CPU cycles, or 57 times per line). Hitting HMOVE turns on all objects' "move enable" latches, as well as the system's "counter force enable" and "HMOVE triggered" latches. Those latches get turned off as described below. -1- Every object's "move enable" latch will get cleared any time it matches the system motion counter xor'ed with 8. -2- The "counter force enable" latch gets cleared after one qclock. -3- The system motion counter will count once per qclock unless it's at zero and the "counter force enable" latch is not set. -4- The "HMOVE triggered" latch is continuously cleared during the visible part of the screen. When set, it delays the visible part of the screen by 8 pixels. -5- Each object will receive a count pulse once per pixel during the visible part of the screen, and will receive one count per qclock when its "move enable" latch is set. Each object will be displayed when its count reaches 160; players and missiles may also be displayed when their counts hit 16, 32, or 64, based on NUSIZx. If an object's "move enable" latch is set when a new value is written into HMxx, a variety of things can happen based on the values of the system motion counter and the new HMxx. If HMxx is $80, the object will end up receiving 16 motion pulses. If (HMxx xor $80) is greater than the motion counter value, the move will simply use the new value. If (HMxx xor $80) is non-zero but less than the motion counter value, the motion-enable latch will remain set until either another HMOVE is performed or HMxx is written with $80.