Take this anyway you want, but WTF is wrong with you suggesting there's something wrong with ME trying to point at the obvious fact that most people here claiming to do NES development are NOT DOING SO and are giving NES development a bad name in general.

Look. Compatibility with the system you've developed your software for isn't "good". It's MANDATORY. Commodore 64 software that only runs on a PC is NOT Commodore 64 software. ZX Spectrum software that only runs on a PC is NOT ZX Spectrum software. Game Boy Advanced software that only runs on a PC is NOT Game Boy Advanced software. PlayStation2 software that only runs on a PC is NOT PlayStation2 software. This list could go on forever, but I think you should get my point by now. Namely the fact that NES software that only runs on a PC is ___NOT___ NES software. Is that so fucking hard to grasp?

And yes, of course I'd like to see additional _NES_ PROGRAMMERS. And a NES programmer, by definition, is SOMEONE WHO WRITES SOFTWARE FOR THE NINTENDO ENTERTAINMENT SYSTEM. Thus, I without a doubt prefer 5 people developing working software for the NES to 500 people who develop software that doesn't work at all on a NES. (or any other standardized platform for that matter)

> Software development works through iterative refinement. The usual model for
> freeware for the past 20 years or more has been "get a version at the bare
> minimum of functionality out and release new versions continuously to deal
> with bugs as they occur." It's really quite effective.

Software that doesn't work as intended on the intended system to be point of being unusable DOESN'T HAVE "the bare minimum of functionality". It has NO FUNCTIONALITY.

> Insulting and threatening people because their code doesn't work to standards
> THEY'VE BEEN SYSTEMATICALLY LIED TO ABOUT isn't going to help; providing
> information on what the standards are is more likely to get results.

Excuse me, but just who the hell are you accusing of "systematically lying" to you about standards?!! What kind of SHITTY FUCKED-UP ATTITUDE are you giving us trying to blame OTHER PEOPLE for YOUR OWN FAILURES and UTTER NEGLECTION of making sure your software works on the platform you claim to have written it for?!! It's YOUR OWN damn responsibility to make sure what you've written IS in fact NES software BEFORE you release it as such!

To stop you from whining again, I'll provide you with the one and only standard there is to NES development: you socket a board of your choice and insert either (E)EPROMs or a ROM emulator cable into it. You then insert this board into a NES unit of your choice and press the power button. (the one closest to the red LED) If it works as intended, you just wrote yourself some NES software. If it didn't, you fucked up. And the only one you have to blame for this is YOURSELF.

If you expect some kind of "The Annotated NES Reference Manual" defining the exact results of anything you try to pull off in your code, you're in the wrong business. NO ONE knows exactly how the NES will behave when it runs the code you've written. That's why we TEST IT ON A NES EXTENSIVELY before releasing it as "NES software". We're programmers, not fortune tellers trying to predict the future.

> That said. The NES 101 tutorial was designed to provide semi-cookbook code to
> get all the basic components down, and (with the help of the people in
> #nesdev) was refined from "runs in all known emulators" to "runs on NTSC
> hardware" -- or so I was given to understand, as NES devkits are few and far
> between, and I haven't had the inclination or equipment to create one from
> scratch. PAL software was never tested, and while writing the code I had no
> information available as to the differences between PAL and NTSC. Feel free to
> try it out; source is included and it's generally well commented, so if it
> fails for reasons that are immediately apparent from the code, direct me to
> the issue, and I might even consider fixing it. After all, telling people how
> to do it RIGHT would generally solve your problem rather more neatly, yes?

Good to hear, since "Runs in all known emulators" has about as much value to us as "my mom and dad think it's really cool".

That said, it doesn't seem to work very well on my NES when testing it. (on my SNROM cart, using an autorunning dumping program to get the CHR-ROM in place) The code is obviously running (since I hear the annoying "pling" sounds), but the screen is black. Could be my equipment, but I find it unlikely. It could be that you don't reset the $2006 switch (which defines which of the two bytes you are about to write to $2006/$2005) by reading $2002 at init. Nevertheless, it is strange that you've gotten other results when someone else tested it for you, unless you've modified the source since then. I'll try to check this out at a later time.

I'd also like to inform you that the joypad reading code is somewhat retarded. A far better way to detect single keypresses is to XOR the old joypad byte with the new one. You then AND the result with the new joypad byte to get a byte for 0->1 transitions and AND it with the old one to detect a 1->0 transition. Gives you much cleaner code.

Galaxy Patrol works somewhat, but there are occasional lags in the scrolling as well as occasional flicker of a garbage screen. You are obviously polling $2002 to get the vblank status. This is unreliable and causes the code to miss vblanks every now and then. That's why you should ALWAYS use an NMI handler.

Diffusion Chamber seems to work without any problems AFAICT.

> Unless you think it's your personal due or are otherwise high-handed about it,
> of course, in which case I reserve the right to fix it and then single you out
> for disdain in the acknowledgements.

Go ahead. Make my day.