Creating a decent manual
Moderator: Moderators
The single character bitfield names are just references to the detailed descriptionbox below (I've modified it slightly, see new example). I agree that larger names are preferable but the current design sometimes makes it hard to fit larger names (assuming all 7 bits are used for example).
http://dl.dropbox.com/u/2590713/NES/Ref4.pdf
http://dl.dropbox.com/u/2590713/NES/Ref4.pdf
Yes, but there's nothing there specifically about the Ricoh 2A03 and/or 2A07, I was referring to these specific 2 models.tepples wrote:Have you checked 6502.org?
Uh, didn't I say this, not tepples?cpow wrote:I agree with Tepples we need information, not just a format.
Yeah, that was my point.formats can be changed globally if necessary.
There needs to be contrast between dark and light colors, specifically, you can either have dark text on a light background or light text on a dark background. For example, these forums use white text on a dark blue background. The most contrast is achieved by either pure white text on a pure black background (as in the box I am typing in right now) or pure black text on a pure white background (as is commonly used in books). However, I don't feel that either kyuusaku or oRBIT2002 has been efficient with color in their examples. They both have the problem of dark text on too dark of a background. I propose that rather than change the background colors as you are doing, we vary the text colors between different dark shades and leave the background white. Darker shades of most colors are more common than the lighter ones and I think formatting it in this manner would improve readability.kyuusaku wrote:I understand why it should be colorblind friendly, but I don't get why it has to be devoid of ANY color, nothing has to be solely color coded. Here's a mockup of something I'd do
However, with all that said, I still think gathering and compiling the information is more important and we could have the format discussion forever (I'm sure you're all familiar with iNES vs. UNIF vs. Pasofami and everyone's varying opinions on that.... let's be productive with this.)
6T4 is completely right, collecting the information is obviously most important. It is clear that this web site holds the absolute best information on the NES available, though it is scattered into a million places. That is why we created a wiki many years ago (though many don't seem to know it exists). The wiki is (IMO) the single best piece of documentation we have. I would suggest that whatever you do, base your content on the wiki. If the wiki doesn't have something, please add it
As for formatting, stop messing around and just use Latex like a real content publisher. There's no reason to spend all this effort on presentation, when that can all be done with a Style later.
As for formatting, stop messing around and just use Latex like a real content publisher. There's no reason to spend all this effort on presentation, when that can all be done with a Style later.
Good sources of information
Okay, since most of you are in agreement that we need to compile the information, let's get started on that. A few months ago, when I was gathering information to use for programming NESFaCE, I made a list of what I thought were the best documents and categorized these (CPU, PPU, etc.). The following is a revised version of that list.
General Emulation:
http://www.codeslinger.co.uk/files/emu.pdf
General NES Emulation:
http://wiki.nesdev.com/
http://nesdev.com/NESDoc.pdf
http://fms.komkon.org/EMUL8/NES.html
http://nesdev.com/ndox200.zip
http://nocash.emubase.de/everynes.txt
http://nesdev.com/NESTechFAQ.htm
http://nesdev.com/NES%20emulator%20deve ... 0guide.txt
http://nesdev.icequake.net/NES%20emulat ... ussion.txt
Processor:
http://nesdev.com/2A03%20technical%20reference.txt
http://nesdev.com/r650x.zip
http://nesdev.com/6502.txt
http://nesdev.com/6502_cpu.txt
http://nesdev.com/6502jsm.zip
http://nesdev.com/6502bugs.txt
http://emu-docs.org/CPU%2065xx/Assembly.txt
http://nesdev.com/dr6502-docs.zip
http://www.obelisk.demon.co.uk/6502/
Graphics:
http://nesdev.com/2C02%20technical%20reference.TXT
http://nesdev.com/loopyppu.zip
http://nesdev.com/nesgfx.txt
http://nesdev.com/PPU%20addressing.txt
Sound:
http://nesdev.com/apu_ref.txt
http://www.slack.net/~ant/nes-emu/dmc/
http://emu-docs.org/NES/nessound.txt
Control:
http://nesdev.com/nes4play.txt
Header:
http://nesdev.com/neshdr20.txt
Mappers:
http://emu-docs.org/NES/Mappers/mappers.txt
http://www.romhacking.net/docs/362/
http://www.romhacking.net/docs/353/
http://kevtris.org/nes/mappers.html
I think going through these would be a good starting point for this completely comprehensive NES document project. If anyone has any suggestions for additions to this list, let me know.
I also wanted to say something about the writing style of these documents... it's very bad in many of them. For example, most documents I've read that talk about IRQs don't even say what IRQ stands for (Interrupt Request). The first link in this post uses English very poorly and seems like it is written by someone who's first language isn't English (that author has actually acknowledged this). There are also myriad grammar and spelling errors in many of the documents, but sometimes there are typos that make the information completely inaccurate (like the mixing up of the digits 0 and D in opcodes in 6502.txt (possibly because saying "6D" out loud sounds so similar to saying "60")). I'm just pointing this out as something we need to be careful about if we want to write a good document.
General Emulation:
http://www.codeslinger.co.uk/files/emu.pdf
General NES Emulation:
http://wiki.nesdev.com/
http://nesdev.com/NESDoc.pdf
http://fms.komkon.org/EMUL8/NES.html
http://nesdev.com/ndox200.zip
http://nocash.emubase.de/everynes.txt
http://nesdev.com/NESTechFAQ.htm
http://nesdev.com/NES%20emulator%20deve ... 0guide.txt
http://nesdev.icequake.net/NES%20emulat ... ussion.txt
Processor:
http://nesdev.com/2A03%20technical%20reference.txt
http://nesdev.com/r650x.zip
http://nesdev.com/6502.txt
http://nesdev.com/6502_cpu.txt
http://nesdev.com/6502jsm.zip
http://nesdev.com/6502bugs.txt
http://emu-docs.org/CPU%2065xx/Assembly.txt
http://nesdev.com/dr6502-docs.zip
http://www.obelisk.demon.co.uk/6502/
Graphics:
http://nesdev.com/2C02%20technical%20reference.TXT
http://nesdev.com/loopyppu.zip
http://nesdev.com/nesgfx.txt
http://nesdev.com/PPU%20addressing.txt
Sound:
http://nesdev.com/apu_ref.txt
http://www.slack.net/~ant/nes-emu/dmc/
http://emu-docs.org/NES/nessound.txt
Control:
http://nesdev.com/nes4play.txt
Header:
http://nesdev.com/neshdr20.txt
Mappers:
http://emu-docs.org/NES/Mappers/mappers.txt
http://www.romhacking.net/docs/362/
http://www.romhacking.net/docs/353/
http://kevtris.org/nes/mappers.html
I think going through these would be a good starting point for this completely comprehensive NES document project. If anyone has any suggestions for additions to this list, let me know.
I also wanted to say something about the writing style of these documents... it's very bad in many of them. For example, most documents I've read that talk about IRQs don't even say what IRQ stands for (Interrupt Request). The first link in this post uses English very poorly and seems like it is written by someone who's first language isn't English (that author has actually acknowledged this). There are also myriad grammar and spelling errors in many of the documents, but sometimes there are typos that make the information completely inaccurate (like the mixing up of the digits 0 and D in opcodes in 6502.txt (possibly because saying "6D" out loud sounds so similar to saying "60")). I'm just pointing this out as something we need to be careful about if we want to write a good document.
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: Good sources of information
I attributed the mixing up of fairly-similar-looking characters to a lack of careful review after scan/OCR of the original documents. The C=64 Programmers Reference Guide is full of that type of problem.6T4 wrote:There are also myriad grammar and spelling errors in many of the documents, but sometimes there are typos that make the information completely inaccurate (like the mixing up of the digits 0 and D in opcodes in 6502.txt (possibly because saying "6D" out loud sounds so similar to saying "60")). I'm just pointing this out as something we need to be careful about if we want to write a good document.
Awesome compilation...I would like to help. Perhaps we should "nominate" people to do certain sections? What would be the best way?
Does anyone have this document available on a mirror? Seems the site is dead.
http://www.codeslinger.co.uk/files/emu.pdf
http://www.codeslinger.co.uk/files/emu.pdf
- donato-zits-
- Posts: 47
- Joined: Fri Jun 03, 2022 11:14 am
- Contact:
Re: Creating a decent manual
Where is ndox200?
http://nesdev.com/ndox200.zip or like in the "link" of NES Documentation 1.0
http://nesdev.parodius.com/ndox200.zip
Where is it?
edit: I think so thata I find it right now, is this one https://www.zophar.net/documents/nes/y0 ... ation.html
http://nesdev.com/ndox200.zip or like in the "link" of NES Documentation 1.0
http://nesdev.parodius.com/ndox200.zip
Where is it?
edit: I think so thata I find it right now, is this one https://www.zophar.net/documents/nes/y0 ... ation.html
viewtopic.php?t=24252 <<<<my game
Re: Creating a decent manual
There is another reason to avoid the colours, even if you are not colour blind, which is in case you do not have a colour printer, and you want to print out.
(Free Hero Mesh - FOSS puzzle game engine)
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: Creating a decent manual
Or, you could easily convert each image to grayscale first, then view that grayscale, and finally make some simple color adjustments that translate well to grayscale. This takes a bit more work, but allows appropriate color use.
EDIT: and, with graphics programs nowadays, the image can be quickly converted to and from grayscale with just a button press… no saving involved.
EDIT: and, with graphics programs nowadays, the image can be quickly converted to and from grayscale with just a button press… no saving involved.
Re: Creating a decent manual
The wiki hosts a version of ndox200/nestech updated with what has been learned since then: Nestech.txt