LocalH

I think it appears on all but world 8. Also, it actually IS useful, because the treasure ship replaces one of the Hammer Bros., giving you two free lives (one for coins and one for a hidden 1-up mush). You still have to fight a Hammer Bros. at the end of the ship level, however, and you also still get the item that you would have gotten anyway. I forget whether or not you have to enter the ship or not, like you do with the Hammer Bros., so it's possible that you can skip it if you really want to (sort of like a free Jugem's Cloud that only works with that Hammer Bros.).

I don't think so. I also think they fixed the double-jump-from-mushroom in SMB1/SMB2j. I have yet to check if they took away the hat stomp in both or the high bounce in SMB2j (which allowed you to bounce much higher than in SMB1, by jumping up and clipping the corner of a Paratroopa). I think the wall jump is still there (I think it's related to the world 36 bug, since to get in the wall you have to essentially begin to wall jump, and hit the wall on just the right tile boundary), but I've never done it.

He's basically the Harry Anslinger of the videogame industry. We'd better hope Jack doesn't achieve the same thing with games that Harry achieved with cannabis.

You can get Mario inside the wall on the SNES version, but they fixed the bug where the outer two pipes had a world value of 36, so that you still go where you're supposed to. I know you can get Mario inside the wall because I've done it numerous times. Those GameFAQs FAQs are wrong. The NES world 36 is kind of useless, but do the trick on the Japanese FDS version of the game, and you get some even odder worlds. World 36-3 is one of the Bowser levels (I think it's the one from world 4) with underground graphics instead of castle graphics. Finish 36-3 and it acts like you beat the whole game, complete with the B button world select on the title screen.

Don't forget that you can also duck and protect yourself from fireball damage, but you can no longer slide down hills.

I didn't think the 1200 had RF, I thought you had to use a 520 with it to get RF. Of course, I never actually owned a 1200, but I used to be friends with a guy who did, and I don't remember it being anything but composite and RGB. The 500 and 2000 have composite out, but it's monochrome, not color. The earlier the game, the less likely it will work on the 1200 without the aid of a degrader. I recommend TUDE as your degrader, it has quite a few options and you can usually figure out how to get many (but not all) games to boot. Edit: Huh, now that I look around I guess the 1200 does have RF. Seems weird, as I don't remember any other Amiga coming with a builtin RF modulator (maybe the 1000? I know it came with color composite whereas other Amigas but the 1200 came with mono composite, and the 3000 with no composite video out).

I definitely recommend FCEU. Quite an accurate emulator, and it works with any controller that shows up in the "Game Controllers" control panel.

If it's the plain one, I can't say one way or the other. At such a low cost, it's worth a try, and as a plus, even if it doesn't, the PSX adaptor (which is the same one I own) comes in really handy for using a standard pad to play classic games. I know some people say the d-pad isn't really too good, but I don't have problems with it. Hell, I can even acceptably play N64 games with it.

Is that the plain Real Arcade or the "Real Arcade Universal" with GC and XBox connectors as well? I had problems getting my RAU to work with my PSX adaptor (although a DualShock2 works perfectly). I ended up having to get a four-way XBox adaptor to use it. Through the XBox adaptor, however, it simply kicks ass. Only cost me $50 for the joystick plus another $20 for the adaptor, whereas an X-Arcade controller costs something like $100.

You can also speed up the 1541 by about 25% with a VIC-20 by putting it in 1540 mode. Do this with the following BASIC statements: OPEN1,8,15,"UI-":CLOSE1 The drive will work fine without it, but it will be expecting the slower serial protocol of the C64, and since the VIC-20 has no badlines, the UI- command speeds it up. You can use that command on a C64 too, but you have to disable the screen, otherwise the badlines will trip up the serial accesses.

You can. This particular program works best in straight DOS, however (but there is also information included to help you gain access to 1581 disks under x86 Linux). It works with standard D81 images, as used by many other tools (including VICE). It can handle both reading and writing disk images.

Which is why you can only use illegals if you're pretty sure they're consistent on a platform, since they will break on the expanded instruction set. Even so, there are some illegals that are unstable between, say the C64 and C128, or even between different vintages of C64. I'm sure the same is true to some extent with other 6502-based systems. But, the ones that are stable come in handy for the tightest of the tight cycle-timed code, such as is common on the C64.

Well, I haven't actively programmed 6502 in about a year and a half, so I guess I need to bone up on it again. =P

Well, it's a bug in the sense that I'm pretty sure JMP is the only instruction that exhibits that behavior. So, if you do LDA ($0FFF,X) with X=0, then I'm sure it will read from $0FFF and $1000. Like I said, I haven't done them myself, as I do tend to align my vectors on even bytes. But nonetheless, if you're aiming to replicate 100% accurate behavior, then you must take it into account.

Also, make sure you remember the RMW instructions that read the target address, modify it (by writing $FF), then write the target value. This comes in handy in some instances, for example on the C64 to ack a raster IRQ you can just do LSR $D019 and save a few cycles.

As far as I know, the only bug is in the indirect jump. If you do an indirect jump with a low byte of FF, then the CPU will not increment the high byte and read from the wrong page. For example, if you do JMP ($0FFF), then the CPU will get it's final target address from $0FFF and $0F00. As far as I know, all other indirect opcodes work properly. I'm pretty sure this bug is fixed in the 65C02 and 65816, but most if not all NMOS 6502 implementations have the bug. Edit: Gah, I misread, and thought you were asking about the bug. ZP always ignores the high byte for a saving of 1 cycle. Basically, indirect jumps forget to handle the high byte like ZP opcodes are designed to do. It still reads both bytes, and thus takes the non-ZP cycle count. It just forgets to increment the high byte.

You might want to place a small sticker over that EPROM window, just to be safe.

Best thing to do would probably be to do (or get someone to do) the composite or S-Video mod, and just forget about RF completely. It sounds like your 2600 isn't shielded all too well.

Well, yeah, if he sold them to Tempest then that's different. I was just hoping that he didn't sell that Bobby cart to someone who won't be as helpful with it, that's all.

Please tell me that you kept the Bobby cart for now, and sold the rest.

It sucks that the Bobby proto seems to have bitrotted. If it is indeed bitrot, and not a problem somewhere else on the EPROM or board (like the problems Tempest is having with his Meltdown), then the contents of that particular cart are more than likely lost forever (although depending on the damage, it may or may not be possible to reconstruct what's there, but if it's not a final release binary, then it'll be much harder to do). Given Tempest's role as prototype historian, if he's willing I'd recommend you send that Bobby cart to him, in the hopes that he might be able to pin down what the problem exactly is, so that you (and the whole community) know exactly what is being dealt with.

That almost sounds like some type of RF interference. Any way to provide any screenshots? Do any other games exhibit the same problem? If it were any other system, I'd recommend powering it up without a cart to see if you have the same problem. But since 2600 games more or less directly generate the video signal from the 6507 (with the necessary WSYNC handling), I don't think a bare 2600 would generate any kind of valid video signal.

Here's your chance, if you run Windows - and it's fully legal, since it's coming straight from Bill's website. The only caveat is that joysticks are not supported, so you'd have to use some sort of Joy2Key type program to play it with a gamepad/joystick. I had loads of fun with both of these games back in my younger days, on my old C64. As far as I can remember, the C64 version is pretty much 99% identical to the A8/5200 version, with the exception being the number of possible colors.

If the second fire button is handled the same way as on the Amiga, then you can use a standard Genesis pad - B is button 1 and C is button 2. I used to use one to play Mortal Kombat on my Amiga years ago, and it was much better with two buttons.

Or you could just go find a proper BIN/CUE rip, that is if one exists for the game you want to burn. ISO/MP3 sucks majorly, and should be banned from the Internet. That guide sucks as well. For example, that talk about "WAVs of too high a bitrate" is complete junk. There is only one 'bitrate' that works on a standard CD audio track, and that's 16-bit 44KHz. If you convert the MP3s to 22KHz instead, then most likely your burning program will either puke on it, or automatically convert the 22KHz audio into 44KHz. Based on this and my next point, this probably seems to work because there is indeed enough space for the full WAVs, and the burning software resamples to 44KHz. Which is also the ass-backward way of doing it, since you waste time and lose quality for absolutely no gain, plus you introduce aliasing when converting 22KHz to 44KHz. Also, the talk of "more than 700MB total ISO and WAVs" is junk too. You can fit more audio on a CD than you can data, since the CD audio is more or less stored "raw", where data CDs have more robust error correction that lowers the capacity. The raw audio capacity of a CD, in terms of WAV file sizes, is somewhere above 800MB.