EricBall

The TIA only had two audio channels, so it's hard not to make a stereo game. However, Skeleton was programmed with stereo in mind; and I doubt that there are any other games which were.

I created Skeleton with stereo sound in mind, so it should make a good test base for that.

Not being a champ at your own creation isn't unusual. I haven't played enough Skeleton to get through more than the first level. And that's with the direction indicator on!

I have stated previously that I have no problems if other programmers what to ue the Skeleton kernel to create their own 3-D games. Just give credit where it is due. "Ultima VCS, using the Skeleton engine"

I am always glad to hear that people are enjoying my creation. And I hope that those that have bought it feel they are getting their money's worth.

The 2600 has the following graphics available: 2*20 bit playfield (each bit is 4 pixels wide) two 8 bit players (which may be 8,16 or 32 pixels wide or duplicated 2 or 3 times) two 1 bit missiles (which may be 1,2,4 or 8 pixels wide) one 1 bit ball (which may be 1,2,4 or 8 pixels wide) playfield: - fills the entire screen width, but low horizontal resolution - same registers used for left & right halves - code must update registers on the fly, very little time for anything else players: - max 48 bits wide (both players, three copies each) - (for max width) code must update registers on the fly, very little time for anything else - repositioning requires a blank line and causes black HMOVE line at left edge missiles & ball: - no real capabilities; might be used to fill-out playfield or add extra width to players - difficult to squeeze enable/disable logic into tight playfield & player routines The other problem with "high" resolution graphics is the size of the ROM lookup tables required. The easy way is for the kernel to simply copy data from the ROM to the playfield or player registers. However, this requires > 1K of data for full vertical resolution. Note: Colour is an entirely separate problem. Changing colours also requires time. Each sprite is a single colour and it is very, very difficult to change colours on more than a line by line basis.

Can't speak for the 7800, but the 2600 uses a standard 6502 (although it is missing 3 address lines and the interupt line). Page 7 of http://www.6502.org/datasheets/csg6500.pdf details the startup process. PC is loaded from FFFC & FFFD (LSB/MSB), loading SP is up to the cartridge. SP is hardwired to page 1 ($0100-$01FF), although the same RIOT RAM is used for both $0080-$00FF and $0180-$01FF.

NTSC is the North American & Japan television standard. It has 525 lines (480 active) interlaced with a 60Hz field rate (30Hz for the entire 525 line frame). PAL is the European television standard. It has 625 lines (576 active) interlaced with a 50Hz field rate (25Hz for the entire 625 line frame). The French SECAM standard is closely related to PAL though a SECAM 2600 has very limitted colour capabilities. However, multistandard video equipment is much more common in Europe and are able to handle NTSC and variations of PAL with different number of lines and frame rates. But if you are in an NTSC country, you are probably limitted to NTSC cartridges.

http://cgi6.ebay.ca/ws/eBayISAPI.dll?ViewS...&sort=3&rows=25 Still cheaper at the AtariAge store (for Skeleton at least).

I've only done a little bit of buying on eBay, but when I do bid, I tend to place my bid in the dying seconds of the auction. Why? 1. I only bid on items which I consider a good deal. I try to watch multiple auctions for the same or similar items to get an idea of what the going price is. Then I watch several more auctions and place my bid on the one with the lowest total cost (including shipping etc.). 2. I find out immediately whether I've won. If you bid early, you've effectively committed those $$. (Which can get dangerous if you bid on multiple items simulaneously.) 3. It tends to keep the final price down. If I place an early bid, and then someone else places another bid, my cost goes up regardless of whether they overbid me. Sniping also prevents someone from systematically overbidding me. They have to either go high or go home. I will also caution people who advocate sniping with a ridiculously high maximum. Recognize that you are entering into a contract, so if you snipe $10K for Chase the Chuckwagon and someone else snipes $5K, you have now bought CtC for $5K+! Never bid more than you are prepared to pay for an item. eBay is a prime example of the "Greater Fool" principle at work. (An item is only an investment if a greater fool is willing to buy it for more than you paid.)

