supercat

I've only played the PC demo. I wonder how well the game would work if it was restricted to a vertical format? I coded a crude version once for the PC in BASIC (took about 30 lines IIRC) and it seemed all right. A vertical Zoop-ish game might work nicely on the 2600.

One thing I'd like to see would be something similar to that, but with a CPLD that could be tweaked to add more video modes, features, etc.--possibly with a fast static RAM attached. A 16-bit-wide static RAM that could run at 50MHz would allow a clock rate of 6MHz (256-pixel resolution) with eight fetches per pixel. If one figures that a 16-color sprite would require four fetches (two for position/control and two for shape data) to prepare eight pixels, each group of 8 pixels (64 clocks) could be divided up as something like: 48 -- twelve sprites, four clocks each 4 -- four pixels, palette lookups 2 -- Tile shape index fetch (two layers) 4 -- Tile pixel data fetch (two layers, two fetches each) Leaving six cycles left for remote CPU access. Whereas most game systems limit the number of sprites per line, the screen could if desired be divvied up horizontally as well as vertically (so the limit would be e.g. 12 sprites of arbitrary size within any given 32x32 portion of the screen). A pretty generous allowance. Each 16-bit palette value could be interpreted be used to select either one of 32768 colors, or else select one of 128 colors for the left and right halves of a pixel (allowing limited double-resolution capabilities). Overall, the graphics package would probably be superior to that of something like a Sega Genesis, and would leave much more CPU power available to the main processor. Other games that had different requirements could put different logic into the CPLD (e.g. output a double-buffered straight bitmap, but process texture-mapping primitives at up to 25 million pixels/second--faster than an ARM could handle them)--allowing something like Wolf3d to run at 512x480 resolution, redrawing every frame (Doom might be workable as well, but I'm not sure the logic to handle lighting or floor drawing would fit). I wonder if there'd be any interest in that sort of approach?

The NES offered a "real" resolution that was more than half again that of the 7800 (the 7800 can kludge a 320x200 screen, but motion and transparency are determined on a 160-pixel basis). It also offered better native sound capabilities. While the 7800 does offer a few advantages, the NES is a technically superior platform in many ways.

There are a couple things to note about using such WSYNC tricks on the 7800, though: -1- Although WSYNC on the 2600 is pixel-perfect, on the 7800 it is not. Because 6507 cycles may take 2 or 3 color clocks, there is a clock worth of jitter when the 6507 comes out of WSYNC. It would have been nice if MARIA would throw in a 3-chroma cycle if needed to even things out, but it doesn't. -2- Hitting a color register mid-line will cause one pixel to appear 1.5 chroma clocks wide and the next pixel to appear 0.5 chroma clocks wide.

Note that this sort of 'cover' may sometimes be a useful effect, especially with games that allow sprites to wrap the screen. If HMOVE is hit every scan line, single-width sprites that wrap aren't really a problem in any case, but if one is hiding HMOVE bars, or if one is using wider sprites, having the sprite shape set at one edge of the screen and zeroed at the other may be useful.

Unlike line-level audio outputs which can generally drive multiple inputs without difficulty, a normal video output will be limited to driving one video input. I would expect that trying to tap into the 2600's video circuitry without cutting out the RF modulator will generally not work too well. It may be possible to adjust the monitor one is connected to so as to yield an watchable picture, but the picture quality will likely be sufficiently compromised as to eliminate much of the purpose of doing the mod in the first place. I would highly recommend using the approaches that add buffering to the 2600's video output. It's not a whole lot of circuitry, but it can make the circuit work much more cleanly.

A little further detail: In older television sets, the vertical and horizontal sweep were essentially independent. If the time between vertical sweeps was an integer multiple of the time between horizontal sweeps, successive fields would be drawn precisely on top of each other; if it was an odd half-multiple, they would be 2-way interlaced. If they had some other relationship, 3-way, 5-way, or other interlacing would be possible. An important thing to note, though, is that a television set wouldn't care whether a signal was interlaced or not. An LCD, plasma, or other such set has to care about such things, because it has to know which parts of the display to update on each scan. I've sometimes wondered whether it would be helpful for programmers to adjust game sync timing to somewhat better match the standard. Unfortunately, many games for best appearance require a non-interlaced display; outputting an interlaced signal may improve compatibility with some digital televisions, but would make the game look worse on traditional ones. Further, I'm not sure it's possible to do anything with the vertical sync timing on a PAL machine without jinxing the color.

