Slashdot Mirror

Also this is how Super Mario Bros. 3 works: there is an ASIC instead of the PPU ROM, which is why it is not only quite large

The Memory Management Controller (MMC3) helps make Super Mario Bros. 3 large, but it doesn't quite replace the CHR ROM. It just controls the high address lines (A16-A10) of CHR ROM and the high address lines (A17-A12) of PRG ROM. It's not conceptually different from the MMU used by a modern CPU to translate virtual memory addresses into physical memory addresses. MMC3 also contains a programmable interval timer that generates an IRQ by counting how often the PPU switches between reading sprite tile memory and reading background memory (which happens once per scanline). This timer is mostly used to switch between a game's playfield and its status bar.

but supports both horizontal and vertical scrolling at the same time

And a bunch of games that don't use MMC3 can do 8-way scrolling, such as Solar Jetman and Blaster Master. That's mostly a matter of the design of the game engine and, in some cases, of whether the cartridge has 8 KiB of supplemental work RAM on the CPU side (in addition to the 2 KiB in the NES) to cache a decompressed level map.

with more palettes than normal.

MMC3 does not extend the four background palettes and four sprite palettes, which are internal to the CPU. The closest a mapper can do is shrink the area affected by each palette from the normal 16x16 pixels. MMC5 has an "ExGrafix" mode that shrinks color areas to 8x8, and it was largely used for Koei's war sims but also saw use in Castlevania III and a handful of other games. But by the time developers started to figure out the MMC5's true capability, the TurboGrafx-16, Genesis, and Super NES were out, and game studios had mostly lost interest in the NES.

Sources: MMC3 reverse engineered docs; MMC5 reverse engineered docs; NesCartDB entries for SMB3 and other games

Also this is how Super Mario Bros. 3 works: there is an ASIC instead of the PPU ROM, which is why it is not only quite large

The Memory Management Controller (MMC3) helps make Super Mario Bros. 3 large, but it doesn't quite replace the CHR ROM. It just controls the high address lines (A16-A10) of CHR ROM and the high address lines (A17-A12) of PRG ROM. It's not conceptually different from the MMU used by a modern CPU to translate virtual memory addresses into physical memory addresses. MMC3 also contains a programmable interval timer that generates an IRQ by counting how often the PPU switches between reading sprite tile memory and reading background memory (which happens once per scanline). This timer is mostly used to switch between a game's playfield and its status bar.

but supports both horizontal and vertical scrolling at the same time

And a bunch of games that don't use MMC3 can do 8-way scrolling, such as Solar Jetman and Blaster Master. That's mostly a matter of the design of the game engine and, in some cases, of whether the cartridge has 8 KiB of supplemental work RAM on the CPU side (in addition to the 2 KiB in the NES) to cache a decompressed level map.

with more palettes than normal.

MMC3 does not extend the four background palettes and four sprite palettes, which are internal to the CPU. The closest a mapper can do is shrink the area affected by each palette from the normal 16x16 pixels. MMC5 has an "ExGrafix" mode that shrinks color areas to 8x8, and it was largely used for Koei's war sims but also saw use in Castlevania III and a handful of other games. But by the time developers started to figure out the MMC5's true capability, the TurboGrafx-16, Genesis, and Super NES were out, and game studios had mostly lost interest in the NES.

Sources: MMC3 reverse engineered docs; MMC5 reverse engineered docs; NesCartDB entries for SMB3 and other games

There has never been anything that I watched that I didn't want to watch again.

I know people whose viewing habits differ greatly from yours. Quoting this post by calima:

I don't find any replay value in Zelda, Mario, or other such highly regarded games, so my opinion is certainly not limited to current AAA devs or walking simulators. It's rather about what I enjoy in a game, and that I have an excellent memory. If I know what happens next in a movie, book, or game, it is no longer fun to me. I acknowledge I'm in a minority in this position.

I'm waiting for music released as Nintendo Game Boy carts.

The Famicompo Pico contest, organized by the FamiTracker.org community, has released NES cartridges of the winning original compositions, such as this. Brad Smith has covered the entirety of Pink Floyd's Dark Side of the Moon as an NES cart. As for Game Boy in particular, however, I don't know if the LSDJ scene has held contests.

I'm waiting for music released as Nintendo Game Boy carts.

The Famicompo Pico contest, organized by the FamiTracker.org community, has released NES cartridges of the winning original compositions, such as this. Brad Smith has covered the entirety of Pink Floyd's Dark Side of the Moon as an NES cart. As for Game Boy in particular, however, I don't know if the LSDJ scene has held contests.

