EricBall

For $100 I can (and did) get both the 2600 and the SuperCharger and have $$ left over. Burning EPROMs also takes more time than downloading to the SuperCharger.

Check out my website.

I think one of the other reasons there hasn't been lots of homebrew development is the level of expectation. Consider that the 7800 has several exceptionally good arcade translations. It would be difficult for the average homebrewer to create something of similar quality. In contrast, the 2600 is a very restrictive platofrm, where a skilled homebrewer can leverage the knowledge of the existing developer community to create games with comparable (if not higher) quality than the most original releases. For example, Skeleton has been praised for being a fairly impressive 2600 game. But if I were to simply port Skeleton to the 7800 without significantly improving the graphics, I am sure it would be scorned. The 7800 also doesn't have an inexpensive RAM cart, like the 2600 SuperCharger, which developers could use to test non-bankswitched games on actual hardware. (Sorry Chad, but US$250+MMC costs doesn't qualify as inexpensive.) Which means emulators & EPROMs.

Hmm, I'm trying to figure out the sequence of events based on the bid history: $338.00 Mar-24-03 09:02:26 PST deanmarc $333.00 Mar-25-03 20:41:54 PST jococco $165.00 Mar-25-03 20:40:53 PST sigridwilcox $138.00 Mar-25-03 20:40:15 PST sigridwilcox $85.00 Mar-25-03 19:41:37 PST karidu69 $76.00 Mar-21-03 09:52:32 PST ataribroker deadmarc put in an early high bid to beat out ataribroker which got pushed to $338 by jococco's $333 snipe. Ouch! Which brings me back to the prime directive when bidding on eBay: "Never put in a bid which is higher than you are willing to pay."

Also recognize that many coin-op arcade games (like Pac Man) used a vertically oriented monitor (equivalent to a TV on its side). This means for a home translation the graphics get vertically squeezed, resulting in lines rather than dots.

The larger left side border is caused by the use of HMOVE on every line. On other games (e.g. Ms Pac Man) HMOVE is only used on some lines, causing the well known black lines. I suspect for some games it is more an esthetic choice.

The 6507 (13) has fewer address lines than the standard 6502 (16) and a Ready (RDY) line instead of interrupt lines. RDY is used to halt the CPU until the next horizontal retrace. The IRQ/NMI could have been used by the 6532 RIOT timer, but it is just as easy to poll. Oh, and the 128 bytes of RAM are part of the 6532 RIOT, not the TIA. All of the TIA registers are either read or write only.

From a failure point of view, Nintendo does seem to be faltering. The NES and SNES were market leaders, but then the VirtualBoy was a complete failure and the N64 and GCN were and have been lackluster against the PS1 and the PS2/Xbox respectively. Where Nintendo is having success and making money is with the Gameboy line and the Pokemon franchises. Could Nintendo fall like Atari or N's old competitor Sega? I wouldn't be surprised if they back out of the traditonal console battle and focus on handhelds. (Maybe a handheld version of the GCN...) It depends on what comes first - pride or profits.

From www.6502.org: BIT is often used to skip one or two following bytes as in: CLOSE1 LDX #$10 If entered here, we .BYTE $2C effectively perform CLOSE2 LDX #$20 a BIT test on $20A2, .BYTE $2C another one on $30A2, CLOSE3 LDX #$30 and end up with the X CLOSEX LDA #12 register still at $10 STA ICCOM,X upon arrival here. Thomas Jentzsch is a master at using BIT (or undocumented multicycle NOPs) to make constant cycle routines. e.g. CPY TOPP0 ; 3 cycles BCC SETP0 ; 3 cycles taken, 2 cycles not taken DC $2C ; opcode for BIT ABS 4 cycles SETP0 STA GRP0 ; 3 cycles Whether or not Y Skeleton makes a heavy use of BIT to decode the maze bitmap since 8 mazes are stored in the same byte. Skeleton also uses BIT to sample the random number generator (either 1 or 2 bits as required).

And don't snub the 6502 simply on the basis of it being an 8 bit CPU. The code is very space efficient, therefore the ROMs can be smaller or more complex games can be squeezed into the same size ROM. As noted before, number of bits is more marketting than a useful measurement. To summarize the differences between the Atari 8 bit consoles: 1. graphics (and sound / periphrial) processor capabilities 2. RAM & ROM size Although the 2600 has extremely limitted graphics capabilities, it is also extremely flexible. Thus a console which was created to play Pong and Combat, has one of the largest game libraries in history. Lack of flexibility (e.g. fixed functionality) is a much greater limitation. And even where the flexibility doesn't exist it often can be extended in surprising ways (e.g. RAM in a 2600 cartridge or the DPC for Pitfall 2).

There's an almost complete recollection of the development process on my website. I need to go back an add a kind of post-mortem to finish it off.

It's interesting to read Joe's self analysis, and how common some of the challenges, successes and failures of programming the 2600 are. For Skeleton I think I skimped on outside playtesting, and I didn't even think of attempting to manufacture my own cartridges.

The bin can be found at http://www.atariage.com/2600/roms/Skeleton_SP.zip and it works on an unmodified SuperCharger.

It has come to my attention that some people are having problems with Skeleton on certain 2600jrs, and maybe on 7800s too. If anyone out there is having a problem with Skeleton, and has a Supercharger or CuttleCart, and is willing to test for me; please send me an email or private message. Even if you don't have a Supercharger, if you have problems with Skeleton (e.g. blank screens, weird graphic glitches), post a reply so I can find out if there is more than one problem. Also include info like the model number or serial number, and whether you have problems with other games, and whether you have gotten them to work on other 2600s. Thanks all!

Combat simply uses one channel for each tank/plane. This simplifies programming, but it is not stereo by any means. Skeleton attempts to create a stereo soundfield: changing the volume of the two channels while playing the same sound on both channels. Combat was also one of the original games for the 2600. There were no stereo mods available at that time. In fact, I suspect that stereo TVs may not have even existed at that time.

I haven't done any more coding, but I have done some more thinking. I'm working on an update to my project page too. My next objective is to have something with a controllable character. Then I need to add in the SuperCharger RAM code and figure out the enemy AI, which should bring me very close to a alpha version.

NTSC to PAL conversion requires the following: - number of lines (192 vs 228 onscreen, 262 vs 312 total) - refresh rate (60Hz vs 50Hz), which may impact gamespeed - colours (PAL has fewer colours than NTSC and different numbering) After going to the trouble of creating a PAL version of Skeleton, I am doublely impressed with Thomas Jentzsch's "hacks".

The 2600 is made up of three LSIs: a 6507, which is a 6502 with only 12 address lines, no IRQ, and a RDY line with a 1/3 colourburst clock the TIA which handles the sprites & other graphics, sound and paddles the RIOT which has the 128 bytes of RAM, timers, joysticks, buttons and switches Emulating the 2600 means strict cycle counting and tracking when the game updates the TIA so the graphics can be changed at the same time. It might be easier to start with the Stella or MacStella source, compile it down and go from there.

So true! For Skeleton, each line I had to check to see if the Skeleton is on that line, and load the player registers if so, and check to see if the radar is on that line, and enable/disable the ball register. Lots of very careful cycle counting.

Skeleton uses a reflected asymetrical playfield to draw the maze and both player sprites for the Skeleton. Ms Pac Man uses an asymetrical playfield for rows with dots, and a reflected symetrical playfield for the rest of the maze. It is very, very difficult to combine an asymetrical playfield with sprite reuse since a normal repositioning routine requires an entire scanline for itself.

The license for Skeleton explicitly permits running it on an emulator. (I snagged the wording from Garfield.) I suspect that many homebrews also permit emulation.

The other place to go for VCD info is www.doom9.net.

I'd love to have S-Video & Stereo (though I don't know if I could convince my wife to let me hook the 2600 up in the living room..). Jacks make it easier if you want long cables, but hardwired means no cables are required, hmmm. Don't know about output tweaks, probably not. BTW your picutre is completely black on my system.

Exactly. I released Skeleton as a rom image first, and as a cartridge second. If another publisher wants to release Skeleton, that's fine with me, but it will not be an exclusive (maybe exclusive to the platform though). And whether the royalty is per-piece or a one-time charge (which could be per-piece on an estimated sales volume) would have to be negotiated. Unfortuntately, I doubt that Skeleton has enough attraction to be a significant part of a homebrew anthology. Also, part of the attraction of the Activision Anthology is the nostalgia people have of playing these games when they first came out. Homebrews don't have that same mystique. (Ahh, a Mystique Anthology )