Acmlm's Board - I2 Archive - Rom Hacking - Nes Question...
| User | Post |
Sokarhacd
Posts: 1696/1757 |
Thanks for all the extra info, and those links, ive seen a few before, but not the mapper one, which is helpful, I remember reading the CPU is NMOS in the nes tech doc, and yeah I was reading about the D flag, which sounded weird, but I understand it now, thanks,
also thanks for that other link dan.
Edit: ok, quick Question, i was looking at the 6502 Instructions, and I understand alot of them...but im not quite I understand where/why PHA would be used, I know it pushes a copy of the accumulator to the stack, but what exactly would this accomplish in a game?
|
dan
Posts: 749/782 |
Originally posted by Disch
There was also one made by the No$GMB guy semi-recently which seemed to have the least errors but it's not on nesdev and I don't have the link to it anymore.
Would this document be the one you are referring to? |
Dish
Posts: 590/596 |
Well there isn't really one doc which has it all, unfortunately. The closest thing to that would be the nesdev wiki, although it's not given nearly enough attention... so it's not really as complete as it could be.
As far as 6502 goes.... This page seems to be the best one. I've been using it forever and have yet to find a single error. The infamous "6502.txt" does a better job of explaining each instruction and its operation... however it's riddled with misprints and errors. It still might not be a bad read to get the idea... but for the technical stuff (which instruction uses which opcode, how many cycles they take, etc) I'd use that above linked doc as the final word.
A few 6502 quirks worth mentioning that aren't really covered in many docs:
- NES is an NMOS processor... not CMOS. So if you come across a doc which is talking about NMOS/CMOS differences... you're interested in NMOS.
- There is no Binary Coded Decimal on the NES (controlled by the D status flag). The D flag still exists on the processor and can be set/cleared normally... however its state does absolutly nothing. ADC/SBC always work as though the flag was off... even if it was on.
- BRK is actually a 2-byte opcode (well not really.... but it might as well be). The byte after a BRK instruction is skipped over when a game returns with RTI. However this isn't really important... as BRK is seldom/never used in NES games.
- There is no "Reserved" or "Unused" or "R" flag in the processor status reg (bit 5). It's just that whenever status is pushed to the stack (PHP,IRQ,BRK,NMI) the bit is always set.
- Likewise there is no "Break" or "B" flag in the processor status reg (bit 4). Bit 4 is just set/cleared when status is pushed to the stack depending on HOW the status is being pushed. (PHP/BRK set the bit... IRQ/NMI clear it)
- I have yet to see a document ANYWHERE which does a decent job of explaining how the V flag is set on ADC/SBC. On ADC... it's set when Positive+Positive=Negative... or when Negative+Negative=Positive, and cleared on any other conditions. And on SBC it's set when Positive-Negative=Negative or when Negative-Positive=Positive... and cleared under any other conditions. But the V flag is seldom used so it's not that big of a deal.
This doc on nesdev has a very cool section near the bottom which explains what every instruction is doing on every cycle. It might not be useful for what you're doing but I like recommending it anyway just because it's very detailed.
As for NES operations... honestly... I don't really know of a good doc which covers all of it without error. NEStech is still a favorite of mine.. despite being very old and somewhat outdated (and often incorrect). Although it should be "good enough" for most things. There were a few spinoff docs... FP made one called "Nintech" which I never looked at... mainly because I'm spiteful towards FP. There was also one made by the No$GMB guy semi-recently which seemed to have the least errors but it's not on nesdev and I don't have the link to it anymore. NESdev has another one called "NES System Architecture" by Marat Fayzullin... but it's even older than NEStech so I wouldn't recommend it (it's what NEStech was written to replace).
I'll stop rambling now ^^
EDIT - crap.. forgot probably the most important link!
As far as mappers go... Kevtris' docs are pretty much the FINAL authority in that department: Link. |
Sokarhacd
Posts: 1695/1757 |
im not doing anything yet, im just trying to learn more about the nes, and I was curious about what those 2 unknown scanlines were, so I thought I would ask, though the reason im doing this is so I can learn some 6502 asm, which I never had a chance to do before.
another quick question, I got quite a few docs from nesdev, how complete are they? like how much of the info is correct, since you pointed out a couple things in that doc that wasnt, and I dont really wanna learn something that isnt right. |
Dish
Posts: 589/596 |
Forgot to mention that PAL actually has 70 scanlines of VBlank and not 20. But yeah
Anyway... mind if I ask what you're doing? ^^ I freaking love the NES |
Sokarhacd
Posts: 1692/1757 |
Hey, thanks disch, plenty of info, and thanks for the link to the ppu doc.
ill post here if I have anymore questions, so no mod close this  |
Dish
Posts: 588/596 |
One screen consists of 262 scanlines.
-------------
20 scalines of VBlank
-------------
1 "pre render" scanline
-------------
240 rendered scanlines
-------------
1 Idle scanline
-------------
The pre-render scanline is used to fetch tiles for the first render scanlines (tiles have to be fetched a little earlier than they're drawn). The idle scanline does absolutly nothing... and it's sort of a ripoff (it might as well be VBlank time... but NMIs don't fire until after that scanline is complete).
Every scanline consists of 341 PPU cycles except for the pre-render scanline which alternates between 341 and 340 every odd frame on NTSC systems. On an NTSC system there are 3 PPU cycles to 1 CPU cycle, so a scanline is 113.66666667 CPU cycles. On PAL systems, there are 3.2 PPU cycles to every 1 CPU cycle (PAL scanline = 106.5625 CPU cycles)
For details on what PPU fetches happen on what cycles and further details, I'll refer you to Brad Taylor's excellent PPU doc.
EDIT -- although note that the mentioned doc's MMC3 information is inaccurate. MMC3's IRQ counter is actually tied to A12 not A13, and operates very differently than how described in that doc. |
Sokarhacd
Posts: 1691/1757 |
ive been reading the nes tech guide, and it shows this, what I was wondering is, whats in the unknown space?
+--------+ 0 ----+
| | |
| | |
| Screen | +-- (0-239) 256x240 on-screen results
| | |
| | |
+--------+ 240 --+
| ?? | +-- (240-242) Unknown
+--------+ 243 --+
| | |
| VBlank | +-- (243-262) VBlank
| | |
+--------+ 262 --+ |
|
hukka