If all running applications are 64-bit, the operating system can unload the 32-bit compatibility DLLs from RAM, freeing up more RAM to run applications.

Taken one step further, a fully 64-bit environment can let the operating system publisher remove 32-bit compatibility libraries from secondary storage entirely. This is the excuse that someone on another forum gave. His PC runs 64-bit GNU/Linux, and he's unwilling to use 32-bit applications because they need hundreds of megabytes of 32-bit libraries, even though said 32-bit applications and libraries are distributed as free software.

The part of the Sega Genesis memory map allocated to the cartridge is a linear sequence of bytes from $000000 to $3FFFFF. The part of the Super NES memory map allocated to the cartridge is not. See my diagram of Super NES address space.

The 65816 divides its 16 MiB address space into 256 banks, each 64 KiB in size. In order to make certain addressing modes more efficient to use, the Super NES divides up cartridge ROM address space as follows:

• Bank $00-$3F: Second half (32 KiB, $8000-$FFFF)
• Bank $40-$7D: Whole bank (64 KiB, $0000-$FFFF)
• Bank $80-$BF: Second half (32 KiB, $8000-$FFFF)
• Bank $C0-$FF: Whole bank (64 KiB, $0000-$FFFF)

The "HiROM" mapping (mode $21 or $31) is a linear sequence of bytes from $C00000 on up. Because of incomplete decoding of the address bus, the second half of each 64 KiB bank is usually mirrored into $808000-$80FFFF, $818000-$81FFFF, $828000-$82FFFF, ..., $BF8000-$BFFFFF. In addition, banks $80-$FD are mirrored into banks $00-$7D, so that the 65816 CPU can find the reset vectors at $00FFE0-$00FFFF (which is mirrored from $80FFE0-$80FFFF). Usually, battery save memory is at $306000-$307FFF, $316000-$317FFF, ..., $3F6000-$3F7FFF.

You might notice that everything in the above skips banks $7E and $7F. That's where the Super NES puts its 128 KiB of RAM, with the first 8 KiB mirrored into banks $00-$3F and $80-$BF. It also mirrors the memory-mapped I/O ports associated with the CPU's memory controller and the Picture Processing Unit (PPU) into banks $00-$3F and $80-$BF. They are made accessible through all these banks so that the same value of the Data Bank Register (DBR), analogous to the Data Segment (DS) register on 8086, can see RAM and ROM at the same time.

The "ExHiROM" mapping (mode $25 or $35) has two linear sequences of bytes: from $C00000 to $DFFFFF and then from $400000 to $5FFFFF, which get mirrored down into the second half of $80-$BF and $00-$1F respectively. Only the largest games, mostly exclusive to Japan such as Tales of Phantasia, use ExHiROM.

The "LoROM" mapping (mode $20 or $30), more common on early games, does not connect A15 out of the system to the ROM. This means it uses only the second half of each bank: $808000-$80FFFF, $818000-$81FFFF, $828000-$82FFFF, ..., $FF8000-$FFFFFF. Banks $C0 through $FF mirror the 32K of data in that bank into both halves of the bank, and banks $00-$6F are a mirror of banks $80-$EF. Usually, battery save memory is somewhere in $700000-$77FFFF.

Cartridges use either slow or fast mask ROM. Modes $20, $21, and $25 are "slow ROM", where the CPU slows down slightly in order to allow use of cheaper 200 ns ROM. Modes $30 and $31 are "fast ROM", which needs 120 ns ROM that was more expensive in the early 1990s. Mode $35 has fast ROM for the $C00000-$FFFFFF region but slow ROM for the $400000-$5FFFFF region.

Slight differences in address decoding in each cartridge lead to differences in which address ranges actually contain mirrored ROM (as opposed to open bus) and which address ranges contain battery-backed RAM. Furthermore, some coprocessors included in cartridges can change this mapping at runtime.

Posted on Slashdot recently.
As pointed out it is an emulator that is probably running on a Linux system.
The emulator buggier than the hobbyists versions you can find out there so you get a more accurate system if you buy an RPi and install another emulator on it.
You can throw in the Sega emulator on the same system, but it will still be emulation with all the bugs that comes from that.

Apparently, it's not even a good emulator.

