nesdev.com

All I'm saying is if this guy thinks the NES is poorly designed, he needs to take a look at the SNES.

I don't think many were predicting that... If Apple's rise taught anyone anything, it's that I guess we should never overestimate how smart the average consumer is.

The nes is hoeky to the max, and its not just because it was 1983, it was hoeky for 1983 standards. Nintendo were cheap as cheap and it shows in every aspect.

No BCD because then it would cost more, but even then they technically broke the law and if Commodore found out in time, would have pulled in a hefty fee. Would have probably been enough to finish the LCD and C900 to which we could probably be using Commodores and not Apples today.

2K of RAM, maskable non maskable interrupt.. when the IRQ basically doesn't do very much and audio, particularly samples are very time critical and having them on NMI would make more sense. 8x8 sprites? with a limit of 8 on a line - ugh... Timers who needs Timers... Raster counter meh.... drawing sprites up the edge of the screen on the right boring. The write to this registers and it sets an internal latch so then you can write to it again to set the other half... look spend the extra 0.001c and add the gate for a 2nd register...

So 1983 what do we have.

Well to be fair a NES is better than all the Apple][s bar the GS in terms of capabilities in video games.
Compared the 2600VCS it is a fancy drink on a beach with a dedicated fan boy.
Its better than the P.E.T of 77 and the TRS-80 of 77
Atari 800s - 79 - bitmaps, timers, decent sound chip, 48K ram, built in software, raster counters, expansion ports, higher resolution
VIC-20 of 80~1 with 5K of ram, NES has more colours and sprites and audio channels, but VIC-20 has keyboard, timers and more RAM. And Vic-20 was 1/3 the price.
ColecoVision of 82 getting about square
C64 of 82 - bitmaps, larger sprites, timers, decent sound chip, 64K ram, built in software, raster counters, expansion ports, higher resolution

But the C64 cost more in 83 than the NES did. However by 85 when it hit states side, it was about even if not cheaper. And in 85 we had C128s and A1000s. In 83 the A800s were $165

I fell that Nintendo should have "refreshed" the NES in 85 for the US launch and added in more things to bring it more up to date, having proven the model in Japan for 2 years first. Not that it seems to have mattered for some reason the US jumped on to it. My guess is piracy issues.

But to answer the original post - because Japan was a backwater in 83, that was still crippled from the war - recovering but still gut punched, there was no money, so every single yen counted. So they made it as cheap as possible to sell it as cheap as possible to survive.

This is a better comparison, as we can see that the Famicom was often better but sometimes worse due to year/technology/cost tradeoffs. But it must be mentioned that the A800, C64, and CV all were monochrome / 1bpp (per tile) in their high(er) resolution modes. Their resolution/colour settings meant that games were primarily between 160-176 pixels wide on the computers. Colourful, brick-shaped graphics.

_________________
http://www.chrismcovell.com

8x8 sprites makes perfect sense to me since that's one of the more useful sizes. The PC Engine allows 16x16 as its smallest, which I believe wastes a lot of VRAM for the pattern data for small things like bullets. Not to mention the fact that sprite patterns and background character patterns uses two quite different formats (background characters are always 8x8 on PC Engine).

And max 8 sprites on a scanline was standard for sprite-based systems no? What systems of the time allowed more than this? Game Boy did but it was a later system.

According to interviews, they had no idea how to design the system at first, but they decided to make a system that could run Donkey Kong which was the hottest game at the time. Donkey Kong was using the same board as Radar Scope which in turn was inspired by Namco's Galaxian I think.

The launch price was ¥14800 (according to wikipedia) which was very expensive at the time (about the same as the Nintendo Switch I think). It was already more expensive than what Yamauchi wanted, adding more colors and stuff would have made it too expensive to sell I think (all the newbie mistakes and non-functional features aside).



Updating the NES and possibly breaking compatibility with existing games? Even if it would be backwards compatible with Famicom games that would mean developers would have to make two versions of their games just to take advantage of the updated NES as well as the Famicom that people already had bought.


The US was under the effects of the "American video game crash" so games didn't sell at all. Nintendo somehow convinced people that they had high quality stuff (which they did), and it sold.
Nintendo was even reluctant to sell in Europe at first even though we weren't affected by the crash as much. Bergsala (which is now Scandinavian Nintendo) had been successfully selling Game & Watch systems in Sweden, and now wanted to import the Famicom, but Nintendo wouldn't let them at first because they where afraid of the effects of the crash.


Maybe the yen pinching mentality from the war was still in effect but they had definitely recovered from the wounds of the war quite well in the eighties. The bubble economy started in 1986, so they were on the rise.
But yeah Nintendo was still a small company that had already failed in several business areas, so of course they wanted to make it as cheap as possible.

Yeah, the higher resolution modes of those machines are practically text only since it eats up the ram that can provide higher color resolution at lower pixel resolutions (and still being expensive RAM-wise). You'd need that setting for word processing and programming, while most games stayed at lower resolution. Commodore 64 gets its extra colourfulness from resorting to 2:1 wide pixels in lower res setting. That would count as ugly in my book, although a bit charming in certain sense.

If the NES had a high-res mode, we'd maybe see more text adventures, i guess.. Not much else to do.

I think the most straightforward consideration for it would be to have 4k built-in ram, but that might have been to expensive at the time. I don't know.

Another factor to count in is that the NES not having software built in is really a feature. You don't need to have that much ram if no OS is there to eat it. On C64, you would have a lot more restricted access to zero page for your software. On the NES, it's all yours. That's in other words both more efficient and more straightforward.


Incidentally, i sort of did that for a ming mecca user.
Background is 4 colours per palette. 2 palettes can be shown simultaneously. Sprites are 2 colour (1 solid, one see-through). There can only be 2 sprites at any one time. If you want "more", you have to resort to position jumping synced to screen refresh (so with a bit of glitch prone trickery, it can be 2-per scanline). A complete system costs ~10k usd, no cables or housing included. For being able to patch up more complex games, you'd need to add third party or DIY logic gate modules. The price for gaming modular...

_________________
http://www.frankengraphics.com - personal NES blog

As far as I know, most games/demoes disable BASIC and never return to the OS ever again and just "takes over" the system. Some keeps usage of Kernal ROM, some don't even bother doing that. This leaves all zero page usable exept $00 and $01 which are in fact hardware registers.

As for this thread, I think the OP is simply a troll. He came up calling the NES "ugly architecture" but never mentionned what exactly he thought was ugly, and now he left the discussion altogether, so he just wanted us to argue what was ugly or whatever.


That's actually exactly what they did - the system looks completely different and cartridges aren't even compatible. They just made sure the software was (mostly) compatible. The big failure was that software stopped being compatible with the PAL NES - even the soviet pirates were better than Nintendo at porting the console to PAL - the Dendy does that just fine !

Sorry, my bad - i didn't know commercial games didn't use kernal that much?

_________________
http://www.frankengraphics.com - personal NES blog

Well I don't know exactly what percentage of games uses the Kernal but it's possible to ignore it entirely. Also on the C64 the barrier between "commercial" and "homebrew" games isn't as evident as with the NES since the platform was open to homebrew from it's very start.

The NES's main advantage over the other machines of the era is hardware char level scrolling, the C64 has pixel level( some other machines don't even have that much ) but you then have to manually shift the screen 1 char over, which eats a bunch of clocks. Then if you want CRAM too.... We found ways around it though Being 40chars wide causes pain when trying to do it in hardware... Other machines don't have char mode and well slow is the word...
So its easier to get more colours on the screen on a NES, but the C64 can get more colours on the screen, its a trade off.
While the C64 does have the 8 sprites on a line limit, the sprites are 24 pixels wide, so in NES terms it gets 24 sprites per line. The A800 only has 4 ( or 5 ) but as tall as you like. The 8x8 is great for a bullet hell. Annoying for most other things though I would think. To make a normal sized player character, Mario for example, you have to bolt a bunch together, then you have to store data to point out which sprites are offset from the "anchor" position, then you have to move and update all the sprites to move the character. And then with a character being 2 or 3 sprites wide you hit flicker fast fast. First level of Mario fast. Most games on the C64 for example will use 1 sprite or 2 sprites to make a character. So to move a player one pixel to the right its
INC $D000
and if 2 sprites
INC $D002
But the NES has a faster CPU clock speed. There are points where the smaller sprites help and places where they hinder. Then the C64 can access 16K of RAM for the graphics at one time, allowing it to store more sprite images. Said 16K is directly accessible by the CPU so you can modify it and race the beam or chase the beam as you need.
But to put the architecture in to perspective a C64 has 46 control registers on its Graphics chip, although to be fair this does include the sprite settings, discounting them gives you 21 registers. The sound chip has 28 registers, the CIAs of which there are 2 have 16 registers each, the CPU has a 5 bit register on it as well. The NES Programmers Reference Guide is 2 stapled pages made on a photocopier Remember we are comparing bare metal to bare metal, so none of the mappers that allow you to get away from what is just in the box, as both the NES and other machines can do it as well.