Would it be possible to have the harmony watch for accesses to SWCHA where bits 4-5 were both clear, which are followed by another access from cart space? I would guess that most carts read joysticks from code running within cart space; the access following the SWCHA read would always be an instruction fetch, so there should be no problem inserting a BRK and having the Harmony code take over. The only necessary controller mod would be to add a "reset" button connected to joystick up. To reset to the main menu, push that reset button while pulling the controller down. Note that some games, especially those using the keypad controller, would not work with this approach, so there should be a way to disable the function on a per-game basis. Otherwise, it would seem a good combination of minimal hardware mod and no game mod.

If one were using the POKEY only for sound and were putting it on the same cartridge as the ROM, one could probably put the POKEY at address 0xE000. A pass-through cartridge might work, but the cartridge being plugged in would have to float the data bus on write cycles to ROM space. Having a pass-through device "hide" such cycles might work, or might cause problems.

If a cartridge expects the 6507 to be performing a read when it is actually performing a write, both the processor and cartridge will simultaneously attempt to put different data on the bus simultaneously, a situation called bus contention. If bus contention happens occasionally, it is unlikely to damage anything. If bus contention happened sufficiently often for a sufficient time, however, it could cause parts to overheat and fail. The exact values of 'sufficiently often' and 'sufficient time' are dependent upon many factors. I don't think it's possible for the 6507 to try to write to cartridge space more than 1/3 of the time (two cycles every six, using INC $nnnn) and given that the first byte of written data would match the read data, in most scenarios it's unlikely that it could write contentious data more than 1/4 of the time (one cycle every four, using STA $xxxx). I would guess that even in worst-case scenarios involving a cart trying to output $FF when the 6507 was outputting $00, it's unlikely that the 6507 or cart would be quickly damaged, but they could heat up enough to cause accelerated wear.

From my understanding, writing files to an SD card is generally harder than reading them, though writing to a pre-existing file might not be too bad. The CC2 does not use directories the same way the Harmony cart does; it uses a CC2 menu file to hold for each game a 40-character title, and the filenames for the binary, bankswitch, and boot files (8 bytes per name--24 bytes total). Seemingly-hierarchical menus are supported by specifying the name of a new menu file with a boot file name of "MENU". As such, one need only keep track of the menu file name and index, rather than having to store anything like path information. My inclination would be to store the cluster number of the last directory, a checksum, CRC, or other hash of that directory, and the index of the selected file within that directory. On startup, look to see if the indicated cluster seems to point to a valid directory; if so, start there; if not, start at root. Clear the selection before trying to load it, so that if it's bogus the cart can be restored to operation by power-cycling it.

Countless millions of perfectly-functional Atari 2600 cartridges have been thrown in the trash simply because there are no longer millions of people who want play them. Many millions more are going to be thrown in the trash in future for that reason. The question isn't whether these carts are going to be kept as-is so people can play Missile Command. That simply isn't going to happen. The question is whether they are going to be junked entirely, or whether parts of them will be kept and re-used. And given those choices, I'd say the latter is preferable. Realistically speaking, the number of cartridges that are junked each year is going to dwarf the number that are salvaged for homebrew games until the carts start to get scarce enough that fewer get junked. The more carts get used for homebrew games, the more carts will still exist when they start to become noticeably scarce.

The HMOVE circuitry on the 2600 is rather bizarre. It can do some very nice things, but to use it "normally" you should execute an HMOVE immediately after a WSYNC, and make sure that positioning registers are not written in the first 23 cycles or so following an HMOVE. Executing an HMOVE at any other time, or writing to position registers too soon after an HMOVE, will cause weird things to happen. The only unusual trick which is generally useful is hitting HMOVE just before the end of a scan line. If done properly, all sprites will end up 8 pixels to the left of where they normally would, but there won't be an "HMOVE bar" at the edge of the screen. I wonder if anyone discovered that trick back in the day?

