supercat

If using a common picture-label cart, which costs under $2, would add $20 to the value of a cart compared with a common text label cart, why invest all the labor in building the text-label ones? I personally don't think the added value for picture label carts would be that great. Actually, I'd question whether there's any real added value, since I would expect the metallic text labels to last a bit longer before they started looking ratty.

Depends how far over the sprite needs to go. If it doesn't have to go too far to the right, one could do something like: ; X holds position lda #255 sbx #15 bcs *+7 sta RESPx ldy postbl-241,x sbx #15 bcs *+7 sta RESPx ldy postbl-241,x ... sbx #15 bcs *+7 sta RESPx ldy postbl-241,x sty HMPx sta HMOVE Provided the position value is within range, and postbl is located so the loads will always wrap or never wrap, the total execution time should be constant.

What were the timing limitations for simple multiplexer-based logic in those days? Would it have been practical to interleave CPU accesses and display accesses on the cartridge bus without needing double-speed memory, if the code and display data were fetched from different memory arrays? For example, assume the CPU is running at 2MHz and there is a 12MHz clock. At step 0, drive phi0 to the CPU and start driving the CPU address to the chip. The data bus will hold the last byte of CPU data. At step 1, have the chip latch the address, and start outputting the LSB of the last requested byte of display data. At step 2, drive a new display address to the chip. At the end of this step, latch the data bus into the display controller. At step 3, hold the address. Have the chip start outputting the MSB of the last requested byte of display data. At step 4, hold the address. At the end of this step, latch the data bus into the display controller. At step 5, hold the address. Have the chip start outputting the requested CPU byte. The CPU memory will have a valid address by the end of step 1, and will have until the end of step 4 to supply data, so it would have at least a full half cycle (it would likely have the address sooner, and could likely supply the data later). The display memories (MSB/LSB) would have even longer to supply their data. If one were using off-the-shelf parts in the cartridge, one would have to use three separate ROM chips plus some glue logic. Integrating the three ROMs into one chip, however, shouldn't be a problem. OTOH, using a separate bus wouldn't be evil either. A "chevron-shaped" cartridge slot would have allowed 7800 cartridges to have many more pins while still having 2600 carts fit nicely.

I suspect that when the 2600 was designed, the CPU was expected to replace a certain amount of hardware. A game like Combat may have been designed around the sort of hardware the CPU was expected to replace, rather than being designed around what the system could actually do. Bob Whitehead seems to have grasped early on the implications of using a "real" CPU, in his games Star Ship and Blackjack. Starship is the first game to use flicker to multiplex sprites (the stars in the background). Such flicker would generally be pointless on a pure hardware-based system, but was effective on the CPU-based Star Ship. More significantly, the Blackjack cartridge is hardly wonderful as a game, but it demonstrates a level of system sophistication totally unlike anything that came before. The hardware required to implement Blackjack without a CPU would have been enormous, and yet the 2600 can handle it with no problem whatsoever. Further, BlackJack demonstrates the 2600's ability to show six different sprite shapes per line, an ability which wasn't deliberately provided for by the original designers, but proves very handy nonetheless.

Microprocessors were originally conceived not as computers, but rather as low-cost replacements for logic circuitry. Although the 2600's display hardware turns out to be more versatile than that of many competitors as a consequence of the on-the-fly display generation, the real goal was to simply save cost by eliminating a lot of hardware. I would guess that even if the objective was to play Combat and nothing else, using the CPU to build the display on the fly would save 75% or more of the circuitry that would be necessary for a "set-up-and-forget" frame-drawing implementation. The latter would require 64 bits of shape latch for each player (instead of 16), vertical size latches for the missiles and ball, a presettable vertical counter for each sprite, a few hundred bits of playfield latches (instead of 20), a bunch of vertical counters for playfield formatting and sync generation, etc. And that's just to reproduce a very ordinary game.

The first nine cartridges were not numbered 01-09, but were numbered by genre. The first digit indicated the genre and the second digit indicated the game within the genre (numbered sequentially). Since "Indy 500" was #11 and "Street Racer" was #12, it would appear that genre #1 was intended for racing games. Genre 0: Combat/Air-Sea Battle/Star Ship Genre 1: Indy 500/Street Racer Genre 2: Video Olympics Genre 4: Surround Genre 5: Blackjack Genre 6: Basic Math

Did anyone engineer RAM disk units that included measures to prevent corruption by errant software? Depending upon what chip-select signals are available, things could be protected greatly by the addition of even one or two 74xx-series chips. Adding four or so would allow one to provide very effective protection. Did anyone do such things?

