supercat

And bartop touchscreens are ONLY A QUARTER. How much more cash would the Galaga/Ms. Pacman games rake in if they'd reduce the price to classic levels? I've played those combo games maybe five times at $0.50; I'd play a lot more than ten at $0.25.

So the ball moves horizontally; does it do anything else (any more updates please?)

Glad you people are enjoying the game. Here's the latest and greatest. Difficulty should be the same as last one. I should still add screen blanking for the "pause" switch (left difficulty) since otherwise it allows too much of a cheat, but otherwise things seem pretty much "there". The title screen shows the selected starting level. After a game, the indicator will show the selected starting level but the gem shape will be that of the ending level. The game should work on a Supercharger (not tested as such). I've tested this one quite a bit under emulation. Still have to test it on real hardware, but it seems pretty solid. I'll have to see how the new gem shapes look, though. Difficulty should be unaffected compared with last version, so keep the scores coming. sgems.bin

Logic that was supposed to kick the game out of looping on the gem color for a wild gem was preventing the game from checking for chain-reaction matches. So if a wild gem cleared out gems in a way that should have caused a chain reaction, those gems wouldn't get tripped until next time. Consistent and reproduceable behavior, but will be fixed next version.

Beat ya! The game is a bit easier than when he got his score. Sorry--they're not comparable. I think I'd prefer if there was an option to keep the standard gems throughout the complete game. I found some of the designs are pretty stressful to the eye and hard to adjust to 956024[/snapback] Aww, IMHO having the different gem designs is one of the cool things in the game, though I would not be averse to changing ones that are hard to see. Which ones give you trouble?

In the Dedicated Systems forum, there's a discussion about how to dump the FB2. The exact same approach should work with any Atari 2600 cart on a real 2600. Basically, you make a dumper cart which is a normal cart with some special code it. You plug this in and power up the 2600. Then with the 2600 still powered up, you remove the dumper cart and insert your other cart and hit Reset. The Atari will then send the contents of that other cart out one of its joyports. If you have a computer hooked up to it (simple two-wire cable) you can capture the data. Voila!

I admit it's been ages since I've played Spacewar against another person, but the thrustthrustthrust approach isn't from what I can tell a great strategy since the the player doing that can easily by a shot that's fired at a comparable angle. Perhaps the FB2 version of Spacewar is different from the one released in 1978 (there are multiple revs of some cartridges, and Spacewar might be one such). Any way you could check that out? Also, the docking ones are a nice challenge. I would think that using the difficulty switches you should be able to have fun playing with your son (make it so he just has to hit the thing while you have to dock).

I adjusted the colors in this one, changed the title screen, adjusted the difficulties, and added a few new features to improve playability. Also, different levels now have different gem designs. Please give me feedback on all of those changes. New features: -1- The game now shows the next set of gems -2- The game now draws a foul line below the third row. -3- You may switch the current set of gems for the "next" set any time UNLESS either set is the "bomber" gem. If there's something you don't need yet, you can thus save it for later up unless/until you reach the end of the level (after each set lands, the set you just swapped with the "next" set will become the current set; push up on the joystick to swap it again). While you're doing this, though, your "next gem" display isn't useful for letting you know what's coming. -4- Changed the sound when a bombergem hits bottom. Not sure I like this one any better, though. I still need to work out what I want for the game over and level-select logic, but the game itself is pretty much done. Problem is I spend more time playing than coding. sgems.bin

I wonder why Atari didn't produce a smaller Po/Key-less version of the POKEY by leaving off some pins (the same way as the 6507 is a 6502 die with only 28 pins connected)? The Pokey is a Potentiometer/Keyboard interface chip that just so happens to have sound built in. I would expect that 20 pins could probably be lopped off without difficulty, though depending upon die size a 24-pin package might be necessary (I don't think there are any standard 0.6" packages smaller than that, and don't know if the die would fit in a 0.4" DIP22 or a 0.3" DIP20).

955273[/snapback] My guess would be that BGH doesn't cleanly initialize all the video registers before showing the first frame, and the behavior may depend upon where in the scan line the CPU starts executing code. Does Stella randomize that? Is there any way to force a particular value?

