LocalH

That's correct, there's a chunky-to-planar graphics conversion chip in the CD32 that doesn't exist in the A1200 (although I do remember seeing a few products back in the day that claimed to add support for the chip).

It's compatible with the 5-pin composite+audio cables, but not the 8-pin separated Y/C cable.

Damn, I saw this and thought the 2600 proto had finally been tracked down again. :/

You might install a small applet called QuickResNT. It implements the sorely needed tray icon for switching resolutions, and it also allows you to choose sub-800x600 resolutions. So, you can use it to switch Windows to 640x480, where you can then set the display properly. Just make sure you use the same refresh rate that you have MAME set to, since many displays set the size based on the refresh rate (both horizontal and vertical).

SNOOPER TROOPS REPRESENT

There are two different kinds of multiplayer possible on an SGB2. First of all, there's the link port, of course. Second, you have some games (I think there was a Bomberman game that allowed this) that could support multiple players through controller port 2 - these would also work on a regular SGB1. I don't know if there was a GB game that allowed the use of a multitap, however.

Downloading and playing ROM images would be the primary purpose of a copier, regardless what anyone says. 997318[/snapback] Not for everyone. The primary purpose of my SMD is to run hacks and homebrew code, and for backing up my own carts =P

Damn, good find. I wish I found copiers around here like that, I wouldn't have had to pay out the ass (relatively speaking) for my Super Magic Drive :/

If by AUX you mean the round "A/V OUT" port between the RF port and the power supply, then yes, just use the link I provided for pinout (the one on the left is the Genesis 1). As there are several different types of 1084 monitors (with different connectors), you'd have to disclose which kind of RGB port your 1084 has - whether it has 9-pin d-sub or two DIN RGB ports. But, you basically wire up the R, G, B, and sync lines to the proper lines on the 1084 side, and it should work unless either your Genesis or 1084 is faulty, or if you plain mess up with the cable. If by AUX you mean the EXT port, then no, you can't, as the EXT port is just another controller port, electrically identical to the two on the front of the system.