I don't think massive upgrades would have been done. Just maybe bump it to 8K RAM and add a couple of timers to the machine to make it more in line with the computers the western devs are use to. Japanese devs would be able to ignore them for a local machine and then those would work on a US/EU machine without any changes. The US and Euro devs mostly made things for the Western market so not being able to throw a cart into Japan probably wasn't a big issue, and then if you did, you can easily add a CIA chip or some extra RAM onto the cart to bring it up to the extra spec.

The C64 has banking, so you can kick the internal software to the kerb and take all 64K RAM for yourself and use all of the ZP for yourself as well most games do. And then some games are just written in BASIC or partly use BASIC, Sid Meir's Pirates being the typical example.

2 pixels wide on a 402 pixel screen makes the pixels 1.27x as wide as a NES pixel so not that much chunkier. But then we can overlay hires sprites on the double wide multies of which the pixels are 60% the width of a NES pixel.

PAL vs NTSC is just they don't work, its not Nintendo's fault for them being incompatible, they just are. You can't keep the same number of clocks per line, you can't keep the same number of lines, you can't keep the same refresh rate. These days in HD world were all TVs support 60hz HD images its not an issue any more, but back then nothing you could do.

Well, about the refresh rate nothing can be done obviously, but about the clock per line, the ratio should have been kept the same so that timed code works; Dendy does that just fine.