The NES Game Pak edge connector has three parts: the CPU part, the PPU (Picture Processing Unit) part, and the CIC (Checking Integrated Circuit) part. Bad CIC connection (pins 34, 35, 70, and 71) causes blinking, as you mentioned. But bad CPU connection (pins 2-15 and 38-50) freezes the Control Deck on a blank screen, and bad PPU connection (pins 21-33 and 56-69) causes scrambled tiles, vertical lines, and even freezes in some games.

The PPU failure mode doesn't happen on later Nintendo systems, which have no dedicated PPU bus; all video memory is internal to the console. (In fact, the NES and Neo Geo AES are the only major home consoles to bring the address and data bus for the PPU to the cart edge.) Nor can CPU and CIC connection failure be distinguished on Super NES and Nintendo 64, where the lock chip in the console holds the CPU in constant reset until the CIC pair authenticates. The Game Boy connector has only a CPU bus, and the system authenticates the cartridge by matching the logo data. (Incidentally, Sega's similar Trademark Security System got ruled unenforceable in U.S. courts; see Sega v. Accolade and Lexmark v. Static Control Components.) Nintendo DS and Nintendo 3DS use block storage, similar to CF or SD, with an encrypted bus.

I think the Zapper only had a light filter

The photodiode's output runs through a resonator circuit, similar to that used by remote controls to demodulate pulses, to distinguish 15.7 kHz CRT scanning from other light sources.

and the games then had to make the interesting object bright and everything else on the screen dark during a frame to be able to detect the hit.

Or if the game makes the whole screen bright, it can time from the start of the frame to determine how far up or down it is pointed. A game can use this information in one of two ways: to narrow down how many "interesting objects" it needs to test, or to directly move an object up or down. The Zap Ruder tech demo shows this, and its Pong-like air hockey simulator called "ZapPing" feels just as responsive as "Laser Hockey" in Wii Play.

Because of that it was possible to cheat by pointing the Zapper at a lamp to get a guaranteed hit.

Hardly. If the photodiode sees light just before the start of the frame, the game sees it as a disconnected Zapper. (From the CPU's point of view, the resonator produces a 1 for dark and a 0 for light, and a disconnected input is pulled to 0.)

As usual, NESdev Wiki explains it in detail.

C++ relies on the C preprocessor, which is very limited, on doing macros.

C++ has type-safe and/or scoped alternatives to a lot of things that used to need C macros.

Thanks to this you don't have scoped macros for example.

C++ has namespaced templates.

In rust the macro system is done much later in the process, so that you can declare a macro inside a function, and after the } closing brace the macro scope ends!

In modern C++, you can likewise declare a lambda inside a function (example). This could replace the C-inspired use of macros as ghetto inline functions.

Commodore 64 cartridges could include a circuit that switches different pages of ROM into the 16 KiB of address space available to a cartridge. For example, if writing to cartridge space ($8000-$BFFF) instead writes to an octal D flip-flop (e.g. 74HC373/377) that controls A14 and higher address lines of the ROM, this would allow (in theory) up to 4 MiB of ROM. Similar techniques were common on Atari 2600 (which originally topped out at 4 KiB ROM) and especially on NES (likewise 32 KiB). But cartridges were underused because they were more expensive for game publishers to replicate than tapes and floppies.

very HQ recordings that nobody will ever want to see

You appear to underestimate the demand for videos of gameplay on retro consoles. Not only do people like to watch classic games, but also new games are being developed for the old platforms, and people want to watch the first level before buying the cartridge.

None of which has anything to do with sex life.

It has Robotfindskitten

So does anything with an NES emulator, since I made a robotfindskitten implementation for NES. But a text game with about 2.5K of code that someone could hack up in a night doesn't quite qualify as "high-production-value games".

, what else does anyone need?

I was referring to, say, a first-person shooter or action-adventure game with characters more detailed than smiley faces or stick figures and environments more detailed than just a bunch of featureless boxes.

So yeah. Super Mario Brothers 3 is easy enough to QA so you can release a perfect game.

Super Mario Bros. was 40K but still shipped with the minus world glitch. You'd be surprised at how many glitches Nintendo left in Super Mario Bros. and Super Mario Bros. 3. Read this thread about a hack of Super Mario Bros. and Super Mario Bros. 2: For Super Players (an initially Japan-only mission pack sequel to SMB1 that uses the SMB1 engine) that removes well over a dozen glitches in the game, including many depicted in this montage.

NES for example is 256x224

