EricBall

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 )

There are two challenges a RAM based homebrews must solve: 1. Handling the missing Write Enable line. On a typical RAM chip, the rising edge of WE latches the data & address buses, thus committing the write. The SuperCharger method is very different, using two memory accesses to write a single byte. 2. What memory mapping to use; possibly some form of bank switching to expand the address space beyond the 4K, and wheter or not to duplicate an existing one.

[quote name="Lee KruegerOther than that' date=' I think folks here have offered up some great suggestions. I think if you could swing it, it would be nice to include as many of the recent homebrews as possible. I'm not sure what the homwbrewer's think about this and with their permission. there should be little to no legal hassles except one -- Thomas's Thrust may have some licensing problems, but, hell, just change the name for the Anthology. Okie Dokie, Skeleton, et. al.. would be terrific. [/quote] Whee! imagine the royalties! Although the standard $5/cart royalty may need to be adjusted to keep the price of the 2600 Homebrew Anthology from being astronomical.

Yeah, I've found homebrews for a bunch of systems, but don't know whether they are useable outside of an emulator. I'm not sure what to make of that. Are you really programming for the console in that case, or just for a kind of function library? It seems that in order to create a homebrew game or demo you need an SDK (documentation, libraries, assembler/compiler, other tools) and either an emulator or a way to run the game/demo on an actual console (EEPROM & CD burners, RAM carts, etc). But the critical item is the SDK, in particular the documentation.

I'm curious; what other consoles & portables have homebrews? The AtariAge store sells 2600 & 5200 homebrews, and I know about the Vectrex, and it looks like there is even a NUON homebrew!

Google for ForceASPI

Each 2600 game kernel is specific to the game. There is no DLI concept, although some games may make use of a simplified form to handle multiple full motion sprites. For a full understanding of the 2600 display, you should track down the "Stella Programmer's Guide". But basically the 2600's TIA is a 1-D graphics processor with two 8-bit player sprites, two missile sprites, a ball sprite and a 40-bit (half-screen) playfield. Any changes to the display have to be made by the kernel on the fly.

Shortly after I put the initial versions of Skeleton onto the Stella mailing list I was approached by AtariAge about offering a cartridge version through them. I gave some long thought about this because, although I wanted to support AA via their store, I didn't want to abandon Hozer Video who was the traditional homebrew manufacturer, nor did I want to encourage a price war which wouldn't be sustainable over the long term. My "solution" was to give both AA and HV permission to manufacture Skeleton for the same $5 royalty, but each would have an exclusive label. (AA also went to the trouble & expense of creating a colour manual.) I also have stated that there will never be a limitted release of Skeleton. (Though I could be persuaded to sign a cartridge...) However, the closing of Hozer Video brings up a couple of interesting points: 1. AFAIK there were only 2 copies of Skeleton sold by Hozer Video, talk about a rare label variation! 2. Hozer Video also offered (but AFAIK never sold) my Atari logo demo as a cartridge. Should similar low selling hacks & demos have any rarity value? WRT the percieve quality of Skeleton, this was discussed here. And although some people (both programmers and non-programmers) feel that Skeleton could/should have been improved before it was released, a significant number of people have paid good money to buy the cartridge even though the ROM image is available from AtariAge and the Stella mailing list (with source code) for use in an emulator, RAM Cart, or personal eprom. Quality and completeness are in the eyes of the beholder.

I bought my N64 back when it was first released and played lots of Mario64 waiting for something else to be released. Now I'm thinking I should make up a wish list to build up a collection that my son (now 2) will enjoy playing. Currently in the collection: Mario64, Mario Kart, Diddy Kong Racing, both Zeldas, both Banjos, GoldenEye and a couple I don't recall offhand. What kid-friendly & fun titles should I look to add to my collection?

The damage you do is random (0-15 points, yes you can miss!), and the Skeletons increase 1 hit point per Skeleton. So for level 3, the Skeletons will have 31-40 hit points so will require 4-5 hits to kill on average. The Skeletons speed up at a constant rate. They start out at 1 step or turn per second. After 2 minutes, they should be moving at 2 steps per second, and after 6 minutes 3 steps per second and so on. (It's tough to measure since they only make noise when they move, not when they turn.) So the faster you kill them the better. Not being able to move backwards was a design choice. You can run as fast as you can move the joystick. Backpedalling didn't seem as realistic. (Okay, I admit it, only going forwards was easier to program too.) I also suspect that you would end up backing into a wall and dying anyway. Shoot, turn, and run is the best option. The reload delay would also get you.

Ahh, but it is possible (just damn difficult). Unlike a couple of games where bugs make it impossible to get past a certain point, there is no such problem with Skeleton. The difficulty is there are 80 Skeletons, and you can't make a mistake.

8 levels, 10 skeletons per level Yes, there is an end screen (nothing exciting though). The source code is available from the Stellalist archives. I've never gotten far (only 2nd level) myself. Patience is the key. Check some of my previous posts for some strategy hints.

The basic logic goes something like this: [*]If the player shot the Skeleton (and the Skeleton didn't die), turn towards the player. [*]If the Skeleton turned last move, then step forward. This prevents the Skeleton from spinning around at an intersection. [*]If the player is "ahead" of the Skeleton (in the same row or column, including wrap around), step forward if possible. The Skeleton has the ability to see through walls! [*]Otherwise figure out which directions the Skeleton can move in (forward, right, left) and randomly pick one, giving preference to moving forward if all three are possible. [*]Turn around if the Skeleton is at a dead end. This seems to work fairly well. The Skeleton wanders around randomly, and although it doesn't seek out the player, it does hunt the player to a certain extent.

Correction - there is no inexpensive way. Your PlayStation was designed to be attached to a TV, so the video signal it creates conforms to TV standards (Luma+Chroma, 50 or 60Hz interlaced, 525 or 625 lines), while your monitor is designed to accept a different signal (Red+Green+Blue, 60+Hz non-interlaced). In order to connect your PS2 to your monitor you would need either: 1. A monitor which has a TV compatible inputs (more common on LCDs & projectors) 2. A converter box - a simple one would convert the composite or S-Video signal to RGB (often used for older projection TVs), a more complex one would also de-interlace the picture.

Check out IrfanView32 for conversion between lots of graphics formats (including TIF, PCX).

Cool! And tell Bobby thanks, it's great to have a fan.

Although I didn't go all the way and have an actual PCB made, I did do a bunch of layout for a 2600 RAMcart. Some hints: There are a bunch of prototype PCB service providers. Most accept standard Gerber files, but some (like ExpressPCB) provide customized layout programs instead. There are some free layout programs out there too, like EasyTrax for DOS. Of course, you could always do the etching yourself (just make the tracks as wide & well spaced as possible). Know which parts you are going to use beforehand & study the datasheets. The 2600 edge connector is almost identical to the ROM pinout and (I think) spaced the same. Unfortunately this makes routing A12 (which is what you need to invert) somewhat tricky (depending on where you want to put the inverter). Have fun!

I guess when I think of hacks, I think of a lot of the more simple ones; particularly those which are changing the graphics only (i.e. non-code changes). Things like Combat Rock and Asteroids DC+ are well above this, and I think that the section name should reflect that.

MP3 BIN2WAV Bad idea! Bad, Bad, Bad, Bad. If you read through the Cuttle Cart Manual You will see that each bit of data is sent as a single wave of either a high or low frequency. MPEG Audio (or Ogg or AC3 or WMA) is a lossy compression algorithm. It's like running the bin through a GIF2JPEG utility. The output waveform ain't gonna match the input. A better way would be to link a lossless compression engine (like GZIP) to WPLAYBIN and do the decompress and play in one step. I'm surprised you are having any success at all.

Each "section" (e.g. Homebrews, NUON) needs a explanation. e.g. NUON was an ehanced DVD player with the ability to play games. And what's this with selling original Asteroids? Is this NOS? I'd also classify the "hacks" more as "improved, enhanced & modified versions of classic games".