Making PPU docs easier to understand (also nestech)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: Making PPU docs easier to understand (also nestech)

Post by tepples »

rainwarrior wrote:nestech.txt is a good example. This could easily be a wiki article. It could be updated with the needed corrections, and it could be integrated with links to reference.
And I've started to do just that. Behold: new and improved nestech.txt. Feel free to let me know if I cluttered it up while porting it and patching the out-of-date info.
rainwarrior wrote:Fundamentally though, if you see something you don't like on the wiki. Point it out, or fix it.
Perhaps part of the barrier is that registration is broken.
rainwarrior wrote:Tepples writing an article on what's wrong with nestech.txt hurts the utility of that document by poisoning the well for people that might actually have gotten something good from it. koitsu proclaiming the wiki to be trash forever does the same for the wiki. I think both would be better of if they were capable of leaning on each other rather than being posed in needless opposition.
I'm not in opposition. Once I knew koitsu was open to maintenance of this quick overview of the hardware, I maintained it.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Making PPU docs easier to understand (also nestech)

Post by rainwarrior »

tepples wrote:I'm not in opposition. Once I knew koitsu was open to maintenance of this quick overview of the hardware, I maintained it.
I was referring to the effect rather than intent here. I believe most people would have primarily interpreted that article as a caution not to read nestech.txt.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Making PPU docs easier to understand (also nestech)

Post by gauauu »

rainwarrior wrote:We need reference material just as much as we need teaching material. They complement each other, and are not substitutes for each other. So, we can take a complaint like "the MMC3 page is hard to understand", but we always have to keep in mind who is this information for, why do they need it, what do they need it for. What do they already know?
This is the most important point here, I think. As a relative newcomer to nesdev, I've used the wiki and nestech and Martin Korth's everyNES document for reference, and found each helpful in different ways. But none of those three are particularly aimed at teaching, or useful for a newbie tutorial. And that's ok. But instead of arguing about "which one is better for teaching?" it would be more helpful to come from a different angle and ask "what documents exist that are good for teaching, and how can we organize/improve them? And how can we make the existing reference material better as reference material?"

If the goal is introductory material, something like Nerdy Nights or Cearn's GBA TONC tutorials are great examples. Of course, tutorials like those take tons of work. But you're not going to replicate the teaching style of those by tweaking reference material.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Making PPU docs easier to understand (also nestech)

Post by tepples »

I agree: each teaching style has its own merits. The value of nestech.txt, and why I prepared a version on the wiki that incorporates newer information and practices, is that it provides a overview of the platform's most commonly used functionality.

It might also be advisable to produce hardware docs in a form more familiar to readers of IC datasheets, such as a PPU doc resembling the TMS9918 family datasheet, or an APU doc resembling the SN76489 datasheet.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Making PPU docs easier to understand (also nestech)

Post by koitsu »

I'll try to cover several aspects of replies and what not here:

Folks should take my subjective/opinions with a grain of salt, i.e. they are worth as much as anyone elses. Do not consider my opinions somehow superior.

I agree that teaching material and reference material complement each other.

I do not want to see all the reference material turned into "docs for laymen" -- I actually thought I put this in my initial reply, but I didn't, it was in my 1st and 2nd write-ups which as stated I omitted for brevity.

I do not think the Wiki needs some kind of "massive revamp". Even if I did, it's not feasible to do anyway.

Sadly, this also proves my point about Wiki documentation in general -- in that the "bulk" of the initial work ends up rarely ever getting reorganised. In my experience this is true of almost every technical Wiki I've ever seen (subjective but true). In other words: unless it's well thought out from the beginning, it kinda never gets reorganised (again, subjective).

I do not think the Wiki is a lost cause, I just think the amount of effort to organise it now outweighs the original effort that was put in to create the content in the first place.

The nestech.txt errata page has never bothered me -- if that is indeed the concern (re: "hurts the utility of that document by poisoning the well for people that might actually have gotten something good from it"). I think there may be concerns that I'd feel it was "a jab at me". I've always felt neutral-positive about it; that is to say, I think pointing out the mistakes is just as OK as fixing them. The latter is what I hoped the public would do when I made the document public domain with its final 2.00 release in 1999, but it never happened. If it happens now, great. If not, that's also OK.

