I've had this crazy idea of "could an NES game cartridge be removable without the game crashing?". I realize the space issue would be huge, since there would only be a bit above 1.5k of code that could be housed by the RAM, while still leaving some zero page and stack space for variables. But the biggest issue is what to do with the display? With no CIRAM wiring connected and no tiles, the only thing I could imagine that would work would be to "go Atari 2600" and draw "pixels" after having gone through all the trouble of syncing up the CPU and the PPU. Now drawing using palette changes would not work because after every write, the PPU address is auto-incremented to point to the next palette entry, which would produce unwanted "pixels". On top of that, the time it takes to write the next color to the PPU would be too much to have acceptable pixel resolution this way (the PPU having produced too many pixels by the time a new color is written). But maybe it could be simplified by using grayscale mode and the color emphasis bits for a basic 3-bit RGB palette (whose brightness could be slightly changed by the underlying palette entry, $x0).Would it be possible to have something as simple as Pong working this way?

The good side of not being able to use VRAM for graphics is that you get an extra 2K for the game state and data, leaving most of the CPU RAM free for actual code.

That being said, I don't think you can pull off any kind of usable graphics when rendering is off. Manipulating the PPU address is way too slow, and even if you used 3 settings of emphasis bits (one in each of A, X and Y), the 4 cycles needed for a PPU write correspond to 12 pixels, so the horizontal resolution would be limited to 21 or so pixels. And each line would take 63 bytes of precious RAM.

Yeah, I really can't think of a way to do graphics for games other than Simon or others that can be similarly blocky.

It's also not no graphics. You can still do blocky sprites. You can still do raster effects. (Which raster effects you can can fit in will be limited due to paucity of RAM).

In practice, I've noticed that floating pins on the NES cart connector (meaning specifically NTRAM/CE and NTRAMA10) very loosely capacitively couple with whatever's around, which in practice means "coupling with mains frequency". So a small portion of the screen will actually get valid data from RAM... See ccovell's Theremin.

(The blocky sprite tiles that you do get, when NTRAM/CE is floating high, will look like:

Code:

wxyz2tttwxyz2tt3wxyz2t3twxyz2t33wxyz23ttwxyz23t3wxyz233twxyz2333

where "t"=transparent, "2" and "3"=palette entries 2 and 3, and "wxyz" = the lower 4 bits of the sprite #, in binary, where set bits are color 3 and clear bits are transparent.

other than maybe disabling/removing the CIC so that all console variants start off equally capable.

This, and that the modification is so popular that i estimate that a fair percentage (at least in EU) have been modified. Second hand vendors seem to sell them modified oftener than not. I've modified my two PAL units and have done the modification to two other units for other people. I should probably get an unmodified unit before they run out so i don't forget what blinking gray looks like.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum