supercat

I would expect that the game wouldn't bother with sprites. With the proper "color" selection, it should be possible to use a 4-color 320-mode bitmap to achieve 16 colors using artifacting in a fashion similar to the Apple //e double-hi-res mode (simply have the CPU draw everything onto the bitmap).

Hmm.... I know 8Kx8 chips existed, but I'd thought they were too expensive to be used in cartridges. Atari certainly seemed to think they were too expensive to go in the 7800 itself (the 7800 is laid out so it could use an 8K chip rather than two 2K chips, but it of course doesn't contain one). Given 16K of RAM, I would guess then 7800 could probably do a somewhat decent-looking version of tempest using one of the 320 modes along with aliasing, though the MARIA would gobble up a lot of cycles. The screen bitmap layout would need to be a little goofy, but probably no worse than the Apple II.

The 7800 hardware is good for showing many non-scaled sprites at 160-dot resolution and tolerable for showing tiled backgrounds. I haven't seen the Atari 5200 version of Tempest, but I would guess it probably uses a 160x200 four-color bitmap screen. On either the 5200 or 7800, such a screen would require about 8K of RAM. Not a particular problem on a system which has 16K (like the 5200), but a bit difficult on a system with only 4K (like the 7800). Although 8Kx8 static RAM chips had become available late in the 7800's reign, they were pricey. The Atari 5200, if it was typical of its era, would have used eight 16Kx1 dynamic RAM chips along with some controller logic. Those were dirt cheap (all eight chips in the 5200 probably cost less than the two 2Kx8 chips in the 7800), but required complex controller logic that the 7800 lacked. Further, getting eight RAM chips to fit into a cartridge might have been difficult.

I don't think Tempest would not have been practical on the 7800 with 1980's memory prices unless the cartridge included some interesting custom hardware. The hardware to create good-looking backgrounds while using a modest amount of memory might not have been too outrageous (it would probably be possible to combine connect four reasonable-sized ROMs and a little extra logic to generate background graphics) but I'm not sure how to handle the spikes at high enough resolution to avoid horrible jaggies without using 8K or more of RAM to hold a bitmapped screen. One of the ARM-based 7800 cartridges might be able to pull off a good Tempest clone, but that would seem like "cheating". Actually, I wouldn't be surprised if one of those carts could pull off a 7800 version of Wolf3d or even Doom, but that would really be cheating.

Not to be overly vain, but in Strat-O-Gems is used with an AtariVox or other EEPROM device in port 2, the attract mode will show the play which resulted in the deepest combination and the play which yielded the most points. One day I left my nephew alone with that cartridge, and when he told me he'd gotten a 7-deep combination I might not have believed him except that the attract mode showed his amazing play.

Having A11 feed an active-low chip select on the TIA and RIOT would have increased the cartridge address space to 6K, or made it easier to have 2K on the main board and 4K in a cart.

I just saw the arcade game upon which it is based. Interestingly, from the look of it, I'd say the arcade machine was using flicker multiplexing to display the two on-screen enemies at once (the enemies scaled much more smoothly than the 2600, though).

