It is currently Tue Sep 18, 2018 9:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Tue Oct 10, 2017 2:46 pm 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 317
Location: Colorado USA
I know how memory use works through the Software level, but I want to understand it through the hardware level. What I am mainly asking is how the memory chip on the NES for example, knows that when the address bus is at $037D, it knows “Hey! That’s me!” I just assume that the chip has a predetermined address range. But if that’s the case, then why is it that when I go on eBay to buy EPROMs, it never mentions what the address range for it is?


Top
 Profile  
 
PostPosted: Tue Oct 10, 2017 3:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7519
Location: Seattle
Chip enables.

For example, in the NES, there's a part called a "74139" that is how the NES divides its memory map into multiple regions.

Half of it takes two signals from the 2A03 ("M2" and "A15") and creates two signals ("actively addressing memory from $0000-$7FFF" and "actively addressing memory from $8000-$FFFF").

The other half of it then takes the first one of those, and two more signals from the 2A03 ("A14" and "A13") and creates two more signals ("actively addressing memory from $0000-$1FFF", which is connected to the CPU's RAM; and "actively addressing memory from $2000-$3FFF", which is connected to the PPU)

The RAM and PPU each have a single "chip enable" which use the signals generated above to be told when they should listen and/or talk.



In contrast, in the Atari 2600, there's no such part. Each of the individual parts on the board instead have multiple chip enables that allow for some rudimentary decoding.

Both the TIA and RIOT have two chip enables; the TIA only responds to addresses where "A12" and "A7" are low, the RIOT only responds to addresses where "A12" is low and "A7" is high, and the cartridge ROM is expected to only respond to addresses where "A12" is high. But this is by design, not an intrinsic property. They didn't have to be connected to those specific addresses (although there's good reasons they made these choices)


Top
 Profile  
 
PostPosted: Tue Oct 10, 2017 4:24 pm 
Online
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4076
There's the Chip Select pin, then some series of logic determines what value goes to that pin.

So let's say you had RAM at 0000-1FFF as on the NES (mirrored to fill that address range)
You'd want CHIP SELECT to be set if highest 3 address bits are all 0. That's 8000, 4000, 2000. So you run whatever series of logic gates you need to make CHIP SELECT be set when ADDRESS 15, ADDRESS 14, ADDRESS 13 are all zero. So that's !(A15 & A14 & A13).

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Tue Oct 10, 2017 4:53 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6801
Location: Canada
DementedPurple wrote:
how the memory chip on the NES for example, knows that when the address bus is at $037D...

Most of the address bus is directly connected to the chip.

For example, a 32k ROM has 15 address pins (2 ^ 15 = 32768). So, internally the ROM's address space is just $0000-7FFF. There's no 16th bit to get to $8000.

The NES CPU has a 64k address bus, so this is 16 lines. We just connect the first 15 straight to the chip, and then that 16th one goes to the chip enable*.

DementedPurple wrote:
...it knows “Hey! That’s me!”

So that 16th line from the NEW CPU address bus is not used as an address line on the chip, but instead used to enable/disable it. On the NES CPU side that bit selects between $0000-$7FFF and $8000-FFFF, but where it's connected to the chip is just means off/on.

DementedPurple wrote:
...why is it that when I go on eBay to buy EPROMs, it never mentions what the address range for it is?

The ROM doesn't need to know where it's mapped. All it sees is 1s and 0s on its own address pins.


(* the 16th line isn't connected directly, but more or less this is what's happening. See /ROMSEL.)


Top
 Profile  
 
PostPosted: Tue Oct 10, 2017 9:20 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10806
Location: Rio de Janeiro - Brazil
It's not really the mapped chips/devices that go "hey, that's me!", it's actually the console/computer that goes "hey, you!". This is called "address decoding". In order to activate a specific chip or device, the system has to use the state of the address lines to create an enable signal for the chip/device. How the address lines (and possibly other signals) are combined in order to form the various enable signals is what determines what gets mapped where.