I have programmed games for the NES, and I can assure you that the NTSC NES picture is 256x240. The Super NES is most commonly 256x224 with the black borders you mentioned, and the Sega Genesis is 256x224 or 320x224. On these systems, the size in pixels of the part of the signal that fills the 4:3 frame is 280x240 (or 350x240 in the case of 320px mode on the Genesis), including some borders at the sides that most TVs cut off. The borders would be included in the video uploaded to YouTube, and these borders would still be smaller than the top and bottom borders on letterboxed videos that I see so often on the service.

480p is so-so, at least you have a full video pixel for each original, but the edges doesn't align so it's a bit jittery/blurry.

The nominal bandwidth of a composite signal is 4.2 MHz. The Nyquist rate for a 640-pixel-wide sampling of a 480i component signal is 135/22 = 6.136 MHz. So ideally, one would sample the NTSC signal at 640x240, line-double it to 480p, and let the encoder sort it out. But YouTube punted on this and allowed 60 fps only for high definition, causing flicker transparency effects in these classic games to be rendered incorrectly: either fully opaque or fully invisible.

NES for example is 256x224

I have programmed games for the NES, and I can assure you that the NTSC NES picture is 256x240. The Super NES is most commonly 256x224 with the black borders you mentioned, and the Sega Genesis is 256x224 or 320x224. On these systems, the size in pixels of the part of the signal that fills the 4:3 frame is 280x240 (or 350x240 in the case of 320px mode on the Genesis), including some borders at the sides that most TVs cut off. The borders would be included in the video uploaded to YouTube, and these borders would still be smaller than the top and bottom borders on letterboxed videos that I see so often on the service.

480p is so-so, at least you have a full video pixel for each original, but the edges doesn't align so it's a bit jittery/blurry.

The nominal bandwidth of a composite signal is 4.2 MHz. The Nyquist rate for a 640-pixel-wide sampling of a 480i component signal is 135/22 = 6.136 MHz. So ideally, one would sample the NTSC signal at 640x240, line-double it to 480p, and let the encoder sort it out. But YouTube punted on this and allowed 60 fps only for high definition, causing flicker transparency effects in these classic games to be rendered incorrectly: either fully opaque or fully invisible.

It's not like 1000 people are modding the files in 1000 ways.

Yet.

Virus authors figured out polymorphic code long ago. Now imagine one jackass making a program that shuffles the order of blocks of code in the hack so that you have 1000 files all different but with identical behavior. Thus blacklisting fails for wallhack and aimbot detection the same way it has been shown to fail for virus detection.

The NESdev wiki has a page dedicated to programming tricks with the unofficial opcodes, as well as a list of opcodes. Fogelman linked to the NESdev wiki from the emulator's readme.

The NESdev wiki has a page dedicated to programming tricks with the unofficial opcodes, as well as a list of opcodes. Fogelman linked to the NESdev wiki from the emulator's readme.

Where's the "technical" information?

There's plenty on NESdev Wiki.

There are about 30,000 cycles in each NES frame. Converting an 8-bit number from binary ($00-$FF) to three decimal digits (000-255) finishes within 84 cycles on a 6502. Converting a 16-bit number to five decimal digits takes a little longer (about 700 cycles using my routine). But you don't have to convert all the time; you can use a "dirty" system to convert when the score changes.

The NES had a Ricoh 2A03, which was a modified 6502 which REMOVED the BCD so they could put IO hardware registers in its place

No. They left the BCD in place, but just disabled it. Also, the BCD logic is fairly small, and in the middle of the CPU, where there would be no room to add extra features. The extra IO registers were put around the original 6502 core. Here's an explanation: http://forums.nesdev.com/viewt...

And here you can see the 2A03 chip, with the 6502 core sitting in the corner:
http://www.vgmpf.com/Wiki/inde...

I should know; I've programmed for that platform. But there are a few kinds of game that can't easily be adapted to it. One is games where you need to see farther away than 4 to 8 player heights. Those typically need a 3D GPU to draw a behind-the-player perspective.

*cough* Thwaite and Concentration Room */cough*

Seriously, though, I don't entirely disagree with you at one level. Once you have a core set of applications/libraries/kernels, then most of what you need is just incremental improvement (and driver support) and security fixes. Yet there's still a world of other applications that come and go and are worth paying some small amount of money for--mostly stuff that's either a niche in scope of users or in scope of how long that application/tool is necessary for some real world task.

Meanwhile, a core group of games doesn't keep most people too engaged indefinitely precisely because games having no underlying purpose, there's a much larger market of ideas that can be implemented and it's much more trivial to engage developers to do the work if they're paid than to leave it up to people who just want to try a shot at a game. Also, it allows for more large projects--large whole "free"/free/open source game development projects exist (Sauerbraten comes to mind), but they're obviously much, much fewer in number.

