supercat

Why I'm posting on this thread I have no idea.... Maybe I'm the piano player who thinks the whorehouse should have good music. With a custom kernel, it would indeed be possible to do that, thus allowing the main sprite to be displayed without flicker or to use flicker or flicker-blinds to add more color to the main sprite. I'm not quite sure what the enemy is supposed to be, but if it will always have vertical separation with the main sprite there should be no problem with displaying it and the main sprite simultaneously. Adding some more intermediate frames when moving would improve things. Your rotation demo before was very nice.

An inescapable cause of the '83 crash was the fact that there were so many companies trying to develop games that the amount of money spent on development exceeded the total revenue customers had to spend. Things might have happened differently were it not for Atari's mis-steps with Pac-Man and E.T. but the crash was going to happen regardless.

Tetris certainly belongs on the list, though it should rank behind Super Mario Bros (a game which drove the second video game revolution, targeting those who already had home computers). Off the top of my head, here are some important games: Odyssey -- First home console. Pong -- Certainly in the arcade; knock-offs were by far the most common home video machines until ROM-cartridge systems took over. Combat -- Launch title for the first massively successful game console. Space Invaders -- Major arcade license that dwarfed what came before. Adventure/Superman -- Pioneered the use of a world larger than the screen (Superman was published first, but it was derived from preliminary work on Adventure). Kaboom! -- Put Activision on the map. Pitfall! -- First game to try to create a realistic running-man animation (Donkey Kong had good graphics, but Mario shuffled around, while Pitfall Harry ran smoothly). Perhaps the first game to create the illusion of a world which was too large to be fully tracked, but which allowed one to revisit previously-seen areas. Wolf3d -- Not the first 3d texture-map game on the PC (id software's Catacombs 3d predates it) but the first such game to become popular. Doom -- Introduced a new style of texture-mapped gaming, with arbitrarily-angled walls and variable-height floors and ceilings. Quake -- Introduced a new style of texture-mapped gaming, with full support for arbitrary 3d angles as well as real-time lighting and precomputed shadows. Are there even a dozen games on Guiness' list that were as influential as even the least significant of the ones listed above?

Sorry I didn't respond to this thread earlier. Your question is whether, given four tables, it makes more sense to store the data as: A0 A1 A2 A3 ... B0 B1 B2 B3 ... C0 C1 C2 C3 ... D0 D1 D2 D3 ... (parallel) or A0 B0 C0 D0 A1 B1 C1 D1 A2 B2 C2 D2 A3 B3 C3 D3 ... (serial) The answer is: it depends. If it will be useful to access the data for the tables using the same zero-page pointer, then serial data format is apt to be much more efficient. If the tables will be accessed using separate zero-page pointers, or will only be accessed using absolute addressing, then parallel will often be more efficient, but with an important wrinkle: because zero-page pointers have to be stored with both bytes consecutive, programs which are going to run a loop simultaneously on zero-page pointers and on other data may benefit from having data items spaced two bytes apart, with the data from two tables interleaved. The BTP2 music player in Stella's Stocking does that quite a bit.

If one is trying to save RAM by storing two digits per byte, BCD mode is the only practical way to go. If one isn't trying to save RAM in such a fashion, other approaches may be better. For example, if one can spare 12 bytes to keep pointers to digit shapes "full time", and if one were always adding a multiple of a power of ten points at a time, one could do something like: AddScore:; Assume X points to the digit to be bumped, and accumulator holds 7*value to add. ; The LSB of each digit pointer is are 186+7*digit clc AddScore_lp: adc score,x bcc done_adding sbc #70 sta score,x lda #7 dex dex bpl AddScore_lp ; Score is over 999,999 so do something with that... done_adding: sta score,x rts Note that this approach is easily adaptable for any size score digit, unlike BCD approaches which usually require that digit shapes be stored at 8-byte intervals.

That's precisely what it does.

Killer Bees! features five bee-bots that are 8 pixels wide by IIRC 16 or 18 scan lines tall. Rendering those using 3-block-wide playfield graphics (12 pixels) would not be totally outrageous. The swarms could be drawn using P0/P1/M0/M1. The issue of colors might pose some difficulty, but might be ameliorated by blanking the swarms on alternate lines. Not sure if there'd be enough cycles for that. Let's see: ; Even lines: 14 Load two GRPx. 10 Load two COLUPx. 8 Zero two ENAMx. 28 Load four playfield bytes. 5 Load playfield color. 3 Strobe HMOVE. *68 total ; Odd lines: 8 Zero two GRPx. 10 Load two COLUPx. 20 Load two ENAMx and two HMMxx. 28 Load four playfield bytes. 5 Load playfield color. * 71 total Seems like that might be workable, at least in theory.

I had an Odyssey2 when I was growing up and I tried to like Spin-Out!, but I just plain couldn't. When the barriers were enabled at the faster speed, going through them was a little tricky, but the lack of any sort of inertia made the game pretty feeble.

The Apple's floppy drive controller was a brilliant piece of engineering, conceptually not unlike the TIA. It exploited the fact that the system's CPU didn't have any interrupts or cycle-robbing DMA to jinx its timing, and could manage better than a 10kbyte/second transfer speed (I wouldn't be surprised if specialized loaders could manage better than 20kbytes/second). Since the CPU that was grabbing data off the disk was the same CPU that was connected to main memory, data could go from disk into RAM without any bottlenecks. The Commodore could actually manage a pretty respectable transfer rate on the 1541 when data was stored in specialized format. It's too bad that as far as I know Epyx never licensed that technology to any other vendors.