In my BTP2 music driver, every pitch is a power-of-two multiple of a submultiple of the output sample rate (15.75KHz, matching horizontal scan). This means that any unwanted frequencies resulting from quantizing noise will be "on pitch". For example, when outputting the top C (about 2096Hz) there will be some distortion noise at 1048Hz, but since 1048Hz is also a "C", it's not particularly objectionable. I was somewhat surprised to discover, when I was simulating a more sophisticated synthesis engine, that there is surprisingly little room for improvement in my BTP2 driver. One could offer a somewhat better selection of timbres, but trying for more precise frequency outputs ends up making things sound worse because it disrupts the regular pattern of the quantizing noise.

The screen is limited to 8,000 characters (16K at two bytes/character); the character set offers characters that have the left or right half filled in, but that only gets one to 160x100. Further, drawing to the screen is very slow. I don't remember whether BTR used sprites. The ability to render tiles in 16 colors, rather than just cyan, magenta, and white improved things immensely, however.

The CGA had a ROM-based character set in its text modes. One could program the text mode for different font heights, though the only usefulness of this was that if one set the font height to two rows, one could fill the screen with a character that was solid on the left half; one could thus use foreground/background colors to draw a 160x100 screen. Note that one could not display readable text on such a screen (except at the low resolution), and one could only write a few hundred bytes per frame unless one wanted to either blank the screen or cause annoying "snow". In the 320x200x4 mode, three of the four colors had to be chosen from four "palettes". The red and green components were controlled by the pixel data, while the blue and intensity components were set on a per-screen basis for all pixels that weren't set to the background color. Compare the graphics on "Below the Root" versions for the C64 and CGA. The former blows the latter out of the water.

A nicer way of handling writes, which I believe is used in some of the Harmony schemes, is to repeatedly sample the data bus until the address bus changes, and then use the second-to-last value that was read before the change (if the address bus changes before two samples are taken, go with the last one and hope for the best). Note that (1) if writes don't cross page boundaries, the first cycle following the address change will always be an instruction fetch, so it may not be necessary to perform all of the usual bank-switching logic; (2) if the 'write' zone spans multiple pages, and the 'changed' memory address is within the zone (read it twice to make sure), the cart could ignore the first address and use the second. That would allow addresses that span page boundaries to work "normally".

Here's a 16x16 font I designed ages ago. Each character is 16 rows of 2 bytes each. FNT.ZIP

It's interesting that they seem to have been analyzing write cycles in terms of finding the data-valid window "in advance". I wonder if any RAM cartridges for the 2600 latch the address bus and then hold the write enable until the address from the 2600 changes. My 4A50 cart managed to time the data-valid window very nicely, but it needed a crystal-controlled clock to do it. Using the address change to flag the end of a write cycle would have allowed for much looser timing.

I suppose it might help if I give the table. The values for each square should be: 01101101 01110111 01111010 10101111 10110100 10111011 11001110 11010111 11011001 Looking at the code, I erred on some of the logic (fixed, I hope). The basic idea is that there are eight possible tictactoes for X, likewise for O. Any square which is not "X" will disqualify some of the tictactoes for X, and a square that is not "O" will disqualify some for O. The loop will run through to see if there's any tic tac toe for squares with a value of 1, then 2, then 4, then 8, etc. It's two instructions shorter to let the loop run for all powers of two than to just run it for values of 1 and 2.

It's tough, isn't it. I've shrunk it a little, though how much depends upon how the board is stored. lp1: ldx #8 lda #255 lp2: ldy board,x patch: cpy #1 beq skip ; fixed and table,x beq not_this skip: dex bpl lp2 ; Got tic tac toe not_this: asl patch+1 bcc lp1 rol patch+1 ; If we get here there's no tic tac toe That's 23 bytes, plus nine for a table, or 32 total. A "tic tac toe" will be three 1's, 2's, 4's, 8's, etc. in a row.

If the ARM can accurately glean the bus timing, I would expect that magic writes could be used with the existing hardware, using bus capacitance to hold things for 100-200ns or so. Given an ARM, though, I'd probably do things somewhat differently from the way I did them in 4A50, since 4A50 was designed around the design capacity of the Xilinx XC9536XL CPLD.

Cute technique. Uses the four player/missile combos as four 10-bit sprites, with colors of $10, $20, $40, and $80 so as to add chroma to a background which is drawn in a four-color mode using e.g. colors $00, $05, $0A, and $0F? Cute concept, allowing all 16 chroma colors to be drawn arbitrarily.

It's a shame that Chimera and 4A50 have died off, but at least in the case of 4A50 the killer was seeing that the Harmony board can do almost as much, and in some ways more, and it's a lot cheaper. Aesthetically, I prefer the 'purity' of the hardware approach in the 4A50 cart (as opposed to using a micro that would be powerful enough to implement an entire game even without using the 2600 at all) but the raw cost to produce the 4A50 cart would be about $25 before any markup, and I just don't see people paying the necessary premium to buy 4A50-based games.