It's one of the reasons why as much as I support free/open code, I'm more lax about it when it comes to games. Although truth be told, I'm somewhat reversing on that point as more and more games target Unity3D or Monogames and yet *still* don't work on Linux because there's a lack of clear, high sales figures to account for the development costs--probably the hard part is all the testing. The above wouldn't be such a big deal if said games worked under WINE, but they most often don't.

In any case, once one starts thinking of just money, you really suck the fun out of it for potential gamers. It tends to color just about everything you do or would do. :/ Although I do still feel sympathy for indie developers who are trying to do their best on shoestring budgets.

*sigh* That's life.

*cough* Thwaite and Concentration Room */cough*

Seriously, though, I don't entirely disagree with you at one level. Once you have a core set of applications/libraries/kernels, then most of what you need is just incremental improvement (and driver support) and security fixes. Yet there's still a world of other applications that come and go and are worth paying some small amount of money for--mostly stuff that's either a niche in scope of users or in scope of how long that application/tool is necessary for some real world task.

Meanwhile, a core group of games doesn't keep most people too engaged indefinitely precisely because games having no underlying purpose, there's a much larger market of ideas that can be implemented and it's much more trivial to engage developers to do the work if they're paid than to leave it up to people who just want to try a shot at a game. Also, it allows for more large projects--large whole "free"/free/open source game development projects exist (Sauerbraten comes to mind), but they're obviously much, much fewer in number.

It's one of the reasons why as much as I support free/open code, I'm more lax about it when it comes to games. Although truth be told, I'm somewhat reversing on that point as more and more games target Unity3D or Monogames and yet *still* don't work on Linux because there's a lack of clear, high sales figures to account for the development costs--probably the hard part is all the testing. The above wouldn't be such a big deal if said games worked under WINE, but they most often don't.

In any case, once one starts thinking of just money, you really suck the fun out of it for potential gamers. It tends to color just about everything you do or would do. :/ Although I do still feel sympathy for indie developers who are trying to do their best on shoestring budgets.

*sigh* That's life.

Buggy is a generic term for not working (like crashing or showing a black screen and no idea what to do)

Some more obscure games might not work because they use unusual mappers (configurations of hardware on the circuit board). An NES emulator has to emulate not only the components inside the Control Deck and the ROM chips but also the "bank switching" components that select which part of the ROM to read. Or you might have a bad dump, either with incorrect ROM data or configured to use the wrong mapper. Do games with simpler mapper hardware like Thwaite and RHDE work?

I think one emulator worked nice after setting up keyboard or gamepad keys the ugly way and launching it from command line every time but I can't tell which it was.

Let me guess: Probably Mednafen or the old version of FCE Ultra. You see command-line emulators because the skill set to develop an emulator and the skill set to develop a graphical front-end aren't always inside the same person.

But at least one advantage of SDL under Linux over SDL under Windows (and other DirectInput wrappers) is that SDL under Linux handles the LT and RT buttons of an Xbox 360 controller as separate axes.

On linux you have a great variation between xorg, pulseaudio versions, plus shit like gcc and libc etc. so I'm sure some people have shit working in 2010 already and some other have crap in 2013.

There's variation among Windows versions as well, as you pointed out. I'm just glad FCEUX works well enough for me on Ubuntu 12.04 on a Dell Inspiron mini 1012 (Atom subnotebook) that I can take it with me and write NES programs while riding the bus to and from work.

The problem with any nondeterministic compiler is that it prevents use of diverse double-compiling, a method to detect the sort of compiler backdoor described by Ken Thompson in "Reflections on Trusting Trust". You'd have to bootstrap the compiler with nondeterminism turned off (and with GUIDs, timestamps, and multithreaded allocation of symbols for anonymous objects turned off too) in order for the DDC bootstrap construction to converge.

In any case, I've implemented a technique like this on the Nintendo Entertainment System. I wrote a preprocessor that shuffles the order of functions in the file, the order of opcodes within a function that don't depend on each other's results, and the order of global variables (or the order of fields in an object). One reason I implemented it was to use one variable as another's canary to make buffer overflows easier to detect in an assembly language program. The other is watermarking the binary so that I can tell who leaked a particular copy of the beta version to the public. If you're interested, you can find my shuffle tool in the source code of Concentration Room.

That is really good information to know.

Glad to be helpful.

I'm working on a video game now and will be finished in a few weeks

I too develop video games in my spare time; I have video of a work in progress.

