Urchlay

How do you refuel without blowing up the fuel on a regular basis? I guess it's possible (you can refuel by touching just the wing to the fuel dump, so the bullets don't hit it), but it seems like it'd be a pain. Also, you only get one shot on the screen at a time... if you've already got a shot on the screen, and a new enemy scrolls in from the top, you can't shoot him immediately. Hm.

Yep, works great, on an NTSC 800. Cool game.

Qix, on the Atari 800... to guarantee you're in "slow draw" mode. That's what I'd use it for, anyway. Most 2600 games don't let you hold down the fire button and get multiple shots. Hm, are there any 2600 racing games that use the fire button for the gas pedal? It'd be useful for that (but Pole Position uses the fire button for the brake, not useful).

Also, the only one that runs on a stock NTSC 800, out of the ones mentioned so far. I don't actually remember how to play it though Klony, Flower Mania, Micro-X, Tigris: I just tried these (from AA threads, or cracked versions from Holmes and/or CTH archives) on my 800, nothing worked. Monex (from Homesoft disk #299) does load and run on the 800, but the screen jumps constantly during play. Probably it would work on a PAL 800 (I've only got NTSC here in the US). Too bad, this game has excellent music, and looks like it would be pretty cool. I was able to play Atartris, Cooltris, and Tetris 3D on the 800... out of the 3, Ataritris is the closest to standard Tetris. My favorite puzzle game on the 800 is probably Boulderdash. I just recently discovered the Bandit Boulderdash series (here: http://www.mushca.com/f/atari/index.php?idx=B )... that's 54 more versions of the game with different levels. Not sure if this is what the original poster was looking for (not very Tetris-like), but I really like 'em.

Someone's attempt at a rapid-fire mod, that either never worked, or no longer works? If I had that stick, I'd feel duty-bound to take it apart and find out

Maybe the copyright for Keystone Kops had expired... so they wouldn't have had to pay to license the characters like they would with a more modern movie. ...or maybe the designer was a fan of the old movies?

I just got through playing the C64 version of Jumpman Junior for the first time... have to say, I still like the Atari 8 version best. Was Jumpman Jr. ever released on the Apple II? I've got a IIc around here somewhere, could hook it up and try it out.

Only problem is, that would leave other operating systems out in the cold... you can't use "the standard Windows way of doing things" on a non-Windows platform, and there are plenty of us using Linux, Mac, FreeBSD, GP32X, PDAs, etc who would like to use emulators, too. ...though MESS and MAME are Windows-native programs (everyone else has to run XMESS/XMAME). I thought MAME on Windows did have a standard Windows UI... MESS doesn't?

Nope, they don't work. Neither does the 2nd fire button on a 7800 proline stick. Eh, but the Stelladaptor's a USB device, you could buy a USB numeric keypad (there are a couple on this page: http://www.targus.com/us/accessories_key.asp ), and set up your emulator to use it for the keypad buttons. Assuming your emulator lets you map Num Lock as a button, that gets you 4 rows of 3 keys each, with some extra keys you could map to reset/select/etc or just leave unmapped. There wouldn't really be a good way to attach the Star Raiders overlay to it, though. You'd have to sit the overlay next to it, or just memorize the keys.

Hey, that's got a nice 1960s retro look to it... reminds me of Dad's old radio controlled model plane transmitters from around then. Does it use microswitches, leaf springs, or something else?

Poker Squares does, though I didn't do anything fancy (AND $0F the colors before storing them).

Nope, the 800 has composite and s-video at the same jack. The 1200XL (and most, if not all, XLs) have the same jack, but for some reason the chroma pin isn't hooked up. Means they can't do s-video without being modified, though they were originally supposed to. The XEGS just has a regular RCA jack for composite, and another for audio. They did away with the 5-pin DIN (not sure why; surely two jacks are more expensive than one, even if they're different types of jack?)

My only real gripe about 7800 Galaga is that the enemies are supposed to move in circular patterns, but they actually move in wide oval-shaped patterns. The 7800 pixels aren't square (neither are the 2600 or 5200), but the programmer could have made allowances for that... presumably he's already doing fractional pixel movement, since the bad guys do move at different speeds, so it shouldn't have been very difficult to scale the horizontal motion. Of course, I haven't looked at the code, and everything's easier to see in hindsight... so if the original programmer of the game is reading this, please don't take it as an attack on you or your game.

Hm, I can't tell from the glare in the picture, does that have the 4/8 way adjustable gate? I just recently got a joystick that looks just like that, with 4/8 way gate, in a giant box of TI-994A stuff someone gave me. Should dig it out and try it with Pac-Man.

Well, it helps that I have big hands... but you're right about the button on the base, I never use it. I used to think the Wico sticks would last forever, but that turns out to be wrong... I've got a worn-out one that died in the last month or so. My second choice after the Wico is the standard CX-40 Atari stick. Only complaint there is that I have to either keep my thumb bent to reach the button, or else press the button with the side of my thumb instead. Either position gets uncomfortable after a while.

The Wico Command Control. You've already got 3 pictures of it (two in boxes). To me this is the pinnacle of home video game controller goodness... nothing before or since comes close. I have 6 of these, which is probably a lifetime supply...

I can't speak for the original poster, but I have an 800, a 1200XL, and an XEGS... and I use the 800 pretty much exclusively. Compared to the 800 (even its composite output), the 1200XL and XEGS look like crap. The 800 is also the only one with s-video output, which looks so good it almost makes my eyes hurt (but in a nice way). I also like the 800 keyboard a little better than the 1200XL (and the XEGS keyboard is so bad, I can't stand to use it at all). I know it's possible to fix the 1200XL's video (the supervideo/clearpic mods), and some day I will... and at some point I'm going to want more RAM than 48K, which pretty much means using an XL/XE. But I'll always keep the unmodded 800 for gaming, if nothing else. I don't suppose a 32-in-1 OS upgrade exists for the 800, does it?

You can build your own... get a PC (can be an old, slow one or a shiny new one), install Linux or FreeBSD (or anything else UNIX-flavored). Set it up for serial port logins (generally by editing /etc/inittab), make sure lynx is installed. Use a null-modem cable with an 850, PR connection, or whatever... or use an SIO2PC cable with the R-Verter or SX212 driver (though you won't be able to use the SIO2PC normally while doing this).

Well, I recently replaced the keyboards in my 800 and my 1200XL... without taking them apart again right now, I'm going to say the keyboard connectors were the same (or very very similar, I didn't count the pins), so it's at least possible that the 1200XL keyboard might work on an 800... ...but the 1200XL keyboard won't physically fit inside the 800. You'd have to cut up the front (top) of the 800's case to make room for the extra row of keys (start/select/option/help/etc), and you'd have to figure out a way to mount the 1200XL keyboard (drill new holes, since the screws are in different places). I wouldn't do this to my 800, even if I liked the 1200XL keyboard better (which I don't. I actually prefer the 800 keyboard, at least if it's the original with the brass contacts). The person you really want to talk to about this is MetalGuy66. He's the king of this stuff...

Normally it's done by flipping the on/off switch as fast as you can, or by trying to balance the switch in between the "on" and "off" positions (same thing). The actual "fried" effects seem to be caused by the 2600's RAM contents being partly scrambled. My idea about turning down the voltage is only an idea: I think that turning the voltage down far enough will have a similar effect on the RAM, but with less chance of damaging anything. If nothing else, regular power-switch frying could wear out your power switch long before its time. I don't know what the odds are that it would ever damage anything else, but I've heard people say it's happened to them... and I've heard other people say they've been frying 2600's for 20 years and never broke anything, so make up your own mind I guess.

If you're really worried about damaging your console, you could use an emulator... Stella 2.1 and up have emulated frying support. It's not emulated perfectly, but it can duplicate at least some known frying effects. I think it might be possible to do safe frying on real hardware, too. I haven't tried this, but... you'd need a variable power supply, 0 to 9 volts DC. Turn it up to 9 volts, get the Atari running with it normally. Turn the voltage down until you see glitches, then turn it back up to 9V. You could probably use one of those radio shack "universal" power supplies, the kind with a switch you use to select the voltage. Just don't set it for more than 9 volts. You could also use a variable AC transformer (a variac), and plug the standard Atari power supply into that. I think it'd be more expensive though.

Have you tried transplanting the tape and reels to a new cassette shell? I've fixed an audio tape that way before. It might even be possible to transfer just the tape, and use the new reels. Some brands of cassette have reels with locking mechanisms that hold the tape on the reel, which you can unlock and remove the tape... though your Boulderdash tape probably doesn't have these (you'd have to cut the leader... assuming it has a leader). Of course, this ruins the collectible value of the tape. I don't think I'd use WD40... I think it might gum up the tape player, which would put you in a much worse situation than you're in now.

Yes, you have to set it up, but you do know it comes with software that helps you do that, right? There's also a forum full of people willing to help you with the setup if you're having trouble. You do have to copy your ROMs to the card and build the menu... but you only have to do it once. After that, you just plug it in, turn it on, and play. It has a text menu, and you use the joystick or console switches to pick the game. Man, you don't know what you're missing... the CC2 is like a multi-cart where YOU decide what games are on it. How can you beat that? I paid $200 for mine, and it was worth every penny. I only wish I'd gotten a second one for my other 7800...

How? The only ways I know of to read the program counter on a 6502 are to either trigger an interrupt or perform a JSR. The 6507 hasn't got interrupts, so you can't do it that way... too bad, because this is the kind of job interrupts are tailor-made for. All the following is likely to be impractical or just plain wrong: I've got a programmer's view of the 6507, and I'm not a hardware guy... Still, I might give somebody some ideas (used to call this "brainstorming"), so here goes... What would the switch actually do? All I can think of is that it could enable the ROM in your pause cartridge and disable the ROM in the game cart... but that would just result in the CPU starting to run code in your cart at whatever the program counter happens to point to (effectively, a random jump to somewhere in your code space). Not useful... As far as I know, there's no way to look at the cartridge port pins and tell which fetches are reading code and which are reading data, either... Hm. Here's an idea... your switch causes all fetches from the cart address space to return $EA (the opcode for NOP). Assuming the first read was an instruction fetch, the 6507 would just keep running NOPs. Unfortunately the program counter would keep incrementing... maybe instead of NOPs it could return a JMP that jumps to itself. Or a JSR that jumps to your pause-cart ROM. Still, there's no way to tell code from data... if the game program is loading data from the game ROM, and you return the opcode for NOP or JMP instead of the expected data, you stand a good chance of glitching the game (possibly it would recover). Maybe a better approach would be to modify the console itself: replace the 6507 with a 6502 on a daughterboard (which plugs into the 6507 socket). Most of the 6502's pins would be routed to the same pin on the 6507 socket, but the NMI line would go to your pause switch. The switch would have to stop the 6502 (like WSYNC does), bank in some ROM that replaces the cartridge ROM, and trigger an NMI. The onboard ROM code would have to avoid using any RAM or changing any CPU state (it could be a JMP that jumps to itself)... but it would *also* have to save the program counter somewhere! So you'd have to add some RAM as part of the mod, too. It would end up costing more than the Atari and would require an awful lot of work (which I don't know how to do). So scratch this idea, I guess. Although... STA WSYNC, as I understand it, actually disconnects (or grounds?) the 6507's clock input. Is there any reason your pause switch couldn't just do the same thing? The CPU would just sit there, not running, until you release the switch and reconnect the clock (the TIA would display vertical bars or a blank screen, like it does if you power up an Atari with no cart in it). I don't know, but there may be some limit on how long the 6507 can maintain its internal state without the clock line. I remember someone talking about that on [stella]... This would still be a mod to the console, but a dead simple one (just drill a hole, mount a switch, wire it to the appropriate place, perhaps you'd need to cut a trace or lift a pin somewhere)... assuming it'd work. Probaly this isn't really needed. If you can restore the program counter, flags, and registers, the ROM should "recover" on its own (this is based on my experiments with Stella's debugger and "frying" support, real hardware is of course different, disclaimer disclaimer yadayada). Mostly INTIM is used either to time overscan/vertical blanks (in which case, saving it would be pointless: the TV won't wait for the TIA to finish the frame), or for I/O, like sending data to the Atarivox/Savekey (again, the device wouldn't wait for you to finish, if you paused in the middle of I/O).

Looks like a standard Atari 8-bit executable header... if that's the case, its load address is $0000 and its end address (not length, there is no length) is $0FFF (which is 4095, not 4096... which is correct for a 4K image). Loading anything at $0000 would be a very bizarre thing to do, though (and likely impossible, since whatever you're loading would overwrite page 0, and it's hard to imagine a binary load routine that doesn't use any page 0 at all). However, if it's for use with an EPROM burner, the $0000 might be the offset from the start of the EPROM, rather than an actual address. How did you create this file, exactly? Did it ask you for a start address for the file, when you went to save it? Presumably you'd be able to burn any 4K image by prefixing the raw image with the same 6 byte header. Worth a try, anyway.