The issue is their needs to be a master clock. This is usually the colour carrier clock. On PAL this is 4.43361875 Mhz and on NTSC it is 3.58Mhz if you have looked at a NTSC Z80 machine, a lot of arcades for example, SNES even, 3.58 Mhz clock might look familiar.

The PPU has to run on a clock based upon the output image otherwise the image will roll and the pixels will jump around. If you have the PPU running at one speed and the CPU running at another speed, that is not a nice division, then you have the PPU clock and the CPU clock out of phase which complicates it sending data to the PPU registers or OAM. An example of this case is the C128's VDC which uses a different time base to the VIC IIe chip. Bil Herd had to fudge it with some buffer logic and the chip is a total pain in the butt to use as you have to ask the chip if it is ready to receive data, then poll it to find out when it is ready, then write data then wait a few clocks to make sure it got through the buffer and start again. Vs the VIC chip and the CPU of which the CPU is /8 what the VIC runs at, so you just write what you want and the VIC's address set up times, hold times, data latch times are all in perfect sync with the CPU and it just works(tm) So sliding the CPU clocks on the PAL version would cause more pain then its worth, and then sometimes you will right to the first clock, sometimes the 2nd clock, you would have jitter.

The Dendy is a kooky special PAL that uses a 3.58Mhz colour clock but in a PAL frame timings, thus the divides then happen and line up with NTSC timings, and so the clocks can match NTSC ish which after the divs get you the same number of clock per line.

C64 sprites can be most usefully thought of as four 24x21-pixel sprites with 4 colors plus transparency. Each consists of a 1bpp outline plane on top of a chunkier multicolor plane. Thus you have four colors: the two shared multicolor sprite colors and two particular to a single sprite (the outline plane's color and the first multicolor color). Mayhem demonstrates this well.

One serious problem with C64 is that it takes unbearably long to load games from cassette tape. Unlike with NES, few games came on cartridge, and as I understand it, few people outside the USA got a 1541 disk drive because it was so expensive.

Dendy doesn't use "a 3.58Mhz colour clock". It uses the same color subcarrier and master clock frequency as the PAL NES, just with a /15 in the CPU instead of a /16 and a later NMI in the PPU. Use of /15 causes the number of CPU clocks per scanline, which is the important part, to match NTSC.

No, it's not trolling.
I'm talking about why nes can't self read input every frame

A serial read is of no issue as long as the package is small enough. Reading the game pad is a very small package.

You can, theoretically, also use these ports for external device communication, provided you have a device. Rachel Simone Weil has used it for posting and reading tweets, aswell as TASboting via wi-fi. Not that it's limited to the NES, but the point is you can do it. Heck, you can probably connect a couple of NES units for true separate screen multiplayer, had you the time and means.

_________________
http://www.frankengraphics.com - personal NES blog

It takes a miniscule amount of time to read in the grand scheme of things (even with an active DMC), and even then some games opted out for an unrolled loop and had the same code repeated 8 times. It works, and honestly my question would rather be why the designers of the Mega Drive felt that a controller port interrupt was necessary. Does such a thing improve responsivity noticeably at all?