7 ms·

On the cost-saving point, I always understood that the limited 4kb texture memory led to lots of games having really muddy, blurry textures. How much more would

• jchw 6y ago
  Well, I would guess twice as much and four times as much respectively. I mean RAM is cheap today but if you wanted 128GB of it today it’d still run you like, $700. I can’t pretend to know what this particular type of RAM cost back in the day, but given how relatively cutting edge the machine was I can only guess it was not particularly inexpensive...
  • DarknessFalls 6y ago
    They should have released a Nintendo 64 Plus sometime before the release of the Gamecube that would have doubled its RAM to provide hi-res textures.
    • TAForObvReasons 6y ago
      64DD was an expansion to the 64 https://en.wikipedia.org/wiki/64DD https://en.wikipedia.org/wiki/64DD . It was a commercial flop
      • echelon 6y ago
        It may have done better if Nintendo didn't take so long to develop and release it. I bought one on eBay, and it's a quirky device. It's essentially a glorified floppy drive with proprietary disks, and it makes loud, albeit amusing scanning noises. Every Nintendo console prior to the Wii had some sort of "expansion" or upgrade capability for future peripherals to be added. Hardware revisions took the place of this model.
      • Sevaris 6y ago
        Man, it sounds like it was in development hell. I wish we could get somebody to talk about what it was like developing the 64DD and what problems they ran into. Probably won't ever happen, but I can dream.
      • lumberingjack 6y ago
        We called it 64 cd we where kids so we where waiting every day for a n64 cd kit
    • duskwuff 6y ago
      That... doesn't work. The games which were released for the N64 were all designed to run within the limits of the hardware. Adding more memory later wouldn't give existing games higher resolution textures. Plus, adding more texture memory would have meant respinning the RCP silicon. That would have been a significant expense for marginal returns. Besides, Nintendo had already sold a memory upgrade in the form of the Expansion Pak. A second memory upgrade which couldn't even be installed into existing consoles would have been a very difficult sell, and could have soured customers on their future consoles. ("Why buy a Game Cube when they'll just release a Game Cube Plus next year?")
      • Polylactic_acid 6y ago
        It only works today because devs can update games post release and there is enough speed to use abstracted libraries rather than designing a game to the letter of the spec sheet
    • jerrysievert 6y ago
      they technically did. the https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expansion_Pak https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expans... raised main memory from 4mb to 8mb. it was required for one of the Zelda games, but also helped with graphics for some games if it was inserted. seemed to be a decent success.
      • opencl 6y ago
        DK64 required the expansion pak due to a bug (it was intended to work in either 4MB or 8MB modes and they couldn't fix a crashing bug in the 4MB version) and then Rare spent an obscene amount of money shipping an expansion pak with every copy of the game. That was probably responsible for a large fraction of the units shipped, with most of the rest accounted for by Zelda (which did not include the pak even though it was required).
        • rlanday 6y ago
          The truth of this claim is disputed: https://www.reddit.com/r/n64/comments/ft63zn/dk64_memory_leak/ https://www.reddit.com/r/n64/comments/ft63zn/dk64_memory_lea... The lead artist claims they’d always been planning to make use of it. There’s compelling evidence of a memory leak or similar issue since the released version of the game apparently crashes if you leave it running for some amount of time over 10 hours (which wasn’t usually a problem in practice except for very long speedruns until it was released on Wii U Virtual Console and people started using save states which don’t reset the timer the same way as turning the game off and on does).
          • monocasa 6y ago
            I've heard the the lead programmer confirm it, and I trust him more than the lead artist. I _think_ it was on the documentary clips shipped with Rare Replay, but I'm not 100% on that.
    • lumberingjack 6y ago
      they made a Expansion Pak allows 8MB of RAM. I just replaced mine it was bad I couldn't play perfect Dark with out it
    • deleted 6y ago
      [deleted]
    • robdachshund 6y ago
      They released the expansion pack which doubled the rdram and allowed for 480i
    • deleted 6y ago
      [deleted]
• Jasper_ 6y ago
  Texture memory (TMEM) is very special and fast, so it tends to be expensive stuff, at least back then, and it's balanced together with the rest of the architecture, like the bandwidth the RDP has, DMA copies from main mem -> TMEM, and so on. It would have changed quite a lot of the underlying architecture to increase it to 8KB, and might not have been worth it. You couldn't have increased texture resolution by simply increasing memory without changing a significant part of the architecture elsewhere (e.g. RDP fill rates). Most textures used during draws on the N64 don't even fill up the 4KB texture memory.
  • monocasa 6y ago
    It was a pretty bog standard 6T SRAM block. You can see a die shot here, and I don't think going to 8K would have been a huge deal. http://www.hotchips.org/wp-content/uploads/hc_archives/hc09/3_Tue/HC9.S10/HC9.10.2.pdf http://www.hotchips.org/wp-content/uploads/hc_archives/hc09/... That being said, going to a real cache rather than a block of manually managed memory I thin would have been the better design choice. Most textures didn't fill up the memory because of the practicalities of managing that memory. A double buffer scheme to load a block wile rendering from another one, the fact that you have to eat the whole cost of the full texture's load before you can render from it, etc.
• nwallin 6y ago
  Regarding simply having 8/16/32kB, the cache was integrated with the chip itself, it wasn't RAM that lived on the motherboard. So adding more would have required a larger chip. It was a multifaceted problem, and was ultimately a design flaw/oversight rather than someone saying "I think 4kB is enough memory to store all the textures". The problem is less that the cache was small, it's more that Nintendo's plans for how awesome RDRAM and a unified memory architecture didn't pan out. Problem #1: There was no dedicated video memory. All RAM on the N64 was shared RAM. So framerates tanked if you didn't have most of your stuff in cache. Keep in mind the framebuffer also lived in this unified memory area, so the video chip was already very noisy on the memory bus. Problem #2: The unified shared system RAM was RDRAM, not SDRAM. And the latency on RDRAM is absolutely terrible. So the already expensive cost of using RAM was compounded. If the N64 did what the playstation and saturn did and just have dedicated video/system RAM, and made this RAM relatively low latency SDRAM instead of the relatively high latency RDRAM, this 4kB limitation wouldn't have mattered.
  • joneholland 6y ago
    If I recall correctly, later games actually packed higher throughout ram into the cartridges to work around the latency of the onboard ram.
    • to11mtm 6y ago
      Not quite. Larger cartridges (i.e. 32/64MByte) gave them space in ROM to play with tiled textures. Usually this -did- also involve use of the 4MB RDRAM upgrade.
    • nwallin 6y ago
      They used uncompressed textures on the cart, in ROM. (not on-cart RAM) Normally a game would store compressed textures in ROM, and decompress them into RAM. It was a solution with significant tradeoffs though. #1 It was still slower than the cache. #2 You were still using the single shared bus. You would still be using cycles which contribute to data stalls elsewhere in the system. #3 ROM was expensive. N64 games were typically in the ballpark of $10 more expensive than Playstation or Saturn games because of the manufacturing expense. #4 I don't fully understand why, but it was all or nothing. You couldn't have uncompressed textures in ROM but also gain the benefit of the cache. Maybe the cache invalidation was poor or something. I wish I knew more. Later games were more likely to go this route because ROM was cheaper. (Moore's Law and all that)
• Athas 6y ago
  Interestingly, I feel the opposite. The inferior texture memory means that many games just used Gouraud shading (or sprites) instead, which was quite clean. At the time, I felt that N64 games looked cleaner than PS games, mostly because of the textures, and I also think they have aged (slightly) better. At least those games that didn't aim for realism - Super Mario 64 and Ocarina of Time are still quite playable, while the looks of GoldenEye 007 are probably more of a hurdle.
  • bartread 6y ago
    I agree. I remember thinking at the time that N64 games tended to look significantly better than PS1 games simply because the N64 was capable of shading/smoothing and the PS1 wasn't. The pixellated PS1 textures are a big part of the reason many games on the system have aged so poorly even as compared to the 8 and 16-bit sprite-based consoles of the 1980s and early 1990s[1]. [1] There are other factors of course: SD TV resolutions are low so when you hook a 32-bit 90s console up to a large modern flat panel HD or 4K TV with games running at a resolution of around 320 x 240 the pixels are MASSIVE. In addition polygon counts are low, draw distances are often low, and so it goes on. Depending on your setup games can look considerably worse on a modern TV than they would have done on more modestly sized 90s CRT screens. To be clear I'm talking about SD TVs here, not CRT monitors, which could support much higher resolutions and would therefore suffer from some of the same problems as modern flat panels in terms of making the graphics look too sharp.