But watch out for a few Slashdot regulars who feel that if a video game isn't developed by "the industry" (a well-known game company) or by "industry alumni" (people who have worked for a well-known game company for several years), it's almost certain to be unfun. And until very recently, Nintendo used having a dedicated office as a proxy for whether or not a developer is serious, which is why Robert Pelloni's home-based business couldn't get a DS devkit for his RPG Bob's Game. Nintendo has since loosened up on this requirement in response to the less closed Apple App Store, Google Play Store, and OUYA market; it now treats any lockable room as an office according to warioworld.com.

Playing video games makes you feel like you're experiencing life. Making video games makes it feel like you're delaying life until the game is out.

To me, making video games makes it feel like I'm creating life.

Anyway, I just thought of a major clarifications I need to make regarding what I wrote above. Virtual Console is Nintendo's official emulator on Wii, and it produces the same PlayChoice-looking RGB output as most PC-based emulators. So no, people won't really be able to tell that you're using an emulator if you do it right. A couple of the bigger problems I see are the following:

To compensate for these, pad your emulator's video to 280x240 or 560x480 pixels and then resize it to 640x480. For the gritty details, see Overscan and aspect ratio, Myths, and Mirroring.

That is really good information to know.

Glad to be helpful.

I'm working on a video game now and will be finished in a few weeks

I too develop video games in my spare time; I have video of a work in progress.

But watch out for a few Slashdot regulars who feel that if a video game isn't developed by "the industry" (a well-known game company) or by "industry alumni" (people who have worked for a well-known game company for several years), it's almost certain to be unfun. And until very recently, Nintendo used having a dedicated office as a proxy for whether or not a developer is serious, which is why Robert Pelloni's home-based business couldn't get a DS devkit for his RPG Bob's Game. Nintendo has since loosened up on this requirement in response to the less closed Apple App Store, Google Play Store, and OUYA market; it now treats any lockable room as an office according to warioworld.com.

Playing video games makes you feel like you're experiencing life. Making video games makes it feel like you're delaying life until the game is out.

To me, making video games makes it feel like I'm creating life.

Anyway, I just thought of a major clarifications I need to make regarding what I wrote above. Virtual Console is Nintendo's official emulator on Wii, and it produces the same PlayChoice-looking RGB output as most PC-based emulators. So no, people won't really be able to tell that you're using an emulator if you do it right. A couple of the bigger problems I see are the following:

To compensate for these, pad your emulator's video to 280x240 or 560x480 pixels and then resize it to 640x480. For the gritty details, see Overscan and aspect ratio, Myths, and Mirroring.

That is really good information to know.

Glad to be helpful.

I'm working on a video game now and will be finished in a few weeks

I too develop video games in my spare time; I have video of a work in progress.

But watch out for a few Slashdot regulars who feel that if a video game isn't developed by "the industry" (a well-known game company) or by "industry alumni" (people who have worked for a well-known game company for several years), it's almost certain to be unfun. And until very recently, Nintendo used having a dedicated office as a proxy for whether or not a developer is serious, which is why Robert Pelloni's home-based business couldn't get a DS devkit for his RPG Bob's Game. Nintendo has since loosened up on this requirement in response to the less closed Apple App Store, Google Play Store, and OUYA market; it now treats any lockable room as an office according to warioworld.com.

Playing video games makes you feel like you're experiencing life. Making video games makes it feel like you're delaying life until the game is out.

To me, making video games makes it feel like I'm creating life.

Anyway, I just thought of a major clarifications I need to make regarding what I wrote above. Virtual Console is Nintendo's official emulator on Wii, and it produces the same PlayChoice-looking RGB output as most PC-based emulators. So no, people won't really be able to tell that you're using an emulator if you do it right. A couple of the bigger problems I see are the following:

To compensate for these, pad your emulator's video to 280x240 or 560x480 pixels and then resize it to 640x480. For the gritty details, see Overscan and aspect ratio, Myths, and Mirroring.

The NES PPU takes shortcuts that produce characteristic artifacts in the composite signal. Some games, such as Blaster Master, rely on these artifacts to create more apparent colors than are actually there. Some emulators, such as Nestopia, have an NTSC filter that emulates these artifacts; others don't. Not emulating the artifacts makes your game look like it's being played on a PlayChoice or an emulator.

