It is currently Mon Jun 17, 2019 10:21 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Jan 24, 2019 8:03 am 
Offline

Joined: Thu Jan 24, 2019 7:53 am
Posts: 6
Hello everyone! Longtime lurker, first time post.

I am working on reverse engineering a SNES cartridge as a personal project to learn a bit more about how the system works. For the most part, I understand how the cartridges work, with the exception of the MAD-1 chip/74139 seen on earlier boards. This chip should be a decoder to tell when the SNES wants to work with the ROM or the SRAM, and enable the corresponding chip. I am confused though- it seems that the connector pinout has pin 49 for ROM /OE (/CART) and pin 54 for RAM /OE (/WR). These lines should both be high and then dropped when the system wants to read from the respective chip. What is the purpose of the decoder chip then? I understand it's use for games with multiple ROM, but for games without it, I can't understand the purpose, especially since it's connected to RAM /CE, which I thought that p54 was dedicated to doing.

From romlabs, I also saw that some of the pins of the MAD-1 are connected to A21, A22- what is the reason for this? Are those connections related to the operation of the decoder? Is the SNES sending hardware requests on those lines?

Thanks for all the help and knowledge nested on these forums!


Last edited by VIP Quality Post on Thu Jan 24, 2019 9:31 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 8:23 am 
Offline

Joined: Thu Jan 24, 2019 7:53 am
Posts: 6
As a note, I see a lot of this diagram passed around, originating from warosu, some online board Image
The connections for the 74139 kind of make sense, with /WR used to enable writes on the RAM, and /RD for /OE on ROM and RAM. However, I've seen some users here say that this diagram isn't necessarily correct, so I'm not sure if this is a good resource to use. I'm also confused by the stray caps littered around the board- are these for buffering the power to the chips when the system is reset/powered off? What other purpose do they serve? With some of them at 70nF, I can't imagine they're particularly useful.


Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 8:32 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21440
Location: NE Indiana, USA (NTSC)
How I interpret Game Pak slot pin descriptions from Fullsnes:

  • Pin 49 is ROM select. This is low when the address bus is pointed anywhere in the upper half of banks $00-$3F and $80-$BF and all of banks $40-$7D and $C0-$FF.
  • Pin 54 is write. This is low when the CPU is writing anywhere, including to peripherals in conventionally "ROM" space and (I think) internal WRAM.
  • There is no pin dedicated to enabling cartridge RAM, which in HiROM games is conventionally located at $3x6000-$3x7FFF and in LoROM games is conventionally in bank $70.

Yes, the "bypass capacitors" or "decoupling capacitors" are for stripping AC transients out of the DC power supply. You usually see 100 nF of decoupling near each IC's +5V pin and tens to a few hundred μF near the edge connector.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 8:42 am 
Offline

Joined: Thu Jan 24, 2019 7:53 am
Posts: 6
Okay, so since there is no pin dedicated to enabling cartridge RAM, we use the decoder to enable RAM when pointing at external WRAM space, and this is done on A21 and A22?

Also, what do you mean when writing to 'conventionally "ROM" space'- are you referring to the cartridge, or the ROM itself? I was under the impression there were no writable areas in ROM- hence read-only.

Thanks for the tip on the capacitors!


Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 8:46 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21440
Location: NE Indiana, USA (NTSC)
The circuit generating the ROM select signal at the cartridge edge doesn't know whether the memory behind that address is ROM, RAM, or MMIO. Take the SNES PowerPak for example: it emulates ROM using RAM by first copying an executable from the CF card into RAM. In addition, some coprocessors are mapped in parts of ROM space.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 9:17 am 
Offline

Joined: Thu Jan 24, 2019 7:53 am
Posts: 6
I understand the purpose of the chip now. I think I just had some core misunderstandings on the edge connector roles.

Regarding the role of specific address pins in enabling/disabling the ROM and RAM, do you have any ideas about why those pins (A21/A22) are used for controlling the decoder?

Additionally, I remembered seeing this image a while ago which was on a short tutorial, so no explanation was given as to why they were tying the ROM /CE to A0 (or both demux as well, for that matter). Does that have to do with the fixed top of the stack pointer (https://youtu.be/fWqBmmPQP40?t=399) since A0 will always be low? Similarly, can a trend be found between wanting to read/write data to the RAM/ROM and toggling A21/A22?


Last edited by VIP Quality Post on Thu Jan 24, 2019 9:22 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 9:17 am 
Offline

Joined: Thu Jan 24, 2019 7:53 am
Posts: 6
Forgot image: Image


Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 11:51 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
VIP Quality Post wrote:
Regarding the role of specific address pins in enabling/disabling the ROM and RAM, do you have any ideas about why those pins (A21/A22) are used for controlling the decoder?
Different boards used different conventions for where one could address ROM or RAM. The specific address lines correspond to how the PCB is laid out, and where the ROM is programmed to expect to find ROM and RAM.

There's nothing magical specifically about A21 and A22.

VIP Quality Post wrote:
so no explanation was given as to why they were tying the ROM /CE to A0
That is not what's depicted...

Quote:
(or both demux as well, for that matter).
The 27C322 always has a 16-bit wide data bus. The SNES cannot use this, it only has an 8-bit wide data bus.

The 74'157 multiplexers take the 16 bits out of the ROM and selects one half or the other for the SNES, according to A0.


Top
 Profile  
 
PostPosted: Thu Apr 25, 2019 7:26 am 
Offline

Joined: Sat May 26, 2018 12:30 pm
Posts: 16
I still don't fully understand how a 74139 Demux works for SNES carts. Can someone ELI5 it for me?

So I think I understand the theory behind a chip like the 74139 (it basically allows the SNES to flip between memory banks since the SNES CPU can only "talk" to 8-bits worth of memory at a time, because even though the CPU is 16-bit, the bus is only 8-bit), but reading the datasheets I'm not quite clear how it works.

I'm using this datasheet for reference: http://www.msarnoff.org/chipdb/74139

Why are there 2 separate Enables and Outputs? Is that basically to just to cover bi-directional pathing? Why would you need round-trip demuxing - wouldn't any operation done through the de-muxer one way remain "de-muxed" when that operation was "returned" back to its origin?

Thanks


Top
 Profile  
 
PostPosted: Fri Apr 26, 2019 6:19 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 915
It's easier to understand if you are aware that posts about 74139 are unrelated to those about 74157.


Top
 Profile  
 
PostPosted: Fri Apr 26, 2019 7:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
illuminerdi wrote:
I still don't fully understand how a 74139 Demux works for SNES carts. Can someone ELI5 it for me?
Let's first define a "multiplexer" before we can describe this part.

A "multiplexer" is a thing that gives one specific output out of many inputs depending on some other inputs. It's kind of like those multi-color pens where you push down on one of the springs, and the tip that comes out corresponds to that one.

Now, in an electrical circuit, you don't physically press a button to get a specific color of ink, but it's a similar idea. Instead, each "selector" connected divides the possible inputs into two halves (because the input can be high or low, nothing else is allowed).

A "demultiplexer" is kind of the opposite. Instead of getting one thing out, you instead put one thing in, and it puts it in the right place. Think of one of those robots that sorts candy by color.

So, specifically in the case of 74'139: You put one thing in (the "enable" signal), you have two things that pick where it comes out (sometimes called "A" and "B", or "A0" and "A1"), and a copy of the "enable signal" appears on the output pin that matches the two pickers. What about the other outputs? Specifically in the case of the 74'139, they stay "high", because that's how they chose to design the part.

Quote:
Why are there 2 separate Enables and Outputs?
Because there are entirely independent demultiplexers inside.


Top
 Profile  
 
PostPosted: Mon Apr 29, 2019 7:28 am 
Offline

Joined: Sat May 26, 2018 12:30 pm
Posts: 16
nocash wrote:
It's easier to understand if you are aware that posts about 74139 are unrelated to those about 74157.


Well they're two sides of the same coin in the sense that one is a multiplexer and the other is a demultiplexer.


Top
 Profile  
 
PostPosted: Mon Apr 29, 2019 10:24 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 915
There you have found the best and most plausible way to derail things and produce more confusion. Are you doing that intentionally? Multiplexers and demultiplexers are - despite of their similar naming - completely different things. They aren't the same, and they aren't oppostites of each other. They are just different, completely unrelated. And the different ways how they are wired up in the schematics is making them even more different.

Your conclusion about the 8bit databus not being a 16bit databus sounds right, but that applies to the 2nd schematic (the one with the 74157 chips or 74257 or whatever they are called). And that's an extremly rare corner case - pretty much nobody is using that kind of 16bit-only memory chips in snes carts, so best forget about that.

The 1st schematic (with 74139) is not related to 8bit databus issues, the 74139 doesn't even connect to the databus at all. The main purpose of the schematic is to generate different chip enable signals for ROM or SRAM (or neither one) depending on different memory addresses.
The ROM enable should be fairly obvious, right? The SRAM enable is a bit more tricky, it's (mis-)using the second half of the 74139 to merge in the reset signal and another address line, and then somehow passing the final output through the transistor. I don't fully understand that part, but the overall purpose is clearly generating the SRAM enable signal.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Mon Apr 29, 2019 10:29 am 
Offline

Joined: Sat May 26, 2018 12:30 pm
Posts: 16
lidnariq wrote:
A "demultiplexer" is kind of the opposite. Instead of getting one thing out, you instead put one thing in, and it puts it in the right place. Think of one of those robots that sorts candy by color.

Because there are entirely independent demultiplexers inside.


Thank you for the explanation - I'm actually reasonably familiar with the functionality of mux/demux as a concept (I've worked in networking and telecommunications for much of my professional life) :)

