Questions about NES programming and architecture

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Thu Aug 27, 2020 2:54 pm

Which data line is used to transfer bytes from the disk to the CPU?

lidnariq
Posts: 9676
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Questions about NES programming and architecture

Post by lidnariq » Thu Aug 27, 2020 3:03 pm

All of them? Or else one on the external cable. Depending on what you mean.

2C33 gets a string of bits from the disk drive, and stacks them together in groups of 8 for the CPU. Or when the game is writing to the disk, the 2C33 takes groups of 8 from the CPU and emits a series of bits to the disk drive.

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Thu Aug 27, 2020 3:16 pm

My question was poorly phrased, I was asking where do the read bytes lie in the CPU memory map?

lidnariq
Posts: 9676
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Questions about NES programming and architecture

Post by lidnariq » Thu Aug 27, 2020 3:27 pm

The CPU can get the byte that was received by the 2C33 from the disk by reading from the address $4031... but I don't think including that clarifies anything.

Also, data to be written to disk use a different address.

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Questions about NES programming and architecture

Post by Bregalad » Thu Aug 27, 2020 3:29 pm

Useless, lumbering half-wits don't scare us.

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Thu Aug 27, 2020 4:28 pm

So the 2C33 reads 8 bits from the disk and converts it to a byte which is stored in the chip itself. Then each time the CPU reads a byte at address $4031, a new byte is read from the disk and stored in the shift register. Is that somewhat correct?

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Thu Aug 27, 2020 7:01 pm

Here's a new version of the diagram. I think it's better than the last one. I omitted some components such as the IRQ related hardware and the shift register.
Image

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Mon Aug 31, 2020 10:13 pm

Sorry for being stubborn but I have one more question that I forgot to ask :oops:
I was wondering, why didn't Nintendo let the NES CPU have access to the VRAM? Since big chuncks of the CPU address space go unused, wouldn't it have been possible to let the CPU write to NTRAM?

lidnariq
Posts: 9676
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Questions about NES programming and architecture

Post by lidnariq » Mon Aug 31, 2020 10:23 pm

Ultimately, cost.

It would have required more pins on the PPU, or more parts on the board, or a radically different design for how the CPU and PPU worked.

User avatar
tokumaru
Posts: 11859
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES programming and architecture

Post by tokumaru » Mon Aug 31, 2020 10:28 pm

Secamline wrote:
Mon Aug 31, 2020 10:13 pm
I was wondering, why didn't Nintendo let the NES CPU have access to the VRAM? Since big chuncks of the CPU address space go unused, wouldn't it have been possible to let the CPU write to NTRAM?
I'm not a hardware expert by any means, but I imagine that the reason is that when you have 2 processors connected to the same memory, you obviously can't let them both access it at the same time, so you have to share the access time between the two, possibly slowing down the PPU and/or CPU. I believe this was the case with the Commodore 64.

EDIT: I could be completely wrong, though... :mrgreen:

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Mon Aug 31, 2020 10:54 pm

lidnariq wrote:
Mon Aug 31, 2020 10:23 pm
Ultimately, cost.

It would have required more pins on the PPU, or more parts on the board, or a radically different design for how the CPU and PPU worked.
Maybe it would have been cheaper to use a single 10K or so RAM chip instead of two 2K and 8K chips? Actually I don't even know if 10K RAM chips do exist.
tokumaru wrote:
Mon Aug 31, 2020 10:28 pm
I'm not a hardware expert by any means, but I imagine that the reason is that when you have 2 processors connected to the same memory, you obviously can't let them both access it at the same time, so you have to share the access time between the two, possibly slowing down the PPU and/or CPU. I believe this was the case with the Commodore 64.

EDIT: I could be completely wrong, though... :mrgreen:
Perhaps they would have found a way to share access time between the two processing units. Although letting the CPU access VRAM only when a frame isn't being drawn onscreen would have been quite annoying.

lidnariq
Posts: 9676
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Questions about NES programming and architecture

Post by lidnariq » Mon Aug 31, 2020 11:30 pm