Below is part of my 2nd attempt when originally posting in this thread, which should provide examples and my line of thought.

======
Do I have examples? Sure. Am I reluctant to post them? Yes, and I'll explain why at the end.

Look at anything on the "Programming guide" page. Note section "Getting started". Check out "Programming Basics". Why does this page exist? Seriously, look at the content. You don't try to teach someone about the 6502 CPU, then literally throw them subroutines of multiplication and division, followed by a "hello world" that references things that almost certainly won't mean anything to someone just learning 6502. There's even a brief set of code saying how to make a beep or continual tone -- except the user at this point has no idea about APU MMIO regs, and PROBABLY not even about audio at all: "period low? period high? I'm not on my period!" "Square? Yeah I've been called that before!" This page should be deleted and the subroutines stuck under "6502 code tricks/tips" or some other page, and the APU beep/tone trick placed somewhere else (keep reading).

So what do we have for basics? Well, there's a page called "CPU basics" under section "Tutorials". Sounds promising! Wait... this isn't a tutorial at all. It's absolute 100% reference material about the NES CPU on both a very low level (literal hardware) to a general level. Tutorial... right.

Still under "Tutorials":, we have "PPU reference" as the 2nd item. Reference != tutorial. Then "APU basics", 3rd on the list. NES audio is literally an advanced topic in every way/shape/form. This is subsequently followed by items like: CPU-level compression routines, mappers, then 6502 code tricks/tips, Limitations (I'll cover this in a moment), and then... Emulation Tutorials (I'll cover this in a moment too).

Also note the intermixing of terms here: "Tutorials" is the section, yet several of these things are references. Do people understand the difference between reference material and tutorials? rainwarrior and I seem to understand the difference, but hmm, maybe the fact others don't says something about "how" people read some technical documentation. Could that be the case? Ahem. Let's refocus:

So what should come after teaching 6502? Probably an item giving examples of "how" to do things on the NES, along with the realities of working on it, with some common techniques of things people might want to do. Math seems like a good idea, but still a bit advanced (IMO). Examples of realities to learn/understand first when developing on the NES: there is no printf() equivalent, so debugging is best left done in emulators for step-by-step code analysis. Accept the limitations of the machine, talk about what those are. Describe how to get something up visually on the screen which can be used as a printf() style debugging -- which leads me back to that APU beep subroutine. And that "Limitations" page.

