supercat

What would be the point? Make a move, come back 12 hours later, and find out that some of the pieces are no longer where they're supposed to be. Even if one were to reset after each turn all the pieces except the last one the computer seems to have chosen for its "move", the move may well have been chosen based upon incorrect positions for some of the pieces and may not make any sense (or even be legal, for that matter) with the pieces in their correct spots. Simply put, although the computer may spend more time "thinking" at higher levels, it is less capable of playing a coherent game.

Examples can be worked out in which either machine will win by a considerable margin. The Z80 has a number of internal registers; register-accumulator operations with the accumulator as destination take four cycles and both register-immediate and accumulator-immediate operations take seven. By comparison, on the 6502, zeropage-accumulator operations take three cycles, accumulator-immediate operations take two, and zeropage-immediate operations must go through registers (thus taking five cycles). Thus, for applications that can be handled mostly in registers, the Z80 comes out ahead. On the other hand, the 6502's memory addressing is much more flexible than the Z80's. Although the Z80 is much faster at incrementing a pointer in a register (6 cycles) than the 6502 is at incrementing one in memory (twelve cycles), the 6502 can perform address computations upon pointers stored in memory without having to modify them first using indirect-indexed mode. Many instructions on the Z80 have a very restricted set of addressing modes. Even just loading the contents of memory location $1234 into the E register requires 16 or 17 cycles and trashing another registers, e.g. ; 16 cycles, trashing D ld de,(1234h) ; 17 cycles, trashing A ld a,(1234h) ld e,a ; 17 cycles, trashing HL ld hl,1234h ld e,(hl) By comparison, an absolute-mode load on the 6502 would take 4 cycles--a quarter of what the Z80 requires. Also, in applications that require using lots of memory pointers, the 6502 can really blow the Z80 away. The BTP2 music player in Stella's Stocking requires 46 cycles per scan line. Even if one is nice enough to page-align everything and keep code in RAM, the Z80 would be horribly outclassed: ; A typical Z80 routine, equivalent to the BTP2 player. Note that this is one of four routines that must be used on a rotating basis. ld hl,(patch1+1) ld a,(hl) patch1: ld hl,voice0 add a,(hl) out (audv0),a inc h ld a,(hl) ld (patch0+1),a ld hl,(patch2+1) ld a,(hl) ld hl,(patch3+1) add a,(hl) out (audv1),a ; 16+7+10+7+11 + 4+7+13 + 16+7+16+7+11 ; 51 + 24 + 57 ; Total 132 cycles (as compared with 46) Hmm... not quite as bad as I thought, since I shaved off a few cycles since the last time I looked at the concept. Still, I think the 6502 is the clear winner for that code.

Atari Video Chess moves pieces around the board somewhat arbitrarily at the higher levels, in a fashion not bound by any normal rules of chess. It is thus not possible to really play a game in the normal sense.

Depends how clever you are. Since the ghost's eyes are black and white, and all the places in which the ghosts move have a white foreground and black background, one could draw the ghosts' eyes on the background layer without needing to use sprites for them.

Every once in awhile NetFlix sends out a wrong disk. Someone rents a movie and the bonus disk, mails them back in the wrong sleeves, and the person at NetFlix fails to notice and correct the problem. Perhaps that happened to some of the people who write those bad reviews. Still, I would think those people should be able to figure out what's going on. Also, NetFlix does not always do a good job of making clear what content is on what disks. It would be helpful if there were fields in the database for the titles of individual programs on a multi-program disk. That information is usually found in comments, but is not always easily searchable.

What's the ROM size? 16K? Would it be practical to make a 32K ROM that combined old and new versions, and allow an 'upgrade' option for owners of the original (so then owners of the original that didn't upgrade could sell their "rare collector's edition" carts for 5x the price )?

So which part of the code is that? >:*3

Some decoders count the number of equalization pulses (even vs odd) to distinguish even and odd scan fields. The only way I see to make this thing work is going to be to look at a real signal and at what the A8 puts out to compare them.