Secamline wrote:
Mon Aug 31, 2020 10:54 pm
Maybe it would have been cheaper to use a single 10K or so RAM chip instead of two 2K and 8K chips?
Not at the time the Famicom was designed: in 1982 each 2K SRAM was probably around 20USD. An 8K SRAM would have been more than 4 times as expensive. Using DRAMs would have been cheaper, but required a substantially different design.
Actually I don't even know if 10K RAM chips do exist.
no, RAMs are always a (power of 2) bits. And most of them are a (power of 4).
Perhaps they would have found a way to share access time between the two processing units.
The C64 and VIC-20 do this, and as a result are barely half the speed of the NES.
The Atari 7800 CPU is the same as the NES, but the video hardware steals time depending on how much is being drawn on each scanline.

User avatar
tokumaru
Posts: 11859
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES programming and architecture

Post by tokumaru » Mon Aug 31, 2020 11:31 pm

Secamline wrote:
Mon Aug 31, 2020 10:54 pm
Maybe it would have been cheaper to use a single 10K or so RAM chip instead of two 2K and 8K chips? Actually I don't even know if 10K RAM chips do exist.
Individual memory chips are always sized in powers-of-two. Also, I think that one reason for splitting the video memory between the console and the cartridge was to make the console itself cheaper.
Perhaps they would have found a way to share access time between the two processing units. Although letting the CPU access VRAM only when a frame isn't being drawn onscreen would have been quite annoying.
The time is normally shared in much finer slices than that... For example, if the memory can be read at 2MHz, each cycle serves one of 2 processing units clocked at 1MHz each. I have no idea how these interleaved memory accesses would work on the NES though, where the PPU is 3 times faster than the CPU.

User avatar
Secamline
Posts: 39
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline » Mon Aug 31, 2020 11:42 pm

Okay all in all it justifies the presence of two RAM chips. I expected such answers, I guess I'm simply frustrated by the fact that the 16 bit address range of both units isn't fully used haha.

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Questions about NES programming and architecture

Post by Bregalad » Tue Sep 01, 2020 12:52 am

Secamline wrote:
Mon Aug 31, 2020 10:13 pm
Sorry for being stubborn but I have one more question that I forgot to ask :oops:
You are not stubborn, simply curious and this is always appreciated here.
Secamline wrote:
Mon Aug 31, 2020 11:42 pm
I expected such answers, I guess I'm simply frustrated by the fact that the 16 bit address range of both units isn't fully used haha.
The address of the PPU is only 14 bits, and even then it's not fully used because $3000-$3FFF are unused (but accesses to $3F00-$3FFF are internally attributed to palettes).
Secamline wrote:
Mon Aug 31, 2020 10:13 pm
I was wondering, why didn't Nintendo let the NES CPU have access to the VRAM? Since big chuncks of the CPU address space go unused, wouldn't it have been possible to let the CPU write to NTRAM?
It's extremely complicated to respond to "why didn't" question, because many design choices with the FC/NES are obscure. Why didn't they allow more than 8 sprites per line, why didn't they allow the use of 4 different color #0 for BG palettes, why didn't they have the sprite-zero hit trigger an IRQ, or even simply allow for a scanline IRQ, why didn't they design the PAL NES so that its frame timing is compatible with it's NTSC counterpart (russian hackers managed to do it so why not Nintendo), etc, etc... The list can go on endlessly.

The fact is we have a piece of hardware, which was designed by a company who in 1983 was totally inexperimented at designing such a massively produced piece of hardware, and had only so far worked with some Donkey Kong arcade hardware. They wanted some trade-off between a computer and a video game console, in order to be able to sell games despite the video game crash that was raging in the US at the time; this led the hardware to be purposedly flexible by ginving full access to the PPU bus, allowing for further expansion in the future. The hardware is as it is, and we are here to use it as well as we can.

Now for answering the question, you have to remember that back then, ROM and RAM chips had an access time which determined how fast the CPU/PPU could be clocked. Fast chips were more expensive than slow chips. The PPU is already 3 times faster than the CPU, thus requiring much faster chips. If the access of both had to be multiplexed to a single memory bus, they would have to run even twice as fast, requiring even faster chips. This would have been possible, but very expensive. Alternatively the C64 runs at roughly the same speed as the NES but shares buss access between it's CPU and video chip, so the programs runs about twice as slow and the graphics are typically worse (assuming to tricky tricks are used); either the pixels are doubled in width or there is only monochrome graphics and no multiclor. The FC/NES can do multicolor in high resolution, a novely back then.
Useless, lumbering half-wits don't scare us.

Post Reply