Both Mr. Do's Castle and BurgerTime were ambitious projects, whose programmers bit off a bit more than they could chew. I suspect that if programmers had known in advance the limits to what they'd be able to pull off, the projects would likely have been skipped in favor of games that would better fit the 2600's abilities. Incidentally, back in the day I estimated that BurgerTime would need more than 256 bytes of RAM and wondered how they pulled it off; I didn't realize (1) the 2600 only has 128 bytes [not 256] internally, and (2) some cartridges add a little RAM, and BurgerTime in particular adds a boatload (a whopping 2K!) Both 3d Tic Tac Toe and Stellar Track were implementations of games that were popular on the HP-2000 time-sharing system. A 3x3x3 version of Tic Tac Toe was sold under the name Tri-Tac-Toe and featured three glass shelves along with yellow and blue marbles; as a game, it leaves much to be desired since the center square is way too powerful. A 4x4x4 version using plastic shelves and tokens was sold under the name Qubic. One good thing not mentioned about Froggo's Karate is that if one removes the chip, one can solder in a 2764 socket (only 4K is used). That's how I got my start 2600 programming (I think I burned about half a dozen chips before I decided that 24hr turnaround (2600 was at home, and the programmer was at work) wasn't going to cut it. As for things like Star Ship, it was the first 2600 cartridge to multiplex sprites using flicker (perhaps the first game of any sort to do so?) Flicker multiplexing can certainly be abused, but without it a lot of very good 2600 games wouldn't work at all.

I would think so. There are a relatively small number of features I've found myself wanting that could probably be added fairly easily. Given that 6502 code for the 2600 often has "unusual" address restrictions (e.g. a requirement that some branches and data structures must not cross page boundaries often implies that certain addresses may only be relocated to certain addresses within a page) I don't think a separate link is as helpful with 2600 code as with some other platforms. The things I would add would probably be the following: A mode in which DASM allocates buffers for specific addressing ranges, sends output to those buffers, and then outputs them at the end. This would facilitate use of constructs which allocate data non-sequentially. Better control over the number of passes, and the requirement that labels be resolved by a certain pass. Built-in opcodes for sbne, sbeq, sbcs, sbcs, etc. (which perform like bne, beq, etc. except that they will generate a diagnostic if, on the last pass of assembly, they cross a page boundary. This can be done with macros (I often define macros for that purpose), but using macros clutters the listing file. New .org-style directives which would set the logical or physical output address while keeping the same displacement between those two addresses Bounds checking on the ds directive. When I first started looking at Atari programming in 1994, I would have found DASM to be a massive improvement over any of the alternatives I could find at the time; I started Strat-O-Gems with an assembler that was a big quirky, and nowhere near as nice as DASM. I'm not sure what improvements are needed which couldn't be accomplished with a few tweaks to DASM. I'd been load to change DASM and make any code that used new features be incompatible with what everyone else was using, but if people are going to migrate to something else I think it might be better that it be a tweaked DASM than something completely different.

While building a cartridge using a CPLD plus discrete RAM and ROM is an interesting challenge, I don't think it's really viable as a production-worthy approach. Using an ARM is just so much cheaper and easier. That having been said, my banking scheme was designed around the goal of using macrocells as efficiently as possible. It had four bankable areas: $1000-$17FF -- Bankable to any 2K chunk of RAM or ROM $1800-$1DFF -- Bankable to the first 1.5K of any 2K chunk of RAM or ROM $1E00-$1EFF -- Bankable to any 256-byte chunk of RAM or ROM $1F00-1FFFF -- Fixed at last bank of ROM, but accesses will copy bits 3-6 of the address to bits 8-11 of the address for the $1E00-$1EFF bank. The "interesting" behavior of the last bank was designed around high-res graphics. In particular, if $1F00-$1F5F was filled with $01,$02,$04,$08,$10,$20,$40,$80 and $1F80-$1FDF was filled with the complements of those, then a "pixel set" for coordinates in X and Y registers would be: lda $1F00,x ora $1E00,y sta $1E00,y and a "pixel clear" would be: lda $1F80,x and $1E00,y sta $1E00,y I also discovered that the same hardware worked very well for my game Ruby Runner; I defined the codes for various object types in such a way as to allow my board-scanning loop to be something like: ; Running from 6507 address $1E00 lax (scanPtr),y nop $1F00,x ; bank-switch ... start processing code for that type of object Rather than have to use a computed jump table to dispatch code for each type of object, I simply used the $1Fxx area to select one of 16 pieces of code to execute. If I were designing a CPLD-based banking system today, I think I would specify that code should only be run from addresses $1800-$1FFF or $0880-$08FF. If code is only executed from those addresses (and in particular, not from $1000-$17FF), then the normally-inaccessible address bits A13-A15 for any access to $1000-$17FF will have been on the data bus D5-D7 during the last access that wasn't in that range. Thus, one could fairly easily setup a scheme in which $1000-$17FF was one bankable "data" area, $3000-$37FF was another, $5000-$57FF was another and $7000-$7FFF was a fourth. It would be especially nice if one could have the start address of each such area be specified with resolution of a page rather than a 2K block, but I don't think that would be feasible in a 95C72; you'd probably have to go up at least one more size for that.

For any reasonable-sized Atari project, the time required to assemble the whole thing is going to be pretty negligible. Using macros to arrange memory in DASM can be a bit tricky, but it can do some pretty neat tricks. There are some things that could be improved with DASM, but if the main objection is the lack of separate-link support, I'm not sure I see that as a problem.

That design used a Xilinx 9536XL CPLD with 36 macrocells, clocked at 14.3818MHz (12x cycles per bus cycle), which was accurate enough that the timing would be correct at the end of a 75-cycle fetch following an STA WYNC,. I didn't watch for changes on all the address bits (not enough logic to do that). Instead, I resynched the clock every time I saw a change on A0. I'm pretty happy with the bank scheme I implemented back then, even though nowadays one could do better with an ARM.

Does the linker have any means of issuing warnings if specified branches cross page boundaries? When coding in DASM, I rely upon "safe-branch" macros which will squawk if the target isn't in the proper page. If I get a squawk when I assemble my code, a little rearrangement will usually fix it. Unless link sections are aligned on 256-byte boundaries, I'm not sure how readily one would be able to detect such cross-page faults.

A useful trick with writes, which I invented in 2006 I think, is to use a "bus keeper" circuit which weakly pulls pins on the data bus high if they're high, and low if they're low. On the first half of each cycle, read a byte from RAM at the appropriate address and output it briefly on the bus (whereupon the bus-keeper circuit will effectively latch it). Just before the end of the second half, copy the value on the bus. If the 6507 performed a read, the data will still be on the bus. If it performed a write, the new data will be on the bus.

I've been out of 2600 programming for awhile, but would suggest that a useful trick for improving legibility of "flicker-blinds" text is to try to balance out the "even" and "odd" frames. This will work best with text that's either 7 or 11 lines high, so that something like an "E" will have the center line flickering opposite the top and bottom. Also, it can be helpful to design an "E" like: XXX X.X X.. XX. X.. X.X XXX so that the "serifs" balance out the even and odd frames.

The normal way I've seen to drive video, including in circuitry designed for professional use, is to output a low-impedance signal twice as strong as desired, and then put a 75-ohm resistor in series. The net effect will be that the source impedance will be 75 ohms, the cable (if it's a good one) will be 75 ohms, and the destination impedance will also be 75 ohms. This will avoid reflections at the end of the cable which could otherwise cause ghosting. I don't think I"ve ever seen a video monitor which didn't have 75 ohm termination, though a few units did allow the termination resistors to be switched out.

The counters reset when they reach the programmed count value. The left set of boxes is the AUDFx register, each bit of which is equipped with inverted and non-inverted outputs. Each stage of the counter is likewise equipped with inverted and non-inverted outputs. The leftmost vertical line through the larger, right-side, set of boxes, will be pulled to ground if any counter bit disagrees with its corresponding AUDFx bit. That signal is delayed by two pass gates and then fed vertically, between the two clock wires, as one of the three-inputs to a NOR gate to clear all the counter stages. Incidentally, in the places where you see a grid of wires with circles at some of the intersection, each circle is a transistor. The gate will generally be the horizontal wire and the drain will be the vertical wire. The source will be connected to ground (as with other gates, the ground connection is not explicitly drawn). The simplest way to think about such grids is that a column will be pulled down if row where it has a circle is high. This style of logic requires the same amount of space whether all the intersections have circles or none of them do. On the other hand, such grids can be laid out very compactly. Something like the collision-detect logic uses a 30 transistors in a 5x15 grid to detect collisions. Even though 75 transistors could fit in the space that's used for 30, trying to individually wire the 30 transistors would likely use more space than putting them in the grid.

To understand transistor sizes, first understand that current in amps is the number of coulombs of electrons per second; capacitance in farads is the number of coulombs of electrons that will be required to produce a volt of back pressure. Transistor gates have a certain amount of capacitance, and they must reach a certain voltage to switch; that means they must have a certain number of electrons flow into or out of the gate. If the current flowing into or out of the gate is low, it may take awhile for enough electrons to flow to switch the transistor. Bigger transistors will allow more current to flow when they're turned on, but they will also have higher gate capacitance than smaller transistors.

Here's what I think is going on with the schematic at the top of the page. The clock signal will have to drive a lot of stuff on the chip, so it uses the indicated circuit to drive it strongly high and low. Note that the big bold resistor is probably as low a value as the engineers could practically produce, but the diffusion material has a non-trivial amount of resistance no matter what one does.

A normal NMOS inverter contains a single transistor which pulls the output low whenever the input is high, and a passive pullup resistor which tries to pull the output high always, and succeeds when the transistor doesn't overpower it. NMOS design using such simple gates involves a tradeoff between using a low-value resistor, which will waste a lot of power, dissipate a lot of heat, and require a pull-down transistor strong enough to overpower it, or else using a high-value resistor which can't pull the output very fast. I believe that the side wire on a gate isn't a normal 3-state control, but rather operates a transistor in series with the high-side resistor (which can then be much smaller). Note that if the 'side' wire and the input were both high simultaneously, the gate would draw substantial additional current, since the pull-up transistor's efforts to pull the line high would be much stronger than those of a passive pull-up resistor. One should note that while pull-up transistors can switch more current than pull-up resistors when their outputs are far below their gates, NMOS pull-up transistors get very wimpy when the output voltage approaches the gate voltage. Still, since most NMOS gates will switch at voltages more than two volts below VDD, it's possible to construct a reasonably powerful signal driver by using a small gate to drive a pull-up transistor output for a much larger gate. For signals like Clk which are distributed throughout much of the chip, this is important.

The TIA is implemented with NMOS technology, meaning everything is built from one style of transistor: a Negative-channel Metal Oxide Semiconductor Field Effect Transistor (also called an N-channel MOSFET or NFET). An NFET has three terminals: the source and drain, which are in this context interchangeable (typically the side closer to VDD will be labeled the source, and the other end the drain; power NFETs are generally constructed asymmetrically, and the distinction is important, but within a chip like the TIA it doesn't matter), and the gate. An NFET will connect the source and drain ends whenever the gate is 1-2 volts more positive than the less-positive end, and behave as an insulator otherwise. Note that while the voltage on the gate connects or disconnects the source and drain from each other, almost no current flows into or out of the gate itself. Note also that if one end (e.g. the source) of the MOSFET is ground and the gate is high, the MOSFET will strongly connect the other end to ground, but if the drain is tied to VDD and the gate is also at VDD, it will only pull the source weakly (as the source is pulled toward VDD, the voltage difference between the gate and source will drop so the transistor will start conducting less well). An NMOS inverter consists of an NFET to ground and a resistor to VDD. A NAND gate consists of two NFETS in series connected to ground, along with a resistor to VDD. A NOR gate consists of two NFETs in parallel connected to ground, along with a resistor to VDD. The D1 block consists of two inverters (each of which is a transistor to ground and a resistor to VDD), along with two discrete transistors. When the gate of a discrete transistor is high, it will act as a closed switch (though it is more effective at passing logic '0's than logic '1's). When the gate is low, it will act as an open switch. Because very little current flows into or out of a MOSFET gate, opening the switch connected to the MOSFET gate will cause the gate to simply remain in whatever state it's in, at least for awhile. Effectively, the transistor and inverter form a crude latch. Such a latching circuit is much smaller and simpler than a more 'conventional' latch using a couple of NOR gates (four transistors) but it has the disadvantage of only holding information for a few dozen microseconds. If you look in the TIA design, though, you'll notice that in all the places such latching circuits are used they'll be strobed pretty frequently, typically using a non-overlapping two-phase clock.

IIRC, it also had a decent keyboard, something that's just about impossible to find on portable machines these days.

Were they 9-pin or 7-pin? The older Seikosha-derived ones were all seven pins, without descenders, but it'd be interesting if Commodore released a 9-pin version.

For functions that don't have to be operated by reflex, a keypad can indeed be better than the assortment of buttons around a controller. For example, even though an XBOX360 controller has plenty of triggers, buttons, and such to accommodate numeric entry, a person would need quite a bit of practice to enter numbers as smoothly or as naturally as a newcomer could do with a numeric pad. Numeric pads are not good for actions that must be performed by reflex, and the use of detachable/losable overlays was a significant problem, but I would think a keypad with an LCD behind it to label the 'buttons' would be a useful feature for some games.

I believe there were some word processing carts for the C64. Interestingly, even though as far as I know Easy Script only sold on disk, it occupied precisely 16K and thus probably could have been sold on cart.