The 2600 hardware imposes four limiting factors on a game. In usual order of severity, they are: Kernel time RAM Code space Non-kernel time Note that any one of those constraints may pose difficulties, but RAM and kernel time are usually the most severe. While it is occasionally possible to store data in compact formats and still work with it in the kernel, that is usually only workable if one can afford to waste a scan line or two unpacking the data. Strat-O-Gems employs such an approach, using two scan lines to unpack gem data for each row of the display. Hunchy II uses that approach to do the shape-table lookup for each 'row' of playfield (if you look at the playfield shapes, you'll notice some lines are always blank). Trying to use such an approach at kernel time is not going to work with vertically-mobile sprites. There is, however, another approach you might be able to use if code space is more constrained than RAM (as it was with Toyshop Trouble). Have a RAM buffer which holds the shape (and/or color if you prefer) of a sprite, unpack the sprite data into that buffer during a non-kernel time interval, and then have the kernel fetch the data from RAM. If I recall, Toyshop Trouble has a total of 18 different shapes for the elf, and if they were read from ROM they would have to be preceded and followed by 15 bytes of zeroes. Storing all 18 shapes separately would have used up more than 500 bytes of ROM. What I did instead was to store the body and head shapes, along with a table that indicated that e.g. walking frame #3 of elf walking rightward was body #6 and head #4, mirrored. The screen is divided into 16-line zones, and the elf is 17 lines high, so the elf appears in two zones; I use 16 bytes of RAM to hold the elf GRP0 data for both zones. The net effect is that I need to determine once, before each zone, whether the elf will appear at all in that zone and then set a pointer to either the RAM buffer (if the elf does appear there) or 16 bytes of zeroes (if the elf does not). Within the zone, there is no need for any decision-making about whether or not the elf should be drawn. Addendum: the last line of the elf's coloring always matches the first, so the color can wrap every 16 bytes. There are I think three ways the elf can be colored; I have two copies of each of the three 16-byte color patterns stored back to back. I then have one color pointer, which I share among all zones, which points somewhere in those tables. I never worry about whether to color the elf sprite--I always just do it. For the lines where the GRPx data is non-zero the colors will be right; for the other lines, they'll be wrong but I won't care.

Sometimes I like to imagine how I would have designed something before I see how it was actually done, to see how some of my insights compare with the designers'. I don't think I would have considered using slip counters for object positioning if I hadn't seen it done in PONG and the TIA, but slip counters do provide a very nice approach for things. I recall that TANK did multiplex the players' score display logic; I don't remember if it multiplexed the shape display. Certainly multiplexing logic can save a lot of circuitry. I'll take a look at the manual and see what I think.

...with extra hardware. Stella's Stocking demonstrates that even better audio is possible without extra hardware (though few games could afford the 46 cycles/line that Stella's Stocking spends on audio). The approach used by Stella's Stocking probably wouldn't be usable in a game; indeed, even displaying a decent title screen while playing music was a challenge. On the other hand, four voices with a five-octave full chromatic range using nothing but CPU power is pretty impressive. Incidentally, the BTP2 music driver in Stella's Stocking uses power-of-two rate multiplication for octave selection along with integer rate division for the pitch within each octave. There are 12 wave tables ranging from 60 entries © to 32 entries (B). The octave from middle C to the B above that plays each sample once; the lower octaves play each sample two or four times. At higher octaves, the code skips every other sample, three out of four, or (for the top C) seven out of eight. All pitches are within 1% of true, and sub-harmonic distortion is restricted to octaves below the correct pitch (e.g. playing the top C generates a little distortion at the C below, but does not generate distortion at other pitches). I tested a version which used 3x as well as power-of-two rate multiplication and the subharmonic distortion there was just horrid.

Even without a microprocessor, I would think one could reap benefits from sharing a significant amount of circuitry between the cars. Though perhaps the game did and STILL needed a big board for each one. Though it wouldn't seem like it would need that much stuff... Each car would need hardware to count its position (horizontal and vertical, and rotational), latch its shape for a scan line, shift out its shape when the horizontal counter triggers, latch collisions, count laps, and generate sound. It would also need some multiplexors. Not sure what functions couldn't be multiplexed. The shape ROM could be multiplexed by hitting each board once/line to fetch it. Motion could be handled by hitting one board for each of 8 scan lines at the start of each frame. Microprocessors make it easy to multiplex functionality, but they're hardly essential. Still, maybe it's easier to just build eight of something than design a multiplexer.

For computing purposes, how would the 7800 be better than the Atari 8-bits? I suppose if one could have afforded the RAM, a 320x200x4-color screen mode might have been nice, but MARIA really seems better suited for gaming than computing.