... my @$$! Where I come from, "mint" means unused, and perfect. No, that would be "new" condition. 954915[/snapback] "Mint in box" is a higher quality standard than "new in box". It implies that the box is not only unopened, but it is also unblemished. That having been said, I can't particularly fault this guy for being deceptive since his photos clearly show that the Atari has been removed from the box (and therefore the box, if there is one, has clearly been opened). Further, he doesn't picture the box at all. He may be drawing in some views from people who want a MIB unit and aren't interested in anything else, but I don't think he expects to profit unjustly from that (since such people wouldn't be interested in his system). I do commend the guy for trying to point out what's good about his product. Many people seem to post ebay listings without putting in any time or effort. I suppose such listings can be good for bargain-hunters, since there will be less competition on them than on better listings. But why do the listers bother?

If you use a 10M put, then rotating it 1/10 of its range of motion will be equivalent to rotating a 1M pot through its full range of motion. If you were to find a 50M pot, rotating that through 1/50 of its range of motion would be equivalent to turning a 1M pot the full distance. You could go as high as you want, but I would expect that things would get hard to control beyond 5 megs.

Since he does a TXA immediately before the SBX instruction, tempvar and X will hold the same thing. The "AND" function you suggest will thus have no effect.

That is correct. Doing it this way allowed us to use the same design for 8K, 16K, and 32K boards, with the only difference being the way the PLD is programmed and the type of EPROM used (2764, 27128 or 27256 respectively). 954501[/snapback] If you expand a 4K bin to 8K, 16K, or 32K, you can use the 8K, 16K, or 32K boards with it (using a 2764, 27128, or 27256). Actually, if you do the data properly, you can use a 27256 for any size game (in an 8K, 16K, or 32K board). To double the size of a .bin file, do copy /b oldfile.bin + oldfile.bin newfile.bin This will convert 4K to 8K, 8K to 16K, or 16K to 32K. Once expanded like that, all 4K bin will play in any size boards. Many 8K, 16K, or 32K bins will work on any "size" board that's at least as "big" as the bin, but some bins are picky and will only work in the "right" size board. But any size board will work with 27256's if you expand the bin files to 32K as indicated above.

Saved a bit of code space (and then proceded to use most of it up again--oh well). Most noticeable new feature this version is the enhanced color handling. The wild gems and "bomber gem" now look visually quite distinctive (maybe the wild gems look too cool). I've also increased the frequency of three-in-a-row and wild gems. sgems.bin

On the other hand, you've now got two nice spare joysticks and also a spare wall wart. Just think of the controllers as being $15 each, and they include a free videogame system. So, you fried the videogame system but still have the controllers.

Some third-party games use two chips, of which one is a 24- or 28-pin ROM. On most of those, the ROM may be replaced by another of the same pinout to play a 4K game. Note that some carts will use the top half of a 2764 and others will use the bottom half, so you'll have to ensure that your file is loaded appropriately. None of the rarity-one games will work for this, but I think some rarity-two ones will. I don't think any rarity-twos will support bank-switching, though.

How do I get one here in the U.S.?

SBX doesn't seem obscure. To be sure, it's probably mostly only useful in the cases where either A=X, A=$FF, or X=$FF, but even with those restrictions it's still useful. And there are some other useful cases as well. For example, if I understand it right, I could replace the sequence: lda Bitmap,x and #$55 tay lda (ColPtr1),y sta Color1 lda (ColPtr2),y sta Color1a with ldx Bitmap,y lda #$55 sbx ColorAdj lda COLTABL1,X sta Color1 lda COLTABL2,X sta Color1a If I needed to save a cycle or save three bytes of RAM this could be very handy. (think think think) I just might do that. (looks at opcode list) Drat--Immediate only. Waaah!

Why not drop out 1/6 of the scan lines from the middle four monkies and 1/3 of the scan lines from the bottom monkey? Monkeys are heavy, after all. That should make room for another monkey at the top.

Another thing I sometimes do with macros: include all the .DB statements within macros (rather than having them operate directly), so that then I can rearrange the order in which items appear in the code without having to rearrange the .DBs themselves. This is especially handy if, as in many of my projects, some of the DBs are in separate .include files. I can .include all of the DB-containing macros at the start of my source file, and then arrange the actual data as I see fit. Another way I use this technique is to produce an "initialized data" segment. After the minigame contest, I'll post my code to SDI to show how that works. It's very easy in many 2600 projects to waste a lot of code with "lda #this/sta here/lda #that/sta there" etc. Four bytes for each location that needs to be initialized. Using an "initialized data" segment reduces this to one byte per byte plus a small "loader": ldx #IDATA_END-IDATA_START-1 lp: lda IDATA_ROM,x sta IDATA_START,x dex bpl lp Nine bytes. So if there are four or more bytes that need initialization to different values, it's a win (13 bytes vs. 16). Even if two of the bytes need the same value, it's still a win. And of course, if more data need to be initialized, it's an even bigger win. Indeed, if ZP RAM is abundant, it can make sense to put small tables of constants into ZP RAM since doing so will save a byte of code space for every access to one of them. And if an address is used three or more times with abs,y addressing mode, it can be changed to (zp),y saving a byte per instance at a total cost of two bytes. Of course, in most cases ZP RAM won't be more plentiful than code space. But knowing how to take advantage of initiailized data is still very useful.

Hey, the fact that the tiles are crooked when they fall is a "feature". In reality, do you think the tiles would always fall perfectly straight? IMHO, having the tiles skewed like that is definitely the way to go. It should look reasonable, and would fit perfectly with what your kernel is already doing for the sword. I don't know if you're still using the trick I mentioned earlier of just loading HMBL once at the start of screen, hitting HMOVE every two lines, and setting the starting position of the sword to compensate, but if you are all you'd have to do would be to change the initial-position logic and store a $80 in HMBL and you'll be all set.

Instead of using 'align', I like to use a macro. The macro can take an argument for how much space is needed (so it doesn't advance a page if it doesn't have to), and can output to the screen/list file how much space it's skipping.

It's pretty straightforward. mac sbpl bpl {1} if (* ^ {1}) & $FF00 echo "PAGE CROSSING","WARNING ",{1}," at ",* endif endm For checking data, use mac pcheck if (* ^ {1}) & $FF00 echo "PAGE CROSSING","WARNING ",{1}," at ",* endif endm and, after each data item, do a pcheck with a label to the start. The warnings are a little less than helpful as simply output, but you can search for them easily in the .lst file.