Wiki content (almost) tranfered

Wiki content (almost) tranfered
by Banshaku on 2009-06-12 (#47919)

I just finished to "cut/paste" (I learned about the export option at almost 70% done.. Doh!) all the reference of the previous wiki, ines mapper id info and general programming sample not included.

The link is here: http://wiki.nesdev.com

I want your comment on the new layout since I changed the way things are organized a little bit. I hope to change the content more once I can figure out a proper layout to make it more user friendly.

Now I'm exhausted after moving the section around so I will go sleep. zzz...

by Bregalad on 2009-06-12 (#47920)

This is good work thanks for doing that !

by MetalSlime on 2009-06-12 (#47922)

awesome! once you finish, is the plan to just let everyone have free reign and write anything NESdev related they can think of on there?

by Hangin10 on 2009-06-12 (#47924)

There should be some standards so that information can be easily understood. I'm not sure if I used the correct word "standards", but what I mean is, for example:

- are we talking NTSC or PAL?
- if a specific scanline is mentioned, is that with vblank thought of as before or after the visible frame?

something else: would it be worthwhile to reformat some of the text files on the nesdev main page into the wiki? Not necessarily things like marat's doc, but Brad Taylor's CPU/PPU documents. The cpu page currently (or at least the last time I looked) just had a link to an opcode matrix and a pinout. To make a long story short (too late?), moving some of the longer plain text stuff to a web format (wiki) would be better especially so one doesn't need to find the right encoding or font to see charts and stuff.

by tepples on 2009-06-12 (#47933)

Hangin10 wrote:
- are we talking NTSC or PAL?

NTSC unless otherwise specified. Here's my reasoning: The Famicom was always NTSC, and the RGB systems (Vs. Unisystem and PlayChoice) used NTSC timing. And in Europe home computers (C64, Spectrum, Amiga, ST) stole a lot of the market share that would have otherwise gone to the NES.

Quote:
- if a specific scanline is mentioned, is that with vblank thought of as before or after the visible frame?

Pre-render is "line -1", and post-render is "line 240".

by Banshaku on 2009-06-12 (#47942)

Bregalad wrote:
This is good work thanks for doing that !

You're welcome. It was hell but someone had to do it Most links are working. Some need to be fixed because some article name changed. I will try to fix as soon as I can.

MetalSlime wrote:
awesome! once you finish, is the plan to just let everyone have free reign and write anything NESdev related they can think of on there?

It is technically finished, we can start to add content anytime. As long as it's nesdev related, I don't see any issue. Any information is good information, if people don't agree they will update it or comment about it. We just have to make sure that the new content is organized when possible. If is a code sample, it should be in the getting started section (which I need to start building an example of the structure inside).

The next step is to improve the current content. That will take more time but I will try.

Hangin10 wrote:
There should be some standards so that information can be easily understood.

I totally agree. This is one point to make the wiki more user friendly and not just for the "ones that already know".

So what we have to do is to define the assumption for the user. For example, in the main page we could say that the content refer to NTSC machine unless otherwise noted. All assumption should be documented.

Hangin10 wrote:
something else: would it be worthwhile to reformat some of the text files on the nesdev main page into the wiki?

Yes, I was thinking about that already. I hate the fact that I cannot search when many of the content is in outside links. What doesn't exit in the wiki that has value and , the most important point, is still accurate (since many docs are maybe not) must be inserted in the wiki. Then, a link to the original content could be inserted at the end of the page to say that is refer to this doc. If it just a snippet like a diagram for a chip, it may not be required.

Hangin10 wrote:
To make a long story short (too late?), moving some of the longer plain text stuff to a web format (wiki) would be better especially so one doesn't need to find the right encoding or font to see charts and stuff.

I didn't think about the encoding, that's a valid point. Yes we can do that.

tepples wrote:
Here's my reasoning: The Famicom was always NTSC, and the RGB systems (Vs. Unisystem and PlayChoice) used NTSC timing. And in Europe home computers (C64, Spectrum, Amiga, ST) stole a lot of the market share that would have otherwise gone to the NES.

I see your point but not everyone know. Some people come to nes dev and doesn't have that background. By clarifying the assumption at the beginning, which is only a few line of text or a specific section that can explain all assumption if there is too many or explained at page directly, you already make the learning curve less steep and make it more user friendly. It the kind of small details that your user will always appreciate.

by frantik on 2009-06-12 (#47945)

nice job

by Banshaku on 2009-06-12 (#47946)

For the remaining content, I decided to import it since I don't know yet how to organize it (tutorial in general).

So the wiki transfer is done. Only thing left is a logo. From the current structure I started, people can start giving their opinion about what they like (or don't) about it.

I did one small "doh" when I was tired yesterday. For some reason, I removed the category for a few articles (mailly mappers) because I didn't like the fact that mappers and board were mixed together (they're not the same thing). But now I realize that if I end up from a search engine on a specific mapper page, I don't know how to go back to the main category. I will try to find a way to fix that. Either the word mapper will be highlighted and you can go back to the mapper page or adding some category for specific group only. But not all page were organized that way so actually I found one issue that affect many pages (i.e. how to go back to the main topic, if any).

But still, those are minor details and can be corrected soon.

Welcome to the new home of the nesdev wiki. If you have any issue with the wiki, there are 3 admins: Tepples, Memblers and me. This way, if for some reason something goes wrong with it and I'm not available, other admin can proceed forward.

by koitsu on 2009-06-12 (#47947)

Banshaku wrote:
Welcome to the new home of the nesdev wiki. If you have any issue with the wiki, there are 3 admins: Tepples, Memblers and me. This way, if for some reason something goes wrong with it and I'm not available, other admin can proceed forward.

...and folks can always nag me if they have other problems that are more pressing or server-related.

by Banshaku on 2009-06-13 (#47948)

First, I made a quick logo based on the nesdev one, to keep the site identity. Then I fixed a few of the category that I removed.

Now here something new that I wanted for a long time: a local html copy of the site is available here. For now, this is an experimental dump since the extension doesn't work 100%.. I had to fix the layout by end but it seems to work. Some people may be annoyed that I compressed it in 7z but if I did with zip file.. Instead of 200k it was 1 meg!..

Page without links will be missing since you don't have access to the specials pages. Once we put all the article together, we could do a dump once in a while, unless nobody is interested but I would be surprised.

If everyone could test the local copy and found what is wrong, tell me what they like or not, I would really appreciate it.

by MetalSlime on 2009-06-13 (#47951)

local copy seems to work fine for me. The top and side menus don't work, but I don't think they are supposed to.

by Banshaku on 2009-06-13 (#47956)

MetalSlime wrote:
local copy seems to work fine for me. The top and side menus don't work, but I don't think they are supposed to.

Yes, this is correct, they will not work because either they don't have content or refer to a special section of the wiki. Does it seems useful in it current state?

Now the next step it to check which document from nesdev that is not on the wiki.

by MetalSlime on 2009-06-13 (#47957)

Banshaku wrote:
MetalSlime wrote:
local copy seems to work fine for me. The top and side menus don't work, but I don't think they are supposed to.

Yes, this is correct, they will not work because either they don't have content or refer to a special section of the wiki. Does it seems useful in it current state?

Now the next step it to check which document from nesdev that is not on the wiki.

Yes, I think it's really useful personally, though of course it will be better once the rest of the articles are organized and accessible.

I actually do most NES programming when I have free time at work, which is a place where I am not connected to the internet. So an offline version of the wiki is actually pretty sweet for me personally. I've been carrying around a lot of printouts stapled together, which makes my backpack heavier than it needs to be. I can probably retire the papers now

by miau on 2009-06-13 (#47961)

MetalSlime wrote:
I've been carrying around a lot of printouts stapled together, which makes my backpack heavier than it needs to be. I can probably retire the papers now

hmm, that reminds me...
Has anyone ever had the idea of creating a "quick reference card" for the NES (like there is for unix commands, apache and a lot more stuff, even GB programming) that fits on a single (or just a few) sheets of paper? Always liked them. They make nice posters, too.

More on-topic:
Maybe it would be helpful to have a database of commercial and homebrew nes games in the wiki? E.g. each entry could have:
- general information on the right side like company, release date, - mapper used, prg and chr size and possibly more
- info for emulator developers: emulator requirements, things to pay attention to
- put a link to the corresponding entry at http://datacrystal.org somewhere for ram/rom locations and a list of hacks

Likely not enough points to warrant an article for each game, but maybe a single page for difficult-to-emulate games?
I just like having easily accessible in-depth info about games around. From a nesdev point of view that doesn't seem to make much sense, though, except for emulator developers.

Well, it's just an idea.

by Banshaku on 2009-06-13 (#47971)

MetalSlime wrote:
Yes, I think it's really useful personally, though of course it will be better once the rest of the articles are organized and accessible.

I actually do most NES programming when I have free time at work, which is a place where I am not connected to the internet. So an offline version of the wiki is actually pretty sweet for me personally. I've been carrying around a lot of printouts stapled together, which makes my backpack heavier than it needs to be. I can probably retire the papers now

Yes, still some work to do for the articles. Maybe the not organized one yet will just be set temporary in the getting started section until they can be put at the right place.

The idea of a local version came to me because of 2 factors. Recently, the wiki was down randomly so it was annoying to not have access to the content when you really wanted it. That fix the first issue. The second one is I remember Tepples saying that he was programming while commuting (i.e. no internet access) so in that case, a local version is quite useful.

With a local version, "printer friendly" sections are less useful but we can still make them for people that prefer paper. Before you get rid of your paper version, make sure that all the content you need is there.

Now we need to go through the content of nesdev files and add everything that is missing and is useful.

miau wrote:
hmm, that reminds me...
Has anyone ever had the idea of creating a "quick reference card" for the NES (like there is for unix commands, apache and a lot more stuff, even GB programming) that fits on a single (or just a few) sheets of paper? Always liked them. They make nice posters, too.

This could be an idea and it could be put on the wiki too.

miau wrote:
More on-topic:
Maybe it would be helpful to have a database of commercial and homebrew nes games in the wiki? E.g. each entry could have:
- general information on the right side like company, release date, - mapper used, prg and chr size and possibly more
- info for emulator developers: emulator requirements, things to pay attention to
- put a link to the corresponding entry at http://datacrystal.org somewhere for ram/rom locations and a list of hacks
Likely not enough points to warrant an article for each game, but maybe a single page for difficult-to-emulate games?
I just like having easily accessible in-depth info about games around. From a nesdev point of view that doesn't seem to make much sense, though, except for emulator developers.

Well, it's just an idea.

I consider emu authors also nesdev developers since they contribute emulators that will help for making new software so they should not be excluded.

Any information about software made is ok too. It's not like we have any space restriction or something The only problem is always "who" will fill that information. Nothing was going forward about the wiki (i.e. the waiting game) so I took the time and moved everything. Now I need people to contribute if we want the idea to fly. It should not be a one man army thing.

Regarding a list of commercial games with their specification, yes this is an idea because I wanted to find some details about X game and the bootgod database was down (now it just went back up). I would be useful a simple list of game N uses mapper X, board type X, has Y ammount of rom etc, anything that can be useful. We could always get the list from the bootgod db then format it for the wiki. At the least it would be useful when the bootgod db is down.

by miau on 2009-06-14 (#47986)

Banshaku wrote:
Regarding a list of commercial games with their specification, yes this is an idea because I wanted to find some details about X game and the bootgod database was down (now it just went back up). I would be useful a simple list of game N uses mapper X, board type X, has Y ammount of rom etc, anything that can be useful. We could always get the list from the bootgod db then format it for the wiki. At the least it would be useful when the bootgod db is down.

Oh yeah, almost forgot about bootgod's db. That's one more site to put links to.

I forgot to mention that apart from being useful for emu authors it might be useful for homebrew programmers, too, if questions like "how does game X pull off effect Y?" are covered. You can still learn from the old masters.

I know there are people around with a huge amount of knowledge about specific games. Knowledge which currently, if shared at all, seems to be scattered throughout many different places.

by MetalSlime on 2009-06-19 (#48104)

I think there should be a "programming" section on the main page, and "getting started" should be underneath it.

by Banshaku on 2009-06-19 (#48125)

MetalSlime wrote:
I think there should be a "programming" section on the main page, and "getting started" should be underneath it.

I know what you mean and I though about something similar before but there is one issue. If we do this, this mean where do you put the info for rom hacker that may not technically program in some case, hardware guys and other possibles case like this?

This is way I reverted to "getting started" where you could put all the sections inside like "looking for tools , go here, programming tutorial? here, want to make a dev cart? here" etc.

But if all a sudden we receive an influx of programming tutorial only then I guess this section will become the programming section and we should switch the name.

I'm in the group of programmers myself and I don't mind that the section is called programming but I'm just trying to not forget everybody else

by MetalSlime on 2009-06-20 (#48132)

Banshaku wrote:
MetalSlime wrote:
I think there should be a "programming" section on the main page, and "getting started" should be underneath it.

I know what you mean and I though about something similar before but there is one issue. If we do this, this mean where do you put the info for rom hacker that may not technically program in some case, hardware guys and other possibles case like this?

This is way I reverted to "getting started" where you could put all the sections inside like "looking for tools , go here, programming tutorial? here, want to make a dev cart? here" etc.

But if all a sudden we receive an influx of programming tutorial only then I guess this section will become the programming section and we should switch the name.

I'm in the group of programmers myself and I don't mind that the section is called programming but I'm just trying to not forget everybody else

I plan on writing a bunch of articles with example code to tackle specific topics, so that influx might be coming

I think programming articles should be separated from hardware/reference articles. I envision a main "Programming" section, and then under it have different sections like "Compression", "Mappers", "Sound", "Graphics", "AI", etc. Then those sections would have individual articles under them.

For example under "compression" you'd have a bunch of articles: "programming RLE", "programming Fixed Bit Length Encoding", "programming Huffman", etc. Then, if someone is writing their game and they think "hmm.. I wonder how I should go about compressing the text in my game", they can head to the programming->compression section and read through the articles there. They will get a good idea of how many compression algorithms work, and they will get to see some example code so they have an idea of how they can get it up and running.

I just wrote up an article on programming UNROM. This is the kind of article that I want to see under the programming section. It has just what the programmer needs to implement the idea and nothing extra. It is separate from the UxROM reference article (though it DOES link to it at the end) and I think it should stay that way. Right now, the path to this article is Getting Started -> Programming -> Programming Mappers -> Programming UNROM. My hope is that the "Programming Mappers" section will one day be full of articles teaching you how to use each of the different mappers.

I'm going to continue writing little articles like this and organizing them under the Programming page. They aren't really going to be tutorials, but rather example solutions for specific, targeted problems.

by Banshaku on 2009-06-20 (#48133)

MetalSlime wrote:
I plan on writing a bunch of articles with example code to tackle specific topics, so that influx might be coming

Great to hear! I already read your article and this is simple and useful. There is only one issue but not specific to your article. Right now the article was made with some code sample in ca65. Everyone as it's own taste of assembler they like. How to make everyone happy in that situation... I would like to find a way to be able to show the article with different syntax but how. hmm... For example, when you use MSDN, you can select for which language to see the sample by checking some checkbox at the top. I don't know if we can find a way to make something similar or if there is a plug-in for the wiki for this. Another possibility is that we do all the sample for 1 assembler only for uniformity but hmm..

MetalSlime wrote:
I think programming articles should be separated from hardware/reference articles.

Yes, this is correct. It should explain the hardware only and not show example. Right now the reference section is a little bit messy about that. The programming section can go in more detail for a specific option.

MetalSlime wrote:
I envision a main "Programming" section, and then under it have different sections like "Compression", "Mappers", "Sound", "Graphics", "AI", etc. Then those sections would have individual articles under them.

I have the same idea too. And some section that explain which assembler exist, tool for map etc. There is not enough information about that. I was searching recently for a tool that can import some bmp but there was no information about that in one place, which one is better for what reason etc. You often end up making your own tool when there could be already one available!

MetalSlime wrote:
For example under "compression" you'd have a bunch of articles: "programming RLE", "programming Fixed Bit Length Encoding", "programming Huffman", etc. Then, if someone is writing their game and they think "hmm.. I wonder how I should go about compressing the text in my game", they can head to the programming->compression section and read through the articles there. They will get a good idea of how many compression algorithms work, and they will get to see some example code so they have an idea of how they can get it up and running.

Yes, this is what the getting started(or) programming section is for, explaining about common problems that you have to solve while programming for the nes. There is many common one like:

- compression
- Using mapper for more data
- How to organize data (interleaved, column based, screen based compressed etc)
- How to scroll an infinite map
- How to scroll with less artifact
- How to split the screen for a status bar
- How to do parallax scrolling with the scroll register
- How to keep state
- Frame based algorithm
- Trick of the trade from well known commercial games
- Graphic editing (map, tile etc)
- Music, how to make, to play, sound fx
- NMI, best practices (Dish already started a good document about this)
- etc etc

MetalSlime wrote:
My hope is that the "Programming Mappers" section will one day be full of articles teaching you how to use each of the different mappers.

Yes. Once you understand a specific "breed" mapper, often many a related so we could group many type of mapper together too.

MetalSlime wrote:
I'm going to continue writing little articles like this and organizing them under the Programming page. They aren't really going to be tutorials, but rather example solutions for specific, targeted problems.

It doesn't have to be a tutorial. Any information is a reference that will help other people to understand more. This is already great that you're contributing this information. If more people do the same, we could end up with quite a nice wiki compare to the other platform. That would be great. Keep up the good work

I may change the name of the section already. How many object to this? (wind.... no sound is heard at all). That's almost rhetorical since recently nobody really seems to object to the current direction that it's going. Either people all agree silently or they just don't care as long there is content

by tokumaru on 2009-06-20 (#48141)

So, is the new wiki the official one already? Will the links to the old wiki be updated?

by Banshaku on 2009-06-20 (#48146)

tokumaru wrote:
So, is the new wiki the official one already? Will the links to the old wiki be updated?

I guess the answer should be yes since there is no official jurisdiction on who decide what is the official wiki.

The first goal was to improve the availability of the wiki because of the recent down time. This phase is done. Now we need to put content in it and announce is as the new home for the wiki.

by MetalSlime on 2009-06-22 (#48184)

Banshaku wrote:
There is only one issue but not specific to your article. Right now the article was made with some code sample in ca65. Everyone as it's own taste of assembler they like. How to make everyone happy in that situation... I would like to find a way to be able to show the article with different syntax but how.
...
Another possibility is that we do all the sample for 1 assembler only for uniformity but hmm..

Yes, this is an issue. It might be enough to accompany each code example with a note in parenthesis, like:

(Note: this code was written for the _____ assembler. Some minor changes may be needed to get it running with other assemblers)

Quote:
It doesn't have to be a tutorial. Any information is a reference that will help other people to understand more. This is already great that you're contributing this information. If more people do the same, we could end up with quite a nice wiki compare to the other platform. That would be great. Keep up the good work

Thanks. Here's the one I posted up today: Fixed Bit Length Encoding

Quote:
I may change the name of the section already. How many object to this? (wind.... no sound is heard at all). That's almost rhetorical since recently nobody really seems to object to the current direction that it's going. Either people all agree silently or they just don't care as long there is content

Speaking of changing the name of the section, you might want to make a new page for it too. Right now "Programming Guide" still links to the url called "Getting Started". I think we should just copy the content of "Getting Started" and paste it on a new page called "Programming Guide" and update the link.

Later we can have a "Getting Started" category under the Programming Guide that will be targetted at new nesdevers, telling them what they need to know to get up and running.

by Banshaku on 2009-06-22 (#48185)

For the disclaimer, this is an idea. We could make a template for this.

MetalSlime wrote:
Here's the one I posted up today: Fixed Bit Length Encoding

Great, another contribution Now I need to see how to put more order in the current content and check how to contribute myself.

Regarding the name of the section, I just updated the main page for now and will move the content soon.

by cpow on 2009-06-22 (#48186)

Banshaku wrote:
For the disclaimer, this is an idea. We could make a template for this.

MetalSlime wrote:
Here's the one I posted up today: Fixed Bit Length Encoding

Great, another contribution Now I need to see how to put more order in the current content and check how to contribute myself.

Regarding the name of the section, I just updated the main page for now and will move the content soon.

Very nice article! It is that kind of writing that will help game developers and tool developers also. I've been wondering about what types of compression to offer support for.

by MetalSlime on 2009-06-24 (#48215)

Banshaku wrote:
Great, another contribution Now I need to see how to put more order in the current content and check how to contribute myself.

NESICIDE wrote:
Very nice article! It is that kind of writing that will help game developers and tool developers also. I've been wondering about what types of compression to offer support for.

Thanks. Writing articles is pretty fun. I did another one today. It's under a "Programming Tricks" section: RTS Trick

Also I posted up a Programming UOROM article, though it's pretty much just a copy/paste of the Programming UNROM article with a few details changed.

by Banshaku on 2009-06-25 (#48264)

MetalSlime wrote:
Thanks. Writing articles is pretty fun. I did another one today. It's under a "Programming Tricks" section: RTS Trick

You're on fire these days This article might come in handy on a project I'm working on right now. I get the basic idea, just need the time to read it properly (I did an overview only and it was interesting already).

Thumbs up