What drove koitsu away from nesdev

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

What drove koitsu away from nesdev

Post by tepples » Wed Oct 12, 2005 3:15 pm

This post on Pocket Heaven details what drove koitsu away from the NES scene. Is there a chance that we could fix the problems he mentions so that we don't drive anyone else away?

User avatar
teaguecl
Posts: 210
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl » Wed Oct 12, 2005 4:31 pm

His main complaint seems to be that the technical information about the NES is getting more accurate. If that's why he's not interested in participating, then that's really his problem. I hate to see anyone get frustrated and leave, especially someone who's contributed significantly to this scene. He says that the current state of emulator knowlegde is "borderline electrical engineering" and he's not interested in it. That's fine, he can do what he wants, but embedded systems like consoles involve EE principles, and unless you're modeling them at a very high level you need to understand that stuff. Anyone waiting for the NES to become less complicated is wasting their time, so it sounds like he's made the right choice for him.
Having centralized and clearly written documentation is obviously lacking right now, I think the wiki is our best shot at that. Maybe instead of answering tech questions in the forums, we can point people to the appropriate place in the wiki, updating it if necessary.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Post by Celius » Wed Oct 12, 2005 10:18 pm

* Attitudes of freelance NES developers and those providing information for nestech. There is a certain attitude presented which is very difficult to describe... it's a combination of "You don't know jack shit" + "I do not show any form of emotion when communicating with you" + "I will present my knowledge in a form that supercedes your existance". I can't say it's an ego thing, because it doesn't really seem to be. It's just a personality trait a lot of individuals have in that "scene", and I just can't deal with it.

I think that's funny that he said that. I always thought I was the dumbone who was the only one confused after having things explained to me 1600 times. It's too bad that he gave up nesdev. Hopefully these forums aren't abandoned by the time we all master nesdev...

wombatguy880

Post by wombatguy880 » Sun Oct 16, 2005 3:21 pm

I agree with the loopy doc thing. Does anyone besides loopy understand what that thing is trying to say? If you do please rewrite it so that it makes some sense and even explain why it doesn't make sense to me so I can research what I didn't know that made it so confusing. EE is important but these documents should be written as they apply to development. If they only apply to hardware modification or creation then just say that. Someone should also compile a list of what is needed to get a game to work on real hardware as that is for the most part the point. If you are developing solely for emulation then it's probably a waste of time. I'm not saying everyone has to own a devcart or anything like that. It'd be nice but it doesn't always work out.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sun Oct 16, 2005 4:54 pm

Yeah... I guess I feel like that sometimes too... I mean, it took me nearly 2 years to understand loopy's scrolling doc, from the 1st time I read it to the day I finally understood it, wich was a couple months ago, with the help of people in this board. It is not actually any hard, but it can, and should, be explained in a better way. I suck at writing technical docs, so I won't dare to try...

I don't know anything about electronics and stuff... I'm a programmer, and what I do understand is LOGIC. Many newer NES documents do lack the logic in favour of inner hardware workings. It may be helpfull to some people, but certainly not me.

However, I feel there is no point in "dumbing down" the documents so that everyone can understand them (in fact, there is no such level, there will always be someone that doesn't understand something!). Maybe we should have as many versions of the documents as possible. Maybe anyone who feels that something can be explained better should give it a try and write their explanation. But then, if someone gets something wrong, it will be chaos, and we'll have lots of wrong info floating around.

Right now, I feel there is really little info on sound programming. I don't know anything about sound or even music (I pretended to play when I was at music class in the 3rd and 4th grades!!). There is no document that can get me iniciated in that area in a simple way, and I guess I'll NEVER have any music in my games/demos. Never. I have no idea of where to begin.

So, I really don't know. There will always be someone saying they don't get something and there will always be people trying to explain stuff the hard way, or pointing them to the same docs they already read and didn't understand. Not everyone has the patience to start from the beginning, use examples and such.

I really don't know where I was trying to get with this post! Maybe nowhere... but at least I got to talk a little about what I think... This place has been kinda quiet lately, and I miss talking about nesdev, even though I haven't had much time for actual nesdev'ing, with a new job and all... have done a lot of actionscript'ing on the other hand, wich is not nearly as fun...! =)

Tokumaru

Guest

Post by Guest » Sun Oct 16, 2005 5:54 pm