True, but stuff that isn't very bright will 'burn in' so much more slowly than stuff which is at full brightness that it becomes essentially a non-issue. A bigger issue for 2600 games, IMHO, would be distinction between the displayable screen and border/comb areas. If the displayable screen areas are cycling through bright colors, they would be burned in significantly more than the border areas.

What sort of cart is that? Curious that it has both a 28-pin and 32-pin DIP on it. I don't know that I've ever seen a 32-pin DIP in anything of that vintage.

Yeah, with the caveat that you need to manage to do all your calculations in very little time. To do four voices in my BTP2 player, I need lots of data tables and a fair bit of magic. On every scan line, two voices are sent out AUDV0, and two out AUDV1, using a total of 46 cycles. That's not much.

There aren't really any rhythmic limitations on the 2600's hardware. Check out Toyshop Trouble for an example of what can be done rhythmically (mixtures of triplets, swing, and non-swing eights). It's also difficult to describe everything that's possible using once-per-frame updates of audio registers. The opening music to Thrust+ shows some amazing effects that can be achieved. If one doesn't mind bashing audio registers continuously, the sky's the limit. Stella's Stocking uses the BTP2 music driver, which can play four-part harmony; each voice can independently be loud or soft (two settings), and can play any pitch within a five octave range (full chromatic support).

A surprising number of games use missiles and the Ball for interesting shapes. I'm pretty sure Atari's Basketball, and Activision's Fishing Derby and Tennis predate warlords; their use of the missile sprites aren't terribly exciting, but they go beyond rectangles. M-networks' games are in some ways the most interesting, because they often use the one or both missiles in ways that are indistinguishable from player sprites.

As of a few weeks ago, at least in my area, there are still low-power analog broadcasts.

I am, but the emulator does not do so accurately.

I really need to dig out my code and see what I was doing, but my recollection is that I did some sort of modification to the display list each scan line (I forget exactly why, but I think I was re-using display list entries). On the emulator, those modifications affect a different scan line from what they do on a real 7800, which throws things off.

Do you allow for smooth motion of the worm segments? If I can get my PC set up, I'll try to dig up a worm test I did using 320-pixel 4-color mode. Unfortunately, I can't get the same code to work in both emulation and real hardware; I think I've posted my test on AA, but I forget whether it was the hardware or emulator version. The basic trick is to define four character sets (if you want the worm to move in four 'steps' per character cell) and have 32 characters for the worms: 4 with the head entering a cell (from up/right/down/left) 4 with a body segment entering and a head leaving on the opposite side 4 with a body segment entering and a head leaving after a 'right' turn 4 with a body segment entering and a head leaving after a 'left' turn 4 with a body segment entering and a body segment leaving on the opposite side 4 with a body segment entering and a body segment leaving after a 'right' turn 4 with a body segment entering and a body segment leaving after a 'left' turn 4 with just a body segment leaving This makes it look as though the worm is being animated along its entire length, even though it's really just an illusion. Only the head and tail of the worm need to be updated each time it's moved; the body can just stay as it is.

No, they're not identical, but they don't connect in any way which makes even localized sense. In Adventure, with very few exceptions, going north and then south, or east and then west, will leave you where you started (how many exceptions are there other than via the bridge or the castle gates?) The rooms can't be laid out on a plane, but for almost any pair of adjoining rooms, the left wall of one room will match the right wall of the room to its left, the top wall of one room will match the bottom wall of the room above, etc. If the Superman blocks had been arranged so that the colors and shapes corresponded with streets and neighborhoods, that would have improved things greatly, IMHO. As it is, the arrangement just seems random.

One feature that would have been really cool back in the day, and probably wouldn't have been too hard, would have been to allow a player to select a random number seed (from, say, 10,000 possibilities or for some games even 100). Without such a feature, a time score isn't very meaningful, since there's a lot of luck involved in how easy or hard a particular arrangement of objects is. With such a feature, though, it would be possible to have contests where players would compete with the same setup. Have each player pick a number 0-99, add all the players' numbers together (ignoring any overflow to the hundreds digit), and have all players use that setting. Imagine how cool Adventure, Pitfall, or Skiing (to name a few) could have been with such a feature.