rtcvb32: The 2600/5200 if i remember right, was the result of them taking 'Pong' from a hardware and mixed circuits to a software approach, something that didn't really exist. They even named the hardware items after pong's elements. You had something like 2 player sprites and 1 ball sprite, which was all they really needed. Amazing they got so much more out of it through programming.

Memory was also expensive and space was limited too. Not only that when developing the 6502 certain instructions/features they had to beg for, else the 6502 would have ONLY been able to do Pong and like 1-2 other titles due to the limitations of the instruction set and memory access.

Worse since they didn't want to invest in additional money in a video chip the 6502 ALSO handled drawing the screen, so much that 95% of the speed is simply refreshing the screen and where all logic took place during the overscan areas and vsync refresh. In Pacman you can see undrawn areas where the programmer had to just force a section for additional logic/gameplay to work because he didn't have enough time. And to handle ghosts each ghost is drawn on every 4 frames making them flicker badly.

This is a far cry from anything more modern where the Xbox was literally a 386 800mhz computer with a GPU thrown in.

rtcvb32: Depends. 2D and sprite based games, yeah didn't change much. 30 years ago 3D games were slow and a novelty thing. There's also resolution, processing speed and Floating point. Keep in mind Floating point wasn't built into every CPU, you had a CPU and a separate FPU unit, and if you didn't do that you could emulate (very slowly) or do something like fixed-point, but things being either 8 or 16 bit, well... it was far too slow to active use. A simple wireframe house in BASIC on an 8bit machine would take like 3 minutes to render, and that's just a box with a roof, nothing special, vs sprites. I think there's a huge difference there. Though i'm not sure how many mathematical calculations are needed to render such a simple scene, and my trigonometry sucks. You might get away with 16-bit fixed point but very low resolution for things.

But there is a difference, be it the framework or whatnot. I bought a game on steam (when i first got involved) and it was playing in flash, and required SO MUCH CPU TIME. It was effectively an SNES game and i'd have been happier with a SNES game, at least then it wouldn't have pushed my machine so hard for so little. A simple game you can write in 300 bytes like flappy bird on a 6502 takes 3 Megs on a smart phone, and tons of CPU power. Very inefficient, something i loath.

Then there's differences between games using the same port but on different machines that might have a little extra umph, where in contra leaves would shake and other effects while on other NES systems it would be totally static. Maybe not as noticeable, but i'd think it's a big difference under the hood.

FairyFoliage: ...

Sarafan: Hello there!

Darvond: You youngin' my first RPG that I sank my teeth into was Exile II: The Crystal Souls. From 1996.

Darvond: It was that and Secret of Mana for me, but I was also late to the party.

BanditKeith2: I don't even see Nes titles as ''Old'' Though I see the Atari 2600 and what was on it as ''oldish''.. Whatever the case I could have sworn a Ni No Kuni title was on the ps2 or something with '' Ni No Kuni '' in the title somewhere but I could easily be mistaken on both fronts seeing as I have a big collection of games and was buying ps2 games even when the ps3 and Ps4 was out so ya just saying

rtcvb32: I'm sure a lot of people will think of 'older' as NES or C64 titles, like playing Bard's tale with 6 floppy disks or the like.

rtcvb32: 2600 and NES use the same CPU, the 6502. The difference of a better video output and more memory being the only difference. Namely most 'games' on the 2600 were like 2k in size, while segments in NES is 32k.

oldgamebuff42: Ahh. . .the good old days. The game that made me fall in love with RPGs was Secret of Evermore for the SNES, even though it has many flaws, including a sometimes bare-bone, cliched story and a near-impossible-to-beat-final-boss that I never took down without a "barrier" spell that makes you invulnerable, until it runs out and then you can cast it again with no cooldown.

dtgreene: Floppy drives? How about cassette tapes?

Ever play a game stored on a cassette tape?

dtgreene: I believe the NES only has 2k of RAM.

dtgreene: The reason the games are bigger than you'd expect are as follows:
* The cartridge maps into the upper 32k of the address space. This means that games do not need to load data from the cartridge into RAM; rather, they just access the data as though it were always in RAM.
* Cartridge can contain RAM on board. Sometimes this RAM would be connected to a battery, allowing its contents to remain if the system is powered off. (The Legend of Zelda was one of the first games to do this; you also see this in Dragon Quest 3 (Japanese DQ1/2 used password saves), and Final Fantasy.)
* There's also the handling of video, which has its own memory, and uses tilemaps for its rendering. (It's not like home computers of the time that typically had a framebuffer, as the NES doesn't have the ram for that.)

rtcvb32: Actually nearly all 8bit machines mapped hardware to the upper 32k, as there were no GPIO pins or anything like that, where the 65C02 and later included new pins. So you could include a ROM connection to data and have it work but never communicate with it. Workaround? Use a bit-wise hardware redireciton to addresses to different hardware components. This is why you'd poke to memory locations to change colors or make sounds or read/write to disk.

dtgreene: Actually, this depends on the CPU.

rtcvb32: It certainly does. But i was pretty much referring to the 6502 family and the 8bit machines including popular computers that came out with it, which i can't say all do it, but it seems fairly easy to assume so. Besides checking 1 bit to see if it should go to ROM or other hardware is a very simple check, thus the 32/32 or 48/16 mappings for that popular CPU.

Still it's interesting.

dtgreene: There were actually two main CPU families used in microcomputers of the day, the 6502 and the Z80, and it happens that those two CPU types are quite different at the instruction set level, and in how memory is mapped. The Z80 puts the interrupt pointers at the start, while the 6502 puts them at the end, for example.

dtgreene: Also, apparently those two CPUs don't run C code well, so it was common for programs to be written in assembly language.

dtgreene: The 8086, I believe, could handle C code much better, and it may be one of the reasons that CPU ended up dominating the market, even with its strange segmented address space (which allowed access to 1MB of memory, but also made memory addresses and pointers more complex).

rtcvb32: Doesn't sound right. C might have been complex enough editing, and compiling C on 6502 would have been difficult, but it would have to be fairly simple code. The x86 broke the compiler into several steps in order to compile programs, 6502 would be MORE limited. If you dropped the preprocessor then C probably wouldn't have much issue at all. Though depends on how it handles function calls and the like, and usually C object files all calls point to NULL, and are updated when linking. Plus you probably couldn't do hardly any optimizing of code due to those limitations.

rtcvb32: First system i remember getting had a 200Mb drive, something unthinkable with the 6502 systems.