EricBall

There were a couple of bugs in the MESS a7800 video driver which should be corrected in the next release. I'll give Tower Toppler a try.

What do you mean by artifacting? The 2600 & 7800 graphics are based around pixel clock = colorburst or half colorburst with (on the 2600 at least) the color provided by a delay tapped colorburst signal. Everything I've read about video mods for the 2600 & 7800 haven't indicated any color problems. (I haven't worked up the courage to do my own mod. I also have some ideas using some VLSI video amplifiers.)

As Rasty tried to point out, Skeleton+ creates a psuedo-stereo sound for the Skeleton's steps. Left & Right volume depend on the Skeleton's position in relation to the player.

What you need is a basic text editor, an 6502 assembler and MacMESS. Ooops, forgot, you will need someone to recompile a78sign.c for the Mac. Although you may be able to use one of the modified ROMs (or even the PAL ROM) to bypass the digital signature check.

As for Kirk's idea about using the playfield registers and storing heights, hmm. if we asume y = row number cpy hpf0b4 ; height of pf0 bit 4 ror ; cpy sets the carry bit, shift it in Okay, that makes it possible to create the playfield values on the fly. It's expensive though, 5 cycles per bit. That's far too many for a asymetric playfield which requires 36 cycles minimum per line. So that means a 6 line kernel ((40*5+3*6)/(76-36)). It would be a big 'un too. But not impossible. Two sets of PF shadow registers, update one set while the other is being displayed. And there's no time for sprite updates ((240-216)/6=3.67). Do I hear a 7LK?

Pitfall 2 was an implementation of patent #4,644,495 known as the DPC chip. (Click the image link to get the figures.) Basically the chip contains three (16 bit?) counter based binary waveform generators which are put through a weighted adder to generate a 4 bit amplitude level. Once the counters are initialized, Pitfall 2 reads the adder output from a cartridge memory address periodically (every line?) and shoves that value into the TIA volume for one of the channels. Thus high quality 3 voice music at the cost of some silicon and CPU overhead.

A game could try and detect that it was loaded into a SC or CC by looking at the housekeeping RAM locations used by those devices. The wouldn't work for an emulator though. Though if an emulator always had the same initial values (ie zero) for RAM or other registers where the real thing was random, that could also be detected. About the only way to slow down the process is to use some kind of unique slapstick / bankswitching device like the Atari arcade games used. But the cost of the part would be prohibitive. (Even the AtariAge bankswitching part add $2 to the price of the PCB.) Pitfall 2 is the ultimate version of this. I suspect emulating it would have been very difficult if the patent description didn't exist.

VBLANK specifically, or will turning off everything (with COLUBK=black) work as well?

Correct. You also can't load the horizontal position directly. #1 & #2 are only really applicable if you don't re-use sprites. And since part of the power of the TIA is the ability to re-position sprites on the fly... so that leaves us with #3. So for each sprite the game has a horizontal position variable. The challenge then becomes translating that 0-160 value to the correct RESPn and HMPn usage. Now I hope I'm not giving away too much to say there are ways to reposition a single sprite in one scanline. Unfortunately, these techniques leave very little time to do anything else.

Read The Fine Manual :wink: Depending on the difficulty switches when you start the game, you will either need to kill 5 or 10 Skeletons per level. There are 8 levels in the game. Each level is a different maze, with different styles (long vs short corridors etc). Each Skeleton will take more damage. So the first Skeleton has one life point, the second two, and so on. However, the damage you do is variable as well, so sometimes a Skeleton will take more or less shots to kill. I'm glad that you enjoy playing Skeleton+.

The problem with using add/sub for mul/div is the high variability. And although 2812 cycles sounds like a lot, it can get used very easily.

Series is like a train or chain with "output" of one connected to the "input" on the next. The wires only connect to one component each. graphically: -||--||- Parallel is beside each other, with all of the "outputs" connected together and all of the "inputs" connected together. The wires connect to all components. -||- -||-

Superchargers can be had at a reasonable cost on eBay, and can handle standard 4K carts and do 6K bankswitched. There are utilities to download the ROM image from a PC too. But it is very possible to develop using only a good emulator (Z26 is my favorite) as a guide. Skeleton was developed using only an emulator, with some final testing by others on real hardware.

I just downloaded the 200+MB gold demo, and have spent a few hours completing it (including getting the Blaster). Unfortunately, I have to agree with one of the reviews I read - it's a average first person shooter. First, I you are going to release a 200+MB demo (and what the heck is taking up 200MB in this one level demo?), a separately downloadable test program might be a good idea. Fortunately, my PC was up to the task. Okay, things I liked: 1 - It's TRON. The game looks is like the movie, only better. And there's all kinds of little touches (like the lean & peek) from the movie too. 2 - Umm, there's some neat FPS stuff (like the shock-sticks, and the cluster disc), and some amusing dialog. Things I hated: 1 - The whole saving / jumping / falling / dying / loading got very old getting to the Blaster (which wasn't worth the effort) 2 - Single shot weapons with long reload times and multiple attackers don't mix. Especially when the attackers are better shots than you are. 3 - Why can't I remap the keyboard? (Especially for the lightcycles.) Changing weapons is an annoying two step process too. The lightcycle mini-game is neat, though so far I've found the best strategy is to run away and let the computer-controlled bikes kill themselves. Going head-to-head with the computer, which can react quicker and turn quicker & more accurately, a recipe for doom. A shield-breaker helps, but is not enough. As Gregory said, I'll wait until I see it in the bargain bin.

No 'cause they work very differently. On the Atari controller each switch (fire button, direction) is connected directly to a pin on the connector. In the NES controller (and any other modern controller) contains a parallel to serial converter, so there is no direct pin to switch relationship. People have handwired Atari 9 pin cables to the NES controller internals, but I've never heard of an external converter. There is also a NES style 7800 controller which should work on the 2600.

The forum link from the front page (left sidebar) appears to be broken.

In Hooking up my 2600 to my Stereo Reciever.. there is a discussion of stereo sound on the 2600.

There may be times where a good free emulator does not exist, while a good commercial product does. (Where good may mean several things including the ability to play certain games, or play them at normal speed, graphics/sound quality issues, or even simply documentation & support.) Commercial emulators are often bundled of embedded with licensed games. Examples include the Microsoft Arcade and Activision Anthology series. And even if a good free emulator does exist, there are many cases where a commercial product can make money if they can find customers who are not aware of the free alternatives.

Incorrect: Skeleton/Skeleton+ was written to take advantage of a stereo capable 2600. (And I've been told it works fairly well.)

(From the 7800 Software Guide:) Bit 2 ($04) of CTRL enables "Kangaroo" mode which eliminates transparency, so that any pixel of color "0" will be background color, rather than transparent. Most games will leave this off since it would result in rectangular sprites. However, the 7800 Software Guide also mentions Kangaroo mode in relation to the 320 modes. The 320 modes have a quirk where transparency only works if the even/odd pair of 320 pixels are both color "0". Otherwise any pixel of color "0" will be background color, rather than transparent. Note: Kangaroo and the 320 quirk is not yet implemented correctly in MESS. I have an update to the driver, but I haven't submitted it yet.

1 megabyte ROMs (8 Mbit ROM in NESspeak) wouldn't be out of the question. The bankswitcher would be connected to the 4 most significant bits of the address bus, the data bus, and the read/write line. In write mode it stores the 8 bit data value into the lookup register for the address. In read mode the register is read and provided as the 8 most significant address bits to the ROM (plus the 12 least significant bits = 20 bit addressing). LDA #$DE ; ROM page STA $A000 ; set bankswitch register for page $A LDA $AD78 ; load byte from ROM address $DEAD78 Heck, use the full address and data buses so the bankswitch register is 20 bits wide and have a full 32 bit address!

With bankswitching there's no practical limit to the size of the ROM. The 7800 will only be able to access 48K of it at a time though and there are some restrictions: $F000 -> $FFFF on startup has to map to a bank containing the digital signature and the initial RESET handler. The NMI/DLI (and BRK/IRQ) handler should be fixed in memory along with any graphics and tile data. What to put into the ROM is the other question.

A quick Google search found the following at http://www.howell1964.freeserve.co.uk/part...ts/6510_CPU.htm From a software view this (the 6510 CPU) is almost identical to the standard 6502. The differences include some memory-mapped I/O registers for an on-chip 6-bit I/O port, and a slight variation of the unofficial op-codes. Like the Atari's version of the 6502, the 6510 also had a signal (aec) to tri-state the bus which allowed video processors to take over.

Ahh, the reactivation is under preferences for the item, and you can select up to 12 months.

Don't know when this happened, so maybe it's old news. Although I have purchased several items from eBay, I try to avoid browsing unless I am looking for something specific. But I do have a couple of items I'd buy if the price was right. So I set up them under favorite searches and clicked the email box. It was nice, every so often I'd get an email list of items matching the search, I'd have a look, place watches on some of them, and check back later. But recently I hadn't received any emails, which was a little weird since I got at least one a week. Well, eBay, in their wisdom has decided to make favorite search emails automatically expire after 90 days. (The help says you can re-activate it, but I don't see how.)