You are correct. Skeleton was inspired by the memory of playing Phantom Slayer on the CoCo.

Hells bells, this has gone on longer than it should. But I gotta put in my $0.02. About the only other request which came up multiple times was the ability to move backwards. I considered adding it, but didn't feel the need was great enough; while the radar made a significant improvement to the game. The only other change I wanted to put in was to show the Skeleton's arm poking out of a corridor. And I think part of my frustration with some of the larger suggestions is it seemed that no-one had actually looked at the code. There were no code suggestions on how to save space, or tweaks to the kernel to free up the cycles necessary to implement more on-screen improvements. I have to admit that I did come down a little hard on some posters (including you Manuel), but again, it seemed like no-one had taken the time to look at the code. Sigh, I know everyone is going to want to put their $0.02 in again... Can't help it. PS Why are my quotes screwing up?

And that's of how I feel. I don't want to punish the early buyers by making further enhancements or putting out special releases. And I understand that the comments are mostly constructive criticism. (Though maybe if they had been made a couple of months ago....) As for future projects, I have two in mind. (Truely in mind only, I haven't written the code yet .) One I've mentioned previously (a two player version of Skeleton) while the other I'll keep secret until I have something to show. But I will say, that I'm thinking this one will be a collaborative effort, with other people providing levels and music. It will also be for the SuperCharger only for both the RAM and multi-load capability...

Wow, bunch of negative comments here. And some of them hit close to home. Yes, I admit, part of the reason I finalized Skeleton is I was losing interest. Adding the radar feature was much more difficult than I had estimated and required more time & effort. That being said, I don't think that simply adding a level counter would push Skeleton from being a good game to being a great game because it wouldn't address the problem with Skeleton - the game doesn't significantly change level to level. Sure, there's a challenge in hunting down and eliminating each Skeleton; but that's all there is. Yes, it will get more difficult over time as the Skeleton gets tougher to kill; and yes, the different mazes will add variety; but that's all there is. And that just isn't enough to keep people playing. I'd also like to address some of Manuel's other comments. First, I have posted the full source code for Skeleton to the Stellalist. Manuel (or any other programmer) is free to delve into it, and maybe add that missing level counter, or even use the display kernel as the basis of a full FPS RPG. (Just give credit where credit is due.) Second, the binary image of the cartridge ROM is available from AtariAge and the Stellalist for all to use for free. Some people (at least 20) were willing to buy an actual cartridge from AtariAge or HozerVideo. I sincerely hope that these people played the game via emulation and thought it was worth the money. Finally, those of us who have programmed the 2600 understand that the platform has certain limitations and challenges. One of those challenges is the size of the ROM. And although bankswitching is possible, it brings with it additional difficulties. Skeleton, as it is, fits in a standard 4K cartridge, which makes it possible to play using a SuperCharger or a normal EPROM. PS Paul - I really, really wanted to have Edvard Grieg's _March of the Trolls_ as title screen music, but the title & end screen code & lookup tables ate the page needed to store the music. Sigh!

In the PAL version I see 130 free bytes from $0EE4-$0F66. For comparison, the title screen (no music either) is 110 bytes of code + 85 bytes of data = 195 bytes. 'twould be very tough to squeeze in the digit lookup table even. It's amazing how quickly the bytes get used. And don't ignore the fact that the 130 bytes cross a page boundary, so it's more like 28 bytes + 102 bytes. In any case, the current version is the final version. And wouldn't you rather have me develop something new?

From back when was programming PROMs and PALs: PROMs come in two flavours: electrically erasable (aka EEPROMs) and UV erasable. At that time (10+ years ago) EEPROMs were more expensive, so I used mostly UV-EPROMs. UV-EPROMs naturally have a window (which usually got covered with an information sticker), though there are OTP (one-time-programmable) versions which lack the window, but were otherwise the same. EEPROMs don't have a window either, so you had to be careful or you might grab an OTP accidentally. IIRC I did have a couple of older UV-EPROMs which failed to program. That's where you may get bit-rot problems. But I suspect that a EPROM (especially one in a cartridge) will last for a good long while.

The lack of a level counter (or any other feature) really comes down to two reasons: space & time. The code takes up almost the entire 4K cartridge (especially the PAL version, which required larger lookup tables). There isn't enough space left in the cartridge to put in a level counter, which would require some kind of lookup table for the numbers. I also was ready to call the game finished. Creating the PAL version and adding in the direction indicator required more time and effort than I expected. Now that there are actual cartridges available (and a big thank you to all of you who have purchased one) the current version is the final version.

Xot wrote: I love this game, but I'm curious as to what causes the maze to change color? It seems to go from brown to yellow after I zap the first skel, then eventually it goes to red. I assume the red walls indicate I've entered the second maze, but I've never counted my kills to be sure. Correct. There should be a gradual colour shift as you eliminate each Skeleton, then a dramatic colour shift when you change mazes. When the maze changes, you will also be repositioned so your view will change.

The eight mazes are all predetermined, though they were created semi-randomly. Not enough RAM in a 2600 to generate the maze.

The "radar" indicates the direction the Skeleton is relative to your position. So, if the square is at the top center, the Skeleton is directly ahead of you. If the square is at the top left corner, then the Skeleton is somewhere ahead and left of you. What the radar doesn't indicate is the distance or the actual angle. The sound (especially if you have a VCS modified for stereo) does hint at distance & angle. What may be happening to you is you are stepping into an intersection where the Skeleton is waiting in the corridor. The Skeleton has a real advantage in that case, since you have to turn & shoot before it can take a step. My advice is to make use of the sound volume cues to figure out how close the Skeleton is, and be very, very careful when the Skeleton is close. The radar will help you keep the Skeleton in front of you. And if the radar shifts to the right or left of the screen, run rather than trying to turn. You can move as fast as you can wiggle the joystick.

Xot wrote: Also, anyone know why Skeleton is $20 at AA and $16 at Hozer? I think the AA artwork is cooler, BTW. The game is identical - the cartridge and manual artwork are unique. AA had the artwork done by AtariCart, while I did the cartridge artwork for Hozer, and Randy will be doing the manual. In either case, I get the same royalty. The exclusive labels are a way for AA and Hozer to "compete" on something other than price. Plus, it means I profit from those people addicted to collecting label variations. For reference, I will do not plan on creating limitted collector's editions of my games. So don't wait to buy Skeleton now!

The Skeleleton finder can be enabled/disabled using the left difficulty switch. (It should be B=off.) RTFM For those of you interested in cartridges, I will also be working with Randy at Hozer Video to make cartridges available through him. However, the labels will be different/exclusive. Although a label contest has been discussed, the guys at AtariAge haven't decided whether they want to go that route. I don't know what Randy and I will work out yet either. But I will gladly accept any artwork. But before I give the go ahead to make the carts, I need to hear from you that it is bug free. (Especially the PAL version.) And although emulator testing is appreciated, I want to hear from those people with SuperChargers, CuttleCarts, RAMCarts or even EPROMs in ZIF sockets. Happy hunting!

As CrazyImpmon and Rob Mitchell have discovered, the title screen rolls on a 2600. I've fixed the bug and sent in an update for posting. But you can also simply change the following bytes: $300 - 57 $6ED - 25 $6F1 - 30

I am thrilled that everyone is enjoying my creation. And I read you loud and clear that you want an actual cartridge version. For those of you that want cartridges, I have a few questions: 1. Where do you buy your homebrews? 2. How much would you be willing to pay for an actual cartridge? 3. Plain or fancy? And what sort of fancies? However, before I allow Skeleton to be offered I want to make sure there aren't any bugs still lurking in the code. Wouldn't want people to buy a flawed product.