About that page... check it out. Paraphrased, this is it: "the NES has some limits. Here's a list of game genres and technical complexities you'll run into in each one. Oh, and while I'm here, here's a section on Music". All of that -- huh?!?! We should be able to tell from the style, content, organisation, etc. who made this page. I see some people have edited it, but it was basically written in 2009 (see above: bulk gets written, rarely reorganised). Okay, so the content here is good and relevant *for that subject matter* -- why is the page called "Limitations"? Nebulous and inaccurate. "Game design limitations" is better... except for that Music section, which is what defeats my entire argument about the name of the page. (Right now IRL I've got both my fists in the air yelling "TEPPLES!!!", haha. :-) )

The above paragraph and page/example should, I hope, make my point about organisation, editing, etc. really clear. This is what I mean when I talk about pages being filled with "stuff" that are just like "?!" and aren't really classified or organised properly, especially when considering where that page is placed (Tutorials -> Limitations).

Okay, maybe I'm just being a crotchety old man, a pedant. More examples are required, right?

So let's switch to graphics for a moment, because that's a big part of what drives people to the NES these days.

The "PPU nametables" document literally describes nametables in 3 lines, combined with an ASCII diagram that has X,Y coordinates and lacks a legend (why are there X,Y coordinates anyway? To denote pixels? This is confusing because there isn't >256 or >240 offsets on the NES). Then suddenly, there's a "Background evaluation" section within that same page -- why? That has to do with PPU rendering, which has its own document/page.

The "PPU rendering" page is extremely helpful, but the presentation of information (all the way down to the ASCII diagram) is very confusing. It's like a wizard's tome. "This will make sense to you if you are familiar with it, else enjoy pulling your hair out." What's funny about this page is that at the bottom, there's the "PPU frame timing" image/SVG (very helpful), but also a link to a *separate* document called "PPU frame timing" that doesn't even have said image/SVG in it.

Then we have the "PPU pattern tables" page, which is tolerable... but maybe not, because it's one of the things the user in the thread that prompted *this* one had trouble understanding (pattern vs. name). The ASCII diagram shown is a modified rip-off of the one I did in nestech, and has a very bizarre layout that only makes sense if you understand what it's referencing. For example, it labels the strings $0xx0=$41 01000001 as "Bit planes". What?! No. $0xx0 is the PPU RAM location -- with a preceding 0 for pattern table 0, except that isn't even explained (or relevant!) to comprehending the data format -- followed by the hexdecimal value of the actual byte in RAM, followed by the binary rendition of that (omitting the % that makes it obvious). It then ties all these together to represent the colour values of 0-3 (with . (0) meaning transparent (this is good!), just like nestech), through equals signs at the bottom and top of the subsequent PPU RAM bytes that make up a tile that the user can't even comprehend the shape of (what is that tile anyway? It looks almost like a botched swastika) -- why was this shape chosen rather than something almost everyone would recognise? Compare that page to nestech please, verbatim (in the late 90s we tended to use the term "VRAM" to refer to PPU RAM):

Code: Select all

  D. Pattern Tables
  -----------------
    The Pattern Table contains the actual 8x8 tiles which the Name Table
    refers to. It also holds the lower two (2) bits of the 4-bit colour
    matrix needed to access all 16 colours of the NES palette. Example:

       VRAM    Contents of                     Colour 
       Addr   Pattern Table                    Result
      ------ ---------------                  --------
      $0000: %00010000 = $10 --+              ...1.... Periods are used to
        ..   %00000000 = $00   |              ..2.2... represent colour 0.
        ..   %01000100 = $44   |              .3...3.. Numbers represent
        ..   %00000000 = $00   +-- Bit 0      2.....2. the actual palette
        ..   %11111110 = $FE   |              1111111. colour #.
        ..   %00000000 = $00   |              2.....2.
        ..   %10000010 = $82   |              3.....3.
      $0007: %00000000 = $00 --+              ........

      $0008: %00000000 = $00 --+
        ..   %00101000 = $28   |
        ..   %01000100 = $44   |
        ..   %10000010 = $82   +-- Bit 1
        ..   %00000000 = $00   |
        ..   %10000010 = $82   |
        ..   %10000010 = $82   |
      $000F: %00000000 = $00 --+

    The result of the above Pattern Table is the character 'A', as shown
    in the "Colour Result" section in the upper right.
The "PPU attribute table" page almost immediately throws the user a line of code -- helpful for emulator authors, not helpful for newbies, but also not useful as "reference material" either. The large ASCII depiction at the top (which I am known for doing a lot of myself, just not in that style -- when drawing ASCII boxes it's best to not use extraneous whitespace in ASCII boxes if possible), is almost in contrast to the subsequent images in the "Worked example" section. So here we have ASCII vs. imagery. Furthermore, the imagery in "Worked example" is actually misleading: here we have an actual nametable shown/drawn in its entirety, except using PPU RAM offsets of the attribute table. It's trying to describe, on-screen, what the attribute table is affecting -- this is in no way/shape/form obvious from the pictures. The ONLY PLACE that makes it clear is the TINY TEXT BELOW THE IMAGES. *sigh*

I will say though, one of the best PPU-oriented pages we have on the Wiki is the Mirroring page. I also "kinda" like the "PPU scrolling" page, but only select parts of it -- the bulk of it is insanely complicated and badly organised (use of separate linkable sections makes this page ugly and hard to follow). It's the more clear version of loopy's skinny.txt, i.e. it's better, except it's still not really clear (and it still remains unclear to most people, I think. It did then too, but it's critical to how the NES PPU works).

With regards to that page though, what's *really* needed for homebrewers in particular, is a "this is what you need to do" page/thing. Best practises and why. A big one would be the whole 2000/2005/2006 situation and why zeroing 2005/2006 at the end of NMI can alleviate graphical oddities (I'm speaking of the general-use case here, not complex situations).

Back to earlier stuff: how about that emulation-oriented page, "Emulation Tutorials?"

The page itself is actually sparse of information, because all it does is contain references to *other* pages (remember what I said about organisation of information being in one place?). It's an important page, but it has no substance. It's like a middle manager. I REALLY expected to see it reference something I have posted time and time again: that adc/sbc is the #1 badly-emulated instruction pair on the 6502 because folks don't understand two's complement (this wasn't taught in any CS class I took either). Understanding the overflow flag is actually hard, but important, given bvc/bvs. There's no other truly useful emulator-focused information on this page. Maybe we should reference real-world situations people are encountering (see: forum).

Can I fix that up? Absolutely. Will I? Probably, when I feel like doing so (maybe this weekend). We currently have 146 known NES emulators in development, so it seems like we could relieve some of the repeated forum posts here by having better Wiki content. We get a lot more emulation-oriented posts than I think people realise (vs. general chit-chat about a subject, or vs. homebrew discussions). Banshaku's recent posts asking good questions are great because they get back to the roots of the forum, I think.

As for why I was reluctant to post examples:

Because the immediate rebuttal is always "in the time you wrote up these diatribe replies on nesdev forum criticising the Wiki, you could have simply improved the Wiki" -- which makes me want to reply with an expletive. These are key/critical pages, and my experience with Wiki editing historically has shown that when "revamping" something, people suddenly come out of the woodwork to complain about what you've done, resulting in reverts. In other words: it's actually easier for me to not change any of the pages in risk of upsetting people. I've dealt with this here, as well as on other wikis (Wikipedia, EVE-related wikis, etc.). Nobody wants ripples in the water. So by even saying "this stuff is unorganised" I'm putting ripples in the water -- that nobody wants. Hard to have a discussion about it then, isn't it?

Possibly a better solution for all of this would be to actually have a proper area in the Wiki for starting out (both homebrew, and emulators -- separate sections). You want to know who's pretty good at teaching the "learning the NES" basics? Kasumi (current example thread). I'm not half bad at it myself, but I tend to not hand-hold as much as Kasumi (I'm more of the "if you can't understand the concept that a register holds an 8-bit value, similar to a variable in a programming language, then you should give up" type :-) ).
======

Finally I want to answer one question posed: "Who reads nestech.txt and why?"

What's funny about the question is that it's almost the same question JoeGtake2 asked me when he interviewed me for The New 8-bit Heroes documentary: "why did you write your NES documentation, slash, who was it for?" So in a way I feel like I'm answering this question over and over throughout my life. I've always thought it was obvious, given the style and content, but I'll answer it just like I did for Joe:

It was originally intended for two audiences: 1) emulator authors and 2) homebrewers using emulators (because virtually no one had devcarts then. Yes, much to the surprise of youths, emulators are actually what prompted most of the NES homebrew movement. I only know of 4 people PRIOR to emulation that were doing NES reverse engineering: Alex Krasivsky (Landy), Marat Fayzullin (RST38h), Mark Knibbs, and Kevtris (I think)).

nestech.txt INTENTIONALLY did not go over the 6502 because there are tons of books and resources on those subjects already -- the NES CPU is normal every way barring lack of decimal mode and having an on-die APU. It INTENTIONALLY did not go over mappers because Firebug and others were already doing that (i.e. do not duplicate efforts). It INTENTIONALLY did not go over audio because audio is not a subject I myself understand well (and shortly after, folks like Brad Taylor went over this subject in greater detail, i.e. do not duplicate efforts). Edit: well, I guess it wasn't INTENTIONAL that I didn't go over audio -- you can see in the past (earlier than 2.00) I tried and failed miserably, which was not helpful for others. Quoting my own doc:

Code: Select all

+---------+
| 5. pAPU |
+---------+
   To be written. Prior information was inaccurate or incorrect. No one
   has 100% accurate sound information at this time. This section will
   be completed when someone decides to reverse engineer the pAPU section
   of the NES, and provide me with information (or a reference to infor-
   mation).
But like I said, audio docs came out by Brad Taylor and some others some time after, so I think in the end things got covered. But it's true to this day that audio is a subject I do not grasp well.

It was, in essence, a document allowing someone to learn the aspects of the system to get started either writing games for it, or making an emulator for it -- and being able to comprehend the aspects of the system (esp. the PPU). And, not to brag, but it succeeded. NESticle was done from it (and Icer Addis gave me some info along the way as well) as were a few other emulators. It wasn't until loopy's skinny.txt came along, which revolutionised everything. And here we are today.

If there's one thing I've learned writing technical documentation it's this: if you write documentation for the demographic I earlier called "semi-technical + unfamiliar", then the highly technical (whether familiar or not) will ALSO understand it. If you write documentation for the technically elite, the bar is set too high. Being a good technical writer involves knowing understanding the material yourself and then presenting it in a way that makes sense to the majority of people. It's a balancing act. You CAN write documentation in such a way that works for both... because that's what I've done publicly twice, and at companies as a subset of my job. I dunno what else there is to say about it.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Making PPU docs easier to understand (also nestech)

Post by tepples »

koitsu wrote:I've always felt neutral-positive about it; that is to say, I think pointing out the mistakes is just as OK as fixing them. The latter is what I hoped the public would do when I made the document public domain with its final 2.00 release in 1999, but it never happened. If it happens now, great.
It just did. :wink:
koitsu wrote:And that "Limitations" page.

About that page... check it out. Paraphrased, this is it: "the NES has some limits. Here's a list of game genres and technical complexities you'll run into in each one. Oh, and while I'm here, here's a section on Music". All of that -- huh?!?! We should be able to tell from the style, content, organisation, etc. who made this page. I see some people have edited it, but it was basically written in 2009 (see above: bulk gets written, rarely reorganised). Okay, so the content here is good and relevant *for that subject matter* -- why is the page called "Limitations"? Nebulous and inaccurate. "Game design limitations" is better... except for that Music section, which is what defeats my entire argument about the name of the page. (Right now IRL I've got both my fists in the air yelling "TEPPLES!!!", haha. :-) )
The "Music" part of the page in question was intended to refer to the rhythm game genre, as I tried to imply when I name-dropped Beatmania, Dance Dance Revolution, and Amplitude (the game Harmonix made before Guitar Hero). I'm curious how this could be clarified. Or have rhythm games fallen into obscurity since 2010 or so to the point where they
koitsu wrote:the subsequent PPU RAM bytes that make up a tile that the user can't even comprehend the shape of (what is that tile anyway? It looks almost like a botched swastika)
It was supposed to be a one-half fraction (½), with 1 and 2 drawn in their respective colors and the slash in color 3.
koitsu wrote:my experience with Wiki editing historically has shown that when "revamping" something, people suddenly come out of the woodwork to complain about what you've done, resulting in reverts. In other words: it's actually easier for me to not change any of the pages in risk of upsetting people. I've dealt with this here, as well as on other wikis (Wikipedia, EVE-related wikis, etc.). Nobody wants ripples in the water. So by even saying "this stuff is unorganised" I'm putting ripples in the water -- that nobody wants. Hard to have a discussion about it then, isn't it?
Then perhaps "be bold yet careful", as Wikipedia's guideline puts it. Propose major revamps as a userspace draft, and mention each on Talk: a week before you actually move it into place.
koitsu wrote:nestech.txt INTENTIONALLY did not go over the 6502 because there are tons of books and resources on those subjects already
Is there a web-based 6502 tutorial you'd recommend, other than Easy 6502?
koitsu wrote:You CAN write documentation in such a way that works for both [semi-technical and highly technical]... because that's what I've done publicly twice, and at companies as a subset of my job. I dunno what else there is to say about it.
Other than I wish I'd taken a technical writing elective in college.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Making PPU docs easier to understand (also nestech)

Post by rainwarrior »

koitsu wrote:Can I fix that up? Absolutely. Will I? Probably, when I feel like doing so (maybe this weekend).
Even if you don't, everything you've listed is a useful, actionable complaint that anyone with the energy to do so can consider.
koitsu wrote:As for why I was reluctant to post examples:

Because the immediate rebuttal is always "in the time you wrote up these diatribe replies on nesdev forum criticising the Wiki, you could have simply improved the Wiki" -- which makes me want to reply with an expletive. These are key/critical pages, and my experience with Wiki editing historically has shown that when "revamping" something, people suddenly come out of the woodwork to complain about what you've done, resulting in reverts. In other words: it's actually easier for me to not change any of the pages in risk of upsetting people. I've dealt with this here, as well as on other wikis (Wikipedia, EVE-related wikis, etc.). Nobody wants ripples in the water. So by even saying "this stuff is unorganised" I'm putting ripples in the water -- that nobody wants. Hard to have a discussion about it then, isn't it?
Well, personally I want to thank you for the examples. That's the kind of complaint I thrive on, you're explaining not just what you don't like but why. When you hold back and keep it so vague there are no details, there's nothing to work with, the only effect becomes a vague demeaning of the efforts of people that believe it can be better and are trying to make it so.

As for the inevitable arguments about what happens on wikis, yeah that's part of the wiki process. That's part of open source in general. This is something that's very difficult to manage and a lot of people have different approaches. (Myself I take different approaches in different contexts too.) That's kind of a separate area of people skills, separate from being a good programmer, or a good writer, etc. This is all extra work on top of the writing part, but it's also a necessary part of the collaboration.

Writing a book to self publish. Writing a book with an editor. Writing a book with 20 editors. Even just for the writer this series of tasks has an increasing amount of work involved. Wiki stuff / open source stuff costs more to make than solo stuff. That's a reality of it. So... I don't blame anybody who gets frustrated with this process and leaves it. We're volunteers, and it's open and free. None of us is owed anything here. If you think your time would be better spent writing stuff solo than having this additional burden, that's OK too. That stuff helps us as well. (I'm in the process of writing some tutorial NES stuff of my own, and it's not for the wiki either.)

You can be a good writer but bad at collaborating, and you can be the opposite, or neither or both. Everybody has different skills. I've seen some have ideas about the wiki that they would like to see happen but hold back for their confidence in English. Others might barrel in anyway with poor Englsh. ;)

With the wiki and open source software, incremental changes are always easier than large ones. Often something seems like it needs a big spidery/messy change that is functionally correct to execute but upsets a lot of stuff that people are working on. Just as often there may be a very precise, surgical change that accomplishes the same goal, but probably takes 10x as long to discover. Collaborating with people on wikis often feels the same as this to me. There's a big change I think should happen, but I sit on it a long while trying to think of a smooth way to accomplish it without just deleting big swaths of content people worked hard on. It's slow and painstaking. Something that's easy to give up on... but I have absolutely seen progress. We've definitely made gains here, and I am very hopeful for its future.


As an example, a few years ago zeromus decided to create an article for every single mapper in disch's old mapper doc and paste that document contents in. The initial result was a mess, we had duplicate entries for a lot of mappers, and a lot of disch's work was out of date / incorrect information. On the upside though, we now had entries for a lot of mappers that hadn't been there before. zeromus did not have enough energy to review all this stuff before he added it, and even though it was making a temporary mess, it as a net positive information. (Even the messy out of date stuff wasn't that bad, it just slowed down comprehension to have to check and review the duplicates.) Others cleaned it up slowly. Very slowly. It literally took years, but now all the duplicates are gone and the disch docs have been fully integrated into the wiki. We now have coherent definitions of lots of mappers that were in scattered sources before. At the same time we better organized the mapper page, and more people started contributing to them. It took many, many small changes, by many different people, but look at the mapper article in 2012 and the mapper article now. The reference for this stuff has grown tremendously, and has become very comprehensive.

The tutorial and teaching stuff has not, however. You are right that most users who edit the wiki are people that already know their way around the NES and are looking for good reference, who don't need tutorials and aren't there to organize that stuff. The reference effort has progressed a lot faster and with a lot more quality than tutorial and teaching effort, but it has progressed in that area too, and it will continue. There will always be messes to clean up, but I look at those as a temporary condition on the way to something better in the longer term.

We don't even necessarily need tutorial content directly on the wiki, it is often just as good to link to a good source, but we definitely need to better organize these sources. What we've got know is very much haphazard, though I don't think it's really that far from being much better than this. ;) Some stuff might work well directly on the wiki, though, like tepples' new revised nestech.txt is a solid win in my view.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Making PPU docs easier to understand (also nestech)

Post by Banshaku »

I guess that I'm a little bit responsible for creating that mess by creating the sections at the top of the wiki in the first place... Oppsy :lol:
Post Reply