The Genesis 1 A/V port only passes RGB, composite, and mono audio. To get stereo audio from a Genesis 1 you have to either mod the console and tap in to the line-level audio signals, or just pull the signal from the headphone port (I find the quality is quite good with the headphone turned up all the way, if you're worried about distortion then you might back it off just a tiny bit). For RGB, look here for pinout. The EXT port was used in Japan for the MegaNet modem. To the system, it's just a third controller port with the opposite gender, so theoretically one could write a three-player game for an unmodified Genesis 1, all you'd need would be a single 9-pin straight-through gender changer.

Yet another vote for a new backlit SP. I just got one for Christmas and it's absolutely beautiful. Some people say that the reds are overblown, but I feel the reverse, that the reds were too subdued on the original GBA(SP). Plus, it supports the largest game library of any of the new backlit Game Boy systems. The fact that it's also $20 cheaper than the Micro sealed the deal for me. Also, GB/GBC games look absolutely brilliant on the new screen, and if you like to play them, then you have to get the SP, as they don't work on either the Micro or the DS.

Theoretically, yes. However, the only S-Video mods I've seen that worked across all machines was the "Neo-Geo" mod that uses it's own chroma encoder and thus is fitted inside the Genesis, but if you were able to stick that circuit into a small dongle that plugs into the Genesis 2/32X A/V port and offered S-Video and stereo audio, then it would work, since I'm 99% certain that the 32X did output RGB. The cable that goes between the Genesis and 32X already passes RGB as far as I know.

Yeah, those round batteries have destroyed many a PCB...both the Amiga and the Super Magic Drive use those batteries, for starters.

For the most part, not really, but there are some minor differences - for example, some graphics were changed when porting Sonic 1 from the SMS to the GG (Sonic's sprite was made smaller, and some of the text for the results screen was redrawn to fit better on the GG screen). Of course there is also the fact that the GG has a larger color pallet than the SMS does, so you're likely to see "flatter" color on the SMS versions of some games. There actually exists a one-zone prototype of S1 GG when it was still using the SMS graphics.

I didn't say you had to do that for all RAM expansions, just on some 3rd-party internal expansions. Hm, that's odd, because I used to have an OCS A2000, and could NOT enter PAL-modes at all until I upgraded the Agnus to an 8372. Of course, while I was at it, I also changed the 512K of slowfast into chip RAM. I didn't upgrade the Denise, however, and so I had problems with PAL in a multitasking environment, but software that took over the machine and hit the hardware directly had no problems with PAL on my old 1084S. Also, if you're actually wanting to be able to power the machine off without reaching for the power supply, just get one of those power strips designed to sit under your monitor. I've got one that I've had for about 10 years now that still works perfectly.

No, as I said, that was an Agnus upgrade - you also had to upgrade to at least an 8372 Agnua to have switchable PAL/NTSC capability. And if you do this, it's also a good idea to upgrade to an 8373 Super Denise, which will basically upgrade your machine to ECS. Here is an example of part of a RAM upgrade that goes in the Gary socket, although the Gary still plugs into the daughtercard, so I still don't know why there would be a loose Gary. It'd either be a spare or a bad chip, as I can tell.

No chip has to be replaced to install a ram card in an A500. You simply insert the card into the trapdoor slot under the machine. 984418[/snapback] It may have been required for some 3rd-party above-1MB RAM upgrades, but not for any of the 512K RAM cards that came out (since the A500 was designed for this to begin with). Also, it's not this situation, but there's also an Agnus replacement necessary for 1MB or 2MB chip RAM, last I remember (for 1MB you just had to upgrade the Agnus and change a jumper, but 2MB required a small daughtercard).

In my belief, cycle accuracy is only important for systems that were primarily programmed in ASM or ML. Once you start getting to the 32-bit generation, you see far less low level coding and much more use of a high level language, so the little quirks in the system that only appear with cycle-exact emulation are much less common than they were on the earlier systems. You also have systems designed around a copy-protection method, instead of the earlier way of handling that in software (and thus creating a situation where a copy-protection routine can fail based on a single extra cycle). With regards to 16-bit systems and earlier, I feel that cycle-exact emulation should be a top priority - the more accurate your emulator, the more software that will run, by definition, since it's closer to real hardware. Where the hardest bugs come up is in the last couple of percentage points (even today, C64 emulators are only at 99% accuracy).

Since you said you needed to bone up on the Amiga, here's a good resource for Amiga technical information.

Well, I was more referring to the fact that, in the C64, the VIC-II pretty much drives the system and has great control over the CPU. Probably a bad choice, however, considering that the way the CPU and TIA are linked in the 2600 is different from the way the CPU and VIC-II are linked in the C64.

Well, sort of. The NES lags because it runs out of time to do all the necessary calculations, and thus it will miss a vblank, causing the game to wait until the next vblank to update the screen. The 2600 theoretically could lag, but since the CPU is more entwined with the video chip than pretty much any system out there (even the C64), you don't see it as much because of the programming practice required when you have to draw the screen yourself. Theoretically, you could have a ROM that had too much code per frame outside the kernel, which could introduce lag.

I don't know what the Genesis 3 video output looks like. It'd be too bad if it has decent video output, as the system sucks in all other ways =P I recommend just getting a Genesis 1 (with EXT port on the back, so that it doesn't have the license screen) and modding it for S-Video. You'll get a much better picture, and you'll also be able to play the few early carts that won't run on a system with the license screen. The only real downfall to the Genesis 1 is the lack of stereo audio on the A/V port, but if you mod it for S-Video then you can also add stereo audio outputs.

I'd like to see some good S-Video screenshots captured from a Genesis. I've captured from RF by hacking games to interlace mode 1 which I can then feed to a DV converter to capture. I then bring down the chroma since it captures heavily oversaturated, and increase the contrast slightly: Note in these screenshots that you can easily see the common low-resolution chroma that the Genesis is known for. On the top screenshot, look at some of the red areas on the banner and also on the edges of the blue parts of the ring. On the bottom screenshot, look at the green leaves on the tree and the claws on the crab, as well as the bottom of the frame where the border appears.

I loved the TAC-2, and I've still got one. I had a TAC-3 that I hated, though, and I eventually ripped the wire away from it =P

It's more or less a real C64-on-a-chip, although the cycles-per-line timing is slightly different from an original C64, which only trips up highly technical demos. Most "normal" code should run fine, and you can hack on a serial port, a PS/2 keyboard port, and an S-Video port.