nesdev.org

In addition to what's been said already, you'll want to double check your S-Video cable to be sure it's actually connecting separate Y/C signals. A lot of the cheap ones just feed composite to both. It usually works, but it looks like crap.

Well, right. I know that. Same idea, but one for each bus.

byuu wrote:Either way, we get to a point where one chip has to know about the others.

Not necessarily. Treat the bus as an object, and all of the chips are aware of it, and it handles all of the intricacies of what happens when multiple things try to write simultaneously.

> bsnes already fails to handle multiple coprocessors with IRQ outputs correctly--each coprocessor directly sets the IRQ pin as if it had exclusive control over it, there's no attempt to handle "I'm no longer asserting /IRQ but the other coprocessor still is" This is important for more th...

Think about it, at 15kHz, you get 15 cycles per ms. You need those cycles to establish a reliable signal that can be distinguished from noise. 15 cycles at 60Hz would take 250ms. And that's just for a single bit. Granted, you could probably use fewer cycles, but essentially, you are talking about a ...

2 things. First of all, the demodulator. This is the #1 reason that you're not registering a hit on an LCD screen. It works very similarly to the IR transmitter in your TV remote. When you're using light, visible or otherwise, to send data, it tends to be very susceptible to noise. So, instead of, s...

Looks like I got it right, chalk one up for rubber duck debugging...

I'm working on a ROM hack of A Link to the Past, and one of the sprites is using the wrong palette, so I'm currently trying to backtrace the sprite loading routine in order to find where the palette is being loaded from and fix it. Unfortunately, I'm a bit lost. First of all, what I know. Here is th...

getopt allows you to handle any "extra" options at the end of the command line separately from the "flagged" options (e.g. -x -y somthing_y -z something_z other options go here). while((opt = getopt(argc, argv, "abc:dDeEfg")) != -1) { switch(opt) { . . . } } while (opti...

Not sure if these tests are at all relevant to the particular code you're working on right now, but just in case they are, here's one of ARM9's test ROMs on real hardware (IIRC, it was a GSU-1 on a SNES Jr)

You can buy 40F supercaps for ~$15, might work for rumble (though they're only 3.6V, so you'd need some voltage conversion, and I haven't checked the physical dimensions). http://www.mouser.com/Search/m_ProductDetail.aspx?Taiyo-Yuden%2fLIC1235R3R8406%2f&qs=sGAEpiMZZMuDCPMZUZ%252bYl5iWezzCXqwLj0c...

thats silly if there is not enough amps then we can just use a higher amper supply if im right? No, the external supply won't increase the rating of the internal 5V regulator. As far as games refusing to run, there's a difference between policy rules that devs had to follow in order to pass licensi...

You probably wouldn't even need batteries in the controller, there's no current limiter on the controller's voltage supply, and quite a bit of headroom in terms of available current when using the OEM power supply.

I think you might need a PAL CIC, or it won't boot.

Just delete the .srm file and it will emulate uninitialized SRAM, which is essentially the same thing as non-battery-backed (except it's probably actually initialized to all 0's, so you might want to test your code against an existing .srm to be sure that you're properly initializing everything, and...