A phase accumulator requires more hardware than using a frequency divider; further, when generating square or pulse waves sounds with a phase accumulator, one must use an input clock which is much higher than the desired output frequency or the results will sound terrible. It's certainly possible to design a good sound system around phase accumulators (e.g. Commodore's SID) but the minimum requirements to get anything to sound even halfway decent are pretty steep. A more efficient way to design hardware for playing music would be to have a programmable integer rate divider (5 bits would be adequate, 6 pretty good, and 8 quite good) along with a programmable power-of-two divider. The biggest weakness with the TIA for music is that none of the wave-shaper settings produce divide ratios that are related by powers of two. If I were seeking to achieve the best possible improvement in TIA sound generation capabilities with minimal extra hardware, I would probably add about two gates to each channel so that when bit 0 of AUDCx was clear, the channel to be clocked once per scan line instead of twice. That would cause the even-numbered selections to drop in pitch by an octave, thus allowing many more usable pitches. If i could afford a little more hardware, I would add two bits to AUDFx, and arrange for the horizontal scan circuitry to output pulses on three wires a total of four times per scan line in the pattern ABCB. Wire A would always clock the audio circuitry; wire B would also clock it if AUDFx.7 was set, and wire C if AUDFx.6 was set. That would thus allow an effective input rate of 15.75KHz, 30.5Khz, 47.25KHz, or 63KHz. Of course, it's a bit late to be doing that, but I think POKEY might allow some power-of-two options.

How about a hybrid table/code approach: ; Divide value in acc. by 10 and store the result in Y. X trashed. tay lsr lsr lsr lsr tax tya sec; Could this be eliminated? sbc table1,y ldy table2,x cmp #10 bcc nobump iny cmp #20 bcc nobump iny nobump: ... table1: byte 0,1,3,4,6,8,9,11,12,14,16,17,19,20,22,24 table2: byte 0,10,30,40,60,80,90,110,120,140,160,170,190,200,220,240 Sixteen instructions totaling 36 cycles worst-case and 24+32=56 bytes

Laser tag does not use lasers, it's IR based. Many laser-tag sets use visible-light lasers for aiming or for effect, even though they use other means to detect hits. Actually, I would think the best way to detect hits would be to have the target areas of each vest emit a modulated pattern of light and then have each "gun" incorporate a well-aimed photo-eye. When a person is hit, have the gun radio the victim (identified by the modulation pattern).

If you can cause the system to drop half a scan line, I would suggest doing so at the very end of one field (just before vertical sync pulse) and at the very beginning of the next field (just after the SAME vertical sync pulse). That will leave 262.5 lines between sync pulses on both frames, and even even number of short lines between any displayable scan lines.

Or else about using a full 6502. Not sure which he was considering; bank-switching on systems with proper timing signals would hardly have been unknown, though I wouldn't see much reason not to put the bank-switch logic in the carts themselves.

Today's machines allow a much faster edit/build/test cycle than would have been possible for even a well-equipped lab in the 1980's. Further, the trace/log functions allow one to see more easily and precisely what one's code is doing than would generally have been possible. Were I trying to develop a game with 1970's technology, I probably would have wanted to build a setup with an analog RGB monitor, one channel of which would receive the composite out from the 2600, and two channels of which could be plugged into circuits which would generate either: -1- A high output during a specified scan line. -2- A high output on a specified cycle of a scan line. -3- A high output when a particular TIA address is hit. I'm not aware of any developer back-in-the-day having done such a thing, but it would have been very useful when trying to get timings dialed in correctly.

For medium-sized numbers, there's a huge difference. For really big numbers (crypto-sized), the difference isn't as significant, since the number of steps required to approximate 1/x to a certain number of bits is roughly proportional to the log of the number of bits; once one has a good estimate for the reciprocal of a dividend, the number of multiply/subtract operations is related to the amount of error in the approximated reciprocal. I haven't looked to see to what extent this trick is used in RSA crypto implementations, but if it isn't used, it should be.

Stellar Track appears to use the same "flicker-blinds" kernel as Basic Programming; according to Warren Robinett, that kernel was invented by David Crane.

The 2600 is limited to per-line coloring; the arcade game wasn't, and the designs took advantage of the fact that it wasn't. Perhaps the color choices were a little to bright for some television sets, but it's important to note that there was (and still is) a lot of variation in how televisions display color, so there was no single optimum color choice. Perhaps dropping the luminance value by 2 would have been helpful, but Galaxian is hardly a crime. Pac-Man on the other hand...

It would indeed. It's important that the total number of scan lines in two fields be odd, and that the total length of the VSYNC pulse be the same on even and odd fields. Trying to simply cut half of the VSYNC pulse from every other field while the fields remain the same length won't be good enough. BTW, the C128's 80-column chip didn't interlace properly; it output an even number of lines in a frame IIRC. Nearly any CRT will support interlacing if the timing is right, but if the timing is wrong it won't.

I've thought about doing a DDR or Guitar-Hero-style game for the 2600, using my BTP2 music driver. My big concern was whether the game would be enough fun to make it worth the monstrously-difficult kernel. Since then I've figured out a different possible approach for killer music. Still not sure about the 'fun' factor, though.

Even in email, it's useful to quote the particular details to which one is responding. Keeping a 'log' of all messages at the bottom may be useful as well, but quoting a question and then answering "yes" or "no" is a lot nicer than answering yes or no without context.