"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."

See, I consider a program with a bug in it -- even one that causes it to crash immediately -- to still be a program (albeit a buggy one). I was introduced to the NESdev community via Commodore programming, and the emulation/real-machine situation is exactly reversed there. Anything you can get to run in an imperfect Commodore emulator is just about guaranteed to run on the real machine, but no guarantees in the *other* direction. (This is, of course, always treated as the emu author's fault, and by this point VICE is very nearly at the "works in VICE if and only if it works on the real machine" level. I'm not as plugged into the Spectrum community but I understand that Spectaculator is at similar levels of verisimilitude. To my knowledge, nothing in the NES emulation world even remotely comes close.)

You missed my point regarding dropping the community to five members. You're a programmer: you know how bug reports work. You never -- never -- EVER deliver bug reports insultingly, or even with a sense of entitlement. It's just "This doesn't work. Here's how you reproduce it. Here's diagnostic information to help you track down the problem. Maybe even here's a patch to fix it, depending on the community this is." Your attitude in the posts (albeit not in the actual bug reports) was "This doesn't work. You fucking retard. Never let us hear from you again until you've fixed it. You'll probably have to reverse engineer the console yourself if you want guidance though, because the downloadable documents that you were working with were incomplete, and so we blame YOU for your ignorance." And then the NES will die in obscurity, which is not what we want.

>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!

First: "neglect." Second: Even if it does run, it's still buggy. Third: How do you propose they fix it if it doesn't work and there is no documentation?

>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.

There's a vast store of documents on this very site, describing in great detail what the responses to various reads and writes to I/O ports do. All the demoeffects out there are happening because people actually *understand* what the hardware will do, and are exploiting this knowledge. If we want to grow the NESdev community, this understanding must be transmitted. Burning heretics isn't going to increase the community at all, just make it painfully obvious how small it was. Burning *people who are trying to convert* is actively counterproductive, and it is this that I am calling you out on. Newbie NES developers aren't going to start by investing sizable amounts of money and time in a hardware testing platform, and you clearly know this (hence your testing offer).

Also, the whole point of my WRITING the NES 101 document was not to predict *everything*, but to instead construct a baseline set of routines that would be known to work. Thanks for claiming my task is impossible; I'll keep that in mind while I ponder the Programming Guides for every other platform in the universe.

Demanding that people make extensive investments in hard-to-find-equipment and, essentially, require that they have access to an electronics lab just to do debugging, is a "hurdle" that really, honestly, shouldn't exist. And for all practical purposes, it DOESN'T exist for the other 8-bits.

Also, for the most part, your bug reports are about "industry standard", so you do seem to understand at *some* level that antagonizing potential developers isn't all that productive.

I note in closing that both NES 101 and Galaxy Patrol don't behave as intended on real hardware, and yet they both do *something*. Are they NES programs or not? (Also, Galaxy Patrol development was aborted due to it not being a very good *game*, and the glitches you saw show up in reasonable emulators too. Does this make it more or less a NES program?)

We clearly have irreconcilable differences involving the moral stature of people who write buggy code to standards only dimly understood, and that through reverse engineering. I'm going to keep cutting them slack, but aim to get them accurate information so that they can produce stuff that works.

This means that with respect to NES 101, our goals actually coincide, so perhaps we can each further the other's goals. Further discussion of that will be in a separate reply.