The biggest limitation with the O2 is its poor selection of colors (second only to a SECAM 2600). There are eight background colors and eight foreground colors (which are lighter version of the eight background colors). That's it. The sound also makes the 2600's seem brilliant by comparison (one channel, without even a real volume control).

The expansion port may have been engineered onto the 7800 board at a time when MARIA was expected to be capable of handling video overlay, but since MARIA does not have any genlock support it would have been impossible to engineer a practical video disk unit that could handle video overlay (today's DVD players all have frame buffers, so a DVD player could be engineered to sync to a 7800, but that would seem a bit silly).

That is cute. How'd you come up with that? That ranks right up there with the following routine someone came up with (on another platform, but adaptable to 6502): ; Magical mystery routine (hint: use with acc = 0-15) sed adc #$90 adc #$40 cld Anyone ever seen anything like that one before? It's pretty impressive managing to do the nybble swap with only two "extra" instructions totaling four bytes/four cycles (considering the 4 two-cycle shift/rotate instructions as the "base"). I think the best I would have been able to manage would have been two instructions totalling four bytes/six cycles, plus a magically-pre-initialized register: asl rol rol rol sax temp; Assumes X=$07 or $0F adc temp

I wouldn't expect so. During one half of each 6502 cycle, the internal data buses are unconditionally set to all "1"s; during the other half, any register which is supposed to output its contents will set to "0" any bus wire which should be "0". This requires considerably less circuitry than allowing each register to output both "1"'s and "0"'s. It also means that in case two registers try to put data on a bus simultaneously, any bit which is "0" in either registers will be "0" on the bus. Some opcodes have some odd behaviors I don't understand, but SAX is very straightforward.

Would the Missile Command bonus tally count? It doesn't show the tally on screen the way the arcade machine does, but I'd call the arcade version a cut-scene and thus the 2600 one as well. Maze Craze and Chess have cut scenes, sort of. Okay, that's really stretching it...

A 6502 is a chip in a 40-pin package; I think 37 of the pins are actually used. A 6507 is the same chip in a 28-pin package; nine of the connection points on the chip are left unused. There were actually a number of 28-pin parts available, using different combinations of signals on three of the pins. Using a 6502 instead of a 6507 would have only provided two extra features: -1- It would have expanded the available address space from 8K to 64K. Unless a larger edge connector were used for the cartridge port, however, the extra space wouldn't have really been good for much; -2- It would have allowed the RIOT to interrupt the 6502 when the timer expired. This would have made it easier for games that have a long 'think' to maintain some sort of video display while thinking, but for the most part the 2600 does just fine without such a feature. Given that the machine originally used 2K cartridges, I think the 8K address space is entirely reasonable. It might have been nice to use another 74xx gate so the TIA and RIOT wouldn't be selected at addresses $0800-$0FFF (thus allowing carts up to 6K) but I don't know that even that would have been worth the cost. The design of the 2600 manages to provide 'just enough' in many ways. The 128-byte RAM is cramped, but for many games it is quite workable. The TIA is pretty minimalist, but it too provides enough features to make things work. The color circuitry is simpler than that on some other consoles (which use translation logic to turn e.g. 4-bit colors into different combinations of luma and chroma), and yet works much better. The audio isn't great, but it provides serviceable music. Wonderful machine.

The description of Actionauts gameplay is not accurate. Each arrow will move the robot one space regardless of the speed selected, so changing the speed will not allow the player to avoid walls. Further, running into walls is harmless for the robot, and in some levels is necessary (note: it wasn't necessary in any of the original levels, but it was harmless). The purpose of the speed control is essentially user convenience. At faster speeds, it's difficult to see what the robot is doing, but at slower speeds it may take awhile for the user to test out a program. Speed could impact gameplay if the cartridge were more developed, since every time the robot completes all the steps in its program it fires a shot and restarts the program; this shot always travels in the direction the robot is facing. At faster speeds, it's possible for the robot to turn before the shot hits a wall, thus causing the shot to reach places it otherwise could not. Since there was never any code to make the shot do anything, such behavior doesn't really affect gameplay, but it is an interesting thing to notice.

One more point of curiosity: how fast was the logic in the TIA? Would it have been practical to derive a two-phase non-overlapping clock at 3.579MHz using the chroma circuit, as opposed to generating two-phase non-overlapping clocks at 3.579/4? Or was NMOS not fast enough to allow such an approach?

Page 5 of the TIA schematic (look in the 2600 area at the top, then "Archives"), in the lower-right corner. "Playfield module" may not be a technical term, but I'm not sure what else you'd call that bit of circuitry that holds the playfield registers and shifters. My question with regards to layout had to do with the fact that the shifter interconnects go from the top of one column to the top of the adjacent column, rather than running from the top of one to the bottom of the next. Small savings in silicon (avoiding four vertical traces), but taking such opportunities when they present themselves can be important. True, the polynomial counters are smaller than binary counters. But with a comparator-based approach one would only need one binary counter, instead of needing a two-bit sync counter and six-bit polynomial counter for each sprite. Given that the system already has a four-bit binary counter and a 4-bit comparator for each sprite to handle the HMOVE logic, I would think that adding two bits to that and adding two bits of fine position control would have been easier than adding five 6-bit polynomial counters and five 2-bit sync counters. Have you seen the motion routine that from what I understand was first used in BattleZone, but has been used in many homebrews since? It takes advantage of the fact that "lp: SBC #15 / BCS lp" takes five cycles (i.e. 15 pixels). It ends up having to either use a 15-byte lookup table for HMOVE values or four ASL instructions to position bits for storage in HMxx, but still works quite nicely. I guess what I find really curious is that the slip-counter plus HMOVE approach ended up being more complicated than necessary for the main purpose, but allowed the 'just for fun' feature that turned out to be very useful. Nice bit of lucking out. As for characters, when did you become aware of what Bob Whitehead was doing with Blackjack? What do you mean by "the error"? The artifact produced by doing an HMOVE at the normal time? I guess that makes sense. A slightly unfortunate decision, but not a particularly horrible one. That wasn't luck. That was genius. Your first three items would have increased the cost of the unit, and I'm not sure there would have been much benefit. Cartridges did come along with bank switching, on-board RAM, etc. despite the lack of pins for them. My wish-list items would have been: - Separate NUSIZx enables for players and missiles (how much silicon would that have taken, including routing)? - A 'divide-by-two' option in AUDCx (possibly using bit 0 or adding a new bit 4). If the counter could hold value for 64us, the feature could be implemented by killing one of the clock phases feeding the main counter. Probably less than eight transistors per channel if done using AUDCx.0; a little more if it used bit 4. Still, I shouldn't complain too much about the 2600's musical abilities. It's really quite good compared to almost anything else of the era. - A 20-pixel mode for the playfield using double-sized pixels. Adding too many playfield registers would, I think, have been a mistake, since there's only a finite time available to update them. For most games, the existing set is more useful than a five-byte set of registers would be, unless the latter happened to include a means to update multiple registers with one write. - For PAL 2600's, an read bit to report even-odd scan line (this would make it easier for games to avoid losing color if something slips by a scan line). - A means to write a sprite without copying the other sprite's delay register (see note below (*)) Of course, some of those notions are created with the benefit of 30 years' hindsight. I'm amazed at what you pulled off. Out of curiosity, have you seen any of my projects? Strat-O-Gems, Toyshop Trouble, or the Stella's Stocking menu? And have you read at all about my 4A50 cart? Strat-O-Gems is a game I started back in 1994 but abandoned because I couldn't figure out the RIOT. I finished it in 2005. It manages to do 'thinking' processes that take multiple frames to complete, without causing loss of video. Things would be a little more efficient of the 2600 had interrupts, but the lack of interrupts is hardly a major problem. Toyshop Trouble is my favorite of the games I've done. It shows four player sprites per line with independent color and shape; three of the objects move together horizontally, while the other has free horizontal and vertical motion. I sometimes like to imagine what you guys would have done if I'd smuggled a copy of the game back in time and showed it to you; there are a lot of TIA tricks in that thing. Incidentally, the game uses an 8K EPROM with one off-the-shelf 74xx chip, something I don't think was ever done in the day (games either used multiple chips or custom logic). The Stella's Stocking menu must be seen to be believed. Four-voice music through a five octave range, with full chromatic support. The music driver uses 46 cycles/scan line, leaving 30 to draw the display. The 4A50 cart includes 32K RAM and 128K flash, using my own banking scheme. What makes it unique is that writes and reads can be performed at the same addresses with no special coding tricks required. Even code execution and read-modify-write instructions work 'normally', despite the lack of a R/W line to the cartridge. (*) Handy sprite addressing: Given that the TIA has a fair number of free addresses, it might have been handy to make address 11xxxx write to sprite registers thusly: 11xxx1 -- Write to player 0 write register 11xx1x -- Copy player 0 write register to display register 11x1xx -- Write to player 1 write register 111xxx -- Copy player 1 write register to display register I can't see that anyone would have seen any use for such a thing when the 2600 was designed, but it would have allowed a 'write' register to be latched without copying the other sprite's 'delay' register, thus allowing four bytes' worth of data to be latched in sprite registers before the start of sprite display. It would also have made it easier to show identical data on both sprites, and to clear both sprites when switching between screen zones. It might have required a little routing, but otherwise would not have required any extra silicon.

And why does '27' seem a popular number of game variations?

The TIA documentation I have explicitly states that as being the reason for the choice. Makes sense, though I think bit 0 or 7 would have been more helpful (to allow ROL or ROR). I'm more puzzled by the use of bit 3 for REFPx. It would seem bit 7 would have been the logical choice (store a direction there directly, or if one is in the mood to PHP, push the N flag). I wonder when it became clear that most games on the 2600 would not be 'freewheeling' the sprite horizontal positions? If a game tracks the horizontal positions of sprites, one could show scores using magnified sprites rather than the score-colored playfield. As it turns out, score mode can be handy for purposes other than showing two-player scores, so it's hardly a waste of silicon, but it's hardly essential. I think my biggest peeve in the TIA is probably the sharing of player/missile NUSIZx settings. Even in a game like Combat, it would have been nice to have an option for a triple plane to fire a single bullet. For that to work well, though, it might have been necessary for the code to track the plane/shot positions (since aesthetically a single shot should be fired from the center plane, not the left one). Still, it's curious that the NUSIZx feature was included at all since it considerably complicated the hardware and I know of nothing really similar in any arcade predecessors. Of course, without NUSIZx the 2600 would have died off a lot sooner, but I'm still curious what inspired it.

A few questions for Mr. Decuir which I've not seen discussed elsewhere. First off, though, I should congratulate Mr. Decuir for his involvement in an absolute work of genius. But on to the questions: -1- What were the constraints and optimization goals for the circuit designers? Was it to minimize the number of transistors, transistors plus resistors, or what? To what extent were interconnects considered at the circuit design level? There seems to have been some consideration given in the playfield module, but was layout an issue anywhere else? -2- How did the sprite horizontal positioning circuitry evolve? In particular... - Were it not for the multiple sprite copies, having a common horizontal position counter and then position comparators for each latch would seem a lot easier than the present system; such a design would not readily permit the multiple-sprite-copy feature, however. Were slip counters used because they could allow the sprite-copy function, or because they seemed like such a cool idea to borrow from the PONG design, or were they expected to work out more nicely before it was discovered that all the HMOVE circuitry would be needed anyhow? - How did the multiple-sprite-copies concept enter the picture? I can't think of any arcade hardware which used a finite number of close sprite copies (some games did omit bits from comparison logic, but that would result in copies all across the screen, rather than only near the 'main' player). - Did anyone at Atari ever know the virtues of hitting HMOVE just before the start of horizontal blanking (all the HMOVE pulses will work as normal, but the next horizontal blank won't be extended by 8 pixels). - Was the decision to have HMxx latch D4-D7 really predicted upon 'ease of coding', or hardware layout considerations? In what anticipated scenario would it ease coding? -3- Are there any design decisions where you think you 'lucked out', and made something much more useful than anticipated? Are there any which you wish you had done differently? Thank you Mr. Decuir for producing such a brilliant piece of amazingly simple-yet-powerful hardware. I wish I could manage something even 1/10 as great.

How about showing the 'score' using something like the horizontal positions of the player sprites? Reset them both to zero, and then bump a sprite 8 pixels right when a player scores.

Sound doesn't have to take a whole lot of space. Perhaps as few as four bytes. Possibly even three. If you add a "STA AUDV0" someplace each frame when the bottom four bits of the accumulator are zero but before you handle your ball bouncing logic, you can then use a read-modify-write instruction on AUDV0 to produce a click. If you use INC AUDV0, you'll produce a level-ten click (clearing the zero flag and not affecting any others). If you do "LSR AUDV0" you'll get a level-8 click and the carry flag will be set (if you're lucky, the two-byte LSR instruction will let you avoid an SEC). If you replace AUDV0 with AUDV1 everywhere, the LSR will clear the carry. Not that such clicks would be considered 'great sound effects' by any stretch, but they'd be cheap to code. If you could somewhere squeeze in storing 4 to AUDCx and AUDFx, the clicks would be replaced by high-frequency beeps (at a cost of another four bytes).

It would, though in X07 banking, if bank E is selected, hitting $40-$7F will switch to bank F; if bank F is selected, hitting $00-$3F will switch to bank E. This is part of what makes the Stella's Stocking menu possible (the display needs direct access to ten pages of data, and the wave generator needs direct access to nine). The simple DASM remedy is to change the SLEEP macro to use "NOP $80" instead of "NOP $00", since that never triggers a bank switch in any scheme I know of.

BTW, one of my peeves with Space Invaders for many years (long before I had any clue how the 2600 actually worked) that the last invader on a row produces no explosion. I wonder why the row is skipped, rather than drawn with blank invaders plus an explosion?