It's not an infringement to run homebrew games like Thwaite in an emulator. Nor is it an infringement to back up your own cartridges using a cart reader like this for the purpose of playing them in an emulator, so long as you do not distribute the dumps. (Assuming US law, 17 USC 117(a)(1).) But by the logic of the ruling in UMG v. MP3.com, it is an infringement to download a commercial game's ROM image through the Internet even if you own an authentic cartridge.

At 240p NTSC, a dot clock rate of 135/22 = 6.14 MHz produces square pixels. But actual consoles that ran at 240p tended to have non-square pixel aspect ratios, such as 12:7 (Atari 2600), 6:7 (Apple II, Atari 7800, IBM CGA), 3:4 (Commodore 64), 8:7 (ColecoVision, NES, SMS, most TG16 games, Super NES, and some Genesis games), 32:35 (other Genesis games, PlayStation), etc. See articles about NES overscan and PAR and other classic consoles' PAR. If I record one of these consoles with a DVD recorder or a capture card and then point-resize the recording, it won't look very good because each point-resize cell won't correspond to one pixel output by the console. Nor will conversions of live-action home movies taped with an SD camcorder look very good point-resized.

Besides, if the higher bitrate and point resize really help, YouTube should be doing them automatically. Or must people on an Internet plan whose uploads are capped per month rent a VPS, upload the video to the VPS, resize the video on the VPS, and then upload from the VPS to YouTube?

I offer NESdev Wiki as a compiled zipfile of the latest version of each article for offline use (see "Offline HTML version" at left). But then I admit that's in the tens of megabytes, not the tens of gigabytes. Wikipedia offers dumps as well.

The move to 64-bit CPUs is more akin to the SNES using the 65816 as opposed to the NES' modified 6502

If you know what a "PHK PLB" is,* you'll see how the 65816 is still very, very PAE. The 65816's address space is 24-bit, but a machine register can hold only a 16-bit pointer, so pointers to anything bigger than 64 KiB have to be manipulated in a 3-byte variable in the stack frame.** The 24-bit address space on the 65816 is more like the "segmentation" on an 8086. I'd amend your claim slightly: the move to 64-bit CPUs is more like the move from 65816, Z80, or 6809 class CPUs to the 68000 family.

PAE seems closer in concept to the myriad of NES mappers that still give emulator authors and preservationists headaches.

Call me guilty. I designed a mapper that subsumes NROM, AOROM, BNROM, CNROM, and UNROM in a fairly slick way, and a commercially released homebrew multicart uses it.

* 65816 mnemonics to push the code segment (K) and pop the data segment (B).
** The stack frame or "direct page" replaces 6502's zero page.

txs = 'this evidence suggests'

This obviously wouldn't work for 6502 assembly language programmers. They think txs means initialize stack pointer.

There is no in-house Ouya equivalent of Shigeru Miyamoto

When the PlayStation 2 first launched, the only first-party game was FantaVision, a cross between Klax and Missile Command that a reviewer on tetrisconcept.com called "a steaming pile of tech demo and nothing more." The PS2 had to rely on third-party games at launch, but it still won the fifth generation in sales. Does Apple develop its own games for the App Store or Mac App Store? It's been a long time since Brick Out on the Apple II Plus.

shocking incompetence at even creating their own private app store and reskinning Android for the Ouya

Incompetence in what way, specifically?

Or that a key element of their Big Plan to "return gaming to the TV" is to be a conduit for low-effort tablet/phone game ports which will never play well on a big screen with a real controller.

Never? A lot of these phone and tablet games already have to use an on-screen gamepad to implement gamepad-style controls on a flat sheet of glass, and players end up missing buttons with their thumbs because they can't feel the buttons' edges. Pixeline and the Jungle Treasure, for example, would play a lot better on an Ouya than it does on my Nexus 7. There's also a community of hobbyists still creating games for the NES (yes, the NES), and someone's creating an emulator wrapper analogous to Wii Virtual Console to let NES game developers sell their NES games in the Ouya Store.

that's hilariously fucking clever.

Some people disagreed when I showed them the story for what is now called Concentration Room.

My philosophy has always been, "Fuck 'em if they can't take a joke."

Could you imagine what the art world would look like today, if all (or any) of history's greatest artists had tempered their work based on what other people might think?

that's hilariously fucking clever.

Some people disagreed when I showed them the story for what is now called Concentration Room.

What's the point of homebrew on a modern console? I can see the point for retro consoles such as the Nintendo Entertainment System, where the limitations of ancient hardware are part of the challenge, much like constrained writing. But instead of homebrew on modern consoles, people could just make software for Windows or Linux, connect the PC to the HDTV through VGA or HDMI, and be done with it.

