Inside the Famicom | 03: The Memory Map
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2024
- Welcome to the third video in my multi-part series on the Famicom. In this video, we'll take continue our exploration of the CPU and mainboard by talking about how the Famicom and NES uses the memory map to communicate with other chips.
Links Referenced in this Video:
NESdev Wiki CPU Memory Map - www.nesdev.org...
NESdev Wiki 2A03 Register Map - www.nesdev.org...
Past Episodes:
Episode 1: The Design of a Legend - • Inside the Famicom | 0...
Episode 2: The 6502 CPU - • Inside the Famicom | 0...
Correction:
3:39 I was wrong here - it’s the width of the chip’s internal data bus that determines the chip’s “bitness”, not it’s data pins
For an example of how a detailed Memory Map helps programmers, give Mapping The Atari a read. 😌
I've flipped through it online, but will need to give it a more thorough read 👍
External data bus doesn't determine the "bits" of the CPU. For example, 8088 has also an 8-bit external data bus. And an 80386SX has 16bit. It's the internal data bus width that determines the "bits."
👍 Thanks, I’ve added a correction to that spot of the video
Wonderful. :) Do something cool? Of course now I play NES, SNES... it's a lot more fun that the modern gaming industry can't offer me
At 0:07 - 0:12 the symbol on the right chip looks like the Mitsubishi logo, is there any connection?
Yep, Mitsubishi manufactured that particular character ROM chip. Nintendo used ROM chips from a few companies, including Toshiba, Sharp, and others.
3:40 This isn't strictly true. Based on the parallel input it's true for the NES and this implementation of a chip. Maybe I can learn something here, but I thought that it was the register size or instruction size that made the architecture 8bit since you could ostensibly have Serial communication that would not be a phenotype of the chip itself.
Someone else commented on that as well, and I believe that person was correct - it’s the internal data bus width that determines this (as opposed to the external data bus). The register size is sometimes reflective of that, but it’s not necessarily consistent. I appreciate the discussion, though - and I learned something as a result
11:11 "that 3 bit address space being repeated 1024 times" can you describe the implication or result of this address space being "repeated". I'm not sure what you meant by that. Thanks.
The 10 unconnected bits make 1024 (2^10) different address combinations, or in other words you can access those 8 bytes at 1024 different locations.
The PPU uses 8 bytes of the address space for communication, since there's only 3 address lines connected - these are addresses $2000 - $2007. But since the chip select signal is activated with the 13th address bit, all addresses within that entire 8KB range ($2000 - $3FFF) address the PPU. The result is that those 8 bytes of addresses 'repeat' 1,024 times. In other words, if the CPU reads address $2003, it'll get the same result as reading address $200B, $2013, $201B, etc. all the way up to $3FFB. From the CPU's perspective, it would be requesting data on different addresses - but from the PPU's perspective, it all looks like the same address since it's only connected to the lower 3 bits of the address bus.
Writing a byte to the register mapped to memory location $2000 is the same as writing it to $2008... or location $2010, or $2018, or $2020... and so on...
Then, the register mapped to memory location $2001 is also mapped at location $2009, $2011, $2019, $2021, and so on... Its kinda complicated, just easier to just use $2000 to $2007.
Other way to describe it is understanding that PPU has 8 registers numbered 0 to 7, then you take the binary address in the range $2000 - $2FFFF and consider only and just only the lower 3 bits, so $2000, $2008, $2010, etc are all the same...
@@whatskenmaking OK I think I understand, there a whole load of memory rendered useless because reasons involving pins.
There is redundant memory is what I seeing here and the PPU does not have access to it either.
That's what it essentially amounts to - the rest of that 8KB address space tends to just repeat the same target addresses so they're not usable for anything else. When I get to the episode on cartridges, we'll discuss how they work around the address space limitations with mapper chips.
Great explanation!! Liked and Subscribed!
You inspired me to get a lot of 6 old Famicoms from Japan and to refurbish them. Currently replacing the RF modules with custom PCBs to get composite video out. Can't wait for that PPU episode. I'm looking into RGB mods and all that PPU stuff is pretty WILD
Nice! You can get decent composite video with just a transistor and a couple of resistors - that's how I modded the video in my first Famicom years ago. I have an Atari mod video that walks through the mechanics of how it works, but on a VCS instead of a Famicom. Btw, if you have any FCs that you deem unrepairable, set them aside... in the last episode of the series, I'll show you an alternative for what to do with them 😊
@@whatskenmaking I saw that! I was considering doing a simpler mod but then decided to replace the entire RF module. Solves the issue of the weird polarity power supply as well. And it takes care of the old caps. And it ends up being a bit cleaner. I'm hoping none Famicoms are busted but also happy to hear there is a future for them even if they are!
(@3:03) To read the contents of $053F, you’d need an LDA $053F; STA $053F puts a byte into memory (specifically, from the Accumulator.)
Ah, right - nice catch!
you must finish this series famicom materials!
fantastic video, I always wanted to see such a series, thank you! : ) I hope you can explore DMA as well
even though DMA is more interesting on SNES cmpared to nes system
Subbed this is something I tried to learn on Nintendo ages nerdy nights write up 14 years ago , you have made it simple thanks