There is no document that can get me iniciated in that area in a simple way, and I guess I'll NEVER have any music in my games/demos. Never. I have no idea of where to begin.
Check out FamiTracker or NerdTracker 2 or MCK

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sun Oct 16, 2005 7:16 pm

Anyone can re-present the information in a way that suits a particular audience. The hardware description is fundamental; everything else can be derived from that. The reverse is not true. I can identify at least three uses, from most detailed to least detailed:

- Developing hardware for the NES
- Emulating the NES
- Programming the NES

Hardware developers need to know details that are irrelevant to emulation and programming. Emulator programmers need to know details that NES programmers don't need to know, other than to avoid depending on them. Since the majority of people are not doing hardware development, most people would be satisfied with a description of what happens in response to things the CPU does.

Eventually I'd like to put together a guide for NES programming that shows ways of doing things that avoids subtle problems, but without bogging things down with a description of the problems themselves. One thing sorely lacking is a way for a newcomer to tell what information is central and what is peripheral. Currently it's just a mess of details.

The thing that really puts me off is the lack if distinction between original raw data, original interpretations of this data, and compilations of these that have no new information. I didn't even know that the MMC3 and MMC5 had clear documentation until yesterday when I found kevtris's documents.

drk421
Posts: 328
Joined: Sun Nov 14, 2004 11:24 am
Contact:

Post by drk421 » Sun Oct 16, 2005 8:33 pm

Which MMC3 doc is that?

I've only seen the MMC5 doc.

Having programmed C64 stuff, I'm familiar with the 6502, as well as the SID and VIC2 chip, all of which is very well documented (offcially).

I've just recently gotten into programming the NES's PPU, and must say that I'm not sure which docs to start with. (I've even been told that some are incorrect, and there's nothing worse than using incorrect information).

Guest

Post by Guest » Mon Oct 17, 2005 2:33 pm

I remember the time when the only available info was too abstract at best, and even if that made the NES mysterious and intriguing in a sort of way, I sure prefer the situation now, when things have been carefully detailed at the hardware level. And I am forever thankful to the people who actually took the time to reverse-engineer the hardware, rather than just checking what different games expected the registers to do. Besides, the NES is more or less what got me interested into electronic engineering in the first place, and I'd say there's no more enjoyable way to learn EE basics than soldering up a devcart for your favourite videogame console. =)

That said, I see the reasons for having simpler documents that skip many of the technical details and deal with how to write simple code for it. But if people feel such information is missing, I'd say it's up to them to write it. After all, the people who are being bashed for writing "borderline electrical engineering crap" won't be good at writing a "NES programming for dummies" compilation, nor should it be their responsibility. A lot of the people complaining about the lack of such documentation are obviously competent enough to write it themselves. And if you worry about it adding to the pool of incorrect information, have it reviewed by people who know the details of the NES. Emotionless as we may be, most of us are happy to help out.

But I cannot stress this one enough: if you want to learn how to program a console, the only reasonable way is to EXPERIMENT on it. If you're unsure about how a register behaves from viewing a too detailed hardware description of it, then poke it and study the results. Then go back to the document, and it'll hopefully make more sense to you.

As for the question in the initial post, it's hard to give an answer considering the mix of different reasons Jeremy gives for "quitting the scene". But personally, I'm glad he left. At that time, his bitterness and self-righteousness had grown beyond reason. Newbies joining #nesdev for the first time were being interrogated by Jeremy on 6502 machine code, getting banned if they didn't prove themselves worthy by having learned enough before joining the channel. Or if they were just too young to have lived during the NES's golden era, for that matter. If anything, this elitist attitude is what would ultimately scare people away.

Already being IRC-friends with most of the people who have provided the "too detailed" information docs, I may be somewhat biased. But IMHO, the talk about them not being friendly enough is BS. Without people like Kevin Horton to patiently answer my EE questions, I'd have a much harder time learning the stuff I wanted to. And if they sometimes might have a paternal attitude towards you, I can live with that. After all, I'm the one asking to get lectured. :)

Nowadays, people don't get banned or insulted from not having read enough docs before asking questions. (even if they might be politely forwarded to that information if needed) And people aren't being called "niggers" i #nesdev anymore. Even if the information you seek is now scatthered among several individuals with their own docs and not having someone compile them into an easy-to-read document is indeed a loss, the price to pay would have been higher otherwise, as most people probably prefer "emotionless" communication to one full of negative emotions.