Especially interesting is the special circuitry that eliminated the need to blow air into the cartridges that plagued the original NES.

The need to blow air into cartridges on the original NES was a result of DRM.

No, seriously.

The NES console contained a chip called the CIC, which had to perform a handshake with a corresponding CIC on the cartridge, or else the system wouldn't boot (and you'd get that blinking red power LED). The purpose of this was to ensure that no one could manufacture NES cartridges without the approval of Nintendo of America. Unfortunately, it also made the boot process far more finicky; even the slightest amount of dirt would cause the handshake to fail and the system to repeatedly reset. (The fact that Nintendo used a weird ZIF-style connector rather than a standard card edge connector didn't help, either. This was done because they didn't want the NES to look like a standard game console, which had a bad reputation after the 1983 crash.)

http://nesdev.com/ Formerly nesdev.parodius.com This and Zophar are the who main places to go.

Doesn't the NES have a big fat expansion bus on the bottom?

There's a 48-pin connector (pinout) on the bottom of the NES-101. It was intended to combine the functions of the controller port on the front of the Famicom and the cable that comes out of the Famicom Disk System's system card. The connector was originally intended for the NES version of the FDS, but it never found use because Nintendo discovered that just as the FDS made it easier for Nintendo to make authentic copies of games to sell, it also made it easier for others to make infringing copies of games to sell. So there is no such port on the top-loading NES-101, nor on the Famicom. The configuration where a cable comes out of the side of the cartridge would probably be easier to manufacture in small quantities than a dongle that the NES sits on.

They don't accept evidence as verification

Get your evidence noticed by a member of the scholarly or mainstream media and they'll accept it. For example, MobyGames noticed PocketNES in the credits of Contra 4 for DS, making PocketNES notable.

Misinformation keeps reappearing on pages

How should Wikipedia tell the difference between evidence and misinformation?

So what if Impulse Tracker is "not notable", its file format is still used in the tracking scene

Then the page belongs on a wiki about the tracking scene, not on Wikipedia. For example, detailed information about the technical specifications of the Nintendo Entertainment System belongs on Nesdev wiki more than on Wikipedia. See Wikipedia:Alternative outlets on Wikipedia and The Wiki Rule on TV Tropes.

And if I want to reconstruct the page, I can't because the edit history is blocked out.

If you want to continue a deleted article on a specialized wiki, go to the deletion review page and ask an administrator to e-mail you a copy of the deleted article.

at the same time, pretty much all manufacturers have abandoned S-Video and SCART.

SCART never took off in my country, but I can still get S-Video inputs on most TVs. My Vizio VX32L has one on the left side. As I understand it, TV makers cut out SCART to make room for VGA to hook up netbooks and other non-HDMI PCs.

Since I have some classic game consoles that really could use something less shitty than composite

I take it you're referring to the Super NES and Nintendo 64. The NES directly generated its signal in the composite domain due to its hue-value palette arrangement. The PS2 and PS3 can play almost all PS1 games through a component cable, though some TVs can't take a 240p component signal like the one the PS2 makes when playing PS1 games.

Today's games are only 10,000 times bigger because of the higher-fidelity audio and higher-resolution graphics.

It's not just higher-resolution graphics; it's also more general graphics and more capacity for world simulation. On most consoles prior to the original PlayStation, all sprites needed to be pixel aligned, reducing the ability to show depth by drawing things bigger or smaller or to show direction by rotating the sprite cel. Super Mario Galaxy couldn't have been done on NES. There are also several reasons why a game like The Sims or Animal Crossing couldn't have been done on an NES either. See also other limitations of the NES.

In that case, nesdev.com needs you. We're trying to create a collection of low-color clip art and clip animations useful for displaying in a 256x224 pixel window, for projects on the NES or in an NES style on other platforms.

The revival is here. It is called NESdev.

Sounds interesting, but developing for the Nintendo Entertainment System is a bit outdated, don't you think? :)

I would truly like to see an assembly language revival though.

The revival is here. It is called NESdev. It's just not for making PC programs because the processes to be executed on a PC tend to be much more complex.

Now if we were talking about writing the PHP interpreter in assembler, I'd say you had a winner compromise.

You'd have to do so over and over for x86, x86-64, ARM, PowerPC, and other architectures on which PHP runs. That's why these interpreters are most often written in C, with occasional reference to the assembly language code that the compiler generates. Really the only time you have to handle assembly in a PC application is when you're implementing a just in time compiler, and it's becoming the fashion to let LLVM do that for you.