malducci

BillyHW, on Sat Mar 10, 2012 4:54 PM, said:

Could be a number of factors (main ram). DRAM was generally cheaper than SRAM for the same size in bytes (or whatever the 'word' definition is for the ram chip). NES had the option for both CHR-ROM (character rom or vrom) or CHR-RAM (character ram or vram). But the SMS was a VRAM only setup. That, and the 8x8 graphic cells took up twice as much memory as NES' 2bit format. Better compression techniques were needed to maintain and keep rom sizes down on the SMS. Having a large work space for caching/buffer decompressed sprites meant you could grab frames and such at just as fast rate as uncompressed - but with the benefit of compression. Otherwise normally you need a 'break' area where you can decompress and upload to vram. On the VDP side, SMS had twice the bit depth for tiles/sprites than NES - so it needed twice the vram size to hold the exact same amount of cells (the 16k listed).

In comparison, the Genesis has 64k of system ram and the SNES has 128k of system ram. But the PC-Engine stock only has 8k of system ram. It was originally designed with 32k (the 8k is mirrored to 32k and on the SGX this mirrior is actually populated with the additional 24k). This meant carts (hucards) that had no additional ram, had poor compression schemes (i.e. the trade off being speed over size) and coupled with small to average rom sizes - limited games graphically. Typical compession for hucard games are simple RLE varaints and/or just using 3bit planes (7 colors) for graphic cells. It wasn't until CD games for the PC-Engine, that provided more ram, that compression schemes got more advanced like LZSS variants.

Like someone else stated, computers are a separate beast. The larger amount of ram acts as rom would in a game system, abliet temporary storage. The PC-Engine CD system was a small computer in this way. Sure, there was a bios rom that houses a font and some math functions - but the CD ram is where everything held and run for that 'instance' or area or section. The original had 64k of ram 'cart' ram. That proved to be fairly limiting and was bumped up to 256k for SuperCD (and then later on to 2304K with the Arcade Card). SegaCD is similar, but the ram is divided between the main system and sub system, and neither CPU can access all of it (with the Genesis CPU having access to only a small amount at any one time).

Back to the NES; 2k+2k is what wiki lists? 2k system ram, 2k for tilemap and attribute/palette stuff (tilemap stuff). But it's pretty common to have CHR-RAM setup for games, which is an additional 8k of vram to hold tiles/sprites - so 2k+2k+8k. Not a lot of games increase the system ram, and IIRC out those that do - it's usually for battery backup save game data.

I never been to the Bookmans in Phoenix/Mesa, but there are three of the stores in Tucson. The eastside store is pretty decent. I've picked up quite a bit form there, including my Saturn. They have TG16 stuff, 2600, Coleco stuff etc. Just like stated previously, it's all about what people bring in/sell/trade and the timing of it all.

maiki, on Fri Jul 22, 2011 6:05 PM, said:

Dynamic tile usually refers to creating addition scrolling layers/effects. I'm not sure what else you mean by it. Moving leaves/grass like in Willow or the Japanese version of Contra? But yeah, the updating it almost always done in vblank. And it requires replacing specific tile data with new data. Whether that data is prerendered or realtime modification, is usually isn't relevant (though it's usually prerendered on such dedicated consoles). The SMS and NES are rather slow at updating a number of tiles in vblank. Neither have a DMA assist to transfer like the Genesis. But the NES has the option of using VROM, in which a mapper can update tiles very fast. It can even update ALL tiles and sprites in a matter of a few cpu cycles, instead of 30,000-100,000 cycles. It's specific to the mapper itself. Some NES games even swap out tiles midscreen, and can do it mid scanline too.

theloon, on Fri Jul 1, 2011 3:47 PM, said:

Might not be a matter of "Krikzz" going out of his way to protect them (Pier Solar team), but more a matter of respect in not supporting the special hardware setup that the homebrew developers specifically setup as a security device (among other security steps, from what I've been told), so they can actually sell the game. That is, assuming Everdrive even supports the backend hardware needed to begin with. I'm sure if other developers went out of their way to implement security devices in their homebrew works to be sold, even if they don't extend anything special beyond the stock addressing limit, then he would show the same kind of respect. At least, I would assume.

toptenmaterial, on Thu Jun 30, 2011 8:47 PM, said:

Oh, most definitely the tree scene. The tree slowly eating the kid alive; *nom nom nom nom nom*. I had reoccurring nightmares about that part. To this day, I have a thing about trees eating people alive >_> I remember this one time on LSD in my teenage youth, sitting in front of a tree.... oh wait, this is a video game forum. Nevermind