If you're wondering about mirroring, it's just a side effect of partial address decoding. For example, on the NES, the 8 PPU ports ($2000-$2007) are mirrored all the way up to $3FFF (e.g. writing to $3FFF is the same as writing to $2007). This happens because when deciding whether to redirect accesses to the PPU, the NES isn't watching the 13 address lines it would take to have the PPU respond only to $2000-$2007, it's actually watching only 3 address lines, which leaves a bunch of "don't care" bits in the address, causing a bunch of different addresses to be interpreted as the same thing.

To have the PPU respond only to $2000-$2007 without mirroring, the NES would have to watch for addresses with the following format: 00100000 00000PPP (P = PPU port)

That'd be a waste of resources, so it's simpler and cheaper to just watch the 3 highest address lines instead: 001***** *****PPP (* = don't care, P = PPU port). This means that the value of the * bits aren't taken into consideration when deciding whether to access the PPU, so addresses that only differ by the "don't care" bits will appear to be the same to the system.


Top
 Profile  
 
PostPosted: Mon Oct 30, 2017 10:02 am 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 317
Location: Colorado USA
But that would mean chips have a pre determined chip number through chip select, right? I should probably ask about i2c mapping on the raspberry pi. Could you explain how I would put the individual chips in the mapping range?


Top
 Profile  
 
PostPosted: Mon Oct 30, 2017 10:25 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1060
Location: Minneapolis, MN
DementedPurple wrote:
But that would mean chips have a pre determined chip number through chip select, right? I should probably ask about i2c mapping on the raspberry pi. Could you explain how I would put the individual chips in the mapping range?

An I2C bus is not the same as a memory bus with potentially many individually-selected (via chip select) devices.
A device on an I2C bus has an address that is often, but not necessarily, encoded to it by a series of pull-up/down resistors on its pins. These pins are read by the chip and provide it a "slave address". When an I2C command starts on the I2C bus the first byte is the device address and R/W. If the I2C device recognizes this address it will respond by ACKnowledge (pulling the bus low) in the 9th bus clock cycle. Otherwise, it stays silent.


Top
 Profile  
 
PostPosted: Wed Jan 31, 2018 8:42 pm 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 317
Location: Colorado USA
what happens when you have 1 bit connected to the chip select, and other bits connected to other chip selects, and then you set both of them. Does it send that value to both addresses?


Top
 Profile  
 
PostPosted: Wed Jan 31, 2018 10:11 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7519
Location: Seattle
You usually don't have direct control over the chip select pins, and there is no way in software to enable multiple at the same time. (conspicuous counterexample: ZX80's keyboard)

If you do have a system where multiple devices can be enabled simultaneously, behavior depends on what they are and context. For example, in the SNES, there are two address buses, and two different devices can be enabled at the same time according to these two buses. They share the data bus; this is how it implements DMA transfers.


Top
 Profile  
 
PostPosted: Wed Jan 31, 2018 10:50 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10806
Location: Rio de Janeiro - Brazil
You definitely wouldn't want multiple memory chips outputting data to the same bus, but there are cases when multiple chips receive the same data. If I'm not mistaken, the Master System has some memory mapped registers in the RAM area, and whenever you write data there, it gets written to RAM in addition to being sent to whatever hardware answers to writes to those locations. This means that you can read back values written to those locations as if you were reading from the memory-mapped register, but you're in fact just reading from RAM.

On the NES we have mappers with bus conflicts, because PRG-ROM is normally enabled on any access to $8000-$FFFF, not just reads, and these mappers are wired to receive bits from the data bus only on writes to $8000-$FFFF. When a write to $8000-$FFFF happens, the ROM is enabled and outputting a value to the data bus, the CPU is also outputting a value to the data bus (the value should be the same to prevent conflicts) and the mapper chip's input is enabled so it can read the value that's on the bus. So yeah, there are cases when multiple devices respond to the same memory access in some way, but as long as this doesn't result in bus conflicts, it should be fine.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 2 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group