I think my real problem is that I don't understand SNES memory addressing well enough. I'm reading through https://en.wikibooks.org/wiki/Super_NES ... memory_map and it doesn't quite make sense. If banks are notated as $00-$FF, that's still only an 8-bit bitmask, so selecting any of those banks requires 8 bits and thus can be done without needing to multiplex.

So in the HiROM memory model, since ROM data is mapped to $00 80 00 - $FF FF FF , if I have a sprite located in my ROM at $FF 00 in, say on page $80 DD and code data located at $F1 00 on page $80 CC, I first need to bankswitch to FF then send tell the CPU to read the contents of memory $00 80 DD, which gets me the sprite I want.

I can't get the code block that I want though, because attempting to read $00 80 CC would get me the contents of the ROM chip at $FF 00 80 CC.

So I have to copy the sprite data somewhere, bankswitch to $F1, then read $00 80 CC which gets me the code I want, and I can then execute this code on my sprite data since I stored it into a space that the CPU can read without needing to bankswitch back to the original ROM location of the sprite, thus allowing me to perform a code operation on sprite data located in separate memory bank that exceeds the directly addressable space that can be mapped at any given time?

So either I just figured out SNES memory mapping and bankswitching in a nutshell or I'm totally off base?


Top
 Profile  
 
PostPosted: Mon Apr 29, 2019 10:52 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4105
Location: A world gone mad
illuminerdi wrote:
I think my real problem is that I don't understand SNES memory addressing well enough. I'm reading through https://en.wikibooks.org/wiki/Super_NES ... memory_map and it doesn't quite make sense. If banks are notated as $00-$FF, that's still only an 8-bit bitmask, so selecting any of those banks requires 8 bits and thus can be done without needing to multiplex.

That page is terrible. I don't know what it is with people and the SNES memory map -- there have been I think at least 10 different "attempts" to describe it, and all of them are just downright terrible (many are too verbose because they're trying to cover too many things at once).

For a better understanding of the main two memory modes/layouts -- known as mode 20 (LoROM) and mode 21 (HiROM), which are effectively two separate types of PCBs -- I suggest seeing 3 pictures Tepples drew somewhat recently. One is a "summary" (i.e. general concept of the entire memory space as a whole), the other two are more precise/specific to each mode (these are the two I suggest understanding): viewtopic.php?p=235113#p235113

There are tons of revisions of these PCBs based on what features you want (battery-backed SRAM, etc.), and others which have unique tweaks/etc. applied to them in certain ways (those are a per-game thing, so do not get hung up on them or focus on them; understand the commonplace memory layouts first).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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