JohnnyRockets Posted May 5, 2012 Share Posted May 5, 2012 Hey all, What is the main differences that one experiences when programming for the 2600 and then for the NES system? Thanks ahead of time! JR Quote Link to comment Share on other sites More sharing options...
31336haxx0r Posted May 5, 2012 Share Posted May 5, 2012 IIRC the NES CPU is a 6502 with sound generator on-die.The 6507 in the 2600 is a downgraded 6507, only able to adress 4K of adress space. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted May 5, 2012 Share Posted May 5, 2012 A more-detailed explaination of what is missing in the 6507 (vs. the more-common 6502): http://www.atariage.com/forums/topic/196546-how-do-i-read-a-pinout-with-memory-info/ Quote Link to comment Share on other sites More sharing options...
JohnnyRockets Posted May 6, 2012 Author Share Posted May 6, 2012 Excellent! Thanks Nukey Shay & others! Quote Link to comment Share on other sites More sharing options...
Tjoppen Posted May 6, 2012 Share Posted May 6, 2012 The NES CPU (2A03) also lacks BCD mode, to free up space for the sound generator. Quote Link to comment Share on other sites More sharing options...
tokumaru Posted May 11, 2012 Share Posted May 11, 2012 What is the main differences that one experiences when programming for the 2600 and then for the NES system? Apart from the CPU differences already mentioned, to me the biggest difference between those systems is the video hardware. The NES has enough video memory to hold an entire screen worth of graphics, so the typical game loop consists of using rendering time (the time during which the video chip, the PPU, is rendering the image) for calculating game logic, and then during VBlank, when the video memory can be accessed by the program, the parameters for the next frame are changed (sprites, palettes, background tiles, and so on). The 2600 is the exact opposite. Since its video hardware can only hold information for drawing 1 scanline, the CPU has to constantly interact with the video chip (the TIA), updating the image parameters as the picture is rendered, and then during VBlank the program can perform the game logic for the next frame. The lack of more capable video hardware results in little CPU time available for game calculations on the 2600 when compared to the NES, even though the difference in CPU speed isn't that big (the Atari CPU runs at about 2/3 the speed of the NES CPU). The fact that the Atari CPU has to double as a video chip is what makes the NES look so superior when it comes to processing speed. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 11, 2012 Share Posted May 11, 2012 What is the main differences that one experiences when programming for the 2600 and then for the NES system? I guess I'm one of the few people in the world to have published games on both platforms. As noted, the NES had hardware video capabilities -- 8 sprites, which could each be double-character in height. They could also be multiplexed, so you could get many sprites per screen. You couldn't write to video memory during active screen display, though, and the access to video memory was warped; you had to first write an address to a register then write your data to another register. No direct access. The NES provided character-based graphics, multiple playfields, of sorts, and hardware scrolling -- of sorts. Technically you could scroll the whole screen by +/- 7 pixels but you could rewrite the horizontal scroll during screen display. But not the vertical. However it was possible to get around this limitation to implement split-screen scrolling games. From a CPU point of view, there was no real practical difference between 2600 and NES; it's a 6502 for all intents and purposes. But as mentioned before, lack of BCD mode was a real annoyance because you had to implement division routines to display scores, or do your scoring in a really inefficient manner. Generally with the NES I recall having to pack data very carefully so that the needed animations fitted into the available 256 characters in the character-set. It sounds like a lot of space, but it wasn't. Personally I find programming on the 2600 more pleasurable because of the modern tools we have; back in the day NES programming was tedious and a bit of a black art. Cheers A Quote Link to comment Share on other sites More sharing options...
Phredreeke Posted May 11, 2012 Share Posted May 11, 2012 Also sprite multiplexing is done by the hardware (like the Colecovision) so you don't have to update sprite registers mid-screen to get additional sprites (like the C64) Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 11, 2012 Share Posted May 11, 2012 Also sprite multiplexing is done by the hardware (like the Colecovision) so you don't have to update sprite registers mid-screen to get additional sprites (like the C64) You had 8 sprites per line, full-stop. They were not multiplexed by hardware. You could put more sprites on the line, but the later ones were not displayed. There was a set of (?)64 sprite definitions which gave you your sprite positions and shapes, and the hardware would draw the first 8 on any line. I suppose you could call it multiplexing, of sorts. But generally I considered multiplexing a software operation to get more than 8 sprites/lline. I also have released titles on the C64; this was by far my favourite machine to program. Cheers A Quote Link to comment Share on other sites More sharing options...
eshu Posted May 11, 2012 Share Posted May 11, 2012 What is the main differences that one experiences when programming for the 2600 and then for the NES system? To add to what others have said - I've not actually programmed for the NES but compared to other 8-bits I've programmed on the small amount of RAM on the 2600 can make for a very different environment. Quote Link to comment Share on other sites More sharing options...
Phredreeke Posted May 11, 2012 Share Posted May 11, 2012 (edited) You had 8 sprites per line, full-stop. They were not multiplexed by hardware. You could put more sprites on the line, but the later ones were not displayed. There was a set of (?)64 sprite definitions which gave you your sprite positions and shapes, and the hardware would draw the first 8 on any line. I suppose you could call it multiplexing, of sorts. That's what I was referring to I suppose one would be temporal multiplexing while the other vertical multiplexing? Edited May 11, 2012 by Phredreeke Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 11, 2012 Share Posted May 11, 2012 That's what I was referring to I suppose one would be temporal multiplexing while the other vertical multiplexing? Well, I think of multiplexing as using the available sprites to display ALL objects. So you share all the sprites amongst all the objects. The NES simply *does not display* objects after the first 8 on a line. A software sprite multiplexer would use those 8 sprites to display "n" objects, and WOULD show all objects. So on a per-line basis, the NES hardware does NOT multiplex. However, there are (?)64 sprite definitions available, and the NES will display the first 8 on any line. So in principle, those 64 ARE multiplexed onto the 8 available sprites. It's a grey area; I just consider it "the NES displays (?)64 sprites on the screen at once, but fails dismally if more than 8 are on any line". Cheers A Quote Link to comment Share on other sites More sharing options...
tokumaru Posted May 11, 2012 Share Posted May 11, 2012 hardware scrolling -- of sorts. What do you mean "of sorts"? The scrolling capabilities of the NES are pretty good. You can have rendering start at any pixel in the name tables, and you can change it to any pixel during rendering (even though you have to use a trick to modify the vertical scroll, like you pointed out, but it's a very simple trick to pull off). The only thing that bothers me about scrolling on the NES is that the name tables have the exact same dimensions as the rendered screen, and since there are only 2 of them it's not possible to scroll horizontally and vertically at the same time without visible glitches in one edge of the screen (some very high-profile games suffer from this, like SMB3 and Kirby's Adventure). There are ways to cover this up though, or even avoid the problem completely by putting extra name table memory on the cart. But as mentioned before, lack of BCD mode was a real annoyance because you had to implement division routines to display scores, or do your scoring in a really inefficient manner. Heh, since I learned 6502 assembly on the NES, I don't count on the BCD mode at all! =) I'll be sure to make use of it on the 2600 though. I have always opted to use the inefficient way, where each digit uses 1 byte and the carry is handled manually. I don't see such a big problem with that, because 6 or 12 bytes out of 2048 is not that much. Speaking of RAM, I also see a lot of difference between the 2600 and the NES because of it. I'm currently making my first serious 2600 game, and it amazes me how simple the final design of everything has to be. Of course that just because it's simple it doesn't mean it's easy, because finding that simple solution that will do what you want is the real challenge of coding for the 2600. But still, when I look at the memory map of my game, or the kernels that draw the picture, I'm amazed by how simple they are. They have to be, because there's only so much you can do with 76 cycles per scanline and 128 bytes of RAM, but I find the process of reaching those solutions really fun. On the NES you have much more freedom with the architecture of the program because of the amount of RAM (2KB isn't amazing at all, but is insanely more flexible than 128 bytes!), you can model more complex worlds underneath what gets displayed on the screen, it's not just about calculating the new positions of stuff on the screen every frame. On the NES I usually have a clear separation between the model (the simulated game world) and the view (what gets displayed on the screen), while on the Atari that isn't really possible, the game entities have to BE the sprites. There's just not enough RAM to model anything with greater complexity. Programming the NES is more straightforward, there isn't so much problem solving or code shuffling as on the 2600 (unless you are really trying to push the system's limit, but with simpler games you typically don't even have to care about instruction timing)... I find both ways to program fun though, I'm enjoying my current experience with the 2600 very much. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.