I respect Jeremy for having devoted much of his free time to maintaining a good document that helped me a lot when I wanted to learn how to program the NES. This is hardly "stealing information" in my vocabulary, but rather a honorable effort often not appreciated enough. And for generously providing the webspace needed to keep this wagon rolling.

But I think leaving was the right choice for him, and reading the linked post proves it further. He seems happier now, and far less bitter and hateful. Maybe he indeed has some points in his criticism of the current state of the nesdev community. But that Jeremy "you're a fucking nigger who just wants to get spoonfed and doesn't deserve our help" Chadwick has now become the spokesperson for people who find the nesdev community unfriendly, is ironic to say the least.

Bananmos
Posts: 468
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos » Mon Oct 17, 2005 2:37 pm

Seems I got logged out while writing the post above. And even if some people could probably figure out who wrote it, it's better to leave the nameguessing aside.

tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Oct 17, 2005 5:00 pm

If I had the time, I'd probably help out with a tutorial from the perspective of an NES software programmer. Would this chapter outline make sense?
  • 6502 tutorial
  • NES Basics (covers iNES format, tones on channel 1, and controller reading)
  • NES PPU Basics (palette, pattern tables, nametables)
  • Basic Mappers (CNROM, UNROM)
I'd recommend teaching the basics of 6502 assembly language on a slightly less forbidding environment before graduating into making ROMs for Nintendulator*. Should we use a C=64 emulator, an Apple II emulator, or head straight to Nintendulator?

* Nesticle sucks. Nintendulator sucks much less.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Post by Celius » Mon Oct 17, 2005 8:39 pm

I'd change this:

*Nesticle sucks. Nintendulator sucks much less.

to

*Nesticle SUCKS. Nintendulator does not suck. At all. 99.8% accurate. As apposed to Nesticle, which is 4.5% accurate.

And yes, your chapter outline makes much sense. And I would like to help out with writing a document for begginers, but I'm afraid the information I supply would be horribly inaccurate. And I don't know crap about NES hardware. I think a document like NES hardware for begginers would be very helpful. And perhaps a document on making a cart. I think that would be very useful to newbies. Those would be really useful, because there is no such thing at the moment, and people have to learn all this crap from scratch and the people that know this have to get annoyed answering questions left and right, so I think there should be a document on this kind of stuff. I would even find it useful, because I really don't know much about Flashroms/EPROMS/EEPROMS and I really don't understand the concept of adapters, what the heck are they even for? and how the heck to you know if you need one? If this was explained in a document, that would be so helpful to the NESdev world.

Hyde
Posts: 101
Joined: Mon Sep 27, 2004 11:51 pm

Post by Hyde » Mon Oct 17, 2005 11:20 pm

Celius wrote: *Nesticle SUCKS. Nintendulator does not suck. At all. 99.8% accurate. As apposed to Nesticle, which is 4.5% accurate.
Now how did you get those figures?

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Tue Oct 18, 2005 2:09 am

tepples wrote:
  • 6502 tutorial
  • NES Basics (covers iNES format, tones on channel 1, and controller reading)
  • NES PPU Basics (palette, pattern tables, nametables)
  • Basic Mappers (CNROM, UNROM)
maybe exchange iNES with UNIF or add it to NES Basic?
Sorry for misspellings, I'm from Sweden ^^

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Tue Oct 18, 2005 5:39 am

tepples wrote: I'd recommend teaching the basics of 6502 assembly language on a slightly less forbidding environment before graduating into making ROMs for Nintendulator*. Should we use a C=64 emulator, an Apple II emulator, or head straight to Nintendulator?
For learning 6502 assembly I would strongly recommend Michal Kowalski's 6502 simulator (http://home.pacbell.net/michal_k/6502.html). I think it is good becouse you can abstract from ANY hardware details and focus entirely on the logic. Also, it requires no setup whatsoever, just type and run.

However there is one aspect wich I'm not sure if it is good or bad. The simulator has tons of debugging features, meaning you can see exactly what your code does/did, but there is no actual graphic response to the code, wich people might find boring. Well, you can map memory to a text display... text isnt much fun, but it is better than nothing.

I really think we should abstract from machine-specific details at first, as people who have never had contact with low level programming (or with programming at all) may get both things mixed up. I know I mixed things up a little when I was first learning to program the NES.

We must make it very clear for beginners: the 6502 is a CPU, it works like this and that, and it happens to be used to control the hardware on the NES, but any other processor could have been used.

Post Reply