According to page 2 of the schematic, the collision latching logic is gated with /VB, which is the inverse of the vblank register. The TIA, of course, has no way of knowing whether the electron beam is over a displayable part of the picture tube, but it gates using the VBLANK register. Interesting to know. As for horizontal, that might be worth some experimentation. The collision logic on page 2 does not seem to take into account the /HB signal (horizontal blank), and the signals it samples (pp. 3-4) are synchronized to CLKP (a clock that runs 228x/line) rather than MOTCK (which runs for the 160 visible pixels). By my read of the schematic, if a Player 0 is positioned so that GRP0 bits 0-3 are visible at the right edge of the screen, and 4-7 are visible at the left, and horizontal motion were not activated, then its sprite generator will output bit 3 of GRP0 continuously during the horizontal blank. If Player 1 were similarly positioned, its sprite generator would output bit 3 of GRP1. If going into horizontal blank, GRP0.3 was clear and GRP1.3 was set, and during blanking software set GRP0.3 and cleared GRP1.3 (in that order), I would expect it to cause a collision. If it doesn't, I'd be curious to know why. If things work as I described, the HMOVE behavior would be a bit tricky to describe. Before I bother, it would be helpful to know whether collisions like I described can occur. PS--On real hardware, VBLANK should start at least a line before VSYNC, and continue on for a dozen or so lines afterward. I suspect most newer televisions probably won't care, but a 1950's model might.

The ability to coax the SID into producing an 8-bit DAC value is pretty cool. Too bad the top frequency isn't higher. I wonder why they chose to use a 24-bit phase accumulator? The 4KHz top frequency isn't all that high, and 1/8 or even 1/4Hz frequency accuracy would have been just fine. I know the Atari 2600 can produce nice-sounding four-voice music using two four-bit DACs running at a 15.75KHz update rate. It might be interesting to cram extra voices out of the C64, but the 8KHz sample rate limit and requirement for precise timings would make things somewhat difficult.

It might be interesting to have a RAM-game contest for the 2600 and maybe also one for the 7800. Any size cart could be used for initialization (though anything over 2K would probably be pointless), but once the game is running it can't use the cart any more. In theory, one could pull the cart and the game would continue to run (in practice I wouldn't generally recommend it). I wonder how much of a 2600 game one could do in 128 bytes (or more, for the 7800, but not a whole lot given the required layout of display lists).

A cart to capture the state of a 2600 could probably be constructed, though making it reliable might be tricky. The best way to do it would probably be to have the cartridge take over operation when it sees a store to VSYNC; the cart should disable the other cartridge, stuff code to JMP $1000 (while noting the address from which it was fetched), store the CPU registers to cart space, and then probe the TIA state as well as it can. Wait the proper length of time to complete the frame and let operation resume. It's not possible to probe the entire TIA state, but it may be possible to glean most of it if one doesn't mind trashing a few registers. Most cartridges reload most registers each frame, so trashing a few registers shouldn't disrupt things.

The EGA system used a planar architecture in part to allow faster programming (though the usefulness of those features was limited until the VGA added a couple of practical enhancements). For certain applications, the planar design is very nice; for others, it's a pain in the tush. Nobody uses those modes any more, but for some purposes they worked quite well. As for hardware complexity or simplicity, planar modes make it easy to support an arbitrarily-variable number of bits per pixel. Using two or four bits per pixel may be more convenient in a "chunky" system than in a planar one, but what about using three or five? A bit-plane architecture which is equipped to handle pixel-level shifting of two sets of bit planes may use the two sets individually to produce an parallax-scrolling background, or together to produce more colors. Unless one is using byte-sized "chunky" pixels, I don't see a huge difference between planar and chunky approaches for most applications. BTW, I wonder what machines have used interesting addressing tricks to allow a processor to view memory in different formats? Rescue on Fractalus on the 7800 omitted an address line from its RAM chip, so as to allow each byte of RAM to be displayed twice, but what other tricks have been done?

The 6502 and TIA are NMOS, not CMOS; NMOS does behave somewhat as you describe (many CMOS do not), but I would be extremely loath to design around the fact that a CMOS "low" will win over an NMOS "high". The 6502 will not generally be destroyed by an occasional conflict on the data bus, but that does not mean that thousands of bus conflicts per second wouldn't take a toll. Although the pull-up transistors on the 6507 are not nearly as strong as a modern CMOS pull-down, the device does use active pull-up transistors which are not intended to be overdriven. BTW, a 6507 can be damaged by trying to drive an address pin high with a CMOS output. My 2600jr needs a new processor because of that.

Generating code completely on the fly would be possible, but annoying. I have an approach which should allow much of the benefit of full on-the-fly generation while maintaining a reasonably clear emulation model; I had planned to use it for last year's Christmas cart, but those plans got somewhat derailed. It may appear in next year's, however.