I don't know of any c compilers... I've used nbasic but I don't know basic so it isn't really any easier to use that than learning assembler. Anyway, yeah, that's a PPU address. That link was helpful, thanks. Though, if writing to the same address twice causes the second write to be stored in the address's increment, how do you overwrite a value that you've already written?
NOW will there be a difference? Will using duty cycle 1 in famitracker now sound like duty cycle 0 normally does and vice versa?
Yes, that would be the result.
Quote:
Maybe I should start a new thread for discussing assembler code... anyway, can someone please explain this?
Address 8198 (or $2006) is special and connected to the PPU. It's using to set the PPU-side memory address and is 16 bits, so two writes are needed. First time the high value is sent and second time the low so $3F and $00 will set the adress to $3F00, which is the palette area.
Quote:
Hey, are there C compilers for the 6502 machine? Would it be convenient and efficient? if so, why messing with assembly that much?
Yes there is CC65 and I think it has a NES library, but can't tell how well it works. But usually assembly cannot beat C in efficiency.
That's odd, because later on in the code, it writes to 8198 just once. How do you overwrite a previous value then? By writing to it twice again? What if you write to it just once, then do something else, and then... you write the second time? Does that work? Agh, this stuff is driving me nuts...
I got CC65 and the NES library included but the documentation is just terrible. I actually understand more of the assembler code than I do CC65. I didn't find any code examples either. My guess is writing C code for a NES still isn't like writing C code for a PC... at all. I'd probably have better luck with nBasic.
I feel like you mean the opposite, but if not, horray for C! It's much easier!
I meant the opposite, yes.
Dafydd: If it's written to once then it will be written to again later, the PPU has a flag that tells if you write the first or second time. A read from $2002 can reset that flag.
The C code itself would be pretty much as on a PC, but you still have to make sure you don't print things on screen outside of vblank and such.
How do you handle memory addresses and such in C? I mean, if you want to place a sprite somewhere, do you still need to store it at the exact address where it's supposed to be or can you do something easier like "spriteX = 42"? I couldn't find anything on writing nes code in C...
I haven't used C for NES, but I'd say assembly is the easiest way to learn NES programming as you'll need to deal some with low level stuff and for better understanding.
You should be able to use variables as usual in C on NES, but you must still communicate with the PPU to update sprites. (Preferably by using sprite DMA, requiring sprite data to be in order in memory.)
Ok. Just out of curiosity, have you (jsr) ever managed to make a rom with graphics that... well, worth a look? Or do you stick to music?
Also, I'm wondering a little about stuff like sfx and music in nes games. Let's say I wanted to make a pc game, and wanted nsf background music and sfx. Can something like nsfLive! be used to play music in the background and whenever an sfx plays the channels that the sfx uses override the music on those channels until the sfx is finished and the music returns (i.e. exactly what happens in a typical nes game, such as when one of the square channels stops playing music when megaman fires because the firing sfx uses that channel, and the music starts playing again on that channel as soon as the firing sfx has finished)?
Also, could the NSF driver be used in other applications, like, a nequencer (or whatever), a program that works just like famitracker except it has a sequencer interface rather than a tracker one? Or is the NSF driver not actually used during playback in famitracker, only for making the NSF files?
That pretty much intrigued me : what is exactly an NSF driver?!? That doesn't make much sense to me, as "driver" is something specific to Windows...
[ >> I looked at the 6502 instruction set and its architecture... Wow, such a neat system! Seem somewhat easy and well organised, I understand why it was used over the Z80 (this one frightened me with its billions registers)
One man's tidyness is another man's bloody mess...
Anyway, the NSF driver is written in assembler, so my guess is it's a NES "program" (rather than "game" that plays music. But you'd still need a NES emulator (at least a partial one) to actually get the driver to create sound. Maybe that emulator is included in the driver, I don't know. A driver is usually a dll file and so are winamp plugins, so I guess a driver can really do anything. The dll's I've made have been programs in their own right, or parts of programs, and not necessarily something windows related.
Dafydd: I have a ROM that displays debug data when I develop the NSF code, and I'm working on a visual player for NSFs (but haven't got anywhere).
Jarhmander: Haven't really thought that deep about the name, it's simply a routine that drives the NSF player with data. A device driver (in windows) is something different.
Also, I've used both 6502 and Z80, but I prefer the more complex architecture. ^_^
