I have a short piece of code that I'm trying to figure out (a
program by Bob Rost that just displays some text using letters from a certain ascii.chr - you've probably seen it before). I was hoping to completely "decipher" it and have the whole thing explained in full (well, almost) on the wiki. I don't know where to put the article though, or what to call it. What's a good subsection for explained code?
Personally, I think the wiki is great. I have a hard time reading through the enormous and super-technical documents found on the front page of this site, and a wiki is perfect for storing information in an accessible way. I don't know what the plan is, but if the wiki is intended to be the complete resource for nes development, it's off to a good start, but it could use some more activity...
Is Bob Rost even into NES development anymore?
I don't think so. He still has stuff from his class hosted on his website though. Does it matter? The code may be old, but so is the NES...
Dafydd wrote:
The code may be old, but so is the NES...
Our understanding of the NES is new. A lot of the old code passed off as NES code doesn't work correctly on an NES.
I looked and that code is crap. Don't bother with it unless you want to form false beliefs about the NES. If you want to analyze a basic tutorial, do 2-hello.a from the
ones I posted recently. It already has good comments.
Uh... no, I do not want to form false beliefs about the NES. I just wanted to understand what the code does. If that code doesn't do things the right way (which I've gathered is really important when coding for the NES), ok. Although I have no idea what's wrong about it, other than that it lacks comments.
Where to begin?
Using decimal numbers for addresses: horrible idea. no doc will match those, and are a total mess.
RESET, IRQ, and NMI vectors all point at the same code: Usually, powerup/reset initialization should be done once. This does it every vblank, or would if NMIs were enabled.
It's confusing to follow, but it looks like it might be trying to update the pallete and nametable during the frame, rather than during retrace, which won't work
Well, if we're going to critique the original code, let's have at it...
- nbasic_stack = 256 at beginning, some junk left over from a program that used a BASIC compiler probably.
- JMP start at the beginning, as if the NES starts executing from $8000 (oh, sorry, 32768 heh).
- main loop polls VBL flag, so it'll have an inconsistent frame rate.
- vwait_1 loop waits for VBL flag to become un-set, except that it's cleared when you read it, so this is entirely unnecessary.
- Sets PPUADDR after PPUSCROLL.
Well, thanks for pointing that out, although I can't say I understand why all those things don't work (probably because I still don't know what RESET, NMI or IRQ is - the only experience I have with IRQ is picking one when configuring the sound in old dos game setups). The use of decimals though - really confusing indeed. The fact that you can point out all these things is really getting my hopes up though - you seem to know what you're talking about and in time, I hope I'll learn what you know, too.
RESET is a signal telling the CPU to start executing code. Its vector points to the entry point to the code. If you know C or C++, this is similar in ways to the main() function.
NMI is a non-maskable interrupt. Its vector points to a subroutine that the PPU can tell the CPU to call.
IRQ is an interrupt. Its vector points to a subroutine that the APU or the Game Pak can tell the CPU to call. You appear to remember APU IRQs from MS-DOS; in that environment, APU IRQ told the running app to point the APU at more samples.
NMI and IRQ subroutines should end with RTI (return from interrupt), not RTS (return from subroutine).
Dafydd wrote:
I don't think so. He still has stuff from his class hosted on his website though. Does it matter? The code may be old, but so is the NES...
But bob rost is cool.